Jak rozwiązywać problemy z brakującymi danymi w mojej bazie danych Prometheus?

Stopniowo włączam Prometheusa do moich przepływów pracy monitorowania, aby zebrać szczegółowe dane na temat działania infrastruktury.

Zauważyłem podczas tego, że często napotykam osobliwy problem: czasami eksporter, z którego Prometheus ma pobierać dane, przestaje odpowiadać. Może z powodu błędnej konfiguracji sieci - nie jest już dostępny - lub po prostu z powodu awarii eksportera.

Niezależnie od tego, jaki to może być powód, uważam, że brakuje niektórych danych, które spodziewam się zobaczyć w Prometeuszu, i przez pewien czas nie ma nic w serii. Czasami awaria jednego eksportera (przekroczenie limitu czasu?) Wydaje się również powodować awarię innych (pierwszy limit czasu przesunął całe zadanie powyżej limitu czasu najwyższego poziomu - tylko spekulacje).

Widzę tylko przerwę w serii, jak pokazano na powyższej wizualizacji. Gdy tak się dzieje, w dzienniku nie ma nic. Samometria Prometeusza również wydaje się dość jałowa. Właśnie musiałem ręcznie spróbować powtórzyć to, co robi Prometeusz i zobaczyć, gdzie się psuje. To jest irytujące. Musi być lepszy sposób! Chociaż nie potrzebuję alertów w czasie rzeczywistym, chcę przynajmniej widzieć, że eksporter nie dostarczył danych. Nawet logiczna flaga „hej sprawdź swoje dane” byłaby początkiem.

Jak uzyskać istotne informacje o tym, że Prometheus nie uzyskał danych od eksporterów? Jak zrozumieć, dlaczego istnieją luki bez konieczności przeprowadzania ręcznej symulacji gromadzenia danych Prometheus? Jakie są rozsądne praktyki w tym zakresie, być może nawet w przypadku ogólnego monitorowania gromadzenia danych poza Prometeuszem?

Myślę, że możesz zrobić coś w rodzaju alertu dla metryki za ratepomocą czegoś takiego:

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

Głównym pomysłem jest ostrzeganie za każdym razem, gdy wskaźnik metryki wynosi 0 przez 3 minuty, z odpowiednią nazwą metryki i etykietą informującą, od którego eksportera pochodzi, że powinna ona podawać prawidłowe informacje.

Wybór właściwych wskaźników do monitorowania przez eksportera może być złożony, bez większego wglądu trudno jest podać lepszą poradę z próżni.
Ten post na blogu może być inspiracją również do bardziej ogólnego wykrywania.

Istnieje kilka powodów, które mogły spowodować lukę. Najprawdopodobniej eksporter jest upnieosiągalny, w którym to przypadku przedziały czasowe będą wynosić 0. Możesz o tym ostrzec w ten sposób (wzięte z 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.",
  }

Na stronie statusu powinieneś również zobaczyć, że jest wyłączony, w tym komunikat o błędzie. Niestety nie ma sposobu, aby zobaczyć błąd z przeszłości, ale istnieje problem z jego śledzeniem: https://github.com/prometheus/prometheus/issues/2820

Twój serwer Prometheus może być również przeciążony, powodując zatrzymanie zgarniania, co również wyjaśnia luki. W takim przypadku powinieneś zobaczyć Storage needs throttling. Scrapes and rule evaluations will be skipped.błędy w dzienniku i wzrost prometheus_target_skipped_scrapes_totalwskaźników. Powinieneś też o tym ostrzec, np .:

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

Nie jestem pewien, czy to ten sam problem, który widzisz. Widzieliśmy jednak te losowe luki w aplikacjach Java, które nie określały specjalnie ustawień GC. Oznacza to, że widzieliśmy luki, gdy zatrzymano gromadzenie danych, ponieważ aktywność dla instancji zatrzymała się, gdy JVM robił pełną GC. Jeśli używasz Java, może się to zdarzyć. Naszą poprawką było jawne użycie modułu czyszczącego G1 (Java 8+) z określonym ograniczeniem długości działania GC, aby zapobiec tym przerwom w gromadzeniu danych.