Freigeben über


Glossar zu Azure Virtual Desktop Insights

In diesem Artikel werden Schlüsselbegriffe und Konzepte im Zusammenhang mit Azure Virtual Desktop Insights vorgestellt und kurz beschrieben.

Warnungen

Alle aktiven Azure Monitor-Warnungen, die Sie für das Abonnement konfiguriert und mit Schweregrad 0 klassifiziert haben, werden auf der Seite „Übersicht" angezeigt. Weitere Informationen zum Einrichten von Warnungen finden Sie unter Azure Monitor-Protokollwarnungen.

Verfügbare Sitzungen

„Verfügbare Sitzungen“ zeigt die Anzahl der im Hostpool verfügbaren Sitzungen. Der Dienst berechnet diese Anzahl, indem die Anzahl der virtuellen Computer (VMs) mit der maximal zulässigen Anzahl von Sitzungen pro VM multipliziert und dann die Gesamtanzahl der Sitzungen subtrahiert wird.

Clientbetriebssystem

Das Clientbetriebssystem zeigt an, welche Version des Betriebssystems von Endbenutzern derzeit verwendet wird, die auf Azure Virtual Desktop-Ressourcen zugreifen. Das Clientbetriebssystem zeigt auch an, welche Version des Webclients (HTML) und des vollständigen Remotedesktopclients die Benutzer verwenden. Eine vollständige Liste der Windows-Betriebssystemversionen finden Sie unter Betriebssystemversion.

Verbindung erfolgreich

Dieses Element zeigt die Verbindungsintegrität. „Verbindung erfolgreich“ bedeutet, dass die Verbindung den Host erreichen kann, was vom Stapel auf der jeweiligen VM bestätigt wird. Eine fehlgeschlagene Verbindung bedeutet, dass die Verbindung den Host nicht erreichen konnte.

Aktive Benutzer pro Tag

Die Gesamtanzahl der Benutzer, die in den letzten 24 Stunden eine Sitzung gestartet haben.

Tägliche Warnungen

Die Gesamtanzahl der pro Tag ausgelösten Warnungen.

Tägliche Verbindungen und erneute Verbindungen

Die Gesamtanzahl der Verbindungen und erneuten Verbindungen, die innerhalb der letzten 24 Stunden gestartet oder abgeschlossen wurden.

Täglich verbundene Stunden

Die Gesamtanzahl der Stunden, in denen die Benutzer in den letzten 24 Stunden mit einer Sitzung verbunden waren.

Diagnose und Fehler

Wenn ein Fehler oder eine Warnung in Azure Virtual Desktop Insights auftritt, erfolgt eine Kategorisierung nach drei Kriterien:

  • Aktivitätstyp: Diese Kategorie bestimmt, wie der Fehler von der Azure Virtual Desktop-Diagnose kategorisiert wird. Die Kategorien sind Verwaltungsaktivitäten, Feeds, Verbindungen, Hostregistrierungen, Fehler und Prüfpunkte. Weitere Informationen zu diesen Kategorien finden Sie unter Verwenden von Log Analytics für die Diagnosefunktion.

  • Variante: Diese Kategorie zeigt den Speicherort des Fehlers.

    • Fehler, die mit „service“ oder „ServiceError = TRUE“ markiert sind, sind im Dienst Azure Virtual Desktop aufgetreten.
    • Fehler, die mit „deployment“ oder „ServiceError = FALSE“ markiert sind, sind außerhalb des Diensts Azure Virtual Desktop aufgetreten.
    • Weitere Informationen zum Tag ServiceError finden Sie unter Gängige Fehlerszenarien.
  • Quelle: Diese Kategorie liefert eine spezifischere Beschreibung, wo der Fehler aufgetreten ist.

    • Diagnose: Die Dienstrolle, die für die Überwachung und Berichterstellung bezüglich der Dienstaktivität verantwortlich ist, damit Benutzer Bereitstellungsprobleme beobachten und diagnostizieren können.

    • RDBroker: Die Dienstrolle, die u. a. für die Orchestrierung von Bereitstellungsaktivitäten, Aufrechterhaltung des Zustands von Objekten und Überprüfung der Authentifizierung verantwortlich ist.

    • RDGateway: Die Dienstrolle, die für die Netzwerkkonnektivität zwischen Endbenutzern und VMs zuständig ist.

    • RDStack: Eine Softwarekomponente, die auf Ihren VMs installiert ist, damit diese mit dem Dienst Azure Virtual Desktop kommunizieren können.

    • Client: Software, die auf dem Computer des Endbenutzers ausgeführt wird und die Schnittstelle zum Dienst Azure Virtual Desktop bereitstellt. Sie zeigt die Liste der veröffentlichten Ressourcen an und hostet die Remotedesktopverbindung, nachdem Sie eine Wahl getroffen haben.

Alle Diagnoseprobleme oder -fehler enthalten eine Meldung, in der erläutert wird, was falsch gelaufen ist. Weitere Informationen zur Problembehandlung finden Sie unter Identifizieren und Diagnostizieren von Problemen mit Azure Virtual Desktop.

Gatewayregionscodes

Einige Metriken in Azure Virtual Desktop Insights listen die Gatewayregion auf, über die Benutzerinnen und Benutzer eine Verbindung herstellen. Die Gatewayregion wird durch einen Code aus drei oder vier Buchstaben dargestellt, der der Azure-Region entspricht, in der sich das Gateway befindet. In der folgenden Tabelle sind die Gatewayregionscodes und die zugehörigen Azure-Regionen aufgeführt:

Gatewayregionscode Azure-Region
AUC Australien, Mitte
AUC2 Australien, Mitte 2
AUE Australien (Osten)
AUSE Australien, Südosten
BRS Brasilien, Süden
CAC Kanada, Mitte
CAE Kanada, Osten
CHNO Schweiz, Norden
CIN Indien, Mitte
CUS USA (Mitte)
EAS Asien, Osten
EEU Europa, Osten
EUS East US
EUS2 USA (Ost) 2
FRAS Frankreich, Süden
FRC Frankreich, Mitte
GEC Deutschland, Mitte
GEN Deutschland, Norden
GENE Deutschland, Nordosten
GWC Deutschland, Westen-Mitte
JPE Japan, Osten
JPW Japan, Westen
KRC Korea, Mitte
KRS Korea, Süden
KRS2 Südkorea, Süden 2
NCUS USA Nord Mitte
NEU Nordeuropa
NOE Norwegen, Osten
NOW Norwegen, Westen
SAN Südafrika, Norden
SAW Südafrika, Westen
SCUS USA Süd Mitte
SEA2 Asien, Südosten 2
SEAS Asien, Südosten
SIN Indien (Süden)
SWW Schweiz, Westen
UAEC VAE, Mitte
UAEN Vereinigte Arabische Emirate, Norden
UKN Vereinigtes Königreich, Norden
UKS UK, Süden
UKS2 Vereinigtes Königreich, Süden 2
UKW UK, Westen
WCUS USA, Westen-Mitte
WEU Europa, Westen
WIN Indien, Westen
WUS USA (Westen)

Eingabeverzögerung

„Eingabeverzögerung“ in Azure Virtual Desktop Insights bezieht sich auf den Leistungsindikator „Input Delay Per Process“ (Eingabeverzögerung pro Prozess) für jede Sitzung. Auf der Host-Leistungsseite unter aka.ms/azmonwvdi ist dieser Leistungszähler so konfiguriert, dass er einmal alle 30 Sekunden einen Bericht an den Dienst sendet. Diese 30-Sekunden-Intervalle werden als „Stichproben“ bezeichnet und melden den ungünstigsten Fall in diesem Fenster. Die Werte „Median“ und „p95“ geben den Median und das 95. Perzentil aller Stichproben wieder.

Unter Input delay by host (Eingabeverzögerung nach Host) können Sie eine Sitzungshostzeile auswählen, um alle anderen visuellen Elemente auf der Seite zu diesem Host zu filtern. Sie können auch einen Prozessnamen auswählen, um die durchschnittliche Eingabeverzögerung im Zeitdiagramm zu filtern.

Wir ordnen Verzögerungen den folgenden Kategorien zu:

  • Gut: unter 150 Millisekunden.
  • Akzeptabel: 150-500 Millisekunden.
  • Schwach: 500-2.000 Millisekunden (unter 2 Sekunden).
  • Schlecht: über 2.000 Millisekunden (ab 2 Sekunden).

Weitere Informationen zur Funktionsweise des Leistungsindikators für die Eingabeverzögerung finden Sie unter Verwenden von Leistungsindikatoren für die Diagnose von Leistungsproblemen von Anwendungen auf Remotedesktop-Sitzungshosts.

Monatlich aktive Benutzer (Monthly Active Users, MAU)

Die Gesamtanzahl der Benutzer, die in den letzten 28 Tagen eine Sitzung gestartet haben. Wenn Sie Daten für maximal 30 Tage speichern, kann es sein, dass Sie in Zeiträumen mit Daten für maximal 28 Tage niedrigere Werte für „Monatlich aktive Benutzer“ und „Verbindung“ sehen als erwartet.

Leistungsindikatoren

Leistungsindikatoren bieten Einblick in die Leistung von Hardwarekomponenten, Betriebssystemen und Anwendungen.

In der folgenden Tabelle sind die empfohlenen Leistungsindikatoren und Zeitintervalle aufgelistet, die von Azure Monitor für Azure Virtual Desktop verwendet werden:

Name des Leistungsindikators Zeitintervall
Logischer Datenträger (C:)\Durchschnittl. Warteschlangenlänge des Datenträgers 30 Sekunden
Logischer Datenträger (C:)\Mittlere Sek./Übertragung 60 Sekunden
Logischer Datenträger (C:)\Aktuelle Warteschlangenlänge 30 Sekunden
Arbeitsspeicher(*)\Verfügbare MB 30 Sekunden
Arbeitsspeicher(*)\Seitenfehler/s 30 Sekunden
Arbeitsspeicher(*)\Seiten/s 30 Sekunden
Arbeitsspeicher(*)\Zugesicherte verwendete Bytes (%) 30 Sekunden
Physischer Datenträger(*)\Durchschnittl. Warteschlangenlänge des Datenträgers 30 Sekunden
Physischer Datenträger(*)\Mittlere Sek./Lesevorgänge 30 Sekunden
Physischer Datenträger(*)\Mittlere Sek./Übertragung 30 Sekunden
Physischer Datenträger(*)\Mittlere Sek./Schreibvorgänge 30 Sekunden
Prozessorinformationen(_Total)\Prozessorzeit (%) 30 Sekunden
Terminaldienste(*)\Aktive Sitzungen 60 Sekunden
Terminaldienste(*)\Inaktive Sitzungen 60 Sekunden
Terminaldienste(*)\Sitzungen insgesamt 60 Sekunden
*Benutzereingabeverzögerung pro Prozess(*)\Maximale Eingabeverzögerung 30 Sekunden
*Benutzereingabeverzögerung pro Sitzung(*)\Maximale Eingabeverzögerung 30 Sekunden
RemoteFX-Netzwerk(*)\Aktuelle TCP-RTT 30 Sekunden
RemoteFX-Netzwerk(*)\Aktuelle UDP-Bandbreite 30 Sekunden

Mögliche Konnektivitätsprobleme

In diesem Abschnitt werden die Hosts, Benutzer, veröffentliche Ressourcen und Clients mit einer hohen Verbindungsfehlerquote gezeigt. Wenn Sie den Filter „Bericht nach“ wählen, können Sie den Schweregrad des Problems beurteilen, indem Sie die Werte in diesen Spalten überprüfen:

  • Versuche (Anzahl der Verbindungsversuche)
  • Ressourcen (Anzahl der veröffentlichten Apps oder Desktops)
  • Hosts (Anzahl der VMs)
  • Clients

Wenn Sie z. B. den Filter Nach Benutzer auswählen, können Sie in der Spalte Versuche die Verbindungsversuche jedes Benutzers überprüfen.

Wenn Sie feststellen, dass sich ein Verbindungsproblem auf mehrere Hosts, Benutzer, Ressourcen oder Clients erstreckt, ist es wahrscheinlich, dass das Problem das gesamte System betrifft. Wenn dies nicht der Fall ist, handelt es sich um ein kleineres Problem mit niedrigerer Priorität.

Sie können auch Einträge auswählen, um weitere Informationen dazu anzuzeigen. Sie können anzeigen, welche Hosts, Ressourcen und Clientversionen in das Problem involviert waren. Die Anzeige enthält auch alle während der Verbindungsversuche gemeldeten Fehler.

Paketumlaufzeit (RTT)

Die Round-Trip-Time (RTT) stellt eine Schätzung der Round-Trip-Zeit der Verbindung zwischen dem Standort des Endbenutzers und der Azure-Region des Sitzungshosts dar. Um festzustellen, welche Standorte die beste Latenz aufweisen, schlagen Sie Ihren gewünschten Standort in den Tool Azure Netzwerk-Latenzstatistiken für Roundtrips nach.

Sitzungsverlauf

Das Element Sitzungen zeigt den Status aller Sitzungen, ob verbunden oder getrennt. In Leerlaufsitzungen werden nur die getrennten Sitzungen gezeigt.

Warnungen mit Schweregrad 0

Die dringendsten Angelegenheiten, um die Sie sich sofort kümmern müssen. Wenn Sie diese Probleme nicht angehen, könnten sie dazu führen, dass Ihre Azure Virtual Desktop-Bereitstellung nicht mehr funktioniert.

Zeit für Verbindungsherstellung

Die Zeit für Verbindungsherstellung ist die Zeit zwischen dem Zeitpunkt des Öffnens einer Ressource durch den Benutzer und dem Zeitpunkt, zu dem der Desktop geladen und einsatzbereit ist. Bei einer RemoteApp ist dies beispielsweise die Zeit, die zum Starten der Anwendung benötigt wird.

Die Zeit für Verbindungsherstellung umfasst zwei Phasen:

  • Verbindung: Dies ist die Dauer, die der Azure-Dienst benötigt, um den Benutzer zu einen Sitzungshost weiterzuleiten.
  • Anmeldung, d. h., wie lange der Dienst braucht, um die Aufgaben im Zusammenhang mit der Anmeldung des Benutzers und dem Aufbau der Sitzung auf dem Sitzungshost auszuführen.

Beachten Sie beim Überwachen der Zeit für Verbindungsherstellung Folgendes:

  • Die Zeit für die Verbindungsherstellung wird anhand der folgenden Prüfpunkte in Azure Virtual Desktop-Dienstdiagnosedaten gemessen. Die Prüfpunkte, die Insights verwendet, um zu bestimmen, wann die Verbindung hergestellt ist, sind für ein Desktop- und ein RemoteApp-Szenario unterschiedlich.

    • Beginn: WVDConnection Status = gestartet

    • Endet: WVDCheckpoints Name = ShellReady (Desktops); Name = RdpShellAppExecuted (RemoteApp. Für die Zeitplanung sollten Sie nur den ersten App-Start in Betracht ziehen)

Insights misst beispielsweise die Zeit, die zum Starten einer Desktoperfahrung benötigt wird, anhand der Zeit, die zum Starten des Windows Explorer benötigt wird. Insights misst auch die Zeit für das Starten einer RemoteApp basierend auf der Zeit, die zum Starten der ersten Instanz der Shell-App für eine Verbindung benötigt wird.

Hinweis

Wenn ein Benutzer mehrere RemoteApps startet, kann die Shell-App manchmal mehrmals während einer einzigen Verbindung ausgeführt werden. Für eine genaue Messung der Verbindungsdauer sollten Sie nur den ersten Ausführungsprüfpunkt für jede Verbindung verwenden.

  • Das Einrichten neuer Sitzungen dauert in der Regel länger als das Wiederherstellen von Verbindungen mit vorhandenen Sitzungen. Dies liegt an den Unterschieden im Anmeldevorgang für neue und bestehende Verbindungen.

  • Die Zeit, die der Benutzer benötigt, um seine Anmeldeinformationen einzugeben, wird von der Zeit abgezogen, die er benötigt, um sich mit dem Konto zu verbinden. Dies gilt für Situationen, in denen ein Benutzer entweder eine Weile braucht, um seine Anmeldeinformationen einzugeben, oder alternative Authentifizierungsmethoden für die Anmeldung verwendet.

Bei der Problembehandlung eines hohen Zeitaufwands für die Verbindungsherstellung schlüsselt Azure Monitor die gesamten Daten zur Zeit für Verbindungsherstellung in vier Komponenten auf, um Ihnen zu zeigen, wie Sie die Anmeldezeit verkürzen können.

Hinweis

Die Komponenten in diesem Abschnitt zeigen nur die primären Verbindungsphasen. Diese Komponenten können parallel ausgeführt werden, was bedeutet, dass sie sich nicht zur Gesamtzeit der Verbindungsherstellung addieren lassen. Die Gesamtzeit für die Verbindungsherstellung ist eine Messung, die Azure Monitor in einem separaten Prozess vornimmt.

Das folgende Flussdiagramm zeigt die vier Phasen des Anmeldeprozesses:

Ein Flussdiagramm, das die vier Phasen des Anmeldevorgangs zeigt: Benutzerroute, Herstellen der Stapelverbindung, Anmeldung und Shellstart in Shell bereit.

Das Flussdiagramm zeigt die folgenden vier Komponenten:

  • Benutzerroute: die Zeit, die vergeht, nachdem der Benutzer das Azure Virtual Desktop-Symbol ausgewählt hat, um eine Sitzung zu starten, bis der Dienst einen Host ermittelt hat, mit dem er sich verbinden kann. Eine hohe Netzwerklast, eine hohe Dienstauslastung oder ein spezifisches Routing von Netzwerkdatenverkehr kann zu langen Routingzeiten führen. Um Probleme mit dem Benutzerrouting zu beheben, sehen Sie sich Ihre Netzwerkpfade an.

  • Herstellen der Stapelverbindung: die Zeit, die von der Auflösung eines Zielsitzungshosts für den Benutzer bis zum Aufbau einer Verbindung zwischen dem Sitzungshost und dem Remoteclient des Benutzers durch den Dienst vergeht. Wie das Benutzerrouting können auch die Netzwerk- und Serverauslastung oder das spezifische Routing des Netzwerkdatenverkehrs die Zeit für Verbindungsherstellung beeinflussen. Bei dieser Komponente müssen Sie auch auf das Netzwerkrouting achten. Um die Verbindungszeit zu verkürzen, stellen Sie sicher, dass Sie alle Proxykonfigurationen sowohl auf dem Client- als auch auf dem Sitzungshost richtig konfiguriert haben und dass das Routing zum Dienst optimal ist.

  • Anmeldung: die Zeit, die zwischen dem Herstellen einer Verbindung mit einem Host und dem Beginn des Ladens der Shell vergeht. Die Anmeldezeit umfasst mehrere Prozesse, die zu langen Verbindungszeiten beitragen können. Sie können Daten für die Anmeldephase in Insights einsehen, um zu prüfen, ob es zu normalen Zeiten zu unerwarteten Spitzen kommt.

    Der Anmeldevorgang ist in vier Phasen unterteilt:

    • Profile: die Zeit, die benötigt wird, um das Profil eines Benutzers für neue Sitzungen zu laden. Die Dauer des Ladevorgangs hängt von der Größe des Benutzerprofils oder den von Ihnen verwendeten Benutzerprofillösungen (z. B. User Experience Virtualization) ab. Wenn Sie eine Lösung verwenden, die auf im Netzwerk gespeicherte Profile angewiesen ist, kann eine übermäßige Latenz auch zu längeren Ladezeiten für Profile führen.

    • Gruppenrichtlinienobjekte: die Zeit, die benötigt wird, um Gruppenrichtlinien auf neue Sitzungen anzuwenden. Eine Spitze in diesem Bereich der Daten ist ein Zeichen dafür, dass es zu viele Gruppenrichtlinien gibt, die Umsetzung der Richtlinien zu lange dauert oder der Sitzungshost mit Ressourcenproblemen zu kämpfen hat. Sie können die Verarbeitungszeiten optimieren, indem Sie sicherstellen, dass sich der Domänencontroller so nah wie möglich bei den Sitzungshosts befindet.

    • Shellstart: die Zeit, die zum Starten der Shell benötigt wird (in der Regel „explorer.exe“).

    • FSLogix (Frxsvc): die Zeit, die zum Starten von FSLogix in neuen Sitzungen benötigt wird. Eine lange Startzeit kann auf Probleme mit den Freigaben zum Hosten der FSLogix-Benutzerprofile hinweisen. Um diese Probleme zu beheben, stellen Sie sicher, dass die Freigaben mit den Sitzungshosts verbunden sind und für die durchschnittliche Anzahl der Benutzer, die sich bei den Hosts anmelden, angemessen dimensioniert sind. Ein weiterer Bereich, den Sie sich ansehen sollten, ist die Profilgröße. Durch hohe Profilgrößen können sich Startzeiten verlangsamen.

  • Shellstart in Shell bereit: die Zeit zwischen dem Beginn des Ladevorgangs und dem Zeitpunkt, an dem die Shell vollständig geladen und einsatzbereit ist. Verzögerungen in dieser Phase können durch Sitzungshostüberlastung (hohe CPU-, Arbeitsspeicher- oder Datenträgeraktivität) oder Konfigurationsprobleme verursacht werden.

Benutzerbericht

Auf dieser Seite können Sie den Verbindungsverlauf und die Diagnoseinformationen eines bestimmten Benutzers einsehen. Jeder Benutzerbericht zeigt Nutzungsmuster, Benutzerfeedback und Fehler, die in den Sitzungen der Benutzer aufgetreten sind. Die meisten kleineren Probleme können mithilfe von Benutzerfeedback gelöst werden. Wenn Sie genauer nachforschen müssen, können Sie auch Informationen zu einer bestimmten Verbindungs-ID oder einem bestimmten Zeitraum filtern.

Benutzer pro Kern

Dies ist die Anzahl der Benutzer pro VM-Kern. Die Nachverfolgung der maximalen Anzahl von Benutzern pro Kern im Zeitverlauf kann Ihnen helfen festzustellen, ob die Umgebung konstant mit einer hohen, niedrigen oder schwankenden Anzahl von Benutzern pro Kern betrieben wird. Wenn Sie wissen, wie viele Benutzer aktiv sind, können Sie die Ressourcen effizient nutzen und die Umgebung skalieren.

Windows-Ereignisprotokolle

Windows-Ereignisprotokolle sind Datenquellen, die entweder vom Log Analytics-Agent oder vom Azure Monitor-Agent auf virtuellen Windows-Computern erfasst werden. Sie können Ereignisse sowohl aus Standardprotokollen wie „System“ und „Anwendung“ als auch aus benutzerdefinierten Protokollen sammeln, die von zu überwachenden Anwendungen erstellt wurden.

In der folgenden Tabelle sind die erforderlichen Windows-Event-Protokolle für Azure Virtual Desktop Insights aufgeführt:

Ereignisname Ereignistyp
Anwendung Fehler und Warnungen
Microsoft-Windows-TerminalServices-RemoteConnectionManager/Admin Fehler, Warnung und Information
Microsoft-Windows-TerminalServices-LocalSessionManager/Operational Fehler, Warnung und Information
System Fehler und Warnungen
Microsoft-FSLogix-Apps/Operational Fehler, Warnung und Information
Microsoft-FSLogix-Apps/Admin Fehler, Warnung und Information

Nächste Schritte

Sie können auch Azure Advisor einrichten, um herauszufinden, wie gängige Probleme gelöst oder verhindert werden. Weitere Informationen finden Sie unter Einführung in Azure Advisor.

Wenn Sie Hilfe benötigen oder Fragen haben, konsultieren Sie unsere Communityressourcen: