Service Mesh / Prometheus / Kiali · Stand 2026-07-07

09 Service Mesh, Monitoring und Observability

Service Mesh kontrolliert Service-zu-Service-Kommunikation mit Sidecars, mTLS und Traffic-Regeln. Monitoring sammelt Metriken; Observability verbindet Metriken, Logs und Traces zur Fehlersuche.

Fachliche Erklärung

Microservices verschieben Komplexität vom Code in das Netzwerk. Service Mesh hilft, diese Komplexität zentral sichtbar und steuerbar zu machen.

Für jedes System gilt: Erst messen, dann optimieren. Ohne Metriken, Logs und Traces ist ein Rollout nur Hoffnung.

Mesh kann helfen bei

mTLS zwischen Services.

Canary und Traffic Splitting.

Retries, Timeouts, Circuit Breaking auf Netzwerkebene.

Topologie-Ansicht und Fehlerquoten pro Servicekante.

Mesh ist kein Freifahrtschein

Ein Mesh ersetzt kein sauberes API-Design.

Falsche Retries können Lastspitzen verschlimmern.

Jeder Sidecar kostet CPU, Memory und Betriebsaufwand.

Für kleine Systeme kann einfaches Kubernetes-Routing ausreichend sein.

Ausführliches Enterprise-Beispiel

Das Beispiel folgt einer fiktiven Shop-Landschaft mit order-api, billing-api, payment-api, portal-ui, Batch-Export und Messaging. Der Fokus liegt auf sauberem Verständnis statt auf blindem Kopieren.

Fachlicher Ablauf

Kunde bestellt über Portal.
order-api validiert Auftrag.
billing-api erzeugt Rechnung.
payment-api prüft Zahlung.
Events informieren Lager und Reporting.

Technischer Ablauf

Route nimmt HTTPS an.
Service verteilt auf Pods.
Pods lesen ConfigMaps und Secrets.
Readiness schützt Rollout.
Monitoring misst Fehlerquote und Latenz.

Konfigurations- und Codebeispiele

YAML

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: payment-routing
spec:
  hosts:
    - payment-api.shop.svc.cluster.local
  http:
    - match:
        - headers:
            x-canary:
              exact: "true"
      route:
        - destination:
            host: payment-api.shop.svc.cluster.local
            subset: v2
          weight: 100
    - route:
        - destination:
            host: payment-api.shop.svc.cluster.local
            subset: v1
          weight: 90
        - destination:
            host: payment-api.shop.svc.cluster.local
            subset: v2
          weight: 10

YAML

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: order-api
  namespace: shop
spec:
  selector:
    matchLabels:
      app: order-api
  endpoints:
    - port: http
      path: /q/metrics
      interval: 30s

BASH

oc -n shop get servicemonitor,prometheusrule
oc -n shop logs deploy/order-api --since=20m
oc adm top pods -n shop
oc -n istio-system get pods

Typische Fehlerbilder und Diagnose

Pending Pods

Prüfe Ressourcen, Node-Selector, Taints, PVC und Quotas. Nicht sofort am Java-Code suchen.

CrashLoopBackOff

Prüfe Logs des vorherigen Containers, Config/Secrets, Port, JVM Memory und Health Endpoints.

Route erreichbar, App nicht

Prüfe Service-Selector, Endpoints, Readiness, TLS-Termination und NetworkPolicy.

Praxisaufgabe

Baue ein Canary-Szenario: 90 Prozent Traffic auf payment v1, 10 Prozent auf v2. Definiere Metriken, ab wann v2 abgebrochen wird.

Merksätze

Deklarativer Zustand ist wichtiger als manuelle Serveränderung.
Security und Betrieb gehören von Anfang an zum Deployment.
Jede YAML-Datei ist Architekturentscheidung und sollte reviewbar sein.
Produktionsreife entsteht durch Messbarkeit, Rollback und klare Ownership.