Erweiterte Zustandsberichte und Überwachung - AWS Elastic Beanstalk

Erweiterte Zustandsberichte und Überwachung

Erweiterte Zustandsberichte ist eine Funktion, die Sie auf Ihrer Umgebung aktivieren können, damit AWS Elastic Beanstalk weitere Informationen über Ressourcen in Ihrer Umgebung erfassen kann. 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 anzuzeigen.


      Die Übersichtsseite zur Elastic-Beanstalk-Umgebung der Elastic-Beanstalk-Konsole, auf der ein erweiterter Integritätsstatus angezeigt wird

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 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, 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 in der Elastic-Beanstalk-Konsole oder mit dem Befehl eb health in der Elastic-Beanstalk-Befehlszeilenschnittstelle (EB-CLI) anzeigen. Zum Erfassen und Verfolgen der Umgebungs- und Instance-Integrität im Laufe der Zeit können Sie Ihre Umgebung so konfigurieren, dass die von Elastic Beanstalk erfassten Informationen für erweiterte Integritätsberichte in Amazon-CloudWatch als benutzerdefinierte Metriken veröffentlicht werden. CloudWatch-Gebühren für benutzerdefinierte Metriken gelten für alle Metriken mit Ausnahme von EnvironmentHealth, was kostenlos ist.

Erweiterte Zustandsberichte erfordern Version 2 oder eine neuere Plattformversion. Zum Überwachen von Ressourcen und Veröffentlichen von Metriken benötigt Ihre Umgebung sowohl ein Instance-Profil als auch eine Service-Rolle. Die Multicontainer-Docker-Plattform umfasst standardmäßig keinen Webserver, kann jedoch mit erweiterten Zustandsberichten verwendet werden, wenn Sie Ihren Webserver so konfigurieren, dass Protokolle im richtigen Format bereitgestellt werden.

Hinweise zur Windows-Plattform
  • Diese Funktion steht bei Windows Server-Plattformversionen vor Version 2 (v2) nicht zur Verfügung.

  • Wenn Sie erweiterte Zustandsberichte für eine Windows Server-Umgebung aktivieren, ändern Sie nicht die IIS-Protokollierungskonfiguration. 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 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.

Für den verbesserten Zustand muss die Umgebung über ein Instance-Profil verfügen. Das Instance-Profil sollte über Rollen verfügen, die Ihren Umgebungs-Instances Berechtigungen zum Sammeln und Berichten von erweiterten Integritätsinformationen bereitstellen. Wenn Sie erstmals eine Umgebung mit einer v2-Plattformversion in der Elastic Beanstalk-Konsole erstellen, fordert Elastic Beanstalk Sie auf, die erforderlichen Rollen zu erstellen, und aktiviert standardmäßig die erweiterten Integritätsberichte. Lesen Sie Details darüber, wie die erweiterten Integritätsberichte funktionieren, oder besuchen Sie Aktivieren der erweiterten Elastic-Beanstalk-Integritätsberichte, um die Funktion sofort zu verwenden.

Amazon-Linux-2-Plattformen benötigen Instance-Profile, sodass sie immer eine erweiterte Integrität unterstützen können. Wenn Sie eine Umgebung mit einer Amazon-Linux-2-Plattform erstellen, aktiviert Elastic Beanstalk immer die erweiterte Integrität. Dies gilt unabhängig davon, wie Sie die Umgebung erstellen – mit der Elastic-Beanstalk-Konsole, der EB-CLI, der AWS CLI oder der API.

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 Integritäts-Agent meldet ähnliche Metriken wie die, die von Amazon-EC2-Auto-Scaling und Elastic-Load-Balancing in CloudWatch veröffentlicht werden, als Teil der grundlegenden Integritätsberichte, einschließlich CPU-Auslastung, HTTP-Codes und Latenz. 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, um die Gesamtintegrität der Umgebung zu bestimmen.

Die Gesamtintegrität der Umgebung kann auf der Umgebungsübersichtsseite der Elastic-Beanstalk-Konsole in Echtzeit angezeigt werden und wird von Elastic Beanstalk alle 60 Sekunden in CloudWatch veröffentlicht. Sie können detaillierte Metriken, die vom Zustandsagenten in Echtzeit gemeldet werden, mit dem eb health-Befehl in der EB-CLI anzeigen.

Gegen eine zusätzliche Gebühr können Sie einzelne Metriken auf Instance- und Umgebungsebene alle 60 Sekunden in CloudWatch veröffentlichen. In CloudWatch veröffentlichte Metriken können dann verwendet werden, um Überwachungsdiagramme in der Environment Management Console zu erstellen.

Für erweiterte Integritätsberichte fällt nur dann eine Gebühr an, wenn Sie erweiterte Integritätsmetriken 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 finden Sie Details zu Metriken, die vom Zustandsagenten veröffentlicht werden. Weitere Informationen zum Veröffentlichen erweiterter Integritätsmetriken in CloudWatch finden Sie unter Veröffentlichen von benutzerdefinierten Amazon-CloudWatch-Metriken für eine Umgebung.

Faktoren bei der Bestimmung des Instance- und Umgebungszustands

Zusätzlich zu den grundlegenden Systemprüfungen der Integritätsberichte, einschließlich Elastic Load Balancing-Zustandsprüfungen und Ressourcenüberwachung, 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 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 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-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-Namespace) festgelegt. Wenn alle Instances im Stapel innerhalb des Befehls-Timeout 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-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.

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 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.

Betriebssystemmetriken

Elastic Beanstalk überwacht Betriebssystemmetriken, die vom Integritäts-Agenten gemeldet wurden, um Instances zu identifizieren, die konsequent geringe Systemressourcen haben.

Unter Instance-Metriken 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.

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 Servicerolle ermöglicht Elastic Beanstalk die Interaktion mit anderen AWSServices in Ihrem Auftrag, 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 AWS CLI zum Erstellen von Umgebungen verwenden, müssen Sie diese Rollen im Vorfeld erstellen und während der Umgebungserstellung angeben, um erweiterte Zustandsberichte zu verwenden. Anweisungen zum Erstellen geeigneter Rollen für Ihre Umgebungen finden Sie unter Servicerollen, Instance-Profile und Benutzerrichtlinien.

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 von Elastic Beanstalk verwaltet werden. 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 oder auf Worker-Ebene handelt. Ausführliche Informationen zu diesen beiden Richtlinien für verwaltete Instance-Profile finden Sie unter Elastic Beanstalk Instance-Profile verwalten.

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 dieelasticbeanstalk: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 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 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-Namespace auf true ein. Sie können diese Option mithilfe einer Optionseinstellung in einer Konfigurationsdatei 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

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 der Elastic-Beanstalk-Konsole und in der EB-CLI verfügbar. Indem Sie die EB-CLI an Ihre Umgebung anfügen und den eb health-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 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 und fortlaufende Bereitstellungen.

Erweiterte Integritätsberichte können auch die Notwendigkeit, eine ordnungsgemäße Integritätsprüfungs-URL 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.