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.
# Überwachung von Beanstalk Cluster-Umgebungen
Eine Beanstalk Cluster-Umgebung meldet den Zustand auf Umgebungsebene mithilfe des gleichen Elastic Beanstalk-Integritätsmodells und der gleichen APIs wie eine Beanstalk Standard-Umgebung. Sie sehen die Farbe und den Status des Zustands in der Elastic Beanstalk-Konsole. Sie können anrufen, um die aktuelle Farbe, den Status und die Ursachen dafür `DescribeEnvironmentHealth` zu erfahren. Gesundheitsfarben und -status haben in beiden Modi dieselbe Bedeutung.
Wenn eine Beanstalk-Cluster-Umgebung einen Application Load Balancer verwendet, bestimmt Elastic Beanstalk den Zustand der Anwendung anhand der Load Balancer-Metriken der Umgebung: der Anforderungsrate, dem Anteil der Anfragen, die HTTP 4xx- und 5xx-Antworten zurückgeben, und der Antwortlatenz. Eine Umgebung, die Anfragen erfolgreich verarbeitet, meldet einen fehlerfreien Status. Wenn der Anteil der fehlgeschlagenen Anfragen steigt, wird der Status zunehmend schwerwiegender. Eine Umgebung, die zu wenig Traffic empfängt, als dass Elastic Beanstalk sie auswerten könnte, meldet, dass die Anforderungsrate nicht ausreicht, um den Zustand zu ermitteln, was bei einer Umgebung im Leerlauf zu erwarten ist. Wenn Sie den Load Balancer-Typ auf einstellen`None`, gilt diese Load Balancer-Evaluierung nicht.
Im Gegensatz zu einer Beanstalk Standard-Umgebung wird in einer Beanstalk Cluster-Umgebung der Zustand nicht pro Instanz gemeldet. Beanstalk Cluster verwendet nicht den Health Agent auf der Instanz, und die Einstellungen für Integritätsberichte auf Instanzebene, die für Standardumgebungen gelten, gelten nicht.
Container-Probes steuern, wann Anwendungsreplikate Traffic empfangen und wann sie neu gestartet werden: Ein Readiness-Test entfernt eine noch nicht betriebsbereite Kopie aus dem Betrieb, ein Liveness Test startet eine Kopie neu, die fehlerhaft bleibt, und ein Starttest gibt eine langsam startende Kopierzeit für die Initialisierung an. Konfigurieren Sie `aws:elasticbeanstalk:eks:environment` die Probes mit den Test-Namespaces unter. Siehe [Die Namespaces der Container-Probe](command-options-general-eks.md#command-options-eks-probes).
## Metriken, Logs und Traces
Die Beobachtbarkeit von Anwendungen ist unabhängig vom Zustand der Umgebung. Sie wählen die Backends für die Metriken, Logs und Traces Ihrer Anwendung mit den Konfigurationsoptionen im `aws:elasticbeanstalk:eks:observability` Namespace aus. Standardmäßig sendet Elastic Beanstalk die Metriken und Logs Ihrer Anwendung an Amazon CloudWatch (CloudWatch), und Traces haben kein Backend. Sie können stattdessen Protokolle an Amazon S3 senden, Metriken an Amazon Managed Service for Prometheus senden und Traces an senden. AWS X-Ray Sie können jedes der drei auch an ein Backend eines Drittanbieters senden, das OpenTelemetry Daten akzeptiert; siehe. [Senden von Observability-Daten an ein Backend eines Drittanbieters](#monitoring-cluster-environments-custom-backend) Die verfügbaren Optionen finden Sie unter[aws:elasticbeanstalk:eks:observability](command-options-general-eks.md#command-options-eks-observability).
Elastic Beanstalk stellt die Erfassungskomponenten bereit und betreibt sie und veröffentlicht Infrastrukturkennzahlen in Ihrem Namen. Sie sind dafür verantwortlich, Ihre Anwendung so zu instrumentieren, dass sie die von Ihnen gewünschten Metriken, Logs und Traces ausgibt, und den Zugriff auf jedes von Ihnen gewählte Ziel bereitzustellen und aufrechtzuerhalten.
Ihre Anwendung muss OpenTelemetry Daten ausgeben, damit ein Backend alles empfangen kann. Um dies zu erreichen, ohne Ihre Anwendung zu ändern, setzen Sie die `language` Option im `aws:elasticbeanstalk:eks:environment` Namespace auf die Laufzeit Ihrer Anwendung. Elastic Beanstalk fügt Ihrem Container eine OpenTelemetry automatische Instrumentierung für diese Laufzeit hinzu, was für jedes Backend und für Drittanbieter gleichermaßen gilt. AWS Auto-instrumentation ist für Java-, Python- Node.js und.NET-Anwendungen verfügbar. Bei einer Java-Anwendung überbrückt der Agent außerdem Log4j2, Logback und, sodass die Logs Ihrer Anwendung das Log-Backend erreichen`java.util.logging`, ohne dass Änderungen an der Anwendung erforderlich sind.
Unabhängig vom Logs-Backend erfasst Elastic Beanstalk ein Deployment-Log für jeden Umgebungsvorgang. Es enthält die Container-Logs Ihrer Pods und die Kubernetes-Ereignisse des Vorgangs und ist somit der Ort, an dem Sie nachschauen können, wenn ein Vorgang fehlschlägt. Weitere Informationen finden Sie unter [Bereitstellungsprotokolle](environments-deployment-logs.md).
### Deine Logs und Metriken findest du in CloudWatch
Mit den Standard-Backends schreibt Elastic Beanstalk in vier CloudWatch Loggruppen. Die Namen der Loggruppen sind fest und Sie können sie nicht ändern.
**CloudWatch Protokollgruppen für Beanstalk Cluster-Umgebungen**
| **Gruppe protokollieren ** | **Inhalt** | **Name des Datenstroms protokollieren ** | **Wenn es existiert ** |
| --- | --- | --- | --- |
| `/aws/elasticbeanstalk/application/logs` | Ausgabe aus den Containern Ihrer Anwendung. | `eb-{{environment-name}}.{{pod-name}}` | Wann `logs-backend` ist`cloudwatch`, die Standardeinstellung. |
| `/aws/elasticbeanstalk/application/metrics` | Metriken, die Ihre Anwendung ausgibt. | `{{environment-name}}/{{pod-name}}` | Wann `metrics-backend` ist das`cloudwatch`, die Standardeinstellung, und Ihre Anwendung gibt Metriken aus. |
| `/aws/elasticbeanstalk/infrastructure/logs` | Ausgabe der Komponenten, die Elastic Beanstalk in Ihrem Namen auf dem Cluster ausführt. | `{{kubernetes-namespace}}.{{pod-name}}` | Immer. |
| `/aws/elasticbeanstalk/infrastructure/metrics` | Die Metriken, die Elastic Beanstalk für Sie veröffentlicht, im eingebetteten Metrikformat. | `{{kubernetes-namespace}}.{{pod-name}}` | Immer. |
**Anmerkung**
Diese Protokollgruppen werden gemeinsam genutzt. Jede Beanstalk-Cluster-Umgebung in einem AWS Konto und einer Region schreibt in allen Clustern in dieselben vier Gruppen. Die Daten Ihrer Umgebung sind durch den Namen des Log-Streams getrennt, nicht durch die Log-Gruppe. Elastic Beanstalk führt jede Umgebung in einem Kubernetes-Namespace aus, dem der Umgebungsname `eb-` folgt, sodass die Logstreams Ihrer Anwendung mit einem Punkt beginnen. `eb-{{environment-name}}` Die Metrik-Streams Ihrer Anwendung beginnen mit dem Umgebungsnamen und einem Schrägstrich ohne Präfix. `eb-`
Elastic Beanstalk erstellt diese Protokollgruppen ohne Aufbewahrungsrichtlinie, sodass ihr Inhalt niemals abläuft. Die Namen der Log-Streams enthalten den Pod-Namen, sodass bei jeder Bereitstellung neue Streams erstellt werden und die Streams aus früheren Bereitstellungen erhalten bleiben. Legen Sie für jede Protokollgruppe eine Aufbewahrungsrichtlinie fest, um zu begrenzen, was Sie speichern.
Die Metriken, die Elastic Beanstalk für Sie veröffentlicht, kommen in drei CloudWatch Namespaces an. Bei allen drei handelt es sich um benutzerdefinierte Namespaces, für die Sie pro Metrik bezahlen. Beanstalk Standard-Umgebungen veröffentlichen stattdessen im `AWS/ElasticBeanstalk` Namespace, der kostenlos zur Verfügung steht. CloudWatch Eine Beanstalk Cluster-Umgebung veröffentlicht die unten aufgeführten Container-Metriken für jedes ihrer Replikate, sodass die Anzahl der benutzerdefinierten Metriken mit der Anzahl der von Ihnen ausgeführten Replikate wächst. Die aktuellen Tarife finden Sie unter Amazon-Preise. [ CloudWatch ](https://aws.amazon.com/cloudwatch/pricing/)
**CloudWatch Metriken für Beanstalk Cluster-Umgebungen**
| **Namespace** | **Metriken** | **Dimensions (Abmessungen)** |
| --- | --- | --- |
| `ElasticBeanstalk/Infrastructure` | Für die Container Ihrer Anwendung:`container_cpu_usage_seconds_total`, und `container_memory_working_set_bytes``EnvironmentReplicas`, die Anzahl der Replikate, die bereit sind. | Die beiden Container-Metriken werden mit `namespace``pod`, `container` und wieder mit `namespace` alleine veröffentlicht. `EnvironmentReplicas`wird `namespace` nur mit veröffentlicht. |
| `ElasticBeanstalk/System` | Dieselben beiden Container-Metriken für die Komponenten, die Elastic Beanstalk in Ihrem Namen auf dem Cluster ausführt, und nicht für Ihre Anwendung. | `namespace`, `pod``container`, und wieder mit `namespace` alleine. |
| `ElasticBeanstalk/Application` | Die Metriken, die Ihre Anwendung ausgibt, einschließlich der Laufzeit-Metriken, die von der automatischen Instrumentierung generiert werden. | `EnvironmentName`. Die Dauer der Anfrage wird auch mit `http.method``http.route`, und veröffentlicht`http.status_code`. |
Die `namespace` Dimension ist der Kubernetes-Namespace, daher `eb-` folgt auf ihren Wert der Name Ihrer Umgebung. Der `ElasticBeanstalk/Application` Namespace verwendet stattdessen eine `EnvironmentName` Dimension, deren Wert der eigenständige Umgebungsname ist. Verwenden Sie den Wert, der dem Namespace entspricht, den Sie abfragen.
Wenn Sie `logs-backend` auf setzen`s3`, schreibt Elastic Beanstalk die Logs Ihrer Anwendung in einen Bucket mit dem Namen `elasticbeanstalk-logs-{{account-id}}-{{region}}-an` stattdessen, und zwar unter einem Schlüssel, der aus dem Kubernetes-Namespace, dem Pod-Namen und dem Datum erstellt wurde, und nichts geht an. `/aws/elasticbeanstalk/application/logs` Elastic Beanstalk fasst diese Uploads stapelweise zusammen, sodass es bis zu einer Minute dauern kann, bis ein Objekt angezeigt wird. Wenn Sie `logs-backend` oder `metrics-backend` so einstellen`custom`, werden diese Daten an das von Ihnen konfigurierte Backend weitergeleitet und erscheinen in keiner dieser Protokollgruppen. Siehe [Senden von Observability-Daten an ein Backend eines Drittanbieters](#monitoring-cluster-environments-custom-backend).
## Senden von Observability-Daten an ein Backend eines Drittanbieters
Beanstalk Cluster sammelt die Telemetrie Ihrer Anwendung mit dem OpenTelemetry Collector, sodass Sie sie an jedes Backend senden können, das OpenTelemetry Daten akzeptiert, wie Datadog oder Splunk, anstatt an ein Ziel. AWS Sie geben die Pipeline-Konfiguration und die benötigten Anmeldeinformationen an, und Elastic Beanstalk führt Ihre Pipeline als Sidecar-Container im Pod Ihrer Anwendung aus.
Für die Konfiguration eines Drittanbieter-Backends sind vier Dinge erforderlich:
1. Stellen Sie jedes Signal ein, zu dem Sie umleiten möchten`custom`. Die Signale sind unabhängig, sodass Sie Metriken und Logs an ein Backend eines Drittanbieters senden können, während die Traces AWS X-Ray weiterlaufen. Verwenden Sie `metrics-backend``logs-backend`, und `traces-backend` im `aws:elasticbeanstalk:eks:observability` Namespace.
1. Auf `custom-config` die Pipeline-Konfiguration des Collectors als JSON setzen. Verweisen Sie auf jeden Berechtigungsnachweis als `${{{NAME}}}` Platzhalter, anstatt den Wert in die Konfiguration aufzunehmen.
1. Speichern Sie die Anmeldeinformationen in AWS Secrets Manager und setzen Sie `custom-credentials` sie auf den ARN des Secrets. Der geheime Wert muss ein JSON-Objekt sein, dessen Schlüssel den Platzhalternamen in Ihrer Konfiguration entsprechen.
1. Stellen Sie die `application-role` Option im `aws:elasticbeanstalk:eks:environment` Namespace ein und gewähren Sie dieser Rolle die Erlaubnis, das Geheimnis zu lesen. Der Collector verwendet zur Laufzeit die Anwendungsrolle, nicht die Observability-Rolle, und er erreicht das Secret über die Identität des Pods, die nur existiert, wenn sie gesetzt `application-role` ist. Ohne sie schlägt das Mounten fehl und Ihre Replikate werden nie gestartet.
Das folgende Beispiel sendet Metriken und Logs an Datadog und führt die Traces weiter. AWS X-Ray Erstellen Sie zunächst das Geheimnis, das die Anmeldeinformationen enthält, auf die Ihre Konfiguration verweist:
```
$ aws secretsmanager create-secret \
--name {{my-app/otel-credentials}} \
--secret-string '{"DD_API_KEY":"{{your-api-key}}"}'
```
Erteilen Sie der Anwendungsrolle die Berechtigung, es zu lesen, damit der Collector es zur Laufzeit abrufen kann:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue",
"secretsmanager:DescribeSecret"
],
"Resource": "{{arn:aws:secretsmanager:us-east-1:111122223333:secret:my-app/otel-credentials-AbCdEf}}"
}
]
}
```
Elastic Beanstalk aktualisiert die bereitgestellten Anmeldeinformationen nach einem Zeitplan, und bei der Aktualisierung wird die aktuelle Version des Secrets überprüft. Gewähren `secretsmanager:DescribeSecret` Sie also zusätzlich. `secretsmanager:GetSecretValue` Eine Umgebung beginnt mit `GetSecretValue` alleine, aber jede spätere Aktualisierung schlägt fehl.
Als Nächstes fügen Sie die Optionseinstellungen in eine Datei ein. Eine Collector-Konfiguration enthält Kommas, die in der Kurzsyntax von als Trennzeichen `--option-settings` behandelt werden. Übergeben Sie die Einstellungen daher stattdessen als JSON. Speichern Sie Folgendes unter`options.json`, wobei die Pipeline-Konfiguration als JSON-Zeichenfolge im Wert enthalten ist: `custom-config`
```
[
{
"Namespace": "aws:elasticbeanstalk:eks:observability",
"OptionName": "metrics-backend",
"Value": "custom"
},
{
"Namespace": "aws:elasticbeanstalk:eks:observability",
"OptionName": "logs-backend",
"Value": "custom"
},
{
"Namespace": "aws:elasticbeanstalk:eks:observability",
"OptionName": "traces-backend",
"Value": "xray"
},
{
"Namespace": "aws:elasticbeanstalk:eks:observability",
"OptionName": "custom-config",
"Value": "{\"receivers\":{\"otlp\":{\"protocols\":{\"grpc\":{\"endpoint\":\"0.0.0.0:4317\"},\"http\":{\"endpoint\":\"0.0.0.0:4318\"}}}},\"processors\":{\"batch\":{}},\"exporters\":{\"datadog\":{\"api\":{\"site\":\"{{datadoghq.com}}\",\"key\":\"${DD_API_KEY}\"}}},\"service\":{\"pipelines\":{\"metrics\":{\"receivers\":[\"otlp\"],\"processors\":[\"batch\"],\"exporters\":[\"datadog\"]},\"logs\":{\"receivers\":[\"otlp\"],\"processors\":[\"batch\"],\"exporters\":[\"datadog\"]}}}}"
},
{
"Namespace": "aws:elasticbeanstalk:eks:observability",
"OptionName": "custom-credentials",
"Value": "{{arn:aws:secretsmanager:us-east-1:111122223333:secret:my-app/otel-credentials-AbCdEf}}"
}
]
```
Stellen Sie `site` die Datadog-Website ein, die Ihre Organisation verwendet. Wenden Sie dann die Datei an:
```
$ aws elasticbeanstalk update-environment \
--environment-name {{my-cluster-env}} \
--option-settings file://options.json
```
Definieren Sie eine Pipeline für jedes Signal, das Sie auf einstellen`custom`. Ein Signal, das Sie an einem AWS Ziel hinterlassen, verwendet weiterhin die Sammlung, die Elastic Beanstalk betreibt, und benötigt keine eigene Pipeline.
Für Komponenten ohne Einstellungen wird ein leeres Objekt verwendet, z. B. `"batch": {}` Der `receivers` Block ist optional. Wenn Sie ihn weglassen, fügt Elastic Beanstalk den OTLP-Empfänger hinzu, an den Ihre Anwendung sendet, und zeichnet ein Umgebungsereignis auf, das den Zusatz meldet. Das vorherige Beispiel definiert den Empfänger explizit.
Fügen Sie bei der Einrichtung jeder Pipeline einen `debug` Exporter hinzu und nehmen Sie ihn in die `exporters` Liste der Pipeline auf. Der Collector protokolliert dann die Telemetrie, die er empfängt und exportiert. Dadurch erfahren Sie, ob Daten den Collector erreichen, und separat, ob der Collector Ihr Backend erreichen kann.