Kardinalität ist die Anzahl eindeutiger Werte, die eine Dimension annehmen kann. In der Observability bezeichnet sie meist die Zahl unterschiedlicher Zeitreihen einer Metrik, also die Zahl eindeutiger Kombinationen ihrer Label-Werte. Attribute mit hoher Kardinalität wie User-IDs machen Daten detaillierter, können Speicher-, Arbeitsspeicher- und Abfragekosten aber stark erhöhen.
Was Kardinalität bedeutet
In der Mathematik ist die Kardinalität die Mächtigkeit einer Menge. In der Observability wird der Begriff in zwei eng verwandten Bedeutungen verwendet. Erstens beschreibt die Kardinalität eines Attributs, wie viele unterschiedliche Werte es hat: http.request.method hat eine Handvoll, user.id womöglich Millionen. Zweitens ist die Kardinalität einer Metrik die Zahl unterschiedlicher Zeitreihen, die sie erzeugt. Jede eindeutige Kombination von Label-Werten bildet eine eigene Zeitreihe, die gespeichert, indiziert und abgefragt werden muss.
Nehmen wir die Metrik http_requests_total mit den Labels service (20 Werte), endpoint (50 Werte), status_code (8 Werte) und pod (30 Werte). Im ungünstigsten Fall ergibt das 20 × 50 × 8 × 30 = 240.000 Zeitreihen für einen einzigen Metriknamen. In der Praxis tritt nicht jede Kombination auf, doch die Multiplikation zeigt, warum ein einziges zusätzliches Label das Bild drastisch verändern kann.
Warum Kardinalität wichtig ist
Zeitreihendatenbanken wie Prometheus führen für jede aktive Zeitreihe einen Indexeintrag und halten aktuelle Samples im Arbeitsspeicher. Speicherbedarf, Ingest-Last und Abfragelatenz wachsen daher mit der Zahl aktiver Zeitreihen, nicht mit der Zahl der Metriknamen. Eine Kardinalitätsexplosion entsteht, wenn ein Label plötzlich unbegrenzt viele Werte annimmt, etwa wenn ein Request-Pfad mit Bestellnummer als Label verwendet wird. Jede neue Bestellung erzeugt neue Zeitreihen, und der Speicherbedarf wächst, bis die Datenbank langsam oder instabil wird.
Kardinalität treibt auch Kosten. Viele kommerzielle Metrikprodukte rechnen nach Zahl der Custom Time Series ab, ein unbedachtes Label kann die Rechnung also vervielfachen. Gleichzeitig sind Daten mit hoher Kardinalität genau das, was Debugging ermöglicht: Zu wissen, dass Fehler nur einen Kunden, einen Build oder einen Kubernetes-Node betreffen, ist oft der Schlüssel zur Ursache.
Metriken versus Events und Traces
Wie stark der Zielkonflikt zwischen Detailtiefe und Kosten ausfällt, hängt vom Datenmodell ab. Metriken aggregieren Daten vorab zu Zeitreihen. Das ist für Dimensionen mit niedriger Kardinalität günstig und für hohe Kardinalität teuer. Logs und Traces speichern einzelne Events mit beliebigen Attributen, eine user.id an einem Span erzeugt also keine neue Zeitreihe. Ein bewährtes Muster: Metriken für Dashboards und Alerting mit niedriger Kardinalität halten und den Kontext mit hoher Kardinalität an Spans und strukturierte Logs hängen, verknüpft über Exemplars.
Beispiel: den Verursacher finden
In Prometheus listen Sie die Metriknamen mit den meisten Zeitreihen etwa mit dieser Abfrage auf:
topk(10, count by (__name__) ({__name__=~".+"}))Angenommen, die beispielhafte Metrik api_latency_seconds_bucket hat 1,8 Millionen Zeitreihen. Die Aufschlüsselung mit count by (path) (api_latency_seconds_bucket) zeigt, dass path rohe URLs wie /orders/84721 enthält. Ersetzt man den Pfad durch das Routen-Template /orders/{id}, wie es die OpenTelemetry Semantic Conventions für http.route empfehlen, schrumpft das Label auf wenige Dutzend Werte. Beachten Sie, dass Histogramme die Kardinalität zusätzlich vervielfachen, weil jede Bucket-Grenze eine eigene Zeitreihe ist.
Best Practices
- Begrenzte Label-Werte verwenden. Routen-Templates statt URLs, Statusklassen statt Freitext-Fehlermeldungen.
- Unbegrenzte Identifikatoren nicht an Metriken hängen: User-IDs, Request-IDs, Session-IDs und E-Mail-Adressen gehören in Traces und Logs.
- Labels beim Ingest entfernen oder aggregieren. Eine Telemetrie-Pipeline kann Labels wie
podentfernen, wenn keine Auflösung pro Pod nötig ist. - Kardinalität überwachen. Verfolgen Sie aktive Zeitreihen pro Metrik und alarmieren Sie bei plötzlichem Wachstum, wie bei jeder anderen Ressource.
- Konventionen vereinbaren. Einheitliche Attributnamen und erlaubte Werte über Teams hinweg verhindern doppelte Zeitreihen mit leicht abweichenden Labels.
Häufige Fehler
Der häufigste Fehler ist, Daten mit hoher Kardinalität ganz zu vermeiden und damit die Frage „Wer genau ist betroffen?“ nicht mehr beantworten zu können. Der gegenteilige Fehler: jedes Attribut an jede Metrik hängen, „nur für alle Fälle“. Eine weitere Falle ist Churn: Labels wie Container-IDs in Kubernetes ändern sich bei jedem Deployment und erzeugen fortlaufend neue Zeitreihen, selbst wenn die Zahl aktiver Zeitreihen zu jedem Zeitpunkt moderat aussieht.
Wie Obseria unterstützt
Obseria Lake ist ein indexfreies Lakehouse mit Schema-on-Read. Attribute mit hoher Kardinalität an Logs und Spans erfordern daher keine vorab definierten Indizes. Obseria Pipeline kann Labels beim Ingest filtern, aggregieren oder entfernen, bevor sie teuer werden, und die nutzungsbasierte Abrechnung pro Signal macht die Wirkung dieser Entscheidungen sichtbar. Passende Ansätze finden Sie unter Observability-Kosten senken mit Pipeline-First und im Cloud-Kostenmanagement.
