Das CloudWatch RUM-Dashboard anzeigen

Benötigt Aufmerksamkeit (nach Gesundheitszustand) — Zeigt an, wie viele App-Monitore von der Gesamtzahl der App-Monitore Aufmerksamkeit erfordern, aufgeschlüsselt nach den Zählwerten „Kritisch“ und „Eingeschränkt“. Ein Fortschrittsbalken zeigt den Anteil der Monitore an, die Aufmerksamkeit benötigen.

Schlimmerer Trend — Zeigt an, bei wie vielen App-Monitoren im Vergleich zur Gesamtzahl ein sich verschlechternder Trend zu verzeichnen ist.

Einrichtung und Reichweite — Zeigt an, für wie viele App-Monitore keine SLOs konfiguriert sind und für wie viele die Ablaufverfolgung deaktiviert ist. So können Sie Lücken in Ihrer Überwachungseinrichtung leichter erkennen.

SLOs und Alarme — Zeigt die Anzahl der verletzten SLIs an der Gesamtzahl der SLIs und die Anzahl der aktuell ausgelösten Alarme an.

Plattform — Web, iOS oder Android.

Gesundheit — Gesund, Kritisch, Beeinträchtigt oder Keine Daten.

SLI-Status — Fehlerfrei, fehlerhaft oder keine SLOs.

Tracing — Aktiviert oder Deaktiviert.

Trend — Verschlechterung, Verbesserung oder Stabilität.

Hauptproblem — Filtern Sie nach dem primären Problemtyp, der den App-Monitor betrifft.

Name — Der Name des App-Monitors mit einem Plattformsymbol (Web, iOS oder Android).

Sitzungen — Die Anzahl der im ausgewählten Zeitraum aufgezeichneten Sitzungen, die mit einer Balkendiagramm-Visualisierung angezeigt werden.

SLI-Status — Der Status der Service-Level-Indikatoren. Zeigt die Anzahl fehlerhafter SLIs an (z. B. „1/2Ungesund“) oder einen Link zum Erstellen von SLOs, wenn keine SLOs konfiguriert sind.

Zustand — Der Integritätsstatus der Anwendung: Fehlerfrei, Kritisch , Herabgesetzt oder Keine Daten.

Einblicke anzeigen — Wählen Sie diesen Link, um den Diagnosebereich für den App-Monitor zu öffnen (sieheDiagnose-Seitenbereich).

Hauptproblem — Der primäre Problemtyp, der die Anwendung betrifft. Bei Web-App-Monitoren beinhalten die Werte JS-Fehler, Perf oder HTTP errors/faults. Bei Monitoren für mobile Apps gehören zu den Werten Crashes, ANRs/App Hangs, Perf oder HTTP. errors/faults

Trend — Eine Beschreibung der Trendrichtung und -stärke (z. B. „JS-Fehler +1% schlechtere Sitzungen“ oder „Perf +81% schlechtere Sitzungen“).

Tracing — Ein Link anzeigen, wenn Tracing aktiviert ist, oder ein Link „Tracing aktivieren“, wenn dies nicht der Fall ist.

Dienste — Der SLI-Integritätsstatus für verknüpfte Dienste (z. B. „1/1 Ungesund“) oder ein Bindestrich, wenn keine Dienste verknüpft sind.

Letztes empfangenes Ereignis — Die Zeit seit dem Empfang des letzten Telemetrieereignisses (z. B. „vor 1 Minute“ oder „In den letzten 4 Wochen wurden keine Ereignisse empfangen“).

Seitenaufrufe — Die Anzahl der Seitenaufrufe im Zeitverlauf.

Seitenladezeit (p75) — Die Ladezeit der Seiten im 75. Perzentil in Sekunden.

JS-Fehler — Die Anzahl der Fehlersitzungen im Laufe der Zeit. JavaScript

HTTP-Fehler — Die Anzahl der HTTP 4xx-Fehler und 5xx-Fehler im Laufe der Zeit.

Ladezeit des Bildschirms — Die Ladezeit des Bildschirms im Zeitverlauf.

Bildschirmladungen — Die Anzahl der Bildschirmladungen im Laufe der Zeit.

Abstürze — Die Anzahl der Absturzsitzungen im Laufe der Zeit.

App Hangs/ANRs — Die Anzahl der App Hang- (iOS) oder ANR-Sitzungen (Android) im Laufe der Zeit.

HTTP-Fehler — Die Anzahl der HTTP 4xx-Fehler und 5xx-Fehler im Laufe der Zeit.

Verletzte SLOs — Eine Tabelle, in der alle SLOs aufgeführt sind, die sich im Status „Sicherheitsverletzung“ befinden, mit Links zu den SLO-Details.

Alarme im ALARM-Status — Eine Tabelle, in der alle aktuell ausgelösten Alarme für den App-Monitor aufgeführt sind.

Die Registerkarte Leistung zeigt Informationen zur Seitenleistung an, einschließlich Ladezeiten, Anforderungsinformationen, Webdaten und Seitenladezeiten im Zeitverlauf. Auf dieser Registerkarte können Sie auch zwischen Seitenaufrufen, Ressourcen und Speicherorten umschalten, um weitere Details zur Seitenleistung zu sehen.

Die Ansicht „Seite wird geladen“ enthält interaktive Web-Vital-Grafiken, in denen Sie die verschiedenen Perzentilwerte der wichtigsten Web-Vitals für Ihre Seiten sehen und Datenpunkte im Diagramm auswählen können, um die korrelierten Sitzungen anzuzeigen, die von RUM erfasst wurden. CloudWatch Von dort aus können Sie mithilfe eines der Links in der Diagnosetabelle zur Registerkarte „Sitzungen“ navigieren, um bestimmte Bedingungen zu identifizieren, die zu Leistungsproblemen führen. Auf der Registerkarte wird auch der Wert des Anwendungsleistungsindex (Apdex) angezeigt, der den Grad der Zufriedenheit der Endbenutzer angibt. Die Punktzahl reicht von 0 (am wenigsten zufrieden) bis 1 (am zufriedensten). Die Ergebnisse basieren nur auf der Anwendungsleistung. Weitere Informationen über Apdex-Ergebnisse finden Sie unter Wie RUM CloudWatch die Apdex-Werte festlegt. In der Tabelle unten sind die 100 besten Seitenladezeiten auf der Grundlage der Seiten-IDs aufgeführt. Sie können dieses Attribut in der Dropdownliste neben der Tabellenkopfzeile ändern.

In ähnlicher Weise werden in der Ressourcenansicht die Zeit und Anzahl der Ressourcenanfragen nach Ressourcentyp angezeigt. Die Standortansicht verfügt über eine interaktive Karte, mit der Sie eine detailliertere Ansicht aufrufen und Leistungsprobleme in einer bestimmten Region untersuchen können.

Im Diagnosefeld auf der rechten Seite befindet sich auch die Registerkarte Browser und Geräte, auf der die fünf wichtigsten Faktoren aufgeführt sind, die zu dem Leistungsproblem browsers/devices beigetragen haben. Sie können auf das Balkendiagramm klicken, um zur Registerkarte Sitzungen zu gelangen und das Problem weiter zu untersuchen.

Auf der Registerkarte „ JavaScript JS-Fehler“ werden die Fehleranzahl und -rate in der Übersichtskomponente zusammen mit dem Browser und dem Gerät mit den meisten Fehlern angezeigt. Diese Registerkarte enthält ein Diagramm, das die Anzahl der Sitzungen mit JS-Fehlern und die Fehlerrate zeigt. Sie können auf einen beliebigen Datenpunkt im Diagramm klicken, um die korrelierten Sitzungen im Diagnosefenster anzuzeigen. In der Tabelle unten sind die 100 häufigsten JS-Fehler aufgeführt. Über den Link zur Fehleranzahl in der Tabelle können Sie zur Registerkarte „Sitzungen“ navigieren, auf der Sie die entsprechenden Sitzungen anzeigen können.

Auf der Registerkarte „HTTP-Anfragen“ werden das HTTP-Anforderungsvolumen und die Fehlerinformationen in der HTTP-Anforderungsübersicht oben angezeigt. Diese Registerkarte enthält ein Diagramm mit den HTTP-Fehlern, HTTP-Fehlern und Netzwerkausfällen. Sie können auf einen beliebigen Datenpunkt im Diagramm klicken, um die korrelierten Sitzungen im Diagnosefenster anzuzeigen. In der Tabelle unten sind die 100 Netzwerkrouten mit den häufigsten Problemen aufgeführt. Wenn Sie eine der Zeilen erweitern, werden die häufigsten Fehlermeldungen für diese URL angezeigt. Über den Link zur Fehleranzahl in der Tabelle können Sie zur Registerkarte „Sitzungen“ navigieren, auf der Sie die entsprechenden Sitzungen anzeigen können.

Auf der Registerkarte „Sitzungen“ wird eine Tabelle angezeigt, in der alle Sitzungen in absteigender chronologischer Reihenfolge aufgeführt sind. Unten zeigt eine Wasserfallvisualisierung die gesamte Telemetrie für die ausgewählte Sitzung. So können Sie Benutzerinteraktionen verfolgen und Leistungsprobleme identifizieren. Sie können auf den Fehlerlink in der Spalte Fehler klicken, um das Wasserfalldiagramm nach dem spezifischen Fehlerereignis zu filtern. Jede Zeile im Wasserfall kann ausgewählt werden, um das Diagnosefenster zu öffnen, in dem Sie sich das Rohereignis ansehen können.

Bei HTTP-Anfragen wird eine TraceID für HTTP- und Xray-Ereignisse angezeigt, die mit der Traces-Konsole verknüpft ist, sofern Sie Tracing aktiviert haben. Für Ereignisse wie JS-Fehler oder HTTP-Fehlerereignisse enthält das Diagnosefeld eine Registerkarte „Ausnahme“ mit dem Stack-Trace. Die Schaltfläche „Ansicht“ im Wasserfall bietet schnellen Zugriff auf diese Informationen.

Die User Journey (Benutzer-Journey) zeigt die Pfade an, die Ihre Kunden verwenden, um in Ihrer Anwendung zu navigieren. Sie können sehen, auf welcher Seite Kunden in Ihrer Anwendung starten und auf welcher Seite sie die Anwendung wieder verlassen. Sie können auch die Pfade sehen, die sie einschlagen, und den Prozentsatz der Kunden, die diesen Pfaden folgen. Sie können auf einem Knoten pausieren, um weitere Details zu dieser Seite zu erhalten. Sie können einen einzelnen Pfad auswählen, um die Verbindungen zur einfacheren Anzeige hervorzuheben. Auf der Seite wird standardmäßig die Benutzerreise bis zur zweiten Interaktion angezeigt. Sie können auf die Schaltfläche Pfad hinzufügen klicken, um weitere Interaktionen anzuzeigen.

Auf dem Tab „ CloudWatchMetriken“ werden alle von Ihrem App Monitor veröffentlichten Standardmetriken angezeigt, einschließlich Web Vitals für Leistung, Fehler (JavaScript Fehler, HTTP errors/faults), Volumen, Benutzerfluss und Apdex-Metriken. Wenn Sie erweiterte Metriken für Ihre Anwendung erstellt haben, enthält der Tab auch eine Teilmenge dieser Metriken im Abschnitt „Erweiterte Metriken“. Diese Teilmenge umfasst Metriken des Typs PageViewCount, Http4xxCount PerformanceNavigationDuration, Http5xxCount und. JsErrorCount Das Dashboard zeigt drei Metrikvariationen pro Metriktyp. Da es sich um CloudWatch Metriken handelt, können Sie diese Registerkarte auch mithilfe der Option Zum Dashboard hinzufügen in Ihr eigenes Dashboard exportieren und aktualisieren, um weitere Metriken einzubeziehen.

Die Registerkarte „Leistung“ bietet Einblicke in die Leistung Ihrer mobilen Anwendung, einschließlich der Ladezeiten auf dem Bildschirm, der Startzeiten der App (kalt und warm), Leistungskennzahlen und Apdex-Werte im Zeitverlauf. In der Detailansicht wird die Leistung nach Bildschirmnamen, Betriebssystemversionen, App-Versionen, Geräten und Ländern aufgeschlüsselt. Wenn Sie im Diagramm auf eine Bildschirmladezeit, eine App-Startzeit oder einen Standortdatenpunkt klicken, wird das Diagnosefeld auf der rechten Seite geöffnet, das weitere Informationen zu dem Datenpunkt enthält, der die letzten korrelierten Sitzungen umfasst, und Links zum Tab Sitzungen zur Problembehandlung enthält.

Auf dieser Registerkarte können Sie auch zwischen Bildschirmladungen, App-Starts und Standort umschalten, um weitere Details zur Anwendungsleistung zu sehen.

Auf der Registerkarte wird auch der Wert des Anwendungsleistungsindex (Apdex) angezeigt, der den Grad der Zufriedenheit der Endbenutzer angibt. Die Punktzahl reicht von 0 (am wenigsten zufrieden) bis 1 (am zufriedensten). Die Ergebnisse basieren nur auf der Anwendungsleistung. Weitere Informationen über Apdex-Ergebnisse finden Sie unter Wie RUM CloudWatch die Apdex-Werte festlegt.

Auf der Registerkarte „Fehler“ werden Anwendungsprobleme in drei Kategorien unterteilt: Netzwerkfehler, Abstürze und ANRs (Android) /App hängt (iOS). Die Registerkarte „Netzwerkfehler“ enthält ein Liniendiagramm, das die Netzwerklatenz, Client-Fehler (4xx-Statuscode) und Serverfehler (5xx-Statuscode) zeigt. Wenn Sie für eine dieser Linien im Diagramm auf einen Datenpunkt klicken, wird das Diagnosefeld geöffnet. In der unteren Tabelle sind die 100 gängigsten Netzwerkrouten aufgeführt. Wenn Sie auf ein Optionsfeld klicken, wird das Liniendiagramm nach der ausgewählten Netzwerkroute gefiltert.

In ähnlicher Weise wird auf den Registerkarten Abstürze und ANRs/App Hänge eine Reihe von Zeilen angezeigt, in denen die Anzahl der einzelnen Fehler angegeben wird. Diese Fehler können nicht behoben werden. In der unteren Tabelle werden die häufigsten Absturzmeldungen oder der ANR/App Hang Stack Trace angezeigt. Wenn Sie auf ein Optionsfeld klicken, wird das Diagramm gefiltert, und wenn Sie auf die Fehlermeldung klicken, wird der komplette Stack-Trace angezeigt.

Auf der Registerkarte „Sitzungen“ wird eine Tabelle angezeigt, in der alle Sitzungen in absteigender chronologischer Reihenfolge aufgeführt sind. Unten zeigt eine Wasserfallvisualisierung die gesamte Telemetrie für die ausgewählte Sitzung. So können Sie Benutzerinteraktionen verfolgen und Leistungsprobleme identifizieren. Jede Zeile im Wasserfall kann ausgewählt werden, um das Diagnosefeld zu öffnen. Bei HTTP-Anfragen wird eine TraceID angezeigt, die mit der Traces-Konsole verknüpft ist.

Bei HTTP-Anfragen mit Nicht-2xx-Statuscodes, Abstürzen oder ANRs (Android)/App Hangs (iOS) enthält das Diagnosefeld eine Registerkarte „Ausnahme“ mit dem Stack-Trace. Die Schaltfläche „Ansicht“ im Wasserfall bietet schnellen Zugriff auf diese Informationen.

Auf der Registerkarte „ CloudWatchMetriken“ werden alle von Ihrem App-Monitor veröffentlichten Standardmetriken angezeigt, darunter Leistungskennzahlen (Ladezeiten auf dem Bildschirm, kalte App-Startzeiten), Fehlermetriken (Abstürze, ANRs/App Hänge, HTTP errors/faults), Volumen- und Apdex-Metriken. Wenn Sie erweiterte Metriken für Ihre Anwendung erstellt haben, enthält der Tab auch eine Teilmenge dieser Metriken im Abschnitt „Erweiterte Metriken“. Diese Teilmenge umfasst Metriken des Typs ScreenLoadTime,, Http4xxCount ScreenLoadCount CrashCount, Http5xxCount und,. ANRCount/AppHangCount ColdLaunchTime WarmLaunchTime Das Dashboard zeigt drei Metrikvariationen pro Metriktyp. Da es sich um CloudWatch Metriken handelt, können Sie diese Registerkarte auch mithilfe der Option Zum Dashboard hinzufügen in Ihr eigenes Dashboard exportieren und aktualisieren, um weitere Metriken einzubeziehen.

Die Registerkarte „Konfiguration“ bietet Zugriff auf die allgemeinen Einstellungen und Konfigurationsdetails Ihres App-Monitors. Sie können auch auf die Registerkarte Codefragmente zugreifen, die Anweisungen zur Instrumentierung Ihrer mobilen Anwendung mit dem ADOT SDK enthält, einschließlich manueller und Instrumentierungsoptionen. Zero-Code

Zufrieden — Die tatsächliche Antwortzeit der Anwendung ist kleiner oder gleich dem Apdex-Schwellenwert. Für CloudWatch RUM liegt dieser Schwellenwert bei 2000 ms oder weniger.

Tolerierbar — Die tatsächliche Reaktionszeit der Anwendung ist größer als der Apdex-Schwellenwert, aber kleiner oder gleich dem Vierfachen des Apdex-Schwellenwerts. Für CloudWatch RUM liegt dieser Bereich zwischen 2000 und 8000 ms.

Frustrierend — Die tatsächliche Reaktionszeit der Anwendung ist größer als das Vierfache des Apdex-Schwellenwerts. Bei CloudWatch RUM liegt dieser Bereich bei über 8000 ms.