Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Den Betriebsstatus Ihrer Anwendungen mit Application Signals überwachen
Verwenden Sie Application Signals in der [CloudWatch Konsole](https://console.aws.amazon.com/cloudwatch/), um den Betriebsstatus Ihrer Anwendungen zu überwachen und Fehler zu beheben:
+ **Ihre Anwendungsservices überwachen** – Im Rahmen der täglichen Betriebsüberwachung finden Sie auf der Seite [Services](Services-page.md) eine Zusammenfassung all Ihrer Services. Sehen Sie sich die Dienste mit der höchsten Fehlerrate oder Latenz an und finden Sie heraus, welche Dienste fehlerhafte [Service-Level-Indikatoren aufweisen (SLIs)](CloudWatch-ServiceLevelObjectives.md). Wählen Sie einen Service aus, um die [Service-Detailseite](ServiceDetail.md) zu öffnen und detaillierte Metriken, Servicebetriebe, Synthetics-Canarys und KundenAnforderungen anzuzeigen. Auf diese Weise können Sie die Ursache betrieblicher Probleme ermitteln und beheben.
+ **Ihre Anwendungstopologie untersuchen** – Verwenden Sie die [Anwendungskarte](ServiceMap.md), um Ihre Anwendungstopologie im Laufe der Zeit zu verstehen und zu überwachen, einschließlich der Beziehungen zwischen Clients, Synthetics-Canarys, Services und Abhängigkeiten. Sehen Sie sich sofort den Status des Servicelevel-Indikators (SLI) an und lassen Sie sich wichtige Kennzahlen wie Aufrufvolumen, Störungsrate und Latenz anzeigen. Detailliertere Informationen finden Sie auf der Seite mit den [Servicedetails](ServiceDetail.md).
Sehen Sie sich ein [Beispielszenario](Services-example-scenario.md) an, das zeigt, wie diese Seiten zur schnellen Behebung eines Betriebszustands eines Services verwendet werden können, von der ersten Erkennung bis zur Identifizierung der Grundursache.
**Wie Application Signals die Überwachung des Betriebsstatus ermöglicht**
Nachdem Sie [Ihre Anwendung für Application Signals aktiviert](CloudWatch-Application-Signals-Enable.md) haben, werden Ihre Anwendungsdienste und deren Abhängigkeiten automatisch erkannt und auf den Seiten **Dienste**, **Dienstdetails** und **Anwendungsübersicht angezeigt**. APIs Application Signals sammelt Informationen aus verschiedenen Quellen, um die Serviceerkennung und die Überwachung des Betriebsstatus zu ermöglichen:
+ [AWS Distro for OpenTelemetry (ADOT)](CloudWatch-Application-Signals-supportmatrix.md) — Im Rahmen der Aktivierung von Application Signals werden OpenTelemetry Java- und Python-Bibliotheken für die automatische Instrumentierung so konfiguriert, dass sie Metriken und Traces ausgeben, die vom Agenten gesammelt werden. CloudWatch Die Metriken und Traces werden verwendet, um die Erkennung von Services, Vorgängen, Abhängigkeiten und anderen Serviceinformationen zu ermöglichen.
+ [Service-Level-Ziele (SLOs)](CloudWatch-ServiceLevelObjectives.md) — Nachdem Sie Service-Level-Ziele für Ihre Services erstellt haben, wird auf den Seiten Services, Servicedetails und Anwendungsübersicht der Status des Service Level Indicators (SLI) angezeigt. SLIs kann Latenz, Verfügbarkeit und andere Betriebskennzahlen überwachen.
+ [CloudWatch Synthetics Canaries](CloudWatch_Synthetics_Canaries.md) — Wenn Sie X-Ray Tracing auf Ihren Canaries konfigurieren, werden Aufrufe Ihrer Dienste von Ihren Canary-Skripten aus mit Ihrem Dienst verknüpft und auf der Service-Detailseite angezeigt.
+ [CloudWatch Real User Monitoring (RUM)](CloudWatch-RUM.md) — Wenn X-Ray Tracing auf Ihrem CloudWatch RUM-Webclient aktiviert ist, werden Anfragen an Ihre Dienste automatisch verknüpft und auf der Service-Detailseite angezeigt.
+ [AWS Service Catalog AppRegistry](https://docs.aws.amazon.com/servicecatalog/latest/arguide/intro-app-registry.html)— Application Signals erkennt automatisch AWS Ressourcen in Ihrem Konto und ermöglicht es Ihnen, sie in logischen Anwendungen zu gruppieren, die in erstellt wurden. AppRegistry Der auf der Services-Seite angezeigte Anwendungsname basiert auf der zugrunde liegenden Rechenressource, auf der Ihre Services ausgeführt werden.
**Anmerkung**
Application Signals zeigt Ihre Services und Operationen auf der Grundlage von Metriken und Traces an, die innerhalb des von Ihnen ausgewählten aktuellen Zeitfilters ausgegeben wurden. (Standardmäßig sind dies die letzten drei Stunden.) Wenn im aktuellen Zeitfilter für einen Services, einen Vorgang, eine Abhängigkeit, einen Synthetics-Canary oder eine Client-Seite keine Aktivität vorhanden ist, wird diese nicht angezeigt.
Bis zu 1 000 Services können angezeigt werden. Die Erkennung Ihrer Services und der Servicetopologie kann sich um bis zu 10 Minuten verzögern. Die Bewertung des Zustands Ihres Servicelevel-Indikators (SLI) kann sich um bis zu 15 Minuten verzögern.
**Anmerkung**
Die Application-Signals-Konsole unterstützt derzeit nur die Auswahl von maximal einem Tag innerhalb des Zeitraums von 30 Tagen.
# Allgemeine Serviceaktivität und den Betriebsstatus auf der Services-Seite anzeigen
Auf der Services-Seite finden Sie eine Liste Ihrer Services, die [für Application Signals aktiviert](CloudWatch-Application-Signals-Enable.md) sind. Sie können auch Betriebsmetriken einsehen und schnell erkennen, welche Dienste fehlerhafte Service-Level-Indikatoren aufweisen (SLIs). Gehen Sie ins Deital, um nach Leistungsanomalien zu suchen, und ermitteln Sie die Ursache betrieblicher Probleme. Um diese Seite aufzurufen, öffnen Sie die [CloudWatch Konsole](https://console.aws.amazon.com/cloudwatch/) und wählen Sie im linken Navigationsbereich im Bereich **Application Signals** die Option **Services** aus.
Bei Diensten ohne Instrumentierung werden auf der Seite mit der Serviceübersicht begrenzte Informationen angezeigt, die calls-to-action zur Instrumentierung von Application Signals hervorgehoben sind.
## Sich über Betriebsstatus-Metriken für Ihre Services informieren
Oben auf der Serviceseite finden Sie ein Diagramm zum allgemeinen Betriebszustand des Service und mehrere Tabellen, in denen die wichtigsten Services und Serviceabhängigkeiten nach Störungsrate sowie eine Liste der Services angezeigt werden. Das Diagramm „Dienste“ auf der linken Seite zeigt eine Aufschlüsselung der Anzahl der Dienste, die während des aktuellen Zeitfilters auf Seitenebene fehlerfreie oder fehlerhafte Service Level Indicators (SLIs) aufwiesen. SLIs kann Latenz, Verfügbarkeit und andere Betriebskennzahlen überwachen. Die wichtigsten Services nach Störungsrate sehen Sie in den beiden Tabellen neben dem Diagramm. Wählen Sie in einer der Tabellen einen Servicenamen aus, um die [Seite mit den Servicedetails](ServiceDetail.md) zu öffnen, die detaillierte Informationen zu den Serviceoperationen enthält. Wählen Sie einen Abhängigkeitspfad aus, um die Details zur Serviceabhängigkeit auf der zugehörigen Detailseite anzuzeigen.
In beiden Tabellen werden Informationen für die letzten drei Stunden angezeigt, auch wenn oben rechts auf der Seite ein Filter für längere Zeiträume ausgewählt wurde.
Bei Verwendung der dynamischen Servicegruppierung aggregieren die Betriebszustandsmetriken automatisch die Daten aller Services in jeder Gruppe. Das ermöglicht:
+ konsolidierte Störungsraten für Servicegruppen
+ SLI-Zustände auf Gruppenebene
+ aggregierte Leistungsmetriken, mit deren Hilfe problematische Servicecluster identifiziert werden können
+ schnelle Identifizierung von Gruppen, die bei Vorfällen sofortige Aufmerksamkeit erfordern
![\[CloudWatch Die wichtigsten Grafiken zu den Diensten\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/services-top-graphs.png)
## Den Betriebsstatus mit der Services-Tabelle überwachen
Auf der Services-Tabelle finden Sie eine Liste Ihrer Services, die für Application Signals aktiviert sind. Wählen Sie **Application Signals aktivieren**, um eine Einrichtungsseite zu öffnen und mit der Konfiguration Ihrer Services zu beginnen. Weitere Informationen finden Sie unter [Application Signals aktivieren](CloudWatch-Application-Signals-Enable.md).
Filtern Sie die Services-Tabelle, um die Suche zu erleichtern, indem Sie eine oder mehrere Eigenschaften aus dem Filter-Textfeld auswählen. Bei der Auswahl der einzelnen Eigenschaften werden Sie durch die Filterkriterien geführt. Sie sehen den vollständigen Filter unter dem Filter-Textfeld. Sie können jederzeit **Filter löschen** auswählen, um den Tabellenfilter zu entfernen.
Mit den erweiterten Filteroptionen können Sie:
+ nach Servicegruppen filtern (Standard- und benutzerdefinierte Gruppierungen).
+ nach aktuellen Bereitstellungsaktivitäten filtern.
+ Nach Plattform filtern
+ Nach SLI Health filtern
+ Nach Konto-ID filtern (in kontoübergreifenden Observability-Konfigurationen)
+ Nach Instrumentierungsstatus filtern (instrumentiert oder nicht instrumentiert)
+ nach Umgebung filtern.
+ nach Servicezustand filtern.
![\[CloudWatch Tabelle „Dienste“\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/services-table-healthy-updated.png)
Bei Diensten ohne Instrumentierung werden auf der Seite mit der Serviceübersicht nur begrenzte Informationen angezeigt, sodass die Instrumentierung calls-to-action durch Application Signals aktiviert wird. Dienste ohne Instrumentierung werden in der Services-Tabelle angezeigt, auch wenn sie nicht mit Application Signals konfiguriert wurden. So können Sie Lücken in Ihrer Observability-Abdeckung identifizieren und anhand ihrer Position in Ihrer Architektur priorisieren, welche Dienste als Nächstes instrumentiert werden müssen.
Wählen Sie den Namen eines beliebigen Services in der Tabelle aus, um eine [Service-Detailseite](ServiceDetail.md) mit Metriken, Vorgängen und zusätzlichen Details auf Service-Ebene anzuzeigen. [Wenn Sie die dem Service zugrunde liegende Rechenressource auf der AWS-Managementkonsole Startseite AppRegistry oder der Karte „Anwendungen“ einer Anwendung zugeordnet haben, wählen Sie den Namen der Anwendung, um die Anwendungsdetails auf der Konsolenseite „Meine Anwendungen“ anzuzeigen.](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/aws-myApplications.html) Wählen Sie für in Amazon EKS gehostete Services einen beliebigen Link in der Spalte **Gehostet in**, um Cluster, Namespace oder Workload in CloudWatch Container Insights anzuzeigen. Für Dienste, die auf Amazon ECS oder Amazon ausgeführt werden EC2, wird der Wert Environment angezeigt.
Der Status des [Servicelevel-Indikators (SLI)](CloudWatch-ServiceLevelObjectives.md#CloudWatch-ServiceLevelObjectives-concepts) wird für jeden Service in der Tabelle angezeigt. Wählen Sie den SLI-Status für einen Service aus, um ein Pop-up mit einem Link zu einem fehlerhaften SLIs Service und einen Link zur Anzeige aller Informationen SLOs für den Service anzuzeigen.
![\[Service mit fehlerhaftem SLI\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/services-unhealthy-sli.png)
Wenn für einen Dienst keine erstellt SLOs wurden, klicken Sie in der Spalte **SLI-Status auf die Schaltfläche „SLO** **erstellen**“. Um weitere Dienste SLOs für einen beliebigen Dienst zu erstellen, wählen Sie das Optionsfeld neben dem Dienstnamen aus und wählen Sie dann oben rechts in der Tabelle die Option **SLO erstellen** aus. Bei der Erstellung SLOs können Sie auf einen Blick sehen, welche Ihrer Dienste und Operationen gut funktionieren und welche nicht. Weitere Informationen finden Sie unter [Service Level Objectives (SLOs)](CloudWatch-ServiceLevelObjectives.md).
## Service-Übersicht
Nachdem Sie einen Service aus der Tabelle Services ausgewählt haben, wird die Seite mit der Serviceübersicht geöffnet. Diese Seite bietet einen umfassenden Überblick über den Betriebsstatus und die Leistungskennzahlen Ihres Dienstes. In der Übersicht werden diese zusammenfassenden Kennzahlen angezeigt:
+ Gesamte Operationen
+ Abhängigkeiten von Diensten
+ Status der Canary-Überwachung
+ RUM-Clientdaten
Diese Kennzahlen geben Ihnen einen sofortigen Einblick in den aktuellen Status Ihres Dienstes.
Mithilfe einer Reihe von Diagrammen können Sie wichtige betriebliche Leistungsindikatoren im Zeitverlauf visualisieren. Passen Sie den Zeitfilter an, um Trends zu analysieren und potenzielle Probleme zu identifizieren, die sich auf den Zustand Ihres Dienstes auswirken. Alle Diagramme werden automatisch aktualisiert, um die Daten für den ausgewählten Zeitraum wiederzugeben.
Im Abschnitt Prüfungsergebnisse werden kritische Probleme im Verhalten Ihres Dienstes automatisch erkannt und angezeigt, sodass Sie keine manuellen Untersuchungen durchführen müssen. Application Signals analysiert Ihre Anwendungen, um wichtige Beobachtungen und potenzielle Probleme zu melden und so die Ursachenanalyse zu vereinfachen. Diese automatisierten Ergebnisse konsolidieren die relevanten Spuren, sodass Sie nicht mehr mit mehreren Klicks navigieren müssen. Das Auditsystem hilft Teams dabei, Probleme und ihre zugrunde liegenden Ursachen schnell zu identifizieren und ermöglicht so eine schnellere Problemlösung.
Im Abschnitt Änderungsereignisse können Sie ermitteln, wie sich aktuelle Bereitstellungen oder Konfigurationsänderungen auf Ihr Serviceverhalten auswirken. Application Signals verarbeitet CloudTrail Ereignisse automatisch, um Änderungsereignisse in Ihrer gesamten Anwendung nachzuverfolgen. Überwachen Sie die Konfigurations- und Bereitstellungsereignisse für Dienste und deren Abhängigkeiten und bieten Sie so unmittelbaren Kontext für Betriebsanalysen und Problembehebungen. Application Signals korreliert Bereitstellungszeiten automatisch mit Leistungsänderungen, sodass Sie schnell erkennen können, ob kürzliche Bereitstellungen zu Serviceproblemen beigetragen haben.
![\[Service-Übersicht\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/Service_detail.png)
# Anzeigen detaillierter Serviceaktivitäten und des Betriebsstatus auf der Servicedetailseite
Wenn Sie Ihre Anwendung instrumentieren, ordnet [Amazon CloudWatch Application Signals](CloudWatch-Application-Monitoring-Sections.md) alle Dienste zu, die Ihre Anwendung erkennt. Auf der Servicedetailseite erhalten Sie einen Überblick über Ihre Services, Operationen, Abhängigkeiten, Canarys und Client-Anforderungen für einen einzelnen Service. Gehen Sie wie folgt vor, um Servicedetailseite aufzurufen:
+ Öffnen Sie die [CloudWatch -Konsole](https://console.aws.amazon.com/cloudwatch/).
+ Wählen Sie im linken Navigationsbereich im Abschnitt **Application Signals** die Option **Services** aus.
+ Wählen Sie den Namen eines beliebigen Service aus den Tabellen **Services**, **Top-Services** oder „Abhängigkeiten“ aus.
Unter **schedule-visits** sehen Sie das Kontolabel und die ID unter dem Namen des Service.
Die Servicedetailseite ist in vier Registerkarten unterteilt:
+ [Überblick](#ServiceDetail-overview): Auf dieser Registerkarte sehen Sie einen einzelnen Service, einschließlich der Anzahl der Operationen, Abhängigkeiten, Synthetics und Client-Seiten. Auf der Registerkarte werden die wichtigsten Metriken für Ihren gesamten Service, die wichtigsten Operationen und Abhängigkeiten angezeigt. Zu diesen Metriken gehören Zeitreihendaten zu Latenz, Störungen und Fehlern bei allen Serviceoperationen für diesen Service.
+ [Serviceoperationen](#ServiceDetail-operations): Auf dieser Registerkarte sehen Sie eine Liste der von Ihrem Service aufgerufenen Operationen und interaktive Diagramme mit wichtigen Metriken zur Messung des Zustands der einzelnen Operationen. Sie können einen Datenpunkt in einem Diagramm auswählen, um Informationen zu Ablaufverfolgungen, Protokollen oder Metriken abzurufen, die mit diesem Datenpunkt verknüpft sind.
+ [Abhängigkeiten](#ServiceDetail-dependencies): Auf dieser Registerkarte sehen Sie eine Liste der von Ihrem Service aufgerufenen Abhängigkeiten sowie eine Liste von Metriken für diese Abhängigkeiten.
+ [Synthetics-Canarys](#ServiceDetail-canaries): Auf dieser Registerkarte finden Sie eine Liste von Synthetics-Canarys, die Benutzeraufrufe an Ihren Service simulieren, sowie wichtige Leistungsmetriken für diese Canarys.
+ [Client-Seiten](#ServiceDetail-clientpages): Auf dieser Registerkarte finden Sie eine Liste von Client-Seiten, die Ihren Service aufrufen, sowie Metriken zur Messung der Qualität der Client-Interaktionen mit Ihrer Anwendung.
+ [Zugehörige Metriken](#ServiceDetail-relatedmetrics): Auf dieser Registerkarte können Sie zugehörige Metriken korrelieren, z. B. Standardmetriken, Laufzeitmetriken und benutzerdefinierte Metriken für einen Service, seine Operationen oder Abhängigkeiten.
## Aufrufen Ihrer Serviceübersicht
Auf der Seite mit der Serviceübersicht können Sie sich eine allgemeine Zusammenfassung der Metriken für alle Serviceoperationen an einem einzigen Standort ansehen. Überprüfen Sie die Leistung aller Operationen, Abhängigkeiten, Client-Seiten und Synthetics-Canarys, die mit Ihrer Anwendung interagieren. Anhand dieser Informationen können Sie ermitteln, worauf Sie sich konzentrieren sollten, um Probleme zu identifizieren, Fehler zu beheben und Optimierungsmöglichkeiten zu finden.
Wählen Sie unter **Servicedetails** einen Link aus, um Informationen zu einem bestimmten Service anzuzeigen. Für Services, die in Amazon EKS gehostet werden, sehen Sie auf der Seite mit den Servicedetails beispielsweise Informationen zu **Cluster**, **Namespace** und **Workload**. Für Services, die in Amazon ECS oder Amazon EC2 gehostet werden, wird auf der Seite mit den Servicedetails der Wert **Umgebung** angezeigt.
Unter **Services** auf der Registerkarte **Überblick** wird eine Zusammenfassung der folgenden Informationen angezeigt:
+ Operationen: Auf dieser Registerkarte können Sie den Zustand Ihrer Serviceoperationen einsehen. Der Zustand wird durch Service Level Indicators (SLIs) bestimmt, die als Teil eines [Service Level Objective](CloudWatch-ServiceLevelObjectives.md) (SLO) definiert sind.
+ Abhängigkeiten: Auf dieser Registerkarte finden Sie die wichtigsten Abhängigkeiten der von Ihrer Anwendung aufgerufenen Services, aufgelistet nach Fehlerrate, sowie den Zustand Ihrer Serviceabhängigkeiten. Der Zustand wird durch Service Level Indicators (SLIs) bestimmt, die als Teil eines Service Level Objective (SLO) definiert sind.
+ Synthetics Canaries — Verwenden Sie diese Registerkarte, um das Ergebnis simulierter Aufrufe an Endpunkte oder im APIs Zusammenhang mit Ihrem Service sowie die Anzahl der fehlgeschlagenen Canaries anzuzeigen.
+ Client-Seiten — Verwenden Sie diese Registerkarte, um die wichtigsten Seiten zu sehen, die von Clients aufgerufen wurden, bei denen asynchrone Fehler und XML- (AJAX JavaScript -) Fehler aufgetreten sind.
Die folgende Abbildung zeigt einen Überblick über Ihre Services:
![\[Serviceüberblick-Widgets\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/service-detail-widgets.png)
Auf der Registerkarte **Überblick** wird außerdem ein Diagramm der Abhängigkeiten mit der höchsten Latenz für alle Services angezeigt. Verwenden Sie die Latenzmetriken **p99**, **p90** und **p50**, um schnell zu bewerten, welche Abhängigkeiten zur gesamten Servicelatenz beitragen:
![\[Diagramm zur Latenz von Serviceoperationen\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/service-detail-latency.png)
Das obige Diagramm zeigt beispielsweise, dass 99 % der Anforderungen, die an die Abhängigkeit **customer-service** gesendet wurden, in etwa 4.950 Millisekunden abgeschlossen wurden. Die anderen Abhängigkeiten nahmen weniger Zeit in Anspruch.
Diagramme, die die vier Top-Serviceoperationen nach Latenz darstellen, zeigen das Volumen der Anforderungen, die Verfügbarkeit, die Störungsrate und die Fehlerquote für diese Services, wie im folgenden Bild zu sehen ist:
![\[Diagramme zu Volumen, Verfügbarkeit, Störungsrate und Fehlerrate von Serviceoperationen\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/service-detail-operations-graphs.png)
Im Abschnitt **Servicedetails** werden die Details des Service angezeigt, einschließlich **Konto-ID** und **Kontolabel**.
## Ihre Service-Vorgänge anzeigen
Wenn Sie Ihre Anwendung instrumentieren, erkennt [Application Signals](CloudWatch-Application-Monitoring-Sections.md) alle Serviceoperationen, die Ihre Anwendung aufruft. Auf der Registerkarte **Serviceoperationen** sehen Sie eine Tabelle mit Serviceoperationen und Metriken, mit denen die Leistung einer ausgewählten Operation gemessen wird. Zu diesen Metriken gehören der SLI-Status, die Anzahl der Abhängigkeiten, Latenz, Volumen, Störungen, Fehler und Verfügbarkeit, wie im folgenden Bild zu sehen ist:
![\[Tabelle mit Service-Vorgängen\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/service-operations-table.png)
Filtern Sie die Tabelle, um die Suche nach einer Serviceoperation zu erleichtern. Wählen Sie dazu eine oder mehrere Eigenschaften aus dem Filter-Textfeld aus. Bei der Auswahl der einzelnen Eigenschaften werden Sie durch die Filter-Kriterien geführt und der vollständige Filter wird unter dem Filter-Textfeld angezeigt. Sie können jederzeit **Filter löschen** auswählen, um den Tabellenfilter zu entfernen.
Wählen Sie den SLI-Status für einen Vorgang, um ein Popup anzuzeigen, das einen Link zu fehlerhaften SLI und einen Link zur Anzeige aller SLOs Informationen zu dem Vorgang enthält, wie in der folgenden Tabelle dargestellt:
![\[Serviceoperation-SLI-Status\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/service-operation-unhealthy-slo.png)
In der Tabelle mit den Servicevorgängen werden der SLI-Status, die Anzahl der fehlerfreien oder SLIs fehlerhaften Vorgänge und die Gesamtzahl der SLOs Operationen aufgeführt.
Wird verwendet, SLIs um Latenz, Verfügbarkeit und andere Betriebskennzahlen zu überwachen, die den Betriebsstatus eines Dienstes messen. Mit einem SLO können Sie die Leistung und den Zustand Ihrer Services und Operationen prüfen.
Gehen Sie wie folgt vor, um ein SLO zu erstellen:
+ Wenn für eine Operation keine SLOs erstellt wurden, wählen Sie in der Spalte **SLI-Status** die Schaltfläche **SLO erstellen** aus.
+ Wenn für eine Operation bereits ein SLO vorhanden ist, gehen Sie wie folgt vor:
+ Wählen Sie das Optionsfeld neben dem Namen der Operation aus.
+ Wählen Sie über den Abwärtspfeil **Aktionen** oben rechts in der Tabelle die Option **SLO erstellen** aus.
Weitere Informationen finden Sie unter [Service-Level-Ziele (SLOs)](CloudWatch-ServiceLevelObjectives.md).
In der Spalte **Abhängigkeiten** wird die Anzahl der Abhängigkeiten angezeigt, die dieser Vorgang aufruft. Wählen Sie diese Zahl, um die Registerkarte **Abhängigkeiten** zu öffnen, die nach dem ausgewählten Vorgang gefiltert ist.
### Anzeigen von Metriken zu Serviceoperationen, korrelierten Ablaufverfolgungen und Anwendungsprotokollen
Application Signals korreliert Servicebetriebsmetriken mit AWS X-Ray Traces, CloudWatch [Container Insights](ContainerInsights.md) und Anwendungsprotokollen. Verwenden Sie diese Metriken, um Probleme mit dem Betriebszustand zu beheben. Gehen Sie wie folgt vor, um Metriken als grafische Informationen anzuzeigen:
1. Wählen Sie in der Tabelle **Serviceoperationen** eine Serviceoperation aus, um oberhalb der Tabelle eine Reihe von Diagrammen für die ausgewählte Operation anzuzeigen, mit Metriken für **Volumen und Verfügbarkeit**, **Latenz** sowie **Störungen und Fehler**.
1. Bewegen Sie den Mauszeiger auf einen Punkt in einem Diagramm, um weitere Informationen zu sehen.
1. Wählen Sie einen Punkt aus, um einen Diagnosebereich zu öffnen, in dem korrelierte Ablaufverfolgungen, Metriken und Anwendungsprotokolle für den ausgewählten Punkt im Diagramm angezeigt werden.
Das folgende Bild zeigt den Tooltip, der eingeblendet wird, wenn Sie den Mauszeiger auf einen Punkt im Diagramm bewegen, und den Diagnosebereich, der angezeigt wird, wenn Sie auf einen Punkt klicken. Der Tooltip enthält Informationen zum zugehörigen Datenpunkt im Diagramm **Störungen und Fehler**. Der Bereich enthält **korrelierte Ablaufverfolgungen**, **wichtigste Faktoren** und **Anwendungsprotokolle** zum ausgewählten Punkt.
![\[Korrelierte Ablaufverfolgungen für Störungen und Fehler\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/service-detail-correlated-traces.png)
#### Korrelierte Ablaufverfolgungen
Zugehörige Ablaufverfolgungen ansehen, um das zugrunde liegende Problem mit einer Ablaufverfolgung zu ermitteln. Sie können überprüfen, ob sich korrelierte Ablaufverfolgungen oder damit zusammenhängende Serviceknoten ähnlich verhalten. Um korrelierte Ablaufverfolgungen zu untersuchen, wählen Sie eine **Ablaufverfolgungs-ID** aus der Tabelle **Korrelierte Ablaufverfolgungen** aus, um die Seite [Details zu X-Ray-Ablaufverfolgung](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-traces.html) für die gewählten Ablaufverfolgung zu öffnen. Die Seite mit den Ablaufverfolgungsdetails enthält eine Übersicht der Serviceknoten, die der ausgewählten Ablaufverfolgung zugeordnet sind, sowie eine Zeitleiste mit Ablaufverfolgungssegmenten.
#### Wichtigste Faktoren
Wichtigste Faktoren ansehen, um die Haupt-Eingabequellen für eine Metrik zu finden. Gruppieren Sie die Faktoren nach verschiedenen Komponenten, um nach Ähnlichkeiten innerhalb der Gruppe zu suchen und zu verstehen, wie sich das Ablaufverfolgungsverhalten zwischen den Faktoren unterscheidet.
Auf der Registerkarte **Wichtigste Faktoren** finden Sie Metriken für **Aufrufvolumen**, **Verfügbarkeit**, **durchschnittliche Latenz**, **Fehler** und **Störungen** für jede Gruppe. Das folgende Beispielbild zeigt die wichtigsten Faktoren für eine Reihe von Metriken für eine Anwendung, die auf einer Amazon-EKS-Plattform bereitgestellt wurde:
![\[Wichtigste Faktoren zu Serviceoperationen\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/service-operations-top-contributors.png)
Die wichtigsten Faktoren enthalten die folgenden Metriken:
+ **Aufrufvolumen**: Anhand des Aufrufvolumens können Sie die Anzahl der Anforderungen pro Zeitintervall für eine Gruppe ermitteln.
+ **Verfügbarkeit**: Mithilfe der Verfügbarkeit können Sie sehen, wie lange (in Prozent) für eine Gruppe keine Störungen festgestellt wurden.
+ **Durchschnittliche Latenz**: Anhand der Latenz können Sie die durchschnittliche Dauer ausgeführter Anforderungen für eine Gruppe in einem Zeitintervall überprüfen, das davon abhängt, wie lange es her ist, dass die untersuchten Anforderungen gestellt wurden. Anforderungen, die vor weniger als 15 Tagen gestellt wurden, werden in Intervallen von 1 Minute ausgewertet. Anforderungen, die vor 15 bis 30 Tagen gestellt wurden, werden in Intervallen von 5 Minuten ausgewertet. Wenn Sie beispielsweise Anforderungen untersuchen, die vor 15 Tagen eine Störung verursacht haben, entspricht die Metrik für das Aufrufvolumen der Anzahl der Anforderungen pro 5-Minuten-Intervall.
+ **Fehler**: Die Anzahl der Fehler pro Gruppe, die über ein Zeitintervall gemessen wurden.
+ **Störungen**: Die Anzahl der Störungen pro Gruppe über ein Zeitintervall.
**Wichtigste Faktoren mit Amazon EKS oder Kubernetes**
Verwenden Sie Informationen über die wichtigsten Mitwirkenden für Anwendungen, die auf Amazon EKS bereitgestellt werdenKubernetes, oder um nach **Knoten, **Pod** und Knoten** gruppierte Betriebszustandsmetriken anzuzeigen **PodTemplateHash**. Es gelten folgende Definitionen:
+ Ein **Pod** ist eine Gruppe von einem oder mehreren Docker-Containern, die sich Speicher und Ressourcen teilen. Ein Pod ist die kleinste Einheit, die auf einer Kubernetes-Plattform bereitgestellt werden kann. Gruppieren Sie nach Pods, um zu überprüfen, ob Fehler mit Pod-spezifischen Einschränkungen zusammenhängen.
+ Ein **Knoten** ist ein Server, auf dem Pods ausgeführt werden. Gruppieren Sie nach Knoten, um zu überprüfen, ob Fehler mit knotenspezifischen Einschränkungen zusammenhängen.
+ Ein **Pod-Template-Hash** wird verwendet, um eine bestimmte Version einer Bereitstellung zu finden. Gruppieren Sie nach Pod-Template-Hash, um zu überprüfen, ob Fehler mit einer bestimmten Bereitstellung zusammenhängen.
**Wichtigste Faktoren mit Amazon EC2**
Verwenden Sie Informationen zu den wichtigsten Faktoren für Anwendungen, die in Amazon EKS bereitgestellt sind, um nach Instance-ID und Auto-Scaling-Gruppe gruppierte Betriebszustandsmetriken anzuzeigen. Es gelten folgende Definitionen:
+ Eine **Instance-ID** ist eine eindeutige ID für die Amazon-EC2-Instance, die Ihr Service ausführt. Gruppieren Sie nach Instance-ID, um zu überprüfen, ob Fehler mit einer bestimmten Amazon-EC2-Instance zusammenhängen.
+ Eine [Auto-Scaling-Gruppe](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html) ist eine Sammlung von Amazon-EC2-Instances, mit denen Sie die Ressourcen, die Sie für die Bearbeitung Ihrer AnwendungsAnforderungen benötigen, hoch- oder herunterskalieren können. Gruppieren Sie nach Auto-Scaling-Gruppe, wenn Sie überprüfen möchten, ob Fehler auf die Instances innerhalb der Gruppe beschränkt sind.
**Wichtigste Faktoren mit einer benutzerdefinierten Plattform**
Verwenden Sie Informationen zu den wichtigsten Faktoren für Anwendungen, die mit benutzerdefinierter Instrumentierung bereitgestellt sind, um nach **Hostname** gruppierte Betriebszustandsmetriken anzuzeigen. Es gelten folgende Definitionen:
+ Ein Hostname identifiziert ein Gerät, z. B. einen Endpunkt oder eine Amazon-EC2-Instance, die mit einem Netzwerk verbunden ist. Gruppieren Sie nach Hostnamen, um zu überprüfen, ob Fehler mit einem bestimmten physischen oder virtuellen Gerät zusammenhängen.
**Wichtigste Faktoren in Log Insights und Container Insights ansehen**
In [Log Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) können Sie die automatische Abfrage, die Metriken für Ihre wichtigsten Faktoren generiert hat, anzeigen und bearbeiten. In [Container Insights](ContainerInsights.md) können Sie Metriken zur Infrastrukturleistung nach Gruppen wie Pods oder Knoten anzeigen. Sie können Cluster, Knoten oder Workloads nach Ressourcenverbrauch sortieren. Dadurch können Anomalien schnell identifiziert und Risiken proaktiv gemindert werden, bevor das Benutzererlebnis beeinträchtigt wird. In diesem Bild sehen Sie, wie Sie diese Optionen auswählen können:
![\[Tabelle „Wichtigste Faktoren“\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/service-operations-top-contributors-insights.png)
In **Container Insights** können Sie Metriken für Ihren Amazon-EKS- oder Amazon-ECS-Container einsehen, die spezifisch für die Gruppierung Ihrer wichtigsten Faktoren sind. Wenn Sie für einen EKS-Container beispielsweise nach Pod gruppiert haben, um die wichtigsten Faktoren zu generieren, zeigt Container Insights für Ihren Pod gefilterte Metriken und Statistiken an.
In **Log Insights** können Sie die Abfrage, die die Metriken generiert hat, unter **Wichtigste Faktoren** wie folgt ändern:
1. Wählen Sie **In Log Insights anzeigen** aus. Die **Logs Insights-Seite**, die geöffnet wird, enthält eine automatisch generierte Abfrage, die die folgenden Informationen enthält:
+ den Namen der Protokoll-Cluster-Gruppe
+ Die Operation, mit der Sie die Untersuchung durchgeführt haben CloudWatch.
+ die Zusammenfassung der Betriebszustandsmetrik, mit der im Diagramm interagiert wurde
Die Protokollergebnisse werden automatisch gefiltert, um die Daten der letzten fünf Minuten anzuzeigen, bevor Sie den Datenpunkt im Servicediagramm auswählen.
1. Zum Bearbeiten der Abfrage ersetzen Sie den generierten Text durch Ihre Änderungen. Mit dem **Abfragegenerator** können Sie auch eine neue Abfrage generieren oder die bestehende Abfrage aktualisieren.
#### Anwendungsprotokolle
Verwenden Sie die Abfrage auf der Registerkarte **Anwendungsprotokolle**, um protokollierte Informationen für Ihre aktuelle Protokollgruppe und Ihren aktuellen Service zu generieren und einen Zeitstempel einzufügen. Eine Protokollgruppe ist eine Gruppe von Protokollstreams, die Sie beim Konfigurieren Ihrer Anwendung definieren können.
Mit einer Protokollgruppe können Sie Protokolle mit ähnlichen Merkmalen organisieren, zum Beispiel folgende:
+ Protokolle von einer bestimmten Organisation, Quelle oder Funktion
+ Protokolle, die von einem bestimmten Benutzer aufgerufen werden
+ Protokolle für einen bestimmten Zeitraum
Verwenden Sie diese Protokollstreams, um bestimmte Gruppen oder Zeitrahmen im Blick zu behalten. Sie können auch Überwachungsregeln, Alarme und Benachrichtigungen für diese Protokollgruppen einrichten. Informationen zu Protokollgruppen finden Sie unter [Arbeiten mit Protokollgruppen und Protokollstreams](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html).
Die Abfrage der Anwendungsprotokolle gibt die Protokolle, die wiederkehrenden Textmuster und die grafischen Visualisierungen Ihrer Protokollgruppen zurück.
Um die Abfrage auszuführen, wählen Sie **Abfrage in Logs Insights ausführen** aus, um die automatisch generierte Abfrage auszuführen oder die Abfrage zu ändern. Zum Bearbeiten der Abfrage ersetzen Sie den automatisch generierten Text durch Ihre Änderungen. Mit dem **Abfragegenerator** können Sie auch eine neue Abfrage generieren oder die bestehende Abfrage aktualisieren.
Das folgende Bild zeigt die Beispielabfrage, die auf der Grundlage des ausgewählten Punkts im Servicebetriebsdiagramm automatisch generiert wird:
![\[Tabelle „Anwendungsprotokolle“\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/service-operations-application-logs.png)
In der vorherigen Abbildung CloudWatch hat die Protokollgruppe, die dem ausgewählten Punkt zugeordnet ist, automatisch erkannt und in eine generierte Abfrage aufgenommen.
## Ihre Service-Abhängigkeiten anzeigen
Wählen Sie die Registerkarte **Abhängigkeiten**, um die **Abhängigkeiten**-Tabelle und eine Reihe von Metriken für die Abhängigkeiten aller Service-Vorgänge oder eines einzelnen Vorgangs anzuzeigen. Die Tabelle enthält eine Liste der Abhängigkeiten, die von Application Signals erkannt wurden, einschließlich Metriken für SLI-Status, Latenz, Aufrufvolumen, Störungsrate, Fehlerrate und Verfügbarkeit.
Wählen Sie oben auf der Seite einen Vorgang aus der Dropdown-Liste aus, um die zugehörigen Abhängigkeiten anzuzeigen, oder wählen Sie **Alle** aus, um die Abhängigkeiten für alle Operationen anzuzeigen.
Filtern Sie die Tabelle, um die Suche nach dem, was Sie suchen, zu erleichtern, indem Sie eine oder mehrere Eigenschaften aus dem Filter-Textfeld auswählen. Bei der Auswahl der einzelnen Eigenschaften werden Sie durch die Filter-Kriterien geführt und der vollständige Filter wird unter dem Filter-Textfeld angezeigt. Sie können jederzeit **Filter löschen** auswählen, um den Tabellenfilter zu entfernen. Wählen Sie oben rechts in der Tabelle die Option **Nach Abhängigkeit gruppieren** aus, um Abhängigkeiten nach Service- und Vorgangsnamen zu gruppieren. Wenn die Gruppierung aktiviert ist, können Sie eine Gruppe von Abhängigkeiten mit dem **\$1**-Symbol neben dem Namen der Abhängigkeit erweitern oder reduzieren.
![\[Tabelle mit Abhängigkeiten\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/service-dependencies-table.png)
In der Spalte **Abhängigkeit** wird der Name des Abhängigkeits-Services angezeigt, während in der Spalte **Remote-Vorgang** der Name der Serviceoperation angezeigt wird. In der **SLI-Statusspalte** wird die Anzahl der fehlerfreien oder fehlerhaften SLIs Dateien zusammen mit der Gesamtzahl der Fehler SLIs für jede Abhängigkeit angezeigt. Beim Aufrufen von AWS Diensten wird in der Spalte **Ziel** die AWS Ressource angezeigt, z. B. die DynamoDB-Tabelle oder die Amazon SNS SNS-Warteschlange.
Um eine Abhängigkeit auszuwählen, wählen Sie in der Tabelle **Abhängigkeiten** die Option neben einer Abhängigkeit aus. Dadurch werden Diagramme angezeigt, die detaillierte Metriken für Aufrufvolumen, Verfügbarkeit, Störungen und Fehler darstellen. Bewegen Sie den Mauszeiger auf einen Punkt in einem Diagramm, um ein Popup mit weiteren Informationen zu öffnen. Wählen Sie einen Punkt in einem Diagramm aus, um einen Diagnosebereich zu öffnen, in dem korrelierte Ablaufverfolgungen für den ausgewählten Punkt im Diagramm angezeigt werden. Wählen Sie eine Ablaufverfolgungs-ID aus der Tabelle **Korrelierte Ablaufverfolgungen** aus, um die Seite [Details zu X-Ray-Ablaufverfolgung](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-traces.html) für die gewählten Ablaufverfolgung zu öffnen.
![\[Abhängigkeitsdiagramme und korrelierte Traces\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/service-dependency-graph-traces.jpg)
## Ihre Synthetics-Canarys anzeigen
Wählen Sie die Registerkarte **Synthetics-Canarys**, um die **Synthetics-Canarys**-Tabelle und eine Reihe von Metriken für jeden Canary in der Tabelle anzuzeigen. Die Tabelle enthält Metriken für den prozentualen Erfolg, die durchschnittliche Dauer, die Ausführungen und die Ausfallrate. Es werden nur Kanarienvögel angezeigt, [für AWS X-Ray die die Ablaufverfolgung aktiviert ist](CloudWatch_Synthetics_Canaries_tracing.md).
Mit dem Filtertextfeld in der Synthetics-Canarys-Tabelle können Sie nach relevanten Canarys suchen. Jeder Filter, den Sie erstellen, wird unter dem Filtertextfeld angezeigt. Sie können jederzeit **Filter löschen** auswählen, um den Tabellenfilter zu entfernen.
![\[Synthetics-Canarys-Tabelle\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/service-canaries-table.png)
Wählen Sie das Optionsfeld neben dem Namen des Canarys aus, um eine Reihe von Registerkarten mit Diagrammen und detaillierten Metriken wie Erfolgsquote, Fehlern und Dauer anzuzeigen. Bewegen Sie den Mauszeiger auf einen Punkt in einem Diagramm, um ein Popup mit weiteren Informationen zu öffnen. Wählen Sie einen Punkt in einem Diagramm aus, um einen Diagnosebereich zu öffnen, in dem korrelierte Canary-Ausführungen für den ausgewählten Punkt angezeigt werden. Wählen Sie eine Canary-Ausführung und dann die **Laufzeit** aus, um Artefakte für die ausgewählte Canary-Ausführung zu sehen, einschließlich Protokollen, HTTP-Archivdateien (HAR), Screenshots und empfohlene Schritte zur Problembehebung. **Wähle **Mehr erfahren**, um die Seite [CloudWatch Synthetics Canaries neben Canary Runs](CloudWatch_Synthetics_Canaries.md) zu öffnen.**
![\[Synthetics-Canary-Diagramme und -Ausführungen\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/service-canary-graphs-runs.jpg)
## Ihre Kundenseiten anzeigen
Wählen Sie die Registerkarte **Client-Seiten** aus, um eine Liste von Client-Webseiten anzuzeigen, die Ihren Service aufrufen. Verwenden Sie die Metriken für die ausgewählte Client-Seite, um die Qualität der Kundenerfahrung bei der Interaktion mit einem Service oder einer Anwendung zu messen. Zu diesen Metriken gehören Seitenladevorgänge, Webdaten und Fehler.
Um Ihre Kundenseiten in der Tabelle anzuzeigen, müssen Sie [Ihren CloudWatch RUM-Webclient für X-Ray Tracing konfigurieren](CloudWatch-RUM-get-started-create-app-monitor.md) und Application Signals-Metriken für Ihre Kundenseiten aktivieren. Wählen Sie **Seiten verwalten** aus, um zu verwalten, welche Seiten für Metriken von Application Signals aktiviert sind.
Verwenden Sie das Filtertextfeld, um darunter die gewünschte Client-Seite oder den gewünschten Anwendungsmonitor zu finden. Sie können **Filter löschen** auswählen, um den Tabellenfilter zu entfernen. Wählen Sie **Nach Clients gruppieren**, um Client-Seiten nach Clients zu gruppieren. Wenn Sie gruppiert sind, klicken Sie auf das **\$1**-Symbol neben einem Client-Namen, um die Zeile zu erweitern und alle Seiten für diesen Client anzuzeigen.
![\[Tabelle mit den Client-Seiten\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/service-client-pages-table.png)
Um eine Client-Seite auszuwählen, wählen Sie in der **Client-Seiten**-Tabelle die Option neben einer Client-Seite aus. Sie werden eine Reihe von Diagrammen sehen, die detaillierte Metriken anzeigen. Bewegen Sie den Mauszeiger auf einen Punkt in einem Diagramm, um ein Popup mit weiteren Informationen zu öffnen. Wählen Sie einen Punkt in einem Diagramm aus, um einen Diagnosebereich zu öffnen, in dem korrelierte Leistungsnavigationsereignisse für den ausgewählten Punkt im Diagramm angezeigt werden. Wählen Sie eine Event-ID aus der Liste der Navigationsereignisse aus, [CloudWatch um die RUM-Seitenansicht](CloudWatch-RUM-view-data.md) für das gewählte Ereignis zu öffnen.
![\[CloudWatch Anfragen an RUM-Clientseiten\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/service-client-page-graphs-events.jpg)
**Anmerkung**
Um AJAX-Fehler auf Ihren Kundenseiten zu sehen, verwenden Sie den [CloudWatch RUM-Webclient](CloudWatch-RUM-configure-client.md) Version 1.15 oder neuer.
Pro Service können bis zu 100 Operationen, Canarys und Client-Seiten sowie bis zu 250 Abhängigkeiten angezeigt werden.
## Zugehörige Metriken anzeigen
Verwenden Sie die Registerkarte „Zugehörige Metriken“, um mehrere Metriken zu visualisieren, Korrelationsmuster zu identifizieren und die Hauptursachen von Problemen zu ermitteln.
Die Metriktabelle enthält drei Arten von Metriken:
+ Standardmetriken: Application Signals erfasst Standard-Anwendungsmetriken von Services, die es entdeckt. Weitere Informationen finden Sie unter [Erfasste Standard-Anwendungsmetriken](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AppSignals-MetricsCollected.html#AppSignals-StandardMetrics).
+ Laufzeitmetriken — Application Signals verwendet das AWS Distro for OpenTelemetry SDK, um automatisch OpenTelemetry kompatible Metriken aus Ihren Java- und Python-Anwendungen zu sammeln. Weitere Informationen finden Sie unter [Laufzeitmetriken](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AppSignals-MetricsCollected.html#AppSignals-RuntimeMetrics).
+ Benutzerdefinierte Metriken: Application Signals ermöglicht Ihnen, benutzerdefinierte Metriken aus Ihrer Anwendung zu generieren. Weitere Informationen finden Sie unter [Benutzerdefinierte Metriken mit Application Signals](AppSignals-CustomMetrics.md).
Sie können die Registerkarte „Zugehörige Metriken“ über die Registerkarten „Serviceübersicht“, „Serviceoperationen“, „Abhängigkeiten“, „Synthetics-Canarys“ und „RUM“ aufrufen.
![\[Zugehörige Metriken anzeigen\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/Custom_metrics.png)
+ Im linken Navigationsbereich sind alle Operationen und Abhängigkeiten zunächst nicht ausgewählt.
+ Das Diagramm zeigt am Anfang die Störungsmetrik für die Operation mit der höchsten Störungsrate.
Bevor Sie mit der Korrelationsanalyse beginnen, sollten Sie sichtbare Datenpunkte unter „Serviceoperationen“ oder „Abhängigkeiten“ haben. Analysieren Sie Korrelationen wie folgt:
1. Öffnen Sie die Seite „Serviceoperationen“ oder „Abhängigkeiten“.
1. Wählen Sie einen Datenpunkt in einem beliebigen Diagramm aus.
1. Wählen Sie im rechten Bereich die Option **Mit anderen Metriken korrelieren** aus.
1. In der Registerkarte **Zugehörige Metriken**, die sich jetzt öffnet, sehen Sie:
+ die ausgewählte Operation oder Abhängigkeit in der linken Navigationsleiste.
+ die ausgewählte Metrik, grafisch dargestellt in der Tabelle *Metriken durchsuchen*.
+ korrelierte Spans, wenn Sie einen Datenpunkt auswählen.
Um mehrere Metriken grafisch darzustellen, wählen Sie eine oder mehrere Metriken in der Ansicht **Durchsuchen** auf der Registerkarte **Zugehörige Metriken** aus. Wählen Sie **Grafisch dargestellte Metriken** aus, um alle entsprechenden Metriken anzuzeigen.
Zum Filtern von Metriken verwenden Sie die Filter im linken Bereich, um die Ansicht auf bestimmte Operationen oder Abhängigkeiten zu begrenzen, und suchen Sie über die Filterleiste in der Tabellenüberschrift nach Namen, Typ oder anderen Attributen. Diese Filteroptionen helfen Ihnen, Muster zu erkennen und Probleme effizienter zu beheben.
Wenn Sie zugehörige Metriken detailliert analysieren möchten, wählen Sie auf der Registerkarte **Zugehörige Metriken** einen Datenpunkt aus. Dann können Sie Folgendes einsehen:
+ Wichtigste Mitwirkende — Analysiert Metriken, indem CloudWatch Logs Insights-Abfragen ausgeführt werden. Diese Abfragen verarbeiten Enhanced Metrics Format (EMF)-Datensätze, die Schlüsselattribute für eine detaillierte Analyse der folgenden Elemente enthalten:
+ Latenzmessungen
+ Störungsereignisse
+ Metriken zur Serviceverfügbarkeit
Die folgenden Metriken unterstützen die wichtigsten Faktoren nicht:
+ OTEL-Metriken
+ Serverseitige Span-Metriken
Sie können sich die wichtigsten Faktoren für RED-Metriken und clientseitige Span-Metriken anzeigen lassen.
+ Korrelierte Spans: Der Bereich „Korrelierte Spans“ funktioniert wie die Registerkarte „Serviceoperationen“. Um Ihnen bei der Ermittlung zugehöriger Ablaufverfolgungen und Metriken zu helfen, funktioniert der Korrelationsmechanismus wie folgt:
+ Metriknamen werden mit Span-Attributen verglichen
+ Während des ausgewählten Zeitraums werden übereinstimmende Muster identifiziert
+ Relevante Ablaufverfolgungsinformationen werden angezeigt
Für eine effektive Analyse Ihrer Metriken und Spans müssen Sie verstehen, wie verschiedene Metriktypen korrelieren. Die wichtigsten Einschränkungen:
+ OTEL-Metriken korrelieren nicht mit Spans, da sie unabhängige Benennungssysteme verwenden.
+ Korrelieren Sie server- oder clientseitige Span-Metriken mit Spans wie folgt:
+ Fügen Sie Ihrer Konfiguration ein Feld für die Service-Dimension hinzu.
+ Ohne diese Service-Dimension können Sie die Metriken nicht mit Spans korrelieren.
+ Protokollanwendungen: Informationen zur Protokollanwendung finden Sie unter [Anwendungsprotokolle](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ServiceDetail.html#ServiceDetail-operations).
# Sehen Sie sich Ihre Anwendungstopologie an und überwachen Sie den Betriebsstatus mit der CloudWatch Anwendungsübersicht
**Anmerkung**
Die CloudWatch Anwendungsübersicht ersetzt die Service Map. Um eine auf AWS X-Ray Spuren basierende Karte Ihrer Anwendung zu sehen, öffnen Sie die [X-Ray Trace Map](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-servicemap.html). Wählen Sie im linken Navigationsbereich der CloudWatch Konsole im Bereich **X-Ray** die Option **Trace Map** aus.
Nachdem Sie Ihre Anwendung für Application Signals aktiviert haben, zeigt die Anwendungsübersicht Knoten an, die Ihre Gruppen darstellen. Sie können diese Gruppen detailliert aufschlüsseln, um sich Ihre Services und deren Abhängigkeiten anzusehen. Verwenden Sie die Anwendungsübersicht, um die Topologie Ihrer Anwendungsclients, Synthetics-Canarys, Services und Abhängigkeiten anzuzeigen und den Betriebszustand zu überwachen. Um die Anwendungsübersicht anzuzeigen, öffnen Sie die [CloudWatch Konsole](https://console.aws.amazon.com/cloudwatch/) und wählen Sie im linken Navigationsbereich im Bereich **Application Signals** die Option Application **Map** aus.
Nachdem Sie [Ihre Anwendung für Application Signals aktiviert](CloudWatch-Application-Signals-Enable.md) haben, verwenden Sie die Anwendungsübersicht, um die Überwachung des Betriebszustands Ihrer Anwendung zu vereinfachen:
+ Sehen Sie sich Verbindungen zwischen Client-, Canary-, Service- und Abhängigkeitsknoten an, um Ihre Anwendungstopologie und den Ausführungsablauf besser zu verstehen. Dies ist besonders hilfreich, wenn Ihre Service-Anwender nicht Ihr Entwicklungsteam sind.
+ Finden Sie heraus, welche Services Ihre [Service-Level-Ziele erfüllen oder nicht (SLOs)](CloudWatch-ServiceLevelObjectives.md). Wenn ein Service Ihre Anforderungen nicht erfüllt SLOs, können Sie schnell erkennen, ob ein nachgelagerter Service oder eine Abhängigkeit möglicherweise zu dem Problem beiträgt oder sich auf mehrere vorgelagerte Dienste auswirkt.
+ Wählen Sie einen einzelnen Client-, Synthetics-Canary-, Service- oder Abhängigkeitsknoten aus, um zugehörige Metriken zu sehen. Auf der Seite mit den [Servicedetails](ServiceDetail.md) sehen Sie detailliertere Informationen zu Operationen, Abhängigkeiten, Synthetics-Canarys und Client-Seiten.
+ Filtern und zoomen Sie die Anwendungsübersicht, damit Sie sich leichter auf einen Teil Ihrer Anwendungstopologie konzentrieren oder die gesamte Karte anzeigen können. Erstellen Sie einen Filter, indem Sie eine oder mehrere Eigenschaften aus dem Filter-Textfeld auswählen. Bei der Auswahl der einzelnen Eigenschaften werden Sie durch die Filterkriterien geführt. Sie sehen den vollständigen Filter unter dem Filter-Textfeld. Sie können jederzeit **Filter löschen** auswählen, um den Filter zu entfernen.
+ Überwachen Sie Dienste AWS für mehrere Konten in einer einzigen, einheitlichen Anwendungsübersicht. Dienste von verschiedenen Konten werden anhand von Kontoinformationen eindeutig identifiziert, sodass verteilte Anwendungen einheitlich beobachtet werden können.
+ Identifizieren Sie Dienste, die in Ihrer Anwendung noch nicht instrumentiert sind. Application Signals erkennt automatisch Dienste, die noch nicht instrumentiert wurden, und zeigt sie an, sodass Sie eine vollständige Observability-Abdeckung erreichen können. Dienste ohne Instrumentierung werden auf der Karte visuell unterschieden, sodass Sie Ihre Instrumentierung besser priorisieren können.
+ Gruppieren und filtern Sie Services, um benutzerdefinierte Ansichten zu erstellen, die zu Ihren Workflows passen. Diese Organisation hilft Ihnen, die am häufigsten verwendeten Services schnell zu finden und aufzurufen.
+ Speichern Sie Ihre gefilterten und gruppierten Ansichten, um schnell zu häufig verwendeten Konfigurationen zurückzukehren.
## Erkunden der Anwendungsübersicht
Wenn Sie die Anwendungsübersicht aufrufen, werden standardmäßig Services angezeigt, die nach **Zugehörige Services** gruppiert sind. „Zugehörige Services“ gruppiert Services auf der Grundlage ihrer Abhängigkeiten. Wenn Service A beispielsweise Service B aufruft, der Service C aufruft, werden sie unter Service A gruppiert. Sie können den SLI-Zustand, die Metriken und die Serviceanzahl für alle Services in jeder Gruppe einsehen.
![\[CloudWatch Standardanwendungsübersicht, gruppiert nach verwandten Diensten.\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/explore-application-map-overview.png)
Wählen Sie eine der Registerkarten aus, um Informationen zur Erkundung der einzelnen Knotentypen und der Edges (Verbindungen) zwischen ihnen zu erhalten.
### Dynamisches Gruppieren und Filtern
Sie können auf das Dropdown **Gruppieren nach** klicken, um verschiedene Gruppierungsoptionen zu nutzen. Standardmäßig bietet die Anwendungsübersicht zwei Gruppierungen:
+ **Zugehörige Services**: gruppiert Services auf der Grundlage ihrer Abhängigkeiten.
+ **Umgebung**: gruppiert Services nach ihrer Umgebung.
Wenn Sie eine eigene benutzerdefinierte Gruppierung festlegen möchten, klicken Sie auf **Gruppen verwalten**, um benutzerdefinierte Gruppen zu definieren, und kennzeichnen Sie Ihre Services oder fügen Sie OTEL-Ressourcenattribute mit dem Gruppenschlüssel hinzu.
**Anmerkung**
Um die Gruppierung über OTEL-Ressourcenattribute zu aktivieren, muss die CloudWatch Agentenversion v1.300056.0 oder höher sein.
![\[Benutzerdefiniertes Gruppierungsfenster erstellen\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/explore-application-map-create-custom-grouping.png)
Die Standardgruppierung in Application Signals organisiert Services automatisch anhand der nachgelagerten Abhängigkeiten. Das System analysiert das Diagramm der Serviceabhängigkeiten und erstellt Gruppen, in denen der Stammknoten (ein Service ohne Upstream-Abhängigkeiten) zum Gruppennamen wird. Alle Dienste, die direkt oder indirekt von diesem Root-Service abhängen, werden automatisch in die Gruppe aufgenommen. Wenn beispielsweise Service A Service B aufruft, der wiederum Service C aufruft, werden alle drei Services zusammen mit Service A als Gruppennamen gruppiert, da es sich um den Stamm der Abhängigkeitskette handelt. Dieser automatische Gruppierungsmechanismus bietet eine natürliche Möglichkeit, verwandte Services auf der Grundlage ihrer tatsächlichen Laufzeitinteraktionen und Abhängigkeiten zu visualisieren und zu verwalten.
### Gruppenaktionen und Einblicke
Diese Aktionen können Sie für jede Gruppe ausführen:
+ Klicken Sie auf **Mehr anzeigen**, um Metrikdiagramme, die letzten beiden Änderungsereignisse und die letzte Bereitstellungszeit für die Gruppe anzuzeigen
![\[Weitere Schubladen für Gruppen in der Anwendungsübersicht anzeigen\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/explore-application-map-view-more.png)
+ Klicken Sie auf **Dashboard anzeigen**, um das Metrik-Dashboard, die Tabelle mit den Änderungsereignissen und die Serviceliste für die Gruppe anzuzeigen
![\[Anwendungs-Dashboard für die Gruppe anzeigen\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/explore-application-map-team-overview.png)
![\[Anwendungs-Dashboard für Gruppen mit Metrikdiagrammen anzeigen\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/explore-application-map-team-overview-2.png)
Mithilfe der Option **Gruppe und Filter** in der linken Leiste können Sie Gruppen filtern, die Dienste nach Bereitstellungszeit, SLI-Status oder Rechenplattformtyp anbieten.
![\[Gruppieren und Filtern von Diensten im Anwendungs-Dashboard\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/explore-application-map-grouping-filter.png)
Sie können in Ihrem kontoübergreifenden Observability-Setup auch nach AWS Konten filtern, um Dienste von bestimmten Konten anzuzeigen.
![\[Filtern Sie Dienste im Anwendungs-Dashboard nach Konto\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/explore-application-map-account-filter.png)
Über die Leiste **Suchen und filtern** können Sie Gruppen nach Namen suchen oder Gruppen suchen, die eine bestimmte Serviceumgebung oder -abhängigkeit enthalten. Filtern Sie nach Konto-ID, um sich auf Dienste von bestimmten Konten zu konzentrieren.
![\[Suchen und filtern Sie Dienste in der Anwendungsübersicht\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/explore-application-map-search-and-filter.png)
### Konfigurieren benutzerdefinierter Gruppen
Mit der benutzerdefinierten Gruppierung können Sie Services logisch auf der Grundlage Ihrer Geschäftsanforderungen und betrieblichen Prioritäten organisieren. Diese Funktion ermöglicht Ihnen, definierte Ansichten zu speichern und aufzurufen, die nach Ihren spezifischen Bedürfnissen priorisiert sind, Gruppen auf der Grundlage der Teamzuständigkeit zu erstellen und Gruppen von Services zusammenzustellen, die für wichtige Geschäftstransaktionen benötigt werden.
Erstellen Sie die benutzerdefinierten Gruppennamen (die Gruppennamen, die Sie in der Benutzeroberfläche sehen werden) und die entsprechenden Gruppenschlüsselnamen. Führen Sie diesen Schritt entweder über die Benutzeroberfläche von Application Signals oder mithilfe der [PutGroupingConfiguration](https://docs.aws.amazon.com/applicationsignals/latest/APIReference/API_PutGroupingConfiguration.html)API aus.
Bei den Namen der Gruppenschlüssel kann es sich entweder um einen AWS Tagschlüssel oder ein OTEL-Ressourcenattribut für Ihren Service handeln. Die Entscheidung für Tags oder OTEL-Ressourcenattributen sollte sich nach Ihrer Rechenplattform richten:
+ Für Single-Service-Plattformen (z. B. Lambda oder Auto Scaling Group) — Verwenden Sie Tags AWS
+ Für Multi-Service-Plattformen (z. B. Amazon-EKS-Cluster) – verwenden Sie OTEL-Ressourcenattribute für eine detailliertere Gruppierung
**Hinzufügen von Tags AWS **
Fügen Sie einem Amazon EKS-Cluster ein AWS Tag mit dem benutzerdefinierten Gruppenschlüssel als Schlüssel und Wert hinzu. Wenn mehrere Services in einem Amazon-EKS-Cluster ausgeführt werden, sind sie alle mit demselben benutzerdefinierten Gruppenschlüssel gekennzeichnet. Wenn beispielsweise auf Amazon EKS-Cluster A Service 1, Service 2 und Service 3 ausgeführt werden, werden durch Hinzufügen eines AWS Tags mit dem Schlüssel *Team X* zum Cluster alle drei Services zu *Team X* hinzugefügt. Um *Team X* nur bestimmte Dienste hinzuzufügen, fügen Sie OTEL-Ressourcenattribute für die Dienste hinzu, wie unten gezeigt.
**Hinzufügen von OTEL-Ressourcenattributen**
Informationen zum Hinzufügen eines OTEL-Ressourcenattributs finden Sie in der folgenden Konfiguration:
**Allgemeine Konfiguration**
Konfigurieren Sie die `OTEL_RESOURCE_ATTRIBUTES`-Umgebungsvariable in Ihrer Anwendung mithilfe der Schlüssel-Wert-Paare für benutzerdefinierte Gruppen. Die Schlüssel sind getrennt durch `&` unter `aws.application_signals.metric_resource_keys` aufgeführt.
Wenn Sie zum Beispiel benutzerdefinierte Gruppen mit `Application=PetClinic` und `Owner=Test` erstellen möchten, verwenden Sie Folgendes:
```
OTEL_RESOURCE_ATTRIBUTES=Application=PetClinic,Owner=Test,aws.application_signals.metric_resource_keys=Application&Owner
```
**Plattformspezifische Konfiguration**
Im Folgenden sehen Sie die Bereitstellungsspezifikationen.
**Amazon EKS und natives Kubernetes**
```
apiVersion: apps/v1
kind: Deployment
metadata:
...
spec:
replicas: 1
...
template:
spec:
containers:
- name: your-app
image: your-app-image
env:
...
- name: OTEL_RESOURCE_ATTRIBUTES
value: Application=PetClinic,Owner=Test,aws.application_signals.metric_resource_keys=Application&Owner
```
**Amazon EC2**
Fügen Sie dem Startskript Ihrer Anwendung `OTEL_RESOURCE_ATTRIBUTES` hinzu. Das vollständige Beispiel finden Sie unter [Hinzufügen von `OTEL_RESOURCE_ATTRIBUTES`](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Signals-Enable-EC2Main.html#CloudWatch-Application-Signals-Monitor-EC2).
```
...
OTEL_RESOURCE_ATTRIBUTES="service.name=$YOUR_SVC_NAME,Application=PetClinic,Owner=Test,aws.application_signals.metric_resource_keys=Application&Owner" \
java -jar $MY_JAVA_APP.jar
```
**Amazon ECS**
Fügen Sie `OTEL_RESOURCE_ATTRIBUTES` dem hinzu TaskDefinition. Das vollständige Beispiel finden Sie unter [Aktivieren in Amazon ECS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Signals-Enable-ECSMain.html).
```
{
"name": "my-app",
...
"environment": [
{
"name": "OTEL_RESOURCE_ATTRIBUTES",
"value": "service.name=$YOUR_SVC_NAME,Application=PetClinic,Owner=Test,aws.application_signals.metric_resource_keys=Applicationmanagement portalOwner"
},
...
]
}
```
**Lambda**
Fügen Sie der Lambda-Umgebungsvariable `OTEL_RESOURCE_ATTRIBUTES` hinzu.
```
OTEL_RESOURCE_ATTRIBUTES="Application=PetClinic,Owner=Test,aws.application_signals.metric_resource_keys=Application&Owner"
```
### Anzeigen von Services in Gruppen
Um Services und ihre Abhängigkeiten in einer Gruppe anzuzeigen, klicken Sie auf den Gruppennamen. Eine Übersicht der Services in der Gruppe wird angezeigt. Für jeden Serviceknoten sehen Sie SLI-Zustand, Metriken und Plattformdetails. Services, bei denen ein SLI-Verstoß vorliegt, werden hervorgehoben.
![\[CloudWatch Anwendungszuordnungsdienste innerhalb der Gruppe.\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/View-services-groups.png)
Dienste ohne Instrumentierung werden mit einem deutlichen visuellen Indikator (z. B. einem gestrichelten Rand oder einer anderen Farbe) angezeigt, um sie von instrumentierten Diensten zu unterscheiden. Zeigen Sie mit der Maus auf einen Serviceknoten ohne Instrumentierung, um Anleitungen zur Instrumentierung und Links zur Einrichtungsdokumentation anzuzeigen.
![\[Filtern Sie auf der Anwendungsübersicht nach Diensten ohne Instrumentierung\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/explore-application-map-uninstrumented-filter.png)
Alle Canaries, RUM-Clients und AWS Service-Knoten werden standardmäßig ausgeblendet. Wenn Services in dieser Gruppe Services aufrufen, die nicht Teil dieser Gruppe sind, werden sie ebenfalls standardmäßig ausgeblendet.
![\[Kanarische Knoten werden in der Anwendungsübersicht zu einer Gruppe zusammengefasst\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/explore-application-map-canary-collapse.png)
Wenn Ihre Übersicht immer noch zu groß ist, um eine effektive Untersuchung zuzulassen, können Sie die Untersuchung mithilfe verschachtelter Gruppierungen eingrenzen. Wenn Sie Services beispielsweise nach **Geschäftsbereich** gruppiert haben und immer noch zu viele Services in einer Gruppe haben, wählen Sie im Dropdown-Menü „Gruppieren nach“ die Option **Team** aus, um eine verschachtelte Gruppierungsstruktur zu erschaffen.
![\[Verschachtelte Gruppierung in der Anwendungsübersicht\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/explore-application-map-nested-grouping.png)
### Serviceeinblicke und -details
Auf dieser Seite können Sie auch neben der Suchleiste auf **Ansicht speichern** klicken, damit Sie beim nächsten Mal nicht dieselbe Gruppierung und Filterung auswählen müssen.
![\[Speichern Sie die Gruppierungskonfiguration\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/explore-application-map-save-view.png)
Klicken Sie im Serviceknoten auf **Mehr anzeigen**, um die Diagramme Service Audit, Change Events, SLI-Status und Metriken anzuzeigen.
![\[CloudWatch Einblicke in den Service von Application Map.\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/explore-application-map-service-view-more.png)
Wenn Sie den Servicebetrieb und andere Servicedetails anzeigen möchten, klicken Sie auf **Dashboard anzeigen**, um zur Seite mit der Serviceübersicht zu gelangen.
![\[CloudWatch Übersicht über den Service in der Anwendungsübersicht.\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/explore-application-map-service-overview.png)
Alternativ können Sie auf Edge klicken, um Metriken zu einem bestimmten Abhängigkeitsaufruf eines Service aufzurufen.
![\[CloudWatch Anwendungsübersicht, Knoten, Edge Drawer\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/explore-application-map-edge.png)
### Ereignisse ändern
Verfolgen Sie mit der automatischen Verarbeitung von Ereignissen durch Application Signals CloudTrail Änderungsereignisse in Ihrer gesamten Anwendung. Überwachen Sie die Konfigurations- und Bereitstellungsereignisse für Dienste und deren Abhängigkeiten und bieten Sie so unmittelbaren Kontext für Betriebsanalysen und Problembehebungen. Die Erkennung von Änderungsereignissen wird zusammen mit der Aktivierung der Serviceerkennung über die CloudWatch Konsole oder StartDiscovery API aktiviert. Für EKS-Dienste erfordert die Bereitstellungserkennung, dass die EKS-Dienste mit dem Application-Signals-Instrumentierungs-SDK instrumentiert sind. Application Signals korreliert Bereitstellungszeiten automatisch mit Leistungsänderungen, sodass Sie schnell erkennen können, ob kürzliche Bereitstellungen zu Serviceproblemen beigetragen haben. Sehen Sie sich den Verlauf von Änderungsereignissen und deren Auswirkungen auf Ihre Services an, ohne dass zusätzliche Anforderungen an Konfiguration oder Einrichtung gestellt werden müssen.
### Audit-Ergebnisse
Entdecken Sie wichtige Einblicke anhand der Audit-Ergebnisse von Application Signals. Der Service analysiert Ihre Anwendungen, um wichtige Beobachtungen und potenzielle Probleme zu melden und so die Ursachenanalyse zu vereinfachen. Diese automatisierten Ergebnisse konsolidieren die relevanten Spuren, sodass Sie nicht mehr mit mehreren Klicks navigieren müssen. Das Auditsystem hilft Teams dabei, Probleme und ihre zugrunde liegenden Ursachen schnell zu identifizieren und ermöglicht so eine schnellere Problemlösung.
Für Dienste, die auf Amazon Bedrock ausgeführt werden, überwacht Application Signals automatisch die Nutzungsmuster von GenAI-Tokens. Das Prüfsystem erkennt Anomalien beim Verbrauch von Eingabe- und Ausgabe-Tokens und vergleicht die aktuelle Nutzung mit historischen Ausgangswerten. Wenn die Token-Nutzung die normalen Muster überschreitet, bieten die Prüfungsergebnisse eine detaillierte Analyse, einschließlich Trends beim Token-Verbrauch, Kostenauswirkungen und Optimierungsempfehlungen. Dies hilft Teams dabei, ineffiziente Eingabeaufforderungen, unerwartete Token-Spitzen und Möglichkeiten zur Senkung der Betriebskosten von GenAI zu identifizieren.
### Kontoübergreifende Beobachtbarkeit auf der Anwendungsübersicht
Application Signals unterstützt kontenübergreifende Beobachtbarkeit, sodass Sie Dienste, die auf mehrere AWS Konten verteilt sind, in einer einzigen einheitlichen Anwendungsübersicht überwachen und visualisieren können. Diese Funktion ist für Unternehmen mit Architekturen mit mehreren Konten, die sich an bewährte Verfahren halten, unerlässlich. AWS
**Die wichtigsten Funktionen:**
+ *Einheitliche Ansicht*: Zeigen Sie Services von mehreren AWS Konten in einer einzigen Anwendungsübersicht an und erhalten Sie so ein vollständiges Bild Ihrer verteilten Anwendungsarchitektur.
+ *Kontoidentifikation*: Jeder Serviceknoten zeigt deutlich seine Konto-ID und Region an, sodass die Inhaberschaft und der Standort des Dienstes leicht zu identifizieren sind.
+ *Zentralisierte Überwachung*: Überwachen Sie den Zustand, die Leistung und den SLO-Status der Dienste für alle verbundenen Konten von einem einzigen Monitoring-Konto aus.
+ *Kontoübergreifende Filterung: Filtern* und gruppieren Sie Dienste nach Konto-ID, um sich auf bestimmte Konten zu konzentrieren oder kontoübergreifende Interaktionen anzuzeigen.
**So funktioniert es:**
Application Signals verwendet AWS Organizations und kontenübergreifendes Teilen, um die Beobachtbarkeit über mehrere Konten hinweg zu ermöglichen. Informationen zur Einrichtung der kontenübergreifenden Observability finden Sie unter. [CloudWatch kontenübergreifende Beobachtbarkeit](CloudWatch-Unified-Cross-Account.md)
------
#### [ View your application services ]
**Service (instrumentiert)**
**In der Anwendungsübersicht können Sie Ihre Anwendungsdienste SLOs und deren Status sowie die Service-Level-Indikatoren (SLIs) einsehen.** Wenn Sie nichts SLOs für einen Service erstellt haben, klicken Sie unter dem Serviceknoten auf die Schaltfläche „**SLO erstellen**“.
In der **Anwendungsübersicht** sehen Sie alle Ihre Services. Außerdem werden die Kunden und Canarys angezeigt, die den Service nutzen, sowie die Abhängigkeiten, die Ihre Services aufrufen, wie in der folgenden Abbildung dargestellt:
![\[Eine CloudWatch Anwendungsübersicht, in der ein fehlerfreier und ein fehlerhafter Dienst angezeigt werden.\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/service-map-service-healthy-unhealthy.png)
Wenn Sie einen Serviceknoten auswählen, öffnet sich ein Bereich mit detaillierten Serviceinformationen:
+ Gesamtfehlerrate und Störungsrate.
+ Die Anzahl von SLIs und SLOs das sind `healthy` oder`unhealthy`.
+ Die Option, weitere Informationen zu einem SLO anzuzeigen.
+ Der `Cluster`, der `Namespace` und die `Workload` für Services, die in Amazon EKS gehostet werden, oder die Umgebung für Services, die in Amazon ECS oder Amazon EC2 gehostet werden. Wählen Sie für von Amazon EKS gehostete Dienste einen beliebigen Link, um CloudWatch Container Insights zu öffnen.
+ AccountId und Region.
+ Der Abschnitt „**Änderung**“ zeigt die letzten Änderungsereignisse und den Zeitpunkt der letzten Bereitstellung an.
+ Die Registerkarte **Betrieblicher Audit** bietet automatisierte Audit-Ergebnisse und Empfehlungen.
+ Diagramm mit Servicemetriken zu Verfügbarkeit, Latenz, Störungen und Fehlern.
Wählen Sie einen Edge oder eine Verbindung zwischen einem Serviceknoten und einem nachgeschalteten Service- oder Abhängigkeitsknoten aus. Dadurch wird ein Bereich geöffnet, der die Top-Pfade nach Störungsrate, Latenz und Fehlerrate enthält, wie im folgenden Beispielbild gezeigt. Wählen Sie einen Link im Bereich aus, um die Seite mit den [Servicedetails](ServiceDetail.md) zu öffnen und detaillierte Informationen zum ausgewählten Service oder zur ausgewählten Abhängigkeit anzuzeigen.
![\[Ein CloudWatch Application-Map-Service-Edge\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/App-signals-service-edge.png)
Wenn Sie einen Edge-Knoten auswählen, öffnet sich ein Bereich mit detaillierten Serviceinformationen:
+ Gesamtzahl der Anforderungen, Latenz, Fehlerrate und Störungsrate
+ Top-Pfad nach Störungsrate
+ Top-Pfad nach Latenz
+ Top-Pfad nach Fehlerrate
**Service (nicht instrumentiert)**
Dienste ohne Instrumentierung werden auf der Anwendungsübersicht angezeigt, auch wenn sie nicht mit Application Signals konfiguriert wurden. Diese Dienste werden automatisch erkannt, indem Resource Explorer mithilfe von Anwendungsnamen und -tags verwendet wird. Das System kann automatisch bis zu 3.000 Ressourcen in Ihrem AWS Konto erkennen.
Wenn Sie einen Serviceknoten ohne Instrumentierung auswählen, wird ein Fenster geöffnet, in dem Folgendes angezeigt wird:
+ Dienstname und Identifikationsinformationen
+ AccountId und Region, in der der Dienst erkannt wird
+ Status und Anleitung zur Instrumentierung
+ Call-to-Action-Schaltfläche „Anwendungssignale aktivieren“, die Anweisungen zur Einrichtung enthält
+ Plattformtyp berechnen (falls nachweisbar)
Dienste ohne Instrumentierung helfen Ihnen:
+ Identifizieren Sie Lücken in Ihrer Observability-Abdeckung
+ Priorisieren Sie anhand ihrer Position in Ihrer Architektur, welche Services als Nächstes eingesetzt werden sollen
+ Machen Sie sich bereits vor der vollständigen Instrumentierung mit der gesamten Anwendungstopologie vertraut
+ Planen Sie die Einführung der Instrumentierung in Ihrem gesamten Unternehmen
**Anmerkung**
Dienste ohne Instrumentierung zeigen nur begrenzte Telemetriedaten an, da sie nicht aktiv Metriken oder Traces senden.
![\[CloudWatch Instrumentierung, Filter für Anwendungsübersicht\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/explore-application-map-instrumentation-filter.png)
------
#### [ View dependencies ]
Ihre Anwendungsabhängigkeiten werden in der Anwendungsübersicht angezeigt und sind mit den Services verbunden, die sie aufrufen.
Wählen Sie einen Abhängigkeitsknoten aus, um einen Bereich mit folgenden Inhalten aufzurufen: Fehlerrate und Störungsrate, Metrikdiagramm für Anforderungen, Verfügbarkeit und Latenz.
Wenn es sich bei dem Abhängigkeitsknoten um einen Dienst oder eine Ressource handelt, werden im Bereich Änderungsereignisse für den angeforderten Zeitraum angezeigt.
![\[Eine CloudWatch Anwendungsübersicht, die einen erweiterbaren AWS Dienstabhängigkeitsknoten anzeigt.\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/service-map-dependency.png)
------
#### [ View clients ]
Nachdem Sie [X-Ray Tracing für Ihre CloudWatch RUM-Webclients aktiviert](CloudWatch-RUM-get-started-create-app-monitor.md) haben, werden sie in der Anwendungsübersicht angezeigt, die mit den von ihnen aufgerufenen Diensten verbunden ist.
Wählen Sie einen Client-Knoten aus, um einen Bereich mit detaillierten Client-Informationen zu öffnen:
+ Metriken für Seitenladevorgänge, durchschnittliche Ladezeit, Fehler und durchschnittliche Webdaten
+ Ein Diagramm, das eine Aufschlüsselung der Fehler anzeigt
+ Ein Link zur Anzeige der Kundendetails in RUM CloudWatch
![\[Eine CloudWatch Anwendungsübersicht, die einen erweiterbaren Clientknoten anzeigt.\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/service-map-client.png)
Wählen Sie **Dashboard anzeigen** aus, um die Canary-Details zu öffnen.
------
#### [ View synthetics canaries ]
Um Kanarienvögel auf Ihrer Anwendungsübersicht anzuzeigen, aktivieren Sie die Option „[X-Ray Tracing](CloudWatch-RUM-get-started-create-app-monitor.md)“ für Ihre CloudWatch Synthetics-Kanarienvögel. Nach der Aktivierung werden Canarys in der Anwendungsübersicht mit den von ihnen aufgerufenen Services verbunden angezeigt.
Das System gruppiert Canarys standardmäßig in einem einzigen erweiterbaren Symbol. Im Bereich mit den detaillierten Canary-Informationen werden Metriken, Traces und Statusinformationen angezeigt.
Wählen Sie einen Canary-Knoten aus, um einen Bereich mit detaillierten Canary-Informationen zu öffnen, wie in der folgenden Abbildung gezeigt:
![\[Eine CloudWatch Anwendungsübersicht, die einen erweiterbaren Synthetics Canary-Node anzeigt.\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/service-map-canary.png)
Wählen Sie **Dashboard anzeigen** aus, um die Canary-Details zu öffnen.
------
# Beobachtbarkeit von Anwendungen für Action AWS
Application Observability for AWS GitHub Action bietet einen Workflow zur Untersuchung der end-to-end Anwendungsbeobachtbarkeit, der Ihren Quellcode und Ihre Telemetriedaten aus der Produktion in Echtzeit mit dem KI-Agenten verbindet. Er nutzt CloudWatch MCPs und generiert benutzerdefinierte Eingabeaufforderungen, um den Kontext bereitzustellen, den KI-Agenten für die Fehlerbehebung und die Anwendung von Codekorrekturen benötigen.
[Die Aktion richtet den MCP-Server und den [MCP-Server von CloudWatch Application Signals](https://awslabs.github.io/mcp/servers/cloudwatch-applicationsignals-mcp-server) ein und CloudWatch konfiguriert sie, sodass sie auf Live-Telemetriedaten als Kontext zur Fehlerbehebung zugreifen können.](https://awslabs.github.io/mcp/servers/cloudwatch-applicationsignals-mcp-server) Sie können Ihr bevorzugtes KI-Modell — sei es über Ihren eigenen API-Schlüssel, ein Drittanbietermodell oder Amazon Bedrock — für Untersuchungen zur Anwendungsleistung verwenden.
Geben Sie zunächst `@awsapm` in Ihren GitHub Problemen an, ob der KI-Agent ausgelöst werden soll. Der Agent behebt Produktionsprobleme, implementiert Korrekturen und verbessert die Observability-Abdeckung auf der Grundlage Ihrer Live-Anwendungsdaten.
Für diese Maßnahme selbst fallen keine direkten Kosten an. Die Nutzung dieser Aktion kann jedoch zu Gebühren für AWS Dienste und die Nutzung von KI-Modellen führen. Ausführliche Informationen zu möglichen [Kosten finden Sie in der Dokumentation zu den Kostenerwägungen](https://github.com/marketplace/actions/application-observability-for-aws#-cost-considerations).
## Erste Schritte
Mit dieser Aktion werden KI-Agenten in Ihrem GitHub Workflow konfiguriert, indem AWS spezifische MCP-Konfigurationen und benutzerdefinierte Observability-Prompts generiert werden. Sie müssen lediglich die IAM-Rolle angeben, die Sie übernehmen möchten, und eine [Bedrock-Model-ID](https://docs.aws.amazon.com/bedrock/latest/userguide/models-supported.html), die Sie verwenden möchten, oder ein API-Token aus Ihrem bestehenden LLM-Abonnement. Das folgende Beispiel zeigt eine Workflow-Vorlage, die diese Aktion in die von [Anthropic integriert, claude-code-base-action um automatisierte Untersuchungen](https://github.com/anthropics/claude-code-base-action) durchzuführen.
### Voraussetzungen
Bevor Sie beginnen, stellen Sie sicher, dass Sie über Folgendes verfügen:
+ **GitHub Repository-Berechtigungen**: Schreibzugriff oder höher auf das Repository (erforderlich, um die Aktion auszulösen)
+ **AWS IAM-Rolle**: Eine mit OpenID Connect (OIDC) konfigurierte IAM-Rolle für Aktionen mit Berechtigungen für GitHub :
+ CloudWatch Anwendungssignale und Zugriff CloudWatch
+ Zugriff auf Amazon Bedrock-Modelle (bei Verwendung von Bedrock-Modellen)
+ **GitHub Token**: Der Workflow verwendet automatisch GITHUB\$1TOKEN mit den erforderlichen Berechtigungen
### Schritte zur Einrichtung
#### Schritt 1: AWS Anmeldeinformationen einrichten
Diese Aktion basiert auf der Aktion [aws-actions/](https://github.com/aws-actions/configure-aws-credentials), um die AWS Authentifizierung in Ihrer configure-aws-credentials Aktionsumgebung einzurichten. GitHub Wir empfehlen die Verwendung von OpenID Connect (OIDC) zur Authentifizierung mit. AWS OIDC ermöglicht Ihren GitHub Actions-Workflows den Zugriff auf AWS Ressourcen mit kurzlebigen Anmeldeinformationen, sodass Sie keine langfristigen AWS Anmeldeinformationen in Ihrem Repository speichern müssen.
1. **Erstellen Sie einen IAM-Identitätsanbieter**
Erstellen Sie zunächst einen IAM-Identitätsanbieter, der seinem OIDC-Endpunkt in GitHub der Management Console vertraut: AWS
1. Öffnen Sie die IAM-Konsole
1. Klicken Sie unter **Zugriffsverwaltung** auf **Identitätsanbieter**
1. Klicken Sie auf die Schaltfläche **Anbieter hinzufügen**, um den GitHub Identitätsanbieter hinzuzufügen, falls er noch nicht erstellt wurde
1. Wählen Sie den **OpenID Connect-Typ** des Identitätsanbieters
1. Geben Sie in `https://token.actions.githubusercontent.com` das **Eingabefeld Provider-URL** ein
1. Geben Sie in `sts.amazonaws.com` das Eingabefeld „**Zielgruppe**“ ein
1. Klicken Sie auf die Schaltfläche **Anbieter hinzufügen**
1. **Erstellen Sie eine IAM-Richtlinie**
Erstellen Sie eine IAM-Richtlinie mit den erforderlichen Berechtigungen für diese Aktion. Einzelheiten finden Sie [Erforderliche Berechtigungen](#Service-Application-Observability-for-AWS-GitHub-Action-required-permissions) im folgenden Abschnitt.
1. **Erstellen Sie eine IAM-Rolle**
Erstellen Sie eine IAM-Rolle (z. B.`AWS_IAM_ROLE_ARN`) in der AWS Management Console mit der folgenden Vorlage für eine Vertrauensrichtlinie. Dadurch können autorisierte GitHub Repositorys die Rolle übernehmen:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam:::oidc-provider/token.actions.githubusercontent.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
},
"StringLike": {
"token.actions.githubusercontent.com:sub": "repo:/:ref:refs/heads/"
}
}
}
]
}
```
Ersetzen Sie die folgenden Platzhalter in der Vorlage:
+ ``- Ihre AWS Konto-ID
+ ``- Der Name Ihrer GitHub Organisation
+ ``- Ihr Repository-Name
+ ``- Ihr Branchenname (z. B. main)
1. **Hängen Sie die IAM-Richtlinie an**
Fügen Sie auf der Registerkarte „Berechtigungen“ der Rolle die IAM-Richtlinie an, die Sie in Schritt 2 erstellt haben.
Weitere Informationen zur Konfiguration von OIDC mit AWS finden Sie in der [configure-aws-credentials OIDC-Schnellstartanleitung](https://github.com/aws-actions/configure-aws-credentials/tree/main?tab=readme-ov-file#quick-start-oidc-recommended).
#### Schritt 2: Secrets konfigurieren und Workflow hinzufügen
1. **Konfigurieren Sie Repository-Geheimnisse**
Gehe zu deinem Repository → Einstellungen → Geheimnisse und Variablen → Aktionen.
+ Erstellen Sie ein neues Repository-Geheimnis mit dem Namen `AWS_IAM_ROLE_ARN` und legen Sie seinen Wert auf den ARN der IAM-Rolle fest, die Sie in Schritt 1 erstellt haben.
+ (Optional) Erstellen Sie eine Repository-Variable mit `AWS_REGION` dem Namen Ihrer AWS Region (standardmäßig auf, `us-east-1` falls nicht festgelegt)
1. **Fügen Sie die Workflow-Datei hinzu**
Im Folgenden finden Sie einen Beispiel-Workflow, der die Verwendung dieser Aktion mit Amazon Bedrock-Modellen demonstriert. Erstellen Sie anhand dieser Vorlage in Ihrem GitHub Repository-Verzeichnis einen Workflow zur Untersuchung von Application Observability. `.github/workflows`
```
name: Application observability for AWS
on:
issue_comment:
types: [created, edited]
issues:
types: [opened, assigned, edited]
jobs:
awsapm-investigation:
if: |
(github.event_name == 'issue_comment' && contains(github.event.comment.body, '@awsapm')) ||
(github.event_name == 'issues' && (contains(github.event.issue.body, '@awsapm') || contains(github.event.issue.title, '@awsapm')))
runs-on: ubuntu-latest
permissions:
contents: write # To create branches for PRs
pull-requests: write # To post comments on PRs
issues: write # To post comments on issues
id-token: write # Required for AWS OIDC authentication
steps:
- name: Checkout repository
uses: actions/checkout@v4
- name: Configure AWS credentials
uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: ${{ secrets.AWS_IAM_ROLE_ARN }}
aws-region: ${{ vars.AWS_REGION || 'us-east-1' }}
# Step 1: Prepare AWS MCP configuration and investigation prompt
- name: Prepare Investigation Context
id: prepare
uses: aws-actions/application-observability-for-aws@v1
with:
bot_name: "@awsapm"
cli_tool: "claude_code"
# Step 2: Execute investigation with Claude Code
- name: Run Claude Investigation
id: claude
uses: anthropics/claude-code-base-action@beta
with:
use_bedrock: "true"
# Set to any Bedrock Model ID
model: "us.anthropic.claude-sonnet-4-5-20250929-v1:0"
prompt_file: ${{ steps.prepare.outputs.prompt_file }}
mcp_config: ${{ steps.prepare.outputs.mcp_config_file }}
allowed_tools: ${{ steps.prepare.outputs.allowed_tools }}
# Step 3: Post results back to GitHub issue/PR (reuse the same action)
- name: Post Investigation Results
if: always()
uses: aws-actions/application-observability-for-aws@v1
with:
cli_tool: "claude_code"
comment_id: ${{ steps.prepare.outputs.awsapm_comment_id }}
output_file: ${{ steps.claude.outputs.execution_file }}
output_status: ${{ steps.claude.outputs.conclusion }}
```
**Hinweis zur Konfiguration:**
+ Dieser Workflow `@awsapm` wird automatisch ausgelöst, wenn er in einem Problem oder Kommentar erwähnt wird
+ Der Workflow verwendet das im vorherigen Schritt konfigurierte `AWS_IAM_ROLE_ARN` Geheimnis
+ Aktualisieren Sie den Modellparameter in Schritt 2, um Ihre bevorzugte Amazon Bedrock-Modell-ID anzugeben
+ Sie können den Bot-Namen (z. B.`@awsapm-prod`,`@awsapm-staging`) im Parameter bot\$1name anpassen, um verschiedene Umgebungen zu unterstützen
#### Schritt 3: Fangen Sie an, die Aktion zu verwenden
Sobald der Workflow konfiguriert ist, können Sie jedes GitHub Problem erwähnen`@awsapm`, um eine KI-gestützte Untersuchung auszulösen. Die Aktion analysiert Ihre Anfrage, greift auf Live-Telemetriedaten zu und gibt Empfehlungen oder implementiert automatisch Korrekturen.
**Beispiele für Anwendungsfälle:**
1. Untersuchen Sie Leistungsprobleme und korrigieren Sie Folgendes:
`@awsapm, can you help me investigate availability issues in my appointment service?`
![\[alt text not found\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/github-availability-issue-investigate.png)
`@awsapm, can you post a fix?`
![\[alt text not found\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/github-availability-issue-pr-fix.png)
1. Instrumentierung aktivieren:
`@awsapm, please enable Application Signals for lambda-audit-service and create a PR with the required changes.`
1. Telemetriedaten abfragen:
`@awsapm, how many GenAI tokens have been consumed by my services in the past 24 hours?`
**Was passiert als Nächstes:**
1. Der Workflow erkennt die `@awsapm` Erwähnung und löst die Untersuchung aus
1. Der AI-Agent greift über die konfigurierten MCP-Server auf Ihre AWS Live-Telemetriedaten zu
1. Der Agent analysiert das Problem und entweder:
+ Veröffentlicht Ergebnisse und Empfehlungen direkt in der Ausgabe
+ Erstellt eine Pull-Anfrage mit Codeänderungen (für Instrumentierung oder Problembehebungen)
1. Du kannst die Ergebnisse überprüfen und die Konversation fortsetzen, indem du @awsapm erneut mit weiteren Fragen erwähnst
## Sicherheit
Bei dieser Aktion wird der Sicherheit mit strengen Zugriffskontrollen, OIDC-basierter AWS Authentifizierung und integriertem Schutz vor Prompt-Injection-Angriffen Priorität eingeräumt. Nur Benutzer mit Schreibzugriff oder höher können die Aktion auslösen, und alle Operationen sind auf das jeweilige Repository beschränkt.
Für detaillierte Sicherheitsinformationen, einschließlich:
+ Zugriffskontrolle und Genehmigungsanforderungen
+ AWS IAM-Berechtigungen und OIDC-Konfiguration
+ Sofortige Injektionsrisiken und Abhilfemaßnahmen
+ Bewährte Methoden für die Gewährleistung der Sicherheit
Weitere Informationen finden Sie in der [Sicherheitsdokumentation](https://github.com/aws-actions/application-observability-for-aws/blob/main/docs/security.md).
## Konfiguration
### Erforderliche Berechtigungen
Die von GitHub Actions übernommene IAM-Rolle muss über die folgenden Berechtigungen verfügen.
**Hinweis**: `bedrock:InvokeModel` und `bedrock:InvokeModelWithResponseStream` sind nur erforderlich, wenn Sie Amazon Bedrock-Modelle verwenden
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"application-signals:ListServices",
"application-signals:GetService",
"application-signals:ListServiceOperations",
"application-signals:ListServiceLevelObjectives",
"application-signals:GetServiceLevelObjective",
"application-signals:ListAuditFindings",
"cloudwatch:DescribeAlarms",
"cloudwatch:DescribeAlarmHistory",
"cloudwatch:ListMetrics",
"cloudwatch:GetMetricData",
"cloudwatch:GetMetricStatistics",
"logs:DescribeLogGroups",
"logs:DescribeQueryDefinitions",
"logs:ListLogAnomalyDetectors",
"logs:ListAnomalies",
"logs:StartQuery",
"logs:StopQuery",
"logs:GetQueryResults",
"logs:FilterLogEvents",
"xray:GetTraceSummaries",
"xray:GetTraceSegmentDestination",
"xray:BatchGetTraces",
"xray:ListRetrievedTraces",
"xray:StartTraceRetrieval",
"servicequotas:GetServiceQuota",
"synthetics:GetCanary",
"synthetics:GetCanaryRuns",
"s3:GetObject",
"s3:ListBucket",
"iam:GetRole",
"iam:ListAttachedRolePolicies",
"iam:GetPolicy",
"iam:GetPolicyVersion",
"bedrock:InvokeModel",
"bedrock:InvokeModelWithResponseStream"
],
"Resource": "*"
}
]
}
```
## Dokumentation
Weitere Informationen finden Sie unter:
+ [CloudWatch Dokumentation zu Application Signals](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Monitoring-Intro.html) — Erfahren Sie mehr über CloudWatch die Funktionen und Möglichkeiten von Application Signals
+ [Öffentliche Dokumentation zur Anwendungsbeobachtung für AWS Action](https://github.com/marketplace/actions/application-observability-for-aws) — ausführliche Anleitungen und Tutorials
# Beispiel: Application Signals verwenden, um ein Problem mit dem Betriebsstatus zu beheben
Das folgende Szenario bietet ein Beispiel dafür, wie Application Signals verwendet werden kann, um Ihre Services zu überwachen und Probleme mit der Servicequalität zu identifizieren. Gehen Sie ins Detail, um mögliche Ursachen zu ermitteln und Maßnahmen zur Behebung des Problems zu ergreifen. Dieses Beispiel konzentriert sich auf eine Anwendung für Tierkliniken, die aus mehreren Microservices besteht, die AWS-Services beispielsweise DynamoDB aufrufen.
Jane ist Teil eines DevOps Teams, das den Betrieb einer Anwendung für Tierkliniken überwacht. Janes Team setzt sich dafür ein, dass die Anwendung hochverfügbar und reaktionsschnell ist. Sie verwenden [Service Level Objectives (SLOs)](CloudWatch-ServiceLevelObjectives.md), um die Anwendungsleistung anhand dieser geschäftlichen Verpflichtungen zu messen. Sie erhält eine Warnung über mehrere fehlerhafte Service-Level-Indikatoren (SLIs). Sie öffnet die CloudWatch Konsole und navigiert zur Seite Dienste, auf der sie mehrere Dienste in einem fehlerhaften Zustand sieht.
![\[Dienste mit fehlerhaftem Zustand SLIs\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/example-scenario-services-page.jpg)
Oben auf der Seite sieht Jane, dass `visits-service` der Service mit der höchsten Fehlerrate ist. Sie wählt den Link im Diagramm aus, wodurch die Seite mit den Service-Details für den Service geöffnet wird. Sie stellt fest, dass in der Tabelle mit den Service-Vorgängen ein fehlerhafter Vorgang vorliegt. Sie wählt diesen Vorgang aus und sieht im Volumen- und Verfügbarkeitsdiagramm, dass es periodische Spitzen im Aufrufvolumen gibt, die mit Verfügbarkeitseinbrüchen zu korrelieren scheinen.
![\[Umfang und Verfügbarkeit des Servicebetriebs\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/example-scenario-unhealthy-operation.png)
Um sich die Einbrüche der Serviceverfügbarkeit genauer anzusehen, wählt Jane einen der Verfügbarkeits-Datenpunkte im Diagramm aus. Es öffnet sich eine Leiste mit X-Ray-Traces, die mit dem ausgewählten Datenpunkt korreliert sind. Sie sieht, dass es mehrere Traces gibt, die Fehler enthalten.
![\[Verfügbarkeit der Servcies und damit verbundene Traces\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/example-scenario-correlated-traces.jpg)
Jane wählt eine der korrelierten Traces mit einem Fehlerstatus aus, wodurch die X-Ray-Trace-Detailseite für das ausgewählte Trace geöffnet wird. Jane scrollt nach unten zum Abschnitt Segment-Timeline und folgt dem Aufrufpfad, bis sie feststellt, dass Aufrufe einer DynamoDB-Tabelle Fehler zurückgeben. Sie wählt das DynamoDB-Segment aus und navigiert zur Ausnahmen-Registerkarte in der rechten Leiste.
![\[Trace-Segment mit DynamoDB-Fehlern\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/example-scenario-DDB-segment.jpg)
Jane stellt fest, dass eine DynamoDB-Ressource falsch konfiguriert ist, was bei hohen KundenAnforderungen zu Fehlern führt. Der in der DynamoDB-Tabelle bereitgestellte Durchsatz wird regelmäßig überschritten, was zu Problemen mit der Dienstverfügbarkeit und zu Störungen der Serviceverfügbarkeit führt. SLIs Auf der Grundlage dieser Informationen ist ihr Team in der Lage, einen höheren Bereitstellungsdurchsatz zu konfigurieren und eine hohe Verfügbarkeit der Anwendung sicherzustellen.
# Beispiel: Verwenden Sie Anwendungssignale, um Fehler bei generativen KI-Anwendungen zu beheben, die mit Amazon Bedrock Modellen interagieren
Sie können Anwendungssignale verwenden, um Fehler bei Ihren generativen KI-Anwendungen zu beheben, die mit Amazon Bedrock Modellen interagieren. Application Signals optimiert diesen Prozess, indem es out-of-the-box Telemetriedaten bereitstellt und so tiefere Einblicke in die Interaktionen Ihrer Anwendung mit LLM-Modellen bietet. Das ist unter anderem für folgende Anwendungsfälle hilfreich:
+ Probleme mit der Konfiguration von Modellen
+ Kosten der Modellnutzung
+ Modell-Latenz
+ Generierung von Modellantworten wurde beendet
[Durch die Aktivierung von Anwendungssignalen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Signals-Enable.html) mit LLM/GenAI Observability erhalten Sie in Echtzeit Einblick in die Interaktionen Ihrer Anwendung mit den Amazon Bedrock-Services. Application Signals generiert automatisch Leistungskennzahlen und Traces für Amazon Bedrock API-Aufrufe und korreliert diese.
Application Signals unterstützt derzeit die folgenden LLM-Modelle in Amazon Bedrock.
+ AI21 Jamba
+ Amazon Titan
+ Anthropic Claude
+ Cohere Command
+ Meta Llama
+ Mistral AI
+ Nova
## Detaillierte Metriken und Traces
Für jeden Amazon Bedrock API-Aufruf generiert Application Signals detaillierte Leistungskennzahlen auf Ressourcenebene, darunter:
+ Modell-ID
+ Integritätsschutz-ID
+ Wissensdatenbank-ID
+ Bedrock-Agent-ID
Darüber hinaus bieten korrelierte Trace-Spans auf derselben Ebene einen umfassenden Überblick über die Ausführung von Anforderungen und ihre Abhängigkeiten.
![\[Leistungsmetriken unter Verwendung von Application Signals\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/AppSignalsAIExample.png)
## OpenTelemetry Unterstützung von GenAI-Attributen
Application Signals generiert die folgenden GenAI-Attribute für Amazon Bedrock API-Aufrufe mit OpenTelemetry semantischer Konvention. Diese Attribute helfen bei der Analyse der Modellnutzung, der Kosten und der Antwortqualität und können über die [Transaktionssuche](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Transaction-Search.html) genutzt werden, um tiefere Einblicke zu erhalten.
+ gen\$1ai.system
+ gen\$1ai.request.model
+ gen\$1ai.request.max\$1tokens
+ gen\$1ai.request.temperature
+ gen\$1ai.request.top\$1p
+ gen\$1ai.usage.input\$1tokens
+ gen\$1ai.usage.output\$1tokens
+ gen\$1ai.response.finish\$1reasons
![\[GenAI-Attribute unter Verwendung von Application Signals\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/AppSignalsAIExample_1.png)
Sie können beispielsweise die Analysefunktionen der Transaktionssuche verwenden, um die Token-Nutzung und die Kosten verschiedener LLM-Modelle für denselben Prompt zu vergleichen, was eine kosteneffiziente Modellauswahl ermöglicht.
![\[GenAI-Attribute unter Verwendung von Application Signals\]](http://docs.aws.amazon.com/de_de/AmazonCloudWatch/latest/monitoring/images/AppSignalsAIExample_2.png)
Weitere Informationen finden Sie unter [Verbessern Sie die Amazon Bedrock Beobachtbarkeit mit CloudWatch ](https://aws.amazon.com/blogs/mt/improve-amazon-bedrock-observability-with-amazon-cloudwatch-appsignals/) Anwendungssignalen.