Come posso risolvere i dati mancanti nel mio database Prometheus?


13

Ho gradualmente integrato Prometheus nei miei flussi di lavoro di monitoraggio, al fine di raccogliere metriche dettagliate sulla gestione dell'infrastruttura.

Durante questo, ho notato che spesso mi imbatto in un problema particolare: a volte un esportatore da cui Prometheus dovrebbe estrarre i dati non risponde. Forse a causa di un'errata configurazione della rete - non è più accessibile - o solo perché l'esportatore si è bloccato.

Qualunque sia la ragione, trovo che mancano alcuni dei dati che mi aspetto di vedere in Prometeo e che non ci sia nulla nelle serie per un certo periodo di tempo. A volte, un fallimento di un esportatore (timeout?) Sembra anche causare il fallimento di altri (il primo timeout ha spinto l'intero lavoro al di sopra del timeout di livello superiore? Solo ipotizzando).

Divario nei dati

Tutto quello che vedo è un vuoto nella serie, come mostrato nella visualizzazione sopra. Non c'è nulla nel registro quando ciò accade. Anche l'autometria di Prometeo sembra abbastanza sterile. Ho appena dovuto ricorrere al tentativo di replicare manualmente ciò che Prometheus sta facendo e vedere dove si rompe. Questo è fastidioso. Deve esserci un modo migliore! Anche se non ho bisogno di avvisi in tempo reale, almeno voglio essere in grado di vedere che un esportatore non è riuscito a fornire i dati. Anche un booleano "hey check your data" sarebbe un inizio.

Come posso ottenere informazioni significative su Prometeo che non riesce a ottenere dati dagli esportatori? Come faccio a capire perché esistono lacune senza dover eseguire una simulazione manuale della raccolta dei dati di Prometeo? Quali sono le pratiche sensibili a questo proposito, forse anche se estese al monitoraggio delle raccolte di dati in generale, oltre Prometeo?


Sono presenti voci di registro o avvisi / errori rilevanti per il problema?
Kenorb,

Nulla di tutto ciò, vedo solo un vuoto nella serie di dati. L'output di Prometheus ha solo le normali linee regolari sul salvataggio delle modifiche in sospeso ogni pochi minuti e quant'altro (a meno che non manchi alcuni registri nascosti da guardare).
Sander

Stiamo affrontando anche questo problema. @Sandro sei riuscito a trovare la causa?
Deepak N,

@DeepakN no, purtroppo non ho informazioni utili da aggiungere qui. Rimane un punto dolente quando si utilizza Prometeo.
Sander,

Risposte:


5

Penso che tu possa fare una sorta di avviso su una metrica ratecon qualcosa del genere:

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'idea principale è di avvisare ogni volta che la frequenza metrica è a 0 per 3 minuti, con il nome della metrica corretto e un'etichetta da qualche parte che dice da quale esportatore proviene che dovrebbe fornire le informazioni corrette.

La scelta della giusta metrica da monitorare da parte dell'esportatore potrebbe essere complessa, senza ulteriori approfondimenti è difficile fornire una consulenza migliore dal vuoto.
Questo post sul blog potrebbe essere d'ispirazione anche per un rilevamento più generico.


rate calcola una frequenza al secondo per un dato contatore. Questo non ha nulla a che fare con la velocità con cui vengono scartate le metriche (-> scrape_interval). Il tuo esempio avviserebbe se il dato contatore (metric_name) non aumenta per 3 minuti, il che probabilmente non è quello che l'OP vuole.
Johannes 'fish' Ziemke,

@ Johannes'fish'Ziemke Questo è il motivo per cui ho detto che trovare la metrica giusta potrebbe essere complesso. Utilizzando la timemetrica su un esportatore di nodi, ad esempio. Se hai un modo migliore per avvisare in caso di fallimento di un esportatore, sentiti libero di aggiungere una risposta
Tensibai,

@ Johannes'fish'Ziemke Benvenuto su devops.se a proposito :)
Tensibai

1

Ci sono alcuni motivi che potrebbero aver causato il divario. Molto probabilmente l'esportatore non è raggiungibile, nel qual caso la serie uptemporale sarà 0. Puoi avvisare in questo modo (preso da 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.",
  }

Nella pagina di stato dovresti anche vedere che è inattivo con un messaggio di errore. Sfortunatamente non c'è modo di vedere l'errore passato ma c'è un problema per rintracciarlo: https://github.com/prometheus/prometheus/issues/2820

Il tuo server Prometheus può anche essere sovraccaricato, causando l'arresto della raschiatura, il che spiegherebbe anche le lacune. In tal caso, dovresti visualizzare Storage needs throttling. Scrapes and rule evaluations will be skipped.errori nel registro e aumenti delle prometheus_target_skipped_scrapes_totalmetriche. Dovresti avvisare anche su questo, ad esempio:

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

1

Non sono sicuro se questo è lo stesso problema che stai vedendo. Ma abbiamo visto queste lacune casuali per le applicazioni Java che non hanno specificamente impostato le impostazioni del GC. Ciò significa che stavamo vedendo delle lacune quando la raccolta dei dati si è interrotta perché l'attività per l'istanza si è interrotta mentre la JVM stava eseguendo un GC completo. Se stai usando Java questo può succedere. La nostra soluzione consisteva nell'utilizzare esplicitamente il garbage collector G1 (Java 8+) con un limite specificato sulla durata dell'attività GC per evitare questi intervalli di tempo nella raccolta dei dati.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.