Monitoring Grundlagen

Lernziele

Nach dieser Lektion kannst du Metriken, Logs und Traces sauber voneinander abgrenzen und begründen, wofür sich welches Signal eignet. Du verstehst, warum Prometheus auf ein Pull-Modell setzt, wo dessen Grenzen liegen und wann ein Push-Ansatz die bessere Wahl ist. Außerdem kennst du mit der RED- und der USE-Methode zwei Frameworks, mit denen du im Interview strukturiert beantworten kannst, was man überhaupt messen sollte.

Das Problem: „Läuft der Service noch?” ist die falsche Frage

Stell dir einen Webshop vor, der aus zwanzig Microservices besteht. Irgendwann zwischen 14:00 und 14:30 werden Bestellungen langsamer, ein Teil schlägt fehl. Kein Service ist „down” — alle Health-Checks sind grün. Ohne Messdaten bleibt dir nur Raten: Du klickst dich durch Logs einzelner Pods und hoffst, zufällig den richtigen zu erwischen.

Monitoring löst genau dieses Problem: Es macht den Zustand eines Systems kontinuierlich messbar, sodass du Abweichungen erkennst, bevor (oder zumindest während) Nutzer sie spüren — und nach einem Incident belegen kannst, was wann passiert ist. Der Begriff Observability geht noch einen Schritt weiter: Ein System ist observable, wenn du aus seinen Außensignalen auch neue, vorher nicht antizipierte Fragen beantworten kannst. Monitoring fragt „Ist das kaputt, was ich kenne?”, Observability fragt „Warum verhält sich das System so?”.

Die drei Signale: Metriken, Logs, Traces

Die drei Säulen unterscheiden sich fundamental in Struktur, Kosten und Einsatzzweck — und genau diese Abgrenzung wird im Interview erwartet.

Metriken sind numerische Zeitreihen: ein Wert, ein Zeitstempel, ein Satz Labels. http_requests_total{status="500"} ist so eine Zeitreihe. Metriken sind extrem günstig zu speichern (ein Messpunkt sind wenige Bytes), aggregierbar und damit ideal für Dashboards und Alerting. Ihr Preis: Sie sind vor-aggregiert. Du siehst, dass 2 % der Requests fehlschlagen — aber nicht, welcher Request für welchen Kunden.

Logs sind diskrete Ereignisse mit beliebigem Inhalt, im Idealfall strukturiert (JSON). Sie tragen den Kontext, den Metriken wegwerfen: Stack Traces, Request-IDs, Fehlermeldungen. Dafür sind sie teuer — bei hohem Traffic erzeugt ein einziger Service Gigabytes pro Tag, und über Logs zu alerten ist langsam und fragil.

Traces verfolgen einen einzelnen Request über Servicegrenzen hinweg: Welcher Service hat wie lange gebraucht, wo entstand die Latenz? Unverzichtbar in Microservice-Architekturen, aber fast immer gesampelt, weil 100 % Tracing zu teuer wäre.

Die Faustregel für die Praxis und fürs Interview: Metriken sagen dir, dass etwas kaputt ist. Logs und Traces sagen dir, warum. Ein Alert feuert auf einer Metrik („Fehlerrate > 1 %”), danach grenzt du mit Traces den Service und mit Logs die Ursache ein.

Pull vs. Push: warum Prometheus scraped

Es gibt zwei Wege, Metriken einzusammeln. Im Push-Modell schicken Anwendungen ihre Messwerte aktiv an einen zentralen Collector — so arbeiten etwa StatsD oder das InfluxDB-Ökosystem. Im Pull-Modell drehst du die Richtung um: Jede Anwendung stellt ihre Metriken auf einem HTTP-Endpoint (/metrics) bereit, und der Monitoring-Server holt sie in festen Intervallen ab. Diesen Vorgang nennt Prometheus Scraping.

Prometheus hat sich bewusst für Pull entschieden, und die Gründe sind ein Interview-Klassiker:

• Health-Check gratis: Schlägt der Scrape fehl, weiß Prometheus sofort, dass das Target nicht erreichbar ist — die eingebaute Metrik up wird 0. Im Push-Modell ist „keine Daten” mehrdeutig: Ist der Service tot oder hat er nur nichts zu melden?
• Kontrolle beim Server: Scrape-Intervall und Last bestimmt Prometheus, nicht tausende Clients. Ein fehlkonfigurierter Service kann den Monitoring-Server nicht mit Daten fluten.
• Debugbarkeit: Du kannst jeden /metrics-Endpoint mit curl selbst ansehen — kein Tooling nötig.

Ehrliche Grenzen: Pull setzt voraus, dass Prometheus die Targets erreichen kann. Bei kurzlebigen Batch-Jobs, die nach Sekunden beendet sind, gibt es nichts zu scrapen — dafür existiert das Pushgateway, an das Jobs ihr Ergebnis vor dem Beenden pushen. Und über Netzwerkgrenzen hinweg (Edge-Geräte, fremde Netze, NAT) ist Push oft praktikabler. Das Pushgateway ist bewusst eine Ausnahme für Batch-Jobs, kein genereller Push-Eingang: Es vergisst Werte nicht von selbst, und up sagt dann nichts mehr über den Job aus.

Was messen? RED und USE als Startpunkt

Die häufigste Unsicherheit am Anfang ist nicht das Wie, sondern das Was. Zwei etablierte Methoden geben dir ein Gerüst:

Die RED Method für Services (request-getrieben): Rate (Requests pro Sekunde), Errors (Anteil fehlgeschlagener Requests), Duration (Latenzverteilung, nicht nur der Durchschnitt). Wenn du für jeden Service diese drei Werte hast, kannst du fast jede „Der Shop ist langsam”-Beschwerde eingrenzen.

Die USE Method für Ressourcen (Hosts, Disks, Netzwerk): Utilization (wie ausgelastet), Saturation (wie viel Arbeit staut sich, z. B. Load, Queue-Länge), Errors (z. B. I/O-Fehler). USE findet Engpässe in der Infrastruktur, RED misst die Nutzererfahrung — beide ergänzen sich und ersetzen einander nicht.

Praxis

Du brauchst für den Einstieg kein Kubernetes — ein Container reicht, um das Pull-Modell anzufassen:

# Prometheus lokal starten (Konfiguration siehe unten)
docker run -d --name prom -p 9090:9090 \
  -v "$PWD/prometheus.yml:/etc/prometheus/prometheus.yml" \
  prom/prometheus

# Den Metrics-Endpoint ansehen, den Prometheus über sich selbst exponiert
curl -s localhost:9090/metrics | head -20

# prometheus.yml — Prometheus scraped sich selbst
global:
  scrape_interval: 15s
scrape_configs:
  - job_name: prometheus
    static_configs:
      - targets: ["localhost:9090"]

Öffne dann http://localhost:9090 und probiere im Query-Feld:

# Ist das Target erreichbar? 1 = ja, 0 = nein
up

# Eine echte Zeitreihe mit Labels
prometheus_http_requests_total{handler="/metrics"}

Schau dir unter Status → Targets an, wie Prometheus den Scrape-Status anzeigt. Stoppe den Container kurz und beobachte, wie up auf 0 fällt — genau das ist der Pull-Vorteil in Aktion.

Typische Stolperfallen

Logs als Alert-Quelle: Wer auf „ERROR im Log” alertet statt auf eine Fehlerraten-Metrik, baut sich langsame, fragile Alerts, die bei jedem Log-Format-Wechsel brechen. Alerts gehören auf Metriken.

Durchschnittslatenz statt Verteilung: Ein Durchschnitt von 80 ms kann bedeuten, dass 5 % der Nutzer 3 Sekunden warten. Für das D in RED brauchst du Perzentile — wie das mit Histogrammen geht, klärt Lektion 3 und 7.

Pushgateway als Standardweg: Wer alle Services pushen lässt, verliert die up-Semantik und baut einen Single Point of Failure. Das Pushgateway ist nur für kurzlebige Batch-Jobs gedacht.

„Wir monitoren alles”: Hunderte Metriken ohne Fragestellung erzeugen Kosten und Rauschen, aber keine Erkenntnis. Erst die Frage (RED/USE), dann die Metrik.

Interview-Vorbereitung

Die Standardfrage „Was ist der Unterschied zwischen Metriken, Logs und Traces?” beantwortest du am besten über drei Dimensionen: Struktur (Zeitreihe vs. Event vs. Request-Pfad), Kosten (billig/aggregiert vs. teuer/detailliert) und Einsatz (Alerting vs. Ursachenanalyse vs. Latenz-Lokalisierung) — und schließt mit dem Merksatz, dass Metriken das Dass und Logs/Traces das Warum liefern.

Typische Follow-ups:

• „Warum nutzt Prometheus Pull statt Push?” — up-Semantik als eingebauter Health-Check, Lastkontrolle beim Server, Debugbarkeit per curl; Grenzen: Erreichbarkeit, Batch-Jobs.
• „Wann ist Push trotzdem richtig?” — kurzlebige Jobs (Pushgateway), Quellen hinter NAT/Firewalls, Edge-Geräte.
• „Was würdest du bei einem neuen Service als Erstes messen?” — RED: Rate, Errors, Duration; auf Infrastruktur-Ebene USE.
• „Monitoring vs. Observability?” — Monitoring prüft bekannte Fehlerzustände, Observability erlaubt neue Fragen an Außensignale; Metriken/Logs/Traces sind die Werkzeuge für beides.

Zusammenfassung

Monitoring macht Systemzustand messbar: Metriken sind günstige, aggregierbare Zeitreihen für Alerting und Dashboards, Logs und Traces liefern den Kontext für die Ursachenanalyse. Prometheus sammelt Metriken im Pull-Modell per Scraping ein und bekommt damit Erreichbarkeits-Checks (up) geschenkt; für Batch-Jobs gibt es das Pushgateway als bewusste Ausnahme. Mit RED (Services) und USE (Ressourcen) hast du ein Gerüst, was du messen solltest.

In der nächsten Lektion schauen wir hinter den Scrape: Wie Prometheus intern aufgebaut ist — Server, TSDB, Service Discovery und Alertmanager — und welchen Weg eine Metrik vom Target bis zum Alert nimmt.