Observability as Code für AWS Lambda: Serverless Framework & Datadog

Observability as Code (OaC) verändert die Art und Weise, wie Entwicklungsteams die Überwachung ihrer Anwendungen verwalten. Statt manuelle Konfigurationen in verschiedenen Umgebungen zu pflegen, wird die Observability direkt in den Code integriert – ähnlich wie bei Infrastructure as Code (IaC). Besonders bei serverlosen Architekturen wie AWS Lambda entfaltet OaC sein volles Potenzial.

Warum manuelle Observability an Grenzen stößt

AWS Lambda bietet zwar die Möglichkeit, Funktionen gezielt zu instrumentieren, doch diese Herangehensweise birgt langfristig erhebliche Herausforderungen. Sobald neue Entwickler hinzukommen, Umgebungen erweitert oder Updates deployed werden, entstehen Inkonsistenzen. Typische Probleme sind:

• Veraltete oder fehlende Monitore in neuen Umgebungen
• Abweichende Konfigurationen zwischen Entwicklung, Staging und Produktion
• Manuell nicht erfasste Metriken oder Alerts
• Hoher Wartungsaufwand bei Skalierung des Teams oder der Infrastruktur

Jede dieser Situationen erfordert manuelle Eingriffe und erhöht das Risiko von Ausfällen oder Performance-Problemen. OaC eliminiert diese Risiken, indem es die gesamte Observability-Konfiguration in Versionierungssysteme wie Git überführt – und damit reproduzierbar, nachvollziehbar und automatisch bereitstellbar macht.

Wie Observability as Code die Herausforderungen löst

Bei OaC wird nicht nur die Anwendung selbst, sondern auch ihre Überwachung als Code definiert. Das bedeutet:

• Alle Monitore, Metriken, Alerts und Traces liegen in Dateien vor, die gemeinsam mit dem Anwendungscode verwaltet werden.
• Bei jedem Deployment wird die Observability-Schicht automatisch mitdeployt – ohne manuelle Schritte.
• Konfigurationen bleiben konsistent, unabhängig von der Umgebung oder dem Teammitglied, das das Deployment durchführt.

Diese Automatisierung reduziert nicht nur den Wartungsaufwand, sondern ermöglicht auch:

• Versionierte Konfigurationen: Jede Änderung an Monitors oder Alerts wird protokolliert und kann bei Bedarf zurückgerollt werden.
• Peer-Review-Prozesse: Teams können Observability-Konfigurationen wie Anwendungscode prüfen und genehmigen.
• Kosteneffizienz: Durch Standardisierung und Automatisierung lassen sich Überwachungskosten besser kontrollieren.
• Skalierbarkeit: Neue Umgebungen oder Funktionen können ohne zusätzlichen Aufwand integriert werden.

Schritt-für-Schritt: OaC für eine Node.js Lambda-API umsetzen

In diesem Praxisbeispiel wird eine einfache REST-API für Reisekostenberechnungen mit AWS Lambda, HTTP API Gateway und Datadog aufgebaut. Die API akzeptiert Parameter wie Reisedauer, Anzahl der Personen und Unterkunftsklasse und gibt eine detaillierte Kostenaufschlüsselung zurück.

Die technische Basis: Serverless Framework + Datadog

Der Kern der Lösung ist das Serverless Framework in Kombination mit dem Datadog-Plugin (serverless-plugin-datadog). Bei einem Deployment mit sls deploy übernimmt das Plugin folgende Aufgaben:

• Bereitstellung der Datadog Lambda Library als Layer, um Node.js-Laufzeiten für Application Performance Monitoring (APM) zu instrumentieren.
• Integration der Datadog Lambda Extension als Sidecar-Prozess, der Metriken, Traces und Logs direkt an Datadog sendet – ohne zusätzliche Forwarder-Lambdas.
• Automatische Einrichtung aller erforderlichen Umgebungsvariablen wie DD_SITE, DD_SERVICE oder DD_ENV.
• Erstellung oder Aktualisierung von Datadog-Monitoren basierend auf der Konfiguration in serverless.yml.

Ein vollständiges Beispiel für die Konfiguration:

service: trip-estimator

useDotenv: true

provider:
  name: aws
  runtime: nodejs20.x
  region: us-east-1
  stage: dev
  logRetentionInDays: 1
  environment:
    DD_API_KEY: ${env:DD_API_KEY}
    DD_SITE: ${env:DD_SITE, 'us5.datadoghq.com'}
    DD_ENV: ${sls:stage}
    DD_SERVICE: trip-estimator
    DD_VERSION: "1.0.0"
    DD_LOGS_INJECTION: "true"

functions:
  tripCostEstimator:
    handler: handler.estimate
    events:
      - httpApi:
          path: /estimate
          method: POST

plugins:
  - serverless-plugin-datadog

custom:
  datadog:
    apiKey: ${env:DD_API_KEY}
    appKey: ${env:DD_APP_KEY}
    site: ${env:DD_SITE, 'us5.datadoghq.com'}
    env: ${sls:stage}
    service: -estimator
    version: "1.0.0"
    enableDDLogs: true
    enableDDTracing: true
    enableEnhancedMetrics: true
    captureLambdaPayload: true
    addLayers: true
    monitors:
      - lambda-high-error-rate: ...
      - lambda-high-p90-latency: ...

Die Anmeldedaten (DD_API_KEY, DD_APP_KEY) werden in einer .env-Datei hinterlegt, die nicht in die Versionskontrolle eingeht. Für Produktionsumgebungen empfiehlt sich stattdessen die Verwendung von AWS Secrets Manager.

Application Performance Monitoring (APM) aktivieren

Sobald die Datadog-Layer integriert sind, erstellt jede Lambda-Aufrufung automatisch einen Trace in Datadog APM – ohne zusätzlichen Code. Für detailliertere Einblicke in Geschäftslogik können benutzerdefinierte Spans hinzugefügt werden. Dafür wird die Bibliothek dd-trace im Handler verwendet.

In der Entwicklungsumgebung wird dd-trace als DevDependency installiert:

{
  "devDependencies": {
    "dd-trace": "^5.x",
    "serverless-plugin-datadog": "^5.x"
  }
}

Im Handler wird die Bibliothek mit einem Fallback eingebunden, um lokale Tests ohne Layer zu ermöglichen:

let tracer;
try {
  tracer = require('dd-trace');
} catch {
  tracer = null;
}

let summary;
if (tracer) {
  summary = tracer.trace('trip.estimate', {
    tags: { days, people, accommodation }
  }, (span) => {
    const result = calculate(days, people, accommodation);
    span.setTag('grand_total', result.grand_total);
    span.setTag('per_person_total', result.per_person_total);
    return result;
  });
} else {
  summary = calculate(days, people, accommodation);
}

In Datadog APM erscheinen daraufhin:

• Ein automatisierter Root-Span für die gesamte Lambda-Ausführung
• Ein benutzerspezifischer Kind-Span trip.estimate mit Geschäftsattributen
• End-to-End-Metriken zu Latenz, Fehlerrate und Durchsatz pro Service

Logs mit Trace-Korrelation verbinden

Die Datadog Lambda Extension leitet alle Logs direkt an Datadog weiter – vorausgesetzt, enableDDLogs: true ist in der Plugin-Konfiguration aktiviert. Der entscheidende Vorteil liegt in der Trace-Korrelation: Jede Logzeile enthält automatisch die IDs der aktiven Traces und Spans.

So lässt sich in Datadog ein Log-Eintrag anklicken und direkt zur zugehörigen Trace-Ansicht springen – und umgekehrt. Das vereinfacht die Fehleranalyse erheblich und beschleunigt die Ursachenforschung.

Best Practices und Kosteneffizienz

Um OaC optimal zu nutzen, sollten Teams folgende Empfehlungen beachten:

• Modularisierung: Behalten Sie Observability-Konfigurationen in separaten Dateien bei, um Änderungen besser zu organisieren.
• Standardisierung: Definieren Sie wiederverwendbare Templates für Monitore und Alerts, um Konsistenz zu gewährleisten.
• Kostenkontrolle: Nutzen Sie erweiterte Metriken nur dort, wo sie wirklich benötigt werden, und deaktivieren Sie sie bei nicht-kritischen Funktionen.
• Dokumentation: Halten Sie Observability-Konfigurationen durch Kommentare und Metadaten selbsterklärend.

Mit Observability as Code wird die Überwachung nicht mehr zum Bottleneck, sondern zum integralen Bestandteil des Entwicklungsprozesses. Die Automatisierung spart Zeit, reduziert Fehler und ermöglicht es Teams, sich auf das Wesentliche zu konzentrieren: die Entwicklung robuster, skalierbarer Anwendungen.

Die Zukunft der Observability liegt in der Code-basierten Verwaltung – und AWS Lambda ist das perfekte Einsatzgebiet für diesen Ansatz.