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.
# Überwachungsumgebungen in Elastic Beanstalk
Mit Elastic Beanstalk Health Monitoring können Sie die Verfügbarkeit von Anwendungen überprüfen und Warnmeldungen erstellen, die aktiviert werden, wenn die Messwerte Ihre Schwellenwerte überschreiten. Sie können Elastic Beanstalk Health Monitoring sowohl in der Konsole als auch in der Befehlszeile verwenden, um den Status Ihrer Umgebung zu verfolgen.
**Topics**
+ [Überwachung des Zustands der Umgebung in der AWS Managementkonsole](environment-health-console.md)
+ [Verwenden der EB-CLI zur Überwachung des Umgebungszustands](health-enhanced-ebcli.md)
+ [Grundlegende Zustandsberichte](using-features.healthstatus.md)
+ [Verbesserte Gesundheitsberichterstattung und Überwachung in Elastic Beanstalk](health-enhanced.md)
+ [Alarme verwalten](using-features.alarms.md)
+ [Anzeigen des Änderungsverlaufs einer Elastic Beanstalk-Umgebung](using-features.changehistory.md)
+ [Ereignis-Stream einer Elastic Beanstalk-Umgebung anzeigen](using-features.events.md)
+ [Auflisten von Server-Instances/Verbinden mit Server-Instances](using-features.ec2connect.md)
+ [Protokolle von Amazon EC2-Instances in Ihrer Elastic Beanstalk Umgebung anzeigen](using-features.logging.md)
+ [Bereitstellungsprotokolle für eine Elastic Beanstalk Beanstalk-Umgebung anzeigen](environments-deployment-logs.md)
# Überwachung des Zustands der Umgebung in der AWS Managementkonsole
Sie können über die Elastic Beanstalk-Konsole auf operative Informationen zu Ihrer Anwendung zugreifen. Umgebungsstatus und Anwendungszustand werden in der Konsole übersichtlich dargestellt. Auf der Seite **Environments (Umgebungen)** der Konsole und auf der Seite jeder Anwendung werden die Umgebungen in der Liste farbcodiert, um den Status anzuzeigen.
**So überwachen Sie eine Umgebung in der Elastic Beanstalk-Konsole**
1. Öffnen Sie die [Elastic Beanstalk Beanstalk-Konsole](https://console.aws.amazon.com/elasticbeanstalk) und wählen Sie in der Liste **Regionen** Ihre aus. AWS-Region
1. Wählen Sie im Navigationsbereich **Environments (Umgebungen)** aus und wählen Sie dann in der Liste den Namen Ihrer Umgebung aus.
1. Wählen Sie im Navigationsbereich **Monitoring (Überwachung)** aus.
Auf der Seite "Monitoring" werden allgemeine Statistikwerte zur Umgebung angegeben, z. B. CPU-Auslastung und durchschnittliche Latenz. Neben diesen allgemeinen Statistikdaten können Sie Überwachungsdiagramme mit der Ressourcennutzung im Verlauf der Zeit aufrufen. Klicken Sie auf ein Diagramm, um detailliertere Informationen zu sehen.
**Anmerkung**
Standardmäßig sind nur CloudWatch Basismetriken aktiviert, die Daten innerhalb von fünf Minuten zurückgeben. Sie können detailliertere CloudWatch Ein-Minuten-Metriken aktivieren, indem Sie die Konfigurationseinstellungen Ihrer Umgebung bearbeiten.
## Überwachungsdiagramme
Die Seite **Überwachung** zeigt eine Übersicht über die Zustandsdaten für Ihre Umgebung an. Dazu gehören die von Elastic Load Balancing und Amazon bereitgestellten Standardmetriken sowie Grafiken EC2, die zeigen, wie sich der Zustand der Umgebung im Laufe der Zeit verändert hat.
Die Leiste über den Grafiken bietet eine Vielzahl von Zeitintervallen, aus denen Sie auswählen können. Wählen Sie beispielsweise **1w** aus, um Informationen anzuzeigen, die sich über die letzte Woche erstrecken. Oder wählen Sie **3h**, um Informationen aus den letzten drei Stunden anzuzeigen.
Wählen Sie **Benutzerdefiniert**, um eine größere Auswahl an Zeitintervallen zu erhalten. Von hier aus haben Sie zwei Bereichsoptionen: *Absolut* oder *Relativ*. Mit der Option **Absolut** können Sie einen bestimmten Datumsbereich angeben, z. B. den *1. Januar 2023 bis 30. Juni 2023*. Die Option **Relativ** ermöglicht die Auswahl einer Ganzzahl mit einer bestimmten Zeiteinheit: *Minuten*, *Stunden*, *Tage*, *Wochen* oder *Monate*. Beispiele hierfür sind *10 Stunden*, *10 Tage* und *10 Monate*.
![\[Abschnitt zur Überwachung des Umgebungszustands auf der Seite zur Umgebungsüberwachung der Elastic Beanstalk-Konsole\]](http://docs.aws.amazon.com/de_de/elasticbeanstalk/latest/dg/images/environment-monitoring-graphs.png)
## Anpassen der Überwachungskonsole
Um benutzerdefinierte Metriken zu erstellen und anzuzeigen, müssen Sie Amazon verwenden CloudWatch. Mit können CloudWatch Sie benutzerdefinierte Dashboards erstellen, um Ihre Ressourcen in einer einzigen Ansicht zu überwachen. Wählen Sie **Zum Dashboard hinzufügen**, um von der **Monitoring-Seite zur CloudWatch ** Amazon-Konsole zu gelangen. Amazon CloudWatch bietet Ihnen die Möglichkeit, ein neues Dashboard zu erstellen oder ein vorhandenes auszuwählen. Weitere Informationen finden Sie unter [Verwenden von CloudWatch Amazon-Dashboards](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) im * CloudWatch Amazon-Benutzerhandbuch*.
![\[Abschnitt zur Überwachung des Umgebungszustands auf der Seite zur Umgebungsüberwachung der Elastic Beanstalk-Konsole\]](http://docs.aws.amazon.com/de_de/elasticbeanstalk/latest/dg/images/environment-monitoring-graphs.png)
[Elastic Load Balancing](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/elb-metricscollected.html) und [ EC2Amazon-Metriken](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/ec2-metricscollected.html) sind für alle Umgebungen aktiviert.
Bei [verbesserter Integrität](health-enhanced.md) ist die EnvironmentHealth Metrik aktiviert und der Überwachungskonsole wird automatisch ein Diagramm hinzugefügt. Zudem wird mit erweiterten Zustandsberichten auch eine [Zustandsprüfungsseite](health-enhanced-console.md#health-enhanced-console-healthpage) zur Management Console hinzugefügt. Eine Liste der verfügbaren erweiterten Zustandsmetriken finden Sie unter [Veröffentlichen CloudWatch benutzerdefinierter Amazon-Metriken für eine Umgebung](health-enhanced-cloudwatch.md).
# Verwenden der EB-CLI zur Überwachung des Umgebungszustands
Das [Elastic Beanstalk Command Line Interface](eb-cli3.md) (EB CLI) ist ein Befehlszeilentool für die Verwaltung von AWS Elastic Beanstalk Umgebungen. Sie können die EB CLI auch zum Überwachen des Zustands der Umgebung in Echtzeit einsetzen. Dabei bietet sie mehr Granularität, als derzeit in der Elastic Beanstalk-Konsole verfügbar ist.
Nach der [Installation](eb-cli3.md#eb-cli3-install) und [Konfiguration](eb-cli3-configuration.md) der EB-CLI können Sie eine neue Umgebung starten und Ihren Code mit dem **eb create** Befehl darauf bereitstellen. Wenn Sie bereits über eine Umgebung verfügen, die Sie in der Elastic Beanstalk-Konsole erstellt haben, können Sie die EB CLI anfügen, indem Sie **eb init** in einem Projektordner ausführen und die Anweisungen auf dem Bildschirm befolgen (der Projektordner kann leer sein).
**Wichtig**
Stellen Sie sicher, dass Sie die neueste Version der EB CLI verwenden, indem Sie `pip install` mit der `--upgrade`-Option ausführen:
```
$ sudo pip install --upgrade awsebcli
```
Vollständige Anweisungen zur EB CLI-Installation finden Sie unter [EB CLI mit Setup-Skript installieren (empfohlen)](eb-cli3.md#eb-cli3-install).
Zum Verwenden der EB CLI für die Zustandsüberwachung Ihrer Umgebung müssen Sie zuerst einen lokalen Projektordner konfigurieren, indem Sie **eb init** ausführen und die Anweisungen befolgen. Vollständige Anweisungen finden Sie unter [Konfigurieren der EB CLI](eb-cli3-configuration.md).
Wenn Sie bereits über eine Umgebung in Elastic Beanstalk verfügen und die EB CLI für ihre Zustandsüberwachung verwenden möchten, fügen Sie sie mit diesem Verfahren die vorhandene Umgebung an.
**So fügen Sie die EB CLI an eine vorhandene Umgebung an**
1. Öffnen Sie ein Befehlszeilen-Terminal und navigieren Sie zu Ihrem Benutzerordner.
1. Erstellen und öffnen Sie einen neuen Ordner für Ihre Umgebung.
1. Führen Sie den **eb init**-Befehl aus und wählen Sie dann die Anwendung und die Umgebung, deren Zustand Sie überwachen möchten. Wenn Sie nur eine Umgebung haben, auf der die ausgewählte Anwendung ausgeführt wird, wählt die EB CLI diese automatisch aus, und Sie müssen die Umgebung nicht auswählen, wie im folgenden Beispiel gezeigt.
```
~/project$ eb init
Select an application to use
1) elastic-beanstalk-example
2) [ Create new Application ]
(default is 2): 1
Select the default environment.
You can change this later by typing "eb use [environment_name]".
1) elasticBeanstalkEx2-env
2) elasticBeanstalkExa-env
(default is 1): 1
```
**So überwachen Sie den Zustand mit der EB CLI**
1. Öffnen Sie eine Befehlszeile und navigieren Sie zu Ihrem Projektordner.
1. Führen Sie den **eb health**-Befehl zum Anzeigen des Zustands der Instances in Ihrer Umgebung aus. In diesem Beispiel gibt es fünf Instances, die in einer Linux-Umgebung ausgeführt werden.
```
~/project $ eb health
elasticBeanstalkExa-env Ok 2015-07-08 23:13:20
WebServer Ruby 2.1 (Puma)
total ok warning degraded severe info pending unknown
5 5 0 0 0 0 0 0
instance-id status cause health
Overall Ok
i-d581497d Ok
i-d481497c Ok
i-136e00c0 Ok
i-126e00c1 Ok
i-8b2cf575 Ok
instance-id r/sec %2xx %3xx %4xx %5xx p99 p90 p75 p50 p10 requests
Overall 671.8 100.0 0.0 0.0 0.0 0.003 0.002 0.001 0.001 0.000
i-d581497d 143.0 1430 0 0 0 0.003 0.002 0.001 0.001 0.000
i-d481497c 128.8 1288 0 0 0 0.003 0.002 0.001 0.001 0.000
i-136e00c0 125.4 1254 0 0 0 0.004 0.002 0.001 0.001 0.000
i-126e00c1 133.4 1334 0 0 0 0.003 0.002 0.001 0.001 0.000
i-8b2cf575 141.2 1412 0 0 0 0.003 0.002 0.001 0.001 0.000
instance-id type az running load 1 load 5 user% nice% system% idle% iowait% cpu
i-d581497d t2.micro 1a 12 mins 0.0 0.04 6.2 0.0 1.0 92.5 0.1
i-d481497c t2.micro 1a 12 mins 0.01 0.09 5.9 0.0 1.6 92.4 0.1
i-136e00c0 t2.micro 1b 12 mins 0.15 0.07 5.5 0.0 0.9 93.2 0.0
i-126e00c1 t2.micro 1b 12 mins 0.17 0.14 5.7 0.0 1.4 92.7 0.1
i-8b2cf575 t2.micro 1c 1 hour 0.19 0.08 6.5 0.0 1.2 92.1 0.1
instance-id status id version ago deployments
i-d581497d Deployed 1 Sample Application 12 mins
i-d481497c Deployed 1 Sample Application 12 mins
i-136e00c0 Deployed 1 Sample Application 12 mins
i-126e00c1 Deployed 1 Sample Application 12 mins
i-8b2cf575 Deployed 1 Sample Application 1 hour
```
In diesem Beispiel gibt es eine Instance, die in einer Windows-Umgebung ausgeführt wird.
```
~/project $ eb health
WindowsSampleApp-env Ok 2018-05-22 17:33:19
WebServer IIS 10.0 running on 64bit Windows Server 2016/2.2.0
total ok warning degraded severe info pending unknown
1 1 0 0 0 0 0 0
instance-id status cause health
Overall Ok
i-065716fba0e08a351 Ok
instance-id r/sec %2xx %3xx %4xx %5xx p99 p90 p75 p50 p10 requests
Overall 13.7 100.0 0.0 0.0 0.0 1.403 0.970 0.710 0.413 0.079
i-065716fba0e08a351 2.4 100.0 0.0 0.0 0.0 1.102* 0.865 0.601 0.413 0.091
instance-id type az running % user time % privileged time % idle time cpu
i-065716fba0e08a351 t2.large 1b 4 hours 0.2 0.1 99.7
instance-id status id version ago deployments
i-065716fba0e08a351 Deployed 2 Sample Application 4 hours
```
## Lesen der Ausgabe
Die Ausgabe zeigt den Namen der Umgebung, den Gesamtzustand der Umgebung und das aktuelle Datum oben im Bildschirm an.
```
elasticBeanstalkExa-env Ok 2015-07-08 23:13:20
```
In den nächsten drei Zeilen werden der Umgebungstyp (in diesem Fall“ WebServer "), die Konfiguration (Ruby 2.1 mit Puma) und eine Aufschlüsselung der Anzahl der Instanzen in jedem der sieben Status angezeigt.
```
WebServer Ruby 2.1 (Puma)
total ok warning degraded severe info pending unknown
5 5 0 0 0 0 0 0
```
Der Rest der Ausgabe in vier Abschnitte unterteilt. Der erste zeigt den *Status* und den *Grund* des Status für die gesamte Umgebung und anschließend für jede Instance an. Das folgende Beispiel zeigt zwei Instances in der Umgebung mit dem Status `Info` und einem Grund, der besagt, dass eine Bereitstellung gestartet wurde.
```
instance-id status cause health
Overall Ok
i-d581497d Info Performing application deployment (running for 3 seconds)
i-d481497c Info Performing application deployment (running for 3 seconds)
i-136e00c0 Ok
i-126e00c1 Ok
i-8b2cf575 Ok
```
Weitere Informationen über Zustand und Farben finden Sie unter [Farben und Status in Zustandsangaben](health-enhanced-status.md).
Der Abschnitt **requests** enthält Informationen aus den Webserverprotokollen zu jeder Instance. In diesem Beispiel nimmt jede Instance Anfragen normal an und es gibt keine Fehler.
```
instance-id r/sec %2xx %3xx %4xx %5xx p99 p90 p75 p50 p10 requests
Overall 13.7 100.0 0.0 0.0 0.0 1.403 0.970 0.710 0.413 0.079
i-d581497d 2.4 100.0 0.0 0.0 0.0 1.102* 0.865 0.601 0.413 0.091
i-d481497c 2.7 100.0 0.0 0.0 0.0 0.842* 0.788 0.480 0.305 0.062
i-136e00c0 4.1 100.0 0.0 0.0 0.0 1.520* 1.088 0.883 0.524 0.104
i-126e00c1 2.2 100.0 0.0 0.0 0.0 1.334* 0.791 0.760 0.344 0.197
i-8b2cf575 2.3 100.0 0.0 0.0 0.0 1.162* 0.867 0.698 0.477 0.076
```
Der Abschnitt **cpu** enthält Betriebssystemmetriken für jede Instance. Die Ausgabe unterscheidet sich je nach Betriebssystem. Hier sehen Sie die Ausgabe für Linux-Umgebungen.
```
instance-id type az running load 1 load 5 user% nice% system% idle% iowait% cpu
i-d581497d t2.micro 1a 12 mins 0.0 0.03 0.2 0.0 0.0 99.7 0.1
i-d481497c t2.micro 1a 12 mins 0.0 0.03 0.3 0.0 0.0 99.7 0.0
i-136e00c0 t2.micro 1b 12 mins 0.0 0.04 0.1 0.0 0.0 99.9 0.0
i-126e00c1 t2.micro 1b 12 mins 0.01 0.04 0.2 0.0 0.0 99.7 0.1
i-8b2cf575 t2.micro 1c 1 hour 0.0 0.01 0.2 0.0 0.1 99.6 0.1
```
Und hier die Ausgabe für Windows-Umgebungen.
```
instance-id type az running % user time % privileged time % idle time
i-065716fba0e08a351 t2.large 1b 4 hours 0.2 0.0 99.8
```
Weitere Informationen über die dargestellten Server- und Betriebssystemmetriken finden Sie unter [Instance-Metriken](health-enhanced-metrics.md).
Der letzte Abschnitt **deployments** zeigt den Bereitstellungsstatus jeder Instance. Wenn eine fortlaufende Bereitstellung fehlschlägt, können Sie die Bereitstellung-ID, den Status und die angezeigte Versionsbezeichnung verwenden, um Instances in Ihrer Umgebung zu identifizieren, die mit der falschen Version ausgeführt werden.
```
instance-id status id version ago deployments
i-d581497d Deployed 1 Sample Application 12 mins
i-d481497c Deployed 1 Sample Application 12 mins
i-136e00c0 Deployed 1 Sample Application 12 mins
i-126e00c1 Deployed 1 Sample Application 12 mins
i-8b2cf575 Deployed 1 Sample Application 1 hour
```
## Interaktive Ansicht des Zustands
Der **eb health**-Befehl zeigt einen Snapshot des Zustands Ihrer Umgebung. Um die angezeigten Informationen alle zehn Sekunden zu aktualisieren, verwenden Sie die `--refresh`-Option.
```
$ eb health --refresh
elasticBeanstalkExa-env Ok 2015-07-09 22:10:04 (1 secs)
WebServer Ruby 2.1 (Puma)
total ok warning degraded severe info pending unknown
5 5 0 0 0 0 0 0
instance-id status cause health
Overall Ok
i-bb65c145 Ok Application deployment completed 35 seconds ago and took 26 seconds
i-ba65c144 Ok Application deployment completed 17 seconds ago and took 25 seconds
i-f6a2d525 Ok Application deployment completed 53 seconds ago and took 26 seconds
i-e8a2d53b Ok Application deployment completed 32 seconds ago and took 31 seconds
i-e81cca40 Ok
instance-id r/sec %2xx %3xx %4xx %5xx p99 p90 p75 p50 p10 requests
Overall 671.8 100.0 0.0 0.0 0.0 0.003 0.002 0.001 0.001 0.000
i-bb65c145 143.0 1430 0 0 0 0.003 0.002 0.001 0.001 0.000
i-ba65c144 128.8 1288 0 0 0 0.003 0.002 0.001 0.001 0.000
i-f6a2d525 125.4 1254 0 0 0 0.004 0.002 0.001 0.001 0.000
i-e8a2d53b 133.4 1334 0 0 0 0.003 0.002 0.001 0.001 0.000
i-e81cca40 141.2 1412 0 0 0 0.003 0.002 0.001 0.001 0.000
instance-id type az running load 1 load 5 user% nice% system% idle% iowait% cpu
i-bb65c145 t2.micro 1a 12 mins 0.0 0.03 0.2 0.0 0.0 99.7 0.1
i-ba65c144 t2.micro 1a 12 mins 0.0 0.03 0.3 0.0 0.0 99.7 0.0
i-f6a2d525 t2.micro 1b 12 mins 0.0 0.04 0.1 0.0 0.0 99.9 0.0
i-e8a2d53b t2.micro 1b 12 mins 0.01 0.04 0.2 0.0 0.0 99.7 0.1
i-e81cca40 t2.micro 1c 1 hour 0.0 0.01 0.2 0.0 0.1 99.6 0.1
instance-id status id version ago deployments
i-bb65c145 Deployed 1 Sample Application 12 mins
i-ba65c144 Deployed 1 Sample Application 12 mins
i-f6a2d525 Deployed 1 Sample Application 12 mins
i-e8a2d53b Deployed 1 Sample Application 12 mins
i-e81cca40 Deployed 1 Sample Application 1 hour
(Commands: Help,Quit, ▼ ▲ ◄ ►)
```
Das folgende Beispiel zeigt eine Umgebung, die kürzlich von einer auf fünf Instances hochskaliert wurde. Der Skalierungsvorgang wurde erfolgreich abgeschlossen und alle Instances bestehen nun die Zustandsprüfungen und können Anfragen annehmen. Im interaktiven Modus wird der Zustandsstatus alle zehn Sekunden aktualisiert. In der rechten oberen Ecke zählt ein Timer bis zum nächsten Update herunter.
In der linken unteren Ecke zeigt der Bericht eine Liste der Optionen an. Um den interaktiven Modus zu verlassen, drücken Sie **Q.** Drücken Sie die Pfeiltasten, um zu scrollen. Für eine Liste der zusätzlichen Befehle drücken Sie **H**.
## Optionen für die Interaktive Ansicht des Zustands
Bei der interaktiven Anzeige des Zustands der Umgebung können Sie die Ansicht über die Tastatur anpassen und Elastic Beanstalk anweisen, einzelne Instances zu ersetzen oder neu zu starten. Für eine Liste der verfügbaren Befehle während der Anzeige der Zustandsberichte im interaktiven Modus drücken Sie **H**.
```
up,down,home,end Scroll vertically
left,right Scroll horizontally
F Freeze/unfreeze data
X Replace instance
B Reboot instance
<,> Move sort column left/right
-,+ Sort order descending/ascending
P Save health snapshot data file
Z Toggle color/mono mode
Q Quit this program
Views
1 All tables/split view
2 Status Table
3 Request Summary Table
4 CPU%/Load Table
H This help menu
(press Q or ESC to return)
```
# Grundlegende Zustandsberichte
In diesem Thema werden die Funktionen von Elastic Beanstalk Basic Health erklärt.
AWS Elastic Beanstalk verwendet Informationen aus mehreren Quellen, um festzustellen, ob Ihre Umgebung verfügbar ist, und verarbeitet Anfragen aus dem Internet. Der Zustand einer Umgebung wird durch eine von vier Farben dargestellt und auf der [Umgebungsübersichtsseite](environments-console.md) der Elastic Beanstalk-Konsole angezeigt. Es ist auch über die [DescribeEnvironments](https://docs.aws.amazon.com/elasticbeanstalk/latest/api/API_DescribeEnvironments.html)API und durch Aufrufen **eb status** mit der [EB-CLI](eb-cli3.md) verfügbar.
Das grundlegende Zustandsberichtssystem bietet Informationen über den Zustand der Instances in einer Elastic Beanstalk-Umgebung basierend auf Zustandsprüfungen, die von Elastic Load Balancing für lastverteilte Umgebungen oder von Amazon Elastic Compute Cloud für Umgebungen mit einer Instance durchgeführt werden.
Elastic Beanstalk überprüft nicht nur den Zustand Ihrer EC2 Instances, sondern überwacht auch die anderen Ressourcen in Ihrer Umgebung und meldet fehlende oder falsch konfigurierte Ressourcen, die dazu führen können, dass Ihre Umgebung für Benutzer nicht verfügbar ist.
Die von den Ressourcen in Ihrer Umgebung gesammelten Metriken werden CloudWatch in Intervallen von fünf Minuten auf Amazon veröffentlicht. Dazu gehören Betriebssystemmetriken von EC2 und Anforderungsmetriken von Elastic Load Balancing. Auf der [Monitoring-Seite](environment-health-console.md) der Umgebungskonsole können Sie sich Diagramme ansehen, die auf diesen CloudWatch Metriken basieren. Für grundlegende Zustandsberichte werden diese Metriken nicht verwendet, um den Zustand einer Umgebung zu bestimmen.
**Topics**
+ [Zustandsfarben](#using-features.healthstatus.colors)
+ [Zustandsprüfungen von Elastic Load Balancing](#using-features.healthstatus.understanding)
+ [Zustandsprüfungen für Umgebungen mit einer einzelnen Instance oder Worker-Ebene](#monitoring-basic-healthcheck-singleinstance)
+ [Zusätzliche Prüfungen](#monitoring-basic-additionalchecks)
+ [CloudWatch Amazon-Metriken](#monitoring-basic-cloudwatch)
## Zustandsfarben
Elastic Beanstalk meldet den Zustand einer Webserverumgebung je nachdem, wie die Anwendung, die darin ausgeführt wird, auf die Zustandsprüfung reagiert. Elastic Beanstalk nutzt eine von vier Farben zum Beschreiben des Status, wie in der folgenden Tabelle gezeigt:
****
| Farbe | Description |
| --- | --- |
| Grau | Ihre Umgebung wird aktualisiert. |
| Grün | Ihre Umgebung ist die letzte Zustandsprüfung bestanden. Mindestens eine Instance in Ihrer Umgebung ist verfügbar und verarbeitet Anfragen. |
| Gelb | Ihre Umgebung hat eine oder mehrere Zustandsprüfungen nicht bestanden. Einige Anfragen in Ihrer Umgebung schlagen fehl. |
| Rot | Ihre Umgebung hat drei oder mehr Zustandsprüfungen nicht bestanden oder eine Umgebungsressource ist nicht mehr verfügbar. Anfragen schlagen durchgängig fehl. |
Diese Beschreibungen gelten nur für Umgebungen, die grundlegende Zustandsberichte verwenden. Unter [Farben und Status in Zustandsangaben](health-enhanced-status.md) finden Sie Details im Zusammenhang mit der erweiterten Zustandsprüfung.
## Zustandsprüfungen von Elastic Load Balancing
In einer Umgebung mit Lastenausgleich sendet Elastic Load Balancing alle 10 Sekunden eine Anfrage an jede Instance in einer Umgebung, um zu bestätigen, dass diese stabil sind. Standardmäßig ist der Load Balancer so konfiguriert, dass er eine TCP-Verbindung auf Port 80 öffnet. Wenn die Instance die Verbindung anerkennt, wird sie als stabil eingestuft.
Sie können diese Einstellung überschreiben, indem Sie eine vorhandene Ressource in Ihrer Anwendung angeben. Wenn Sie einen Pfad angeben, wie `/health`, ist die Zustandsprüfungs-URL auf `HTTP:80/health` festgelegt. Die Zustandsprüfungs-URL sollte auf einen Pfad gesetzt sein, der immer von Ihrer Anwendung bedient wird. Wenn eine statische Webseite festgelegt ist, die vom Webserver vor Ihrer Anwendung bereitgestellt oder zwischengespeichert wird, zeigen Zustandsprüfungen keine Probleme mit dem Anwendungsserver oder Webcontainer. Anweisungen zum Ändern der Zustandsprüfungs-URL finden Sie unter [Gesundheitscheck](environments-cfg-clb.md#using-features.managing.elb.healthchecks).
Wenn eine Zustandsprüfungs-URL konfiguriert ist, erwartet Elastic Load Balancing eine GET-Anfrage, auf die die Antwort `200 OK` zurückgegeben werden soll. Die Anwendung besteht die Zustandsprüfung nicht, wenn sie nicht innerhalb von fünf Sekunden reagiert oder einen anderen HTTP-Statuscode zurückgibt. Nach 5 aufeinanderfolgenden Fehlern bei der Zustandsprüfung nimmt Elastic Load Balancing die Instanz außer Betrieb.
Weitere Informationen zu den Zustandsprüfungen von Elastic Load Balancing finden Sie unter [Zustandsprüfungen](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/TerminologyandKeyConcepts.html#healthcheck) im *Elastic Load Balancing-Benutzerhandbuch*.
**Anmerkung**
Wenn Sie eine URL für die Zustandsprüfung konfigurieren, ändert dies das Verhalten einer Auto Scaling-Gruppe in der Umgebung nicht. Eine fehlerhafte Instance wird aus dem Load Balancer entfernt, aber nicht automatisch durch Amazon EC2 Auto Scaling ersetzt, es sei denn, Sie konfigurieren Amazon EC2 Auto Scaling so, dass der Elastic Load Balancing Health Check als Grundlage für das Ersetzen von Instances verwendet wird. Informationen zur Konfiguration von Amazon EC2 Auto Scaling zum Ersetzen von Instances, die eine Elastic Load Balancing Balancing-Zustandsprüfung nicht bestehen, finden Sie unter[Einstellung für die Auto Scaling Scaling-Integritätsprüfung für Ihre Elastic Beanstalk Beanstalk-Umgebung](environmentconfig-autoscaling-healthchecktype.md).
## Zustandsprüfungen für Umgebungen mit einer einzelnen Instance oder Worker-Ebene
In einer Single-Instance- oder Worker-Tier-Umgebung bestimmt Elastic Beanstalk den Zustand der Instance, indem es ihren EC2 Amazon-Instance-Status überwacht. Die Integritätseinstellungen von Elastic Load Balancing, einschließlich der URLs HTTP-Zustandsprüfung, können in diesen Umgebungstypen nicht verwendet werden.
Weitere Informationen zu EC2 Amazon-Instance-Statuschecks finden Sie unter [Monitoring Instances with Status Checks](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html) im * EC2 Amazon-Benutzerhandbuch*.
## Zusätzliche Prüfungen
Zusätzlich zu den Elastic Load Balancing -Zustandsprüfungen überwacht Elastic Beanstalk-Ressourcen in Ihrer Umgebung und ändert den Status in Rot, wenn sie nicht bereitgestellt werden, nicht korrekt konfiguriert sind oder nicht mehr verfügbar sind. Diese Prüfungen bestätigen, dass:
+ Die Auto Scaling-Gruppe der Umgebung verfügbar ist und über mindestens eine Instance verfügt.
+ Die Sicherheitsgruppe der Umgebung ist verfügbar und so konfiguriert, dass eingehender Datenverkehr auf Port 80 zulässig ist.
+ Der Umgebungs-CNAME ist vorhanden und weist auf den rechten Load Balancer.
+ In einer Worker-Umgebung wird die Amazon Simple Queue Service (Amazon SQS)-Warteschlange mindestens einmal alle drei Minuten abgefragt.
## CloudWatch Amazon-Metriken
Bei grundlegenden Gesundheitsberichten veröffentlicht der Elastic Beanstalk-Service keine Metriken auf Amazon. CloudWatch Die CloudWatch Metriken, die zur Erstellung von Diagrammen auf der [Monitoring-Seite](environment-health-console.md) der Umgebungskonsole verwendet werden, werden von den Ressourcen in Ihrer Umgebung veröffentlicht.
EC2 Veröffentlicht beispielsweise die folgenden Metriken für die Instances in der Auto Scaling Scaling-Gruppe Ihrer Umgebung:
`CPUUtilization`
Prozentsatz der Recheneinheiten, die zurzeit verwendet werden.
`DiskReadBytes``DiskReadOps``DiskWriteBytes``DiskWriteOps`
Anzahl der gelesenen und geschriebenen Bytes und die Anzahl der Lese- und Schreibvorgänge.
`NetworkIn``NetworkOut`
Anzahl der gesendeten und empfangenen Bytes.
Elastic Load Balancing veröffentlicht die folgenden Metriken für den Load Balancer Ihrer Umgebung:
`BackendConnectionErrors`
Anzahl der fehlgeschlagenen Verbindung zwischen dem Load Balancer und den Umgebung-Instances.
`HTTPCode_Backend_2XX``HTTPCode_Backend_4XX`
Anzahl der erfolgreichen (2XX) und Client-Fehler-Antwortcodes (4XX), die von Instances in Ihrer Umgebung generiert wurden.
`Latency`
Anzahl der Sekunden zwischen dem Zeitpunkt, an dem der Load Balancer eine Anfrage an eine Instance weiterleitet, und dem Zeitpunkt, zu dem die Antwort empfangen wird.
`RequestCount`
Anzahl der abgeschlossenen Anfragen.
Diese Listen sind nicht vollständig. Eine vollständige Liste der Kennzahlen, die für diese Ressourcen gemeldet werden können, finden Sie in den folgenden Themen im Amazon CloudWatch Developer Guide:
**Kennzahlen**
| Namespace | Thema |
| --- | --- |
| AWS::ElasticLoadBalancing::LoadBalancer | [Elastic Load Balancing-Metriken und -Ressourcen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/elb-metricscollected.html) |
| AWS::AutoScaling::AutoScalingGruppe | [Amazon Elastic Compute Cloud-Metriken und -Ressourcen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/ec2-metricscollected.html) |
| AWS::SQS::Queue | [Amazon SQS-Metriken und -Ressourcen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/sqs-metricscollected.html) |
| AWS: :RDS:: DBInstance | [Amazon RDS-Dimensionen und -Metriken](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/rds-metricscollected.html) |
### Worker-Umgebung – Zustandsmetrik
Nur für Worker-Umgebungen veröffentlicht der SQS-Daemon eine benutzerdefinierte Metrik für den Zustand der Umgebung CloudWatch, wobei der Wert 1 Grün ist. Sie können die CloudWatch Gesundheitsmetrikdaten in Ihrem Konto mithilfe des `ElasticBeanstalk/SQSD` Namespace überprüfen. Die Metrikdimension ist `EnvironmentName` und der Metrikname lautet `Health`. Alle Instances veröffentlichen ihre Metriken auf dem gleichen Namespace.
Damit der Daemon Metriken veröffentlichen kann, muss das Instance-Profil der Umgebung die Berechtigung zum Aufrufen von `cloudwatch:PutMetricData` haben. Diese Berechtigung ist im Standard-Instance-Profil enthalten. Weitere Informationen finden Sie unter [Elastic Beanstalk Instance-Profile verwalten](iam-instanceprofile.md).
# Verbesserte Gesundheitsberichterstattung und Überwachung in Elastic Beanstalk
In diesem Abschnitt werden die Funktionen der Elastic Beanstalk Enhanced Health-Funktion erläutert.
Enhanced Health Reporting ist eine Funktion, die Sie in Ihrer Umgebung aktivieren können, AWS Elastic Beanstalk um zusätzliche Informationen über Ressourcen in Ihrer Umgebung zu sammeln. Elastic Beanstalk analysiert die gesammelten Informationen, um ein besseres Bild der Gesamtumgebungsintegrität zu erhalten und um bei der Identifizierung von Problemen zu helfen, die dazu führen können, dass Ihre Anwendung nicht mehr verfügbar ist.
Zusätzlich zu Änderungen bei der Funktionsweise von Zustandsfarben, fügt der erweiterte Zustandsbericht einen *Status*-Deskriptor hinzu, der auf den Schweregrad von Problemen hinweist, wenn eine Umgebung gelb oder rot ist. Wenn weitere Informationen über den aktuellen Status verfügbar sind, können Sie die Schaltfläche **Causes** wählen, um detaillierte Zustandsinformationen auf der Seite [Zustand](health-enhanced-console.md) anzuzeigen.
Um detaillierte Integritätsinformationen zu den Amazon-EC2-Instances bereitzustellen, die in Ihrer Umgebung ausgeführt werden, enthält Elastic Beanstalk für jede Plattformversion, die erweiterte Integritätsberichte unterstützt, einen [Integritäts-Agenten](#health-enhanced-agent) im Amazon-Machine-Image (AMI). Der Integritäts-Agent überwacht Webserverprotokolle und Systemmetriken und leitet sie an den Elastic-Beanstalk-Service weiter. Elastic Beanstalk analysiert diese Metriken und Daten von Elastic-Load-Balancing und Amazon-EC2-Auto-Scaling, um ein Gesamtbild der Integrität einer Umgebung zu erhalten.
Zusätzlich zum Sammeln und Präsentieren von Informationen über die Ressourcen Ihrer Umgebung überwacht Elastic Beanstalk die Ressourcen in Ihrer Umgebung auf verschiedene Fehlerbedingungen und bietet Benachrichtigungen, um Fehler zu vermeiden und Konfigurationsprobleme zu lösen. [Faktoren, die den Zustand Ihrer Umgebung beeinflussen](#health-enhanced-factors), umfassen die Ergebnisse jeder einzelnen Anforderung, die von Ihrer Anwendung bereitgestellt wird, Metriken des Betriebssystems Ihrer Instance und den Status der letzten Bereitstellung.
Sie können den Integritätsstatus in Echtzeit auf der [Umgebungsübersichtsseite](health-enhanced-console.md) in der Elastic-Beanstalk-Konsole oder mit dem Befehl [eb health](health-enhanced-ebcli.md) in der [Elastic-Beanstalk-Befehlszeilenschnittstelle](eb-cli3.md) (EB-CLI) anzeigen. Um den Zustand der Umgebung und Instance im Laufe der Zeit aufzuzeichnen und zu verfolgen, können Sie Ihre Umgebung so konfigurieren, dass die von Elastic Beanstalk gesammelten Informationen für erweiterte Statusberichte CloudWatch als benutzerdefinierte Metriken an Amazon veröffentlicht werden. CloudWatch [Gebühren](https://aws.amazon.com/cloudwatch/pricing/) für benutzerdefinierte Metriken fallen für alle Metriken an, mit Ausnahme von`EnvironmentHealth`, was kostenlos ist.
**Hinweise zur Windows-Plattform**
Wenn Sie erweiterte Zustandsberichte für eine Windows Server-Umgebung aktivieren, ändern Sie nicht die [IIS-Protokollierungskonfiguration](https://docs.microsoft.com/en-us/iis/manage/provisioning-and-managing-iis/configure-logging-in-iis). Damit die erweiterte Statusüberwachung einwandfrei funktioniert, muss die IIS-Protokollierung mit dem **W3C**-Format und den Protokollereigniszielen **ETW event only (Nur ETW-Ereignis)** oder **Both log file and ETW event (Sowohl Protokolldatei als auch ETW-Ereignis)** konfiguriert werden.
Außerdem dürfen Sie den Windows-Service des [Elastic-Beanstalk-Integritäts-Agenten](#health-enhanced-agent) auf keiner der Instances Ihrer Umgebung deaktivieren oder anhalten. Damit erweiterte Zustandsinformationen für eine Instance gesammelt und als Bericht zusammengefasst werden, muss dieser Service aktiviert sein und ausgeführt werden.
Wenn Sie zum ersten Mal eine Umgebung erstellen, fordert Elastic Beanstalk Sie auf, die erforderlichen Rollen zu erstellen, und aktiviert standardmäßig erweiterte Zustandsberichte. Lesen Sie Details darüber, wie die erweiterten Integritätsberichte funktionieren, oder besuchen Sie [Aktivieren der erweiterten Elastic-Beanstalk-Integritätsberichte](health-enhanced-enable.md), um die Funktion sofort zu verwenden.
**Topics**
+ [Der Elastic-Beanstalk-Integritäts-Agent](#health-enhanced-agent)
+ [Faktoren bei der Bestimmung des Instance- und Umgebungszustands](#health-enhanced-factors)
+ [Anpassung der Regel für die Zustandsprüfung](#health-enhanced.rules)
+ [Rollen in erweiterten Zustandsberichten](#health-enhanced-roles)
+ [Erweiterte Zustandsautorisierung](#health-enhanced-authz)
+ [Ereignisse in erweiterten Zustandsberichten](#health-enhanced-events)
+ [Verhalten der erweiterten Zustandsberichte bei Aktualisierungen, Bereitstellungen und Skalierung](#health-enhanced-effects)
+ [Aktivieren der erweiterten Elastic-Beanstalk-Integritätsberichte](health-enhanced-enable.md)
+ [Erweiterte Integritätsüberwachung mithilfe der Environment Management Console](health-enhanced-console.md)
+ [Farben und Status in Zustandsangaben](health-enhanced-status.md)
+ [Instance-Metriken](health-enhanced-metrics.md)
+ [Konfigurieren von Regeln für den erweiterten Zustand einer Umgebung](health-enhanced-rules.md)
+ [Veröffentlichen CloudWatch benutzerdefinierter Amazon-Metriken für eine Umgebung](health-enhanced-cloudwatch.md)
+ [Verwenden der erweiterten Integritätsberichte mit der Elastic-Beanstalk-API](health-enhanced-api.md)
+ [Format der Protokolle der erweiterten Zustandsberichte](health-enhanced-serverlogs.md)
+ [Benachrichtigungen und Fehlerbehebung](environments-health-enhanced-notifications.md)
+ [KI-gestützte Umgebungsanalyse](health-ai-analysis.md)
## Der Elastic-Beanstalk-Integritäts-Agent
Der Elastic-Beanstalk-Integritäts-Agent ist ein Daemon-Prozess (oder in Windows-Umgebungen ein Service), der auf den einzelnen Amazon-EC2-Instances in Ihrer Umgebung ausgeführt wird, das Betriebssystem und Integritätsmetriken auf Anwendungsebene überwacht und Probleme an Elastic Beanstalk meldet. Der Zustandsagent ist in allen Plattformversionen ab Version 2.0 einer jeden Plattform enthalten.
Der Health Agent meldet ähnliche Metriken wie die, die Amazon EC2 Auto Scaling und Elastic Load Balancing im Rahmen der [grundlegenden Statusberichterstattung](using-features.healthstatus.md) [veröffentlicht](using-features.healthstatus.md#monitoring-basic-cloudwatch) haben, einschließlich CPU-Last, HTTP-Codes und Latenz. CloudWatch Der Integritäts-Agent meldet jedoch direkt an Elastic Beanstalk – mit höherer Granularität und Häufigkeit als die grundlegenden Integritätsberichte.
Für grundlegende Zustandsberichte werden diese Metriken alle fünf Minuten veröffentlicht und können mit Diagrammen in der Environment Management Console überwacht werden. Bei den erweiterten Integritätsberichten meldet der Elastic-Beanstalk-Integritäts-Agent die Metriken alle 10 Sekunden an Elastic Beanstalk. Elastic Beanstalk verwendet die Metriken des Integritäts-Agenten, um den Integritätsstatus jeder Instance in der Umgebung zu bestimmen, und, in Kombination mit anderen [Faktoren](#health-enhanced-factors), um die Gesamtintegrität der Umgebung zu bestimmen.
Der allgemeine Zustand der Umgebung kann in Echtzeit auf der Umgebungsübersichtsseite der Elastic Beanstalk-Konsole angezeigt werden und wird alle 60 Sekunden CloudWatch von Elastic Beanstalk veröffentlicht. Sie können detaillierte Metriken, die vom Zustandsagenten in Echtzeit gemeldet werden, mit dem [**eb health**](health-enhanced-ebcli.md)-Befehl in der [EB-CLI](eb-cli3.md) anzeigen.
Gegen eine zusätzliche Gebühr können Sie wählen, ob Sie einzelne Metriken auf Instanz- und Umgebungsebene alle 60 Sekunden veröffentlichen möchten. CloudWatch In CloudWatch veröffentlichte Metriken können dann verwendet werden, um [Überwachungsdiagramme](environment-health-console.md#environment-health-console-customize) in der [Environment Management Console](environments-console.md) zu erstellen.
Für erweiterte Zustandsberichte fällt nur eine Gebühr an, wenn Sie erweiterte Zustandsmetriken in CloudWatch veröffentlichen. Wenn Sie erweiterte Zustandsberichte verwenden, werden die grundlegenden Zustandsmetriken noch kostenlos veröffentlicht, auch wenn Sie keine erweiterten Zustandsmetriken veröffentlichen.
Unter [Instance-Metriken](health-enhanced-metrics.md) finden Sie Details zu Metriken, die vom Zustandsagenten veröffentlicht werden. Einzelheiten zur Veröffentlichung erweiterter Integritätskennzahlen auf finden Sie CloudWatch unter. [Veröffentlichen CloudWatch benutzerdefinierter Amazon-Metriken für eine Umgebung](health-enhanced-cloudwatch.md)
## Faktoren bei der Bestimmung des Instance- und Umgebungszustands
Zusätzlich zu den grundlegenden Systemprüfungen der Integritätsberichte, einschließlich [Zustandsprüfungen von Elastic Load Balancing](using-features.healthstatus.md#using-features.healthstatus.understanding) und [Ressourcenüberwachung](using-features.healthstatus.md#monitoring-basic-additionalchecks), sammeln die erweiterten Integritätsberichte von Elastic Beanstalk zusätzliche Daten zur Integrität der Instances in Ihrer Umgebung. Dazu zählen Betriebssystemmetriken, Serverprotokolle und der Zustand laufender Umgebungsoperationen, wie Bereitstellungen und Updates. Das Integritätsberichtesystem von Elastic Beanstalk kombiniert Informationen aus allen verfügbaren Quellen und analysiert sie, um die Gesamtintegrität der Umgebung zu bestimmen.
### Operationen und Befehle
Wenn Sie eine Operation in Ihrer Umgebung durchführen, z. B. die Bereitstellung einer neuen Version einer Anwendung, nimmt Elastic Beanstalk mehrere Änderungen vor, die sich auf den Integritätsstatus der Umgebung auswirken.
Wenn Sie beispielsweise eine neue Version einer Anwendung in einer Umgebung bereitstellen, in der mehreren Instances ausgeführt werden, werden beim Überwachen des Zustands der Umgebung [mithilfe der EB-CLI](health-enhanced-ebcli.md) möglicherweise Meldung ähnlich der folgenden angezeigt:
```
id status cause
Overall Info Command is executing on 3 out of 5 instances
i-bb65c145 Pending 91 % of CPU is in use. 24 % in I/O wait
Performing application deployment (running for 31 seconds)
i-ba65c144 Pending Performing initialization (running for 12 seconds)
i-f6a2d525 Ok Application deployment completed 23 seconds ago and took 26 seconds
i-e8a2d53b Pending 94 % of CPU is in use. 52 % in I/O wait
Performing application deployment (running for 33 seconds)
i-e81cca40 Ok
```
In diesem Beispiel lautet der Gesamtstatus der Umgebung `Ok` und die Ursache dieses Status ist, dass der *Befehl drei von fünf Instances ausführt*. Drei der Instances in der Umgebung haben den Status *Pending*, was bedeutet, dass ein Vorgang ausgeführt wird.
Wenn ein Vorgang abgeschlossen ist, meldet Elastic Beanstalk zusätzliche Informationen über die Operation. Zum Beispiel zeigt Elastic Beanstalk die folgenden Informationen zu einer Instance, die bereits mit der neuen Version der Anwendung aktualisiert wurde:
```
i-f6a2d525 Ok Application deployment completed 23 seconds ago and took 26 seconds
```
Instance-Zustandsinformationen umfassen auch Details zur aktuellen Bereitstellung für jede Instance in Ihrer Umgebung. Jede Instance meldet eine Bereitstellungs-ID und einen Status. Die Bereitstellungs-ID ist eine ganze Zahl, die sich jedes Mal erhöht, wenn Sie eine neue Version Ihrer Anwendung bereitstellen oder Einstellungen für die Konfigurationsoptionen für die Instance, wie Umgebungsvariablen, ändern. Sie können die Bereitstellungsinformationen zur Identifizierung von Instances verwenden, auf denen die falsche Version Ihrer Anwendung ausgeführt wird, nachdem eine [fortlaufende Bereitstellung](using-features.rolling-version-deploy.md) fehlgeschlagen ist.
In der Spalte mit der Ursache schließt Elastic Beanstalk Informationsmeldungen zu erfolgreichen Operationen und anderen fehlerfreien Zuständen in mehreren Integritätsprüfungen ein, diese werden aber nicht unbegrenzt beibehalten. Ursachen für fehlerhafte Umgebungsstatus verbleiben, bis die Umgebung in einen fehlerfreien Status zurückkehrt.
### Befehls-Timeout
Elastic Beanstalk wendet einen Befehls-Timeout ab dem Zeitpunkt an, an dem eine Operation beginnt, damit eine Instance in einen fehlerfreien Zustand übergehen kann. Dieser Befehls-Timeout wird in der Update- und Bereitstellungskonfiguration Ihrer Umgebung festgelegt (im [aws:elasticbeanstalk: Befehl](command-options-general.md#command-options-general-elasticbeanstalkcommand)-Namespace) und standardmäßig auf zehn Minuten gesetzt.
Während fortlaufenden Updates wendet Elastic Beanstalk einen separaten Timeout auf jeden Stapel in der Operation an. Dieser Timeout wird als Teil der fortlaufenden Update-Konfiguration der Umgebung (im [aws:autoscaling: updatepolicy: rollingupdate](command-options-general.md#command-options-general-autoscalingupdatepolicyrollingupdate)-Namespace) festgelegt. Wenn alle Instances im Stapel innerhalb des Timeouts für fortlaufende Updates fehlerfrei sind, fährt die Operation mit dem nächsten Stapel fort. Wenn dies nicht der Fall ist, schlägt die Operation fehl.
**Anmerkung**
Wenn Ihre Anwendung Integritätsprüfungen nicht mit dem Status **OK** besteht, sie auf einer anderen Stufe jedoch stabil ist, können Sie die `HealthCheckSuccessThreshold`-Option im [`aws:elasticbeanstalk:command namespace`](command-options-general.md#command-options-general-elasticbeanstalkcommand)-Namespace so festlegen, dass die Stufe geändert wird, auf der Elastic Beanstalk eine Instance als stabil betrachtet.
Damit eine Webserverumgebung als fehlerfrei angesehen wird, muss jede Instance in der Umgebung oder im Stapel zwölf aufeinanderfolgende Zustandsprüfungen im Verlauf von zwei Minuten bestehen. Bei einer Umgebung mit Worker-Ebene muss jede Instance 18 Zustandsprüfungen bestehen. Bevor ein Befehls-Timeout auftritt, senkt Elastic Beanstalk den Integritätsstatus einer Umgebung nicht, wenn die Integritätsprüfungen fehlschlagen. Wenn die Instances in der Umgebung innerhalb des Befehls-Timeouts fehlerfrei werden, ist die Operation erfolgreich.
### HTTP-Anforderungen
Wenn keine Operation in einer Umgebung ausgeführt wird, ist die primäre Quelle für Informationen über den Instance- und Umgebungszustand die Webserverprotokolle für jede Instance. Um die Integrität einer Instance und die Gesamtintegrität der Umgebung zu prüfen, berücksichtigt Elastic Beanstalk die Anzahl der Anforderungen, das Ergebnis jeder Anforderung und die Geschwindigkeit, mit der jede Anforderung gelöst wurde.
Auf Linux-basierten Plattformen liest und analysiert Elastic Beanstalk Web-Server-Protokolle zum Abrufen von Informationen über HTTP-Anfragen. Auf der Windows Server-Plattform erhält Elastic Beanstalk diese Informationen [direkt von dem IIS-Webserver](health-enhanced-metrics-server-iis.md).
Ihre Umgebung verfügt möglicherweise nicht über einen aktiven Webserver. So beinhaltet die Multicontainer Docker-Plattform beispielsweise keinen Webserver. Andere Plattformen enthalten einen Webserver, der von Ihrer Anwendung möglicherweise deaktiviert wird. In diesen Fällen ist für Ihre Umgebung eine zusätzliche Konfiguration erforderlich, um dem [Elastic Beanstalk-Integritäts-Agenten](#health-enhanced-agent) Protokolle in dem Format zur Verfügung zu stellen, das zur Weiterleitung von Integritätsinformationen an den Elastic-Beanstalk-Service benötigt wird. Details dazu finden Sie unter [Format der Protokolle der erweiterten Zustandsberichte](health-enhanced-serverlogs.md).
### Betriebssystemmetriken
Elastic Beanstalk überwacht Betriebssystemmetriken, die vom Integritäts-Agenten gemeldet wurden, um Instances zu identifizieren, die konsequent geringe Systemressourcen haben.
Unter [Instance-Metriken](health-enhanced-metrics.md) finden Sie Details zu Metriken, die vom Zustandsagenten veröffentlicht werden.
## Anpassung der Regel für die Zustandsprüfung
Erweiterte Integritätsberichte von Elastic Beanstalk basieren auf mehreren Regeln, um die Integrität Ihrer Umgebung zu bestimmen. Einige dieser Regeln sind möglicherweise nicht für Ihre jeweilige Anwendung geeignet. Ein häufiger Fall ist eine Anwendung, die standardmäßig viele HTTP-4xx-Fehler zurückgibt. Elastic Beanstalk kommt unter Verwendung einer seiner Standardregeln zu dem Schluss, dass etwas schief läuft, und ändert den Integritätsstatus Ihrer Umgebung je nach Fehlerrate von „OK“ auf „Warning (Warnung)“, „Degraded (Schwach)“ oder „Severe (Stark)“. Um diesen Fall ordnungsgemäß zu verarbeiten, gestattet Ihnen Elastic Beanstalk, diese Regel zu konfigurieren und HTTP-4xx-Fehler von Anwendungen zu ignorieren. Details hierzu finden Sie unter [Konfigurieren von Regeln für den erweiterten Zustand einer Umgebung](health-enhanced-rules.md).
## Rollen in erweiterten Zustandsberichten
Erweiterte Integritätsberichte erfordern zwei Rollen – eine Servicerolle für Elastic Beanstalk und ein Instance-Profil für die Umgebung. Die Service-Rolle ermöglicht es Elastic Beanstalk, in Ihrem Namen mit anderen AWS Services zu interagieren, um Informationen über die Ressourcen in Ihrer Umgebung zu sammeln. Das Instance-Profil ermöglicht es den Instances in Ihrer Umgebung, Protokolle in Amazon-S3 zu schreiben und erweiterte Integritätsinformationen an den Elastic-Beanstalk-Service zu übermitteln.
Wenn Sie eine Elastic-Beanstalk-Umgebung mit der Elastic-Beanstalk-Konsole oder der EB-CLI erstellen, erstellt Elastic Beanstalk eine Standard-Servicerolle und fügt die erforderlichen verwalteten Richtlinien an ein Standard-Instance-Profil für Ihre Umgebung an.
Wenn Sie die API, ein SDK oder die verwenden, um Umgebungen AWS CLI zu erstellen, müssen Sie diese Rollen im Voraus erstellen und sie bei der Umgebungserstellung angeben, um Enhanced Health verwenden zu können. Anweisungen zum Erstellen geeigneter Rollen für Ihre Umgebungen finden Sie unter [Elastic Beanstalk Service-Rollen, Instanzprofile und Benutzerrichtlinien](concepts-roles.md).
Es wird empfohlen, *verwaltete Richtlinien* für Ihr Instance-Profil und Ihre Servicerolle zu verwenden. Verwaltete Richtlinien sind AWS Identity and Access Management (IAM-) Richtlinien, die Elastic Beanstalk verwaltet. Durch die Verwendung verwalteter Richtlinien wird sichergestellt, dass Ihre Umgebung über alle erforderlichen Berechtigungen verfügt, um ordnungsgemäß zu funktionieren.
Für das Instance-Profil können Sie die verwalteten Richtlinien `AWSElasticBeanstalkWebTier` oder `AWSElasticBeanstalkWorkerTier` verwenden, je nachdem, ob es sich um eine Umgebung auf [Webserverebene](concepts-webserver.md) oder auf [Worker-Ebene](concepts-worker.md) handelt. Ausführliche Informationen zu diesen beiden Richtlinien für verwaltete Instance-Profile finden Sie unter [Elastic Beanstalk Instance-Profile verwalten](iam-instanceprofile.md).
## Erweiterte Zustandsautorisierung
Die Richtlinien, die das Elastic-Beanstalk-Instance-Profil verwaltet, enthalten die Berechtigungen der Aktion `elasticbeanstalk:PutInstanceStatistics`. Diese Aktion ist nicht Teil der Elastic-Beanstalk-API. Sie ist Teil einer anderen API, die Umgebungs-Instances intern verwenden, um erweiterte Zustandsinformationen an den Elastic-Beanstalk-Service zu übermitteln. Sie rufen diese API nicht direkt auf.
Wenn Sie eine neue Umgebung erstellen, wird die Autorisierung für die`elasticbeanstalk:PutInstanceStatistics` Aktion standardmäßig aktiviert. Um die Sicherheit Ihrer Umgebung zu erhöhen und das Spoofing von Gesundheitsdaten in Ihrem Namen zu verhindern, empfehlen wir die aktivierte Einstellung. Wenn Sie verwaltete Richtlinien für Ihr Instance-Profil verwenden, steht diese Funktion für Ihre neue Umgebung ohne weitere Konfiguration zur Verfügung. Wenn Sie anstelle einer *verwalteten Richtlinie* ein *benutzerdefiniertes Instance-Profil* verwenden, zeigt Ihre Umgebung möglicherweise den Zustandstatus **Keine Daten** an. Dies geschieht, weil die Instances nicht für die Aktion autorisiert sind, die erweiterte Zustandsdaten an den Service übermittelt.
Um die Aktion zu autorisieren, fügen Sie die folgende Anweisung in Ihr Instance-Profil ein.
```
{
"Sid": "ElasticBeanstalkHealthAccess",
"Action": [
"elasticbeanstalk:PutInstanceStatistics"
],
"Effect": "Allow",
"Resource": [
"arn:aws:elasticbeanstalk:*:*:application/*",
"arn:aws:elasticbeanstalk:*:*:environment/*"
]
}
```
Wenn Sie die erweiterte Zustandsberechtigung zu diesem Zeitpunkt nicht verwenden möchten, deaktivieren Sie sie, indem Sie die Einstellung `EnhancedHealthAuthEnabled` Option in der [aws:elasticbeanstalk:healthreporting:system](command-options-general.md#command-options-general-elasticbeanstalkhealthreporting) Namespace zu `false`. Wenn diese Option deaktiviert ist, sind die zuvor beschriebenen Berechtigungen nicht erforderlich. Sie können sie aus dem Instanceprofil entfernen, um [Zugriff auf Ihre](security-best-practices.md#security-best-practices.preventive.least-priv) Anwendungen und Umgebungen mit den geringsten Rechten zu erhalten.
**Anmerkung**
Bisher war die Standardeinstellung für `EnhancedHealthAuthEnabled` `false`, welches im Ergebnis die Aktion `elasticbeanstalk:PutInstanceStatistics` standardmäßig ebenfalls deaktiviert. Um diese Aktion für eine vorhandene Umgebung zu aktivieren, stellen Sie die `EnhancedHealthAuthEnabled`-Option im [aws:elasticbeanstalk:healthreporting:system](command-options-general.md#command-options-general-elasticbeanstalkhealthreporting)-Namespace auf `true` ein. Sie können diese Option mithilfe einer [Optionseinstellung](ebextensions-optionsettings.md) in einer [Konfigurationsdatei](ebextensions.md) konfigurieren.
## Ereignisse in erweiterten Zustandsberichten
Das System für erweiterte Zustandsberichte generiert Ereignisse, wenn eine Umgebung zwischen Zuständen wechselt. Das folgende Beispiel zeigt ausgegebene Ereignisse durch eine Umgebungsübertragung zwischen den Zuständen **Info**, **OK** und **Severe (Schwerwiegend)**.
![\[Die Übersichtsseite zur Elastic-Beanstalk-Umgebung der Elastic-Beanstalk-Konsole, auf der die letzten Ereignisse der erweiterten Integrität angezeigt werden\]](http://docs.aws.amazon.com/de_de/elasticbeanstalk/latest/dg/images/enhanced-health-events.png)
Wenn in einen schlechteren Zustand gewechselt wird, enthält das Ereignis der erweiterten Zustandsberichte eine Meldung mit der Ursache des Wechsels.
Nicht alle Änderungen des Status auf Instance-Ebene bewirken, dass Elastic Beanstalk ein Ereignis ausgibt. Um Fehlalarme zu verhindern, generiert Elastic Beanstalk nur dann ein integritätsbezogenes Ereignis, wenn ein Problem über mehrere Prüfungen hinweg bestehen bleibt.
Echtzeit-Integritätsinformationen auf Umgebungsebene, einschließlich Zustand, Farbe und Ursache, sind auf der [Umgebungsübersichtsseite](environments-dashboard.md) der Elastic-Beanstalk-Konsole und in der [EB-CLI](eb-cli3.md) verfügbar. Indem Sie die EB-CLI an Ihre Umgebung anfügen und den [**eb health**](health-enhanced-ebcli.md)-Befehl ausführen, können Sie auch Echtzeitstatus aus jeder der Instances in Ihrer Umgebung anzeigen.
## Verhalten der erweiterten Zustandsberichte bei Aktualisierungen, Bereitstellungen und Skalierung
Das Aktivieren von erweiterten Zustandsberichten kann beeinflussen, wie sich Ihre Umgebung während Konfigurations-Updates und -bereitstellungen verhält. Elastic Beanstalk schließt eine Reihe von Aktualisierungen erst dann ab, wenn alle Instances die Integritätsprüfungen durchgängig bestehen. Da die erweiterten Zustandsberichte einen höheren Standard für den Zustand anwenden und mehr Faktoren überwachen, bestehen Instances, die die grundlegende [ELB-Zustandsprüfung](using-features.healthstatus.md#using-features.healthstatus.understanding) der Zustandsberichte bestehen, nicht notwendigerweise die Prüfung mit erweiterten Zustandsberichten. Weitere Informationen dazu, wie Zustandsprüfungen den Update-Prozess beeinflussen, finden Sie in den Themen [fortlaufende Konfigurations-Updates](using-features.rollingupdates.md) und [fortlaufende Bereitstellungen](using-features.rolling-version-deploy.md).
Erweiterte Integritätsberichte können auch die Notwendigkeit, eine ordnungsgemäße [Integritätsprüfungs-URL](environments-cfg-clb.md#using-features.managing.elb.healthchecks) für Elastic-Load-Balancing festzulegen, hervorheben. Wenn Ihre Umgebung nach oben skaliert wird, um den Bedarf zu erfüllen, beginnen neue Instances mit der Annahme von Anforderungen, sobald sie ausreichend ELB-Zustandsprüfungen bestehen. Wenn eine Zustandsprüfungs-URL nicht konfiguriert ist, dauert es nur 20 Sekunden, bis eine neue Instance eine TCP-Anwendung akzeptieren kann.
Wenn Ihre Anwendung den Start nicht abgeschlossen hat, bis der Load Balancer sie für ausreichend stabil für den Empfang von Datenverkehr erklärt hat, sehen Sie zahlreiche fehlerhafte Anforderungen und Ihre Umgebung besteht die Zustandsprüfungen nicht mehr. Eine Zustandsprüfungs-URL, die auf einen Pfad abzielt, der von Ihrer Anwendung verarbeitet wird, kann dieses Problem verhindern. ELB-Zustandsprüfungen schlagen so lange fehl, bis eine GET-Anforderung an die Zustandsprüfungs-URL als Statuscode 200 zurückgibt.
# Aktivieren der erweiterten Elastic-Beanstalk-Integritätsberichte
In diesem Thema wird erklärt, wie erweiterte Gesundheitsberichte aktiviert werden. Es enthält Verfahren, mit denen Sie die erweiterte Gesundheitsfunktion für Ihre Umgebung mit der Elastic Beanstalk Beanstalk-Konsole, der EB-CLI und mit einer .ebextensions-Konfiguration aktivieren können.
Zu den neuen Umgebungen, die mit den neuesten [Plattformversionen](concepts.platforms.md) erstellt wurden, gehört der AWS Elastic Beanstalk [Health Agent](health-enhanced.md#health-enhanced-agent), der erweiterte Gesundheitsberichte unterstützt. Wenn Sie Ihre Umgebung in der Elastic-Beanstalk-Konsole oder mit der EB-CLI erstellen, sind erweiterte Integritätsberichte standardmäßig aktiviert. Sie können die Einstellungen der erweiterten Zustandsberichte auch im Quellcode Ihrer Anwendung mithilfe von [Konfigurationsdateien](ebextensions.md) festlegen.
Erweiterte Zustandsberichte erfordern ein [Instance-Profil](concepts-roles-instance.md) und eine [Servicerolle](concepts-roles-service.md) mit den Standardberechtigungen. Wenn Sie eine Umgebung in der Elastic-Beanstalk-Konsole erstellen, legt Elastic Beanstalk die erforderlichen Rollen automatisch fest. Anweisungen zum Erstellen Ihrer ersten Umgebung finden Sie unter [Erfahren Sie, wie Sie mit Elastic Beanstalk loslegen können](GettingStarted.md).
**Topics**
+ [Aktivieren der erweiterten Integritätsberichte mit der Elastic-Beanstalk-Konsole](#health-enhanced-enable-console)
+ [Aktivieren der erweiterten Zustandsberichte mit der EB-CLI](#health-enhanced-enable-ebcli)
+ [Aktivieren der erweiterten Zustandsberichte mit einer Konfigurationsdatei](#health-enhanced-enable-config)
## Aktivieren der erweiterten Integritätsberichte mit der Elastic-Beanstalk-Konsole
**So aktivieren Sie erweiterte Integritätsberichte in einer laufenden Umgebung mit der Elastic-Beanstalk-Konsole**
1. Öffnen Sie die [Elastic Beanstalk Beanstalk-Konsole](https://console.aws.amazon.com/elasticbeanstalk) und wählen Sie in der Liste **Regionen** Ihre aus. AWS-Region
1. Wählen Sie im Navigationsbereich **Environments (Umgebungen)** aus und wählen Sie dann in der Liste den Namen Ihrer Umgebung aus.
1. Wählen Sie im Navigationsbereich **Configuration (Konfiguration)** aus.
1. Wählen Sie in der Konfigurationskategorie **Monitoring (Überwachung)** die Option **Edit (Bearbeiten)**.
1. Klicken Sie unter **Health reporting** (Zustandsberichte) für die Option **System** auf **Enhanced** (Erweitert).
**Anmerkung**
Die Optionen für erweiterte Zustandsberichte werden nicht angezeigt, wenn Sie eine [nicht unterstützte Plattform oder Version](health-enhanced.md) verwenden.
1. Wählen Sie unten auf der Seite die Option **Apply** (Anwenden) aus, um die Änderungen zu speichern.
Die Elastic-Beanstalk-Konsole erstellt standardmäßig erweiterte Integritätsberichte, wenn Sie eine neue Umgebung mit einer Version 2 (v2)-Plattform erstellen. Sie können erweiterte Zustandsberichte deaktivieren, indem Sie die Option für Zustandsberichte während der Umgebungserstellung ändern.
**So deaktivieren Sie erweiterte Integritätsberichte, wenn Sie eine Umgebung mit der Elastic-Beanstalk-Konsole erstellen**
1. Öffnen Sie die [Elastic Beanstalk Beanstalk-Konsole](https://console.aws.amazon.com/elasticbeanstalk) und wählen Sie in der Liste **Regionen** Ihre aus. AWS-Region
1. [Erstellen Sie eine Anwendung](applications.md) oder wählen Sie eine bestehende.
1. [Erstellen Sie eine Umgebung](using-features.environments.md). Wählen Sie auf der Seite **Create a new environment** (Neue Umgebung erstellen) zuerst **Configure more options** (Weitere Optionen konfigurieren) aus und klicken Sie dann auf **Create environment** (Umgebung erstellen).
1. Wählen Sie in der Konfigurationskategorie **Monitoring (Überwachung)** die Option **Edit (Bearbeiten)**.
1. Klicken Sie unter **Health reporting** (Zustandsberichte) für die Option **System** auf **Basic** (Grundlegend).
1. Wählen Sie **Speichern**.
## Aktivieren der erweiterten Zustandsberichte mit der EB-CLI
Wenn Sie eine neue Umgebung mit dem **eb create**-Befehl erstellen, aktiviert die EB-CLI erweiterte Zustandsberichte standardmäßig und wendet das Standard-Instance-Profil und die Standard-Servicerolle an.
Sie können mit der `--service-role`-Option eine andere Servicerolle nach Namen festlegen.
Wenn Sie eine Umgebung haben, auf der grundlegende Zustandsberichte auf einer Version 2 (v2)-Plattformversion ausgeführt werden, und Sie zu erweiterten Zustandsberichten wechseln möchten, führen Sie die folgenden Schritte aus.
**So aktivieren Sie die erweiterten Zustandsberichte auf einer laufenden Umgebung mit der [EB-CLI](eb-cli3.md)**
1. Verwenden Sie den **eb config**-Befehl, um die Konfigurationsdatei im Standard-Texteditor zu öffnen.
```
~/project$ eb config
```
1. Suchen Sie den `aws:elasticbeanstalk:environment`-Namespace im Bereich mit den Einstellungen. Stellen Sie sicher, dass der Wert von `ServiceRole` nicht null ist und mit dem Namen Ihrer [Servicerolle](concepts-roles-service.md) übereinstimmt.
```
aws:elasticbeanstalk:environment:
EnvironmentType: LoadBalanced
ServiceRole: aws-elasticbeanstalk-service-role
```
1. Ändern Sie unter dem `aws:elasticbeanstalk:healthreporting:system:`-Namespace den Wert von `SystemType` zu **enhanced**.
```
aws:elasticbeanstalk:healthreporting:system:
SystemType: enhanced
```
1. Speichern Sie die Konfigurationsdatei und schließen Sie den Text-Editor.
1. Die EB-CLI startet ein Umgebungs-Update, um Ihre Konfigurationsänderungen anzuwenden. Warten Sie, bis der Vorgang abgeschlossen ist, oder drücken Sie **Ctrl\$1C**, um den Vorgang sicher zu beenden.
```
~/project$ eb config
Printing Status:
INFO: Environment update is starting.
INFO: Health reporting type changed to ENHANCED.
INFO: Updating environment no-role-test's configuration settings.
```
## Aktivieren der erweiterten Zustandsberichte mit einer Konfigurationsdatei
Sie können erweiterte Zustandsberichte aktivieren, indem Sie eine [Konfigurationsdatei](ebextensions.md) zu Ihrem Quell-Bundle hinzufügen. Das folgende Beispiel zeigt eine Konfigurationsdatei, mit der erweiterte Zustandsberichte aktiviert und der Standardservice und das Standard-Instance-Profil zur Umgebung hinzugefügt werden:
**Example .ebextensions/enhanced-health.config**
```
option_settings:
aws:elasticbeanstalk:healthreporting:system:
SystemType: enhanced
aws:autoscaling:launchconfiguration:
IamInstanceProfile: aws-elasticbeanstalk-ec2-role
aws:elasticbeanstalk:environment:
ServiceRole: aws-elasticbeanstalk-service-role
```
Wenn Sie Ihr eigenes Instance-Profil oder Ihre eigene Servicerolle erstellt haben, ersetzen Sie den hervorgehobenen Text mit den Namen dieser Rollen.
# Erweiterte Integritätsüberwachung mithilfe der Environment Management Console
Wenn Sie die erweiterte Statusberichterstattung in aktivieren AWS Elastic Beanstalk, können Sie den Zustand der Umgebung in der [Umgebungsmanagementkonsole](environments-console.md) überwachen.
**Topics**
+ [Überblick über die Umgebung](#health-enhanced-console-overview)
+ [Seite „Umgebungsintegrität“](#health-enhanced-console-healthpage)
+ [Überwachungsseite](#health-enhanced-console-monitoringpage)
## Überblick über die Umgebung
In der [Umgebungsübersicht ](environments-dashboard.md) werden der [Integritätsstatus](health-enhanced-status.md) der Umgebung angezeigt und Ereignisse aufgelistet, die Informationen zu aktuellen Änderungen in Bezug auf den Integritätsstatus bereitstellen.
**So zeigen Sie die Umgebungsübersicht an**
1. Öffnen Sie die [Elastic Beanstalk Beanstalk-Konsole](https://console.aws.amazon.com/elasticbeanstalk) und wählen Sie in der Liste **Regionen** Ihre aus. AWS-Region
1. Wählen Sie im Navigationsbereich **Environments (Umgebungen)** aus und wählen Sie dann in der Liste den Namen Ihrer Umgebung aus.
Ausführliche Informationen zur aktuellen Integrität der Umgebung finden Sie auf der Seite **Health (Integrität)** durch Auswahl von **Causes (Ursachen)**. Alternativ können Sie im Navigationsbereich die Option **Health (Integrität)** auswählen.
## Seite „Umgebungsintegrität“
Auf der Seite **Health** werden der Gesundheitsstatus, Kennzahlen und Ursachen für die Umgebung und für jede EC2 Amazon-Instance in der Umgebung angezeigt.
**Anmerkung**
Elastic Beanstalk zeigt die Seite **Health (Integrität)** nur dann an, wenn Sie die [erweiterte Integritätsüberwachung für die Umgebung aktiviert haben](health-enhanced-enable.md).
Das folgende Image zeigt die Seite **Health** (Integrität) in einer Linux-Umgebung.
![\[Die Seite „Umgebungsintegrität“ für eine Linux-Umgebung\]](http://docs.aws.amazon.com/de_de/elasticbeanstalk/latest/dg/images/enhanced-health-instances.png)
Das folgende Image zeigt die Seite **Health** (Integrität) für eine Windows-Umgebung. Beachten Sie, dass sich CPU-Metriken von denen in einer Linux-Umgebung unterscheiden.
![\[Seite „Zustand der Umgebung“ für eine Windows-Umgebung.\]](http://docs.aws.amazon.com/de_de/elasticbeanstalk/latest/dg/images/enhanced-health-instances-win.png)
Oben auf der Seite können Sie die Gesamtzahl der Umgebungs-Instances sowie die Anzahl der Instances pro Status anzeigen. Wenn Sie nur Instances mit einem bestimmten Status anzeigen möchten, wählen Sie **Filter By (Filtern nach)** und dann einen [Status](health-enhanced-status.md) aus.
![\[Seite „Umgebungsintegrität“ mit menübasierter Filterung zur Auswahl eines Instance-Status zur Anzeige\]](http://docs.aws.amazon.com/de_de/elasticbeanstalk/latest/dg/images/enhanced-health-instances-status.png)
Um eine fehlerhafte Instance neu zu starten oder zu beenden, klicken Sie auf **Instance Actions (Instance-Aktionen)** und anschließend auf **Reboot (Neu starten)** oder **Terminate (Beenden)**.
![\[Seite zur Umgebungsintegrität mit dem Menü mit Instanzaktionen zum Neustarten oder Beenden fehlerhafter Instances.\]](http://docs.aws.amazon.com/de_de/elasticbeanstalk/latest/dg/images/enhanced-health-instances-actions.png)
Elastic Beanstalk aktualisiert die Seite **Health (Integrität)** alle 10 Sekunden. Es werden Informationen zur Integrität von Umgebung und Instance angezeigt.
Für jede EC2 Amazon-Instance in der Umgebung werden auf der Seite die ID und der [Status](health-enhanced-status.md) der Instance, die Zeit seit dem Start der Instance, die ID der letzten Bereitstellung, die auf der Instance ausgeführt wurde, die Antworten und die Latenz der Anfragen, die die Instance bedient hat, sowie Informationen zur Last und CPU-Auslastung angezeigt. In der Zeile **Overall (Gesamt)** werden Informationen zur durchschnittlichen Antwortzeit und Latenz für die gesamte Umgebung angezeigt.
Die Seite zeigt zahlreiche Details in einer sehr breiten Tabelle an. Um Spalten auszublenden, wählen Sie ![\[the cog icon.\]](http://docs.aws.amazon.com/de_de/elasticbeanstalk/latest/dg/images/cog.png) (**Preferences (Einstellungen)**) aus. Markieren oder löschen Sie Spaltennamen und klicken Sie anschließend auf **Confirm (Bestätigen)**.
![\[Auswählen von Spalten zur Anzeige auf der Seite „Umgebungsintegrität“\]](http://docs.aws.amazon.com/de_de/elasticbeanstalk/latest/dg/images/enhanced-health-console-preferences.png)
Wählen Sie die **Instance ID (Instance-ID)** einer Instance aus, um weitere Informationen zur Instance anzuzeigen, einschließlich Availability Zone und Instance-Typ.
![\[Servermetriken auf der Seite „Umgebungsintegrität“ mit Informationen zur Instance\]](http://docs.aws.amazon.com/de_de/elasticbeanstalk/latest/dg/images/enhanced-health-console-instance.png)
Wählen Sie die **Deployment ID (Bereitstellungs-ID)** einer Instance aus, um Informationen zur letzten [Bereitstellung](using-features.deploy-existing-version.md) auf der Instance anzuzeigen.
![\[Servermetriken auf der Seite „Umgebungsintegrität“ mit Informationen zu Bereitstellungen\]](http://docs.aws.amazon.com/de_de/elasticbeanstalk/latest/dg/images/enhanced-health-console-deployment.png)
Zu den Bereitstellungsinformationen gehören:
+ **Deployment ID (Bereitstellungs-ID)** – Die eindeutige ID für die [Bereitstellung](using-features.deploy-existing-version.md). IDs Die Bereitstellung beginnt bei 1 und wird jedes Mal um eins erhöht, wenn Sie eine neue Anwendungsversion bereitstellen oder Konfigurationseinstellungen ändern, die sich auf die Software oder das Betriebssystem auswirken, die auf den Instances in Ihrer Umgebung ausgeführt werden.
+ **Version** – Die Versionsbezeichnung des Anwendungsquellcodes, der in der Bereitstellung verwendet wird.
+ **Status** – Der Status der Bereitstellung, der `In Progress`, `Deployed` oder `Failed` lauten kann.
+ **Time (Zeit)** – Für angefangene Bereitstellungen ist dies die Zeit, zu der die Bereitstellung gestartet wurde. Für abgeschlossene Bereitstellungen ist dies die Zeit, zu der die Bereitstellung beendet wurde.
Wenn Sie die [X-Ray-Integration in Ihrer Umgebung aktivieren](environment-configuration-debugging.md) und Ihre Anwendung mit dem AWS X-Ray SDK ausstatten, fügt die **Health-Seite** Links zur AWS X-Ray Konsole in der Übersichtszeile hinzu.
![\[Anforderungsmetriken auf der Seite „Umgebungsintegrität“\]](http://docs.aws.amazon.com/de_de/elasticbeanstalk/latest/dg/images/enhanced-health-console-xray.png)
Wählen Sie einen Link, um Traces im Zusammenhang mit der markierten Statistik in der AWS X-Ray Konsole anzuzeigen.
## Überwachungsseite
Auf der Seite **Überwachung** werden zusammenfassende Statistiken und Grafiken für die benutzerdefinierten CloudWatch Amazon-Metriken angezeigt, die vom erweiterten Gesundheitsberichtssystem generiert wurden. Unter [Überwachung des Zustands der Umgebung in der AWS Managementkonsole](environment-health-console.md) finden Sie Anweisungen zum Hinzufügen von Diagrammen und Statistiken zu dieser Seite.
# Farben und Status in Zustandsangaben
Erweiterte Zustandsberichte zeigen den Zustand von Instances und der Umgebung insgesamt mit vier Farben an, ähnlich wie bei [grundlegenden Zustandsberichten](using-features.healthstatus.md). Erweitere Zustandsberichte bieten außerdem sieben Zustandsstatus, wobei es sich um einzelne Wortdeskriptoren handelt, die eine bessere Angabe des Zustands Ihrer Umgebung bieten.
## Instance-Status und Umgebungsstatus
Jedes Mal, wenn Elastic Beanstalk eine Integritätsprüfung für Ihre Umgebung ausführt, wird mit den erweiterten Integritätsberichten die Integrität jeder Instance in Ihrer Umgebung durch die Analyse der [verfügbaren Daten](health-enhanced.md#health-enhanced-factors) überprüft. Wenn eine der untergeordneten Prüfungen fehlschlägt, setzt Elastic Beanstalk die Integrität der Instance herunter.
Elastic Beanstalk zeigt die Integritätsinformationen für die gesamte Umgebung (Farbe, Status und Ursache) in der [Environment Management Console](environments-console.md) an. Diese Informationen sind auch in der EB-CLI verfügbar. Status- und Ursachenmeldungen für einzelne Instances werden alle 10 Sekunden aktualisiert und sind in der [EB-CLI](eb-cli3.md) verfügbar, wenn Sie den Status mit [**eb health**](health-enhanced-ebcli.md) anzeigen.
Elastic Beanstalk nutzt Änderungen bei der Instance-Integrität, um die Umgebungsintegrität zu evaluieren, ändert jedoch nicht sofort den Umgebungsintegritätsstatus. Wenn eine Instance die Integritätsprüfungen mindestens drei Mal in einem 1-Minuten-Zeitraum nicht besteht, kann Elastic Beanstalk die Integrität der Umgebung herabsetzen. Abhängig von der Anzahl der Instances in der Umgebung und dem identifizierten Problem kann eine fehlerhafte Instance dazu führen, dass Elastic Beanstalk eine Informationsmeldung anzeigt oder den Integritätsstatus der Umgebung von Grün (**OK**) in Gelb (**Warning (Warnung)**) oder Rot (**Degraded (Schwach)**) oder (**Severe (Stark)**) ändert.
## OK (Grün)
Dieser Status wird angezeigt, wenn:
+ Eine Instance besteht die Zustandsprüfungen und der Zustandsagent meldet keine Probleme.
+ Die meisten Instances in der Umgebung bestehen die Zustandsprüfungen und der Zustandsagent meldet keine wesentlichen Probleme.
+ Eine Instance besteht Zustandsprüfungen und führt Anfragen normal aus.
*Beispiel: *Ihre Umgebung wurde kürzlich bereitgestellt und führt Anfragen normal aus. 5 % der Anfragen geben Serienfehler 400 zurück. Die Bereitstellung wurde auf jeder Instance normal abgeschlossen.
*Nachricht (Instance):* Anwendungsbereitstellung vor 23 Sekunden abgeschlossen (Dauer: 26 Sekunden).
## Warning (Gelb)
Dieser Status wird angezeigt, wenn:
+ Der Zustandsagent meldet eine geringe Anzahl an Anfragefehlern oder andere Probleme für eine Instance oder Umgebung.
+ Ein Vorgang ist auf einer Instance in Bearbeitung und dauert sehr lange.
*Beispiel:* Eine Instance in der Umgebung hat den Status **Severe (Stark)**.
*Nachricht (Umgebung):* Eingeschränkte Services bei 1 von 5 Instances.
## Degraded (Rot)
Dieser Status wird angezeigt, wenn der Zustandsagent eine große Anzahl an Anfragefehlern oder andere Probleme für eine Instance oder Umgebung meldet.
*Beispiel:* Umgebung wird auf bis zu 5 Instance aufwärts skaliert.
*Nachricht (Umgebung):* 4 aktive Instances liegen unter der Mindestgröße für Auto Scaling-Gruppen von 5.
## Severe (Rot)
Dieser Status wird angezeigt, wenn der Zustandsagent eine sehr große Anzahl an Anfragefehlern oder andere Probleme für eine Instance oder Umgebung meldet.
*Beispiel:* Elastic Beanstalk kann den Load Balancer nicht zum Abrufen der Instance-Integrität kontaktieren.
*Nachricht (Umgebung):* ELB-Zustandsprüfung schlägt fehl oder ist nicht für alle Instances verfügbar. Keine der Instances sendet Daten. Die Rolle „arn:aws:iam: :123456789012:role/“ konnte nicht übernommen werden. aws-elasticbeanstalk-service-role Überprüfen Sie, ob die Rolle vorhanden ist und richtig konfiguriert wurde.
*Nachricht (Instances):* Instance-ELB-Zustandsprüfung war 37 Minuten nicht verfügbar. Keine Daten. Zuletzt vor 37 Minuten gesehen.
## Info (Grün)
Dieser Status wird angezeigt, wenn:
+ Eine Operation wird auf einer Instance ausgeführt.
+ Eine Operation wird auf mehreren Instances in einer Umgebung ausgeführt.
*Beispiel:* Eine neue Anwendungsversion wird für laufende Instances bereitgestellt.
*Nachricht (Umgebung):* Befehl wird auf 3 von 5 Instances ausgeführt.
*Nachricht (Instance):* Durchführen der Anwendungsbereitstellung (drei Sekunden lang ausgeführt).
## Pending (Grau)
Dieser Status wird angezeigt, wenn auf einer Instance innerhalb des [Befehls-Timeout](health-enhanced.md#health-enhanced-factors-timeout) eine Operation ausgeführt wird.
*Beispiel:* Sie haben kürzlich die Umgebung erstellt und Instances werden per Bootstrapping bereitgestellt.
*Nachricht:* Durchführen der Initialisierung (12 Sekunden lang ausgeführt).
## Unknown (Grau)
Dieser Status wird angezeigt, wenn Elastic Beanstalk und der Integritäts-Agent eine unzureichende Anzahl an Daten für eine Instance melden.
*Beispiel:* Keine Daten werden empfangen.
## Suspended (Grau)
Dieser Status wird angezeigt, wenn Elastic Beanstalk die Überwachung der Integrität der Umgebung gestoppt hat. Die Umgebung funktioniert möglicherweise nicht korrekt. Einige gravierende Integritätsbedingungen bewirken bei längerer Dauer, dass Elastic Beanstalk die Umgebung in den Status **Suspended (Gesperrt)** versetzt.
*Beispiel:* Elastic Beanstalk kann nicht auf die [Servicerolle](iam-servicerole.md) der Umgebung zugreifen.
*Beispiel:* Die von Elastic Beanstalk für die Umgebung erstellte [Auto-Scaling-Gruppe](using-features.managing.as.md) wurde gelöscht.
*Nachricht:* Der Umgebungszustand hat von **OK** zu **Severe (Stark)** gewechselt. Es sind keine Instances vorhanden. Die gewünschte Kapazität für die Auto-Scaling-Gruppe ist auf 1 gesetzt.
# Instance-Metriken
Instance-Metriken bieten Informationen über den Zustand der Instances in Ihrer Umgebung. Der [Elastic-Beanstalk-Integritäts-Agent](health-enhanced.md#health-enhanced-agent) wird auf jeder Instance ausgeführt. Er erfasst Metriken zu Instances und leitet diese an Elastic Beanstalk weiter. Dort erfolgt die Analyse der Metriken, um die Integrität der Instances in Ihrer Umgebung zu bestimmen.
Der Elastic-Beanstalk-Integritäts-Agent für die Instance erfasst Metriken zu Instances von Webservern und dem Betriebssystem. Um Informationen vom Webserver auf Linux-basierten Plattformen zu erhalten, liest und analysiert Elastic Beanstalk Web-Server-Protokolle. Auf der Windows Server-Plattform erhält Elastic Beanstalk diese Informationen direkt von dem IIS-Webserver. Webserver bieten Informationen zu eingehenden HTTP-Anforderungen, z. B. wie viele Anforderungen eingegangen sind, wie viele davon zu Fehlern führten und wie lange die Verarbeitung gedauert hat. Das Betriebssystem bietet Snapshot-Informationen zum Status der Instance-Ressourcen, wie z. B. CPU-Auslastung und Verteilung der aufgewendeten Zeit je Prozesstyp.
Der Integritäts-Agent erfasst Webserver- und Betriebssystemmetriken und leitet diese in Intervallen von 10 Sekunden an Elastic Beanstalk weiter. Elastic Beanstalk analysiert die Daten und verwendet die Ergebnisse, um den Integritätsstatus für die einzelnen Instances und die Umgebung zu aktualisieren.
**Topics**
+ [Webserver-Metriken](#health-enhanced-metrics-server)
+ [Betriebssystemmetriken](#health-enhanced-metrics-os)
+ [Erfassung von Webserver-Metriken in IIS auf Windows Server](health-enhanced-metrics-server-iis.md)
## Webserver-Metriken
Auf Linux-basierten Plattformen liest der Elastic-Beanstalk-Integritäts-Agent die Webservermetriken aus den Protokollen aus, die vom Webcontainer oder Server, der die Anforderungen für alle Instances der Umgebung verarbeitet, generiert werden. Elastic-Beanstalk-Plattformen sind so konfiguriert, dass zwei Protokolle generiert werden, nämlich ein visuell lesbares und ein maschinenlesbares Format. Der Integritäts-Agent leitet die maschinenlesbaren Protokolle alle 10 Sekunden an Elastic Beanstalk weiter.
Weitere Informationen zum Protokollformat von Elastic Beanstalk finden Sie unter [Format der Protokolle der erweiterten Zustandsberichte](health-enhanced-serverlogs.md).
Auf der Windows-Server-Plattform fügt Elastic Beanstalk ein Modul zur Anfrage-Pipeline des IIS-Webservers hinzu und erfasst Metriken über HTTP-Anfragezeiten und Antwortcodes. Das Modul sendet diese Metriken über einen leistungsfähigen IPC-Kanal (Inter-Process Communication) an den On-Instance-Zustandsagenten. Weitere Informationen zur Implementierung finden Sie in [Erfassung von Webserver-Metriken in IIS auf Windows Server](health-enhanced-metrics-server-iis.md).Gemeldete Webservermetriken
`RequestCount`
Anzahl der vom Webserver pro Sekunde verarbeiteten Anforderungen in den letzten zehn Sekunden. Dargestellt als Durchschnittswert `r/sec` (Anfragen pro Sekunde) in der EB-CLI und der [Seite „Umgebungsintegrität“](health-enhanced-console.md#health-enhanced-console-healthpage).
`Status2xx``Status3xx``Status4xx``Status5xx`
Anzahl der Anforderungen je Statuscode in den letzten zehn Sekunden. Beispielsweise geben erfolgreiche Anforderungen den Code "200 OK" und Weiterleitungen den Code "301" zurück. Falls die eingegebene URL mit keiner Ressource in der Anwendung übereinstimmt, wird der Code "404" zurückgegeben.
In der EB-CLI und der [Seite „Umgebungsintegrität“](health-enhanced-console.md#health-enhanced-console-healthpage) werden diese Metriken sowohl als reine Anzahl der Anforderungen für Instances als auch als Prozentsatz der generellen Anforderungen für die Umgebungen dargestellt.
`p99.9``p99``p95``p90``p85``p75``p50``p10`
Durchschnittliche Latenzzeit der am langsamsten verarbeiteten *x* Prozent an Anforderungen in den letzten zehn Sekunden (wobei *x* die Differenz zwischen der Ziffer und 100 angibt). Beispielsweise gibt `p99 1.403` gibt an, dass für die am langsamsten verarbeiteten 1 Prozent der Anforderungen in den letzten zehn Sekunden die durchschnittliche Latenz 1,403 Sekunden betrug.
## Betriebssystemmetriken
Der Elastic-Beanstalk-Integritäts-Agent meldet die folgenden Betriebssystemmetriken. Elastic Beanstalk verwendet diese Metriken, um Instances zu ermitteln, bei denen die Auslastung durchgängig hoch ist. Die Metriken unterscheiden sich je nach Betriebssystem.Gemeldete Betriebssystemmetriken – Linux
`Running`
Der seit dem Instance-Start verstrichene Zeitraum.
`Load 1``Load 5`
Durchschnittliche Auslastung in den letzten Ein-Minuten- und Fünf-Minuten-Zeiträumen. Dieser Dezimalwert gibt die durchschnittliche Anzahl der in diesem Zeitraum ausgeführten Prozesse an. Wenn die angezeigte Zahl höher ist als die Anzahl der verfügbaren v CPUs (Threads), entspricht der Rest der durchschnittlichen Anzahl der Prozesse, die gewartet haben.
Wenn Ihr Instance-Typ beispielsweise vier V CPUs hat und die Last 4,5 beträgt, warteten in diesem Zeitraum durchschnittlich 0,5 Prozesse, was einem Prozess entspricht, der 50 Prozent der Zeit gewartet hat.
`User %``Nice %``System %``Idle %``I/O Wait %`
Prozentangabe des Zeitraums, den die CPU in den letzten zehn Sekunden im jeweiligen Status gewesen ist.Gemeldete Betriebssystemmetriken – Windows
`Running`
Der seit dem Instance-Start verstrichene Zeitraum.
`% User Time``% Privileged Time``% Idle Time`
Prozentangabe des Zeitraums, den die CPU in den letzten zehn Sekunden im jeweiligen Status gewesen ist.
# Erfassung von Webserver-Metriken in IIS auf Windows Server
Auf der Windows-Server-Plattform fügt Elastic Beanstalk ein Modul zur Anfrage-Pipeline des IIS-Webservers hinzu und erfasst Metriken über HTTP-Anfragezeiten und Antwortcodes. Das Modul sendet diese Metriken über einen leistungsfähigen IPC-Kanal (Inter-Process Communication) an den On-Instance-Zustandsagenten. Der Integritäts-Agent aggregiert diese Metriken, kombiniert sie mit Metriken des Betriebssystems und sendet sie an den Elastic-Beanstalk-Service.
## Implementierungsinformationen
Um Metriken aus IIS zu erfassen, implementiert Elastic Beanstalk eine verwaltete [https://msdn.microsoft.com/en-us/library/system.web.ihttpmodule%28v=vs.110%29.aspx](https://msdn.microsoft.com/en-us/library/system.web.ihttpmodule%28v=vs.110%29.aspx) und abonniert sie zu den [https://msdn.microsoft.com/en-us/library/system.web.httpapplication.beginrequest(v=vs.110).aspx](https://msdn.microsoft.com/en-us/library/system.web.httpapplication.beginrequest(v=vs.110).aspx)- und [https://msdn.microsoft.com/en-us/library/system.web.httpapplication.endrequest(v=vs.110).aspx](https://msdn.microsoft.com/en-us/library/system.web.httpapplication.endrequest(v=vs.110).aspx)-Ereignissen. Dies ermöglicht es dem Modul, HTTP-Anfragelatenz und Antwortcodes für alle vom IIS bearbeiteten Webanfragen zu melden. Um das Modul der IIS-Anfrage-Pipeline hinzuzufügen, registriert Elastic Beanstalk das Modul im [https://docs.microsoft.com/en-us/iis/configuration/system.webserver/modules/](https://docs.microsoft.com/en-us/iis/configuration/system.webserver/modules/)-Abschnitt der IIS-Konfigurationsdatei `%windir%\System32\inetsrv\config\applicationHost.config`.
Das Elastic-Beanstalk-Modul in IIS sendet die erfassten Metriken der Web-Anfrage an den Integritäts-Agenten für die Instance. Dabei handelt es sich um einen Windows-Service mit dem Namen `HealthD`. Um diese Daten zu senden, verwendet das Modul [https://msdn.microsoft.com/en-us/library/system.servicemodel.netnamedpipebinding(v=vs.110).aspx](https://msdn.microsoft.com/en-us/library/system.servicemodel.netnamedpipebinding(v=vs.110).aspx), die eine sichere und zuverlässige Bindung bietet, die für die Kommunikation auf der Maschine optimiert ist.
# Konfigurieren von Regeln für den erweiterten Zustand einer Umgebung
AWS Elastic Beanstalk Die erweiterte Zustandsberichterstattung stützt sich auf eine Reihe von Regeln zur Bestimmung des Zustands Ihrer Umgebung. Einige dieser Regeln sind möglicherweise nicht für Ihre jeweilige Anwendung geeignet. Im Folgenden finden Sie einige häufig verwendete Beispiele:
+ Sie verwenden clientseitige Testwerkzeuge. In diesem Fall werden häufige HTTP-Clientfehler (4xx) erwartet.
+ Sie verwenden [AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/) in Verbindung mit dem Application Load Balancer Ihrer Umgebung, um unerwünschten eingehenden Datenverkehr zu blockieren. In diesem Fall gibt der Application Load Balancer für jede abgelehnte eingehende Nachricht „HTTP 403“ zurück.
Standardmäßig berücksichtigt Elastic Beanstalk alle HTTP 4xx-Fehler von Anwendungen, wenn die Integrität der Umgebung ermittelt wird. Abhängig von der Fehlerquote ändert sich der Zustandsstatus der Umgebung von **OK** in **Warnung**, **Beeinträchtigt** oder **Schwerwiegend**. Damit Fälle, wie die erwähnten Beispiele, korrekt gehandhabt werden, können Sie mit Elastic Beanstalk einige Regeln für die erweiterte Integrität konfigurieren. Sie können wählen, ob HTTP 4xx-Fehler von Anwendungen auf Instances der Umgebung oder ob HTTP 4xx-Fehler, die vom Load Balancer der Umgebung zurückgegeben werden, ignoriert werden sollen. In diesem Thema wird beschrieben, wie diese Konfigurationsänderungen vorgenommen werden.
**Anmerkung**
Derzeit sind dies die einzigen verfügbaren Anpassungen von Regeln zum erweiterten Zustand. Die erweiterte Integrität kann nicht so konfigurieren werden, dass andere HTTP-Fehler zusätzlich zu 4xx ignoriert werden.
## Konfigurieren von Regeln für die erweiterte Integrität mit der Elastic-Beanstalk-Konsole
Sie können die Elastic-Beanstalk-Konsole verwenden, um Regeln für die erweiterte Integrität in einer Umgebung zu konfigurieren.
**So konfigurieren Sie die HTTP 4xx-Statuscodeprüfung mithilfe der Elastic-Beanstalk-Konsole**
1. Öffnen Sie die [Elastic Beanstalk Beanstalk-Konsole](https://console.aws.amazon.com/elasticbeanstalk) und wählen Sie in der Liste **Regionen** Ihre aus. AWS-Region
1. Wählen Sie im Navigationsbereich **Environments (Umgebungen)** aus und wählen Sie dann in der Liste den Namen Ihrer Umgebung aus.
1. Wählen Sie im Navigationsbereich **Configuration (Konfiguration)** aus.
1. Wählen Sie in der Konfigurationskategorie **Monitoring (Überwachung)** die Option **Edit (Bearbeiten)**.
1. Aktivieren oder deaktivieren Sie unter **Anpassung der Integritätsüberwachungsregel** die gewünschten **Ignore (Ignorieren)**-Optionen.
![\[Abschnitt zur Anpassung der Integritätsüberwachungsregel auf der Konfigurationsüberwachungsseite der Elastic-Beanstalk-Konsole\]](http://docs.aws.amazon.com/de_de/elasticbeanstalk/latest/dg/images/enhanced-health-rule-customization.png)
1. Wählen Sie unten auf der Seite die Option **Apply** (Anwenden) aus, um die Änderungen zu speichern.
## Konfigurieren von erweiterten Zustandsregeln unter Verwendung der EB-CLI
Sie können mit der EB-CLI Regeln für die erweiterte Integrität konfigurieren, indem Sie die Konfiguration Ihrer Umgebung lokal speichern, einen Eintrag hinzufügen, der Regeln für die erweiterte Integrität konfiguriert, und die Konfiguration dann in Elastic Beanstalk hochladen. Sie können die gespeicherte Konfiguration zu einer Umgebung während oder nach der Erstellung hinzufügen.
**So konfigurieren Sie die HTTP 4xx-Statuscodeprüfung mit der EB-CLI und gespeicherten Konfigurationen**
1. Initialisieren Sie Ihren Projektordner mit [**eb init**](eb-cli3-configuration.md).
1. Erstellen Sie eine Umgebung, indem Sie den **eb create**-Befehl ausführen.
1. Speichern Sie eine Konfigurationsvorlage lokal, indem Sie den **eb config save**-Befehl ausführen. Im folgenden Beispiel wird die `--cfg`-Option verwendet, um den Namen der Konfiguration anzugeben.
```
$ eb config save --cfg 01-base-state
Configuration saved at: ~/project/.elasticbeanstalk/saved_configs/01-base-state.cfg.yml
```
1. Öffnen Sie die gespeicherte Konfigurationsdatei in einem Texteditor.
1. Fügen Sie unter `OptionSettings` > `aws:elasticbeanstalk:healthreporting:system:` einen `ConfigDocument`-Schlüssel hinzu, um alle Regeln für den erweiterten Zustand aufzulisten, die konfiguriert werden können. Im Folgenden wird mit `ConfigDocument` die Überprüfung der HTTP 4xx-Statuscodes von Anwendungen deaktiviert, während die Überprüfung des HTTP 4xx-Codes des Load Balancer aktiviert bleibt.
```
OptionSettings:
...
aws:elasticbeanstalk:healthreporting:system:
ConfigDocument:
Rules:
Environment:
Application:
ApplicationRequests4xx:
Enabled: false
ELB:
ELBRequests4xx:
Enabled: true
Version: 1
SystemType: enhanced
...
```
**Anmerkung**
Sie können `Rules` und `CloudWatchMetrics` in derselben `ConfigDocument`-Optionseinstellung kombinieren. `CloudWatchMetrics` sind in [Veröffentlichen CloudWatch benutzerdefinierter Amazon-Metriken für eine Umgebung](health-enhanced-cloudwatch.md) beschrieben.
Wenn Sie zuvor `CloudWatchMetrics` aktiviert haben, hat die Konfigurationsdatei, die Sie mit dem Befehl **eb config save** abrufen, bereits einen `ConfigDocument`-Schlüssel mit einem `CloudWatchMetrics`-Abschnitt. *Löschen Sie ihn nicht* – fügen Sie einen `Rules`-Abschnitt in denselben `ConfigDocument`-Optionswert ein.
1. Speichern Sie die Konfigurationsdatei und schließen Sie den Text-Editor. Bei diesem Beispiel wird die aktualisierte Konfigurationsdatei mit einem Namen (`02-cloudwatch-enabled.cfg.yml`) gespeichert, der sich von dem der heruntergeladenen Konfigurationsdatei unterscheidet. Dadurch wird eine separat gespeicherte Konfiguration erstellt, wenn die Datei hochgeladen wird. Sie können demselben Namen wie die heruntergeladene Datei verwenden, um die vorhandene Konfiguration zu überschreiben, ohne dass Sie eine neue erstellen müssen.
1. Verwenden Sie zum Hochladen der aktualisierten Konfigurationsdatei in Elastic Beanstalk den Befehl **eb config put**.
```
$ eb config put 02-cloudwatch-enabled
```
Schließen Sie die Dateinamenerweiterung bei Verwendung der Befehle **eb config** `get` und `put` mit gespeicherten Konfigurationen nicht mit ein.
1. Wenden Sie die gespeicherte Konfiguration auf Ihre laufende Umgebung an.
```
$ eb config --cfg 02-cloudwatch-enabled
```
Die `--cfg`-Option gibt eine benannte Konfigurationsdatei an, die auf die Umgebung angewendet wird. Sie können die Konfigurationsdatei lokal oder in Elastic Beanstalk speichern. Wenn eine Konfigurationsdatei mit dem angegebenen Namen in beiden Speicherorten vorhanden ist, verwendet die EB-CLI die lokale Datei.
## Konfigurieren von erweiterten Zustandsregeln unter Verwendung eines Konfigurationsdokuments
Das Konfigurationsdokument (config) für Regeln für erweiterte Zustände ist ein JSON-Dokument, das die zu konfigurierenden Regeln auflistet.
Das folgende Beispiel zeigt ein Konfigurationsdokument, das die Überprüfung von HTTP 4xx-Statuscodes von Anwendungen deaktiviert und die Überprüfung von HTTP 4xx-Statuscodes für Load Balancer aktiviert.
```
{
"Rules": {
"Environment": {
"Application": {
"ApplicationRequests4xx": {
"Enabled": false
}
},
"ELB": {
"ELBRequests4xx": {
"Enabled": true
}
}
}
},
"Version": 1
}
```
Für den AWS CLIübergeben Sie das Dokument als Wert für den `Value` Schlüssel in einem Optionseinstellungsargument, das selbst ein JSON-Objekt ist. In diesem Fall müssen Anführungszeichen im eingebetteten Dokument durch Escape-Zeichen geschützt werden. Mit dem folgenden Befehl wird überprüft, ob die Konfigurationseinstellungen gültig sind.
```
$ aws elasticbeanstalk validate-configuration-settings --application-name my-app --environment-name my-env --option-settings '[
{
"Namespace": "aws:elasticbeanstalk:healthreporting:system",
"OptionName": "ConfigDocument",
"Value": "{\"Rules\": { \"Environment\": { \"Application\": { \"ApplicationRequests4xx\": { \"Enabled\": false } }, \"ELB\": { \"ELBRequests4xx\": {\"Enabled\": true } } } }, \"Version\": 1 }"
}
]'
```
Für eine `.ebextensions`-Konfigurationsdatei in YAML können Sie das JSON-Dokument unverändert bereitstellen.
```
option_settings:
- namespace: aws:elasticbeanstalk:healthreporting:system
option_name: ConfigDocument
value: {
"Rules": {
"Environment": {
"Application": {
"ApplicationRequests4xx": {
"Enabled": false
}
},
"ELB": {
"ELBRequests4xx": {
"Enabled": true
}
}
}
},
"Version": 1
}
```
# Veröffentlichen CloudWatch benutzerdefinierter Amazon-Metriken für eine Umgebung
Sie können die im Rahmen der AWS Elastic Beanstalk erweiterten Gesundheitsberichterstattung gesammelten Daten CloudWatch als benutzerdefinierte Metriken an Amazon veröffentlichen. Durch die Veröffentlichung von Metriken CloudWatch können Sie Veränderungen der Anwendungsleistung im Laufe der Zeit überwachen und potenzielle Probleme identifizieren, indem Sie verfolgen, wie die Ressourcennutzung und die Latenz von Anfragen mit der Auslastung skalieren.
Indem Sie Metriken veröffentlichen CloudWatch, stellen Sie sie auch für die Verwendung in [Überwachungsdiagrammen](environment-health-console.md#environment-health-console-graphs) und [Alarmen](using-features.alarms.md) zur Verfügung. Eine kostenlose Metrik, *EnvironmentHealth*, wird automatisch aktiviert, wenn Sie die erweiterte Statusberichterstattung verwenden. Für andere benutzerdefinierte Messwerte *EnvironmentHealth*fallen keine [CloudWatch Standardgebühren](https://aws.amazon.com/cloudwatch/pricing/) an.
Um CloudWatch benutzerdefinierte Metriken für eine Umgebung zu veröffentlichen, müssen Sie zunächst die erweiterte Zustandsberichterstattung für die Umgebung aktivieren. Detaillierte Anweisungen finden Sie unter [Aktivieren der erweiterten Elastic-Beanstalk-Integritätsberichte](health-enhanced-enable.md).
**Topics**
+ [Metriken der erweiterten Zustandsberichte](#health-enhanced-cloudwatch-metrics)
+ [Konfiguration von CloudWatch Metriken mit der Elastic Beanstalk Beanstalk-Konsole](#health-enhanced-cloudwatch-console)
+ [Konfiguration CloudWatch benutzerdefinierter Metriken mit der EB-CLI](#health-enhanced-cloudwatch-ebcli)
+ [Bereitstellen von benutzerdefinierten Metrikkonfigurations-Dokumenten](#health-enhanced-cloudwatch-configdocument)
## Metriken der erweiterten Zustandsberichte
Wenn Sie die erweiterte Zustandsberichterstattung in Ihrer Umgebung aktivieren, veröffentlicht das erweiterte Zustandsberichtssystem automatisch eine [CloudWatch benutzerdefinierte Metrik](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/publishingMetrics.html), *EnvironmentHealth*. [Um zusätzliche Metriken zu veröffentlichen CloudWatch, konfigurieren Sie Ihre Umgebung mit diesen Metriken, indem Sie die [Elastic Beanstalk Beanstalk-Konsole](#health-enhanced-cloudwatch-console), [EB CLI](#health-enhanced-cloudwatch-ebcli) oder .ebextensions verwenden.](command-options.md)
Sie können die folgenden erweiterten Integritätsmetriken aus Ihrer Umgebung in veröffentlichen. CloudWatchVerfügbare Metriken – alle Plattformen
`EnvironmentHealth`
*Nur Umgebung. * Dies ist die einzige CloudWatch Metrik, die das erweiterte Zustandsberichtssystem veröffentlicht, sofern Sie keine zusätzlichen Messwerte konfigurieren. Der Umgebungszustand wird durch einen von sieben [Status](health-enhanced-status.md) dargestellt. In der CloudWatch Konsole werden diese Status den folgenden Werten zugeordnet:
+ 0 – OK
+ 1 – Info
+ 5 – Unknown
+ 10 – No data
+ 15 – Warning
+ 20 – Degraded
+ 25 – Severe
`InstancesSevere``InstancesDegraded``InstancesWarning``InstancesInfo``InstancesOk``InstancesPending``InstancesUnknown``InstancesNoData`
*Nur Umgebung. * Diese Metriken geben die Anzahl der Instances in der Umgebung mit dem jeweiligen Zustand an. `InstancesNoData` gibt die Anzahl der Instances an, für die keine Daten empfangen wurden.
`ApplicationRequestsTotal``ApplicationRequests5xx``ApplicationRequests4xx``ApplicationRequests3xx``ApplicationRequests2xx`
*Instance und Umgebung. * Gibt die Gesamtanzahl der Anforderungen an, die von der Instance oder Umgebung abgeschlossen wurden, und die Anzahl der Anfragen, die mit jeder Statuscodekategorie abgeschlossen wurde.
`ApplicationLatencyP10``ApplicationLatencyP50``ApplicationLatencyP75``ApplicationLatencyP85``ApplicationLatencyP90``ApplicationLatencyP95``ApplicationLatencyP99``ApplicationLatencyP99.9`
*Instance und Umgebung. * Gibt die durchschnittliche Zeit in Sekunden an, die es dauert, bis die schnellsten *x* Prozent der Anfragen abgeschlossen wurden.
`InstanceHealth`
*Nur Instance.* Gibt den aktuellen Zustand der Instance an. Der Instance-Zustand wird durch einen von sieben [Status](health-enhanced-status.md) dargestellt. In der CloudWatch Konsole werden diese Status den folgenden Werten zugeordnet:
+ 0 – OK
+ 1 – Info
+ 5 – Unknown
+ 10 – No data
+ 15 – Warning
+ 20 – Degraded
+ 25 – SevereVerfügbaren Metriken – Linux
`CPUIrq``CPUIdle``CPUUser``CPUSystem``CPUSoftirq``CPUIowait``CPUNice`
*Nur Instance.* Gibt eine Prozentangabe des Zeitraums an, den die CPU in der letzten Minute im jeweiligen Status gewesen ist.
`LoadAverage1min`
*Nur Instance.* Die durchschnittliche CPU-Auslastung der Instance innerhalb der letzten Minute.
`RootFilesystemUtil`
*Nur Instance.* Gibt den prozentualen Anteil des verwendeten Speicherplatzes an.Verfügbaren Metriken – Windows
`CPUIdle``CPUUser``CPUPrivileged`
Nur Instance. Gibt eine Prozentangabe des Zeitraums an, den die CPU in der letzten Minute im jeweiligen Status gewesen ist.
## Konfiguration von CloudWatch Metriken mit der Elastic Beanstalk Beanstalk-Konsole
Sie können die Elastic Beanstalk Beanstalk-Konsole verwenden, um Ihre Umgebung so zu konfigurieren, dass erweiterte Gesundheitsberichtsmetriken veröffentlicht CloudWatch und für die Verwendung mit Überwachungsdiagrammen und Alarmen verfügbar gemacht werden.
**So konfigurieren Sie CloudWatch benutzerdefinierte Metriken in der Elastic Beanstalk Beanstalk-Konsole**
1. Öffnen Sie die [Elastic Beanstalk Beanstalk-Konsole](https://console.aws.amazon.com/elasticbeanstalk) und wählen Sie in der Liste **Regionen** Ihre aus. AWS-Region
1. Wählen Sie im Navigationsbereich **Environments (Umgebungen)** aus und wählen Sie dann in der Liste den Namen Ihrer Umgebung aus.
1. Wählen Sie im Navigationsbereich **Configuration (Konfiguration)** aus.
1. Wählen Sie in der Konfigurationskategorie **Monitoring (Überwachung)** die Option **Edit (Bearbeiten)**.
1. Wählen Sie unter **Health reporting (Zustandsberichte)** die Instance-und Umgebungsmetriken aus, die Sie in CloudWatch veröffentlichen möchten. Zur Auswahl mehrerer Metriken drücken Sie die **Strg**-Taste während der Auswahl.
1. Wählen Sie unten auf der Seite die Option **Apply** (Anwenden) aus, um die Änderungen zu speichern.
Wenn Sie CloudWatch benutzerdefinierte Metriken aktivieren, werden sie der Liste der auf der [**Monitoring-Seite**](environment-health-console.md) verfügbaren Metriken hinzugefügt.
## Konfiguration CloudWatch benutzerdefinierter Metriken mit der EB-CLI
Sie können mit der EB-CLI benutzerdefinierte Metriken konfigurieren, indem Sie die Konfiguration Ihrer Umgebung lokal speichern, einen Eintrag hinzufügen, der die Metriken für die Veröffentlichung definiert, und die Konfiguration dann in Elastic Beanstalk hochladen. Sie können die gespeicherte Konfiguration zu einer Umgebung während oder nach der Erstellung hinzufügen.
**So konfigurieren Sie CloudWatch benutzerdefinierte Metriken mit der EB-CLI und gespeicherten Konfigurationen**
1. Initialisieren Sie Ihren Projektordner mit [**eb init**](eb-cli3-configuration.md).
1. Erstellen Sie eine Umgebung, indem Sie den **eb create**-Befehl ausführen.
1. Speichern Sie eine Konfigurationsvorlage lokal, indem Sie den **eb config save**-Befehl ausführen. Im folgenden Beispiel wird die `--cfg`-Option verwendet, um den Namen der Konfiguration anzugeben.
```
$ eb config save --cfg 01-base-state
Configuration saved at: ~/project/.elasticbeanstalk/saved_configs/01-base-state.cfg.yml
```
1. Öffnen Sie die gespeicherte Konfigurationsdatei in einem Texteditor.
1. Fügen Sie unter `OptionSettings` > einen `ConfigDocument` Schlüssel hinzu`aws:elasticbeanstalk:healthreporting:system:`, um jede der gewünschten CloudWatch Metriken zu aktivieren. Wenn beispielsweise der folgende `ConfigDocument` `ApplicationRequests5xx`- und `ApplicationRequests4xx` -Metriken auf Umgebungsebene und `ApplicationRequestsTotal`-Metriken auf Instance-Ebene veröffentlicht.
```
OptionSettings:
...
aws:elasticbeanstalk:healthreporting:system:
ConfigDocument:
CloudWatchMetrics:
Environment:
ApplicationRequests5xx: 60
ApplicationRequests4xx: 60
Instance:
ApplicationRequestsTotal: 60
Version: 1
SystemType: enhanced
...
```
Im Beispiel gibt 60 die Anzahl der Sekunden zwischen Messungen an. Derzeit ist dies der einzige unterstützte Wert.
**Anmerkung**
Sie können `CloudWatchMetrics` und `Rules` in derselben `ConfigDocument`-Optionseinstellung kombinieren. `Rules` sind in [Konfigurieren von Regeln für den erweiterten Zustand einer Umgebung](health-enhanced-rules.md) beschrieben.
Wenn Sie zuvor `Rules` verwendet haben, um Regeln für den erweiterten Zustand zu konfigurieren, hat die Konfigurationsdatei, die Sie mit dem Befehl **eb config save** abrufen, bereits einen `ConfigDocument`-Schlüssel mit einem `Rules`-Abschnitt. *Löschen Sie ihn nicht* – fügen Sie einen `CloudWatchMetrics`-Abschnitt in denselben `ConfigDocument`-Optionswert ein.
1. Speichern Sie die Konfigurationsdatei und schließen Sie den Text-Editor. Bei diesem Beispiel wird die aktualisierte Konfigurationsdatei mit einem Namen (`02-cloudwatch-enabled.cfg.yml`) gespeichert, der sich von dem der heruntergeladenen Konfigurationsdatei unterscheidet. Dadurch wird eine separat gespeicherte Konfiguration erstellt, wenn die Datei hochgeladen wird. Sie können demselben Namen wie die heruntergeladene Datei verwenden, um die vorhandene Konfiguration zu überschreiben, ohne dass Sie eine neue erstellen müssen.
1. Verwenden Sie zum Hochladen der aktualisierten Konfigurationsdatei in Elastic Beanstalk den Befehl **eb config put**.
```
$ eb config put 02-cloudwatch-enabled
```
Schließen Sie die Dateierweiterung bei Verwendung der Befehle **eb config** `get` und `put` mit gespeicherten Konfigurationen nicht mit ein.
1. Wenden Sie die gespeicherte Konfiguration auf Ihre laufende Umgebung an.
```
$ eb config --cfg 02-cloudwatch-enabled
```
Die `--cfg`-Option gibt eine benannte Konfigurationsdatei an, die auf die Umgebung angewendet wird. Sie können die Konfigurationsdatei lokal oder in Elastic Beanstalk speichern. Wenn eine Konfigurationsdatei mit dem angegebenen Namen in beiden Speicherorten vorhanden ist, verwendet die EB-CLI die lokale Datei.
## Bereitstellen von benutzerdefinierten Metrikkonfigurations-Dokumenten
Das Konfigurationsdokument (Config) für CloudWatch benutzerdefinierte Amazon-Metriken ist ein JSON-Dokument, das die zu veröffentlichenden Metriken auf Umgebungs- und Instanzebene auflistet. Das folgende Beispiel zeigt ein Konfigurationsdokument, das alle verfügbaren benutzerdefinierten Metriken aktiviert.
```
{
"CloudWatchMetrics": {
"Environment": {
"ApplicationLatencyP99.9": 60,
"InstancesSevere": 60,
"ApplicationLatencyP90": 60,
"ApplicationLatencyP99": 60,
"ApplicationLatencyP95": 60,
"InstancesUnknown": 60,
"ApplicationLatencyP85": 60,
"InstancesInfo": 60,
"ApplicationRequests2xx": 60,
"InstancesDegraded": 60,
"InstancesWarning": 60,
"ApplicationLatencyP50": 60,
"ApplicationRequestsTotal": 60,
"InstancesNoData": 60,
"InstancesPending": 60,
"ApplicationLatencyP10": 60,
"ApplicationRequests5xx": 60,
"ApplicationLatencyP75": 60,
"InstancesOk": 60,
"ApplicationRequests3xx": 60,
"ApplicationRequests4xx": 60
},
"Instance": {
"ApplicationLatencyP99.9": 60,
"ApplicationLatencyP90": 60,
"ApplicationLatencyP99": 60,
"ApplicationLatencyP95": 60,
"ApplicationLatencyP85": 60,
"CPUUser": 60,
"ApplicationRequests2xx": 60,
"CPUIdle": 60,
"ApplicationLatencyP50": 60,
"ApplicationRequestsTotal": 60,
"RootFilesystemUtil": 60,
"LoadAverage1min": 60,
"CPUIrq": 60,
"CPUNice": 60,
"CPUIowait": 60,
"ApplicationLatencyP10": 60,
"LoadAverage5min": 60,
"ApplicationRequests5xx": 60,
"ApplicationLatencyP75": 60,
"CPUSystem": 60,
"ApplicationRequests3xx": 60,
"ApplicationRequests4xx": 60,
"InstanceHealth": 60,
"CPUSoftirq": 60
}
},
"Version": 1
}
```
Für das AWS CLIübergeben Sie das Dokument als Wert für den `Value` Schlüssel in einem Optionseinstellungsargument, das selbst ein JSON-Objekt ist. In diesem Fall müssen Anführungszeichen im eingebetteten Dokument durch Escape-Zeichen geschützt werden.
```
$ aws elasticbeanstalk validate-configuration-settings --application-name my-app --environment-name my-env --option-settings '[
{
"Namespace": "aws:elasticbeanstalk:healthreporting:system",
"OptionName": "ConfigDocument",
"Value": "{\"CloudWatchMetrics\": {\"Environment\": {\"ApplicationLatencyP99.9\": 60,\"InstancesSevere\": 60,\"ApplicationLatencyP90\": 60,\"ApplicationLatencyP99\": 60,\"ApplicationLatencyP95\": 60,\"InstancesUnknown\": 60,\"ApplicationLatencyP85\": 60,\"InstancesInfo\": 60,\"ApplicationRequests2xx\": 60,\"InstancesDegraded\": 60,\"InstancesWarning\": 60,\"ApplicationLatencyP50\": 60,\"ApplicationRequestsTotal\": 60,\"InstancesNoData\": 60,\"InstancesPending\": 60,\"ApplicationLatencyP10\": 60,\"ApplicationRequests5xx\": 60,\"ApplicationLatencyP75\": 60,\"InstancesOk\": 60,\"ApplicationRequests3xx\": 60,\"ApplicationRequests4xx\": 60},\"Instance\": {\"ApplicationLatencyP99.9\": 60,\"ApplicationLatencyP90\": 60,\"ApplicationLatencyP99\": 60,\"ApplicationLatencyP95\": 60,\"ApplicationLatencyP85\": 60,\"CPUUser\": 60,\"ApplicationRequests2xx\": 60,\"CPUIdle\": 60,\"ApplicationLatencyP50\": 60,\"ApplicationRequestsTotal\": 60,\"RootFilesystemUtil\": 60,\"LoadAverage1min\": 60,\"CPUIrq\": 60,\"CPUNice\": 60,\"CPUIowait\": 60,\"ApplicationLatencyP10\": 60,\"LoadAverage5min\": 60,\"ApplicationRequests5xx\": 60,\"ApplicationLatencyP75\": 60,\"CPUSystem\": 60,\"ApplicationRequests3xx\": 60,\"ApplicationRequests4xx\": 60,\"InstanceHealth\": 60,\"CPUSoftirq\": 60}},\"Version\": 1}"
}
]'
```
Für eine `.ebextensions`-Konfigurationsdatei in YAML können Sie das JSON-Dokument unverändert bereitstellen.
```
option_settings:
- namespace: aws:elasticbeanstalk:healthreporting:system
option_name: ConfigDocument
value: {
"CloudWatchMetrics": {
"Environment": {
"ApplicationLatencyP99.9": 60,
"InstancesSevere": 60,
"ApplicationLatencyP90": 60,
"ApplicationLatencyP99": 60,
"ApplicationLatencyP95": 60,
"InstancesUnknown": 60,
"ApplicationLatencyP85": 60,
"InstancesInfo": 60,
"ApplicationRequests2xx": 60,
"InstancesDegraded": 60,
"InstancesWarning": 60,
"ApplicationLatencyP50": 60,
"ApplicationRequestsTotal": 60,
"InstancesNoData": 60,
"InstancesPending": 60,
"ApplicationLatencyP10": 60,
"ApplicationRequests5xx": 60,
"ApplicationLatencyP75": 60,
"InstancesOk": 60,
"ApplicationRequests3xx": 60,
"ApplicationRequests4xx": 60
},
"Instance": {
"ApplicationLatencyP99.9": 60,
"ApplicationLatencyP90": 60,
"ApplicationLatencyP99": 60,
"ApplicationLatencyP95": 60,
"ApplicationLatencyP85": 60,
"CPUUser": 60,
"ApplicationRequests2xx": 60,
"CPUIdle": 60,
"ApplicationLatencyP50": 60,
"ApplicationRequestsTotal": 60,
"RootFilesystemUtil": 60,
"LoadAverage1min": 60,
"CPUIrq": 60,
"CPUNice": 60,
"CPUIowait": 60,
"ApplicationLatencyP10": 60,
"LoadAverage5min": 60,
"ApplicationRequests5xx": 60,
"ApplicationLatencyP75": 60,
"CPUSystem": 60,
"ApplicationRequests3xx": 60,
"ApplicationRequests4xx": 60,
"InstanceHealth": 60,
"CPUSoftirq": 60
}
},
"Version": 1
}
```
# Verwenden der erweiterten Integritätsberichte mit der Elastic-Beanstalk-API
Da AWS Elastic Beanstalk erweiterte Integritätsberichte Rollen- und Lösungs-Stack-Anforderungen haben, müssen Sie Skripts und Code, die Sie vor der Veröffentlichung von Enhanced Health Reporting verwendet haben, aktualisieren, bevor Sie sie verwenden können. Um die Abwärtskompatibilität zu gewährleisten, ist bei einer Umgebungserstellung mithilfe der Elastic-Beanstalk-API die Funktion der erweiterten Integritätsberichte standardmäßig deaktiviert.
Sie konfigurieren die erweiterte Statusberichterstattung, indem Sie die Servicerolle, das Instance-Profil und die CloudWatch Amazon-Konfigurationsoptionen für Ihre Umgebung festlegen. Dafür gibt es drei Möglichkeiten: Sie legen die Konfigurationsoptionen im Ordner `.ebextensions` fest, Sie nutzen gespeicherte Konfigurationen oder Sie nehmen die Konfiguration direkt im Parameter `create-environment` des Aufrufs `option-settings` vor.
Um mit der API oder der AWS Befehlszeilenschnittstelle (CLI) eine Umgebung zu erstellen, die Enhanced Health unterstützt, müssen Sie: SDKs
+ Erstellen Sie eine Servicerolle und ein Instance-Profil mit den entsprechenden [Berechtigungen](concepts-roles.md).
+ Erstellen Sie eine neue Umgebung mit einer neuen [Plattformversion](concepts.platforms.md).
+ Legen Sie die [Konfigurationsoptionen](command-options.md) für Zustandssystemtyp, Instance-Profil und Servicerolle fest.
Verwenden Sie die folgenden Konfigurationsoptionen in den Namespaces `aws:elasticbeanstalk:healthreporting:system`, `aws:autoscaling:launchconfiguration` und `aws:elasticbeanstalk:environment`, um die erweiterten Zustandsberichte in der Umgebung zu konfigurieren.
## Konfigurationsoptionen für erweiterte Zustandsberichte
**SystemType**
Namespace: `aws:elasticbeanstalk:healthreporting:system`
Legen Sie den Wert auf fest, um die Funktion der erweiterten Zustandsberichte zu nutzen **enhanced**.
**IamInstanceProfile**
Namespace: `aws:autoscaling:launchconfiguration`
Geben Sie den Namen eines Instance-Profils an, das für die Verwendung mit Elastic Beanstalk konfiguriert ist.
**ServiceRole**
Namespace: `aws:elasticbeanstalk:environment`
Geben Sie den Namen einer Servicerolle an, die für die Verwendung mit Elastic Beanstalk konfiguriert ist.
**ConfigDocument** (optional)
Namespace: `aws:elasticbeanstalk:healthreporting:system`
Ein JSON-Dokument, das die Instanz- und Umgebungsmetriken definiert, in denen veröffentlicht CloudWatch werden soll. Beispiel:
```
{
"CloudWatchMetrics":
{
"Environment":
{
"ApplicationLatencyP99.9":60,
"InstancesSevere":60
}
"Instance":
{
"ApplicationLatencyP85":60,
"CPUUser": 60
}
}
"Version":1
}
```
**Anmerkung**
Je nach der Bereitstellung für Elastic Beanstalk erfordern Config-Dokumente möglicherweise eine spezielle Formatierung (z. B. Escape-Anführungszeichen). Beispiele finden Sie unter [Bereitstellen von benutzerdefinierten Metrikkonfigurations-Dokumenten](health-enhanced-cloudwatch.md#health-enhanced-cloudwatch-configdocument).
# Format der Protokolle der erweiterten Zustandsberichte
AWS Elastic Beanstalk Plattformen verwenden ein benutzerdefiniertes Webserver-Protokollformat, um Informationen über HTTP-Anfragen effizient an das erweiterte Gesundheitsberichtssystem weiterzuleiten. Das System analysiert die Protokolle, identifiziert Probleme und legt den Instance- und Umgebungszustand entsprechend fest. Wenn Sie den Webserver-Proxy in Ihrer Umgebung deaktivieren und Anfragen direkt über den Webcontainer verarbeiten, können Sie erweiterte Integritätsberichte trotzdem vollumfänglich nutzen, indem Sie den Server für die Ausgabe von Protokollen in den Speicherort und im Format konfigurieren, den bzw. das der [Elastic-Beanstalk-Integritäts-Agent](health-enhanced.md#health-enhanced-agent) verwendet.
**Anmerkung**
Die Informationen auf dieser Seite gilt nur für Linux-basierte Plattformen. Auf der Windows-Server-Plattform erhält Elastic Beanstalk diese Informationen über HTTP-Anfragen direkt von dem IIS-Webserver. Details hierzu finden Sie unter [Erfassung von Webserver-Metriken in IIS auf Windows Server](health-enhanced-metrics-server-iis.md).
## Konfiguration von Webserver-Protokollen
Elastic-Beanstalk-Plattformen sind so konfiguriert, dass sie zwei Protokolle mit Informationen über HTTP-Anfragen ausgeben. Die erste ist im Verbose-Format und bietet detaillierte Informationen über die Anfrage, einschließlich der Benutzer-Agent-Informationen des Anforderers und eines lesbaren Zeitstempels.
**/var/log/nginx/access.log**
Im folgenden Beispiel wird ein nginx-Proxy auf einer Ruby-Webserverumgebung ausgeführt, das Format ist jedoch vergleichbar für Apache.
```
172.31.24.3 - - [23/Jul/2015:00:21:20 +0000] "GET / HTTP/1.1" 200 11 "-" "curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3" "177.72.242.17"
172.31.24.3 - - [23/Jul/2015:00:21:21 +0000] "GET / HTTP/1.1" 200 11 "-" "curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3" "177.72.242.17"
172.31.24.3 - - [23/Jul/2015:00:21:22 +0000] "GET / HTTP/1.1" 200 11 "-" "curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3" "177.72.242.17"
172.31.24.3 - - [23/Jul/2015:00:21:22 +0000] "GET / HTTP/1.1" 200 11 "-" "curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3" "177.72.242.17"
172.31.24.3 - - [23/Jul/2015:00:21:22 +0000] "GET / HTTP/1.1" 200 11 "-" "curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3" "177.72.242.17"
```
Das zweite Protokoll ist im Terse-Format. Es enthält Informationen, die nur für erweiterte Zustandsberichte relevant sind. Dieses Protokoll wird in einen Unterordner mit dem Namen `healthd` ausgegeben und stündlich rotiert. Alte Protokolle werden sofort nach der Rotation gelöscht.
**/.log.2015-07-23-00 var/log/nginx/healthd/application**
Das folgende Beispiel zeigt ein Protokoll in einem für Computer lesbaren Format.
```
1437609879.311"/"200"0.083"0.083"177.72.242.17
1437609879.874"/"200"0.347"0.347"177.72.242.17
1437609880.006"/bad/path"404"0.001"0.001"177.72.242.17
1437609880.058"/"200"0.530"0.530"177.72.242.17
1437609880.928"/bad/path"404"0.001"0.001"177.72.242.17
```
Das Protokollformat für erweiterte Zustandsberichte enthält die folgenden Informationen:
+ Die Uhrzeit der Anfrage in Unix-Zeit
+ Den Pfad der Anfrage
+ Den HTTP-Statuscode für das Ergebnis
+ Die Anfragezeit
+ Die Upstream-Zeit
+ Den `X-Forwarded-For`-HTTP-Header
Für nginx-Proxys werden Zeiten in Floating-Point-Sekunden mit drei Dezimalstellen gedruckt. Für Apache werden ganze Mikrosekunden verwendet.
**Anmerkung**
Wenn Sie eine Warnung ähnlich der Folgenden in einer Protokolldatei sehen, in der Datum und Uhrzeit `DATE-TIME` ist, und Sie einen benutzerdefinierten Proxy verwenden, z. B. wie in einer Multicontainer-Docker-Umgebung, müssen Sie eine .ebextension zur Konfiguration Ihrer Umgebung verwenden, sodass die `healthd` Ihre Protokolldateien lesen kann:
```
W, [DATE-TIME #1922] WARN -- : log file "/var/log/nginx/healthd/application.log.DATE-TIME" does not exist
```
Sie können mit .ebextension im [Beispiel für Multicontainer-Docker](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/samples/docker-multicontainer-v2.zip) beginnen.
**/etc/nginx/conf.d/webapp\$1healthd.conf**
Das folgende Beispiel zeigt die Protokollkonfiguration für nginx mit dem `healthd`-Protokollformat hervorgehoben.
```
upstream my_app {
server unix:///var/run/puma/my_app.sock;
}
log_format healthd '$msec"$uri"'
'$status"$request_time"$upstream_response_time"'
'$http_x_forwarded_for';
server {
listen 80;
server_name _ localhost; # need to listen to localhost for worker tier
if ($time_iso8601 ~ "^(\d{4})-(\d{2})-(\d{2})T(\d{2})") {
set $year $1;
set $month $2;
set $day $3;
set $hour $4;
}
access_log /var/log/nginx/access.log main;
access_log /var/log/nginx/healthd/application.log.$year-$month-$day-$hour healthd;
location / {
proxy_pass http://my_app; # match the name of upstream directive which is defined above
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location /assets {
alias /var/app/current/public/assets;
gzip_static on;
gzip on;
expires max;
add_header Cache-Control public;
}
location /public {
alias /var/app/current/public;
gzip_static on;
gzip on;
expires max;
add_header Cache-Control public;
}
}
```
**etc/httpd/conf.d/healthd/.conf**
Im folgenden Beispiel wird die Protokollkonfiguration für Apache gezeigt.
```
LogFormat "%{%s}t\"%U\"%s\"%D\"%D\"%{X-Forwarded-For}i" healthd
CustomLog "|/usr/sbin/rotatelogs /var/log/httpd/healthd/application.log.%Y-%m-%d-%H 3600" healthd
```
## Generieren von Protokollen für erweiterte Zustandsberichte
Um Protokolle für den Zustandsagenten bereitzustellen, müssen Sie die folgenden Schritte ausführen:
+ Protokolle im korrekten Format ausgeben, wie im vorherigen Abschnitt gezeigt
+ Protokolle in Ausgabe `/var/log/nginx/healthd/`
+ Protokolle mit folgendem Format benennen: `application.log.$year-$month-$day-$hour`
+ Protokolle einmal pro Stunde rotieren
+ Protokolle nicht kürzen
# Benachrichtigungen und Fehlerbehebung
**Testen Sie Amazon Q Developer CLI zur KI-gestützten Fehlerbehebung**
Amazon Q Developer CLI kann Ihnen helfen, Umgebungsprobleme schnell zu beheben. Die Q CLI bietet Lösungen, indem sie den Umgebungsstatus überprüft, Ereignisse überprüft, Protokolle analysiert und klärende Fragen stellt. Weitere Informationen und detaillierte Anleitungen finden Sie in den Blogs unter [Troubleshooting Elastic Beanstalk Environments with Amazon Q Developer CLI](https://aws.amazon.com/blogs/devops/troubleshooting-elastic-beanstalk-environments-with-amazon-q-developer-cli/). AWS
Auf dieser Seite sind Meldungen zu häufig auftretenden Problemen sowie Links zu weiteren Informationen aufgeführt. Meldungen werden in [Bereich „Übersicht über die Umgebung“](environments-dashboard-envoverview.md) der Elastic Beanstalk Beanstalk-Konsole angezeigt und in [Ereignissen](using-features.events.md) aufgezeichnet, bei denen Gesundheitsprobleme über mehrere Prüfungen hinweg andauern.
## Bereitstellungen
Elastic Beanstalk überwacht Ihre Umgebung nach Bereitstellungen auf Konsistenz. Wenn eine fortlaufende Bereitstellung fehlschlägt, kann die Version Ihrer Anwendung auf den Instances in Ihrer Umgebung variieren. Dies kann der Fall sein, wenn eine Bereitstellung auf einem oder mehreren Stapeln erfolgreich ist, aber vor allen abgeschlossenen Stapeln fehlschlägt.
*In 2 von 5 Instanzen wurde eine falsche Anwendungsversion gefunden. Erwartete Version „v1" (Bereitstellung 1).*
*Falsche Anwendungsversion auf Umgebungsinstanzen. Erwartete Version „v1" (Bereitstellung 1).*
Die erwartete Anwendungsversion wird auf einigen oder allen Instances in einer Umgebung nicht ausgeführt.
*Falsche Anwendungsversion „v2" (Bereitstellung 2). Erwartete Version „v1" (Bereitstellung 1).*
Die Anwendung, die auf einer Instance bereitgestellt wurde, unterscheidet sich von der erwarteten Version. Wenn eine Bereitstellung fehlschlägt, wird die erwartete Version auf die Version aus der letzten erfolgreichen Bereitstellung zurückgesetzt. Im vorangegangenen Beispiel war die erste Bereitstellung (Version "v1") erfolgreich, aber die zweite Bereitstellung (Version "v2") ist fehlgeschlagen. Alle Instances mit "v2" werden als fehlerhaft angesehen.
Um dieses Problem zu lösen, starten Sie eine andere Bereitstellung. Sie können [eine frühere Version erneut bereitstellen](using-features.deploy-existing-version.md), von der Sie wissen, dass sie funktioniert, oder Ihre Umgebung so konfigurieren, dass [Zustandsprüfungen](using-features.rolling-version-deploy.md#environments-cfg-rollingdeployments-console) während der Bereitstellung ignoriert werden und die neue Version erneut bereitgestellt wird, um einen Abschluss der Bereitstellung zu erzwingen.
Sie können auch die Instances identifizieren und beenden, die mit der falschen Anwendungsversion ausgeführt werden. Elastic Beanstalk startet Instances mit der richtigen Version, um alle Instances zu ersetzen, die Sie beenden. Verwenden Sie den [EB-CLI-Zustandsbefehl](health-enhanced-ebcli.md), um Instances zu identifizieren, die mit der falschen Anwendungsversion ausgeführt werden.
## Anwendungsserver
*15 % der Abfragen geben den Fehler HTTP 4xx zurück*
*20 % der Abfragen an den ELB geben den Fehler HTTP 4xx zurück.*
Ein hoher Prozentsatz der HTTP-Anfragen an eine Instance oder eine Umgebung schlagen mit 4xx-Fehlern fehl.
Ein Serienstatuscode 400 gibt an, dass der Benutzer eine fehlerhafte Anfrage getätigt hat, beispielsweise die Anfrage einer Seite, die nicht vorhanden ist (404 File Not Found) oder auf die der Benutzer keinen Zugriff hat (403 Forbidden). Eine geringe Anzahl von 404s ist nicht ungewöhnlich, aber eine große Anzahl kann bedeuten, dass es interne oder externe Links zu nicht verfügbaren Seiten gibt. Diese Probleme können behoben werden, indem fehlerhafte interne Links repariert und Umleitungen für fehlerhafte externe Links hinzugefügt werden.
*5 % der Anfragen schlagen mit HTTP-5xx fehl*
*3 % der Abfragen an den ELB schlagen mit HTTP 5xx fehl.*
Ein hoher Prozentsatz der HTTP-Anfragen an eine Instance oder eine Umgebung schlagen mit Serienstatuscodes 500 fehl.
Ein Serienstatuscode 500 gibt an, dass beim Anwendungsserver ein interner Fehler aufgetreten ist. Diese Fehler zeigen an, dass es einen Fehler in Ihrem Anwendungscode gibt, der identifiziert und schnell behoben werden sollte.
*95 % der CPU wird verwendet*
Auf einer Instance meldet der Zustandsagent einen extrem hohen Prozentsatz an CPU-Auslastung und setzt den Instance-Zustand auf **Warning (Warnung)** oder **Degraded (Schwach)**.
Skalieren Sie Ihre Umgebung, um Last von Instances zu nehmen.
## Worker-Instances
*20 Nachrichten in der Warteschlange (vor 25 Sekunden)*
Anfragen werden schneller zur Warteschlange Ihrer Worker-Umgebung hinzugefügt, als sie verarbeitet werden können. Skalieren Sie Ihre Umgebung zur Erhöhung der Kapazität.
*5 Nachrichten in Warteschlange für unzustellbare Nachrichten (vor 15 Sekunden)*
Worker-Anfragen schlagen wiederholt fehl und werden zur hinzugefügt [Warteschlangen mit unzustellbaren Briefen](using-features-managing-env-tiers.md#worker-deadletter). Prüfen Sie die Anfragen in der Warteschlange für unzustellbare Nachrichten, um zu sehen, warum sie nicht erfüllt werden.
## Sonstige Ressourcen
*4 aktive Instances liegen unter der Mindestgröße für Auto Scaling-Gruppen von 5*
Die Anzahl der Instances in Ihrer Umgebung ist geringer als die minimale Konfiguration für die Auto-Scaling-Gruppe.
*Benachrichtigungen der Auto Scaling-Gruppe (Gruppenname) wurden gelöscht oder geändert*
Die Benachrichtigungen, die für Ihre Auto-Scaling-Gruppe konfiguriert sind, wurden außerhalb von Elastic Beanstalk geändert.
# KI-gestützte Umgebungsanalyse
AWS Elastic Beanstalk Die KI-gestützte Analyse identifiziert die Grundursachen und empfiehlt Lösungen für umweltbedingte Gesundheitsprobleme. Wenn in Ihrer Umgebung Probleme auftreten, können Sie mithilfe der Operationen `RequestEnvironmentInfo` und der `RetrieveEnvironmentInfo` API-Operationen mit dem `analyze` Informationstyp eine KI-Analyse anfordern, um KI-generierte Erkenntnisse und empfohlene Lösungen zu erhalten.
**Anmerkung**
Die KI-Analyse ist nur für unterstützte Amazon Linux 2- und AL2023 Plattformversionen verfügbar, die am oder nach dem 16. Februar 2026 veröffentlicht wurden.
## Funktionsweise
Wenn Sie eine KI-Analyse anfordern, führt Elastic Beanstalk ein Skript auf einer Instance in Ihrer Umgebung aus, das aktuelle Ereignisse, den Instanzstatus und Logs (bis zu 170.000 [Tokens](https://docs.aws.amazon.com/bedrock/latest/userguide/key-definitions.html) an Daten) sammelt. Anschließend werden diese Daten an Amazon Bedrock in Ihrem Konto gesendet und Sie erhalten Einblicke und empfohlene nächste Schritte.
## Voraussetzungen
Bevor Sie die KI-Analyse verwenden, stellen Sie sicher, dass Ihre Umgebung die folgenden Anforderungen erfüllt:
+ Umgebung, auf der eine [unterstützte Plattformversion](#health-ai-analysis-supported-platforms) ausgeführt wird
+ [Instanzprofil](iam-instanceprofile.md) mit den erforderlichen Berechtigungen (siehe [Erforderliche Berechtigungen](#health-ai-analysis-permissions) unten)
+ **Details zu anthropischen Anwendungsfällen — Bei** der KI-Analyse werden Modelle von Anthropic Claude über Amazon Bedrock verwendet. Anthropic verlangt von Ihnen, dass Sie ein einmaliges Formular mit Einzelheiten zu einem Anwendungsfall einreichen, bevor Sie ihre Modelle aufrufen können. Um dieses Formular einzureichen, wählen Sie ein beliebiges Anthropic-Modell aus dem Modellkatalog in der [Amazon Bedrock-Konsole](https://console.aws.amazon.com/bedrock/) aus oder rufen Sie die API auf [https://docs.aws.amazon.com/bedrock/latest/APIReference/API_PutUseCaseForModelAccess.html](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_PutUseCaseForModelAccess.html). Sie müssen dies nur einmal pro AWS Konto tun. Wenn Sie das Formular über das Verwaltungskonto der AWS Organizations einreichen, deckt es automatisch alle Mitgliedskonten der Organisation ab. Weitere Informationen finden Sie unter [Zugriff auf Amazon Bedrock Foundation-Modelle.](https://docs.aws.amazon.com/bedrock/latest/userguide/model-access.html)
+ **GovCloud Regionen** — Wenn Sie Regionen AWS GovCloud (USA) verwenden, müssen Sie den Zugriff auf das neueste Modell von Anthropic Claude Sonnet and/or Opus in Amazon Bedrock aktivieren, bevor Sie die KI-Analyse verwenden können. Anweisungen zur Aktivierung des Modellzugriffs in GovCloud Regionen finden Sie unter [Zugriff auf Amazon Bedrock Foundation-Modelle verwalten](https://docs.aws.amazon.com/bedrock/latest/userguide/model-access.html#model-access-govcloud). Informationen zum neuesten verfügbaren Modell von Anthropic Claude Sonnet and/or Opus finden Sie unter [Unterstützte Regionen und Modelle](https://docs.aws.amazon.com/bedrock/latest/userguide/inference-profiles-support.html) für Inferenzprofile.
## Erforderliche Berechtigungen
Um die KI-Analyse verwenden zu können, muss das Amazon EC2 EC2-Instance-Profil für Ihre Umgebung über Berechtigungen zum Aufrufen von Amazon Bedrock verfügen. Fügen Sie Ihrem Instance-Profil die folgenden Berechtigungen hinzu:
+ `bedrock:InvokeModel`
+ `bedrock:ListFoundationModels`
+ `elasticbeanstalk:DescribeEvents`
+ `elasticbeanstalk:DescribeEnvironmentHealth`
Weitere Informationen zur Konfiguration von Instanzprofilen finden Sie unter[Elastic Beanstalk Instance-Profile verwalten](iam-instanceprofile.md).
## KI-Analyse in der Konsole verwenden
**Aus der Umgebungsübersicht**
Wenn der Integritätsstatus Ihrer Umgebung „**Warnung**“, „**Eingeschwächt“** oder „**Schwerwiegend**“ lautet, wird im Bereich „Umgebungsübersicht“ eine **KI-Analyseschaltfläche** angezeigt. Klicken Sie auf diese Schaltfläche, um eine KI-Analyse Ihrer Umgebung zu starten.
**Von der Seite „Logs“**
Sie können die KI-Analyse auch über die Seite **Logs** im Navigationsbereich aufrufen. Klicken Sie auf die Schaltfläche **KI-Analyse**, um eine KI-gestützte Analyse des aktuellen Zustands Ihrer Umgebung anzufordern.
## Verwenden Sie die KI-Analyse mit dem AWS CLI
Sie können die Elastic Beanstalk Beanstalk-API über verwenden AWS CLI , um KI-Analysen programmgesteuert anzufordern und abzurufen.
**KI-Analyse anfordern**
Verwenden Sie die [https://docs.aws.amazon.com/elasticbeanstalk/latest/api/API_RequestEnvironmentInfo.html](https://docs.aws.amazon.com/elasticbeanstalk/latest/api/API_RequestEnvironmentInfo.html)Operation, bei der der `InfoType` Parameter auf gesetzt ist`analyze`.
**Example AWS CLI - KI-Analyse anfordern**
```
aws elasticbeanstalk request-environment-info \
--environment-name my-env \
--info-type analyze \
--region us-east-1
```
**KI-Analyse abrufen**
Verwenden Sie die [https://docs.aws.amazon.com/elasticbeanstalk/latest/api/API_RetrieveEnvironmentInfo.html](https://docs.aws.amazon.com/elasticbeanstalk/latest/api/API_RetrieveEnvironmentInfo.html)Operation mit dem auf eingestellten `InfoType` Parameter`analyze`, um die Analyseergebnisse abzurufen.
**Example AWS CLI - Rufen Sie die KI-Analyse ab**
```
aws elasticbeanstalk retrieve-environment-info \
--environment-name my-env \
--info-type analyze \
--region us-east-1
```
Die Antwort umfasst eine KI-generierte Analyse des aktuellen Zustands der Umgebung sowie empfohlene Lösungen für alle identifizierten Probleme.
## KI-Analyse mit der EB CLI verwenden
Wenn Sie die EB-CLI verwenden, können Sie mit der Option `--analyze` (`-ai`) des **eb logs** Befehls eine KI-Analyse anfordern. Der Befehl fordert die Analyse an, wartet, bis sie abgeschlossen ist, und zeigt die Ergebnisse an.
**Example EB CLI - KI-Analyse anfordern**
```
$ eb logs --analyze
```
Die `--analyze` Option ist nicht kompatibel mit `--instance``--all`,`--zip`, oder`--log-group`. Die vollständige Befehlsreferenz finden Sie unter[**eb logs**](eb3-logs.md).
**Anmerkung**
Die `--analyze` Option erfordert EB CLI Version 3.27 oder höher.
## Wichtige Überlegungen
+ **Preisgestaltung — Die** KI-Analyse verwendet Amazon Bedrock, um Ihre Umgebungsdaten zu verarbeiten, und für Modellaufrufe gelten die Standardpreise von Amazon Bedrock. Details zu den Preisen finden Sie unter [Amazon Bedrock – Preise](https://aws.amazon.com/bedrock/pricing/).
+ **Plattformanforderung** — Die KI-Analyse ist nur für Amazon Linux 2 und AL2023 basierte Plattformversionen verfügbar, die am oder nach dem 16. Februar 2026 veröffentlicht wurden. Um diese Funktion nutzen zu können, aktualisieren Sie Ihre Umgebung auf eine unterstützte Plattformversion. Weitere Informationen finden Sie unter [Aktualisieren der Plattformversion für die Elastic Beanstalk-Umgebung](using-features.platform.upgrade.md).
+ **Berechtigungen** — Stellen Sie vor der Verwendung der KI-Analyse sicher, dass Ihr Instance-Profil über die erforderlichen Amazon Bedrock-Berechtigungen (`bedrock:InvokeModel`und`bedrock:ListFoundationModels`) und Elastic Beanstalk Beanstalk-Berechtigungen (`elasticbeanstalk:DescribeEvents`und) verfügt. `elasticbeanstalk:DescribeEnvironmentHealth`
+ **Datenschutz** — Die Analyse sendet Umgebungsereignisse und Protokolle zur Verarbeitung an Amazon Bedrock in Ihrem Konto. Informationen darüber, wie Amazon Bedrock mit Ihren Daten umgeht, finden Sie unter [Amazon Bedrock Security and Compliance](https://aws.amazon.com/bedrock/security-compliance/).
+ **Servicekontingente** — Die KI-Analyse verwendet ein Anthropic-Claude-Modell in Amazon Bedrock, das Standardkontingente für Anfragen pro Minute und Token pro Minute hat. Wenn Sie auf Drosselungsfehler stoßen, können Sie eine Erhöhung des Kontingents beantragen. Weitere Informationen finden Sie unter [Anfordern einer Kontingenterhöhung](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html).
## Unterstützte Plattformversionen
Die KI-Analyse wird auf Amazon Linux 2 und AL2023 basierten Plattformversionen unterstützt, die am oder nach dem [16. Februar 2026](RELEASE_NOTES_URL) veröffentlicht wurden. Informationen zur Überprüfung Ihrer Plattformversion finden Sie in den [Versionshinweisen zu Elastic Beanstalk](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/welcome.html).
# Alarme verwalten
Dieses Thema führt Sie durch die Schritte zum Erstellen von Alarmen für Metriken, die Sie überwachen. Es enthält auch Anweisungen zum Anzeigen Ihrer vorhandenen Alarme und zum Überprüfen ihres Status.
Sie können Alarme für Metriken erstellen, die Sie mit der Elastic Beanstalk-Konsole überwachen. Alarme helfen Ihnen dabei, Änderungen an Ihrer AWS Elastic Beanstalk Umgebung zu überwachen, sodass Sie Probleme leicht erkennen und beheben können, bevor sie auftreten. Sie können beispielsweise einen Alarm festlegen, der Sie benachrichtigt, wenn die CPU-Auslastung in einer Umgebung einem bestimmten Schwellenwert überschreitet, wodurch sichergestellt wird, dass Sie benachrichtigt werden, bevor ein potentielles Problem auftritt. Weitere Informationen finden Sie unter [Elastic Beanstalk mit Amazon verwenden CloudWatch](AWSHowTo.cloudwatch.md).
**Anmerkung**
Elastic Beanstalk verwendet CloudWatch für Überwachung und Alarme, was bedeutet, dass die CloudWatch Kosten für alle Alarme, die Sie verwenden, Ihrem AWS Konto belastet werden.
Weitere Informationen zur Überwachung spezifischer Metriken finden Sie unter [Grundlegende Zustandsberichte](using-features.healthstatus.md).
**So prüfen Sie den Status Ihrer Alarme**
1. Öffnen Sie die [Elastic Beanstalk Beanstalk-Konsole](https://console.aws.amazon.com/elasticbeanstalk) und wählen Sie in der Liste **Regionen** Ihre aus. AWS-Region
1. Wählen Sie im Navigationsbereich **Environments (Umgebungen)** aus und wählen Sie dann in der Liste den Namen Ihrer Umgebung aus.
1. Klicken Sie im Navigationsbereich auf **Alarms** (Alarme).
Die Seite zeigt eine Liste vorhandener Alarme an. Wenn sich Alarme im Alarmstatus befinden, werden sie mit dem Warnsymbol () gekennzeichnet. ![\[Image of the warning icon.\]](http://docs.aws.amazon.com/de_de/elasticbeanstalk/latest/dg/images/warning.png)
1. Um Alarme zu filtern, wählen Sie das Drop-down-Menü und dann einen Filter aus.
1. Um einen Alarm zu bearbeiten oder zu löschen, wählen Sie das Bearbeitungssymbol (![\[Image of a cog, which serves as the edit icon.\]](http://docs.aws.amazon.com/de_de/elasticbeanstalk/latest/dg/images/cog.png)) bzw. das Löschsymbol (![\[Image of an x, which servers as the delete icon.\]](http://docs.aws.amazon.com/de_de/elasticbeanstalk/latest/dg/images/x.png)).
**So erstellen Sie einen Alarm**
1. Öffnen Sie die [Elastic Beanstalk Beanstalk-Konsole](https://console.aws.amazon.com/elasticbeanstalk) und wählen Sie in der Liste **Regionen** Ihre aus. AWS-Region
1. Wählen Sie im Navigationsbereich **Environments (Umgebungen)** aus und wählen Sie dann in der Liste den Namen Ihrer Umgebung aus.
1. Wählen Sie im Navigationsbereich **Monitoring (Überwachung)** aus.
1. Suchen Sie die Metrik, für die Sie einen Alarm erstellen möchten, und wählen Sie dann das Alarmsymbol ()![\[Image of a bell, which serves as the alarm icon.\]](http://docs.aws.amazon.com/de_de/elasticbeanstalk/latest/dg/images/bell.png). Die Seite **Add alarm (Alarm hinzufügen)** wird angezeigt.
1. Geben Sie Informationen zum Alarm ein:
+ **Name**: Ein Name für diesen Alarm.
+ **Description** (optional): Eine kurze Beschreibung dieses Alarms.
+ **Period**: Das Zeitintervall zwischen den Auslesungen.
+ **Threshold**: Beschreibt das Verhalten und den Wert, den die Metrik überschreiten muss, um einen Alarm auszulösen.
+ **Change state after**: Der Zeitraum nach dem Überschreiten eines Schwellenwerts, der eine Änderung des Status des Alarms auslöst.
+ **Notify**: Das Amazon SNS-Thema, das benachrichtigt wird, wenn ein Alarm einen anderen Zustand annimmt.
+ **Benachrichtigung, wenn sich der Zustand in folgende Status ändert**:
+ **OK**: Die Metrik liegt innerhalb des festgelegten Schwellenwerts.
+ **Alarm**: Die Metrik hat den festgelegten Schwellenwert überschritten.
+ **Insufficient data**: Der Alarm wurde soeben gestartet; die Metrik ist nicht verfügbar oder es sind nicht genügend Daten verfügbar, damit die Metrik den Alarmstatus bestimmen kann.
1. Wählen Sie **Hinzufügen** aus. Der Umgebungsstatus wechselt zu Grau, während die Umgebung aktualisiert wird. Sie können den erstellten Alarm anzeigen, indem Sie im Navigationsbereich **Alarms (Alarme)** wählen.
# Anzeigen des Änderungsverlaufs einer Elastic Beanstalk-Umgebung
In diesem Thema wird erklärt, wie Sie die Elastic Beanstalk Console verwenden können, um einen Verlauf der Konfigurationsänderungen anzuzeigen, die an Ihren Elastic Beanstalk Beanstalk-Umgebungen vorgenommen wurden.
Elastic Beanstalk ruft Ihren Änderungsverlauf aus Ereignissen ab, die in [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) aufgezeichnet wurden, und zeigt sie in einer Liste an, durch die Sie einfach navigieren und filtern können.
Das Fenster „Änderungsverlauf“ zeigt die folgenden Informationen für Änderungen an Ihren Umgebungen an:
+ Das Datum und die Uhrzeit, zu der eine Änderung vorgenommen wurde
+ Den IAM-Benutzer, der für eine vorgenommene Änderung verantwortlich war
+ Das Quelltool (entweder die Elastic Beanstalk-Befehlszeilenschnittstelle (EB CLI) oder die Konsole), mit dem die Änderung vorgenommen wurde
+ Den Konfigurationsparameter und neue Werte, die festgelegt wurden
Alle sensiblen Daten, die Teil der Änderung sind, wie die Namen der von der Änderung betroffenen Datenbankbenutzer, werden nicht angezeigt.
**So zeigen Sie den Änderungsverlauf an**
1. Öffnen Sie die [Elastic Beanstalk Beanstalk-Konsole](https://console.aws.amazon.com/elasticbeanstalk) und wählen Sie in der Liste **Regionen** Ihre aus. AWS-Region
1. Wählen Sie im Navigationsbereich **Change history (Änderungsverlauf)** aus.
Auf der Seite „Change History“ (Änderungsverlauf) wird eine detaillierte Liste der Konfigurationsänderungen angezeigt, die an Ihren Elastic-Beanstalk-Umgebungen vorgenommen wurden.
Beachten Sie beim Navigieren in den Informationen auf dieser Seite die folgenden Punkte:
+ Sie können durch die Liste blättern, indem Sie **<** (Zurück) oder **>** (Weiter) wählen oder eine bestimmte Seitenzahl wählen.
+ Wählen Sie in der Spalte **Konfigurationsänderungen** das Pfeilsymbol aus, um zwischen dem Erweitern und Reduzieren der Liste der Änderungen unter der Überschrift **Vorgenommene Änderungen** zu wechseln.
+ Verwenden Sie die Suchleiste, um Ihre Ergebnisse aus der Liste des Änderungsverlaufs zu filtern. Sie können eine beliebige Zeichenfolge eingeben, um die Liste der angezeigten Änderungen einzugrenzen.
Beachten Sie Folgendes zum Filtern der angezeigten Ergebnisse:
+ Beim Suchefilter wird die Groß-/Kleinschreibung nicht beachtet.
+ Sie können angezeigte Änderungen basierend auf Informationen in der Spalte **Konfigurationsänderungen** filtern, auch wenn sie nicht sichtbar sind, da sie innerhalb der **vorgenommenen Änderungen** reduziert wurden.
+ Sie können nur die angezeigten Ergebnisse filtern. Der Filter bleibt jedoch bestehen, auch wenn Sie auf eine andere Seite gehen möchten, um weitere Ergebnisse anzuzeigen. Ihre gefilterten Ergebnisse werden an den Ergebnissatz auf der nächsten Seite angehängt.
Die folgenden Beispiele zeigen, wie die auf dem vorherigen Bildschirm angezeigten Daten gefiltert werden können:
+ Geben Sie **GettingStartedApp-env** in das Suchfeld ein, um die Ergebnisse so einzugrenzen, dass sie nur die Änderungen enthalten, die an der Umgebung mit dem Namen *GettingStartedApp-env* vorgenommen wurden.
+ Geben Sie **example3** in das Suchfeld ein, um die Ergebnisse so einzugrenzen, dass sie nur Änderungen enthalten, die von IAM-Benutzern vorgenommen wurden, deren Benutzername die Zeichenfolge *example3* enthält.
+ Geben Sie **2020-10** in das Suchfeld ein, um die Ergebnisse so einzugrenzen, dass nur Änderungen enthalten sind, die im Oktober 2020 vorgenommen wurden. Ändern Sie den Suchwert in **2020-10-16**, um die angezeigten Ergebnisse weiter zu filtern, sodass nur Änderungen enthalten sind, die am 16. Oktober 2020 vorgenommen wurden.
+ Geben Sie **proxy:staticfiles** in das Suchfeld ein, um die Ergebnisse so einzugrenzen, dass sie nur die Änderungen einschließen, die am Namespace namens *aws:elasticbeanstalk:environment:proxy:staticfiles* vorgenommen wurden. Die Zeilen, die angezeigt werden, sind das Ergebnis des Filters. Dies gilt auch für Ergebnisse, die unter **Änderungen** reduziert sind.
# Ereignis-Stream einer Elastic Beanstalk-Umgebung anzeigen
In diesem Thema wird erklärt, wie Sie auf Ereignisse und Benachrichtigungen zugreifen, die mit Ihrer Anwendung verknüpft sind.
## Ereignisse mit der Elastic Beanstalk Beanstalk-Konsole anzeigen
**So zeigen Sie Ereignisse mit der Elastic Beanstalk Beanstalk-Konsole an**
1. Öffnen Sie die [Elastic Beanstalk Beanstalk-Konsole](https://console.aws.amazon.com/elasticbeanstalk) und wählen Sie in der Liste **Regionen** Ihre aus. AWS-Region
1. Wählen Sie im Navigationsbereich **Environments (Umgebungen)** aus und wählen Sie dann in der Liste den Namen Ihrer Umgebung aus.
1. Wählen Sie im Navigationsbereich die Option **Events**.
Die Seite „Event“ (Ereignisse) zeigt eine Liste aller Ereignisse an, die für die Umgebung aufgezeichnet wurden. Sie können durch die Liste blättern, indem Sie **<** (vorherige), **>** (nächste) oder Seitenzahlen wählen. Sie können nach der Art der angezeigten Ereignisse filtern, indem Sie die Drop-down-Liste **Severity (Schweregrad)** verwenden.
## Ereignisse mit Befehlszeilentools anzeigen
Die [EB CLI](eb-cli3.md) und die [AWS CLI](https://aws.amazon.com/cli/) bieten Befehle zum Abrufen von Ereignissen. Wenn Sie Ihre Umgebung mit der EB CLI verwalten, verwenden Sie [**eb events**](eb3-events.md), um eine Liste der Ereignisse zu drucken. Dieser Befehl verfügt zudem über eine `--follow`-Option, die weiterhin neue Ereignisse angezeigt, bis Sie **Strg\$1C** drücken, um die Ausgabe zu beenden.
Um Ereignisse mit dem abzurufen AWS CLI, verwenden Sie den `describe-events` Befehl und geben Sie die Umgebung mit Namen oder ID an:
```
$ aws elasticbeanstalk describe-events --environment-id e-gbjzqccra3
{
"Events": [
{
"ApplicationName": "elastic-beanstalk-example",
"EnvironmentName": "elasticBeanstalkExa-env",
"Severity": "INFO",
"RequestId": "a4c7bfd6-2043-11e5-91e2-9114455c358a",
"Message": "Environment update completed successfully.",
"EventDate": "2015-07-01T22:52:12.639Z"
},
...
```
Weitere Informationen zu den Befehlszeilentools finden Sie unter[Einrichtung der EB-Befehlszeilenschnittstelle (EB CLI) zur Verwaltung von Elastic Beanstalk](eb-cli3.md).
# Auflisten von Server-Instances/Verbinden mit Server-Instances
In diesem Thema wird erklärt, wie Sie eine Liste der EC2 Amazon-Instances anzeigen, auf denen Ihre Elastic Beanstalk Beanstalk-Anwendungsumgebung ausgeführt wird, und wie Sie eine Verbindung zu ihnen herstellen können.
In der Elastic Beanstalk Beanstalk-Konsole können Sie sich eine Liste der EC2 Amazon-Instances ansehen, auf denen Ihre AWS Elastic Beanstalk Anwendungsumgebung ausgeführt wird. Eine Verbindung zu den Instances stellen Sie über einen beliebigen SSH-Client her. Die Verbindung zu Instances, auf denen Windows ausgeführt wird, können Sie mit Remote Desktop herstellen.
**Wichtig**
Bevor Sie auf Ihre von Elastic Beanstalk bereitgestellten EC2 Amazon-Instances zugreifen können, müssen Sie ein EC2 Amazon-Schlüsselpaar erstellen und Ihr von Elastic Beanstalk bereitgestelltes Amazon so konfigurieren, dass es das Amazon-Schlüsselpaar verwendet. EC2instances EC2 Sie können Ihre EC2 Amazon-Schlüsselpaare mithilfe der [AWS Management Console](https://console.aws.amazon.com/) einrichten. Anweisungen zum Erstellen eines key pair für Amazon EC2 finden Sie im *Amazon-Leitfaden „ EC2 Erste Schritte*“. Weitere Informationen zur Konfiguration Ihrer EC2 Amazon-Instances für die Verwendung eines EC2 Amazon-Schlüsselpaars finden Sie unter[EC2 key pair](using-features.managing.security.md#using-features.managing.security.keypair).
Standardmäßig ermöglicht Elastic Beanstalk keine Remoteverbindungen zu EC2 Instances in einem Windows-Container, außer denen in älteren Windows-Containern. (Elastic Beanstalk konfiguriert EC2 Instances in älteren Windows-Containern so, dass sie Port 3389 für RDP-Verbindungen verwenden.) Sie können Remoteverbindungen zu Ihren EC2 Windows-Instances aktivieren, indem Sie einer Sicherheitsgruppe eine Regel hinzufügen, die eingehenden Datenverkehr zu den Instances autorisiert. Es wird ausdrücklich empfohlen, diese Regel bei Beendigung der Remote-Verbindung zu entfernen. Sie können die Regel bei der nächsten Remote-Anmeldung wieder hinzufügen. Weitere Informationen finden Sie unter [Hinzufügen einer Regel für eingehenden RDP-Verkehr zu einer Windows-Instance](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/authorizing-access-to-an-instance.html#authorizing-access-to-an-instance-rdp) und [Verbinden mit der Windows Instanz](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/EC2Win_GetStarted.html#connecting_to_windows_instance) im *Amazon Elastic Compute Cloud-Benutzerhandbuch für Microsoft Windows*.///
**So zeigen Sie EC2 Amazon-Instances für eine Umgebung an und stellen eine Verbindung zu ihnen her**
1. Öffnen Sie die EC2 Amazon-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Wählen Sie im Navigationsbereich der Konsole **Load Balancers** aus.
1. Load Balancer, die von Elastic Beanstalk erstellt wurden, haben **awseb** im Namen. Suchen Sie nach dem Load Balancer für Ihre Umgebung und klicken Sie darauf.
1. Wählen Sie im unteren Abschnitt der Konsole die Registerkarte **Instances** aus.
Die Liste der Instances, die vom Load Balancer für die Elastic Beanstalk-Umgebung verwendet werden, wird angezeigt. Notieren Sie sich die ID der Instance, zu der eine Verbindung hergestellt werden soll.
1. Wählen Sie im Navigationsbereich der EC2 Amazon-Konsole **Instances** aus und suchen Sie Ihre Instance-ID in der Liste.
1. Klicken Sie mit der rechten Maustaste auf die Instance-ID für die EC2 Amazon-Instance, die im Load Balancer Ihrer Umgebung ausgeführt wird, und wählen Sie dann im Kontextmenü **Connect** aus.
1. Notieren Sie sich die öffentliche DNS-Adresse der Instance von der Registerkarte **Description**.
1. Stellen Sie mithilfe des SSH-Clients Ihrer Wahl eine Connect zu einer Instance her, auf der Linux ausgeführt wird, und geben Sie dann **ssh -i .ec2/mykeypair.pem ec2-user@ ein. of-the-instance
Weitere Informationen zum Herstellen einer Verbindung mit einer Amazon EC2 Linux-Instance finden Sie unter [Erste Schritte mit Amazon EC2 Linux-Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html) im * EC2 Amazon-Benutzerhandbuch*.
Wenn Ihre Elastic Beanstalk Beanstalk-Umgebung die [Plattform .NET auf Windows Server](create_deploy_NET.container.console.md) verwendet, finden Sie weitere Informationen unter [Erste Schritte mit Amazon EC2 Windows-Instances](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/EC2_GetStarted.html) im * EC2 Amazon-Benutzerhandbuch*.
# Protokolle von Amazon EC2-Instances in Ihrer Elastic Beanstalk Umgebung anzeigen
In diesem Thema werden die Arten von Instance-Logs erklärt, die Elastic Beanstalk bereitstellt. Es enthält auch detaillierte Anweisungen zum Abrufen und Verwalten dieser Dateien.
Die Amazon EC2-Instances der Elastic Beanstalk-Umgebung generieren Protokolle, die Sie zur Behebung von Fehlern mit der Anwendung oder mit Konfigurationsdateien aufrufen können. Protokolle, die vom Webserver, dem Anwendungsserver und den Skripten der Elastic Beanstalk-Plattform erstellt und lokal auf einzelnen Instances gespeichert CloudFormation werden. Sie können diese über die [Environment Management Console](environments-console.md) oder die EB CLI ganz einfach abrufen. Sie können Ihre Umgebung auch so konfigurieren, dass Protokolle in Echtzeit an Amazon CloudWatch Logs gestreamt werden.
Als Protokollfragmente werden die letzten 100 Zeilen der am häufigsten verwendeten Protokolldateien bezeichnet, z. B. Elastic Beanstalk-Betriebsprotokolle sowie Protokolle vom Webserver oder Anwendungsserver. Wenn Sie Protokollfragmente in der Environment Management Console oder mit **eb logs** anfordern, verkettet eine Instance der Umgebung die letzten Protokolleinträge zu einer einzigen Textdatei und lädt diese in Amazon S3 hoch.
Bei Bundle-Protokollen handelt es sich um vollständige Protokolle für ein breiteres Spektrum an Protokolldateien, darunter Protokolle von "yum" und "cron" und verschiedene Protokolle von CloudFormation. Bei der Anforderung von Bundle-Protokollen komprimiert eine Instance der Umgebung die vollständigen Protokolldateien in ein ZIP-Archiv und lädt dieses in Amazon S3 hoch.
Damit rotierte Protokolle in Amazon S3 hochgeladen werden können, müssen die Instances der Umgebung über ein [Instance-Profil](concepts-roles-instance.md) mit Schreibberechtigung für den Elastic Beanstalk Amazon S3-Bucket verfügen. Diese Berechtigungen sind im Instance-Standardprofil enthalten, zu dessen Erstellung Sie von Elastic Beanstalk aufgefordert werden, wenn Sie zum ersten Mal eine Umgebung in der Elastic Beanstalk-Konsole starten.
**So rufen Sie Instance-Protokolle ab:**
1. Öffnen Sie die [Elastic Beanstalk Beanstalk-Konsole](https://console.aws.amazon.com/elasticbeanstalk) und wählen Sie in der Liste **Regionen** Ihre aus. AWS-Region
1. Wählen Sie im Navigationsbereich **Environments (Umgebungen)** aus und wählen Sie dann in der Liste den Namen Ihrer Umgebung aus.
1. Wählen Sie im Navigationsbereich **Protokolle** aus.
1. Wählen Sie **Request Logs (Protokolle anfordern)** und wählen Sie dann den Typ der Protokolle, die abgerufen werden sollen. Um Protokollfragmente abzurufen, wählen Sie **Last 100 Lines** aus. Für den Abruf von Bundle-Protokollen wählen Sie **Full Logs** aus.
1. Wenn Elastic Beanstalk mit dem Abrufen Ihrer Protokolle fertig ist, wählen Sie **Download (Herunterladen)** aus.
Elastic Beanstalk speichert Tail- und Bundle-Protokolle in einem Amazon S3-Bucket und generiert eine vordefinierte Amazon S3-URL, über die Sie auf Ihre Protokolle zugreifen können. Elastic Beanstalk löscht die Dateien von Amazon S3 nach 15 Minuten.
**Warnung**
Jeder im Besitz der vorsignierten Amazon S3-URL kann vor dem Löschen auf die Dateien zugreifen. Geben Sie nur vertrauenswürdigen Parteien Zugriff auf die URL.
**Anmerkung**
Ihre Benutzerrichtlinie muss die Berechtigung `s3:DeleteObject` haben. Elastic Beanstalk verwendet Ihre Benutzerberechtigungen, um die Protokolle von Amazon S3 zu löschen.
Damit Protokolle erhalten bleiben, können Sie Ihre Umgebung so konfigurieren, dass Protokolle nach dem Rotieren automatisch in Amazon S3 veröffentlicht werden. Befolgen Sie zum Rotieren von Protokollen in Amazon S3 die Anleitung unter [Konfigurieren der Anzeige von Instance-Protokollen](environments-cfg-logging.md#environments-cfg-logging-console). Instances in der Umgebung versuchen dann, Protokolle hochzuladen, die einmal pro Stunde rotiert wurden.
Wenn die Anwendung Protokolle an einem Speicherort generiert, der nicht zur Standardkonfiguration der Umgebungsplattform gehört, können Sie die Standardkonfiguration mithilfe von Konfigurationsdateien erweitern (`[.ebextensions](ebextensions.md)`). Die Protokolldateien der Anwendung können zu Protokollfragmenten, zu Bundle-Protokollen oder zur Protokollrotation hinzugefügt werden.
Für Echtzeit-Log-Streaming und Langzeitspeicherung konfigurieren Sie Ihre Umgebung so, dass [Logs an Amazon CloudWatch Logs gestreamt](#health-logs-cloudwatchlogs) werden.
Informationen zur KI-gestützten Analyse Ihrer Umgebungsprotokolle, Ereignisse und des Zustands Ihrer Instances zur Identifizierung von Ursachen und Lösungen für Integritätsprobleme finden Sie unter[KI-gestützte Umgebungsanalyse](health-ai-analysis.md).
**Topics**
+ [Speicherort der Protokolle auf Amazon EC2-Instances](#health-logs-instancelocation)
+ [Speicherort der Protokolle in Amazon S3](#health-logs-s3location)
+ [Protokollrotations-Einstellungen auf Linux](#health-logs-logrotate)
+ [Erweitern der Standardkonfiguration für Protokollaufgaben](#health-logs-extend)
+ [Protokolldateien nach Amazon CloudWatch Logs streamen](#health-logs-cloudwatchlogs)
## Speicherort der Protokolle auf Amazon EC2-Instances
Protokolle werden an Standardspeicherorten auf den Amazon EC2-Instances Ihrer Umgebung gespeichert. Elastic Beanstalk erzeugt die folgenden Protokolle.
**Amazon Linux 2**
+ `/var/log/eb-engine.log`
**Amazon Linux-AMI (AL1)**
**Anmerkung**
[Am 18. Juli 2022](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2022-07-18-linux-al1-retire.html) **hat Elastic Beanstalk den Status aller Plattformbranches, die auf Amazon Linux AMI (AL1) basieren, auf eingestellt gesetzt.** Weitere Informationen zur Migration zu einem aktuellen und vollständig unterstützten Plattformzweig für Amazon Linux 2023 finden Sie unter [Migrieren der Elastic-Beanstalk-Linux-Anwendung zu Amazon Linux 2023 oder Amazon Linux 2](using-features.migration-al.md).
+ `/var/log/eb-activity.log`
+ `/var/log/eb-commandprocessor.log`
**Windows Server**
+ `C:\Program Files\Amazon\ElasticBeanstalk\logs\`
+ `C:\cfn\log\cfn-init.log`
Diese Protokolle enthalten Meldungen über Bereitstellungsaktivitäten, einschließlich solcher über Konfigurationsdateien ([`.ebextensions`](ebextensions.md)).
Jede Anwendung und jeder Webserver speichert Protokolle in einem eigenen Ordner:
+ **Apache** – `/var/log/httpd/`
+ **IIS** – `C:\inetpub\wwwroot\`
+ **Node.js** – `/var/log/nodejs/`
+ **nginx** – `/var/log/nginx/`
+ **Passenger** – `/var/app/support/logs/`
+ **Puma** – `/var/log/puma/`
+ **Python** – `/opt/python/log/`
+ **Tomcat** – `/var/log/tomcat/`
## Speicherort der Protokolle in Amazon S3
Wenn Sie Protokollfragmente oder Bundle-Protokolle aus Ihrer Umgebung anfordern oder wenn Instances rotierte Protokolle hochgeladen haben, werden diese in Ihrem Elastic Beanstalk-Bucket in Amazon S3 gespeichert. Elastic Beanstalk erstellt einen Bucket, der `elasticbeanstalk-region-account-id` nach jeder AWS Region benannt ist, in der Sie Umgebungen erstellen. In diesem Bucket werden Protokolle unter dem Pfad `resources/environments/logs/logtype/environment-id/instance-id` gespeichert.
Beispielsweise werden Logs von der Instanz `i-0a1fd158` in der Elastic Beanstalk Beanstalk-Umgebung unter AWS Region `e-mpcwnwheky` `us-west-2` im Account `123456789012` an den folgenden Orten gespeichert:
+ **Tail Logs** –
`s3://elasticbeanstalk-us-west-2-123456789012/resources/environments/logs/tail/e-mpcwnwheky/i-0a1fd158`
+ **Bundle Logs** –
`s3://elasticbeanstalk-us-west-2-123456789012/resources/environments/logs/bundle/e-mpcwnwheky/i-0a1fd158`
+ **Rotated Logs** –
`s3://elasticbeanstalk-us-west-2-123456789012/resources/environments/logs/publish/e-mpcwnwheky/i-0a1fd158`
**Anmerkung**
Die Umgebungs-ID finden Sie in der Environment Management Console.
Elastic Beanstalk löscht Tail- und Bundle-Protokolle von Amazon S3 automatisch 15 Minuten nach ihrer Erstellung. Rotierte Protokolle bleiben bestehen, bis Sie sie löschen oder nach Amazon Glacier verschieben.
## Protokollrotations-Einstellungen auf Linux
Auf Linux-Plattformen verwendet Elastic Beanstalk `logrotate`, um Protokolle periodisch zu rotieren. Nach der lokalen Rotation des Protokolls erfasst es die Protokollrotationsaufgabe und lädt es in Amazon S3 hoch (sofern dies konfiguriert ist). Lokal rotierte Protokolle werden standardmäßig nicht in Protokollfragmente oder Bundle-Protokolle aufgenommen.
Elastic Beanstalk-Konfigurationsdateien für `logrotate` finden Sie unter `/etc/logrotate.elasticbeanstalk.hourly/`. Diese Rotationseinstellungen sind plattformspezifisch und können sich in späteren Versionen der Plattform ändern. Führen Sie `man logrotate` aus, um weitere Informationen zu den verfügbaren Einstellungen sowie Beispielkonfigurationen zu erhalten.
Die Konfigurationsdateien werden von Cron-Aufträgen in `/etc/cron.hourly/` aufgerufen. Führen Sie zum Erhalten weiterer Informationen zu `cron` `man cron` aus.
## Erweitern der Standardkonfiguration für Protokollaufgaben
In Elastic Beanstalk werden Dateien in den Unterordnern von `/opt/elasticbeanstalk/tasks` (Linux) oder `C:\Program Files\Amazon\ElasticBeanstalk\config` (Windows Server) auf der Amazon EC2-Instance verwendet, um Aufgaben für Protokollfragmente, Bundle-Protokolle und Protokollrotation zu konfigurieren.
**Auf Amazon Linux:**
+ **Tail Logs** –
`/opt/elasticbeanstalk/tasks/taillogs.d/`
+ **Bundle Logs** –
`/opt/elasticbeanstalk/tasks/bundlelogs.d/`
+ **Rotated Logs** –
`/opt/elasticbeanstalk/tasks/publishlogs.d/`
**Auf Windows Server:**
+ **Tail Logs** –
`c:\Program Files\Amazon\ElasticBeanstalk\config\taillogs.d\`
+ **Bundle Logs** –
`c:\Program Files\Amazon\ElasticBeanstalk\config\bundlelogs.d\`
+ **Rotated Logs** –
`c:\Program Files\Amazon\ElasticBeanstalk\config\publogs.d\`
Beispielsweise werden mit der Datei `eb-activity.conf` auf Linux zwei Protokolldateien zur Protokollfragmentaufgabe hinzugefügt:
**`/opt/elasticbeanstalk/tasks/taillogs.d/eb-activity.conf `**
```
/var/log/eb-commandprocessor.log
/var/log/eb-activity.log
```
Sie können Umgebungskonfigurationsdateien (`[.ebextensions](ebextensions.md)`) verwenden, um Ihre eigenen `.conf`-Dateien diesen Ordnern hinzuzufügen. Eine `.conf`-Datei listet für Ihre Anwendung spezifische Protokolldateien auf, die Elastic Beanstalk zu den Protokolldateiaufgaben hinzufügt.
Verwenden Sie den Abschnitt `files`, um Konfigurationsdateien zu den Aufgaben hinzuzufügen, die geändert werden sollen. Der folgende Konfigurationstext fügt beispielsweise eine Protokollkonfigurationsdatei zu den einzelnen Instances Ihrer Umgebung hinzu. Die Protokollkonfigurationsdatei `cloud-init.conf` fügt `/var/log/cloud-init.log` zu Protokollfragmenten hinzu.
```
files:
"/opt/elasticbeanstalk/tasks/taillogs.d/cloud-init.conf" :
mode: "000755"
owner: root
group: root
content: |
/var/log/cloud-init.log
```
Fügen Sie diesen Text zu einer Datei mit der Dateinamenerweiterung `.config` zu Ihrem Quell-Bundle in einen Ordner namens `.ebextensions` hinzu.
```
~/workspace/my-app
|-- .ebextensions
| `-- tail-logs.config
|-- index.php
`-- styles.css
```
Auf Linux-Plattformen können Sie bei der Konfiguration von Protokollaufgaben auch Platzhalterzeichen einsetzen. Mithilfe dieser Konfigurationsdatei werden alle Dateien mit der Erweiterung `.log`, die sich im Ordner `log` des Anwendungsstamms befinden, zu Bundle-Protokollen hinzugefügt.
```
files:
"/opt/elasticbeanstalk/tasks/bundlelogs.d/applogs.conf" :
mode: "000755"
owner: root
group: root
content: |
/var/app/current/log/*.log
```
Konfiguration von Protokollaufgaben unterstützen keine Platzhalterzeichen auf Windows-Plattformen.
**Anmerkung**
Wenn Sie sich mit den Verfahren zur Anpassung von Protokollen vertraut machen möchten, können Sie mithilfe der [EB-CLI](eb-cli3.md) eine Beispielanwendung bereitstellen. Dazu erstellt die EB-CLI ein lokales Anwendungsverzeichnis, in dem `.ebextentions`-Unterverzeichnis mit einer Beispielkonfiguration enthalten ist. Sie können die Protokolldateien der Beispielanwendung auch dazu verwenden, die in diesem Thema beschriebene Protokollabruffunktion zu untersuchen.
Weitere Informationen zur Verwendung von Konfigurationsdateien finden Sie unter [Erweiterte Umgebungsanpassung mit Konfigurationsdateien (`.ebextensions`)](ebextensions.md).
So wie Sie Protokollfragmente und Bundle-Protokolle erweitern können, so können Sie auch Protokollrotation mit einer Konfigurationsdatei erweitern. Jedes Mal, wenn Elastic Beanstalk seine eigenen Protokolle rotiert und auf Amazon S3 hochlädt, rotiert es auch Ihre zusätzlichen Protokolle und lädt sie hoch. Die Protokollrotation-Erweiterung verhält sich abhängig vom Betriebssystem der Plattform anders. In den folgenden Abschnitten werden diese beiden Fälle beschrieben.
### Erweitern der Protokollrotation auf Linux
Wie in [Protokollrotations-Einstellungen auf Linux](#health-logs-logrotate) erläutert, verwendet Elastic Beanstalk `logrotate` zum Rotieren von Protokollen auf Linux-Plattformen. Wenn Sie die Protokolldateien Ihrer Anwendung für Protokollrotation konfigurieren, muss die Anwendung keine Kopien von Protokolldateien erstellen. Elastic Beanstalk konfiguriert `logrotate` so, dass bei jeder Rotation eine Kopie der Protokolldateien Ihrer Anwendung erstellt wird. Aus diesem Grund muss die Anwendung die Protokolldateien entsperrt halten, wenn sie nicht aktiv in sie schreibt.
### Ausdehnen der Protokollrotation auf Windows Server
Auf Windows Server muss die Anwendung die Protokolldateien regelmäßig rotieren, wenn Sie Ihre Anwendung für Protokollrotation konfigurieren. Elastic Beanstalk sucht nach Dateien mit Namen, die mit dem von Ihnen konfigurierten Muster beginnen, und markiert sie zum Hochladen in Amazon S3. Darüber hinaus werden Punkte im Dateinamen ignoriert und Elastic Beanstalk betrachtet den Namen bis zum Punkt als Basis-Protokolldateinamen.
Elastic Beanstalk lädt alle Versionen einer Basis-Protokolldatei hoch, mit Ausnahme der neuesten, da es diese als aktive Protokolldatei der Anwendung betrachtet, die möglicherweise gesperrt sein kann. Ihre Anwendung kann daher die aktive Protokolldatei zwischen Rotationen gesperrt halten.
Beispiel: Ihre Anwendung schreibt in eine Protokolldatei mit dem Namen `my_log.log` und Sie geben diesen Namen in der `.conf`-Datei an. Die Anwendung rotiert die Datei in regelmäßigen Abständen. Während des Elastic Beanstalk-Rotationszyklus findet die Anwendung die folgenden Dateien im Ordner der Protokolldatei: `my_log.log`, `my_log.0800.log` und `my_log.0830.log`. Elastic Beanstalk betrachtet sie alle als Versionen des gleichen Basisnamens `my_log`. Die Datei `my_log.log` hat die neueste Änderungszeit, daher lädt Elastic Beanstalk nur die beiden anderen Dateien, `my_log.0800.log` und `my_log.0830.log`, hoch.
## Protokolldateien nach Amazon CloudWatch Logs streamen
Sie können Ihre Umgebung in der Elastic Beanstalk Beanstalk-Konsole oder mithilfe von [Konfigurationsoptionen](command-options.md) so konfigurieren, dass CloudWatch Logs zu Amazon Logs gestreamt werden. Mit CloudWatch Logs streamt jede Instance in Ihrer Umgebung Logs in Protokollgruppen, die Sie so konfigurieren können, dass sie für Wochen oder Jahre aufbewahrt werden, auch wenn Ihre Umgebung beendet wurde.
Die gestreamten Protokollsätze sind je nach Umgebung unterschiedlich, enthalten aber immer das Protokoll `eb-engine.log` sowie die Zugriffsprotokolle des nginx- oder Apache-Proxy-Servers, der vor der Anwendung ausgeführt wird.
Sie können das Protokoll-Streamen in der Elastic Beanstalk-Konsole entweder beim [Erstellen der Umgebung](environments-create-wizard.md#environments-create-wizard-software) oder [für eine vorhandene Umgebung](environments-cfg-logging.md#environments-cfg-logging-console) konfigurieren. Sie können die folgenden Optionen von der Konsole aus festlegen: Log-Streaming in CloudWatch Logs aktivieren/deaktivieren, die Anzahl der Aufbewahrungstage festlegen und aus Lifecyle-Optionen wählen. Im folgenden Beispiel werden Protokolle auch dann für sieben Tage gespeichert, wenn die Umgebung beendet wird.
![\[Bildschirmbild der CloudWatch Logs-Einstellungen in der Elastic Beanstalk Beanstalk-Konsole.\]](http://docs.aws.amazon.com/de_de/elasticbeanstalk/latest/dg/images/log-streaming-screen.png)
Mit der folgenden [Konfigurationsdatei](ebextensions.md) wird das Protokoll-Streaming aktiviert und die Protokolle bleiben 180 Tage erhalten, auch bei beendeter Umgebung.
**Example .ebextensions/log-streaming.config**
```
option_settings:
aws:elasticbeanstalk:cloudwatch:logs:
StreamLogs: true
DeleteOnTerminate: false
RetentionInDays: 180
```
# Bereitstellungsprotokolle für eine Elastic Beanstalk Beanstalk-Umgebung anzeigen
Elastic Beanstalk generiert für jedes Deployment in Ihrer Umgebung ein Deployment-Log. Das Deployment-Log bietet eine konsolidierte, chronologische Ansicht dessen, was während einer Bereitstellung passiert ist, einschließlich der Installation von Abhängigkeiten, der Build-Ausgabe, des Anwendungsstarts und aller aufgetretenen Fehler. Mithilfe von Bereitstellungsprotokollen können Sie fehlgeschlagene Bereitstellungen schnell diagnostizieren, ohne dass Sie per SSH auf Instanzen zugreifen oder mehrere Protokolldateien korrelieren müssen.
Bereitstellungsprotokolle werden lokal in jede Instanz geschrieben. Bei Bereitstellungen, die über die Konsole, CLI, API oder verwaltete Updates ausgelöst werden, lädt eine Instance ihr Protokoll während der Bereitstellung kontinuierlich auf Amazon S3 hoch. Die Elastic Beanstalk Beanstalk-Konsole liest das Protokoll von Amazon S3, sodass Sie den Fortschritt überwachen können, ohne eine Verbindung zur Instance herstellen zu müssen.
Die Bereitstellungsprotokolle sind so konzipiert, dass sie präzise sind. Bei Erfolg zeigt das Protokoll nur zusammenfassende Meldungen an (z. B. welche Befehle ausgeführt und abgeschlossen wurden). Bei einem Fehler enthält das Protokoll bis zu 50 Zeilen mit der Ausgabe des fehlgeschlagenen Schritts, sodass Sie den Fehler erkennen können, ohne die ausführliche Ausgabe durchsuchen zu müssen.
**Anmerkung**
Bereitstellungsprotokolle sind auf den Plattformversionen [Amazon Linux 2](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2026-03-11-al2.html) und [Amazon Linux 2023](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2026-03-11-al2023.html) verfügbar, die am oder nach dem 11. März 2026 veröffentlicht wurden. Windows-Plattformen werden derzeit nicht unterstützt.
## Unterstützte Vorgänge
Deployment-Logs werden für die folgenden Operationen generiert:
+ **Anwendungsbereitstellungen** — Bereitstellung einer neuen Anwendungsversion in Ihrer Umgebung.
+ **Konfigurationsupdates** — Änderung der Umgebungskonfigurationseinstellungen, für die Instanzupdates erforderlich sind.
+ **Erstellung einer Umgebung** — Die erste Bereitstellung, wenn Sie eine neue Umgebung erstellen.
+ **App-Server neu starten** — Starten Sie den Anwendungsserver auf Ihren Instanzen neu.
Bei Vorgängen, die den Anwendungs- oder Konfigurationsstatus auf Instanzen nicht ändern, wie z. B. das Anfordern von Protokollen, das Austauschen CNAMEs oder Aktualisieren von Tags, werden keine Bereitstellungsprotokolle generiert.
## Inhalt des Bereitstellungsprotokolls
Ein Bereitstellungsprotokoll erfasst die folgenden Informationen während einer Bereitstellung:
+ **Bereitstellungslebenszyklus** — Start- und Abschlussnachrichten für jede Bereitstellungsphase, z. B. `Starting Application deployment` und`Completed Application deployment`.
+ **.ebextensions-Ausgabe** — Bei Erfolg die Namen der Befehle, die ausgeführt wurden. Bei einem Fehler die letzten 50 Zeilen der `cfn-init` Ausgabe, um das Problem zu diagnostizieren.
+ **Plattform-Hooks-Ausgabe** — Bei Erfolg die Namen der Hook-Skripte, die ausgeführt wurden. Bei einem Fehler werden die letzten 50 Zeilen der Hook-Ausgabe ausgegeben.
+ **Installation von Abhängigkeiten** — Ausgabe von Paketmanagern wie **npm install****pip install**,**composer install**, und**bundle install**. Bei erfolgreicher Ausführung wird nur eine Abschlussmeldung protokolliert. Bei einem Fehler sind die letzten 50 Ausgabezeilen enthalten.
+ **Build-Ausgabe** — Ausgabe von Build-Befehlen wie **docker build****go build**, und Java-Builds. Bei einem Fehler sind die letzten 50 Ausgabezeilen enthalten.
+ **Ausgabe beim Start der Anwendung** — Erste Ausgabe Ihrer Anwendung nach dem Start. Die Quelle hängt von Ihrer Plattform ab:
+ *Docker* — Container-Logs von oder **docker logs** **docker compose logs**
+ *Java SE, Go, Node.js, Python, Ruby, .NET* — Standardprotokolle verarbeiten
+ *Tomcat — Catalina-Protokollausgabe*
+ *PHP — PHP-FPM-Master* - und Pool-Fehlerprotokolle
+ *ECS* — Container-Protokolle aus jedem Task-Container
**Anmerkung**
Die Anwendungsausgabe wird ab 2 Sekunden nach dem Start der Anwendung erfasst. Es sind nur die ersten Startmeldungen enthalten. Wenn die Ausgabe Ihrer Anwendung länger dauert, werden sie nicht im Bereitstellungsprotokoll angezeigt. Um die vollständigen Anwendungsprotokolle einzusehen, fordern Sie Bundle-Logs an oder stellen Sie eine direkte Verbindung mit der Instance her. Weitere Informationen finden Sie unter [Anzeigen von Instance-Protokollen](using-features.logging.md).
Wenn ein Bereitstellungsschritt fehlschlägt, wird er im Protokoll mit `[ERROR]` bis zu 50 Zeilen mit der Ausgabe des fehlgeschlagenen Schritts gekennzeichnet. Wenn das Bereitstellungsprotokoll nicht genügend Details enthält, können Sie die vollständigen Instanzprotokolle (einschließlich `eb-engine.log``eb-hooks.log`, und Anwendungsprotokolle) auf der Registerkarte **Protokolle** abrufen. Weitere Informationen finden Sie unter [Protokolle von Amazon EC2-Instances in Ihrer Elastic Beanstalk Umgebung anzeigen](using-features.logging.md).
## Bereitstellungsprotokolle in der Konsole anzeigen
Die Elastic Beanstalk Beanstalk-Konsole bietet im Umgebungs-Dashboard einen Tab „**Deployments**“, auf dem Sie Ihren Bereitstellungsverlauf und Ihre Logs einsehen können.
### Bereitstellungsverlauf anzeigen
**Um den Bereitstellungsverlauf einzusehen**
1. Öffnen Sie die [Elastic Beanstalk Beanstalk-Konsole](https://console.aws.amazon.com/elasticbeanstalk) und wählen Sie in der Liste **Regionen** Ihre aus. AWS-Region
1. Wählen Sie im Navigationsbereich **Environments (Umgebungen)** aus und wählen Sie dann in der Liste den Namen Ihrer Umgebung aus.
1. Wählen Sie im Umgebungs-Dashboard den Tab **Deployments** aus.
Auf der Registerkarte Bereitstellungen wird eine Tabelle mit Bereitstellungen für die Umgebung angezeigt. Jede Zeile enthält die folgenden Informationen:
+ **Anforderungs-ID** — Die eindeutige Kennung für die Bereitstellung.
+ **Status** — *Erfolgreich*, *Fehlgeschlagen* oder *In Bearbeitung*.
+ **Typ** — Der Bereitstellungstyp, z. B. *Umgebungserstellung*, *Anwendungsbereitstellung*, *Konfigurationsupdate*, *verwaltetes Plattform-Update*, *App Server neu starten*, *Umgebung neu aufbauen*, *Umgebung wiederherstellen*, *Umgebungsdomäne austauschen* oder *Umgebung beenden*.
+ **Startzeit** — Wann die Bereitstellung begann.
+ **Dauer** — Wie lange es gedauert hat, bis die Bereitstellung abgeschlossen war.
Wenn eine Bereitstellung im Gange ist, fragt die Registerkarte automatisch nach Updates ab. Sie können auch die Schaltfläche „Aktualisieren“ wählen, um die Liste manuell neu zu laden.
### Bereitstellungsdetails und -protokolle anzeigen
**Um Bereitstellungsdetails anzuzeigen**
1. Wählen Sie auf der Registerkarte **Bereitstellungen** den Link **Anforderungs-ID** für die Bereitstellung aus, die Sie überprüfen möchten.
1. Auf der Seite mit den Bereitstellungsdetails wird eine Zusammenfassung mit der Anforderungs-ID, dem Status, dem Bereitstellungstyp, der Startzeit, der Dauer und der Bereitstellungsrichtlinie angezeigt. Die Bereitstellungsrichtlinie (z. B. „*Alles auf einmal*“, „Rollend“, „*Rollend*“ *mit zusätzlichem Batch*, „*Unveränderlich*“ oder „*Traffic Splitting*“) wird angezeigt, wenn sie anhand der Bereitstellungsereignisse ermittelt werden kann.
1. Wählen Sie unter der Zusammenfassung eine der folgenden Registerkarten aus:
+ **Ereignisse** — Eine Zeitleiste mit Ereignissen im Zusammenhang mit dieser Bereitstellung, die so gefiltert wurde, dass nur Ereignisse für die ausgewählte Bereitstellung angezeigt werden.
+ **Bereitstellungsprotokolle** — Das konsolidierte Bereitstellungsprotokoll der Instance. Sie können die Protokolldatei suchen, nach Protokollebene filtern und herunterladen.
Bei laufenden Bereitstellungen wird die Registerkarte „Protokolle“ automatisch aktualisiert, sodass neue Protokolleinträge angezeigt werden, während sie geschrieben werden. Nach Abschluss einer Bereitstellung ruft die Konsole den endgültigen Protokollstatus ab, um sicherzustellen, dass Sie die vollständige Ausgabe sehen.
**Wichtig**
Für das Anzeigen von Bereitstellungsprotokollen in der Konsole ist eine `s3:GetObject` Genehmigung für den Amazon S3 S3-Speicher-Bucket der Umgebung erforderlich (`elasticbeanstalk-region-account-id`). Wenn Ihre IAM-Richtlinie diese Berechtigung nicht beinhaltet, sind der Bereitstellungsverlauf und die Ereignisse weiterhin verfügbar, aber auf der Registerkarte „Protokolle“ wird ein Fehler angezeigt.
## Bereitstellungsprotokolldateien auf Instanzen
Bereitstellungsprotokolle werden in das `/var/log/deployments/` Verzeichnis jeder Instance geschrieben. Der Protokolldateiname hängt davon ab, wie die Bereitstellung ausgelöst wurde:
+ **Workflow-gesteuerte Bereitstellungen** (ausgelöst über die Konsole, CLI oder API) —`eb-deployment-request-id.log`, wo *request-id* ist die eindeutige Bereitstellungsanforderungs-ID.
+ **Selbststartende Bereitstellungen** (Instanzstart oder Neustart des App-Servers) —. `eb-deployment-unix-timestamp.log`
Elastic Beanstalk rotiert diese Dateien automatisch und behält die 50 neuesten Deployment-Logs für jede Instance bei.
Für Workflow-gesteuerte Bereitstellungen wird das Protokoll unter dem folgenden Pfad in Amazon S3 hochgeladen:
```
s3://elasticbeanstalk-region-account-id/resources/environments/logs/deployments/environment-id/log-filename
```
In Umgebungen mit mehreren Instanzen beansprucht die erste Instance, die mit dem Hochladen beginnt, die Rolle für die gesamte Bereitstellung. Diese Instance lädt ihr Protokoll für die Dauer der Bereitstellung auf Amazon S3 hoch. Alle Instances schreiben weiterhin Bereitstellungsprotokolle lokal.
**Wichtig**
Für das Hochladen von Bereitstellungsprotokollen auf Amazon S3 ist eine `s3:PutObject` Genehmigung für den Amazon S3-Speicher-Bucket der Umgebung im Instance-Profil erforderlich, und die VPC-Konfiguration muss die Konnektivität zu Amazon S3 zulassen.
Das Hochladen von Bereitstellungsprotokollen ist auf 1 MB pro Datei begrenzt. Wenn ein Bereitstellungsprotokoll diese Größe überschreitet, wird die hochgeladene Version gekürzt und es wird eine Meldung angezeigt, dass das vollständige Protokoll auf der Instanz verfügbar ist.
### S3-Protokoll-Uploads deaktivieren
Um zu verhindern, dass Bereitstellungsprotokolle auf Amazon S3 hochgeladen werden, legen Sie die folgende Umgebungseigenschaft für Ihre Umgebung fest:
```
option_settings:
- namespace: aws:elasticbeanstalk:application:environment
option_name: EB_DEPLOYMENT_LOG_S3_DISABLED
value: true
```
Wenn diese Umgebungseigenschaft festgelegt ist, werden Bereitstellungsprotokolle weiterhin lokal `/var/log/deployments/` auf jeder Instance geschrieben, aber sie werden nicht auf Amazon S3 hochgeladen und sind nicht auf der Registerkarte **Deployments** in der Konsole verfügbar. Sie können diese Eigenschaft auch auf der **Konfigurationsseite** unter **Software** oder mithilfe der EB-CLI oder festlegen AWS CLI.