Serverless Observability: Lambda-Funktionen und Cloud-Run-Dienste sinnvoll überwachen

Serverlose Architekturen haben sich in den letzten Jahren als fester Bestandteil moderner Cloud-Anwendungen etabliert. AWS Lambda, Google Cloud Run, Azure Functions und ähnliche Dienste ermöglichen es Teams, Funktionen ohne dauerhaft laufende Server zu betreiben – die Infrastruktur skaliert automatisch, Betriebskosten entstehen nur bei tatsächlicher Nutzung. Doch diese Vorteile erkaufen Teams mit einer erheblich komplexeren Observability-Situation.

Klassische Monitoring-Ansätze, die auf dauerhaft laufenden Prozessen, persistenten Log-Dateien und stabilen IP-Adressen basieren, greifen bei serverlosen Funktionen schlecht. Wer serverlose Anwendungen produktiv betreibt, braucht ein anderes Mindset und andere Werkzeuge.

Die besonderen Herausforderungen serverloser Observability

Serverlose Funktionen unterscheiden sich in mehreren Punkten grundlegend von klassischen Diensten:

• Kurzlebige Ausführungsumgebungen: Lambda-Funktionen werden für die Dauer eines einzelnen Requests gestartet und anschließend eingefroren oder beendet. Es gibt kein dauerhaftes Prozessmodell, in dem Metriken über Zeit akkumuliert werden könnten.
• Cold Starts: Wenn eine Funktion länger nicht aufgerufen wurde, muss die Laufzeitumgebung neu gestartet werden. Das verursacht Latenz, die in Metriken klar sichtbar sein sollte, aber oft in aggregierten Werten untergeht.
• Verteilte Ausführung: Bei hohem Traffic laufen Dutzende oder Hunderte paralleler Instanzen derselben Funktion. Log-Einträge kommen aus unterschiedlichen Instanzen und müssen einer gemeinsamen Anfrage zugeordnet werden.
• Kein dauerhafter Zustand: In-Memory-Caches, lokale Verbindungspools und ähnliche Techniken sind in serverlosen Umgebungen nur eingeschränkt nutzbar. Das beeinflusst sowohl das Verhalten als auch die Beobachtbarkeit.
• Abhängigkeit von verwalteten Diensten: Serverlose Funktionen kommunizieren intensiv mit S3, DynamoDB, SQS, Pub/Sub und ähnlichen Diensten. Latenzen und Fehler in diesen Abhängigkeiten sind oft die eigentliche Ursache von Problemen in der Funktion.

Logs: Die Basis, aber nicht ausreichend

Cloud-Anbieter stellen für serverlose Funktionen standardmäßig Log-Dienste bereit – CloudWatch Logs für AWS Lambda, Cloud Logging für Google Cloud Run. Diese Basis ist wichtig, aber für ernsthafte Observability nicht ausreichend.

Das zentrale Problem: Logs aus parallelen Instanzen werden zeitlich vermischt. Wenn eine einzelne Anfrage mehrere Log-Einträge aus verschiedenen internen Schritten erzeugt, sind diese Einträge ohne zusätzliche Korrelation nicht als zusammengehörig erkennbar. Structured Logging mit einheitlichen Correlation-IDs – idealerweise einer Trace-ID, die von der auslösenden Anfrage durch die gesamte Funktionskette weitergegeben wird – ist daher keine optionale Ergänzung, sondern Grundvoraussetzung.

Empfehlenswert ist ein strukturiertes Log-Format (JSON), das neben der eigentlichen Nachricht immer auch Funktionsname, Versionsnummer, Instanz-ID, Ausführungsdauer und Trace-ID enthält. Das ermöglicht eine sinnvolle Filterung und Korrelation in zentralen Log-Aggregationslösungen wie OpenSearch, Loki oder Cloud-eigenen Diensten.

Metriken für serverlose Funktionen

Plattform-eigene Metriken wie Invocation Count, Error Rate, Duration und Throttles sind ein guter Startpunkt. Sie liefern aber keinen Einblick in anwendungsspezifische Aspekte. Wer wissen will, wie viele Bestellungen pro Minute verarbeitet wurden oder wie lange ein bestimmter Datenbankquery dauert, muss diese Metriken selbst instrumentieren.

Wichtige Metriken für serverlose Funktionen im Überblick:

• Cold Start Rate und Cold Start Duration: Wie häufig treten Cold Starts auf und wie lange dauern sie? Hohe Cold Start Raten können auf Skalierungsverhalten oder unzureichende Provisioned Concurrency hinweisen.
• p99-Latenz: Der Median der Ausführungsdauer verbirgt Ausreißer. Die 99. Perzentile zeigt, wie sich die Funktion für die langsamsten ein Prozent der Anfragen verhält.
• Fehlerquote nach Fehlertyp: Timeout-Fehler, Speicherfehler, Konfigurationsfehler und Anwendungsfehler haben unterschiedliche Ursachen und erfordern unterschiedliche Reaktionen.
• Concurrent Executions: Wie viele parallele Instanzen laufen gleichzeitig? Nähert sich der Wert dem konfigurierten Limit, drohen Throttling-Fehler.
• Downstream-Latenzen: Wie lange dauern Aufrufe an externe Dienste wie Datenbanken, APIs oder Storage? Diese Metriken muss die Funktion selbst messen und berichten.

Distributed Tracing: Der Schlüssel zur End-to-End-Sicht

In serverlosen Architekturen kann eine einzelne Nutzeraktion eine Kette von Funktionsaufrufen auslösen: Eine API-Gateway-Anfrage triggert eine Lambda-Funktion, die eine Nachricht in SQS schreibt, die wiederum eine weitere Funktion auslöst, die schließlich in eine Datenbank schreibt. Ohne Distributed Tracing ist es extrem schwierig zu verstehen, wo in dieser Kette Latenz entsteht oder Fehler auftreten.

OpenTelemetry hat sich als Standard für die Instrumentierung serverloser Funktionen etabliert. Die wichtigsten Schritte:

• Jeden eingehenden Request als Trace starten und eine Trace-ID vergeben, sofern keine weitergereicht wird.
• Trace-ID und Span-ID als Kontext in alle ausgehenden Aufrufe weitergeben – über HTTP-Header, Message-Attribute in SQS oder Event-Metadaten.
• Eigene Spans für relevante interne Operationen erstellen, insbesondere für Datenbankaufrufe und externe API-Aufrufe.
• Spans mit relevanten Attributen anreichern: User-ID, Datensatzgröße, Ziel-Endpunkt.

Tracing-Backends wie Jaeger, Tempo oder die Cloud-eigenen Trace-Dienste (AWS X-Ray, Google Cloud Trace) visualisieren die gesamte Aufrufkette und machen Engpässe sofort sichtbar.

Heartbeat-Monitoring für serverlose Workflows

Serverlose Funktionen, die durch Zeitpläne (Cron) ausgelöst werden, stellen eine besondere Monitoring-Herausforderung dar: Da kein dauerhafter Prozess läuft, gibt es nichts, das man dauerhaft überwachen könnte. Die Funktion läuft, erledigt ihre Aufgabe und verschwindet wieder.

Heartbeat-Monitoring ist hier die richtige Methode: Die Funktion sendet am Ende jeder erfolgreichen Ausführung ein Signal an ein Heartbeat-Monitoring-System. Bleibt das Signal aus, schlägt das System Alarm. Das erkennt nicht nur Fehler innerhalb der Funktion, sondern auch Probleme mit dem Scheduling selbst – etwa wenn ein Cloud-Scheduler fehlerhaft konfiguriert ist oder die Funktion wegen Ressourcenproblemen nie gestartet wird.

Cold Starts gezielt reduzieren

Cold Starts lassen sich in vielen Fällen durch gezielte Maßnahmen deutlich reduzieren:

• Provisioned Concurrency (AWS Lambda): Eine definierte Anzahl vorgewärmter Instanzen hält die Funktion permanent bereit. Das eliminiert Cold Starts für Grundlast, ist aber mit Kosten verbunden.
• Minimale Paketgröße: Kleinere Deployment-Pakete werden schneller geladen. Unnötige Abhängigkeiten und große Bibliotheken sollten konsequent entfernt werden.
• Laufzeitwahl: Compiled Languages wie Go oder Rust starten schneller als interpretierte Sprachen wie Python oder JavaScript. Für latenz-sensitive Funktionen kann die Laufzeitwahl einen messbaren Unterschied machen.

Werkzeuge für serverlose Observability

Der Markt für serverlose Observability-Werkzeuge hat sich in den letzten Jahren deutlich weiterentwickelt. Neben den Cloud-eigenen Diensten gibt es spezialisierte Lösungen wie Lumigo, Thundra und Epsagon, die tief in serverlose Laufzeitumgebungen integriert sind und automatisch Traces und Metriken erfassen. Für Teams, die auf standardisierte Werkzeuge setzen wollen, ist OpenTelemetry mit einem zentralen Collector-Backend die empfohlene Basis – unabhängig vom Cloud-Anbieter und damit portierbarer.

Fazit

Serverlose Anwendungen zu betreiben ohne durchdachte Observability bedeutet im Fehlerfall im Dunkeln zu tappen. Structured Logging, Distributed Tracing, anwendungsspezifische Metriken und Heartbeat-Monitoring für geplante Aufgaben bilden zusammen ein Fundament, das auch in komplexen serverlosen Architekturen Transparenz schafft.

Der Aufwand lohnt sich: Teams, die ihre serverlosen Anwendungen von Anfang an sorgfältig instrumentieren, reagieren im Fehlerfall schneller, verstehen ihre Systeme besser und können Optimierungspotenziale gezielt identifizieren.

Bildquelle: Pexels / Pixabay