Metriken überwachen mit Prometheus und OpenTelemetry

Was ist Metriken-Monitoring?

Metriken-Monitoring bezeichnet das kontinuierliche Erfassen, Speichern und Auswerten numerischer Messwerte über die Zeit. Eine Metrik ist eine benannte Zeitreihe, etwa Request-Rate, Fehleranzahl, CPU-Auslastung oder Queue-Länge, beschrieben durch Labels wie Service, Region oder Pod. Weil Metriken kompakt sind und sich schnell aggregieren lassen, bilden sie die Grundlage für Dashboards, Alerts und SLOs.

In Cloud-nativen Umgebungen haben sich Prometheus-Metriken und OpenTelemetry-Metriken als Standard etabliert. Exporter liefern Infrastrukturdaten, Bibliotheken in der Anwendung erzeugen Request- und Geschäftsmetriken, und das Prometheus-Textformat oder OTLP transportiert sie ins Backend. Die Herausforderung liegt heute nicht mehr im Erzeugen von Metriken, sondern darin, sie in großem Umfang zu speichern, abzufragen und zu bezahlen.

Warum Sie Metriken überwachen sollten

Metriken zeigen, ob gerade etwas nicht stimmt und wie sich der aktuelle Zustand vom Normalverhalten unterscheidet. Sie machen Engpässe vor einem Ausfall sichtbar, decken schleichende Verschlechterungen auf, die in einzelnen Logs untergehen, und liefern die Zahlen für Kapazitätsplanung und Kostendiskussionen. Fast jeder Alert, der Sekunden nach einem Problem auslöst, basiert auf einer Metrik.

Der Eigenbetrieb wird mit wachsenden Systemen aufwendiger. Einzelne Prometheus-Server stoßen an Speichergrenzen, Langzeitspeicherung erfordert zusätzliche Komponenten, Labels mit hoher Kardinalität vervielfachen die Zahl der Zeitreihen, und föderierte Setups machen globale Abfragen langsam. Am Ende pflegen Teams ein Monitoring-System, das selbst überwacht werden muss.

Welche Metriken Sie überwachen sollten

Ein bewährter Einstieg kombiniert die Golden Signals für Services mit der USE-Methode für Ressourcen:

• Traffic: Requests pro Sekunde je Service und Endpunkt.
• Fehler: fehlgeschlagene Requests, Exceptions und Fehlerstatuscodes als Rate und Anteil.
• Latenz: Request-Dauer als Histogramm, damit Sie Perzentile statt Durchschnittswerte berechnen.
• Auslastung: CPU, Speicher, Disk, Connection Pools, Thread Pools und Queue-Länge.
• Geschäftsmetriken: Bestellungen, Registrierungen oder Zahlungen, die die Auswirkungen auf das Unternehmen zeigen.

So funktioniert Metriken-Monitoring mit Obseria

Obseria nimmt Metriken per Prometheus Remote Write und OTLP an. Bestehende Exporter, Scrape-Konfigurationen und OpenTelemetry SDKs funktionieren weiter, der Obseria Agent ist optional. Noch vor der Speicherung kann Obseria Pipeline ungenutzte Zeitreihen verwerfen, nie abgefragte Labels wegaggregieren und Team- oder Umgebungsmetadaten ergänzen.

Die Metriken landen in Obseria Lake, demselben indexfreien Speicher, der auch Logs, Traces und Events enthält. Die Aufbewahrung beträgt 13 Monate, sodass Sie saisonale Spitzen ohne zweite Speicherebene vergleichen. Ihre PromQL-Abfragen und Alert-Regeln können Sie weiterverwenden:

sum by (service) (rate(http_server_request_duration_seconds_count{status=~"5.."}[5m]))
/
sum by (service) (rate(http_server_request_duration_seconds_count[5m]))

Da TopoGraph Services, Hosts und Workloads automatisch abbildet, liegen zu jeder Spitze im Chart die passenden Traces, Logs und letzten Deployments nur einen Klick entfernt. Obseria Intelligence nutzt dieselben Metriken für Anomalieerkennung und kausale Ursachenanalyse und zeigt die Belege hinter jeder Schlussfolgerung.

Kardinalität und Kosten steuern

Die Kosten für Metriken hängen von der Zahl der Zeitreihen und Datenpunkte ab. Ein einziges Label mit Nutzer-IDs oder Request-Pfaden kann Millionen Zeitreihen erzeugen. Obseria zeigt, welche Metriken und Labels das meiste Volumen verursachen, damit Sie gezielt entscheiden, was bleibt. Regeln in Obseria Pipeline schreiben Daten beim Ingest um, aggregieren oder verwerfen sie. Abgerechnet wird pro ingestiertem Datenpunkt bei unbegrenzten Nutzern, zusätzliche Engineers erhöhen die Rechnung also nie.

Bewährt hat sich ein regelmäßiger Blick auf die größten Volumentreiber, etwa einmal pro Sprint. Häufig stammen sie aus wenigen Bibliotheken oder Exportern mit sehr detaillierten Standardeinstellungen. Werden diese einmal sauber konfiguriert, sinken Volumen und Kosten dauerhaft, ohne dass für Dashboards, Alerts oder SLOs relevante Informationen verloren gehen.

Best Practices für Metriken-Monitoring

1. Histogramme für Latenz nutzen. Durchschnittswerte verbergen Ausreißer; Histogramme ermöglichen Perzentile und SLOs.
2. Labels begrenzen. Nutzer-IDs, Session-IDs oder rohe URLs gehören nicht in Metrik-Labels.
3. Namenskonventionen einhalten. Die OpenTelemetry Semantic Conventions machen Metriken über Services und Teams hinweg vergleichbar.
4. Auf Raten und Anteile alarmieren. Fehlerquoten und Burn-Rates sind stabiler als rohe Zähler.
5. Ungenutzte Metriken prüfen. Verwerfen Sie Zeitreihen, die niemand abfragt, um Rauschen und Kosten zu senken.
6. Mit anderen Signalen verknüpfen. Metriken zeigen, dass sich etwas verändert hat; Traces und Logs erklären, warum.