Eine Metrik ist ein numerischer Messwert eines Systems, der in regelmäßigen Abständen erfasst und als Zeitreihe gespeichert wird. Jeder Datenpunkt besteht aus Metrikname, Wert, Zeitstempel und Attributen (Labels). Metriken sind günstig zu speichern und schnell abzufragen und bilden damit die Grundlage für Dashboards, Alerting und SLOs.
Was ist eine Metrik?
Eine Metrik ist eine Zahl, die Zustand oder Verhalten eines Systems zu einem Zeitpunkt beschreibt: Requests pro Sekunde, Anzahl der Fehler, Heap-Belegung, Consumer Lag. Weil eine Metrik fortlaufend erfasst wird, entsteht eine Zeitreihe: eine Folge von Werten mit Zeitstempel, eindeutig identifiziert durch den Metriknamen und eine bestimmte Kombination von Attributen wie service.name, http.route oder region.
Metriken gehören neben Logs, Traces und Profilen zu den zentralen Signalen von Observability. Sie sind voraggregiert und bleiben daher kompakt, unabhängig davon, wie viel Traffic ein Service verarbeitet. Das macht sie ideal für langfristige Trends, Kapazitätsplanung und Alerting. Traces und Logs liefern anschließend die Details pro Request, die Sie brauchen, sobald ein Alarm auslöst.
Aufbau eines Metrik-Datenpunkts
- Name: ein stabiler Bezeichner wie
http.server.request.duration. Die Semantic Conventions von OpenTelemetry legen Namen für gängige Technologien fest. - Wert: Ganz- oder Gleitkommazahl, bei Histogrammen Bucket-Zähler plus Summe und Anzahl.
- Zeitstempel: Zeitpunkt der Messung; kumulative Summen haben zusätzlich eine Startzeit.
- Attribute (in Prometheus: Labels): Schlüssel-Wert-Paare, die eine Metrik in einzelne Zeitreihen aufteilen.
- Einheit: etwa
s,Byoder{request}, damit Werkzeuge korrekt umrechnen und anzeigen.
Metrik-Typen in OpenTelemetry und Prometheus
OpenTelemetry trennt das Instrument, das Sie im Code verwenden, vom exportierten Datenmodell. Synchrone Instrumente rufen Sie direkt im Programmablauf auf; asynchrone (Observable-)Instrumente werden zum Erfassungszeitpunkt über einen Callback ausgelesen.
| OpenTelemetry-Instrument | Typischer Einsatz | Entsprechender Prometheus-Typ |
|---|---|---|
| Counter / ObservableCounter | Monoton steigende Summen: Requests, gesendete Bytes | counter |
| UpDownCounter / ObservableUpDownCounter | Steigende und fallende Werte: aktive Verbindungen, Queue-Länge | gauge |
| Gauge / ObservableGauge | Aktuelle Momentwerte: Temperatur, CPU-Auslastung | gauge |
| Histogram | Verteilungen: Latenz, Payload-Größe | histogram |
Prometheus kennt vier Metrik-Typen: counter, gauge, histogram und summary. Summaries berechnen Quantile im Client und lassen sich nicht über Instanzen hinweg aggregieren, deshalb sind Histogramme meist die bessere Wahl. OpenTelemetry unterstützt zusätzlich exponentielle Histogramme, die ihre Bucket-Grenzen automatisch anpassen und genaue Perzentile ohne manuell abgestimmte Buckets liefern.
Temporalität
Summen und Histogramme werden entweder kumulativ (Gesamtwert seit Prozessstart, das Prometheus-Modell) oder als Delta (Änderung seit dem letzten Export) übertragen. Das Backend muss wissen, welche Variante ankommt; eine Verwechslung führt zu völlig falschen Raten.
Beispiel: einen Request-Handler instrumentieren
Das folgende Python-Beispiel (zur Veranschaulichung) erfasst Anzahl und Dauer von Requests mit der OpenTelemetry-API:
meter = metrics.get_meter("checkout")
requests = meter.create_counter("app.checkout.requests", unit="{request}")
duration = meter.create_histogram("app.checkout.duration", unit="s")
requests.add(1, {"payment.method": "card", "outcome": "ok"})
duration.record(0.182, {"payment.method": "card"})Bei zwei Zahlungsarten und zwei Ergebnissen erzeugt der Counter vier Zeitreihen pro Service-Instanz. Ein zusätzliches Attribut user.id würde dagegen eine Zeitreihe pro Nutzer erzeugen, das klassische Beispiel für eine Explosion der Kardinalität.
Best Practices
- Mit den Golden Signals beginnen. Latenz, Traffic, Fehler und Sättigung beantworten die meisten Fragen zur Service-Gesundheit; mehr dazu unter Golden Signals.
- Latenz als Histogramm erfassen. Mittelwerte verbergen das Verhalten im Long Tail; Histogramme erlauben p95 und p99 im Nachhinein und lassen sich über Pods hinweg aggregieren.
- Attribute begrenzen. Nutzen Sie Routen-Templates wie
/orders/{id}, niemals rohe URLs, IDs oder Zeitstempel. - Semantic Conventions einhalten. Standardisierte Namen machen Dashboards und Alerts über Sprachen und Anbieter hinweg portabel.
- Einheiten angeben. Eine Latenzmetrik ohne Einheit lädt zu Fehlern um den Faktor 1.000 zwischen Millisekunden und Sekunden ein.
Metriken, Alerts und SLOs
Das meiste Alerting basiert auf Metriken, weil sie sich kontinuierlich und kostengünstig auswerten lassen. Ein guter Alert bewertet eine Rate oder ein Verhältnis über ein Zeitfenster, etwa den Anteil der HTTP-5xx-Antworten in den letzten fünf Minuten, statt eines einzelnen Rohwerts. Service Level Objectives gehen einen Schritt weiter: Ein SLI wie „Anteil der Requests unter 300 ms“ wird aus einem Latenz-Histogramm berechnet, und das Error Budget zeigt, wie viel Unzuverlässigkeit im aktuellen Zeitraum noch verbleibt. Burn-Rate-Alerts auf dieses Budget wecken nur dann jemanden, wenn Nutzer messbar betroffen sind. Das hält den Lärm niedrig und schützt das Team vor Alarmmüdigkeit.
Typische Fehler
- Eine Rate aus einem Gauge berechnen oder den Rohwert eines Counters statt seiner Rate auswerten.
- Vorberechnete Perzentile über mehrere Hosts mitteln, was mathematisch nicht aussagekräftig ist.
- Jedes Team erfindet eigene Namen für dieselbe Messgröße.
- Metriken als Ersatz für Traces betrachten: Eine Metrik zeigt, dass die p99-Latenz steigt, ein Trace zeigt, wo.
Wie Obseria unterstützt
Obseria nimmt Metriken per OTLP entgegen, scrapt Prometheus-Endpunkte und erfasst Host- und Container-Metriken über den Obseria Agent. Sie fragen die Daten mit OQL, PromQL oder SQL ab, verknüpfen sie über Exemplars mit Traces und lassen Obseria Intelligence Baselines für die Anomalie-Erkennung bilden. Obseria Pipeline entfernt oder aggregiert Attribute mit hoher Kardinalität bereits beim Ingest, sodass Sie nur für die Zeitreihen bezahlen, die Sie tatsächlich nutzen.
