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:
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
- Lesen Sie zum Einstieg Verwenden von Azure Virtual Desktop Insights zum Überwachen Ihrer Bereitstellung.
- Informationen dazu, wie Sie Ihre Datenspeicherkosten schätzen, messen und verwalten können, finden Sie unter Schätzung der Azure Monitor-Kosten.
- Wenn ein Problem auftritt, finden Sie weitere Informationen im Leitfaden zur Problembehebung.
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:
Stellen Sie in der Tech Community zu Azure Virtual Desktop Fragen, oder machen Sie der Community Vorschläge.
Informationen zum Hinterlassen von Feedback finden Sie unter Problembehandlung: Übersicht, Feedback und Support für Azure Virtual Desktop.
Sie können Ihr Feedback bezüglich Azure Virtual Desktop auch im Azure Virtual Desktop-Feedback-Hub hochladen.