

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.

# Überwachen Sie Serviceereignisse
<a name="CloudWatch-Application-Signals-ServiceEvents"></a>

Service Events bietet automatische detaillierte Beobachtbarkeit für Dienste, die mit CloudWatch Anwendungssignalen überwacht werden. Es erfasst Fehlermetriken, Leistungsdaten auf Funktionsebene, Momentaufnahmen von Vorfällen (wenn Anfragen Latenzschwellenwerte überschreiten oder Ausnahmen auslösen) und Bereitstellungsereignisse — ohne zusätzliche Codeänderungen.

## So funktionieren Serviceereignisse
<a name="Application-Signals-ServiceEvents-HowItWorks"></a>

Service Events erfasst die folgenden Arten von Signalen von Ihren instrumentierten Diensten:
+ **Fehlermetriken ** — Anzahl und Häufigkeit der Per-exception-type Fehler für jeden Vorgang, anhand derer Sie ermitteln können, welche Ausnahmen am häufigsten auftreten und am häufigsten auftreten.
+ **Function-call Metriken ** — Anzahl der Aufrufe, Dauer und Fehlerraten für einzelne Funktionen in Ihrem Anwendungscode.
+ **Momentaufnahmen von Vorfällen ** — Detaillierte Aufzeichnungen, die ausgelöst werden, wenn eine Anforderung einen Latenzschwellenwert überschreitet oder eine Ausnahme auslöst, einschließlich Stack-Traces, Aufrufstrukturen, Anruferdetails und Betriebskontext.
+ **Bereitstellungsereignisse ** — Markierungen, die beim Start der Anwendung und alle 24 Stunden ausgegeben werden und die Codebereitstellungen mit Änderungen im Dienstverhalten korrelieren. Die Anwendung gibt automatisch Bereitstellungsereignisse aus. Durch die Bereitstellung von Deployment-Metadaten (Git Commit, Deployment-ID) werden diese Ereignisse mit zusätzlichem Kontext angereichert.

Service Events wird automatisch aktiviert, wenn Sie CloudWatch Application Signals für Ihren Service aktivieren. Fehlermetriken und Ausnahme-Tracking sind sofort aktiv. Function-call Für Metriken ist eine zusätzliche Konfiguration erforderlich. Sie müssen die Pakete für die Instrumente konfigurieren, bevor Daten zu Funktionsaufrufen erfasst werden (siehe[Aktivieren Sie die Funktionsinstrumentierung](#Application-Signals-ServiceEvents-Configure-Function)). Service Events können durch eine Einstellung deaktiviert werden. `OTEL_AWS_SERVICE_EVENTS_ENABLED=false` Daten fließen vom ADOT SDK zum CloudWatch Agenten. Der Agent veröffentlicht Ereignisse in CloudWatch Logs (`/aws/service-events/{{service-name}}`Loggruppen) und CloudWatch Metriken.

Unterstützte Sprachen: Java, Python und Node.js.

**Anmerkung**  
Service Events wird in Lambda-Umgebungen automatisch deaktiviert.

## Datenspeicher
<a name="Application-Signals-ServiceEvents-DataStorage"></a>

Service Events speichert Daten in CloudWatch Protokollen. CloudWatch veröffentlicht Serviceereignisdaten in einer Protokollgruppe mit dem Präfix`/aws/application-signals/{{service-name}}`, wobei der Wert Ihrer `OTEL_SERVICE_NAME` Umgebungsvariablen {{service-name}} ist. Pro Dienst wird eine Protokollgruppe erstellt.

Das Aufnehmen und Speichern von Protokollen wird Ihnen zu den CloudWatch Standardtarifen für Protokolle in Rechnung gestellt.

## Fehler in der Konsole anzeigen
<a name="Application-Signals-ServiceEvents-Errors"></a>

Navigieren Sie in der CloudWatch Konsole zu ** Application Signals**, wählen Sie Ihren Service aus und wählen Sie dann die ** Registerkarte ** Fehler. Auf dieser Registerkarte werden Ausnahmemetriken für Ihren Service angezeigt.

Auf der Registerkarte wird Folgendes angezeigt:
+ Ein Diagramm zur Anzahl der Ausnahmen, das die Fehlertrends im Zeitverlauf zeigt. Verwenden Sie dieses Diagramm, um zu ermitteln, welche Ausnahmetypen sich in letzter Zeit in ihrer Häufigkeit geändert haben.
+ Eine Tabelle, in der jeder Ausnahmetyp, der Vorgang, bei dem er aufgetreten ist, die Anzahl der Vorkommnisse und die Änderung gegenüber der Vorperiode aufgeführt sind.

Wählen Sie eine Ausnahme aus, um detaillierte Informationen wie den Stack-Trace, die Ausnahmemeldung und einen Link zum zugehörigen Trace anzuzeigen.

Die Fehler werden nach Operation, Ausnahmetyp und Top-Stack-Frames gruppiert. Nur der neueste Vertreter jeder Gruppe wird angezeigt.

**Anmerkung**  
Um Fehlerdaten anzeigen zu können, muss mindestens eine `/aws/service-events/{{service-name}}` Protokollgruppe in Ihrem Konto vorhanden sein. Wenn keine Protokollgruppen vorhanden sind, wird auf der Registerkarte „Fehler“ eine Eingabeaufforderung angezeigt.

## Serviceereignisse in Protokollen anzeigen
<a name="Application-Signals-ServiceEvents-Logs"></a>

Daten zu Serviceereignissen werden in CloudWatch Protokollen unter Protokollgruppen mit dem Präfix gespeichert`/aws/service-events/{{service-name}}`. Sie können diese Daten direkt mithilfe von CloudWatch Logs Insights abfragen, um benutzerdefinierte Ansichten zu erstellen, Dashboards zu erstellen oder bestimmte Vorfälle zu untersuchen.

So fragen Sie Serviceereignisse ab:

1. Öffnen Sie die CloudWatch Konsole und navigieren Sie zu ** Logs Insights**.

1. Wählen Sie die Protokollgruppe `/aws/service-events/{{service-name}}` für Ihren Service aus.

1. Geben Sie eine Abfrage ein, um die Daten zu Serviceereignissen zu filtern und zu analysieren.

## Serviceereignisse auf dem CloudWatch Application Signals MCP (Model Context Protocol) -Server
<a name="Application-Signals-ServiceEvents-MCP"></a>

Auf Daten zu Serviceereignissen kann über den CloudWatch Application Signals MCP-Server (Model Context Protocol) zugegriffen werden, sodass KI-Codierungsassistenten und -Agenten das Laufzeitverhalten Ihres Dienstes direkt abfragen können.

**Fehlersuche**
+ Korrelieren Sie Fehler in Ihrem Code automatisch mit Snapshots von Produktionsvorfällen, einschließlich vollständiger Stack-Traces und betroffener Endpunkte.
+ Verwenden Sie den Kontext des Vorfalls (Ausnahmetypen, Aufrufpfade, Trace-IDs), um gezielte Lösungen vorzuschlagen, ohne dass Sie manuell in Dashboards navigieren müssen.
+ Rufen Sie Bereitstellungsereignisse ab, um festzustellen, ob in einer aktuellen Version eine Regression eingeführt wurde.

**Verbesserung der Leistung **
+ Fragen Sie Leistungsdaten auf Funktionsebene ab, um Engpässe bei der Untersuchung von Latenzproblemen zu identifizieren.
+ Vergleichen Sie die Dauer von Funktionsaufrufen in verschiedenen Bereitstellungen, um Leistungsrückgänge zu ermitteln.

Anweisungen zur Einrichtung und Verwendung finden Sie auf dem [ Application Signals MCP-Server auf der Website. ](https://awslabs.github.io/mcp/servers/cloudwatch-applicationsignals-mcp-server) GitHub 

## Konfigurieren Sie Serviceereignisse
<a name="Application-Signals-ServiceEvents-Configure"></a>

### Voraussetzungen
<a name="Application-Signals-ServiceEvents-Configure-Prerequisites"></a>

Um Service Events verwenden zu können, stellen Sie sicher, dass Sie über die erforderlichen Mindestversionen der folgenden Komponenten verfügen:

1. **Aktualisieren Sie das ADOT SDK ** — Aktualisieren Sie das AWS Distro for OpenTelemetry (ADOT) Instrumentation SDK auf die neueste Version für Ihre Sprache (Java, Python oder). Node.js

1. **Aktualisieren Sie das Amazon EKS-Add-on (falls zutreffend) ** — Wenn Sie das CloudWatch Observability Amazon EKS-Add-on zur Instrumentierung Ihrer Anwendungen verwenden, aktualisieren Sie das Add-on auf die neueste Version.

1. **Den CloudWatch Agenten aktualisieren ** — Aktualisieren Sie den CloudWatch Agenten auf Version `1.300069.0` oder höher.

Wenn Sie Amazon EKS verwenden, finden Sie Anweisungen [Anwendungen auf Amazon-EKS-Clustern aktivieren](CloudWatch-Application-Signals-Enable-EKS.md) zur Einrichtung des Add-Ons.

### Funktionen sind standardmäßig aktiviert
<a name="Application-Signals-ServiceEvents-Configure-Defaults"></a>

Wenn Sie CloudWatch Anwendungssignale verwenden, sind die folgenden Signale für Serviceereignisse standardmäßig ** aktiviert, ** ohne dass eine zusätzliche Konfiguration erforderlich ist:
+ Snapshots von Vorfällen (ausgelöst bei Ausnahmen und Verstößen gegen den Latenzschwellenwert)
+ Fehlermetriken (Anzahl der Fehler pro Ausnahmetyp pro Vorgang)
+ Bereitstellungsereignisse (werden immer ausgegeben; angereichert, wenn Sie Bereitstellungsmetadaten angeben)
+ Funktionsinstrumentation (standardmäßig aktiviert, erzeugt aber keine Metriken, bis Sie die Pakete für die Instrumentierung konfigurieren)

Die folgenden Funktionen sind ** optional ** und erfordern das Setzen von Umgebungsvariablen, um Daten zu erzeugen:
+ Function-level Metriken (muss konfiguriert `OTEL_AWS_SERVICE_EVENTS_PACKAGES_INCLUDE` werden)
+ Benutzerdefinierte Endpunktfilterung
+ Per-endpoint Latenz-Schwellenwerte

### Allgemeine Einstellungen
<a name="Application-Signals-ServiceEvents-Configure-General"></a>


| Umgebungsvariable | Standard | Description | 
| --- | --- | --- | 
| OTEL\_AWS\_SERVICE\_EVENTS\_ENABLED | Folgt CloudWatch Anwendungssignalen | Schalten Sie die Option „Serviceereignisse“ ein. Service Events wird automatisch aktiviert, wenn CloudWatch Application Signals aktiviert ist. Auf setzen, false um es explizit zu deaktivieren. | 
| OTEL\_AWS\_SERVICE\_EVENTS\_SAMPLING\_MODE | always | Steuert die Strategie zur Datenerfassung bei Funktionsaufrufen. Werte: always (zeichnet alle Funktionsaufrufe auf), auto (lässt das SDK anhand der Auslastung entscheiden), never (deaktiviert die Aufzeichnung von Funktionsaufrufen). Gilt nur, wenn Funktionsinstrumentationspakete konfiguriert sind. | 

### Aktivieren Sie die Funktionsinstrumentierung
<a name="Application-Signals-ServiceEvents-Configure-Function"></a>

Die Funktionsinstrumentierung ist standardmäßig aktiviert, aber sie erzeugt keine Metriken, bis Sie konfigurieren, welche Pakete instrumentiert werden sollen. Stellen Sie eine Liste der zulässigen Pakete bereit, um mit der Erfassung der Telemetriedaten pro Funktion zu beginnen:


| Umgebungsvariable | Standard | Description | 
| --- | --- | --- | 
| OTEL\_AWS\_SERVICE\_EVENTS\_FUNCTION\_INSTRUMENT\_ENABLED | true | Aktiviert oder deaktiviert Instrumentierung auf Funktionsebene. Stellen Sie diese Option auf ein, um sie vollständig false zu deaktivieren. | 
| OTEL\_AWS\_SERVICE\_EVENTS\_PACKAGES\_INCLUDE | Keine (für Metriken erforderlich) | Comma-separated Liste der Paketpräfixe für das Instrument. Kein Platzhalter erforderlich. Zum Beispiel: Java verwendetcom.myapp, Python verwendetmyapp, Node.js verwendetsrc/myapp. | 
| OTEL\_AWS\_SERVICE\_EVENTS\_PACKAGES\_EXCLUDE | Keine | Comma-separated Liste der Unterpakete, die von der Instrumentierung ausgeschlossen werden sollen. Exclude hat immer Vorrang vor Include. Beispielsweise können Sie mithilfe von Include com.myapp und com.myapp.models Exclude Ihren Anwendungscode instrumentieren, Datenmodellklassen jedoch überspringen. | 

### Filterung von Endpunkten
<a name="Application-Signals-ServiceEvents-Configure-Endpoint"></a>

Die Endpunktfilterung steuert, welche Endpunkte Endpunktfehlermetriken und Vorfall-Snapshots generieren. Diese Einstellungen wirken sich nicht auf die Funktionsinstrumentierung aus.


| Umgebungsvariable | Standard | Description | 
| --- | --- | --- | 
| OTEL\_AWS\_SERVICE\_EVENTS\_ENDPOINT\_INCLUDE\_PATTERNS | Alle Endpunkte | Comma-separated Glob-Muster der einzuschließenden Endpunkte. Abgestimmt gegen. METHOD /route | 
| OTEL\_AWS\_SERVICE\_EVENTS\_ENDPOINT\_EXCLUDE\_PATTERNS | Keine | Comma-separated Glob-Muster der auszuschließenden Endpunkte. Ausschließen hat Vorrang, wenn ein Endpunkt beiden entspricht. | 

### Latenz-Schwellenwerte
<a name="Application-Signals-ServiceEvents-Configure-Latency"></a>

Verwenden Sie die folgenden Umgebungsvariablen, um Latenzschwellenwerte für Incident-Snapshot-Trigger zu konfigurieren.


| Umgebungsvariable | Standard | Description | 
| --- | --- | --- | 
| OTEL\_AWS\_SERVICE\_EVENTS\_INCIDENT\_SNAPSHOT\_DURATION\_THRESHOLD\_MS | 5000 | Globaler Latenzschwellenwert in Millisekunden. Anfragen, die diese Dauer überschreiten, lösen einen Snapshot des Vorfalls aus. | 
| OTEL\_AWS\_SERVICE\_EVENTS\_LATENCY\_THRESHOLDS | Keine | Per-endpoint Latenzschwellenwerte, die den globalen Standard außer Kraft setzen. Format: METHOD /route:ms (zum BeispielGET /health:200,POST /checkout:8000). | 

### Ratenbegrenzung
<a name="Application-Signals-ServiceEvents-Configure-RateLimit"></a>

Verwenden Sie die folgenden Umgebungsvariablen, um die Rate zu steuern, mit der Daten zu Serviceereignissen erfasst und gemeldet werden.


| Umgebungsvariable | Standard | Description | 
| --- | --- | --- | 
| OTEL\_AWS\_SERVICE\_EVENTS\_INCIDENT\_SNAPSHOT\_MAX\_PER\_MINUTE | 100 | Maximale Anzahl von Snapshots von Vorfällen, die pro Minute erfasst werden. | 
| OTEL\_AWS\_SERVICE\_EVENTS\_INCIDENT\_SNAPSHOT\_MAX\_SAME\_ERROR | 1 | Maximale Anzahl von Schnappschüssen für denselben Fehler pro Erfassungsfenster. | 

## Konfigurieren Sie Bereitstellungsereignisse
<a name="Application-Signals-ServiceEvents-DeploymentEvents"></a>

Bereitstellungsereignisse werden immer beim Start der Anwendung und alle 24 Stunden ausgelöst. Durch die Bereitstellung von Bereitstellungsmetadaten werden diese Ereignisse angereichert, sodass Sie Vorfälle und Leistungsänderungen bestimmten Codebereitstellungen zuordnen können.

Stellen Sie die folgenden Umgebungsvariablen in Ihren Anwendungscontainern oder Prozessen ein, um Bereitstellungsmetadaten bereitzustellen:


| Umgebungsvariable | Description | 
| --- | --- | 
| OTEL\_AWS\_SERVICE\_EVENTS\_GIT\_COMMIT\_SHA | Git Commit SHA des bereitgestellten Codes. | 
| OTEL\_AWS\_SERVICE\_EVENTS\_GIT\_REPO\_URL | URL des Git-Repositorys. | 
| OTEL\_AWS\_SERVICE\_EVENTS\_DEPLOYMENT\_ID | Eindeutiger Bezeichner für die Bereitstellung (z. B. eine CI/CD Pipeline-Run-ID). | 
| OTEL\_AWS\_SERVICE\_EVENTS\_DEPLOYMENT\_TIMESTAMP | ISO 8601-Zeitstempel der Bereitstellung. | 
| OTEL\_AWS\_SERVICE\_EVENTS\_DEPLOYMENT\_URL | URL des Deployment-Builds oder der Pipeline-Ausführung. | 

### Konfigurieren Sie Bereitstellungsereignisse mit GitHub Aktionen
<a name="Application-Signals-ServiceEvents-DeploymentEvents-GitHub"></a>

Verwenden Sie in Ihrem GitHub Aktionsworkflow die integrierten Umgebungsvariablen, um Bereitstellungsmetadaten zu füllen. Fügen Sie Ihrem Bereitstellungsschritt oder Ihrer Container-Umgebung Folgendes hinzu:

```
env:
  OTEL_AWS_SERVICE_EVENTS_GIT_COMMIT_SHA: ${{ github.sha }}
  OTEL_AWS_SERVICE_EVENTS_GIT_REPO_URL: ${{ github.server_url }}/${{ github.repository }}
  OTEL_AWS_SERVICE_EVENTS_DEPLOYMENT_ID: ${{ github.run_id }}
  OTEL_AWS_SERVICE_EVENTS_DEPLOYMENT_TIMESTAMP: $(date -u +%Y-%m-%dT%H:%M:%SZ)
  OTEL_AWS_SERVICE_EVENTS_DEPLOYMENT_URL: ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}
```

Wenn Sie Container-Images bereitstellen, übergeben Sie diese Werte als Umgebungsvariablen in Ihrer Aufgabendefinition oder Pod-Spezifikation. Sie können sie bei der Erstellung in das Image integrieren oder sie bei der Bereitstellung über Ihre Bereitstellungskonfiguration einfügen.

### Konfigurieren Sie Bereitstellungsereignisse mit GitLab CI/CD
<a name="Application-Signals-ServiceEvents-DeploymentEvents-GitLab"></a>

Verwenden Sie in Ihrer GitLab CI/CD Pipeline die vordefinierten CI/CD Variablen, um Deployment-Metadaten aufzufüllen. Fügen Sie Ihrem Bereitstellungsauftrag Folgendes hinzu:

```
deploy:
  variables:
    OTEL_AWS_SERVICE_EVENTS_GIT_COMMIT_SHA: $CI_COMMIT_SHA
    OTEL_AWS_SERVICE_EVENTS_GIT_REPO_URL: $CI_PROJECT_URL
    OTEL_AWS_SERVICE_EVENTS_DEPLOYMENT_ID: $CI_PIPELINE_ID
    OTEL_AWS_SERVICE_EVENTS_DEPLOYMENT_TIMESTAMP: $(date -u +%Y-%m-%dT%H:%M:%SZ)
    OTEL_AWS_SERVICE_EVENTS_DEPLOYMENT_URL: $CI_PIPELINE_URL
```

Übergeben Sie diese Variablen bei der Bereitstellung über Ihre Container-Orchestrierungsplattform an Ihre Anwendungscontainer (z. B. als Umgebungsvariablen in Ihrer Amazon ECS-Aufgabendefinition oder Ihrem Kubernetes-Bereitstellungsmanifest).