Die Monitoring-Krise bei Microservices#

Klassisches Uptime-Monitoring fragt: „Antwortet deine Website?"

Eine moderne Microservices-Architektur fragt: „Antworten alle 47 Microservices – und kommunizieren sie korrekt miteinander?"

Eine Microservices-Plattform besteht aus dutzenden vernetzter Services:

API Gateway → Auth Service → User Service → Database
             → Payment Service → Stripe
             → Notification Service → SendGrid
             → Reporting Service → Data Warehouse
             → Search Service → Elasticsearch
             → Cache → Redis

Wenn EINER dieser Services ausfällt:

Auth Service down = niemand kann sich einloggen
Payment Service down = Kunden können nicht bezahlen
Search Service down = Kunden finden keine Produkte
Redis-Cache down = das System wird langsam (Kaskadenausfall)

Klassisches Uptime-Monitoring übersieht diese Komplexität komplett.

Warum Microservices-Monitoring anders ist#

1. Verteilte Ausfälle

In monolithischen Systemen ist ein Ausfall binär: up oder down.

Bei Microservices sind Ausfälle partiell und kaskadierend:

Szenario 1: Search Service langsam
  - Such-Requests dauern 10 Sekunden (normal 200 ms)
  - Frontend-Requests laufen beim Warten auf Suchergebnisse in Timeouts
  - API-Latenz steigt um das 10-Fache
  - Nutzer sehen „Seite lädt langsam"
  - Wird von einfachen Uptime-Checks nicht erkannt (die API antwortet ja technisch)

Szenario 2: Cache Service degradiert
  - Hit-Rate des Redis-Caches fällt von 90 % auf 20 %
  - Datenbank bekommt 4-mal mehr Queries
  - Datenbank-CPU schießt auf 100 %
  - Alle Requests werden langsam (auch unabhängige)
  - Kaskadenausfall im gesamten System

Szenario 3: Service-Kommunikation gestört
  - Auth Service ist up
  - User Service ist up
  - Aber ein Netzwerkproblem verhindert die Kommunikation Auth → User
  - Nutzer können sich nicht einloggen
  - Beide Services zeigen im Monitoring „up"

2. Kubernetes-spezifische Ausfälle

Kubernetes erhöht die Komplexität:

Pod-Restart-Schleife:
  - Pod stürzt wegen Memory Leak ab
  - Kubernetes startet den Pod automatisch neu
  - Pod startet gerade, antwortet nicht auf Traffic
  - Erscheint als „up" (Pod existiert), liefert aber keine Requests aus

Node-Ausfall:
  - Ein Kubernetes-Node geht down
  - Scheduler verschiebt Pods auf andere Nodes
  - Pods sind okay, aber während der Migration kurz nicht erreichbar
  - Kurze Request-Fehler während der Übergabe

Deployment-Problem:
  - Neues Deployment hat einen Bug beim Startup
  - Pods starten nicht
  - Bestehende Pods bedienen weiter Requests
  - System ist degradiert, aber nicht komplett down

3. Service-Mesh-Komplexität

Mit einem Service Mesh (Istio, Linkerd):

Das Service Mesh bringt eine weitere Schicht:
  - Service → Sidecar → Network → Sidecar → Service
  - Sidecars können Fehler injizieren (Rate-Limiting, Timeouts)
  - Circuit Breaker können auslösen (Requests werden blockiert)
  - Load Balancing kann ungleich sein (manche Instanzen bekommen mehr Traffic)

Monitoring muss abdecken:
  - Sidecar-Health
  - Circuit-Breaker-Status
  - Load-Balancing-Verteilung
  - Health der Service-Mesh-Control-Plane

Architektur für Microservices-Monitoring#

Ebene 1: Service-Verfügbarkeit#

Überwache jeden Service einzeln:

Auth Service:
  - Läuft der Service? (Pod-Anzahl > 0)
  - Antwortet er auf Health Checks? (GET /health liefert 200)
  - Wie ist die Antwortzeit? (P95 &lt; 100 ms)
  - Wie ist die Fehlerrate? (&lt; 0,1 %)

Payment Service:
  - Läuft der Service?
  - Antwortet er? (GET /health)
  - Kann er mit Stripe kommunizieren? (Stripe antwortet)
  - Wie ist die Latenz? (P95 &lt; 500 ms)

Ebene 2: Service-Kommunikation#

Überwache die Kommunikation zwischen Services:

Auth Service → User Service:
  - Erreicht der Auth Service den User Service? (Netzwerk-Konnektivität)
  - Wie ist die Latenz? (P95 &lt; 50 ms)
  - Wie ist die Fehlerrate? (&lt; 0,01 %)

User Service → Database:
  - Erreicht der User Service die Datenbank? (Health des Connection Pools)
  - Ist der Connection Pool ausgeschöpft? (Wartet auf Verbindungen)
  - Wie ist die Query-Latenz? (P95 &lt; 100 ms)

Ebene 3: Distributed Transaction Tracing#

Überwache komplette Request-Flows:

Login-Flow eines Nutzers:
  1. API Gateway empfängt Login-Request
  2. Routet an Auth Service (Latenz: 10 ms)
  3. Auth Service fragt User Service ab (Latenz: 15 ms)
  4. User Service fragt Datenbank ab (Latenz: 20 ms)
  5. Auth Service signiert JWT-Token (Latenz: 5 ms)
  6. API Gateway liefert Antwort zurück (Latenz: 2 ms)

Gesamtlatenz: 52 ms (akzeptabel)

Wenn die User-Service-Query 500 ms statt 20 ms dauert:
  - Gesamtlatenz springt auf 532 ms
  - Nutzer sieht langsamen Login
  - Performance der Anwendung verschlechtert sich
  - Monitoring deckt die Ursache auf (User-Service-Query langsam)

Ebene 4: Kubernetes-spezifisches Monitoring#

Überwache die Kubernetes-Infrastruktur:

Pod-Health:
  - Pod-Restart-Count (Alert bei > 5 in 24 h)
  - Pod-Memory-Auslastung (Alert, wenn Limits angenähert)
  - Pod-CPU-Auslastung (Alert bei dauerhaft > 80 %)

Node-Health:
  - Node-Status (Ready, NotReady, Unknown)
  - Node-Disk-Pressure (Alert bei > 85 % belegt)
  - Node-Memory-Pressure (Alert bei &lt; 10 % verfügbar)

Deployment-Health:
  - Desired vs. Ready Replicas (Alert bei Mismatch)
  - Pod-Erstellungslatenz (Alert bei > 30 Sekunden)
  - Image-Pull-Fehler (Alert, wenn Pods nicht starten)

Echter Microservices-Monitoring-Ausfall#

Organisation: FinTech-Plattform mit über 30 Microservices und 50 Kubernetes-Pods

Architektur:

API Gateway (5 Replicas)
Auth Service (3 Replicas)
Payment Service (5 Replicas)
Notification Service (3 Replicas)
Data Pipeline (2 Replicas)
Cache (Redis-Cluster)
Datenbank (PostgreSQL)

Der Vorfall: Zahlungsverarbeitung wird langsam

Zeitachse:

14:00 Uhr: Notification-Service-Pods starten neu (Memory Leak)
14:05 Uhr: Pod-Erstellung des Notification Service langsam (Kubernetes-Scheduler überlastet)
14:10 Uhr: Requests vom Payment Service an den Notification Service laufen in Timeouts (Service antwortet nicht)
14:10 Uhr: Payment Service implementiert Client-seitige Retries (Exponential Backoff)
14:15 Uhr: Retry-Sturm kaskadiert bis zum API Gateway
14:15 Uhr: API Gateway überlastet, Request-Queue staut sich
14:20 Uhr: Alle User-Requests laufen in Timeouts
14:20 Uhr: Incident ausgerufen, On-Call-Engineer wird gepiept

Was Monitoring erkannt hätte:

14:01 Uhr: Alert „Notification Service Pod Restart Count Threshold überschritten"
14:06 Uhr: Alert „Notification Service Pod-Erstellungslatenz > 30 Sekunden"
14:07 Uhr: Alert „Notification Service Health Check schlägt fehl"
14:08 Uhr: Alert „Latenz-Spike Payment Service → Notification Service"
14:09 Uhr: Alert „Fehlerraten-Spike Payment Service"

Frühe Alerts hätten die Kaskade verhindert: Notification Service manuell neu starten oder Retry-Strategie im Payment Service anpassen.

Microservices-Monitoring umsetzen#

Option 1: DIY mit Prometheus + Grafana#

Prometheus:
  - Scrapt den /metrics-Endpoint jedes Services
  - Speichert Metriken in einer Time-Series-Datenbank
  - Führt Alert-Regeln aus (überschreitet eine Metrik den Schwellwert, gibt es einen Alert)

Grafana:
  - Visualisiert Metriken aus Prometheus
  - Dashboards pro Service
  - Service-eigene und service-übergreifende Dashboards

Implementierung: Open Source, kostenlos, braucht DevOps-Know-how
Kosten: gering (nur Infrastruktur), hoch (Engineering-Zeit)
Geeignet für: Teams mit DevOps-Expertise

Option 2: Managed Service (Datadog, New Relic)#

Datadog-/New-Relic-Agent:
  - Läuft als Sidecar in jedem Pod
  - Sammelt Metriken, Logs, Traces
  - Schickt sie an den Managed Service

Dashboard:
  - Vorgefertigte Dashboards für Kubernetes
  - APM für Service-Kommunikation
  - Distributed Tracing eingebaut

Implementierung: Vendor-Tool, komplexe Konfiguration, mächtig
Kosten: hoch (Pricing pro Host/GB), gering (Engineering-Zeit)
Geeignet für: Teams mit Budget und weniger Ops-Expertise

Option 3: Service Mesh mit eingebautem Monitoring#

Istio/Linkerd:
  - Sidecar-Proxy fängt alle Service-Kommunikation ab
  - Trackt automatisch Latenz, Fehler und Traffic
  - Liefert Observability ohne Code-Änderungen

Monitoring:
  - Service-Mesh-Dashboards zeigen Service-Abhängigkeiten
  - Circuit-Breaker-Status
  - Traffic-Verteilung
  - Request-Latenz pro Route

Implementierung: Eingriff auf Infrastruktur-Ebene, mächtig, aber komplex
Kosten: Infrastruktur-Overhead (CPU/RAM für Sidecars)
Geeignet für: große Organisationen mit vielen Services

Microservices-Monitoring-Checkliste#

Pro Service#

☐ Health-Check-Endpoint implementiert (/health liefert 200, wenn gesund)
☐ Metrics-Endpoint exponiert (/metrics für Prometheus-Scraping)
☐ Service-Verfügbarkeit überwacht (Pod läuft, Health Check ok)
☐ Service-Antwortzeit überwacht (P95-Latenz getrackt)
☐ Service-Fehlerrate überwacht (4xx, 5xx getrackt)
☐ Service-Logs zentralisiert (ELK, Splunk oder ähnlich)

Pro Service-Kommunikation#

☐ Latenz zwischen Services überwacht (Service A → Service B)
☐ Fehlerrate pro Service-Kommunikation getrackt
☐ Circuit-Breaker-Status überwacht (falls vorhanden)
☐ Timeout-Handling geprüft (saubere Retry-Logik)

Pro Kubernetes-Cluster#

☐ Pod-Health überwacht (Restart-Count, Memory, CPU)
☐ Node-Health überwacht (Status, Disk, Memory)
☐ Deployment-Health überwacht (Desired vs. Ready Replicas)
☐ Persistent-Volume-Health überwacht (verfügbarer Speicher, I/O-Fehler)
☐ Namespace-Ressourcennutzung überwacht (CPU-, Memory-Limits)

Distributed Tracing#

☐ Request-Traces gesammelt (Request-ID durch alle Services propagiert)
☐ Trace-Visualisierung verfügbar (Request-Flow sichtbar)
☐ Trace-Latenz-Aufschlüsselung sichtbar (welcher Service ist langsam?)
☐ Trace-Fehlererkennung (welcher Service ist gescheitert?)

Best Practices fürs Microservices-Monitoring#

1. Correlation-IDs für Distributed Tracing

Jeder Request sollte eine eindeutige ID haben, die durch alle Services propagiert wird:

User-Request:
  Header: X-Request-ID: 12345

Service A:
  logs: „Request 12345: Started"
  ruft Service B mit Header X-Request-ID: 12345

Service B:
  logs: „Request 12345: Received from Service A"
  ruft Service C mit Header X-Request-ID: 12345

Service C:
  logs: „Request 12345: Processing complete"

Später: alle Logs zu Request 12345 abrufen, um den ganzen Flow zu sehen

2. Strukturiertes Logging

Nicht loggen: „Error occurred" Stattdessen: JSON mit Kontext

{
  "timestamp": "2026-02-20T14:32:15Z",
  "request_id": "12345",
  "service": "payment-service",
  "level": "error",
  "message": "Payment authorization failed",
  "error_code": "STRIPE_AUTH_FAILED",
  "attempt": 1,
  "latency_ms": 2500,
  "status_code": 503
}

3. Circuit-Breaker-Pattern

Setze Circuit Breaker ein, um kaskadierende Ausfälle zu verhindern:

Normalbetrieb:
  Payment Service → ruft Stripe-API
  Stripe gibt 200 zurück (Erfolg)
  Request läuft weiter

Failure-Modus (Circuit offen):
  Stripe-API gibt 503 zurück (Service down)
  Nach 5 Fehlern öffnet sich der Circuit Breaker
  Folgende Requests scheitern sofort (kein Stripe-Call mehr)
  Stripe-API-Call-Latenz fällt von 2 s auf 50 ms
  System degradiert sauber statt zu kaskadieren

Recovery:
  Circuit Breaker auf half-open (testet 1 Request)
  Bei Erfolg: Stripe-Requests langsam hochfahren
  Bei Fehler: Circuit geht zurück auf offen

Kubernetes-spezifische Monitoring-Stolperfallen#

Stolperfalle 1: Pod-IP ändert sich beim Restart#

Wenn ein Pod neu startet, ändert sich seine IP. DNS-Records müssen aktualisiert werden.

Monitoring muss das berücksichtigen:

Über den Service-Namen monitoren, nicht über die Pod-IP
Kubernetes-DNS nutzen (service-name.namespace.svc.cluster.local)
Kubernetes-Service-Endpoints überwachen (sind die Pods registriert?)

Stolperfalle 2: Verzögerungen durch Init-Container#

Kubernetes-Init-Container laufen vor dem Hauptcontainer. Wenn ein Init-Container langsam ist:

Pod-Status: „Running" (technisch korrekt)
Aber tatsächlich: Init-Container läuft noch, Service noch nicht ready
Health Checks könnten fehlschlagen (Service antwortet noch nicht)

Lösungen:

In den ersten 60 Sekunden nicht auf Health-Check-Fehler alerten
Startup Probes nutzen (anders als Liveness Probes)
Latenz beim Abschluss der Init-Container überwachen

Stolperfalle 3: Resource Limits beeinflussen die Performance#

Wenn das CPU-Limit eines Pods zu niedrig ist:

Pod-Status: Running
Aber tatsächlich: CPU-Throttling, Latenz-Spike
Monitoring zeigt Latenz-Spike, CPU-Auslastung zeigt 100 % Throttling

Lösung: sowohl CPU-Auslastung ALS AUCH CPU-Throttling überwachen
Alerten, wenn CPU > 20 % der Zeit gethrottlet wird

Nova Uptime fürs Microservices-Monitoring#

Der kostenlose Tarif von Nova Uptime kann Microservices überwachen:

Service-Health-Checks: Health-Endpoints der einzelnen Services überwachen
API-Monitoring: Antwortzeiten und Fehlerraten tracken
Webhook-Monitoring: Service-zu-Service-Kommunikation prüfen
E-Mail-Monitoring: prüfen, ob der Notification Service E-Mails zustellt
Public-API-Monitoring: falls Services öffentliche APIs anbieten

Für umfassendes Microservices-Monitoring nutzt du spezialisierte Tools (Prometheus, Datadog, New Relic). Aber Nova Uptime kann sie ergänzen, indem es externe Service-Health und kundenseitige APIs überwacht.

Zusammenfassung: Microservices-Monitoring jenseits einfacher Uptime#

Microservices brauchen anspruchsvolleres Monitoring als klassische Systeme.

Dein Action Plan:

Health-Check-Endpoints implementieren in jedem Microservice
Metriken exponieren (/metrics-Endpoint für Prometheus)
Correlation-IDs in alle Request-Flows einbauen
Circuit Breaker einsetzen, um Kaskadenausfälle zu verhindern
Strukturiertes Logging mit Request-Kontext
Service-Kommunikation überwachen (Latenz, Fehler)
Kubernetes-Infrastruktur überwachen (Pods, Nodes, Deployments)
Distributed Tracing aufsetzen (vollständigen Request-Flow sehen)
Pro-Service-Dashboards bauen (Sichtbarkeit für jeden Service)
Auf Degradation alerten (nicht nur auf Komplettausfälle)

Starte mit Nova Uptime, um deine kundenseitigen APIs zu überwachen. Ergänze Health-Check-Monitoring. Komplettiere das Setup mit Prometheus/Grafana oder einem Managed Service für tieferes Infrastruktur-Monitoring.

Deine Microservices sind komplex. Dein Monitoring sollte zu dieser Komplexität passen.

Monitoring von Microservices und Kubernetes: Mehr als einfache Uptime-Checks