Product Documentation
Herunterladen:PDFPRINT

Zugriff auf Daten mit der API

Jun 20, 2017

Die folgenden Datentypen sind über die Überwachungsdienst-API verfügbar:

  • Daten zu Verbindungsfehlern
  • Maschinen in fehlerhaftem Zustand
  • Sitzungsnutzung
  • Anmeldedauer
  • Daten zum Lastausgleich
  • Auf eine Maschine angewendete Hotfixes
  • Verwendung gehostete Anwendung

Eine komplette Beschreibung der Datenobjekte finden Sie unter http://blogs.citrix.com/2013/08/27/xendesktop-7-monitor-service-what-data-is-available/. 

Zur Verwendung der Überwachungsdienst-OData-API müssen Sie XenApp- bzw. XenDesktop-Administrator sein. Zum Aufrufen der API ist Lesezugriff erforderlich. Welche Daten zurückgegeben werden, hängt von den Rollen und Berechtigungen des XenApp- bzw. XenDesktop-Administrators ab. Administratoren von Bereitstellungsgruppen können beispielsweise die Überwachungsdienst-API aufrufen, aber die zurückgegebenen Daten hängen von dem mit Citrix Studio eingerichteten Bereitstellungsgruppenzugriff ab. Weitere Informationen über XenApp-/XenDesktop-Administratorrollen und -berechtigungen finden Sie unter Delegierte Administration.

Abfragen der Daten

Die Überwachungsdienst-API ist eine REST-basierte API, auf die mit einem OData-Consumer zugegriffen werden kann. OData-Consumer sind Anwendungen, die mit dem OData-Protokoll verfügbar gemachte Daten nutzen. OData-Consumer reichen vom einfachen Webbrowser bis zur benutzerdefinierten Anwendung, die sämtliche Features des OData-Protokolls nutzt. Weitere Informationen über OData-Consumer finden Sie unter http://www.odata.org/ecosystem#consumers.

Jeder Teil des Überwachungsdienst-Datenmodells ist zugänglich und kann über die URL gefiltert werden. OData bietet eine Abfragesprache im URL-Format zum Abrufen von Einträgen aus einem Dienst. Weitere Informationen finden Sie unter http://msdn.microsoft.com/en-us/library/ff478141.aspx.

Die Abfrage wird serverseitig verarbeitet und kann clientseitig mit dem OData-Protokoll weiter gefiltert werden.

Die modellierten Daten fallen in drei Hauptkategorien: Aggregierte Daten (die Zusammenfassungstabellen), aktueller Zustand von Objekten (Maschinen, Sitzungen usw.) und Protokolldaten, wobei es sich um historische Ereignisse handelt (z. B. Verbindungen).

Hinweis: Enumerationen werden vom OData-Protokoll nicht unterstützt, stattdessen werden ganze Zahlen verwendet. Weitere Informationen zum Bestimmen der von der Überwachungsdienst-OData-API zurückgegebenen Werte finden Sie unter http://support.citrix.com/help/monitorserviceapi/7.6/.

Aggregation der Datenwerte

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 in einem bestimmten Zeitraum auf und werden daher als Höchstwerte in einem Zeitraum verfügbar gemacht.
  • Die Anmeldedauer ist ein Zeitlängenwert und wird daher als Durchschnitt in einem Zeitraum verfügbar gemacht.
  • Die Anzahl der Anmeldungen und Verbindungsfehler repräsentieren eine Anzahl von Vorkommen in einem bestimmten Zeitraum und werden als Summen in einem Zeitraum gemacht.

Auswertung gleichzeitiger 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 der Zusammenfassungstabellen mit 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 <=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 Kunden, die keine Lizenz für die Platinum Edition haben, beginnt die Bereinigung am 8. Tag, unabhängig vom Standardbereinigungszeitraum. Platinum-Kunden können den Beibehaltungszeitraum auf die gewünschte Anzahl an Tagen einstellen, sonst wird der Standardwert verwendet.

Mit den folgenden Einstellungen wird die Bereinigung gesteuert:

Einstellungsname Betroffene Bereinigung Standardwert (Tage) Zugriff mit
GroomSessionsRetentionDays Sitzungs- und Sitzungsdetaileinträge 90 Cmdlet (Set/Get-Monitorconfiguration)
GroomSummariesRetentionDays Einträge für DesktopGroupSummary, FailureLogSummary und LoadIndexSummary. Aggregierte Daten, tägliche Granularität 90 Cmdlet (set/get-monitorconfiguration)
GroomHourlyRetentionDays Aggregierte Daten - stundengenaue Granularität 32 Monitor.Configuration-Datenbanktabelle. Siehe Hinweis unten.
GroomMinuteRetentionDays Aggregierte Daten - minutengenaue Granularität 3 Monitor.Configuration-Datenbanktabelle. Siehe Hinweis unten.
GroomFailuresRetentionDays Einträge für MachineFailureLog und ConnectionFailureLog 90 Cmdlet (set/get-monitorconfiguration)
GroomLoadIndexesRetentionDays Einträge für LoadIndex 90 Cmdlet (set/get-monitorconfiguration)
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 Cmdlet (set/get-monitorconfiguration)
GroomMachineHotfixHistoryRetentionDays Auf VDA und Controllermaschinen angewendete Hotfixes 90 Cmdlet (set/get-monitorconfiguration)
Achtung: Nach dem Ändern von Werten auf 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.

Beibehaltungszeitraum der Bereinigung:

  • Platinum Edition-Kunden können den Beibehaltungszeitraum auf die gewünschte Anzahl an Tagen einstellen, sonst wird der Standardwert verwendet.
  • Für Enterprise Edition-Kunden beginnt die Bereinigung an Tag 32. 
  • Für Kunden mit anderen Editionen als Platinum und Enterprise beginnt die Bereinigung an Tag 8. 
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.