Comment résoudre les problèmes de données manquantes dans ma base de données Prometheus?

J'ai progressivement intégré Prometheus dans mes workflows de surveillance, afin de rassembler des métriques détaillées sur l'exécution de l'infrastructure.

Au cours de cela, j'ai remarqué que je rencontre souvent un problème particulier: parfois, un exportateur dont Prometheus est censé extraire des données ne répond plus. Peut-être à cause d'une mauvaise configuration du réseau - il n'est plus accessible - ou simplement parce que l'exportateur est tombé en panne.

Quelle qu'en soit la raison, je trouve que certaines des données que je m'attends à voir dans Prométhée sont manquantes et il n'y a rien dans la série pendant une certaine période de temps. Parfois, un exportateur qui échoue (expiration?) Semble également entraîner l'échec d'autres (le premier délai d'expiration a poussé le travail entier au-dessus du délai d'expiration de niveau supérieur? Spéculer simplement).

Tout ce que je vois, c'est un écart dans la série, comme indiqué dans la visualisation ci-dessus. Il n'y a rien dans le journal lorsque cela se produit. Les auto-mesures de Prométhée semblent également assez stériles. Je viens d'avoir à essayer manuellement de reproduire ce que fait Prométhée et de voir où il se casse. C'est gênant. Il doit y avoir une meilleure façon! Même si je n'ai pas besoin d'alertes en temps réel, je veux au moins pouvoir voir qu'un exportateur n'a pas fourni de données. Même un indicateur booléen "hé vérifier vos données" serait un début.

Comment puis-je obtenir des informations utiles sur Prometheus qui ne parvient pas à obtenir des données des exportateurs? Comment puis-je comprendre pourquoi des lacunes existent sans avoir à effectuer une simulation manuelle de la collecte de données Prometheus? Quelles sont les pratiques judicieuses à cet égard, peut-être même lorsqu'elles sont étendues au suivi des collectes de données en général, au-delà de Prométhée?

Je pense que vous pouvez faire une sorte d'alerte sur une métrique rateavec quelque chose comme ceci:

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 }}%",
}

L'idée principale est d'alerter chaque fois que le taux métrique est à 0 pendant 3 minutes, avec le nom métrique correct et une étiquette indiquant quelque part de quel exportateur il provient, il devrait vous donner les informations correctes.

Le choix de la bonne mesure à surveiller par l'exportateur pourrait être complexe, sans plus d'informations, il est difficile de donner de meilleurs conseils hors du vide.
Ce billet de blog pourrait également être une source d'inspiration pour une détection plus générique.

Il y a quelques raisons qui pourraient avoir causé l'écart. Il est très probable que l'exportateur ne soit pas accessible, auquel cas la série uptemporelle sera 0. Vous pouvez alerter sur ce point comme ceci (extrait de 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.",
  }

Sur la page d'état, vous devriez également voir qu'il est en panne, y compris un message d'erreur. Malheureusement, il n'y a aucun moyen de voir l'erreur passée, mais il y a un problème pour suivre cela: https://github.com/prometheus/prometheus/issues/2820

Votre serveur Prometheus peut également être surchargé, entraînant l'arrêt du grattage, ce qui expliquerait également les lacunes. Dans ce cas, vous devriez voir des Storage needs throttling. Scrapes and rule evaluations will be skipped.erreurs dans le journal et des augmentations dans les prometheus_target_skipped_scrapes_totalmétriques. Vous devez également en informer, par exemple:

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

Je ne sais pas si c'est le même problème que vous voyez. Mais nous avons vu ces écarts aléatoires pour les applications Java qui ne définissaient pas spécifiquement les paramètres GC. Cela signifie que nous avons constaté des lacunes lorsque la collecte de données s'est arrêtée, car l'activité de l'instance s'est arrêtée pendant que la JVM effectuait un GC complet. Si vous utilisez Java, cela peut arriver. Notre correctif consistait à utiliser explicitement le garbage collector G1 (Java 8+) avec une limite spécifiée sur la durée d'activité du GC pour éviter ces écarts de temps dans la collecte de données.