Serverless Monitoring für Lambda, Cloud Run und Azure Functions

Was ist Serverless Monitoring?

Serverless Monitoring bezeichnet die Überwachung von Anwendungen, die auf gemanagten Compute-Diensten wie AWS Lambda, Google Cloud Run oder Azure Functions laufen. Dort betreibt und skaliert der Cloud-Anbieter die Infrastruktur für Sie. Statt Hosts und Prozessen überwachen Sie Invocations, Container, die bei Bedarf starten, und die Events, die sie auslösen: HTTP-Requests, Queue-Nachrichten, Datei-Uploads, Zeitpläne und Datenbankänderungen.

Serverless nimmt Ihnen viel Betriebsaufwand ab, aber nicht die Notwendigkeit, zu verstehen, was passiert. Code, Abhängigkeiten, Konfiguration und das Nutzererlebnis bleiben in Ihrer Verantwortung. Und weil es keinen Server gibt, auf dem Sie sich anmelden könnten, ist Telemetrie der einzige Weg, eine langsame oder fehlgeschlagene Invocation nachzuvollziehen.

Warum Serverless Monitoring wichtig ist

Serverless-Architekturen sind stark verteilt und ereignisgesteuert. Eine einzige Nutzeraktion kann ein API-Gateway, mehrere Functions, eine Queue, einen Stream und einen Datenbankschreibvorgang auslösen. Tritt ein Fehler auf, zeigt er sich oft weit entfernt von seiner Ursache, etwa als wachsende Dead-Letter-Queue statt als sichtbare Exception. Ohne Distributed Tracing sind solche asynchronen Ketten kaum nachzuvollziehen.

Hinzu kommen Serverless-spezifische Fehlerbilder. Cold Starts verursachen zusätzliche Latenz, wenn neue Instanzen initialisiert werden. Concurrency-Limits führen unter Last zu Throttling. Timeouts und Speichereinstellungen beeinflussen Performance und Kosten gleichermaßen, denn abgerechnet wird nach Laufzeit und zugewiesenem Speicher. Schon eine kleine Regression in einer häufig aufgerufenen Function kann die Cloud-Rechnung spürbar erhöhen. Monitoring hilft Ihnen, die richtige Balance aus Latenz, Zuverlässigkeit und Kosten zu finden.

Wichtige Serverless-Metriken

• Invocations und Concurrency: Request-Volumen und Anzahl parallel laufender Instanzen im Vergleich zu den konfigurierten Limits.
• Fehler und Throttles: fehlgeschlagene Invocations, Timeouts und wegen Concurrency-Limits abgelehnte Requests.
• Laufzeit: p50-, p95- und p99-Ausführungszeit, die sowohl Latenz als auch Kosten bestimmt.
• Cold Starts: wie häufig neue Instanzen initialisiert werden und wie lange das dauert.
• Speichernutzung: Spitzenverbrauch im Vergleich zur zugewiesenen Größe, um Functions richtig zu dimensionieren.
• Zustand der Trigger: Nachrichtenalter in Queues, Iterator Age bei Streams, Tiefe der Dead-Letter-Queue und Anzahl der Retries.
• Latenz nachgelagerter Dienste: Zeit, die in Datenbanken, APIs und anderen aufgerufenen Services verbracht wird.

So funktioniert Serverless Monitoring mit Obseria

Obseria verbindet sich mit AWS, Azure und Google Cloud und erfasst Metriken und Logs Ihrer Functions agentenlos, als Teil der Abdeckung von über 300 Cloud-Services. Für Traces instrumentieren Sie Ihre Functions mit OpenTelemetry, über SDKs oder Layer, die Sie womöglich bereits nutzen, und senden die Daten per OTLP. Der Trace-Kontext wird über HTTP-Aufrufe, Queues und Event-Trigger weitergegeben, sodass Obseria asynchrone Abläufe zu einer durchgängigen End-to-End-Ansicht zusammenfügt.

Obseria TopoGraph zeigt, wie Functions mit Gateways, Queues, Datenbanken und containerisierten Services verbunden sind. Steigen die Fehlerraten, prüft Obseria Intelligence die zugehörigen Signale, etwa eine neue Function-Version, Throttling bei einer nachgelagerten Datenbank oder einen wachsenden Rückstau in einer Queue, und legt eine Beweiskette für die wahrscheinlichste Ursache vor. Tail-based Sampling behält alle langsamen und fehlerhaften Invocations und reduziert gleichzeitig das Volumen bei Routine-Traffic.

Cold Starts analysieren Sie direkt mit OQL:

fetch spans
| filter faas.coldstart == true
| summarize count(), p95(duration), by:{faas.name, cloud.region}

Da Obseria pro Signal abrechnet und nicht pro Host oder Function, ändern zusätzliche Functions nichts an Ihrer Lizenz. Sie zahlen nur für die Telemetrie, die Sie ingestieren und speichern.

Best Practices für Serverless Monitoring

1. Trace-Kontext überall weitergeben. Stellen Sie sicher, dass der Kontext Queues und Event-Trigger übersteht, sonst bricht der Trace an jedem asynchronen Übergang ab.
2. Cold Starts getrennt messen. Erfassen Sie sie als eigenes Signal, damit sie nicht in der Durchschnittslatenz untergehen.
3. Speicher datenbasiert dimensionieren. Mehr Speicher bedeutet oft mehr CPU und kürzere Laufzeit; prüfen Sie diesen Zusammenhang gegen die Kosten.
4. Dead-Letter-Queues beobachten. Dort sammeln sich stille Fehler.
5. Strukturiert loggen. JSON-Logs mit Request-IDs erleichtern die Verknüpfung von Logs und Traces.
6. Nach Version taggen. Vergleichen Sie Function-Versionen, um Regressionen direkt nach dem Deployment zu erkennen.