AWS Lambda Monitoring
Kombinieren Sie agentenlose CloudWatch-Metriken mit OpenTelemetry Lambda Layern: Obseria zeigt Aufrufe, Cold Starts, Laufzeit, Fehler und Throttles je Funktion sowie Traces über API Gateway, SQS und DynamoDB.
Warum AWS Lambda mit Obseria überwachen
Agentenlos in Minuten
Eine IAM-Rolle mit Lesezugriff genügt, damit Obseria Lambda-Metriken aus CloudWatch für alle Funktionen und Regionen erfasst, ohne Codeänderung.
Cold Starts sichtbar
Init Duration und das Span-Attribut faas.coldstart zeigen, welche Funktionen kalt starten, wie oft und zu welchem Preis.
Traces über Serverless-Flows
OpenTelemetry Lambda Layer verbinden API Gateway, Lambda, SQS, SNS und DynamoDB zu einem durchgängigen Trace.
Serverless-Komponenten, die Obseria überwacht
- Lambda-Funktionen und Versionen. Metriken je Funktion, Alias und Version, inklusive Provisioned Concurrency.
- Event Sources. SQS-, Kinesis-, DynamoDB-Streams- und Kafka-Trigger mit Iterator Age und Batch-Fehlern.
- API Gateway und Function URLs. Request-Latenz sowie 4xx- und 5xx-Fehler, verknüpft mit den zugehörigen Funktionen.
- Step Functions. Ausführungen von State Machines mit fehlgeschlagenen und abgelaufenen Schritten.
- Runtimes über OpenTelemetry Layer. Node.js, Python, Java und weitere Runtimes, instrumentiert über OpenTelemetry Lambda Layer.
- Funktions-Logs. CloudWatch Logs inklusive REPORT-Zeilen mit Laufzeit, abgerechneter Dauer und Speicherverbrauch.
Die AWS Lambda-Kennzahlen, auf die es ankommt
Obseria erfasst diese Werte automatisch und zeigt sie in fertigen Dashboards und Alerts.Nutzung und Nachfrage
Zeigt, wie oft Ihre Funktionen laufen und wie viele gleichzeitig aktiv sind, was Leistung und Kosten bestimmt.
Fehler und Ablehnungen
Zeigt, wie oft Funktionen scheitern oder wegen erreichter Grenzen abgewiesen werden, also Arbeit liegen bleibt.
Tempo und Startverzögerungen
Macht sichtbar, wie lange Funktionen brauchen und wie viel zusätzliche Zeit beim Kaltstart verloren geht.
Rückstand bei der Verarbeitung
Zeigt, ob Funktionen mit eingehenden Datenströmen Schritt halten oder zurückfallen und so nachgelagerte Geschäftsprozesse verzögern.
Alle 8 Metriken im Detail anzeigen
| Metrik | Einheit | Aussage |
|---|---|---|
Invocations | Count | Wie oft eine Funktion lief; Basis für Fehler- und Throttle-Raten. |
Errors | Count | Aufrufe, die mit einem Funktionsfehler wie Exception oder Timeout endeten. |
Throttles | Count | Abgelehnte Requests, weil Concurrency-Limits erreicht waren. |
Duration | Milliseconds | Ausführungszeit je Aufruf; beobachten Sie p95 und p99 im Verhältnis zum Timeout. |
ConcurrentExecutions | Count | Gleichzeitig laufende Instanzen im Vergleich zu Konto- und reservierten Limits. |
IteratorAge | Milliseconds | Alter des letzten Datensatzes einer Stream-Quelle; Wachstum heißt, die Funktion hängt hinterher. |
ProvisionedConcurrencySpilloverInvocations | Count | Aufrufe, die die Provisioned Concurrency überschritten und on demand starteten. |
init_duration | Milliseconds | Lambda-Insights-Metrik für die Initialisierungszeit, die direkten Kosten eines Cold Starts. |
AWS Lambda-Monitoring in wenigen Minuten einrichten
- Schritt 1
AWS-Konto verbinden
Legen Sie eine IAM-Rolle mit Lesezugriff für Obseria an und wählen Sie die Regionen; Lambda-Metriken aus CloudWatch kommen ohne Agent.
- Schritt 2
OpenTelemetry Layer hinzufügen
Hängen Sie den OpenTelemetry Lambda Layer für Ihre Runtime an und setzen Sie AWS_LAMBDA_EXEC_WRAPPER für die Autoinstrumentierung.
- Schritt 3
An Obseria exportieren
Setzen Sie OTEL_SERVICE_NAME, den OTLP-Endpoint von Obseria und Ihr Token, idealerweise über den OpenTelemetry Collector Layer.
# Node.js-Funktion: OpenTelemetry Layer + Collector Layer (ARNs aus den
# opentelemetry-lambda Releases für Region und Architektur)
aws lambda update-function-configuration \
--function-name checkout-handler \
--layers "${OTEL_NODEJS_LAYER_ARN}" "${OTEL_COLLECTOR_LAYER_ARN}" \
--environment "Variables={\
AWS_LAMBDA_EXEC_WRAPPER=/opt/otel-handler,\
OTEL_SERVICE_NAME=checkout-handler,\
OPENTELEMETRY_COLLECTOR_CONFIG_URI=/var/task/collector.yaml,\
OBSERIA_OTLP_ENDPOINT=${OBSERIA_OTLP_ENDPOINT},\
OBSERIA_TOKEN=${OBSERIA_TOKEN}}"
# collector.yaml (im Funktionspaket) exportiert per otlphttp:
# endpoint: ${env:OBSERIA_OTLP_ENDPOINT}
# headers: { Authorization: "Bearer ${env:OBSERIA_TOKEN}" }Sofort einsatzbereit
Dashboards, Alerts und SLOs, die bereitstehen, sobald die ersten Daten ankommen.
- Lambda-Übersicht: Aufrufe, Fehler, Throttles
- Cold-Start-Rate und Init Duration je Funktion
- Alert bei Laufzeit nahe am Timeout
- Alert bei steigendem IteratorAge
- Concurrency im Vergleich zu Kontolimits
AWS Lambda-Monitoring: Darauf kommt es an
Warum AWS Lambda Monitoring einen eigenen Ansatz braucht
AWS Lambda nimmt Ihnen die Server ab, aber nicht die Performance-Probleme. Funktionen starten kalt, stoßen an Concurrency-Limits, laufen in Timeouts oder fallen hinter Stream-Quellen zurück. Ein einzelner Nutzer-Request durchläuft oft API Gateway, mehrere Funktionen, SQS-Queues und DynamoDB. AWS Lambda Monitoring kombiniert deshalb zwei Datenquellen: Plattform-Metriken aus CloudWatch für jede Funktion und Distributed Traces aus dem Funktionscode.
Klassische Host-Agents passen nicht zu einem Modell, in dem Ausführungsumgebungen nur Minuten leben und zwischen Aufrufen eingefroren werden. Serverless Monitoring funktioniert am besten mit agentenloser Metrikerfassung plus schlanker Instrumentierung, die als Lambda Layer ausgeliefert wird. Das OpenTelemetry-Projekt veröffentlicht solche Layer für gängige Runtimes, AWS verteilt sie zusätzlich als AWS Distro for OpenTelemetry.
Die wichtigsten Lambda-Metriken
CloudWatch veröffentlicht im Namespace AWS/Lambda einen Standardsatz an Metriken. Diese sollten Sie zuerst beobachten:
- Invocations, Errors und Throttles: Zusammen ergeben sie Fehler- und Throttle-Raten je Funktion. Throttles bedeuten abgelehnte, nicht nur langsame Requests.
- Duration: Betrachten Sie p95 und p99 statt des Mittelwerts und vergleichen Sie mit dem konfigurierten Timeout. Die Laufzeit bestimmt auch die Kosten.
- ConcurrentExecutions: Zeigt, wie nah Sie am Kontolimit oder an der reservierten Concurrency einer Funktion sind.
- IteratorAge: Bei Kinesis-, DynamoDB-Streams- und Kafka-Quellen bedeutet ein steigender Wert, dass die Funktion nicht mithält.
- Cold Starts: Die REPORT-Logzeile enthält bei kalten Aufrufen die
Init Duration, Lambda Insights stellt sie alsinit_durationbereit, und OpenTelemetry kennzeichnet kalte Aufrufe mit dem Span-Attributfaas.coldstart.
Typische Lambda-Probleme erkennen
Lambda Cold Starts
Ein Cold Start entsteht, wenn Lambda eine neue Ausführungsumgebung anlegt: Code laden, Runtime starten und Initialisierungscode außerhalb des Handlers ausführen. Große Deployment-Pakete, schwergewichtige Frameworks und VPC-Anbindung verstärken den Effekt. Verfolgen Sie den Anteil der Aufrufe mit faas.coldstart=true und deren Init Duration je Funktion und vergleichen Sie die Werte vor und nach dem Aktivieren von Provisioned Concurrency oder SnapStart.
Timeouts
Funktionen nahe am Timeout warten meist auf eine langsame Abhängigkeit. Traces zeigen, welcher nachgelagerte Aufruf die Zeit verbraucht hat. So beheben Sie die Ursache, statt nur den Timeout zu erhöhen.
Throttling und erschöpfte Concurrency
Eine Lastspitze oder eine einzelne laute Funktion kann die gemeinsame Konto-Concurrency aufbrauchen und unbeteiligte Funktionen drosseln. Alarmieren Sie auf Throttles und auf ConcurrentExecutions im Verhältnis zu Ihren Limits.
Poison Messages und Retries
Bei asynchronen und Stream-Aufrufen wird ein fehlerhafter Datensatz wiederholt verarbeitet. Das lässt IteratorAge steigen und kann einen Shard blockieren. Fehler-Spans mit den Attributen der Event Source zeigen, welcher Batch scheitert und warum.
Best Practices für Serverless Monitoring
- Erfassen Sie CloudWatch-Metriken aller Funktionen agentenlos und ergänzen Sie OpenTelemetry Layer für Funktionen auf kritischen Pfaden.
- Nutzen Sie den OpenTelemetry Collector Layer, damit Telemetrie am Ende jedes Aufrufs effizient übertragen wird, statt den Handler zu blockieren.
- Setzen Sie
service.nameje Funktion und kennzeichnen Sie Aliase und Versionen, um Deployments vergleichen zu können. - Alarmieren Sie auf Raten und Perzentile, etwa Fehlerrate und p99-Laufzeit, statt auf absolute Zähler.
- Halten Sie den Initialisierungscode schlank und messen Sie den Einfluss jeder Abhängigkeit auf die Init Duration.
So unterstützt Obseria das AWS Lambda Monitoring
Obseria verbindet sich über eine IAM-Rolle mit Lesezugriff mit Ihren AWS-Konten und erfasst Metriken für Lambda und mehr als 300 Services von AWS, Azure und GCP ohne Agent. Traces aus OpenTelemetry Lambda Layern kommen per OTLP an und werden mit CloudWatch-Metriken und -Logs zusammengeführt. TopoGraph bildet Event Sources, Funktionen und nachgelagerte Services automatisch ab, sodass Sie sehen, welche API von welcher Funktion und Tabelle abhängt. Steigen Fehler oder Throttles, korreliert Obseria Intelligence die Veränderung mit Deployments, Concurrency-Limits oder ausfallenden Abhängigkeiten und präsentiert die Ursache mit einer Beweiskette. Dashboards, Alerts und SLOs für Serverless-Workloads sind inklusive.
Verwandte Integrationen
Passende Funktionen
Serverless Monitoring
Verfolgen Sie jede Invocation über Functions, Queues und APIs hinweg. Obseria zeigt Cold Starts, Fehler, Laufzeit und Kosten Ihrer Serverless-Workloads im Kontext des Gesamtsystems.
Mehr erfahrenDistributed Tracing
Verfolgen Sie jeden Request über Services, Queues und Datenbanken hinweg und finden Sie den langsamen Span oder die fehlerhafte Abhängigkeit in Sekunden.
Mehr erfahrenCloud Monitoring
Überwachen Sie über 300 Cloud-Services agentenlos und sehen Sie, wie sie Ihre Anwendungen beeinflussen. Eine Plattform für Multi-Cloud-Metriken, Logs, Traces und Topologie.
Mehr erfahrenMehr erfahren
Was ist Observability?
Was ist Observability? Wie Metriken, Logs, Traces und Profile Ihre Systeme verständlich machen und was Observability vom Monitoring unterscheidet.
Was ist OpenTelemetry?
Was ist OpenTelemetry? So erzeugen API, SDKs, Collector, OTLP und Semantic Conventions herstellerneutrale Traces, Metriken, Logs und Profile.
Häufige Fragen zum AWS Lambda-Monitoring
Nein. CloudWatch-Metriken werden agentenlos erfasst. Für Traces hängen Sie den OpenTelemetry Lambda Layer an und setzen AWS_LAMBDA_EXEC_WRAPPER; die Autoinstrumentierung läuft bei unterstützten Runtimes ohne Codeänderung.
Über die von Lambda gemeldete Init Duration und das OpenTelemetry-Span-Attribut faas.coldstart. Obseria zeigt Cold-Start-Rate und Init Duration je Funktion und Version.
Er verlängert die Initialisierung etwas und verursacht geringe Kosten je Aufruf. Der Collector Layer hält den Export aus dem kritischen Pfad heraus; messen Sie den Effekt anhand von Init Duration und Duration Ihrer Funktionen.
Die OpenTelemetry Lambda Layer unterstützen Node.js, Python und Java; andere Runtimes können das OpenTelemetry SDK direkt nutzen. CloudWatch-Metriken decken jede Runtime ab.
Eine IAM-Rolle mit Lesezugriff auf CloudWatch-Metriken und Ressourcen-Metadaten. Schreibrechte in Ihrem Konto benötigt Obseria nicht.
Starten Sie heute mit dem AWS Lambda-Monitoring
Binden Sie AWS Lambda in Minuten per OpenTelemetry oder Obseria Agent an. 14 Tage kostenlos.