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. Bei einem Zeitintervall von 1 Minute werden jedoch alle Sitzungen in dieser Minute (mit oder ohne Überschneidung) als gleichzeitig angesehen, d. h. das Intervall ist so klein, dass sich der Mehraufwand für die Berechnung der Genauigkeit 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 hinweg. 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. Sie können das früheste und letzte Aggregationsintervall für eine bestimmte Datengranularität festlegen, indem Sie die Mindest- und Höchstwerte für “SummaryDate” aus einer bestimmten Zusammenfassungstabelle nehmen. 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 oben 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 von Director abgerufen werden, ist eine Funktion des angeforderten Zeitraums (T). Folgende Regeln gelten:

  • 0 < T <= 1 Stunde: minutengenaue Granularität wird verwendet
  • 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. Bei einer Site mit Platinum-Lizenz kann der Beibehaltungszeitraum auf die gewünschte Anzahl an Tagen eingestellt werden, ansonsten wird der Standardwert verwendet.

Um auf die Einstellungen zuzugreifen, führen Sie die folgenden PowerShell-Befehle auf dem Delivery Controller aus:

asnp Citrix.*
 Get-MonitorConfiguration
 Set-MonitorConfiguration -<setting name> <value>

Mit den folgenden Einstellungen wird die Bereinigung gesteuert:

  Einstellungsname Betroffene Bereinigung Standardwert für Platinum (Tage) Standardwert für andere Lizenzen (Tage)
1 GroomSessionsRetentionDays Beibehaltungszeitraum für Sitzungs- und Verbindungsinformationen nach Beenden der Sitzung 90 7
2 GroomFailuresRetentionDays Einträge für MachineFailureLog und ConnectionFailureLog 90 7
3 GroomLoadIndexesRetentionDays Einträge für LoadIndex 90 7
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 7
5 GroomSummariesRetentionDays Einträge für DesktopGroupSummary, FailureLogSummary und LoadIndexSummary. Aggregierte Daten, tägliche Granularität 90 7
6 GroomMachineHotfixLogRetentionDays Auf VDA und Controllermaschinen angewendete Hotfixes 90 90
7 GroomMinuteRetentionDays Aggregierte Daten - minutengenaue Granularität 3 3
8 GroomHourlyRetentionDays Aggregierte Daten - stundengenaue Granularität 32 7
1031 GroomApplicationInstanceRetentionDays Anwendungsinstanzverlauf 90 0
10 GroomNotificationLogRetentionDays Benachrichtigungsprotokolldaten 90  
11 GroomResourceUsageRawDataRetentionDays Rohdaten zur Ressourcenauslastung 1 1
12 GroomResourceUsageMinuteDataRetentionDays Zusammengefasste Daten zur Ressourcenauslastung mit minutengenauer Granularität 7 7
13 GroomResourceUsageHourDataRetentionDays Zusammengefasste Daten zur Ressourcenauslastung mit stundengenauer Granularität 30 7
14 GroomResourceUsageDayDataRetentionDays Zusammengefasste Daten zur Ressourcenauslastung mit tagesgenauer Granularität 90 7
15 GroomProcessUsageRawDataRetentionDays Rohdaten zur Prozessauslastung 1 1
16 GroomProcessUsageMinuteDataRetentionDays Zusammengefasste Daten zur Auslastung mit minutengenauer Granularität 3 3
17 GroomProcessUsageHourDataRetentionDays Zusammengefasste Daten zur Auslastung mit stundengenauer Granularität 7 7
18 GroomProcessUsageDayDataRetentionDays Zusammengefasste Daten zur Auslastung mit tagesgenauer Granularität 30 7
19 GroomSessionMetricsDataRetentionDays Daten zu Sitzungskennzahlen 7 7
20 GroomMachineMetricDataRetentionDays Daten zu Maschinenkennzahlen 3 3
21 GroomMachineMetricDaySummaryDataRetentionDays Zusammengefasste Daten zu Maschinenkennzahlen 90 7
22 GroomApplicationErrorsRetentionDays Anwendungsfehlerdaten 1 1
23 GroomApplicationFaultsRetentionDays Anwendungsausfalldaten 1 1

Achtung: Nach dem Ändern von Werten in der Überwachungsdienstdatenbank ist ein Neustart des Diensts erforderlich, damit die neuen Werte wirksam werden. Führen Sie Änderungen an der Überwachungsdienstdatenbank nur mit Anleitung vom Citrix Support durch.

Hinweise zum Beibehaltungszeitraum:

  • Sites mit Platinum-Lizenz: Sie können den Beibehaltungszeitraum auf eine beliebige Anzahl an Tagen aktualisieren.
    • Ausnahme: GroomApplicationErrorsRetentionDays und GroomApplicationFaultsRetentionDays sind auf 31 Tage begrenzt. GroomProcessUsageRawDataRetentionDays ist auf 1 Tag beschränkt.
  • Sites mit Enterprise-Lizenz: Der Beibehaltungszeitraum ist für alle Einstellungen auf 31 Tage beschränkt.
  • Alle anderen Sites: Der Beibehaltungszeitraum ist für alle Einstellungen auf 7 Tage beschränkt.

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 sehr schnell zu. Beispielsweise entsprechen die über zwei Jahre gespeicherten Tabellen mehr als 1 TB Daten und erfordern eine High-End-Unternehmensdatenbank.