

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.

# Beobachtbarkeit in Amazon Service OpenSearch
<a name="observability"></a>

Unter Observabilität versteht man das Verständnis des internen Zustands und der Leistung komplexer Systeme durch die Untersuchung ihrer Ergebnisse. Herkömmliche Überwachung zeigt Ihnen, dass ein System ausgefallen ist. Observability hilft Ihnen zu verstehen, warum das so ist, indem Sie neue Fragen zu Ihren Telemetriedaten stellen können.

## Was Amazon OpenSearch Service bietet
<a name="observability-what"></a>

Amazon OpenSearch Service bietet eine einheitliche Observability-Lösung, indem es drei Arten von Telemetriedaten sammelt, korreliert und visualisiert:
+ **Protokolle — Aufzeichnungen von** Ereignissen mit Zeitstempel.
+ **Spuren** — Verlauf End-to-end von Anfragen über verteilte Dienste.
+ **Metriken** — Zeitreihendaten zur Darstellung des Systemzustands mithilfe der direkten Abfrageintegration von Amazon Managed Service für Prometheus.

Indem Amazon Service diese in einer einzigen Oberfläche zusammenführt, hilft Amazon OpenSearch Service Betriebsteams und Entwicklern SREs, Probleme schneller zu erkennen, zu diagnostizieren und zu lösen.

## Der Amazon OpenSearch Service-Ansatz für Observability
<a name="observability-approach"></a>

Amazon OpenSearch Service unterscheidet sich in drei wesentlichen Punkten:
+ **OpenTelemetry-nativ mit OpenSearch Ingestion als letzter Meile — Standardisieren Sie die** Instrumentierung und Erfassung. OTel Amazon OpenSearch Ingestion dient als vollständig verwaltete Pipeline, die Ihre Telemetriedaten vor der Indizierung filtert, anreichert, transformiert und weiterleitet.
+ **Vereinheitlichte Protokolle, Traces und Metriken in der OpenSearch Benutzeroberfläche** — Analysieren Sie alle drei Signaltypen von einem einzigen Observability-Workspace aus. Korrelieren Sie einen Slow-Trace mit den zugehörigen Anwendungsprotokollen oder überlagern Sie Ihre Service-Dashboards mit Prometheus-Metriken.
+ **Zielgerichtete Abfragesprachen** — Verwenden Sie [Piped Processing Language (PPL) für Logs und Traces und PromQL für Metriken](https://observability.opensearch.org/docs/ppl/). Jede Sprache ist für ihren Signaltyp optimiert, sodass Sie ausdrucksstarke Abfragen ohne Kompromisse durchführen können.

![\[alt text not found\]](http://docs.aws.amazon.com/de_de/opensearch-service/latest/developerguide/images/otel-sdk-service.png)


**Anmerkung**  
Die in diesem Abschnitt beschriebenen Observability-Funktionen sind nur in OpenSearch der Benutzeroberfläche verfügbar. Sie sind in OpenSearch Dashboards nicht verfügbar. Für neue Observability-Workloads empfehlen wir, einen Workspace [Verwenden der OpenSearch Benutzeroberfläche in Amazon OpenSearch Service](application.md) mit Observability-Workspace einzurichten.

# Erste Schritte
<a name="observability-get-started"></a>

Starten Sie Ihren Observability-Stack AWS und beginnen Sie innerhalb von Minuten mit dem Senden von Telemetriedaten.

## Schnellstart
<a name="observability-get-started-quick"></a>

Der schnellste Weg, einen end-to-end Observability-Stack bereitzustellen, AWS ist das CLI-Installationsprogramm. Er erstellt die folgenden Ressourcen:
+ Eine Amazon OpenSearch Service-Domain
+ Ein Amazon Managed Service für Prometheus Workspace
+ Eine Amazon OpenSearch Ingestion-Pipeline
+ Eine OpenSearch UI-Anwendung mit einem Observability-Workspace

Optional startet das Installationsprogramm eine EC2-Instance mit der OpenTelemetry Demo für Beispieltelemetrie.

Führen Sie den folgenden Befehl aus, um die Installation zu starten:

```
bash -c "$(curl -fsSL https://raw.githubusercontent.com/opensearch-project/observability-stack/main/install.sh)" -- --deployment-target=aws
```

Die Installation dauert ungefähr 15 Minuten.

## CDK-Bereitstellung
<a name="observability-get-started-cdk"></a>

Verwenden Sie für infrastructure-as-code AWS CDK. Bei der CDK-Bereitstellung werden zwei Stapel erstellt:


| Stack | Was es erzeugt | Bereitstellungszeit | 
| --- | --- | --- | 
| ObsInfra | OpenSearch Domäne, Amazon Managed Service für Prometheus Workspace, direkte Abfrage-Datenquelle, Pipeline-IAM-Rolle | \$117 Minuten | 
| ObservabilityStack | Präzise Zuordnung der Zugriffskontrolle, OpenSearch Ingestion-Pipeline, OpenSearch UI-Anwendung, Dashboard-Initialisierung, Demo-Workload (optional) | \$16 Minuten | 

Führen Sie zur Bereitstellung die folgenden Befehle aus:

```
cd aws/cdk
npm install
cdk deploy --all
```

Weitere Informationen finden Sie in der [README-Datei zur CDK-Bereitstellung](https://github.com/opensearch-project/observability-stack/tree/main/aws/cdk) unter. GitHub

## Telemetrie wird gesendet
<a name="observability-get-started-send"></a>

Beide Bereitstellungsmethoden erstellen einen OpenSearch Aufnahmeendpunkt, der OTLP-Daten akzeptiert. Konfigurieren Sie Ihren OTel Collector für den Export mithilfe der SigV4-Authentifizierung:

```
extensions:
  sigv4auth:
    region: us-west-2
    service: osis

exporters:
  otlphttp/logs:
    logs_endpoint: ${OSIS_ENDPOINT}/v1/logs
    auth: { authenticator: sigv4auth }
    compression: none
  otlphttp/traces:
    traces_endpoint: ${OSIS_ENDPOINT}/v1/traces
    auth: { authenticator: sigv4auth }
    compression: none
  otlphttp/metrics:
    metrics_endpoint: ${OSIS_ENDPOINT}/v1/metrics
    auth: { authenticator: sigv4auth }
    compression: none
```

**Anmerkung**  
Der IAM-Principal, der Daten sendet, benötigt `osis:Ingest` und `aps:RemoteWrite` genehmigt den Pipeline-ARN.

## Weitere Informationen
<a name="observability-get-started-learn-more"></a>

Verwenden Sie die folgenden Ressourcen, um mehr über das Senden von Telemetriedaten zu erfahren:
+ [OpenTelemetry Leitfäden zur Instrumentierung (pro Sprache)](https://observability.opensearch.org/docs/send-data/applications/)
+ [Infrastrukturüberwachung (AWS, Docker, Kubernetes, Prometheus)](https://observability.opensearch.org/docs/send-data/infrastructure/)
+ [OTel Collector-Konfiguration](https://observability.opensearch.org/docs/send-data/opentelemetry/collector/)
+ [Datenpipeline und Batching](https://observability.opensearch.org/docs/send-data/data-pipeline/)
+ [Überblick über Amazon OpenSearch Ingestion](ingestion.md) in dieser Anleitung

# Anwendungstelemetrie aufnehmen
<a name="observability-ingestion"></a>

Um die Observability-Funktionen in Amazon OpenSearch Service nutzen zu können, müssen Sie Anwendungs-Traces, Protokolle und Metriken aufnehmen. Auf dieser Seite wird die Konfiguration der OpenTelemetry Collector- und OpenSearch Ingestion-Pipelines zur Verarbeitung und Weiterleitung von Telemetriedaten an Amazon Managed Service for OpenSearch Prometheus beschrieben.

## OpenTelemetry Konfiguration des Collectors
<a name="observability-ingestion-otel"></a>

Der Collector OpenTelemetry (OTel) ist der Einstiegspunkt für die gesamte Anwendungstelemetrie. Es empfängt Daten über OTLP und leitet Traces und Logs an OpenSearch Ingestion weiter, während es Metriken an Prometheus sendet.

Sie können den OTel Collector mit einem der folgenden Ansätze konfigurieren:

Der OTel Collector exportiert mithilfe der SigV4-Authentifizierung Traces und Logs an einen OpenSearch Ingestion-Endpunkt und mithilfe des Prometheus Remote Write Exporter Metriken an Amazon Managed Service for Prometheus. OpenSearch Ingestion kümmert sich um die Verarbeitung, Anreicherung und Weiterleitung an. OpenSearch

### OTel Collector-Konfiguration mit Ingestion OpenSearch
<a name="observability-ingestion-otel-osis"></a>

Die folgende Beispielkonfiguration verwendet die SigV4-Authentifizierung, um Traces und Logs an einen OpenSearch Ingestion-Endpunkt und Metriken an Prometheus zu exportieren:

```
extensions:
  sigv4auth:
    region: us-west-2
    service: osis

exporters:
  otlphttp/osis-traces:
    traces_endpoint: ${OSIS_ENDPOINT}/v1/traces
    auth: { authenticator: sigv4auth }
    compression: none
  otlphttp/osis-logs:
    logs_endpoint: ${OSIS_ENDPOINT}/v1/logs
    auth: { authenticator: sigv4auth }
    compression: none
  # Amazon Managed Service for Prometheus via Prometheus Remote Write with SigV4 auth
  prometheusremotewrite/amp:
    endpoint: "https://aps-workspaces.region.amazonaws.com/workspaces/workspace-id/api/v1/remote_write"
    auth:
      authenticator: sigv4auth

service:
  extensions: [sigv4auth]
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/osis-traces]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/osis-logs]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [prometheusremotewrite/amp]
```

**Anmerkung**  
Der IAM-Principal, der Daten sendet, benötigt `osis:Ingest` und `aps:RemoteWrite` genehmigt den Pipeline-ARN.

## Konfiguration von OpenSearch Ingestion-Pipelines
<a name="observability-ingestion-pipelines"></a>

OpenSearch Ingestion (oder selbstverwalteter Data Prepper) empfängt Telemetriedaten vom OTel Collector und verarbeitet sie für die Überwachung der Anwendungsleistung (APM).

### Pipeline-Architektur
<a name="observability-ingestion-pipeline-arch"></a>

Die Pipeline verarbeitet Telemetriedaten in den folgenden Phasen:

1. Die Eingangspipeline empfängt alle Telemetriedaten und leitet Protokolle und Traces an separate Sub-Pipelines weiter.

1. Die Protokollpipeline schreibt Protokolldaten OpenSearch unter Verwendung des `log-analytics-plain` Indextyps.

1. Die Trace-Pipeline verteilt die Spans auf die Rohspeicher-Pipeline und die Service Map-Pipeline.

1. Die unbearbeiteten Trace-Pipeline-Prozesse erstrecken sich über den `otel_traces` Prozessor und speichern sie im `trace-analytics-plain-raw` Indextyp.

1. Die Service Map-Pipeline verwendet den `otel_apm_service_map` Prozessor, um Topologie- und RED-Metriken (Rate, Errors, Duration) zu generieren. Es schreibt per Fernschreiben zu OpenSearch und zu Prometheus.

### Pipeline-Konfiguration
<a name="observability-ingestion-pipeline-config"></a>

Das folgende Beispiel zeigt eine vollständige Pipeline-Konfiguration für OpenSearch Ingestion, die alle Arten von Beobachtbarkeitssignalen abdeckt — Logs, Traces und Metriken. Sie können alle Pipelines oder nur die Pipelines einbeziehen, die für Ihren Anwendungsfall relevant sind. Ersetzen Sie die *placeholder* Werte durch Ihre eigenen Informationen.

```
version: '2'

# Main OTLP pipeline - receives all telemetry and routes by signal type
otlp-pipeline:
  source:
    otlp:
      logs_path: '/pipeline-name/v1/logs'
      traces_path: '/pipeline-name/v1/traces'
      metrics_path: '/pipeline-name/v1/metrics'
  route:
    - logs: 'getEventType() == "LOG"'
    - traces: 'getEventType() == "TRACE"'
    - metrics: 'getEventType() == "METRIC"'
  processor: []
  sink:
    - pipeline:
        name: otel-logs-pipeline
        routes:
          - logs
    - pipeline:
        name: otel-traces-pipeline
        routes:
          - traces
    - pipeline:
        name: otel-metrics-pipeline
        routes:
          - metrics

# Log processing pipeline
otel-logs-pipeline:
  source:
    pipeline:
      name: otlp-pipeline
  processor:
    - copy_values:
        entries:
          - from_key: "time"
            to_key: "@timestamp"
  sink:
    - opensearch:
        hosts:
          - 'https://opensearch-endpoint'
        index_type: log-analytics-plain
        aws:
          serverless: false
          region: 'region'
          sts_role_arn: "arn:aws:iam::account-id:role/pipeline-role"

# Trace fan-out pipeline
otel-traces-pipeline:
  source:
    pipeline:
      name: otlp-pipeline
  processor: []
  sink:
    - pipeline:
        name: traces-raw-pipeline
        routes: []
    - pipeline:
        name: service-map-pipeline
        routes: []

# Raw trace storage pipeline
traces-raw-pipeline:
  source:
    pipeline:
      name: otel-traces-pipeline
  processor:
    - otel_traces:
  sink:
    - opensearch:
        hosts:
          - 'https://opensearch-endpoint'
        index_type: trace-analytics-plain-raw
        aws:
          serverless: false
          region: 'region'
          sts_role_arn: "arn:aws:iam::account-id:role/pipeline-role"

# Service map generation pipeline (APM)
service-map-pipeline:
  source:
    pipeline:
      name: otel-traces-pipeline
  processor:
    - otel_apm_service_map:
        group_by_attributes:
          - telemetry.sdk.language # Add any resource attribute to group by
        window_duration: 30s
  route:
    - otel_apm_service_map_route: 'getEventType() == "SERVICE_MAP"'
    - service_processed_metrics: 'getEventType() == "METRIC"'
  sink:
    - opensearch:
        hosts:
          - 'https://opensearch-endpoint'
        aws:
          serverless: false
          region: 'region'
          sts_role_arn: "arn:aws:iam::account-id:role/pipeline-role"
        routes:
          - otel_apm_service_map_route
        index_type: otel-v2-apm-service-map
    - prometheus:
        url: 'https://aps-workspaces.region.amazonaws.com/workspaces/workspace-id/api/v1/remote_write'
        aws:
          region: 'region'
        routes:
          - service_processed_metrics

# Metrics processing pipeline
otel-metrics-pipeline:
  source:
    pipeline:
      name: otlp-pipeline
  processor:
    - otel_metrics:
  sink:
    - prometheus:
        url: 'https://aps-workspaces.region.amazonaws.com/workspaces/workspace-id/api/v1/remote_write'
        aws:
          region: 'region'
```

## Die Einnahme wird überprüft
<a name="observability-ingestion-verify"></a>

Nachdem Sie den OTel Collector und die Pipelines konfiguriert haben, stellen Sie sicher, dass die Telemetriedaten korrekt übertragen werden.
+ ** OpenSearch Indizes überprüfen** — Stellen Sie sicher, dass die folgenden Indizes in Ihrer Domain vorhanden sind:`otel-v1-apm-span-*`, und. `otel-v2-apm-service-map` `logs-otel-v1-*`
+ **Prometheus-Ziele verifizieren** — Stellen Sie sicher, dass das Prometheus-Remote-Write-Ziel Metriken von der Service Map-Pipeline empfängt.
+ **In der OpenSearch Benutzeroberfläche verifizieren** — Navigieren Sie zu **Observability** und dann zu **Application Monitoring**, um zu überprüfen, ob Ihre Services angezeigt werden.

## Nächste Schritte
<a name="observability-ingestion-next"></a>

Nachdem Sie überprüft haben, ob Telemetriedaten aufgenommen wurden, sollten Sie sich mit den folgenden Themen befassen:
+ [Anwendungsüberwachung](observability-app-monitoring.md)— Überwachen Sie den Zustand von Anwendungen mithilfe von Service Maps und RED-Metriken.
+ [Spuren entdecken](observability-analyze-traces.md) — Entdecken und analysieren Sie verteilte Traces.
+ [Protokolle entdecken](observability-analyze-logs.md) — Anwendungsprotokolle entdecken und abfragen.
+ [Metriken entdecken](observability-metrics.md) — Entdecken und fragen Sie Prometheus-Metriken mit PromQL ab.

# Datensätze
<a name="observability-datasets"></a>

Datensätze sind Sammlungen von Indizes, die eine logische Gruppierung Ihrer Observability-Daten darstellen. Sie verwenden Datensätze, um Logs und Trace-Daten zu organisieren, sodass Sie verwandte Indizes in der Discover-Oberfläche gemeinsam abfragen und analysieren können. Jeder Datensatz ist einem oder mehreren Indizes in Ihrer OpenSearch Service-Domain zugeordnet und definiert den Datentyp, das Zeitfeld und die Abfragesprache für die Discover-Seite.

## Datensatztypen
<a name="observability-datasets-types"></a>

In der folgenden Tabelle werden die Datensatztypen beschrieben, die Sie erstellen können.


| Typ | Description | Sprache der Abfrage | 
| --- | --- | --- | 
| Protokolle | Gruppiert einen oder mehrere Protokollindizes zur Abfrage und Visualisierung auf der Seite Discover Logs. | PPL | 
| Ablaufverfolgungen | Gruppiert Trace-Span-Indizes für Abfragen und Visualisierungen auf der Seite Discover Traces. | PPL | 

**Anmerkung**  
Für Metriken ist kein Datensatz erforderlich, da Metrikdaten nicht in OpenSearch gespeichert sind. Metriken werden mit PromQL direkt von Amazon Managed Service for Prometheus abgefragt.

## Um einen Protokolldatensatz zu erstellen
<a name="observability-datasets-create-logs"></a>

Gehen Sie wie folgt vor, um einen Protokolldatensatz in der OpenSearch Benutzeroberfläche zu erstellen.

1. Erweitern Sie in Ihrem Observability-Workspace in der linken Navigationsleiste die Option **Discover** und wählen Sie **Logs** aus.

1. Wählen Sie **Datensatz erstellen**.

1. Wählen Sie eine Datenquelle aus der Liste der verfügbaren OpenSearch Dienstverbindungen aus.  
![\[alt text not found\]](http://docs.aws.amazon.com/de_de/opensearch-service/latest/developerguide/images/datasets/datasets-select-data-source.png)

1. Konfigurieren Sie den Datensatz, indem Sie einen Namen eingeben, den Index auswählen und das Zeitstempelfeld angeben.  
![\[alt text not found\]](http://docs.aws.amazon.com/de_de/opensearch-service/latest/developerguide/images/datasets/datasets-configure-logs.png)

1. Wählen Sie **Datensatz erstellen**, um die Konfiguration zu speichern.

## Um einen Traces-Datensatz zu erstellen
<a name="observability-datasets-create-traces"></a>

Gehen Sie wie folgt vor, um einen Traces-Datensatz in der OpenSearch Benutzeroberfläche zu erstellen.

1. Erweitern Sie in Ihrem Observability-Workspace in der linken Navigationsleiste die Option **Discover** und wählen Sie **Traces** aus.

1. Wählen Sie **Datensatz erstellen**.

1. Wählen Sie eine Datenquelle aus der Liste der verfügbaren OpenSearch Dienstverbindungen aus.

1. Konfigurieren Sie den Datensatz, indem Sie einen Namen eingeben, den Span-Index auswählen und das Timestamp-Feld angeben.  
![\[alt text not found\]](http://docs.aws.amazon.com/de_de/opensearch-service/latest/developerguide/images/datasets/datasets-configure-traces.png)

1. Wählen Sie **Datensatz erstellen**, um die Konfiguration zu speichern.

## Um Datensätze anzuzeigen
<a name="observability-datasets-view"></a>

Sie können alle konfigurierten Datensätze über die Datensatzauswahl auf der Seite Discover Logs oder Discover Traces anzeigen. Die Datensatzliste zeigt den Namen, den Typ, die Datenquelle und das Zeitstempelfeld für jeden Datensatz.

![\[alt text not found\]](http://docs.aws.amazon.com/de_de/opensearch-service/latest/developerguide/images/datasets/datasets-list.png)


## Analysieren von Datensätzen in Discover
<a name="observability-datasets-analyze"></a>

Nachdem Sie einen Datensatz erstellt haben, können Sie ihn auf der entsprechenden Discover-Seite analysieren.

### Protokolle
<a name="observability-datasets-analyze-logs"></a>

Wählen Sie in der Datensatzauswahl auf der Seite „Logs entdecken“ einen Protokolldatensatz aus, um Ihre Protokolldaten mithilfe von PPL abzufragen und zu visualisieren. Weitere Informationen finden Sie unter [Logs entdecken](observability-analyze-logs.md).

### Ablaufverfolgungen
<a name="observability-datasets-analyze-traces"></a>

Wählen Sie in der Datensatzauswahl auf der Seite „Discover Traces“ einen Traces-Datensatz aus, um Trace-Spans zu untersuchen, RED-Metriken einzusehen und einzelne Traces genauer zu untersuchen. Weitere Informationen finden Sie unter [Entdecke Spuren](observability-analyze-traces.md).

# Logs entdecken
<a name="observability-analyze-logs"></a>

Die Seite Discover Logs bietet eine spezielle Oberfläche für die Untersuchung und Analyse von Protokolldaten in Ihrem OpenSearch Service-Observability-Workspace. Sie können PPL-Abfragen schreiben, um Protokolldaten zu filtern und zu aggregieren, Visualisierungen direkt aus Abfrageergebnissen erstellen und diese Visualisierungen zu Dashboards hinzufügen. Die Seite bietet auch Unterstützung bei Abfragen in natürlicher Sprache, die vom KI-Assistenten unterstützt wird. OpenSearch 

## So greifen Sie auf die Logs-Seite zu
<a name="observability-logs-access"></a>

Erweitern Sie in Ihrem Observability-Workspace in der linken Navigationsleiste die Option **Discover** und wählen Sie **Logs** aus.

## Erkundung von Protokolldaten
<a name="observability-logs-explore"></a>

Die Discover Logs-Oberfläche bietet die folgenden Komponenten für die Untersuchung Ihrer Protokolldaten.

![\[alt text not found\]](http://docs.aws.amazon.com/de_de/opensearch-service/latest/developerguide/images/discover-logs/discover-logs-interface.png)

+ **Datensatzauswahl** — Wählen Sie den Protokolldatensatz aus, den Sie abfragen möchten. Jeder Datensatz ist einem oder mehreren Indizes in Ihrer OpenSearch Service-Domain zugeordnet.
+ **Abfrage-Editor** — Schreiben Sie PPL-Abfragen, um Ihre Protokolldaten zu filtern, zu aggregieren und zu transformieren. Der Editor bietet Vorschläge zur automatischen Vervollständigung und Syntaxhervorhebung.
+ **Zeitfilter** — Geben Sie den Zeitraum für Ihre Abfrageergebnisse an. Sie können einen relativen Bereich wählen oder absolute Start- und Endzeiten angeben.
+ **Ergebnisbereich** — Zeigt die Abfrageergebnisse als Tabelle mit Protokollereignissen an. Sie können einzelne Ereignisse erweitern, um alle Felder zu sehen.
+ **Histogramm** — Sehen Sie sich die Verteilung der Protokollereignisse im Laufe der Zeit an. Das Histogramm wird basierend auf Ihrer Abfrage und Ihrem Zeitfilter automatisch aktualisiert.
+ **Bereich „Felder“** — Durchsuchen Sie die verfügbaren Felder in Ihrem Datensatz und fügen Sie sie als Spalten zur Ergebnistabelle hinzu.

## Logs mit PPL abfragen
<a name="observability-logs-query-ppl"></a>

Die Piped Processing Language (PPL) ist eine Abfragesprache, die eine pipebasierte (`|`) -Syntax für die Verkettung von Befehlen verwendet. Sie können PPL verwenden, um Ihre Protokolldaten zu filtern, zu aggregieren und zu transformieren.

### Grundlegende Abfragen
<a name="observability-logs-basic-queries"></a>

Verwenden Sie den `source` folgenden Befehl, um alle Protokollereignisse aus einem Datensatz abzurufen:

```
source = my-logs-dataset
```

Verwenden Sie den `head` folgenden Befehl, um die Anzahl der Ergebnisse zu begrenzen:

```
source = my-logs-dataset | head 20
```

### Filterung mit WHERE
<a name="observability-logs-where-clause"></a>

Verwenden Sie die `where` Klausel, um Protokollereignisse auf der Grundlage von Feldwerten zu filtern:

```
source = my-logs-dataset | where severity_text = 'ERROR'
```

Sie können mehrere Bedingungen kombinieren:

```
source = my-logs-dataset |
    where severity_text = 'ERROR' and service_name = 'payment-service'
```

### Abfragen verwalten
<a name="observability-logs-manage-queries"></a>

Sie können häufig verwendete Abfragen zur Wiederverwendung speichern. Um eine Abfrage zu speichern, wählen Sie in der Werkzeugleiste des Abfrage-Editors **Speichern** und geben Sie einen Namen für die Abfrage ein. Um eine gespeicherte Abfrage zu laden, wählen Sie **Öffnen** und wählen Sie die Abfrage aus der Liste aus.

Eine vollständige Liste der PPL-Befehle und -Funktionen finden Sie in der [Piped Processing Language-Referenz](https://observability.opensearch.org/docs/ppl/).

## Visualisierungen aus Protokollen erstellen
<a name="observability-logs-visualizations"></a>

Sie können Visualisierungen direkt aus Ihren PPL-Abfrageergebnissen erstellen. Verwenden Sie den `stats` Befehl, um Daten für die Visualisierung zu aggregieren:

```
source = my-logs-dataset |
    stats count() as error_count by service_name, span(timestamp, 1h)
```

Nachdem Sie eine `stats` Abfrage ausgeführt haben, wählen Sie die Registerkarte **Visualisierung**, um die Ergebnisse als Diagramm anzuzeigen.

![\[alt text not found\]](http://docs.aws.amazon.com/de_de/opensearch-service/latest/developerguide/images/discover-logs/discover-logs-visualization.png)


### Visualisierungstypen
<a name="observability-logs-viz-types"></a>

In der folgenden Tabelle werden die Visualisierungstypen beschrieben, die Sie verwenden können.


| Typ | Description | 
| --- | --- | 
| Linien | Zeigt Datenpunkte an, die durch Linien miteinander verbunden sind. Dies ist nützlich, um Trends im Zeitverlauf darzustellen. | 
| Flächen | Ähnlich wie bei einem Liniendiagramm, bei dem der Bereich unter der Linie ausgefüllt ist. Dies ist nützlich, um das Volumen im Zeitverlauf darzustellen. | 
| Säulen | Zeigt Daten als vertikale oder horizontale Balken an, was für den Vergleich von Werten zwischen Kategorien nützlich ist. | 
| Metrik | Zeigt einen einzelnen numerischen Wert an, der für die Darstellung wichtiger Leistungsindikatoren nützlich ist. | 
| Zeitleiste des Bundesstaates | Zeigt Statusänderungen im Laufe der Zeit als farbige Bänder an, was für die Überwachung von Statusübergängen nützlich ist. | 
| Heatmap | Zeigt Daten als Matrix aus farbigen Zellen an, was für die Darstellung von Dichte und Mustern nützlich ist. | 
| Balkenmaß | Zeigt einen einzelnen Wert als gefüllten Balken innerhalb eines Bereichs an. Dies ist nützlich, um den Fortschritt bei Erreichen eines Schwellenwerts anzuzeigen. | 
| Kreis | Zeigt Daten als proportionale Teile eines Kreises an, was für die Darstellung der Zusammensetzung nützlich ist. | 

![\[alt text not found\]](http://docs.aws.amazon.com/de_de/opensearch-service/latest/developerguide/images/discover-logs/discover-logs-viz-types.png)


### Einstellungen für die Visualisierung
<a name="observability-logs-viz-settings"></a>

Wenn die Registerkarte **Visualisierung** aktiv ist, wird auf der rechten Seite des Bildschirms ein Einstellungsfenster angezeigt. Verwenden Sie diesen Bereich, um den Diagrammtyp zu konfigurieren, Felder Achsen zuzuordnen und visuelle Stile wie Farben und Legenden anzupassen.

Verwenden Sie die Achsenkonfiguration im Einstellungsfenster, um zwischen den Achsen einer Visualisierung zu wechseln.

![\[alt text not found\]](http://docs.aws.amazon.com/de_de/opensearch-service/latest/developerguide/images/discover-logs/discover-logs-switch-axes.png)


## Hinzufügen von Visualisierungen zu Dashboards
<a name="observability-logs-add-to-dashboard"></a>

Nachdem Sie eine Visualisierung erstellt haben, können Sie sie zu einem Dashboard hinzufügen, um sie fortlaufend zu überwachen. Wählen Sie in der Visualisierungssymbolleiste Im **Dashboard speichern** und wählen Sie dann ein vorhandenes Dashboard aus oder erstellen Sie ein neues. Die Visualisierung wird mit der zugrunde liegenden PPL-Abfrage gespeichert, sodass sie automatisch aktualisiert wird, wenn Sie das Dashboard öffnen.

# Entdecke Spuren
<a name="observability-analyze-traces"></a>

Die Seite Discover Traces bietet eine spezielle Oberfläche für die Untersuchung verteilter Trace-Daten in Ihrem OpenSearch Service-Observability-Workspace. Sie können RED-Metriken (Rate, Fehlerrate, Dauer) für Ihre Services einsehen, Trace-Spans mit facettierter Filterung durchsuchen und einzelne Spans und Traces detailliert untersuchen, um Leistungsprobleme zu diagnostizieren. Die Seite unterstützt auch die Korrelation von Traces mit zugehörigen Protokolldaten.

## Um auf die Traces-Seite zuzugreifen
<a name="observability-traces-access"></a>

Erweitern Sie in Ihrem Observability-Workspace in der linken Navigationsleiste die Option **Discover** und wählen Sie **Traces** aus.

![\[alt text not found\]](http://docs.aws.amazon.com/de_de/opensearch-service/latest/developerguide/images/discover-traces/discover-traces.png)


## Trace-Datensätze konfigurieren
<a name="observability-traces-configure-datasets"></a>

Bevor Sie Trace-Daten untersuchen können, müssen Sie einen Traces-Datensatz konfigurieren. Sie können einen Datensatz automatisch oder manuell erstellen.

### Automatische Datensatzerstellung
<a name="observability-traces-auto-create"></a>

Wenn Sie zum ersten Mal zur Seite „Traces entdecken“ navigieren und in Ihrer Domain Trace-Daten vorhanden sind, werden Sie auf der Seite aufgefordert, automatisch einen Datensatz zu erstellen. Wählen Sie **Datensatz erstellen**, um die Standardkonfiguration zu akzeptieren.

![\[alt text not found\]](http://docs.aws.amazon.com/de_de/opensearch-service/latest/developerguide/images/discover-traces/trace-auto-create.png)


### Manuelle Datensatzerstellung
<a name="observability-traces-manual-create"></a>

Um einen Traces-Datensatz manuell zu erstellen, folgen Sie den Schritten unter[Um einen Traces-Datensatz zu erstellen](observability-datasets.md#observability-datasets-create-traces). Bei der manuellen Erstellung haben Sie die Kontrolle über das Indexmuster, das Zeitstempelfeld und den Datensatznamen.

## Spurendaten untersuchen
<a name="observability-traces-explore"></a>

Die Seite Discover Traces enthält die folgenden Komponenten für die Untersuchung Ihrer Trace-Daten.
+ **RED-Metriken** — Anzeigerate (Anfragen pro Sekunde), Fehlerrate (Prozentsatz fehlgeschlagener Anfragen) und Dauer (Latenzperzentile) für den ausgewählten Datensatz. Diese Metriken werden basierend auf Ihrem Zeitfilter aktualisiert.
+ **Facettierte Felder** — Filtern Sie Trace-Spans nach Dienstname, Vorgang, Statuscode und anderen Span-Attributen. Wählen Sie Werte im Bereich „Facettenfelder“ aus, um Ihre Ergebnisse einzugrenzen.
+ **Span-Tabelle** — Durchsuchen Sie einzelne Bereiche mit Spalten für Trace-ID, Span-ID, Dienstname, Vorgang, Dauer und Status. Sie können nach einer beliebigen Spalte sortieren und die Zeilen erweitern, um die Span-Details zu sehen.

## Einen bestimmten Zeitraum anzeigen
<a name="observability-traces-view-span"></a>

Um Details für einen bestimmten Bereich anzuzeigen, wählen Sie die Span-Zeile in der Span-Tabelle aus. Ein Flyout-Fenster mit den Span-Attributen, Ressourcenattributen und Ereignisinformationen wird geöffnet.

![\[alt text not found\]](http://docs.aws.amazon.com/de_de/opensearch-service/latest/developerguide/images/discover-traces/trace-details-flyout.png)


## Detailseite für die Ablaufverfolgung
<a name="observability-traces-detail-page"></a>

Um den vollständigen Trace anzuzeigen, wählen Sie den Trace-ID-Link in der Span-Tabelle oder im Flyout-Fenster aus. Auf der Trace-Detailseite wird ein Wasserfalldiagramm angezeigt, das alle Spans in der Trace, ihre zeitlichen Beziehungen und die gesamte Trace-Dauer zeigt. Sie können einzelne Bereiche erweitern, um ihre Attribute anzuzeigen und Engpässe zu identifizieren.

![\[alt text not found\]](http://docs.aws.amazon.com/de_de/opensearch-service/latest/developerguide/images/discover-traces/trace-detail-page.png)


## Korrelieren von Traces mit Protokollen
<a name="observability-traces-correlate-logs"></a>

Wenn Sie eine Korrelation zwischen einem Traces-Datensatz und einem Logs-Datensatz konfigurieren, können Sie zugehörige Logeinträge direkt auf der Seite „Traces entdecken“ anzeigen. Hinweise zum Erstellen von Korrelationen finden Sie unter[Korrelationen](observability-correlations.md).

### Verwandte Protokolle anzeigen
<a name="observability-traces-related-logs"></a>

Wählen Sie im Flyout mit den Span-Details oder auf der Trace-Detailseite die Registerkarte **Verwandte Logs** aus, um Logeinträge anzuzeigen, die der Trace-ID, dem Servicenamen und dem Zeitraum des Spans entsprechen. Diese Korrelation hilft Ihnen zu verstehen, was während der Span-Ausführung in Ihrer Anwendung passiert ist.

![\[alt text not found\]](http://docs.aws.amazon.com/de_de/opensearch-service/latest/developerguide/images/discover-traces/related-logs.png)


### Protokollumleitung mit Kontext
<a name="observability-traces-log-redirection"></a>

Sie können von einem Trace-Bereich direkt zur Seite Discover Logs navigieren, wobei der entsprechende Kontext erhalten bleibt. Wählen Sie **im Bereich „Verwandte Logs“ die Option „In Logs anzeigen**“, um die Seite „Discover Logs“ zu öffnen, auf der die Abfrage bereits ausgefüllt ist und nach der Trace-ID und dem Zeitraum des Spans gefiltert wird.

![\[alt text not found\]](http://docs.aws.amazon.com/de_de/opensearch-service/latest/developerguide/images/discover-traces/logs-redirection.png)


## Traces mit PPL abfragen
<a name="observability-traces-querying"></a>

Sie können PPL verwenden, um Trace-Daten direkt abzufragen. PPL verkettet Befehle mithilfe des Pipe-Zeichens, um Span-Daten zu filtern, zu transformieren und zu aggregieren.

Im folgenden Beispiel werden die 10 langsamsten Traces gefunden:

```
source = otel-v1-apm-span-*
| where durationInNanos > 5000000000
| fields traceId, serviceName, name, durationInNanos
| sort - durationInNanos
| head 10
```

Im folgenden Beispiel werden Fehler nach Service gezählt:

```
source = otel-v1-apm-span-*
| where status.code = 2
| stats count() as errorCount by serviceName
| sort - errorCount
```

Im folgenden Beispiel werden Traces für einen bestimmten Dienst gefunden:

```
source = otel-v1-apm-span-*
| where serviceName = 'checkout-service'
| where parentSpanId = ''
| sort - startTime
| head 20
```

# Kennzahlen
<a name="observability-metrics"></a>

Die Seite „Metriken ermitteln“ in der OpenSearch Benutzeroberfläche bietet eine spezielle Oberfläche für die Erkennung, Abfrage und Visualisierung von Metrikdaten in Zeitreihen. Diese Seite ist für die Arbeit mit Prometheus-Metriken unter Verwendung von PromQL optimiert.

![\[alt text not found\]](http://docs.aws.amazon.com/de_de/opensearch-service/latest/developerguide/images/dashboards/prometheus.png)


Die Seite Discover Metrics ist in Observability-Workspaces verfügbar. **Um darauf zuzugreifen, navigieren Sie zu einem Observability-Workspace, erweitern **Sie Discover** in der linken Navigationsleiste und wählen Sie Metriken aus.**

## Konfiguration einer Prometheus-Datenquelle
<a name="observability-metrics-data-source"></a>

Bevor Sie beginnen, konfigurieren Sie eine Prometheus-Datenquelle mit einer der folgenden Methoden:
+ [Erstellen einer Amazon Managed Service for Prometheus-Datenquelle](direct-query-prometheus-creating.md)in der Management Console AWS 
+ [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/opensearch/add-direct-query-data-source.html)

## Bereich „Abfrage“
<a name="observability-metrics-query"></a>

Im Abfragebereich oben auf der Seite „Metriken entdecken“ können Sie Metrikabfragen schreiben und ausführen. Der Abfrage-Editor bietet Vorschläge zur automatischen Vervollständigung und Syntaxhervorhebung für PromQL.

**Abfragen schreiben**  
Schreiben Sie Abfragen mit der PromQL-Syntax. Beispiel:

```
up{job="prometheus"}
```

**Ausführen von Abfragen**  
**Um eine Abfrage auszuführen, geben Sie Ihre Abfrage in den Abfrage-Editor ein und wählen Sie Aktualisieren.**

Sie können mehrere PromQL-Abfragen zusammen ausführen, indem Sie sie durch ein Semikolon () trennen: `;`

```
up{job="prometheus"};
node_cpu_seconds_total{mode="idle"};
```

Jede Abfrage wird unabhängig ausgeführt, und die Ergebnisse werden in der Ausgabe kombiniert.

## Zeitfilter
<a name="observability-metrics-time-filter"></a>

Verwenden Sie den Zeitfilter, um den Zeitraum für Ihre Metrikdaten anzugeben:
+ **Schnellauswahl** — Wählen Sie einen relativen Zeitraum aus (z. B. die letzten 15 Minuten oder die letzten 1 Stunde).
+ **Häufig verwendet** — Wählen Sie aus vordefinierten Zeitbereichen.
+ **Benutzerdefiniert** — Geben Sie absolute Start- und Endzeiten an.
+ **Automatische Aktualisierung** — Legen Sie ein automatisches Aktualisierungsintervall fest.

## Anzeigen der Ergebnisse
<a name="observability-metrics-results"></a>

Nach dem Ausführen einer Abfrage werden die Ergebnisse in einer Oberfläche mit Registerkarten angezeigt:
+ **Metriken** — Zeigt den neuesten Datenpunkt für jede Datenreihe in einem Tabellenformat an.
+ **Raw** — Zeigt den neuesten Datenpunkt für jede Serie als unformatiertes JSON an, das von der Datenquelle zurückgegeben wird.
+ **Visualisierung** — Stellt interaktive Diagramme für Ihre Metrikdaten bereit.

## Konfiguration von Visualisierungen
<a name="observability-metrics-visualizations"></a>

Wenn die Registerkarte **Visualisierung** ausgewählt ist, wird auf der rechten Seite des Bildschirms ein Einstellungsfenster angezeigt. Verwenden Sie dieses Fenster, um:
+ **Wählen Sie einen Diagrammtyp** — Wählen Sie zwischen Linien-, Balken-, Kreis-, Messgerät- oder Tabellenvisualisierungen.
+ **Achsen zuordnen** — Weisen Sie den X- und Y-Achsen Felder zu.
+ **Stile anpassen** — Passen Sie Farben, Legenden, Gitternetzlinien und andere visuelle Optionen an.

Wenn Sie die Einstellungen ändern, wird die Visualisierung automatisch aktualisiert.

# Korrelationen
<a name="observability-correlations"></a>

Korrelationen verknüpfen einen Traces-Datensatz mit einem Log-Datensatz, sodass Sie bei der Untersuchung von Trace-Spans zugehörige Logeinträge einsehen können. Indem Sie eine Korrelation definieren, ermöglichen Sie es, auf der Seite „Discover Traces“ Logs anzuzeigen, die während der Ausführung einer Spanne entstanden sind, sodass Sie Probleme schneller diagnostizieren können, ohne zwischen den Seiten wechseln zu müssen.

## Korrelationsanforderungen
<a name="observability-correlations-requirements"></a>

Um eine Korrelation herzustellen, müssen Ihre Protokoll- und Trace-Daten übereinstimmende Felder enthalten. In der folgenden Tabelle werden die Felder beschrieben, die bei der Korrelation zur Verknüpfung von Trace- und Protokolldaten verwendet werden.


| Feld | Description | Erforderlich | 
| --- | --- | --- | 
| Trace-ID | Die eindeutige Kennung für den Trace. Muss sowohl im Trace-Span-Index als auch im Log-Index vorhanden sein. | Ja | 
| Span-ID | Die eindeutige Kennung für den Bereich. Wird verwendet, um Logs einer bestimmten Spanne innerhalb einer Ablaufverfolgung zuzuordnen. | Nein | 
| Service-Name | Der Name des Dienstes, der die Telemetrie generiert hat. Wird verwendet, um zugehörige Protokolle nach Dienst zu filtern. | Nein | 
| Zeitstempel | Das Zeitfeld, das verwendet wird, um zugehörige Protokolle auf den Zeitraum der Spanne einzugrenzen. | Ja | 

## Um eine trace-to-logs Korrelation zu erstellen
<a name="observability-correlations-create"></a>

Gehen Sie wie folgt vor, um eine Korrelation zwischen einem Traces-Datensatz und einem Logs-Datensatz herzustellen.

1. Erweitern Sie in Ihrem Observability-Workspace in der linken Navigationsleiste die Option **Discover** und wählen Sie **Traces** aus.

1. Wählen Sie den Traces-Datensatz aus, den Sie korrelieren möchten.

1. Wählen Sie im Bereich zur Konfiguration des Datensatzes die Registerkarte **Korrelationen** aus.  
![\[alt text not found\]](http://docs.aws.amazon.com/de_de/opensearch-service/latest/developerguide/images/datasets/correlations-trace-dataset-tab.png)

1. Wählen Sie **Korrelation erstellen** aus.

1. Wählen Sie im Konfigurationsdialogfeld den Zielprotokolldatensatz aus und ordnen Sie die erforderlichen Korrelationsfelder (Trace-ID und Zeitstempel) zu. Ordnen Sie optional die Span-ID und den Servicenamen zu, um einen genaueren Abgleich zu erzielen.  
![\[alt text not found\]](http://docs.aws.amazon.com/de_de/opensearch-service/latest/developerguide/images/datasets/correlations-configure-dialog.png)

1. Wählen Sie **Erstellen**, um die Korrelation zu speichern.

1. Stellen Sie sicher, dass die Korrelation in der Korrelationstabelle angezeigt wird.  
![\[alt text not found\]](http://docs.aws.amazon.com/de_de/opensearch-service/latest/developerguide/images/datasets/correlations-created-table.png)

## Korrelationen in Protokolldatensätzen anzeigen
<a name="observability-correlations-view-logs"></a>

Nachdem Sie eine Korrelation erstellt haben, können Sie sie auch von der Seite der Protokolldatensätze aus anzeigen. Navigieren Sie zur Seite „Logs entdecken“, wählen Sie den Datensatz mit korrelierten Logs und anschließend den Tab **Korrelationen** aus, um den verknüpften Traces-Datensatz zu sehen.

![\[alt text not found\]](http://docs.aws.amazon.com/de_de/opensearch-service/latest/developerguide/images/datasets/correlations-logs-dataset-tab.png)


## Korrelationen auf der Seite „Traces“ verwenden
<a name="observability-correlations-use-traces"></a>

Wenn eine Korrelation besteht, werden auf der Seite „Discover Traces“ zugehörige Logs in der Span-Detailansicht angezeigt. Wählen Sie einen Bereich in der Span-Tabelle aus, um das Details-Flyout zu öffnen, und wählen Sie dann die Registerkarte **Verwandte Logs**, um die korrelierten Logeinträge anzuzeigen.

![\[alt text not found\]](http://docs.aws.amazon.com/de_de/opensearch-service/latest/developerguide/images/datasets/correlations-span-details-logs.png)


## Korrelationen verwalten
<a name="observability-correlations-manage"></a>

**Sie können Korrelationen auf der Registerkarte Korrelationen des Traces- oder des Logs-Datensatzes bearbeiten oder entfernen.**
+ **Bearbeiten** — Wählen Sie die Korrelation in der Tabelle aus und klicken Sie auf **Bearbeiten**, um die Feldzuordnungen oder den Zieldatensatz zu aktualisieren.
+ **Entfernen** — Wählen Sie die Korrelation in der Tabelle aus und klicken Sie auf **Löschen**, um die Korrelation zu entfernen. Durch das Entfernen einer Korrelation werden keine Daten gelöscht.

# Dashboards
<a name="observability-dashboards"></a>

Dashboards kombinieren Visualisierungen aus Protokollen, Traces und Metriken in einer einzigen Ansicht. Mithilfe von Dashboards können Sie den Betriebsstatus überwachen, auf Vorfälle reagieren und die Ressourcennutzung in Ihrem verteilten System verfolgen.

In der folgenden Tabelle werden gängige Anwendungsfälle für Dashboards beschrieben.


| Anwendungsfall | Beispiel | 
| --- | --- | 
| Operative Überwachung | Verfolgen Sie den Dienststatus, den Durchsatz und die Fehlerraten in Echtzeit. | 
| Vorfallreaktion | Korrelieren Sie Protokolle, Traces und Metriken während eines aktiven Vorfalls. | 
| Kapazitätsplanung | Überwachen Sie Trends bei der Ressourcennutzung, um die Skalierung zu planen. | 
| Nachverfolgung der Verfügbarkeit | Messen Sie Betriebszeit und Verfügbarkeit anhand von Service-Level-Zielen. | 
| Überprüfung nach dem Vorfall | Analysieren Sie historische Daten, um die Grundursache vergangener Vorfälle zu verstehen. | 

![\[alt text not found\]](http://docs.aws.amazon.com/de_de/opensearch-service/latest/developerguide/images/otel-dashboard.png)


## Struktur des Dashboards
<a name="observability-dashboards-structure"></a>

Ein Dashboard ist eine Sammlung von Panels, die in einem Raster angeordnet sind. Jedes Panel besteht aus den folgenden Komponenten.
+ **Datenquelle** — Der OpenSearch Index oder die Amazon Managed Service for Prometheus-Datenquelle, die das Panel abfragt.
+ **Abfrage** — Eine PPL- oder PromQL-Abfrage, die die Daten für das Panel abruft.
+ **Visualisierungstyp** — Der Diagrammtyp, der zum Rendern der Abfrageergebnisse verwendet wird, z. B. Linie, Balken oder Metrikwert.
+ **Optionale Konfiguration** — Achsen, Legenden, Schwellenwerte und Formatierungsoptionen.

Die Zeitbereichsauswahl oben im Dashboard gilt für alle Bereiche. Sie können den Zeitraum für einzelne Bereiche bei Bedarf überschreiben.

## Dashboards aus Discover erstellen
<a name="observability-dashboards-discover"></a>

Der empfohlene Workflow für die Erstellung von Dashboards beginnt in Discover. Dieser Workflow ist in allen Protokollen, Traces und Metriken konsistent.

1. **Fragen Sie Ihre Daten in Discover ab** — Navigieren Sie zu Discover Logs, Discover Traces oder Discover Metrics und schreiben Sie eine Abfrage mit PPL (für Logs und Traces) oder PromQL (für Metriken).

1. **Erstellen Sie eine Visualisierung** — Wenn Ihre Abfrage Ergebnisse zurückgibt, wählen Sie auf der Registerkarte „Visualisierung“ einen Diagrammtyp aus und konfigurieren Sie die Anzeige. Bei Protokoll- und Trace-Abfragen wechseln Aggregationsbefehle z. B. `stats` automatisch zur Visualisierungsansicht.

1. In **einem Dashboard speichern** — Wählen Sie **Zum Dashboard hinzufügen**, um die Visualisierung in einem neuen oder vorhandenen Dashboard zu speichern. Das Panel bleibt aktiv und wird aktualisiert, sobald neue Daten eintreffen.

1. **Iterieren** — Wiederhole den Vorgang für jede Frage, die das Dashboard beantworten soll. Wenn auf einem Dashboard etwas falsch aussieht, wählen Sie ein beliebiges Fenster aus, um die zugrunde liegende Abfrage in Discover zur weiteren Untersuchung zu öffnen.

**Wichtig**  
Visualisierungen, die über die Seite „**Visualisierungen**“ in der OpenSearch Benutzeroberfläche erstellt wurden, verwenden DQL (Dashboards Query Language) und DSL (Domain Specific Language), die Piped Processing Language (PPL) derzeit nicht unterstützen. Verwenden Sie den oben beschriebenen Discover-Workflow, um PPL-basierte Visualisierungen zu erstellen.

## Dashboard-Filter
<a name="observability-dashboards-filters"></a>

Mithilfe von Filtern können Sie die in allen Bereichen eines Dashboards angezeigten Daten einschränken, ohne einzelne Abfragen bearbeiten zu müssen.

**Um einen Filter hinzuzufügen**

1. Öffnen Sie das Dashboard, das Sie filtern möchten.

1. Wählen **Sie in der Filterleiste Filter hinzufügen** aus.

1. Wählen Sie einen Feldnamen aus der Dropdownliste aus.

1. Wählen Sie einen Operator aus und geben Sie einen Wert ein.

1. Wählen Sie **Speichern**.

In der folgenden Tabelle werden allgemeine Anwendungsfälle für Filter beschrieben.


| Szenario | Feld | Operator | Wert | 
| --- | --- | --- | --- | 
| Eine einzelne Umgebung anzeigen | environment | is | production | 
| Isolieren von Fehlern | status\$1code | is greater than or equal to | 400 | 
| Konzentrieren Sie sich auf einen bestimmten Service | service.name | is | order-service | 
| Gesundheitschecks ausschließen | http.url | is not | /health | 

**Angeheftete Filter im Vergleich zu nicht angehefteten Filtern** — Ein angehefteter Filter bleibt bestehen, wenn Sie zwischen Dashboards navigieren. Ein nicht angehefteter Filter gilt nur für das aktuelle Dashboard. Um einen Filter anzuheften, wählen Sie das Stecknadelsymbol neben dem Filtersymbol.

## Dashboards erstellen
<a name="observability-dashboards-build"></a>

### Visualisierungstypen
<a name="observability-dashboards-build-viz-types"></a>

In der folgenden Tabelle werden die Visualisierungstypen beschrieben, die für Dashboard-Panels verfügbar sind.


| Typ | Anwendungsfall | 
| --- | --- | 
| Linien | Trends im Zeitverlauf, z. B. Anforderungsraten oder Latenz | 
| Flächen | Volumen im Zeitverlauf mit gestapelten Aufschlüsselungen | 
| Säulen | Vergleich von Werten zwischen Kategorien | 
| Horizontaler Balken | Vergleiche nach Rangfolge, z. B. die besten Dienste nach Anzahl der Fehler | 
| Datentabelle | Tabellarische Daten mit Sortierung und Paginierung | 
| Metrikwert | Einzelne wichtige Leistungsindikatoren, wie z. B. die Gesamtzahl der Anfragen | 
| Messinstrument | Annäherung an einen Schwellenwert, wie z. B. die CPU-Auslastung | 
| Kreis | Zusammensetzung und Proportionen, z. B. Verkehr nach Regionen | 
| Heatmap | Dichte und Verteilungsmuster in zwei Dimensionen | 
| Schlagwort: Wolke | Relative Häufigkeit von Begriffen, wie z. B. häufig vorkommende Fehlermeldungen | 

### Konfiguration von Panels
<a name="observability-dashboards-build-configure"></a>

Jedes Panel hat einen Abfrage-Editor, in dem Sie PPL- oder PromQL-Abfragen schreiben können. Die folgenden Beispiele zeigen gängige Panel-Abfragen.

Anzahl der Fehler pro Dienst (PPL):

```
source = logs-dataset |
    where severity_text = 'ERROR' |
    stats count() as error_count by service_name, span(timestamp, 5m)
```

CPU-Auslastungsrate (PromQL):

```
rate(container_cpu_usage_seconds_total{namespace="production"}[5m])
```

Sie können auch die folgenden Panel-Optionen konfigurieren.
+ **Achsen** — Legen Sie Achsenbeschriftungen, Skalierungen (linear oder logarithmisch) und Wertebereiche fest.
+ **Legenden** — Steuern Sie die Position der Legende und die anzuzeigenden Reihen.
+ **Schwellenwerte** — Fügen Sie horizontale Schwellenwertlinien hinzu, um Warnstufen oder kritische Stufen hervorzuheben.

### Tipps zum Layout
<a name="observability-dashboards-build-layout"></a>

Verwenden Sie die folgenden Tipps, um Ihre Dashboard-Panels effektiv zu organisieren.
+ Platzieren Sie übergeordnete Übersichtsfelder (metrische Werte, Messgeräte) oben im Dashboard.
+ Gruppieren Sie verwandte Bereiche, z. B. alle Bereiche für einen einzelnen Service.
+ Verwenden Sie einheitliche Breiten für Panels in derselben Reihe.
+ Ziehen Sie die Panelkanten, um die Größe zu ändern, und ziehen Sie die Panelüberschriften, um sie neu zu positionieren.

### Empfohlene Layouts
<a name="observability-dashboards-build-recommended"></a>

In den folgenden Tabellen werden empfohlene Panel-Layouts für gängige Dashboard-Typen beschrieben.

**Dashboard zur Dienstintegrität**


| Panel | Art der Visualisierung | 
| --- | --- | 
| Anforderungsrate | Linien | 
| Fehlerquote | Linien | 
| P99-Latenz | Linien | 
| Aktive Warnungen | Metrikwert | 
| Häufigste Fehler nach Service | Horizontaler Balken | 

**Dashboard zur Reaktion auf Vorfälle**


| Panel | Art der Visualisierung | 
| --- | --- | 
| Fehlerprotokolle | Datentabelle | 
| Anzahl der Fehler im Laufe der Zeit | Flächen | 
| Betroffene Dienste | Kreis | 
| Latenzspitzen | Linien | 

**Dashboard zur Ressourcennutzung**


| Panel | Art der Visualisierung | 
| --- | --- | 
| CPU-Auslastung | Messinstrument | 
| Speicherverbrauch im Laufe der Zeit | Flächen | 
| Festplatten-IO | Linien | 
| Netzwerkdurchsatz | Linien | 

### Steuerungen für den Zeitbereich
<a name="observability-dashboards-build-time-range"></a>

Die Zeitbereichsauswahl oben im Dashboard steuert das Zeitfenster für alle Bereiche. Sie können einen voreingestellten Bereich auswählen (z. B. **Letzte 15 Minuten** oder **Letzte 24 Stunden**) oder einen benutzerdefinierten absoluten Bereich angeben.

Um die automatische Aktualisierung zu aktivieren, wählen Sie das Drop-down-Menü für das Aktualisierungsintervall neben der Zeitbereichsauswahl und wählen Sie ein Intervall aus. Bei der automatischen Aktualisierung werden alle Panel-Abfragen im angegebenen Intervall erneut ausgeführt, sodass Ihr Dashboard die neuesten Daten anzeigt.

## Freigeben von Dashboards
<a name="observability-dashboards-sharing"></a>

Sie können Dashboards mithilfe URLs von Schnappschüssen und Exporten mit anderen Benutzern in Ihrer Organisation teilen.

### Über URL teilen
<a name="observability-dashboards-sharing-url"></a>

Kopieren Sie die Dashboard-URL aus der Adressleiste Ihres Browsers und teilen Sie sie direkt. Die URL behält den aktuellen Zeitraum und die Filter bei. Sie können Dashboard-Links in Lesezeichen, Runbooks oder die Dokumentation zur Reaktion auf Vorfälle aufnehmen.

### -Snapshots
<a name="observability-dashboards-sharing-snapshots"></a>

Ein Snapshot erfasst den aktuellen Status eines Dashboards, einschließlich aller Panel-Daten, zu einem bestimmten Zeitpunkt. Snapshots sind schreibgeschützt und werden nicht aktualisiert, wenn sich die zugrunde liegenden Daten ändern. Verwenden Sie Schnappschüsse, um den Status des Dashboards bei Vorfällen oder Überprüfungen aufzuzeichnen.

### Definitionen importieren und exportieren
<a name="observability-dashboards-sharing-import-export"></a>

Sie können eine Dashboard-Definition als JSON exportieren und in einen anderen Workspace oder eine andere Umgebung importieren. Dieser Ansatz ist nützlich, um Dashboards von der Entwicklung bis zur Produktion weiterzuentwickeln oder Standardlayouts teamübergreifend gemeinsam zu nutzen.

### Bewährte Methoden für das Teilen
<a name="observability-dashboards-sharing-best-practices"></a>
+ **Zielgruppe** — Entwerfen Sie Dashboards für eine bestimmte Zielgruppe, z. B. Techniker auf Abruf oder Führungskräfte.
+ **Fokus** — Beschränken Sie jedes Dashboard auf einen einzigen Zweck oder Arbeitsablauf.
+ **Konventionen** — Verwenden Sie einheitliche Benennungskonventionen für Dashboards und Panels in Ihrer gesamten Organisation.
+ **Versionskontrolle** — Exportieren Sie Dashboard-JSON-Definitionen und speichern Sie sie in der Versionskontrolle, um Änderungen im Laufe der Zeit nachzuverfolgen.

## Fehlerbehebung bei Dashboards
<a name="observability-dashboards-troubleshooting"></a>

In diesem Abschnitt werden häufig auftretende Probleme mit Dashboards und deren Behebung beschrieben.

### Keine Daten in einem Panel
<a name="observability-dashboards-troubleshooting-no-data"></a>

Wenn in einem Panel keine Daten angezeigt werden, überprüfen Sie die folgenden häufigen Ursachen.


| Ursache | Check | Korrigieren | 
| --- | --- | --- | 
| Zeitbereich zu eng | Stellen Sie sicher, dass der Dashboard-Zeitraum den Zeitraum abdeckt, in dem Daten aufgenommen wurden. | Erweitern Sie den Zeitraum oder wählen Sie Letzte 24 Stunden aus. | 
| Aktiver Filter ohne Daten | Suchen Sie in der Filterleiste nach Filtern, die möglicherweise alle passenden Dokumente ausschließen. | Entfernen Sie den Filter oder passen Sie ihn an und überprüfen Sie dann, ob Daten angezeigt werden. | 
| Falsches Indexmuster | Vergewissern Sie sich, dass die Panel-Datenquelle auf einen Index verweist, der Daten enthält. | Aktualisieren Sie die Datenquelle im Bedienfeldeditor auf das richtige Indexmuster. | 
| Syntaxfehler bei der Abfrage | Suchen Sie in der Kopfzeile des Bedienfelds oder im Abfrage-Editor nach Fehlermeldungen. | Korrigieren Sie die PPL- oder PromQL-Syntax und führen Sie die Abfrage erneut aus. | 

### Falsche Daten in einem Panel
<a name="observability-dashboards-troubleshooting-wrong-data"></a>

Wenn in einem Panel unerwartete Ergebnisse angezeigt werden, versuchen Sie es mit den folgenden Schritten.
+ Stellen Sie sicher, dass die Abfrage die erwarteten Felder zurückgibt, indem Sie sie zuerst in Discover ausführen.
+ Überprüfen Sie, ob der Visualisierungstyp der Datenform entspricht (verwenden Sie z. B. ein Liniendiagramm für Zeitreihendaten).
+ Vergewissern Sie sich, dass im Bedienfeldeditor die richtige Datenquelle ausgewählt ist.

### Veraltete Daten
<a name="observability-dashboards-troubleshooting-stale-data"></a>

Wenn in den Dashboard-Bedienfeldern veraltete Informationen angezeigt werden, versuchen Sie es mit den folgenden Schritten.
+ Wählen Sie das Aktualisierungssymbol in der Werkzeugleiste, um alle Bereiche manuell zu aktualisieren.
+ Stellen Sie sicher, dass die automatische Aktualisierung aktiviert und auf ein geeignetes Intervall eingestellt ist.
+ Vergewissern Sie sich, dass Ihre Aufnahme-Pipeline aktiv Daten an die konfigurierten Indizes sendet.

### Leistungsprobleme
<a name="observability-dashboards-troubleshooting-performance"></a>

Die folgenden Tipps können Ihnen helfen, häufig auftretende Leistungsprobleme zu lösen.
+ **Langsames Dashboard** — Reduzieren Sie die Anzahl der Bedienfelder oder schränken Sie den Zeitbereich ein. Dashboards mit vielen Panels führen mehrere Abfragen gleichzeitig aus, was die Ladezeiten verlängern kann.
+ **Langsames Panel** — Vereinfachen Sie die Panel-Abfrage. Vermeiden Sie die Verwendung von Platzhaltermustern in `where` PPL-Klauseln und begrenzen Sie die Anzahl der Aggregationsbereiche.
+ **Browserverzögerung** — Reduzieren Sie die Datendichte in Visualisierungen. Erhöhen Sie beispielsweise das Zeitintervall in `stats` Befehlen, um weniger Datenpunkte zu erzeugen.

### Probleme beim Filtern
<a name="observability-dashboards-troubleshooting-filters"></a>

Wenn sich Filter nicht wie erwartet verhalten, versuchen Sie es mit den folgenden Schritten.
+ Stellen Sie sicher, dass der Feldname im Filter mit dem Feldnamen in der Indexzuordnung übereinstimmt.
+ Prüfen Sie, ob sich ein angehefteter Filter aus einem anderen Dashboard auf die Ergebnisse auswirkt.
+ Entfernen Sie alle Filter und fügen Sie sie nacheinander wieder hinzu, um das Problem zu isolieren.

### Untersuchen Sie ein Panel
<a name="observability-dashboards-troubleshooting-inspect"></a>

Der Bedienfeldinspektor hilft Ihnen beim Debuggen von Daten und Abfrageproblemen. Um den Inspektor zu öffnen, wählen Sie das Bedienfeldmenü (drei Punkte) und dann „**Prüfen**“. Der Inspektor bietet die folgenden Registerkarten.
+ **Daten** — Zeigt die von der Abfrage zurückgegebenen Rohdaten im Tabellenformat an.
+ **Anfrage** — Zeigt die an die Datenquelle gesendete Abfrage an, einschließlich der vollständigen PPL- oder PromQL-Anweisung.
+ **Antwort** — Zeigt die Rohantwort der Datenquelle an, einschließlich Zeit- und Statusinformationen.

### Tools für Browser-Entwickler
<a name="observability-dashboards-troubleshooting-browser"></a>

Verwenden Sie zur erweiterten Problembehandlung die Entwickler-Tools Ihres Browsers, um Netzwerkanfragen zu überprüfen. Öffnen Sie die Registerkarte **Netzwerk**, filtern Sie nach API-Aufrufen und suchen Sie nach fehlgeschlagenen Anfragen oder langsamen Antworten. Suchen Sie im Antworttext nach Fehlermeldungen, die Ihnen helfen können, die Ursache zu ermitteln.

# Anwendungsüberwachung
<a name="observability-app-monitoring"></a>

Die Anwendungsüberwachung bietet einen Echtzeitüberblick über die Leistung Ihrer Dienste. Es kombiniert in Amazon Managed Service for Prometheus gespeicherte Topologiedaten OpenSearch mit RED-Metriken (Rate, Errors, Duration) für Zeitreihen, um Informationen zu Zustand, Latenz, Durchsatz und Fehlern in Ihrem gesamten verteilten System zu ermitteln.

**Um auf die Anwendungsüberwachung zuzugreifen, navigieren Sie in der OpenSearch Benutzeroberfläche zu **Observability** > Application Monitoring.** Die Seitenleiste zeigt zwei Ansichten:
+ **Anwendungsübersicht** — Interaktives Topologiediagramm der Dienstabhängigkeiten
+ **Dienste** — Katalog aller instrumentierten Dienste mit Filtern, Detailansichten und Korrelationslinks

## Voraussetzungen
<a name="observability-app-monitoring-prereqs"></a>

Bevor Sie die Anwendungsüberwachung verwenden können, müssen Sie die folgenden Ressourcen konfiguriert haben.
+ [OTLP-Trace-Daten, die von Ihren OTel Collectors zur OpenSearch Erfassung fließen](observability-ingestion.md) (Metriken und Protokolle sind optional)
+ [Amazon Managed Service für Prometheus ist so konfiguriert, dass er Remote-Schreibvorgänge von Ingestion empfängt OpenSearch ](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/configure-client-prometheus.html)
+ Ein OpenSearch UI-Workspace mit aktivierter Observability

## Funktionsweise
<a name="observability-app-monitoring-how-it-works"></a>

Das folgende Diagramm zeigt die end-to-end Architektur für die Anwendungsüberwachung.

![\[alt text not found\]](http://docs.aws.amazon.com/de_de/opensearch-service/latest/developerguide/images/otel-sdk-service.png)


1. Ihre Anwendungen und Infrastruktur senden Telemetrie über die OpenTelemetry SDKs automatische Instrumentierung oder die OTel API an den OTel Collector.

1. Der OTel Collector leitet Trace-Daten über OTLP an OpenSearch Ingestion weiter.

1. Der OpenSearch `otel_apm_service_map` Ingestion-Prozessor extrahiert Beziehungen und berechnet RED-Metriken service-to-service.

1. Topologie und rohe Trace-Daten werden in indexiert. OpenSearch RED-Metriken werden per Fernschreiben an Amazon Managed Service for Prometheus exportiert.

1. OpenSearch Die Benutzeroberfläche fragt beide Stores ab, um die Anwendungsübersicht, den Servicekatalog und die Service-Detailansichten zu rendern.

## Dienstleistungen
<a name="observability-app-services"></a>

Die Ansicht „Dienste“ bietet einen zentralen Katalog aller instrumentierten Dienste und zeigt die RED-Metriken (Rate, Fehler, Dauer) auf einen Blick an. Mithilfe dieser Ansicht können Sie schnell fehlerhafte Services identifizieren und Detailansichten für tiefere Analysen aufrufen.

**Um auf die Serviceansicht zuzugreifen, navigieren Sie in der OpenSearch Benutzeroberfläche zum Observability-Workspace und wählen Sie **APM** > Services aus.**

Auf der Services-Startseite werden eine Tabelle mit allen instrumentierten Services sowie Übersichtsfenstern angezeigt. Die folgende Abbildung zeigt die Services-Startseite.

![\[alt text not found\]](http://docs.aws.amazon.com/de_de/opensearch-service/latest/developerguide/images/apm/services-home.png)


In der folgenden Tabelle werden die Spalten in der Servicetabelle beschrieben.


| Spalte | Description | 
| --- | --- | 
| Service-Name | Der Name des instrumentierten Dienstes. | 
| P99-Latenz | Die 99. Perzentil-Latenz für den Dienst. | 
| P90-Latenz | Die 90. Perzentil-Latenz für den Dienst. | 
| P50-Latenz | Die Latenz im 50. Perzentil (Median) für den Dienst. | 
| Anforderungen insgesamt | Die Gesamtzahl der Anfragen, die im ausgewählten Zeitraum verarbeitet wurden. | 
| Fehlerquote | Das Verhältnis der fehlgeschlagenen Anfragen zur Gesamtzahl der Anfragen. | 
| Umgebung | Die Bereitstellungsumgebung des Dienstes, z. B. production oderstaging. | 

Die Startseite enthält auch die folgenden Übersichtsbereiche:
+ **Top-Dienste nach Fehlerrate** — Dienste mit dem höchsten Prozentsatz von 5xx Antworten.
+ **Pfade mit den meisten Abhängigkeiten nach Fehlerrate** — Service-to-service Abhängigkeitspfade mit den höchsten Fehlerraten.

Sie können die Services-Tabelle mithilfe der folgenden Filter filtern:
+ **Umgebung** — Nach Bereitstellungsumgebung filtern.
+ **Latenz** — Nach Latenzbereich filtern.
+ **Durchsatz** — Filtert nach Anforderungsdurchsatzbereich.
+ **Ausfallrate** — Filtert nach Fehlerquotenbereich.

### Service-Übersicht
<a name="observability-app-services-overview"></a>

Um die Service-Detailansicht zu öffnen, wählen Sie einen Dienstnamen in der Servicetabelle aus. Auf der Registerkarte „Übersicht“ werden metrische Kacheln und Zeitreihendiagramme für den ausgewählten Service angezeigt.

![\[alt text not found\]](http://docs.aws.amazon.com/de_de/opensearch-service/latest/developerguide/images/apm/services-overview.png)


Die Registerkarte „Übersicht“ enthält die folgenden Zeitreihendiagramme:
+ **Latenz nach Dienstabhängigkeiten** — P50-, P90- und P99-Latenz, aufgeschlüsselt nach Downstream-Abhängigkeiten.
+ **Anfragen nach Vorgängen** — Anforderungsvolumen für jeden Vorgang des Dienstes.
+ **Verfügbarkeit nach Vorgängen** — Prozentsatz der erfolgreichen Antworten für jeden Vorgang.
+ **Fehlerrate und Fehlerquote nach Vorgängen** — Prozentsatz der 5xx- und 4xx-Antworten für jeden Vorgang.

### Operationen
<a name="observability-app-services-operations"></a>

Die Registerkarte „Vorgänge“ enthält eine Aufschlüsselung nach Vorgängen für den ausgewählten Dienst. Sie können die Tabelle nach einer beliebigen Spalte sortieren, um problematische Operationen zu identifizieren.

![\[alt text not found\]](http://docs.aws.amazon.com/de_de/opensearch-service/latest/developerguide/images/apm/service-operations.png)


In der folgenden Tabelle werden die Spalten in der Operationstabelle beschrieben.


| Spalte | Description | 
| --- | --- | 
| Vorgangsname | Der Name der Operation. | 
| P50/P90/P99-Latenz | Die Latenz im 50., 90. und 99. Perzentil für den Vorgang. | 
| Anforderungen insgesamt | Die Gesamtzahl der Anfragen für den Vorgang im ausgewählten Zeitraum. | 
| Fehlerrate | Der Prozentsatz der Anfragen, bei denen Fehler zurückgegeben wurden. | 
| Verfügbarkeit | Der Prozentsatz der erfolgreichen Antworten für den Vorgang. | 

### Abhängigkeiten
<a name="observability-app-services-dependencies"></a>

Auf der Registerkarte Abhängigkeiten werden die Downstream-Dienste angezeigt, die der ausgewählte Dienst aufruft.

![\[alt text not found\]](http://docs.aws.amazon.com/de_de/opensearch-service/latest/developerguide/images/apm/service-dependencies.png)


In der folgenden Tabelle werden die Spalten in der Tabelle mit den Abhängigkeiten beschrieben.


| Spalte | Description | 
| --- | --- | 
| Dienst für Abhängigkeiten | Der Name des Downstream-Dienstes. | 
| Bedienung aus der Ferne | Der Vorgang wurde im Downstream-Dienst aufgerufen. | 
| Serviceoperationen | Die Operationen im aktuellen Dienst, die diese Abhängigkeit aufrufen. | 
| P99/P90/P50-Latenz | Die Latenz im 99., 90. und 50. Perzentil für den Abhängigkeitspfad. | 
| Anforderungen insgesamt | Die Gesamtzahl der Anfragen an die Abhängigkeit im ausgewählten Zeitraum. | 
| Fehlerrate | Der Prozentsatz der Anfragen an die Abhängigkeit, bei denen Fehler zurückgegeben wurden. | 
| Verfügbarkeit | Der Prozentsatz erfolgreicher Antworten aus der Abhängigkeit. | 

### Korrelationen
<a name="observability-app-services-correlations"></a>

Die Service-Detailansicht bietet kontextbezogene Korrelationen, mit denen Sie von Servicemetriken direkt zu zugehörigen Traces und Protokollen navigieren können. Sie können Korrelationen verwenden, um die Hauptursache von Latenzspitzen oder erhöhten Fehlerraten zu untersuchen.

![\[alt text not found\]](http://docs.aws.amazon.com/de_de/opensearch-service/latest/developerguide/images/apm/service-span-correlations.png)


Die folgenden Korrelationsoptionen sind verfügbar:
+ **Verwandte Ablaufverfolgungen anzeigen** — Öffnet eine gefilterte Ablaufverfolgungsansicht für den ausgewählten Dienst oder Vorgang.
+ **Verwandte Protokolle anzeigen** — Öffnet eine gefilterte Protokollansicht für den ausgewählten Dienst oder Vorgang.
+ Nach **Attributen filtern** — Schränkt die Korrelationsergebnisse nach bestimmten Span-Attributen ein.

## Übersicht der Anwendung
<a name="observability-app-map"></a>

Die Anwendungsübersicht ist eine interaktive Topologievisualisierung, die OpenSearch Ingestion mithilfe des Prozessors automatisch aus Ihren Trace-Daten generiert. `otel_apm_service_map` Die Karte zeigt Dienste als Knoten mit Richtungskanten, die Kommunikationsmuster zeigen, überlagert mit RED-Metriken (Rate, Errors, Duration).

**Um auf die Anwendungsübersicht zuzugreifen, navigieren Sie in der OpenSearch Benutzeroberfläche zum Observability-Workspace und wählen Sie **APM** > Application Map.**

Die folgende Abbildung zeigt die Anwendungsübersicht.

![\[alt text not found\]](http://docs.aws.amazon.com/de_de/opensearch-service/latest/developerguide/images/apm/application-map.png)


In der Karte werden die folgenden RED-Metriken für jeden Service angezeigt:
+ **Rate** — Anfragen pro Sekunde, die vom Service verarbeitet werden.
+ **Fehler** — Prozentsatz der 4xx- und 5xx-Antworten.
+ **Dauer** — P50- und P99-Latenz für den Dienst.

Der `otel_apm_service_map` Prozessor generiert diese Metriken und speichert sie per Remote-Schreibzugriff in Amazon Managed Service for Prometheus.

Die Topologievisualisierung stellt Dienste als Knoten und die Kommunikationsrichtung als Kanten dar. Die Farbcodierung gibt den Integritätsstatus der einzelnen Dienste an. Die Karte wird automatisch aktualisiert, wenn OpenSearch Ingestion neue Trace-Daten aufnimmt.

### Dienste gruppieren
<a name="observability-app-map-groupby"></a>

Sie können Dienste nach Attributen wie Programmiersprache, Team oder Umgebung gruppieren. Wenn Sie ein Gruppierungsattribut auswählen, wechselt die Karte von einem Topologiediagramm zu einer Kartenrasteransicht. Jede Karte steht für eine Gruppe von Diensten, die denselben Attributwert haben.

![\[alt text not found\]](http://docs.aws.amazon.com/de_de/opensearch-service/latest/developerguide/images/apm/groupby-attributes.png)


Die verfügbaren Gruppierungsattribute werden durch die `group_by_attributes` Einstellung in der `otel_apm_service_map` Prozessorkonfiguration in OpenSearch Ingestion bestimmt.

### Knotendetails anzeigen
<a name="observability-app-map-node-details"></a>

Um Details für einen Service anzuzeigen, wählen Sie einen Knoten auf der Karte aus. Ein Detailfenster mit den folgenden Abschnitten wird geöffnet.

![\[alt text not found\]](http://docs.aws.amazon.com/de_de/opensearch-service/latest/developerguide/images/apm/application-map-node-details.png)


Im Bereich **Health** werden die folgenden zusammenfassenden Kennzahlen angezeigt:
+ Anfragen insgesamt
+ Fehler insgesamt: 4xx
+ Gesamtzahl der Fehler 5xx

Im Bereich **Metriken** werden die folgenden Zeitreihendiagramme angezeigt:
+ Anforderungen
+ Latenz P50/P90/P99
+ Fehler 5xx
+ Fehler 4xx

Wählen Sie **Details anzeigen**, um zur Detailansicht der Dienste für den ausgewählten Dienst zu gelangen.

### Die Karte filtern
<a name="observability-app-map-filters"></a>

Sie können die Anwendungsübersicht mithilfe der folgenden Filter filtern:
+ **Fehlerrate** — Filtert Dienste nach serverseitiger Fehlerrate (5xx).
+ **Fehlerrate** — Filtert Dienste nach der clientseitigen Fehlerrate (4xx).
+ **Umgebung** — Filtert Dienste nach der Bereitstellungsumgebung.

Die folgende Abbildung zeigt die Karte, gefiltert nach der Fehlerrate.

![\[alt text not found\]](http://docs.aws.amazon.com/de_de/opensearch-service/latest/developerguide/images/apm/filter-by-error-rate.png)


### Korrelationen im Kontext
<a name="observability-app-map-correlations"></a>

Sie können von der Topologieansicht aus direkt zu zugehörigen Traces und Logs navigieren. Von jedem Serviceknoten aus sind die folgenden Korrelationsoptionen verfügbar:
+ **Verwandte Traces anzeigen** — Öffnet eine gefilterte Trace-Ansicht für den ausgewählten Service.
+ **Verwandte Protokolle anzeigen** — Öffnet eine gefilterte Protokollansicht für den ausgewählten Dienst.

# KI-Beobachtbarkeit
<a name="observability-ai"></a>

AI Observability in OpenSearch bietet end-to-end Tools für die Überwachung, Debugging und Optimierung von Workflows für KI-Agenten und Large Language Model (LLM). Es basiert auf den semantischen Konventionen von GenAI und ist nativ in OpenTelemetry (OTel) integriert. So erhalten Sie einen vollständigen Überblick darüber, wie sich Ihre KI-Anwendungen in der Produktion verhalten.

Die KI-Beobachtbarkeit umfasst die folgenden Funktionen:
+ **Agentenverfolgung** — Erfassen Sie hierarchische Ausführungsablaufverfolgungen für alle Schritte der Agenten-Orchestrierung, LLM-Aufrufe, Tool-Aufrufe und Abrufvorgänge.
+ **Semantische Konventionen von GenAI** — Verwenden Sie standardisierte OTel Attribute wie, und, um KI-spezifische Telemetrie zu beschreiben. `gen_ai.system` `gen_ai.request.model` `gen_ai.usage.input_tokens`
+ **Automatische Instrumentierung** — Erfassen Sie automatisch Traces von gängigen KI-Frameworks und Anbietern, darunter OpenAI, Anthropic, Amazon Bedrock und mehr als 20 weiteren Bibliotheken. LangChain
+ **PPL-Abfrage — Abfragen** und Aggregieren von Trace-Daten mithilfe der Piped Processing Language (PPL) direkt von der Benutzeroberfläche aus. OpenSearch 

## Erste Schritte
<a name="observability-ai-getting-started"></a>

In diesem Abschnitt erfahren Sie, wie Sie einen KI-Agenten instrumentieren, Traces an Amazon OpenSearch Service senden und sie in der OpenSearch Benutzeroberfläche anzeigen.

### Um das SDK zu installieren
<a name="observability-ai-install-sdk"></a>

Installieren Sie das OpenTelemetry GenAI-Instrumentierungspaket:

```
pip install opentelemetry-instrumentation-openai-v2 opentelemetry-sdk opentelemetry-exporter-otlp
```

### Um Ihren Agentencode zu instrumentieren
<a name="observability-ai-instrument"></a>

Das folgende Beispiel zeigt, wie Sie das OTel SDK registrieren, Ihre Agentenfunktionen mit dem `@observe` Decorator annotieren und Spans mit GenAI-Attributen anreichern.

```
from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter

# Register the tracer provider
provider = TracerProvider()
processor = BatchSpanProcessor(
    OTLPSpanExporter(endpoint="<your-osis-endpoint>")  # Use your OpenSearch Ingestion endpoint with SigV4
)
provider.add_span_processor(processor)
trace.set_tracer_provider(provider)

tracer = trace.get_tracer(__name__)

# Decorate your agent function
@observe
def run_agent(prompt: str):
    with tracer.start_as_current_span("invoke_agent") as span:
        span.set_attribute("gen_ai.operation.name", "invoke_agent")
        span.set_attribute("gen_ai.system", "openai")
        span.set_attribute("gen_ai.request.model", "gpt-4")

        # Enrich with token usage after the LLM call
        response = call_llm(prompt)
        span.set_attribute("gen_ai.usage.input_tokens", response.input_tokens)
        span.set_attribute("gen_ai.usage.output_tokens", response.output_tokens)
        return response
```

**Anmerkung**  
Wenn Sie Traces an Amazon OpenSearch Service senden, verwenden Sie Ihren OpenSearch Ingestion-Pipeline-Endpunkt mit SigV4-Authentifizierung anstelle eines Localhost-Endpunkts. Weitere Informationen zur Konfiguration von OpenSearch Ingestion-Pipelines finden Sie unter. [Überblick über Amazon OpenSearch Ingestion](ingestion.md)

### So zeigen Sie Traces in der Benutzeroberfläche an OpenSearch
<a name="observability-ai-view-traces"></a>

Nachdem Ihre instrumentierte Anwendung Trace-Daten gesendet hat, können Sie sie in der OpenSearch Benutzeroberfläche untersuchen. Erweitern Sie in Ihrem Observability-Workspace in der linken Navigationsleiste die Option **Discover** und wählen Sie **Agent** Traces aus.

## Benutzeroberfläche für Agentenverfolgung
<a name="observability-ai-agent-tracing"></a>

Die Seite „Agent Traces“ in der OpenSearch Benutzeroberfläche bietet eine speziell entwickelte Oberfläche zum Erkunden, Debuggen und Überwachen von LLM-Agent-Ausführungsabläufen. Sie bietet Entwicklern und Plattformbetreibern einen vollständigen Überblick über die KI-Anwendungen von Agenturen, einschließlich hierarchischer Trace-Ansichten, Detail-Flyouts, Ablaufvisualisierungen und aggregierter Metriken.

### Architektur
<a name="observability-ai-architecture"></a>

Das folgende Diagramm zeigt den Datenfluss von instrumentierten Anwendungen zur Agent Traces-Benutzeroberfläche:

```
LLM Application (with OTel SDK + GenAI instrumentation)
    |
    |  OTLP (gRPC/HTTP)
    v
OTel Collector (batch, transform)
    |
    +---- OTLP ----> OpenSearch Ingestion --> OpenSearch (otel-v1-apm-span-*)
    |
    +---- Prometheus Remote Write --> Prometheus (metrics)
                                          |
                                          v
                              OpenSearch UI
                              +-- Agent Traces Plugin
```

### Voraussetzungen
<a name="observability-ai-prereqs"></a>

Bevor Sie Agent Traces verwenden, stellen Sie sicher, dass Sie über Folgendes verfügen:
+ Ein OpenSearch Cluster mit in `otel-v1-apm-span-*` Indizes indizierten Trace-Daten.
+ OpenTelemetry Instrumentierung mit semantischen GenAI-Konventionen, die in Ihrer LLM-Anwendung aktiviert sind.
+ OpenSearch Die Datenaufnahme ist mit dem `otel_trace_raw` Prozessor konfiguriert, in den die Daten aufgenommen werden sollen. OpenSearch
+ PPL-Abfrageunterstützung in der Benutzeroberfläche aktiviert. OpenSearch 

### Erforderliche Span-Attribute
<a name="observability-ai-span-attributes"></a>

Agent Traces benötigt bestimmte Span-Attribute, um Trace-Daten korrekt wiederzugeben. In den folgenden Tabellen werden die Kernfelder und GENAI-spezifischen Attribute beschrieben.

**Kernspan-Felder**  
Jeder Bereich muss die folgenden Kernfelder enthalten:


| Feld | Typ | Description | 
| --- | --- | --- | 
| traceId | Zeichenfolge | Eindeutiger Bezeichner für den gesamten Trace. | 
| spanId | Zeichenfolge | Eindeutiger Bezeichner für diesen Zeitraum. | 
| parentSpanId | Zeichenfolge | Bezeichner des übergeordneten Bereichs. Leer für Wurzelbereiche. | 
| startTime | Zeitstempel | Zeitpunkt, zu dem die Spanne begann. | 
| endTime | Zeitstempel | Zeitpunkt, zu dem die Spanne endete. | 
| durationInNanos | Long | Dauer der Spanne in Nanosekunden. | 
| status.code | Ganzzahl | Span-Statuscode (0 = nicht gesetzt, 1 = OK, 2 = Fehler). | 

**GenAI-Attribute**  
Die folgenden `gen_ai.*` Attribute ermöglichen KI-spezifische Funktionen in der Benutzeroberfläche von Agent Traces:


| Attribut | Beispielwert | Description | 
| --- | --- | --- | 
| gen\$1ai.operation.name | chat | Die Art des GenAI-Vorgangs. Bestimmt die Span-Kategorie. | 
| gen\$1ai.system | openai | Das KI-System oder der Anbieter. | 
| gen\$1ai.request.model | gpt-4 | Das für die Anfrage verwendete Modell. | 
| gen\$1ai.usage.input\$1tokens | 150 | Anzahl der verbrauchten Eingabe-Token. | 
| gen\$1ai.usage.output\$1tokens | 85 | Anzahl der generierten Ausgabetokens. | 
| gen\$1ai.response.finish\$1reasons | ["stop"] | Gründe, warum das Modell die Generierung eingestellt hat. | 

### Seitenlayout und Leiste mit Metriken
<a name="observability-ai-page-layout"></a>

Auf der Seite Agenten-Traces wird oben eine Metrikleiste angezeigt, in der die wichtigsten Statistiken aller sichtbaren Traces zusammengefasst sind. Zu den Metriken gehören die Gesamtzahl der Traces, die durchschnittliche Dauer, die Fehlerrate und die Token-Nutzung. Diese Werte werden basierend auf Ihrem Zeitfilter und Ihrer Abfrage dynamisch aktualisiert.

### Registerkarte „Spuren“
<a name="observability-ai-traces-tab"></a>

Auf der Registerkarte Traces werden alle Root-Agent-Traces aufgeführt, die Ihrer aktuellen Abfrage und Ihrem aktuellen Zeitraum entsprechen. Jede Zeile steht für einen einzelnen Agentenaufruf.

![\[alt text not found\]](http://docs.aws.amazon.com/de_de/opensearch-service/latest/developerguide/images/agent-traces/traces-table.png)


In der folgenden Tabelle werden die Spalten in der Traces-Tabelle beschrieben:


| Spalte | Description | 
| --- | --- | 
| Trace-ID | Eindeutiger Bezeichner für den Trace. Wählen Sie den Link, um das Flyout mit den Ablaufverfolgungsdetails zu öffnen. | 
| Agent name (Name des Kundendienstmitarbeiters) | Name des Agenten, der die Ablaufverfolgung initiiert hat. | 
| Status | Allgemeiner Trace-Status (OK oder Fehler). | 
| Dauer | Gesamtzeit von der ersten Spanne bis zur letzten Spanne in der Ablaufverfolgung. | 
| Spans | Gesamtzahl der Spans im Trace. | 
| Eingabe-Token | Gesamtzahl der Eingabetoken, die bei allen LLM-Aufrufen im Trace verbraucht wurden. | 
| Ausgabe-Token | Gesamtzahl der Ausgabetokens, die für alle LLM-Aufrufe im Trace generiert wurden. | 
| Startzeit | Zeitstempel, als der Trace gestartet wurde. | 

### Kategorien umfassen
<a name="observability-ai-span-categories"></a>

Bereiche werden anhand des `gen_ai.operation.name` Attributs kategorisiert. Jede Kategorie wird in der Benutzeroberfläche mit einer eigenen Farbe und einem eigenen Symbol angezeigt.


| Vorgangsname | Kategorie | Description | 
| --- | --- | --- | 
| invoke\$1agent, create\$1agent | Agent | Schritt zur Orchestrierung der Agenten. | 
| chat | LLM | Anruf zum Abschluss des LLM-Chats. | 
| text\$1completion, generate\$1content | Inhalt | Vorgang zur Textgenerierung. | 
| execute\$1tool | Tool | Aufruf des Tools. | 
| embeddings | Einbettungen | Generierung einbetten. | 
| retrieval | Abruf | Vorgang zum Abrufen von Daten. | 

### Registerkarte „Spannweiten“
<a name="observability-ai-spans-tab"></a>

Auf der Registerkarte Spans werden einzelne Spans über alle Spuren hinweg angezeigt. Sie können Spans filtern und sortieren, um nach bestimmten Vorgängen zu suchen.

![\[alt text not found\]](http://docs.aws.amazon.com/de_de/opensearch-service/latest/developerguide/images/agent-traces/spans-table.png)


### Flyout „Details verfolgen“
<a name="observability-ai-trace-details"></a>

Wenn Sie eine Trace-ID auswählen, wird ein Flyout-Fenster mit zwei Hauptbereichen geöffnet:
+ **Linker Bereich** — Zeigt den Trace-Baum an, in dem die hierarchischen Beziehungen zwischen übergeordneten und untergeordneten Elementen zwischen den Bereichen dargestellt werden. Es enthält auch ein Flow-DAG (Directed Acyclic Graph), das den Ausführungspfad des Agenten visualisiert.
+ **Rechter Bereich** — Enthält zwei Registerkarten. Auf der Registerkarte „**Details**“ werden Span-Attribute, Ressourcenattribute und GENAI-spezifische Metadaten angezeigt. Auf der Registerkarte „**Zeitleiste**“ wird ein Wasserfalldiagramm mit der Dauer der Spanne und ihren zeitlichen Beziehungen angezeigt.

### Ablaufverfolgungen werden abgefragt
<a name="observability-ai-querying"></a>

Agent Traces verwendet PPL (Piped Processing Language) für den gesamten Datenabruf. Sie können Abfragen im Abfragebereich oben auf der Seite schreiben.

**Um Root-Traces aufzulisten**  
Die folgende Abfrage gibt die 100 neuesten Root-Agent-Traces zurück:

```
source = otel-v1-apm-span-*
| where parentSpanId = "" AND isnotnull(`attributes.gen_ai.operation.name`)
| sort - startTime
| head 100
```

**Um alle Spans für einen Trace abzurufen**  
Die folgende Abfrage gibt den vollständigen Span-Baum für einen bestimmten Trace zurück:

```
source = otel-v1-apm-span-*
| where traceId = "trace-id"
| head 1000
```

**Um aggregierte Metriken zu berechnen**  
Die folgende Abfrage berechnet die durchschnittliche Dauer und die gesamte Token-Nutzung, gruppiert nach Modell:

```
source = otel-v1-apm-span-*
| where isnotnull(`attributes.gen_ai.request.model`)
| stats avg(durationInNanos) as avg_duration,
        sum(`attributes.gen_ai.usage.input_tokens`) as total_input_tokens,
        sum(`attributes.gen_ai.usage.output_tokens`) as total_output_tokens
    by `attributes.gen_ai.request.model`
```