Wie behebe ich fehlende Daten in meiner Prometheus-Datenbank?

Ich habe Prometheus schrittweise in meine Überwachungsworkflows integriert , um detaillierte Messdaten zum Betrieb der Infrastruktur zu sammeln.

Dabei ist mir aufgefallen, dass ich häufig auf ein besonderes Problem stoße: Manchmal reagiert ein Exporteur, von dem Prometheus Daten abrufen soll, nicht mehr. Möglicherweise aufgrund einer Netzwerkfehlkonfiguration - auf die nicht mehr zugegriffen werden kann - oder nur, weil der Exporter abgestürzt ist.

Was auch immer der Grund sein mag, ich stelle fest, dass einige der Daten, die ich in Prometheus erwarten würde, fehlen und für einen bestimmten Zeitraum nichts in der Serie ist. Manchmal scheint ein fehlgeschlagener Exporteur (Zeitüberschreitung?) Auch andere zum Scheitern zu bringen (das erste Zeitlimit hat den gesamten Auftrag über das Zeitlimit der obersten Ebene verschoben - nur spekuliert).

Ich sehe nur eine Lücke in der Reihe, wie in der obigen Visualisierung gezeigt. In diesem Fall befindet sich nichts im Protokoll. Prometheus Selbstmetriken scheinen auch ziemlich unfruchtbar. Ich musste nur manuell versuchen zu replizieren, was Prometheus tut und zu sehen, wo es kaputt geht. Das ist lästig. Es muss einen besseren Weg geben! Ich benötige zwar keine Echtzeitwarnungen, möchte aber zumindest feststellen können, dass ein Exporteur keine Daten geliefert hat. Sogar ein boolesches Flag "Hey check your data" wäre ein Anfang.

Wie erhalte ich aussagekräftige Informationen darüber, dass Prometheus keine Daten von Exporteuren abrufen kann? Wie kann ich verstehen, warum Lücken bestehen, ohne eine manuelle Simulation der Prometheus-Datenerfassung durchführen zu müssen? Was sind die vernünftigen Praktiken in dieser Hinsicht, vielleicht sogar, wenn sie über Prometheus hinaus auf die Überwachung von Datensammlungen im Allgemeinen ausgedehnt werden?

Ich denke, Sie können eine Art Alarmierung für eine Metrik durchführen, die ungefähr so ​​aussieht rate:

ALERT DropInMetricsFromExporter
  IF rate(<metric_name>[1m]) == 0
  FOR 3m
  ANNOTATIONS {
    summary = "Rate of metrics is 0 {{ $labels.<your_label> }}",
    description = "Rate of metric dropped, actually: {{ $value }}%",
}

Die Hauptidee ist es, einen Alarm auszulösen, wenn die Metrikrate 3 Minuten lang 0 ist. Der richtige Metrikname und ein Etikett verraten, von welchem ​​Exporteur sie stammt, und geben Ihnen die richtigen Informationen.

Die Auswahl der richtigen Metrik für die Überwachung durch den Exporteur kann komplex sein. Ohne weitere Einsichten ist es schwierig, außerhalb des Vakuums einen besseren Rat zu geben.
Dieser Blog-Beitrag könnte auch als Inspiration für eine allgemeinere Erkennung dienen.

Es gibt einige Gründe, die die Lücke verursacht haben könnten. Höchstwahrscheinlich ist der Exporter nicht erreichbar. In diesem Fall ist die upZeitreihe 0. Sie können dies wie folgt melden (entnommen aus https://prometheus.io/docs/alerting/rules/#templating ):

# Alert for any instance that is unreachable for >5 minutes.
ALERT InstanceDown
  IF up == 0
  FOR 5m
  LABELS { severity = "page" }
  ANNOTATIONS {
    summary = "Instance {{ $labels.instance }} down",
    description = "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 5 minutes.",
  }

Auf der Statusseite sollten Sie auch sehen, dass es nicht funktioniert, einschließlich einer Fehlermeldung. Leider gibt es keine Möglichkeit, vergangene Fehler zu sehen, aber es gibt ein Problem, um dies zu verfolgen: https://github.com/prometheus/prometheus/issues/2820

Ihr Prometheus-Server kann auch überlastet sein und dazu führen, dass das Scraping stoppt, was ebenfalls die Lücken erklären würde. In diesem Fall sollten Storage needs throttling. Scrapes and rule evaluations will be skipped.Fehler im Protokoll und eine Erhöhung der prometheus_target_skipped_scrapes_totalMessdaten angezeigt werden. Sie sollten auch darauf hinweisen, zB:

ALERT PrometheusSkipsScrapes
  IF rate(prometheus_target_skipped_scrapes_total[2m]) > 0
  FOR 5m

Ich bin mir nicht sicher, ob dies dasselbe Problem ist, das Sie sehen. Wir haben diese zufälligen Lücken bei Java-Anwendungen festgestellt, bei denen die GC-Einstellungen nicht speziell festgelegt wurden. Dies bedeutet, dass beim Stoppen der Datenerfassung Lücken aufgetreten sind, da die Aktivität für die Instanz gestoppt wurde, während die JVM einen vollständigen GC durchführte. Wenn Sie Java verwenden, kann dies passieren. Unser Fix war die explizite Verwendung des G1-Garbage Collectors (Java 8+) mit einer festgelegten Begrenzung der Länge der GC-Aktivität, um diese Zeitlücken in der Datenerfassung zu vermeiden.