Label (Attribut)

Was ein Label ist

Ein Label gibt einem Messwert Kontext. Die Zahl 412 allein sagt nichts; http_requests_total{service="checkout", method="POST", status="500"} 412 verrät, welcher Service, welche Methode und welches Ergebnis gezählt wird. Über Labels schneiden Sie Daten in Abfragen, Dashboards und Alerts nach diesen Dimensionen zu.

Verschiedene Systeme verwenden unterschiedliche Begriffe für dasselbe Konzept:

System	Begriff	Beispiel
Prometheus	Label	job="api", instance="10.0.0.5:9100"
OpenTelemetry	Attribut (Resource- oder Signal-Ebene)	service.name, http.route
Kubernetes	Label (Objekt-Metadaten)	app.kubernetes.io/name: checkout
Viele APM-Werkzeuge	Tag oder Dimension	env:prod

Wie Labels in Prometheus und OpenTelemetry funktionieren

In Prometheus ist eine Zeitreihe durch ihren Metriknamen und ihr vollständiges Label-Set eindeutig bestimmt; der Name selbst wird intern als Label __name__ gespeichert. Ändert sich ein einziger Label-Wert, entsteht eine andere Zeitreihe. Labels mit doppeltem Unterstrich am Anfang sind für interne Zwecke reserviert, etwa die Labels __meta_kubernetes_pod_label_*, die die Service Discovery beim Relabeling bereitstellt.

OpenTelemetry unterscheidet zwei Ebenen. Resource-Attribute beschreiben die Quelle der Telemetrie, etwa service.name, service.version, k8s.pod.name oder cloud.region, und gelten für alles, was diese Quelle sendet. Signal-Attribute gehören zu einem einzelnen Span, Log-Eintrag oder Metrik-Datenpunkt, etwa http.request.method oder http.response.status_code. Die Semantic Conventions vereinheitlichen diese Namen, damit alle SDKs und Backends dieselben Schlüssel verwenden.

Labels und Kardinalität

Jede eindeutige Kombination von Label-Werten einer Metrik erzeugt eine neue Zeitreihe. Eine Metrik mit 20 Services, 5 Methoden, 10 Statuscodes und 50 Pods kann 50.000 Zeitreihen erreichen. Kommt ein Label mit Nutzer-IDs hinzu, explodiert die Zahl. Deshalb sind Labels der wichtigste Treiber der Kardinalität und damit von Speicherbedarf, Abfragegeschwindigkeit und Kosten in Metriksystemen.

Die Faustregel: Metrik-Labels sollten begrenzte Wertebereiche mit niedriger Kardinalität haben. Unbegrenzte Kennungen wie Nutzer-IDs, Request-IDs oder vollständige URLs gehören an Spans und Logs, wo sie erwartet werden. Auf Metriken verwenden Sie stattdessen Vorlagen wie http.route="/users/{id}" statt roher Pfade. Log-Systeme, die Labels indexieren, etwa Loki, wenden dasselbe Prinzip auf Stream-Labels an.

Beispiel: Relabeling

Relabeling verändert Labels, bevor Daten gespeichert werden. Eine beispielhafte Prometheus-Scrape-Konfiguration, die ein Kubernetes-Label übernimmt und ein verrauschtes Label entfernt:

relabel_configs:
  - source_labels: [__meta_kubernetes_pod_label_app_kubernetes_io_name]
    target_label: app
metric_relabel_configs:
  - action: labeldrop
    regex: pod_template_hash

relabel_configs wirken vor dem Scrape auf Targets, metric_relabel_configs danach auf die Samples. In OpenTelemetry übernimmt der Collector diese Arbeit, etwa mit den Prozessoren attributes, resource oder transform in einer Telemetrie-Pipeline.

Labels in Kubernetes

In Kubernetes sind Labels nicht nur Metadaten für das Monitoring, die Plattform selbst arbeitet damit. Services, Deployments und NetworkPolicies wählen Pods über Label-Selektoren wie app.kubernetes.io/name=checkout aus. Zum empfohlenen Label-Set gehören app.kubernetes.io/name, app.kubernetes.io/instance, app.kubernetes.io/version, app.kubernetes.io/component, app.kubernetes.io/part-of und app.kubernetes.io/managed-by. Monitoring-Werkzeuge übernehmen diese Labels und machen daraus Prometheus-Labels oder OpenTelemetry-Resource-Attribute, etwa über den Kubernetes-Attributes-Prozessor des Collectors. Saubere Kubernetes-Labels sind damit der günstigste Weg zu einheitlichen Service-Namen und klarer Zuständigkeit in Ihrer gesamten Telemetrie. Einigen Sie sich auf ein kleines Pflicht-Set, etwa Name, Team und Umgebung, und setzen Sie es per Admission Policy durch. So lassen sich neue Workloads nicht mehr ohne diese Labels ausrollen, und Dashboards, Alerts und Kostenauswertungen können sich verlässlich darauf stützen.

Best Practices

• Konventionen folgen. Nutzen Sie die OpenTelemetry Semantic Conventions und die empfohlenen Kubernetes-Labels, statt pro Team eigene Namen zu erfinden.
• Über alle Signale konsistent bleiben. Derselbe service.name an Metriken, Logs und Traces macht Korrelation erst möglich.
• Metrik-Labels begrenzt halten und neue Labels vor dem Produktivgang auf ihren Wertebereich prüfen.
• Keine Secrets oder personenbezogenen Daten in Labels. Sie landen in Indizes, Dashboards und Alerts.
• An der Quelle oder in der Pipeline anreichern statt Ad-hoc-Joins zur Abfragezeit.

Typische Fehler

Typische Fehler sind unterschiedliche Schlüssel für dasselbe (env, environment, stage), Zeitstempel oder IDs in Metrik-Labels, Informationen im Metriknamen statt in Labels (requests_checkout_total statt eines Labels service) und Labels, die sich bei jedem Deployment ändern. Letzteres unterbricht die Kontinuität von Zeitreihen in PromQL-Abfragen. Ebenfalls problematisch sind Labels, die nur auf einem Teil der Zeitreihen gesetzt werden: Aggregationen und Joins liefern dann unvollständige Ergebnisse, ohne dass es auf den ersten Blick auffällt. Prüfen Sie neue Labels deshalb in einem Review, genau wie Änderungen an Schnittstellen.

Wie Obseria unterstützt

Obseria übernimmt OpenTelemetry-Attribute und Prometheus-Labels und hält sie über Metriken, Logs und Traces hinweg konsistent, sodass ein Filter auf service.name überall funktioniert. Obseria Lake speichert Logs und Spans indexfrei mit Schema-on-Read, hochkardinale Attribute müssen dort also nicht vorab deklariert werden. Obseria Pipeline kann Attribute beim Ingest anreichern, entfernen oder maskieren. In Kubernetes werden Pod- und Namespace-Metadaten über das Kubernetes-Monitoring automatisch ergänzt.