Metrikdesign und Kardinalität

Metrikdesign und Kardinalität

0:00 Dieses Modul enthält die eine Zahl, die über die Betriebskosten Ihres Metriksystems entscheidet. Sie heißt Kardinalität, und die Rechnung dahinter ist einfacher, als das Wort vermuten lässt: Jedes Label ist ein Multiplikator. Wer das ignoriert, lernt es irgendwann von der Speicherrechnung — oder von einem Prometheus, der nicht mehr antwortet.

0:19 Wir schauen uns zuerst an, wie man Metriken richtig benennt und typisiert, dann die bewährten Standardsätze, und zum Schluss die Rechnung, die Sie vor der Einführung aufstellen sollten.

Metrikdesign und Kardinalität

0:30 Drei Kapitel. Zuerst die Metriktypen und die Namenskonventionen von Prometheus — die sind strenger, als man zunächst denkt, und aus gutem Grund. Dann die bewährten Metriksätze RED, USE und die Golden Signals, die Ihnen die Frage abnehmen, womit man anfängt. Und schließlich die Kardinalität. Am Ende entwerfen Sie einen vollständigen Metriksatz für Pfandwerk und rechnen aus, was er kostet.

Metriktypen richtig wählen

0:54 Beginnen wir mit Namen und Einheiten. Das klingt nach Formalismus und ist Handwerk: Prometheus leitet aus dem Namen ab, welche Rechenoperationen überhaupt sinnvoll sind. Ein falsch benannter Zähler ist deshalb nicht unschön, sondern irreführend — und irreführende Kennzahlen sind schlimmer als fehlende, weil ihnen jemand vertraut und darauf eine Entscheidung stützt.

1:15 Prometheus verlangt Basiseinheiten — Sekunden statt Millisekunden, Bytes statt Kilobytes. Und es verlangt feste Endungen: _total für aufsummierte Zählwerte ohne Einheit, _seconds für Zeiten, _bytes für Datenmengen, _ratio für normierte Anteile zwischen null und eins, _info für Metadaten. Dazu kommt ein Präfix für den Anwendungsbereich.

1:37 Das ist mehr als Kosmetik: Wer eine Metrik sieht, die auf _total endet, weiß sofort, dass er eine Rate darauf anwenden muss und nicht den aktuellen Wert ablesen darf. Die Konvention transportiert also Bedeutung. Hier steht die Theorie als konkrete Namensliste. Angenommene Behälter als Counter, erkennbar an der Endung. Die Prüfdauer in Sekunden als Histogram — dazu mehr in Modul vierzehn.

2:03 Der Füllstand als Anteil zwischen null und eins, also mit der entsprechenden Endung. Und eine Metadatenmetrik für Versionsangaben, die selbst nichts misst, sondern nur Labels transportiert. Die Fußzeile enthält die Warnung, die man ernst nehmen sollte: Eine Zeit in Millisekunden ist kein Detail. Sie bricht jede Rechnung, die Basiseinheiten erwartet — und zwar um den Faktor tausend, also unauffällig genug, um lange zu überleben.

2:29 Das ist die vielleicht wichtigste Designregel für Metriken. Eine Metrik muss über alle ihre Labelwerte hinweg dasselbe messen — nur dann sind Summe und Mittelwert überhaupt sinnvoll. Wer zwei verschiedene Dinge in eine Metrik legt, weil sie ähnlich heißen, macht sie unauswertbar. Der dritte Punkt ist der praktische Nutzen der Konventionen: Die Endung sagt dem Auswertenden, welche Funktion zulässig ist.

2:52 Und der vierte ist ganz konkret — fertige Dashboards und Alarmregeln aus der Gemeinschaft erwarten genau diese Konventionen. Der erste Punkt ist harmlos und trotzdem ärgerlich: ein Counter ohne die passende Endung, den niemand als solchen erkennt. Der zweite ist die Millisekundenfalle von eben. Der dritte ist ein echter Datenfehler — ein Wert, der fallen kann, als Counter erfasst; nach jedem Neustart liefert die Rate Unsinn, und zwar plausibel aussehenden Unsinn.

3:20 Und der vierte ist der Designfehler aus der vorigen Folie: Zwei Messgrößen teilen sich einen Namen und werden von jeder Aggregation addiert. Das Ergebnis ist eine Zahl ohne Bedeutung.

Bewährte Metriksätze

3:31 Jetzt zu einer Frage, die bei jedem neuen Dienst auftaucht: Womit fängt man an? Es gibt dafür drei etablierte Antworten, die sich seit Jahren bewähren. Ihr eigentlicher Gewinn liegt dabei weniger in ihrer Genialität als in ihrer Einheitlichkeit: Wenn alle Dienste dieselben drei Kennzahlen liefern, lassen sie sich nebeneinander stellen, gemeinsam darstellen und mit denselben Regeln überwachen.

3:53 RED misst Dienste aus Anfragesicht: Rate, Errors, Duration — also wie viel, wie oft falsch, wie lange. USE misst Ressourcen: Utilization, Saturation, Errors — wie ausgelastet, wie überlastet, wie fehlerhaft. Und die Golden Signals fassen Latenz, Verkehr, Fehler und Sättigung zusammen. Der praktische Nutzen steht im letzten Satz: Alle drei ersparen die Frage, womit man anfangen soll.

4:18 Das ist mehr wert, als es klingt — die Alternative ist nämlich meistens, dass man mit gar nichts anfängt. Die Zuordnung ist einfach: RED für alles, was Anfragen beantwortet, USE für alles, was eine begrenzte Ressource ist. Bei Pfandwerk heißt das RED für den Annahmedienst und USE für die PostgreSQL-Datenbank dahinter. Die beiden Sätze beantworten unterschiedliche Fragen: RED sagt Ihnen, was der Nutzer erlebt, USE sagt Ihnen, warum. Deshalb braucht man beide.

4:47 Wer nur RED hat, sieht die Störung ohne Ursache. Wer nur USE hat, sieht eine ausgelastete Datenbank, ohne zu wissen, ob das jemanden stört. Vier Argumente für Standard statt Maßanfertigung. Drei Kennzahlen je Dienst sind für den Regelbetrieb vollständig genug — man braucht nicht mehr, um zu merken, dass etwas nicht stimmt.

5:07 Sie sind über alle Dienste vergleichbar, was ein gemeinsames Dashboard überhaupt erst möglich macht. Sie tragen die späteren Service Level Indicators ohne Umbau, worauf wir in Modul achtzehn zurückkommen. Und der vierte Punkt ist wichtig, damit kein Missverständnis entsteht: Fachliche Metriken ergänzen diese Sätze, sie ersetzen sie nicht.

5:27 Der erste Punkt kostet Vergleichbarkeit: Für jeden Dienst wird ein eigener Kennzahlensatz erfunden, meist gut gemeint. Der zweite ist eine Verwechslung — USE auf Dienste angewendet beantwortet dort keine Frage. Der dritte ist ein fachlicher: Die Fehlerquote zählt technische Fehler, aber nicht fachliche Ablehnungen; das kann richtig sein, muss aber bewusst entschieden werden.

5:48 Und der vierte ist der Prüfungsfehler — der Satz steht, wurde aber nie gegen eine echte Störung gehalten. Machen Sie das einmal: Nehmen Sie den letzten Vorfall und fragen Sie, ob Ihre Metriken ihn gezeigt hätten.

Kardinalität beherrschen

6:01 Jetzt kommt die Rechnung. Kardinalität ist der Grund, warum Metriksysteme umkippen — und es ist der einzige Teil dieses Seminars, in dem ein einzelner unbedachter Wert in einer einzelnen Codezeile ein ganzes System lahmlegen kann. Die gute Nachricht: Die Rechnung, die das verhindert, passt auf einen Bierdeckel. Man muss sie nur vorher aufstellen und nicht hinterher.

6:23 Jede Kombination von Labelwerten erzeugt eine eigene Zeitreihe. Die Dokumentation warnt ausdrücklich davor, Dimensionen mit hoher Kardinalität als Label zu verwenden — Benutzerkennungen, E-Mail-Adressen oder andere unbegrenzte Wertemengen. Der Speicherbedarf wächst dabei mit dem Produkt aller Labelwerte. Stellen Sie sich einen Aktenschrank vor: Für jede Kombination aus Abteilung, Jahr und Vorgangsart legen Sie eine eigene Mappe an. Solange diese Mengen klein sind, geht das gut.

6:51 Nehmen Sie die Kundennummer als vierte Dimension dazu, brauchen Sie ein neues Gebäude. Diese Tabelle ist die Rechnung, und sie ist bewusst simpel gehalten. Drei Dienste, vierzig Filialen, vier Materialarten — drei mal vierzig sind hundertzwanzig, mal vier sind vierhundertachtzig Zeitreihen. Das ist völlig unproblematisch.

7:11 Und dann die letzte Zeile: die Bon-Nummer. Unbegrenzt. Damit ist das Produkt unbegrenzt, und Ihr Prometheus hat ein Problem, das sich nicht durch mehr Speicher lösen lässt. Die Fußzeile sagt das Entscheidende: Die Rechnung ist ein Produkt, keine Summe. Drei für sich harmlose Labels ergeben gemeinsam ein Problem. Sie rechnen jetzt für jede geplante Metrik die Zeitreihenzahl aus und ersetzen das problematische Label.

7:37 Der Hinweis enthält die Lösung, die man kennen sollte: Was als Label nicht taugt, gehört oft als Span-Attribut in den Trace. Dort kostet es nicht dasselbe, weil ein Trace ohnehin ein Einzelfall ist und nicht über die Zeit gespeichert wird. Das ist übrigens ein schönes Beispiel dafür, warum man alle drei Signale braucht — die Bon-Nummer ist im Trace genau richtig und in der Metrik genau falsch.

7:59 Der erste Punkt ist verführerisch, weil er ja hilfreich gemeint ist: die Bon-Nummer als Label, weil sie in der Analyse praktisch wäre. Der zweite ist subtiler — der Pfad einer Anfrage wird ungruppiert übernommen und enthält Kennungen; deshalb sehen konventionsgerechte HTTP-Metriken Pfade in gruppierter Form vor. Der dritte ist besonders tückisch, weil er nur im Fehlerfall zuschlägt: ein Ausnahmetext als Label, und jede neue Fehlermeldung erzeugt eine neue Zeitreihe.

8:26 Und der vierte ist der Zeitpunkt — die Rechnung entsteht erst, wenn Prometheus schon am Limit ist.

Übung

8:33 In der Übung entwerfen Sie den Metriksatz, der uns bis zum Ende des Seminars begleitet. Nehmen Sie sich dafür wirklich Zeit: Diese Namen tragen in Modul dreizehn die Abfragen, in Modul sechzehn das Dashboard und in Modul achtzehn die Zuverlässigkeitsziele. Eine nachträgliche Umbenennung kostet Sie die gesamte Historie — das ist der teuerste Weg, einen Flüchtigkeitsfehler zu korrigieren.

8:55 Zwei Sätze sollen entstehen: RED für den Bon-Dienst, USE für seine Datenbank — jeweils mit Namen, Typ, Einheit und Labels. Und für jede Metrik ist die Zeitreihenzahl berechnet. Der Hinweis ist ernst gemeint: Der Entwurf trägt drei weitere Module. Ein schlecht gewähltes Label merken Sie erst in Modul sechzehn, wenn das Dashboard nicht die gewünschte Gruppierung hergibt — und dann müssen Sie die Metrik ändern und verlieren die Historie.

9:21 Der rote Faden geht von den Kennzahlen über die Form zur Kostenrechnung. Erst RED für den Dienst, dann USE für die Datenbank. Dann je Metrik Typ, Basiseinheit und Namensendung — das ist der Teil, den man am ehesten schludrig macht und der sich am schlechtesten nachträglich korrigieren lässt. Danach die Labels samt Wertebereich, der ja schon im Attributvertrag aus Modul vier stehen sollte. Und zuletzt die Rechnung.

9:45 Die Fußzeile gibt eine Faustregel mit: Über tausend Zeitreihen je Metrik sind ein Anlass zur Rückfrage. Der erste Punkt dreht die Reihenfolge um, auf die es ankommt: Labels wählen, ohne die Fragen aus Modul eins dagegen zu halten. Dann bekommen Sie Dimensionen, nach denen nie jemand gruppiert. Der zweite ist ein Rechenfehler, der fast immer passiert — die Zahl der Instanzen wird vergessen, dabei multipliziert auch sie.

10:10 Der dritte ist eine Vollständigkeitsillusion: RED und USE wirken vollständig, und die fachlichen Metriken bleiben auf der Strecke. Und der vierte ist der organisatorische — der Entwurf bleibt im Protokoll und landet nie im Code.