Metriknamen und Label-Kardinalität: Einheiten im Namen, begrenzte Werte in den Labels

Worum es geht

Ein Metrikname sagt, was gemessen wird; Labels sagen, für welchen Ausschnitt. Der Namensgebungs-Guide von Prometheus nennt die Konventionen: ein einwortiges Anwendungs- oder Subsystem-Präfix (http_, process_), eine Einheit und eine Grösse pro Metrik, Basiseinheiten (Sekunden, Byte, nicht Millisekunden oder Megabyte), die Einheit als Plural-Suffix, _total für kumulierende Zählungen und _info für Metadaten-Pseudometriken. Beispiele aus dem Guide: http_request_duration_seconds, process_cpu_seconds_total, http_requests_total. Der Guide nennt auch einen Test: sum() oder avg() über alle Label-Dimensionen einer Metrik sollten aussagekräftig sein; ist das nicht der Fall, gehören die Daten in zwei Metriken. Er hält fest, dass andere Konventionen, darunter OpenTelemetry, die Einheit aus dem Namen heraushalten und in Metadaten führen; Prometheus empfiehlt, sie im Namen zu behalten, damit Alarm- und Dashboard-Konfiguration ohne Schema lesbar bleibt.

Labels sind die Dimensionen: operation="create", stage="extract", ein Statuscode, eine Routen-Vorlage. Die wichtigere Hälfte ist die Warnung des Guides: Jede eindeutige Kombination von Label-Werten ist eine neue Zeitreihe, daher dürfen Labels keine unbegrenzten Mengen wie Benutzer-IDs oder E-Mail-Adressen tragen.

Warum es wichtig ist

Eine Zeitreihe kostet Speicher, CPU, Platte und Netzwerk, solange sie existiert. Der Instrumentierungs-Guide nennt Grössenordnungen: die Kardinalität einer Metrik als Richtwert unter 10 halten, alles über 100 oder mit Wachstumspotenzial als Fall für weniger Dimensionen oder für das Verlagern der Analyse aus dem Monitoring-System behandeln, und davon ausgehen, dass die grosse Mehrheit der Metriken überhaupt keine Labels hat. Ein klassisches Histogramm, auf klassische Weise erfasst, vervielfacht das Problem: Jeder konfigurierte Bucket erzeugt eine mit _bucket suffigierte Zeitreihe für jede Label-Kombination, ob befüllt oder nicht.

So wird es angewendet

• Nach Präfix, Grösse, Einheit, _total benennen: queue_consumed_messages_total, job_last_success_timestamp_seconds.
• Routen-Vorlagen statt roher Pfade verwenden; Statusklassen oder -codes statt Meldungen; nur enum-artige Werte.
• Vor dem Hinzufügen eines Labels dessen unterschiedliche Werte schätzen und mit den bestehenden Label-Kombinationen sowie den Histogramm-Buckets multiplizieren.
• Analysen pro Benutzer oder pro Anfrage in Logs oder Traces verlagern, wo hohe Kardinalität normal ist.
• Wo der Server es anbietet, ein Sample-Limit pro Ziel setzen (Prometheus: sample_limit in der Scrape-Konfiguration) und bei wachsender Zeitreihenzahl alarmieren, damit ein schlechtes Label erkannt wird, bevor es der Server ist.

Stolpersteine

Die Bedeutung eines Labels in den Metriknamen zu legen (http_requests_get_total) bricht die Aggregation. Sekunden und Millisekunden unter einem Namen zu mischen, lässt die Zeitreihen still kollidieren. Pod- oder Container-Namen an Anwendungsmetriken sind begrenzt, wechseln aber bei jedem Deployment und erzeugen jedes Mal eine neue Menge an Zeitreihen. Native Histogramme ändern das Kostenmodell für Buckets; der zitierte Histogramm-Guide erklärt die Varianten.

Was ein Sample-Limit bei Auslösung bewirkt

sample_limit ist eine letzte Linie, kein Filter: Überschreitet ein Ziel es, behandelt Prometheus den gesamten Scrape als fehlgeschlagen, sodass jede Metrik dieses Dienstes auf einmal verschwindet und die Alarme, die sie lesen, mit ihr verstummen. In drei Schritten einsetzen. Die bekanntermassen riskanten Labels in metric_relabel_configs verwerfen oder aggregieren, sodass ein schlechtes Label nur eine Metrik kostet, nicht das Ziel. Auf steigendes scrape_samples_post_metric_relabeling in Richtung des Limits pro Ziel alarmieren, sowie auf prometheus_tsdb_head_series des Servers, damit Wachstum vor dem Abschneiden erkannt wird. Dann sample_limit deutlich über der normalen Anzahl setzen, sodass nur ein Ausreisser auslöst. label_limit und die Längenlimits für Labels lassen den Scrape auf dieselbe Weise fehlschlagen und verdienen denselben Spielraum.