Datengranularität und -beibehaltung

Aggregation von Datenwerten

Der Überwachungsdienst erfasst diverse Daten über Benutzersitzungsnutzung, Benutzeranmeldeleistung, Sitzungslastausgleich und zu Fehlern bei Verbindungen und Maschinen. Die Daten werden je nach Kategorie unterschiedlich aggregiert. Zum Interpretieren der Daten sind Kenntnisse über die Aggregation der mit den OData-Methoden-APIs abgerufenen Datenwerte unverzichtbar. Beispiel:

  • Fehler bei verbundenen Sitzungen und Maschinen treten über einen Zeitraum verteilt auf. Daher werden sie per Zeitraum als Höchstwerte angegeben.
  • Die Anmeldedauer ist ein Zeitlängenwert und wird daher als Durchschnitt per Zeitraum angegeben.
  • Die Anzahl der Anmeldungen und Verbindungsfehler repräsentieren eine Anzahl von Vorkommen in einem bestimmten Zeitraum und werden als Summen in einem Zeitraum gemacht.

Gleichzeitigkeit von Daten

Sitzungen müssen sich überschneiden, um als gleichzeitig angesehen zu werden. Wenn das Zeitintervall jedoch 1 Minute beträgt, werden alle Sitzungen in dieser Minute (unabhängig davon, ob sie sich überlappen) als gleichzeitig behandelt. Das Intervall ist so klein, dass der Mehraufwand für die Berechnung der Genauigkeit sich nicht lohnt. Finden die Sitzungen in der gleichen Stunde, aber nicht in der gleichen Minute statt, werden sie als einander nicht überschneidend angesehen.

Korrelation zwischen Zusammenfassungstabellen und Rohdaten

Das Datenmodell stellt Metriken auf zwei verschiedene Arten dar:

  • Die Zusammenfassungstabellen zeigen aggregierte Ansichten der Metriken in Granularitäten pro Minute, Stunde und Tag an.
  • Die Rohdaten stehen für einzelne Ereignisse oder den aktuellen Zustand, der bzw. die für eine Sitzung, Verbindung, Anwendung und andere Objekte protokolliert werden.

Wenn Sie versuchen, Daten über API-Aufrufe hinweg oder innerhalb des Datenmodells selbst zu korrelieren, sollten Sie die folgenden Konzepte und Einschränkungen kennen:

  • Keine Zusammenfassungsdaten für Teilintervalle: Die Zusammenfassungen von Metriken erfüllen die Anforderungen von historischen Trends über lange Zeiträume. Diese Metriken werden für vollständige Intervalle in der Zusammenfassungstabelle aggregiert. Für Teilintervalle am Anfang (die ältesten verfügbaren Daten) und am Ende der Datensammlung gibt es keine Zusammenfassungsdaten. Beim Anzeigen der Aggregation eines Tages (Intervall=1440) bedeutet dies, dass der erste Tag und der aktuelle unvollständige Tag keine Daten aufweisen. Obwohl für diese Teilintervalle u. U. Rohdaten vorhanden sind, werden sie nie zusammengefasst. Entnehmen Sie die Mindest- und Höchstwerte für “SummaryDate” aus einer bestimmten Zusammenfassungstabelle, um das früheste und letzte Aggregationsintervall für eine bestimmte Datengranularität zu bestimmen. Die Spalte “SummaryDate” stellt den Start des Intervalls dar. Die Spalte “Granularity” steht für die Länge des Intervalls der aggregierten Daten.
  • Korrelation nach Zeit: Metriken werden, wie im vorigen Abschnitt beschrieben, für vollständige Intervalle in der Zusammenfassungstabelle aggregiert. Sie können für historische Trends verwendet werden, aber rohe Ereignisdaten stellen möglicherweise einen aktuelleren Zustand dar als die Zusammenfassung für die Trendanalyse. Bei zeitbasierten Vergleichen zwischen der Zusammenfassung und den Rohdaten muss beachtet werden, dass es keine Zusammenfassungsdaten für Teilintervalle gibt, die am Anfang und Ende des Zeitraums auftreten.
  • Verpasste und latente Ereignisse: Wenn Ereignisse verpasst werden oder während des Aggregationszeitraums latent sind, sind die für die Zusammenfassungstabelle aggregierten Metriken möglicherweise ungenau. Obwohl der Überwachungsdienst versucht, einen genauen aktuellen Zustand zu erhalten, wird die Aggregation für verpasste oder latente Ereignisse nicht im Nachhinein neu für die Zusammenfassungstabellen berechnet.
  • Hochverfügbare Verbindungen: Bei hoher Verfügbarkeit von Verbindungen entstehen in den Zusammenfassungsdaten für aktuelle Verbindungen Lücken, aber die Sitzungsinstanzen werden dennoch in den Rohdaten ausgeführt.
  • Beibehaltungszeitraum für Daten: Daten werden in den Zusammenfassungstabellen basierend auf einem anderen Bereinigungszeitplan beibehalten als Rohdaten von Ereignissen. Daten fehlen möglicherweise, weil die Zusammenfassungstabellen oder die unformatierten Tabellen bereinigt wurde. Beibehaltungszeiträume können unterschiedliche Granularitäten für Zusammenfassungsdaten aufweisen. Daten basierend auf niedrigerer Granularität (Minuten) werden schneller bereinigt als Daten, die auf höherer Granularität (Tage) basieren. Wenn Daten bereinigt wurden und in einer Granularitätskategorie fehlen, sind sie möglicherweise in einer höheren Granularitätskategorie. API-Aufrufe geben nur Daten für die angeforderte Granularität zurück. Wenn für eine Granularität keine Daten zurückgegeben werden, sind möglicherweise für den gleichen Zeitraum Daten für eine höhere Granularität vorhanden.
  • Zeitzonen: Metriken werden mit UTC-Zeitstempeln gespeichert. Zusammenfassungstabellen werden basierend auf stündlichen Zeitzonengrenzen aggregiert. Bei Zeitzonen, die nicht in diese stündlichen Grenzen fallen, gibt es möglicherweise Unstimmigkeiten beim Ort der Datenaggregation.

Datengranularität und -beibehaltung

Die Granularität der aggregierten Daten, die vom Überwachungsdienst abgerufen werden, ist eine Funktion des angeforderten Zeitraums (T). Folgende Regeln gelten:

  • 0 <T <=30 Tage: stundengenaue Granularität wird verwendet
  • T > 31 Tage: tagesgenaue Granularität wird verwendet

Angeforderte Daten, die nicht von aggregierten Daten stammen, stammen von den rohen Sitzungs- und Verbindungsinformationen. Diese Menge dieser Daten nimmt schnell zu, daher haben sie eine eigene Bereinigungseinstellung. Bereinigung gewährleistet, dass nur relevante Daten langfristig gespeichert werden. Damit wird eine bessere Leistung sichergestellt, während die für die Berichterstellung erforderliche Granularität beibehalten werden kann.

Einstellungsname Betroffene Bereinigung Aufbewahrungszeit für Premium Aufbewahrungszeit für Advanced
  1 GroomSessionsRetentionDays Beibehaltungszeitraum für Sitzungs- und Verbindungsinformationen nach Beenden der Sitzung 90 31
  2 GroomFailuresRetentionDays Einträge für MachineFailureLog und ConnectionFailureLog 90 31
  3 GroomLoadIndexesRetentionDays Einträge für LoadIndex 3 3
  4 GroomDeletedRetentionDays Maschinen-, Katalog-, Desktopgruppen- und Hypervisorentitäten, die einen LifecycleState von “Deleted” haben. Dadurch werden auch zugehörige Einträge für Sitzung, Sitzungsdetail, Zusammenfassung, Fehler oder LoadIndex gelöscht. 90 31
  5 GroomSummariesRetentionDays Einträge für DesktopGroupSummary, FailureLogSummary und LoadIndexSummary. Aggregierte Daten, tägliche Granularität 365 31
  6 GroomMachineHotfixLogRetentionDays Auf VDA und Controllermaschinen angewendete Hotfixes 90 31
  7 GroomHourlyRetentionDays Aggregierte Daten - stundengenaue Granularität 32 31
  8 GroomApplicationInstanceRetentionDays Anwendungsinstanzverlauf 90 Nicht zutreffend
  9 GroomNotificationLogRetentionDays Benachrichtigungsprotokolldaten 90 Nicht zutreffend
  10 GroomResourceUsageRawDataRetentionDays Rohdaten zur Ressourcenauslastung 3 3
  11 GroomResourceUsageHourDataRetentionDays Zusammengefasste Daten zur Ressourcenauslastung mit stundengenauer Granularität 30 30
  12 GroomResourceUsageDayDataRetentionDays Zusammengefasste Daten zur Ressourcenauslastung mit tagesgenauer Granularität 365 31
  13 GroomProcessUsageRawDataRetentionDays Rohdaten zur Prozessauslastung 1 1
  14 GroomProcessUsageHourDataRetentionDays Zusammengefasste Daten zur Auslastung mit stundengenauer Granularität 7 7
  15 GroomProcessUsageDayDataRetentionDays Zusammengefasste Daten zur Auslastung mit tagesgenauer Granularität 30 30
  16 GroomSessionMetricsDataRetentionDays Daten zu Sitzungskennzahlen 1 1
  17 GroomMachineMetricDataRetentionDays Daten zu Maschinenkennzahlen 3 3
  18 GroomMachineMetricDaySummaryDataRetentionDays Zusammengefasste Daten zu Maschinenkennzahlen 365 31
  19 GroomApplicationErrorsRetentionDays Anwendungsfehlerdaten 1 1
  20 GroomApplicationFaultsRetentionDays Anwendungsausfalldaten 1 1

Achtung:

Sie können die Werte in der Überwachungsdienstdatenbank nicht ändern.

Das Beibehalten von Daten über lange Zeiträume hinweg hat die folgenden Auswirkungen auf die Größe von Tabellen:

  • Stundengenaue Daten: Wenn Sie stundengenaue Daten bis zu zwei Jahre lang in der Datenbank speichern, wächst die Datenbank einer Site mit 1000 Bereitstellungsgruppen ungefähr wie folgt an:

    1000 Bereitstellungsgruppen x 24 Stunden/Tag x 365 Tage/Jahr x 2 Jahre = 17.520.000 Datenreihen. Diese große Datenmenge in den Aggregationstabellen hat beträchtliche Auswirkungen auf die Leistung. Wenn man bedenkt, dass die Dashboarddaten aus dieser Tabelle gezogen werden, sind die Anforderungen an den Datenbankserver möglicherweise riesig. Übermäßig viele Daten können dramatische Auswirkungen auf die Leistung haben.

  • Sitzungs- und Ereignisdaten: Diese Daten werden jedes Mal gesammelt, wenn eine Sitzung gestartet und eine Verbindung/Wiederverbindung hergestellt wird. Bei einer großen Site (100.000 Benutzer) nimmt die Menge dieser Daten schnell zu. Beispielsweise entsprechen die über zwei Jahre gespeicherten Tabellen mehr als ein TB Daten und erfordern eine High-End-Unternehmensdatenbank.

Datengranularität und -beibehaltung