Как устранить неполадки с отсутствующими данными в моей базе данных Prometheus?

Я постепенно интегрировал Prometheus в свои рабочие процессы мониторинга, чтобы собрать подробные показатели о работе инфраструктуры.

Во время этого я заметил, что часто сталкиваюсь со специфической проблемой: иногда экспортер, из которого Прометей должен извлекать данные, перестает отвечать на запросы. Возможно, из-за неправильной конфигурации сети - она ​​больше не доступна - или просто из-за сбоя экспортера.

Какова бы ни была причина, я обнаружил, что некоторые данные, которые я ожидаю увидеть в Прометее, отсутствуют, и в этом ряду в течение определенного периода времени ничего нет. Иногда сбой одного экспортера (тайм-аут?) Также может вызывать сбой других (первый тайм-аут выдвинул всю работу выше тайм-аута верхнего уровня - просто спекуляция).

Все, что я вижу, - это пробел в серии, как показано на приведенной выше визуализации. Когда это происходит, в журнале ничего нет. Самометрика Прометея также кажется довольно бесплодной. Мне только что пришлось прибегнуть к ручным попыткам повторить то, что делает Прометей, и посмотреть, где он сломается. Это утомительно. Должен быть лучший способ! Хотя мне не нужны оповещения в реальном времени, я по крайней мере хочу видеть, что экспортер не смог доставить данные. Даже логический флаг «эй, проверь свои данные» будет началом.

Как получить значимую информацию о том, что Прометей не может получить данные от экспортеров? Как я понимаю, почему существуют пропуски без необходимости ручной симуляции сбора данных Прометея? Каковы разумные методы в этом отношении, возможно, даже когда они распространяются на мониторинг сбора данных в целом, помимо Прометея?

Я думаю, что вы можете сделать какое-то предупреждение по метрике 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 }}%",
}

Основная идея состоит в том, чтобы оповещать, когда показатель метрики равен 0 в течение 3 минут, с правильным именем метки и меткой, где-то указывается, от какого экспортера он приходит, он должен дать вам правильную информацию.

Выбор правильной метрики для мониторинга экспортером может быть сложным, без большей проницательности трудно дать лучший совет вне вакуума.
Этот пост может стать источником вдохновения и для более общего обнаружения.

Есть несколько причин, которые могли вызвать разрыв. Скорее всего, экспортер недоступен, и в этом случае upвременной ряд будет равен 0. Вы можете сообщить об этом следующим образом (взято с 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.",
  }

На странице состояния вы также должны увидеть, что она не работает, включая сообщение об ошибке. К сожалению, нет способа увидеть прошлую ошибку, но есть проблема, чтобы отследить это: https://github.com/prometheus/prometheus/issues/2820

Ваш сервер Prometheus также может быть перегружен, что приведет к остановке процесса очистки, что также объяснит пробелы. В этом случае вы должны увидеть Storage needs throttling. Scrapes and rule evaluations will be skipped.ошибки в журнале и увеличение prometheus_target_skipped_scrapes_totalпоказателей. Вы должны также предупредить об этом, например:

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

Я не уверен, что это та же самая проблема, которую вы видите. Но мы увидели эти случайные пробелы для приложений Java, которые не устанавливали параметры GC. Это означает, что мы увидели пробелы, когда сбор данных прекратился, потому что действие для экземпляра остановилось, когда JVM выполняла полный сборщик мусора. Если вы используете Java, это может произойти. Нашим исправлением было явное использование сборщика мусора G1 (Java 8+) с указанным ограничением длины активности GC, чтобы предотвратить эти временные промежутки в сборе данных.