Begriff
Metrics
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
Logs erzählen dir eine Geschichte ("Gestern um 5 ist Server A abgestürzt"). Metriken sind Zahlen ("CPU Auslastung ist 80%"). Metriken sind billig zu speichern und extrem schnell zu durchsuchen. Sie zeigen dir Trends (wird es langsamer?) und den aktuellen Zustand. Typische Fragen für Metriken:
- "Wie viele User sind online?"
- "Wie lange dauert ein Request?"
- "Ist noch genug Speicherplatz da?"
Merksatz: Numerische Messwerte, die den Zustand eines Systems über die Zeit hinweg (Time Series Data) erfassen, um Performance, Auslastung und Verfügbarkeit zu überwachen.
Das Standard-Tool ist Prometheus.
Deine App muss einen Endpunkt /metrics bereitstellen.
Dort steht Text drin:
http_requests_total{method="post",status="200"} 1024
process_cpu_seconds_total 12.5
Prometheus kommt alle 15 Sekunden vorbei ("Scraping") und speichert die Zahlen. In Grafana baust du bunte Kurven daraus.
Praxisroutine
In der Praxis lernst du Metrics, indem du mit einem kleinen, kontrollierten Beispiel beginnst. Baue zuerst einen Minimalfall, prüfe das Ergebnis, veraendere genau eine Sache und beobachte, was sich ändert. Notiere dir Eingabe, Aktion, Ausgabe und typischen Fehler.
Übung: Erstelle ein Beispiel aus deinem Alltag, fuehre den Ablauf gedanklich Schritt für Schritt durch und markiere die Stelle, an der du Feedback oder ein Log brauchst. Wenn du diese Stelle benennen kannst, verstehst du den Begriff praktisch.
1. Metrik-Typen
Es gibt 4 heilige Typen:
- Counter: Geht nur hoch (z. B. "Anzahl Fehler"). Niemals runter (außer Neustart). Rate berechnen:
rate(errors[5m]). - Gauge: Geht hoch und runter (z. B. "Temperatur", "Queue Länge", "Aktuelle User").
- Histogram: Gruppiert Werte in Eimer (Buckets). "Wie viele Requests waren < 0.1s? Wie viele < 0.5s?". Wichtig für Perzentile (P99).
- Summary: Ähnlich wie Histogram, berechnet aber auf Clientside (weniger flexibel).
2. Cardinality Explosion
Der Tod jedes Prometheus-Servers.
Key-Value Paare heißen "Labels".
http_requests_total{method="POST", user_id="123"}.
Wenn du user_id als Label nimmst und 1 Million User hast, erstellt Prometheus 1 Million Zeitreihen.
Der RAM läuft voll (OOM).
Regel: Keine unbegrenzten Werte in Labels! (Keine User-IDs, keine URLs mit Query-Params, keine Fehlermeldungen). Nur endliche Sets (Method, Status Code, Region).
3. Pushgateway
Prometheus "pullt" (holt ab). Was ist mit Batch-Jobs, die nur 5 Sekunden laufen? Prometheus kommt zu spät. Für kurze Jobs nutzt man das Pushgateway. Der Job drückt ("pusht") seine Metriken da rein und stirbt. Prometheus holt sie später gemütlich vom Gateway ab.
1. Quantile und Das Histogram-Bucket Problem
Durchschnitte bei Latenzen sind tödlich ("Average Response Time: 50ms"). Wenn 99 Requests 10ms brauchen, und einer 4010ms (weil DB tot), ist der Schnitt bei 50. Der Support sieht nichts.
Du analysierst P99 (Das 99. Perzentil). Es zeigt dir den Wert, bei dem 99% der Anfragen abschnitten.
Die brutale Realität in Prometheus: Es kann auf dem Server keine echten Perzentile ausrechnen, weil es nicht jeden Request einzeln speichert (zu viel RAM). Prometheus zwingt dich zu "Buckets" (le="0.1", le="1.0", le="5.0").
Kommt ein P99-Request auf 0.6ms, und der Bucket geht von 0.5 bis 1.0, ratet die PromQL Engine per histogram_quantile() linear interpolierend den Wert zwischen 0.5 und 1. Das erzeugt bei falsch konfigurierten Buckets wilde Artefakt-Linien auf Grafana-Meteogrammen (Geister-Spikes).
2. Time-Series Database (TSDB) Architektur
InfluxDB, Prometheus (Gorilla Compression) operieren auf brutalem TSDB-Niveau.
Zwei Zeitstempel sind z.B 160000000 und 15s später 160000015. Man speichert bei TSDBs nicht beide gigantischen 64-Bit Zahlen. Man misst das "Delta" (+15). Beim nächsten Scrap (erneut 15s später) misst man das "Delta-of-Delta" (Differenz der Differenz ist 0). Diese winzige Null lässt sich binär auf exakt 1 Bit im Speicher komprimieren. Dasselbe passiert beim CPU-Wert (50% -> 50% = D-o-D 0). Durch dieses Delta-Encoding pressen TSDBs astronomische Millionen Datensätze pro Sekunde auf die Size eines MP3-Songs.
3. RED Metrics und Service Mesh
Die "USE" (Utilization, Saturation, Errors) Methode der 1990er überwachte primär Hardware. In Cloud-Native geht es dem SRE mehr um RED Methoden (Rate, Errors, Duration). Anstatt die CPU zu prüfen, prüfen wir die User-API. Das geniale an Kubernetes und Istio/Linkerd (Service Mesh): Der App-Code muss sich für die RED-Metriken nicht ändern. Der "Sidecar-Proxy" von Istio sitzt hart verdrahtet im Pod Container. Er sieht jeden Byte HTTP Inbound-Traffic zwangsläufig vorbei fließen, zählt die Requests im Container, und drückt ohne jegliches Eingreifen des Programmierers standardisierte L7-Grafana Kurven an Prometheus ab.
Quick-Check
Warum 4 Golden Signals?
Latenz, Traffic, Errors, Saturation (Auslastung). Diese 4 Metriken reichen aus, um den Gesundheitszustand fast jedes Systems zu beurteilen (Google SRE Book).Was ist High Resolution?
Metriken jede Sekunde sc rapen? Teuer. Standard ist 15s oder 1m. Metriken sind "Lossy" (man verliert kurze Spikes zwischen den Intervallen). Für exakte Analyse brauchst du Logs oder Tracing.Monitoring vs. Observability?
Monitoring sagt dir "Dass" etwas kaputt ist (Alert: CPU > 90%). Observability (Logs + Metrics + Traces) hilft dir herauszufinden "Warum" es kaputt ist, auch wenn du das Problem vorher noch nie hattest.