Prometheus Monitoring mit Remote Write und PromQL
Behalten Sie Exporter, Scrape-Konfigurationen und PromQL. Obseria empfängt Prometheus-Metriken per Remote Write oder OpenTelemetry Collector und ergänzt Langzeitspeicher, Topologie und KI-Ursachenanalyse.
Warum Prometheus mit Obseria überwachen
PromQL bleibt
Fragen Sie Prometheus-Metriken in Obseria mit PromQL ab oder wechseln Sie zu OQL und SQL, wenn Sie Metriken mit Logs und Traces verknüpfen möchten.
Langzeitspeicher ohne Sharding
Metrik-Datenpunkte werden 13 Monate in Obseria Lake gespeichert. Thanos, Cortex oder Federation nur für die Historie entfallen.
Kontext über Metriken hinaus
TopoGraph ordnet jede Zeitreihe Pod, Host und Service zu, Obseria Intelligence korreliert Anomalien mit Traces und Logs.
Prometheus-Quellen, die Obseria aufnimmt
- Prometheus Server. Bestehende Server leiten Samples per Remote Write mit Bearer-Token und Relabeling pro Zeitreihe weiter.
- Prometheus Agent Mode. Prometheus läuft im Agent Mode als schlanker Scraper, der nur weiterleitet und keine lokale TSDB benötigt.
- Exporter. node_exporter, blackbox_exporter, mysqld_exporter, kube-state-metrics und jeder andere /metrics-Endpunkt funktionieren unverändert.
- OpenTelemetry Collector. Der prometheus-Receiver scrapt Targets mit Standard-scrape_configs und sendet die Daten per OTLP.
- Kubernetes Service Discovery. Pods, Services und Endpoints, die Prometheus oder das Obseria-Agent-DaemonSet erkennt, werden automatisch gescrapt.
- Client Libraries. Anwendungen mit Prometheus-Client-Libraries für Go, Java, Python oder Node.js brauchen keine Codeänderung.
Die Prometheus-Kennzahlen, auf die es ankommt
Obseria erfasst diese Werte automatisch und zeigt sie in fertigen Dashboards und Alerts.Zuverlässige Datenerfassung
Zeigt, ob alle überwachten Systeme erreichbar sind und ihre Daten pünktlich liefern, damit keine blinden Flecken entstehen.
Erfasste Datenmenge
Zeigt, wie viele Überwachungsdaten erfasst und gespeichert werden, was sowohl Speicherbedarf als auch Kosten bestimmt.
Übertragung an Obseria
Macht sichtbar, ob Daten zuverlässig und zügig weitergeleitet werden oder sich unterwegs stauen und verloren gehen.
Verlässliche Alerts
Hebt Alert-Regeln hervor, die nicht ausgeführt werden, sodass wichtige Warnungen Ihr Team womöglich nie erreichen.
Alle 8 Metriken im Detail anzeigen
| Metrik | Einheit | Aussage |
|---|---|---|
up | 1 | Ob der letzte Scrape eines Targets erfolgreich war, das erste Signal für einen defekten Exporter. |
scrape_duration_seconds | s | Dauer jedes Scrapes; Werte nahe am Timeout führen zu Lücken. |
scrape_samples_scraped | {samples} | Samples pro Scrape; plötzliche Sprünge deuten auf eine Kardinalitätsexplosion hin. |
prometheus_tsdb_head_series | {series} | Aktive Zeitreihen im Head Block, der größte Treiber für den Speicherbedarf. |
prometheus_remote_storage_samples_pending | {samples} | Für Remote Write wartende Samples; eine wachsende Queue zeigt einen Engpass. |
prometheus_remote_storage_samples_failed_total | {samples} | Samples, deren Versand mit einem nicht behebbaren Fehler scheiterte. |
prometheus_remote_storage_shards | {shards} | Aktive Remote-Write-Shards; dauerhaft auf max_shards bedeutet Drosselung. |
prometheus_rule_evaluation_failures_total | {evaluations} | Recording- und Alerting-Regeln, deren Auswertung fehlschlug. |
Prometheus-Monitoring in wenigen Minuten einrichten
- Schritt 1
Ingest-Token erstellen
Erstellen Sie in Obseria ein Token für Metrik-Ingest und legen Sie es als Datei oder Kubernetes Secret neben Prometheus ab.
- Schritt 2
remote_write ergänzen
Fügen Sie einen remote_write-Block mit Obseria-Endpunkt und Bearer-Token hinzu und laden Sie Prometheus neu. Nicht benötigte Zeitreihen können Sie vorher verwerfen.
- Schritt 3
Abfragen und alarmieren
Öffnen Sie die Prometheus-Dashboards, führen Sie Ihre PromQL-Abfragen aus und machen Sie die wichtigsten zu Alerts und SLOs.
# prometheus.yml: forward every scraped series to Obseria
remote_write:
- url: "https://<your-obseria-remote-write-endpoint>"
authorization:
type: Bearer
credentials_file: /etc/prometheus/obseria-token
queue_config:
capacity: 10000
max_shards: 50
max_samples_per_send: 2000
write_relabel_configs:
# drop high-churn series you never query
- source_labels: [__name__]
regex: "go_gc_duration_seconds.*"
action: drop
Sofort einsatzbereit
Dashboards, Alerts und SLOs, die bereitstehen, sobald die ersten Daten ankommen.
- Remote-Write-Zustand und Queue-Rückstau
- Verfügbarkeit der Scrape-Targets (up) pro Job
- Kardinalität nach Metrik und Label
- Alert: Target länger als 5 Minuten down
- Kubernetes-Cluster-Übersicht aus kube-state-metrics
Prometheus-Monitoring: Darauf kommt es an
Warum Prometheus Monitoring mehr als einen Server braucht
Prometheus ist das Standard-Metriksystem in Cloud-native-Umgebungen. Ein einzelner Server mit lokalem Speicher ist schnell aufgesetzt, wurde aber für kurze Aufbewahrung und eine einzige Fehlerdomäne entworfen. Mit jedem weiteren Cluster kommen mehrere Server pro Region, Federation und eine Langzeitspeicher-Schicht wie Thanos oder Cortex hinzu. Prometheus Monitoring wird so zu zwei Aufgaben: die Workloads überwachen und das Monitoring selbst am Leben halten.
Obseria übernimmt die zweite Aufgabe. Ihre Prometheus-Server oder -Agents scrapen Exporter wie bisher und leiten Samples per Prometheus Remote Write weiter. Obseria speichert sie 13 Monate, beantwortet PromQL-Abfragen und stellt jede Zeitreihe in den Kontext von Topologie, Traces und Logs.
Die Prometheus-Metriken, auf die es ankommt
Jedes Prometheus-Setup sollte sich mit wenigen Meta-Metriken selbst überwachen:
- Target-Zustand:
upist bei jedem erfolgreichen Scrape 1. Alarmieren Sie aufup == 0pro Job statt pro Instanz, um Alert-Stürme bei Rollouts zu vermeiden. - Scrape-Kosten:
scrape_duration_secondsundscrape_samples_scrapedzeigen langsame Exporter und Targets, die plötzlich viel mehr Zeitreihen liefern. - Kardinalität:
prometheus_tsdb_head_seriesist die Zahl aktiver Zeitreihen. Sie bestimmt den Speicherbedarf und ist die erste Metrik, wenn Prometheus per OOM beendet wird. - Remote-Write-Zustand:
prometheus_remote_storage_samples_pending,prometheus_remote_storage_samples_failed_totalundprometheus_remote_storage_shardszeigen, ob Daten den Server tatsächlich verlassen. - Regelauswertung:
prometheus_rule_evaluation_failures_totalfindet Recording- und Alerting-Regeln, die unbemerkt nicht mehr funktionieren.
Typische Probleme und wie Sie sie erkennen
Kardinalitätsexplosionen
Ein Label mit User-IDs, Request-Pfaden oder Pod-Hashes vervielfacht die Zeitreihen über Nacht. Beobachten Sie das Wachstum der Head Series und der Samples pro Scrape und verwerfen oder aggregieren Sie Labels mit write_relabel_configs, bevor sie den Server verlassen. In Obseria kann zusätzlich die Pipeline Labels beim Ingest verwerfen oder umschreiben.
Remote Write kommt nicht hinterher
Wächst die Zahl wartender Samples und stehen die Shards auf max_shards, ist das Netzwerk oder der Empfänger der Engpass. Eine Abfrage wie rate(prometheus_remote_storage_samples_failed_total[5m]) > 0 eignet sich gut als Alert. Passen Sie capacity, max_shards und max_samples_per_send in queue_config an, statt Scrape-Intervalle zu verlängern.
Lücken nach Neustarts
Lokale TSDB-Daten gehen verloren, wenn ein Pod ohne Persistent Volume neu startet. Mit Remote Write liegt die Historie in Obseria, und Prometheus im Agent Mode benötigt nur ein kleines Write-Ahead-Log.
Best Practices für skalierbares Prometheus
- Nutzen Sie am Edge Prometheus im Agent Mode oder den OpenTelemetry Collector und halten Sie nur einen zentralen Speicher für Abfragen vor.
- Setzen Sie External Labels für Cluster und Region, damit Zeitreihen verschiedener Server nie kollidieren.
- Setzen Sie
sample_limitpro Scrape-Job, damit ein einzelnes fehlerhaftes Target den Server nicht überlastet. - Halten Sie Namenskonventionen ein (
_total,_seconds,_bytes), damit Metriktypen in jedem Tool eindeutig sind. - Prüfen Sie regelmäßig die größten Zeitreihen nach Metriknamen und löschen Sie, was niemand abfragt.
So unterstützt Obseria Ihr Prometheus Monitoring
Obseria nimmt Prometheus-Daten per Remote Write, über den prometheus-Receiver des OpenTelemetry Collectors oder direkt über den Obseria Agent auf, der /metrics-Endpunkte scrapt. PromQL funktioniert für Dashboards und Alerts, mit OQL verknüpfen Sie dieselben Metriken mit Logs und Spans. TopoGraph ordnet Zeitreihen Kubernetes-Workloads und Hosts zu, sodass ein Alert auf ein Latenz-Histogramm bereits zeigt, welcher Service und welches Deployment betroffen sind. Obseria Intelligence erkennt Anomalien in Ihren Prometheus-Metriken und erklärt sie mit einer Beweiskette. Abgerechnet wird pro aufgenommenem und gespeichertem Metrik-Datenpunkt, nicht pro Host; in der Pipeline verworfene Datenpunkte kosten nur den Ingest.
Eine typische Migration läuft parallel: Sie ergänzen Remote Write in einem Cluster, vergleichen Dashboards und Alerts einige Tage nebeneinander und rollen die gleiche Konfiguration dann auf die übrigen Server aus. Da sich die Scrape-Schicht nicht ändert, bleiben Exporter, ServiceMonitors und Recording Rules genau dort, wo sie sind. Den Remote Write können Sie jederzeit wieder entfernen. Für Teams mit vielen Clustern lohnt es sich, External Labels und Relabeling-Regeln zentral zu versionieren, damit jede neue Umgebung vom ersten Tag an einheitliche Zeitreihen liefert und Kosten pro Cluster nachvollziehbar bleiben.
Verwandte Integrationen
Passende Funktionen
Kubernetes Monitoring
Sehen Sie jeden Cluster, Node, Pod und Workload im Kontext. Obseria verknüpft Metriken, Events, Logs und Traces, damit Sie die Ursache eines fehlerhaften Rollouts in Minuten finden.
Mehr erfahrenAnomalie-Erkennung
Obseria Intelligence lernt den normalen Rhythmus jedes Service, meldet echte Abweichungen statt Schwellenwert-Rauschen und fasst zusammenhängende Anomalien zu einem Problem mit wahrscheinlicher Ursache zusammen.
Mehr erfahrenMehr erfahren
Was ist Observability?
Was ist Observability? Wie Metriken, Logs, Traces und Profile Ihre Systeme verständlich machen und was Observability vom Monitoring unterscheidet.
Was ist OpenTelemetry?
Was ist OpenTelemetry? So erzeugen API, SDKs, Collector, OTLP und Semantic Conventions herstellerneutrale Traces, Metriken, Logs und Profile.
Häufige Fragen zum Prometheus-Monitoring
Ja. Obseria unterstützt PromQL für Abfragen, Dashboards und Alerts. Für die Korrelation mit Logs und Traces können Sie auf denselben Metriken auch OQL oder SQL verwenden.
Nein. Sie ergänzen einen remote_write-Block, und Ihre Server scrapen wie bisher. Viele Teams wechseln später auf den Agent Mode oder den OpenTelemetry Collector, um den lokalen Ressourcenbedarf zu senken.
Metrik-Datenpunkte werden 13 Monate aufbewahrt. Eine separate Langzeitspeicher-Schicht wie Thanos oder Cortex ist nicht nötig.
Verwerfen Sie Zeitreihen vor dem Versand mit write_relabel_configs oder filtern und aggregieren Sie sie beim Ingest in der Obseria Pipeline. Gefilterte Datenpunkte werden nur für den Ingest berechnet.
Ja. Die Prometheus-Ressource des Operators hat einen remoteWrite-Abschnitt, in dem Sie den Obseria-Endpunkt und eine Secret-Referenz eintragen. ServiceMonitors und PodMonitors bleiben unverändert.
Starten Sie heute mit dem Prometheus-Monitoring
Binden Sie Prometheus in Minuten per OpenTelemetry oder Obseria Agent an. 14 Tage kostenlos.