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.
Verwenden von CloudWatch Metriken mit Lambda-Webfunktionen
AWS Lambda veröffentlicht Web Function-Metriken CloudWatch in zwei Namespaces auf Amazon:
-
AWS/Lambda/Web— Anforderungs- und Antwortmetriken für jeden Endpunkt sowie Kennzahlen zur Ressourcennutzung für die Ausführungsumgebungen, die jede Webfunktion bedienen. Lambda zentralisiert diese Metriken in der Heimatregion der Webfunktion, sodass die Werte in der Heimatregion den Verkehr aus allen Regionen enthalten, die der Endpunkt bedient. -
AWS/Lambda/Web/Usage— Metriken zur regionalen Nutzung und Drosselung, die den Verbrauch anhand regionaler Kontingente und Endpunktgrenzwerte aufzeigen. Diese Kennzahlen sind nicht zentralisiert. Sie verbleiben in der Region, in der die Anfrage zugestellt wurde.
Lambda veröffentlicht Anforderungs-, Nutzungs- und Drosselungsmetriken nur, wenn eine Anfrage einen Wert für sie generiert. Die Metriken der Ausführungsumgebung sind unterschiedlich: Lambda veröffentlicht sie jede Minute für jede aktive Ausführungsumgebung. Einige Metriken sind spärlich: Lambda veröffentlicht keinen Datenpunkt von 0 für einen Zeitraum, in dem das Ereignis nicht eingetreten ist. Wenn beispielsweise keine Anfrage in einem Zeitraum eine 5xx-Antwort zurückgibt, HTTPResponseStatusClass5XX gibt es keinen Datenpunkt für diesen Zeitraum. In den folgenden Tabellen wird beschrieben, wann Lambda die einzelnen Metriken ausgibt. Wenn Sie Alarme für spärliche Metriken erstellen, konfigurieren Sie, wie der Alarm mit fehlenden Daten umgeht. Weitere Informationen finden Sie unter Konfiguration der Behandlung fehlender Daten durch CloudWatch Alarme im CloudWatch Amazon-Benutzerhandbuch.
Themen
Anforderungsmetriken
Anforderungsmetriken werden im AWS/Lambda/Web Namespace mit den EndpointName Dimensionen FunctionName und veröffentlicht. Sie verwenden das Count Gerät. Benutze die Sum Statistik.
| Metrik | Statistik | Wenn Lambda es aussendet | Description |
|---|---|---|---|
ExecutedRequests |
Sum |
Nur für Zeiträume, in denen mindestens eine Anfrage eine Ausführungsumgebung erreicht hat. | Die Anzahl der Anfragen, die eine Ausführungsumgebung erreicht haben. Anfragen, die Lambda drosselt oder ablehnt, bevor sie eine Ausführungsumgebung erreichen, werden nicht gezählt. |
HTTPResponseStatusClass4XX |
Sum |
Spärlich. Nur für Zeiträume mit mindestens einer 4xx-Antwort. | Die Anzahl der Antworten, die an Anrufer mit einem Statuscode zwischen 400 und 499 zurückgesendet wurden. Die Antwort kann von Ihrer Anwendung oder von Lambda kommen, einschließlich gedrosselter Anfragen, die HTTP 429 empfangen. Anfragen, die Lambda ablehnt, bevor es den Endpunkt identifiziert, wie z. B. falsch formatierte Anfragen, werden nicht gezählt. |
HTTPResponseStatusClass5XX |
Sum |
Spärlich. Nur für Zeiträume mit mindestens einer 5xx-Antwort. | Die Anzahl der Antworten, die an Anrufer mit einem Statuscode zwischen 500 und 599 zurückgesendet wurden. Die Antwort kann von Ihrer Anwendung oder von Lambda kommen. Während einer Serviceunterbrechung kann diese Kennzahl Fehler unterschätzen. |
Bei den Statusklassen-Metriken wird der Statuscode gezählt, den der Anrufer erhalten hat. Sie unterscheiden nicht zwischen Antworten, die von Ihrer Anwendung geschrieben wurden, und Antworten, die von Lambda zurückgegeben wurden. Wenn Ihre Anwendung den Antwortstatus und die Header bereits gesendet hat, wird ein späterer Fehler, z. B. ein unterbrochener Stream oder ein Anforderungs-Timeout, unter dem ursprünglichen Statuscode gezählt. Verwenden Sie den lambda-web-error-type Antwort-Header und Ihre Logs, um die Ursache eines Fehlers zu ermitteln. Um Anwendungsfehler getrennt zu zählen, veröffentlichen Sie Ihre eigenen Messwerte. Weitere Informationen finden Sie unter Veröffentlichen von benutzerdefinierten Metriken mit dem eingebetteten Metrikformat.
Um die Serverfehlerrate zu schätzen, dividieren Sie mit ExecutedRequests Hilfe CloudWatch metrischer Berechnungen HTTPResponseStatusClass5XX durch die Werte für denselben Zeitraum. Verwenden Sie beispielsweiseFILL(m5xx, 0) / m_executed, where m5xx und m_executed are die IDs der beiden Messwerte. Da HTTPResponseStatusClass5XX es dünn gesät ist, verwenden Sie FILL es so, dass Perioden ohne Fehler 0 ergeben, anstatt keinen Wert zu haben. HTTPResponseStatusClass5XXzählt auch 5xx-Antworten, die Lambda zurückgegeben hat, bevor eine Anfrage eine Ausführungsumgebung erreichte. ExecutedRequestszählt diese Antworten nicht, sodass das Verhältnis die Rate während einer Betriebsunterbrechung überbewerten kann.
Anforderungsmetriken in der Heimatregion aggregieren den Verkehr aus allen Regionen, die der Endpunkt bedient, sodass ein Alarm in der Heimatregion den gesamten Endpunkt abdeckt. Erstellen Sie Alarme und Dashboards für die Werte der Heimatregion. Verlassen Sie sich in anderen Regionen nicht auf diese Kennzahlen. Weitere Informationen finden Sie unterTelemetrie in jeder Region.
Lambda gibt Anforderungsmetriken aus, wenn eine Anfrage abgeschlossen ist. Bei einer Anfrage mit langer Laufzeit kann der Datenpunkt bis zum Timeout der Anfrage nach dem Start der Anfrage angezeigt werden, sodass Fehler aufgrund langer Anfragen Ihre Alarme erst spät erreichen können. Informationen zum Zeitlimit für Anfragen finden Sie unter. Anforderungstimeout
Metriken der Ausführungsumgebung
Metriken zur Ausführungsumgebung beschreiben die Ressourcen, die die Ausführungsumgebungen verwenden, die Ihre Webfunktion bedienen. Lambda veröffentlicht sie im AWS/Lambda/Web Namespace mit der FunctionName Dimension und zentralisiert sie in der Heimatregion der Webfunktion.
Lambda gibt diese Metriken einmal pro Minute für jede aktive Ausführungsumgebung aus, sodass sie spärlich sein könnten, wenn es keine aktiven Ausführungsumgebungen gibt. Ein Wert kann 0 sein. Eine Ausführungsumgebung kann mehr als einen Datenpunkt pro Minute veröffentlichen, z. B. wenn sie initialisiert und heruntergefahren wird. Verwenden Sie die SampleCount Statistik also nicht, um aktive Umgebungen zu zählen. Um sie für einen Endpunkt zu zählen, verwenden Sie. EndpointActiveEnvironments
| Metrik | Einheit | Statistik | Description |
|---|---|---|---|
EnvironmentActiveTime |
Milliseconds |
Sum |
Die Uhrzeit, zu der die Ausführungsumgebungen der Funktion aktiv waren, einschließlich der Initialisierung. Jeder Datenpunkt entspricht der aktiven Zeit einer Umgebung seit ihrem vorherigen Datenpunkt. Die Summe über einen Zeitraum entspricht also der gesamten verbrauchten Umgebungszeit. |
EnvironmentCPUTime |
Milliseconds |
Sum |
Die vCPU-Zeit, die die Ausführungsumgebungen der Funktion verbraucht haben, einschließlich der Initialisierung. |
EnvironmentMaxMemoryUsage |
Megabytes |
Maximum |
Der maximale Speicherverbrauch, den eine Ausführungsumgebung in ihrer Lebensdauer bisher genutzt hat. |
EnvironmentConcurrentRequests |
Count |
Maximum |
Die höchste Anzahl von Anfragen, die eine Ausführungsumgebung während des Zeitraums gleichzeitig bearbeitet hat. |
ResponseBytes |
Bytes |
Sum |
Die Anzahl der Antwortbytes, die die Ausführungsumgebungen der Funktion gesendet haben. |
Die Metriken der Ausführungsumgebung enthalten die EndpointName Dimension nicht. Sie decken alle Endpunkte der Webfunktion ab.
Regionale Nutzungs- und Drosselungsmetriken
Nutzungs- und Drosselungsstatistiken zeigen, wie nah Ihr Konto und Ihre Endgeräte an ihren regionalen Grenzwerten sind und welches Limit eine Anfrage gedrosselt hat. Das Kontingent für die Kontoanforderungsrate und das Arm64-vCPU-Kontingent für das Konto gelten jeweils separat AWS-Region, sodass Lambda diese Metriken in jeder Region veröffentlicht und nicht zentralisiert. Um die Nutzung für eine Region zu sehen, sehen Sie sich die Metriken in dieser Region an. Die Kontingente finden Sie unterLambda-Webfunktionen.
Diese Metriken werden im AWS/Lambda/Web/Usage Namespace mit den ExecutionRegion Dimensionen FunctionNameEndpointName, und veröffentlicht. Sie verwenden das Count Gerät.
| Metrik | Statistik | Wenn Lambda es aussendet | Description |
|---|---|---|---|
ExecutedRequests |
Sum |
Nur für Zeiträume, in denen mindestens eine Anfrage eine Ausführungsumgebung in der Region erreicht hat. | Die Anzahl der Anfragen, die eine Ausführungsumgebung in der Region erreicht haben. |
EndpointActiveEnvironments |
Maximum |
Mit Anfragen an den Endpunkt. Der Wert kann 0 sein. Es gibt keine Datenpunkte, und der Endpunkt empfängt keine Anfragen. | Die Anzahl der aktiven Ausführungsumgebungen des Endpunkts in der Region. Vergleichen Sie diesen Wert mitmaxEnvironments. |
AccountRequestThrottles |
Sum |
Spärlich. Nur für Zeiträume mit mindestens einer solchen Drosselung. | Die Anzahl der Anfragen an den Endpunkt, die gedrosselt wurden, weil das Konto seine Quote für die Anforderungsrate in der Region erreicht hat. |
EndpointRequestThrottles |
Sum |
Spärlich. Nur für Zeiträume mit mindestens einer solchen Drosselung. | Die Anzahl der Anfragen, die gedrosselt wurden, weil der Endpunkt sein Limit für die Anforderungsrate () erreicht hat. rateLimit |
AccountActiveVCPUArm64Throttles |
Sum |
Spärlich. Nur für Zeiträume mit mindestens einer solchen Drosselung. | Die Anzahl der Anfragen an den Endpunkt, die gedrosselt wurden, weil ihre Bearbeitung das Arm64-vCPU-Kontingent des Kontos in der Region überschritten hätte. Wie bei den anderen Drosselungsmetriken werden nur die Drosselungen dieses Endpunkts gezählt. Um die Gesamtzahl der Konten zu sehen, summieren Sie sie über die Endpunkte hinweg. |
EndpointActiveEnvironmentThrottles |
Sum |
Spärlich. Nur für Zeiträume mit mindestens einer solchen Drosselung. | Die Anzahl der Anfragen, die gedrosselt wurden, weil ihre Bearbeitung die Endpunkteinstellung überschritten hätte. maxEnvironments |
Lambda ordnet jeder gedrosselten Anfrage ein Limit zu, sodass eine gedrosselte Anfrage höchstens eine Drosselungsmetrik erhöht. Anfragen, die Lambda drosselt, weil zu viele Ausführungsumgebungen gleichzeitig initialisiert werden, geben HTTP 429 mit dem Platform.EndpointConcurrentInitThrottle Fehlertyp zurück, erhöhen jedoch keine Drosselungsmetrik. Gedrosselte Anfragen werden auch im Namespace berücksichtigt. HTTPResponseStatusClass4XX AWS/Lambda/Web
Um einen PerRegion Or-Endpunkt zu überwachen, können Sie sich die Nutzungsmetriken in jeder Region anzeigen lassen MultiRegion oder einen Alarm ausgeben oder sie in einem CloudWatch regionsübergreifenden Dashboard kombinieren.
Metriken mit anderen CloudWatch Funktionen verwenden
Da AWS/Lambda/Web Metriken in der Heimatregion zentralisiert sind, können Sie sie mit den CloudWatch Standardfunktionen in dieser Region verwenden, darunter:
-
Amazon CloudWatch Observability Access Manager — Teilen Sie Web Function-Metriken mit einem zentralen Überwachungskonto, sodass ein Konto viele Anwendungskonten beobachten kann.
-
Dashboards und Alarme — Erstellen Sie Dashboards und Alarme zu den Kennzahlen der Heimatregion, um den gesamten Einsatz in mehreren Regionen abzudecken.
Einen Alarm bei 5xx Antworten einrichten
Erstellen Sie CloudWatch Alarme, um Probleme wie erhöhte Fehlerraten oder Drosselung zu erkennen.
Mit dem folgenden Befehl wird ein Alarm ausgelöst, der ausgelöst wird, wenn Anrufer innerhalb von fünf Minuten mehr als fünf 5xx-Antworten vom Endpunkt erhalten.
aws cloudwatch put-metric-alarm \ --alarm-namemy-web-app-prod-5xx\ --namespace AWS/Lambda/Web \ --metric-name HTTPResponseStatusClass5XX \ --statistic Sum \ --period 300 \ --threshold 5 \ --comparison-operator GreaterThanThreshold \ --evaluation-periods 1 \ --treat-missing-data notBreaching \ --dimensions Name=FunctionName,Value=my-web-appName=EndpointName,Value=prod\ --alarm-actionsarn:aws:sns:us-east-1:111122223333:my-alerts
Ersetzen Sie die folgenden Werte:
-
my-web-app-prod-5xx— Ein Name für den Alarm. -
my-web-app— Der Name Ihrer Webfunktion. -
prod– Der Name des Endpunkts. -
arn:aws:sns:us-east-1:111122223333:my-alerts— Der ARN des Amazon SNS SNS-Themas, das Alarmbenachrichtigungen empfängt.
--treat-missing-data notBreachingist hier wichtig. HTTPResponseStatusClass5XXist eine spärliche Metrik, sodass Perioden ohne 5xx-Antworten keine Datenpunkte ergeben. Ohne diese Einstellung würde der Alarm während dieser Zeiträume in den INSUFFICIENT_DATA Status wechseln.
Anmerkung
Metriken für Web-Funktionen enthalten keine Revisionsdimension. Um einer Revision während einer Canary-Implementierung Fehler zuzuordnen, legen Sie eine Umgebungsvariable fest, die den Build identifiziert, z. B. APP_VERSION in jeder Revision, und nehmen Sie seinen Wert in Ihre strukturierten Logs oder als Dimension in Metriken auf, die Sie mit dem eingebetteten Metrikformat veröffentlichen. Systemprotokollereignisse zeichnen beispielsweise platform.initStart auch auf, wie revisionId die einzelnen Ausführungsumgebungen ausgeführt werden, und der lambda-web-logstream Antwort-Header identifiziert den Protokollstream der Ausführungsumgebung, die eine Anfrage bearbeitet hat. Informationen zum Rollback-Verfahren finden Sie unterWird zurückgesetzt.