Як вирішити проблеми, що відсутні у моїй базі даних Прометея?

Я поступово інтегрую Прометей у мої робочі процеси моніторингу, щоб зібрати детальні показники щодо роботи інфраструктури.

Під час цього я помітив, що часто натрапляю на своєрідне питання: іноді експортер, про який повинен був Прометей витягувати дані, стає невідповідним. Можливо, через неправильну конфігурацію мережі - вона більше недоступна - або просто тому, що експортер зазнав аварії.

Якою б причиною це не було, я вважаю, що деякі дані, які я очікую побачити в Прометеї, відсутні, і в серії немає нічого за певний проміжок часу. Іноді один невдалий експортер (вичерпання часу?) Також, здається, спричиняє збій у інших (перший тайм-аут підсунув всю роботу вище тайм-ауту верхнього рівня - просто спекуляція).

Все, що я бачу, - це розрив у серії, як показано на наведеній вище візуалізації. У журналі немає нічого, коли це станеться. Самометрія Прометея також здається досить безплідною. Мені просто довелося вдатися до того, щоб вручну намагатися повторити те, що робить Прометей, і побачити, де воно ламається. Це набридливо. Має бути кращий спосіб! Поки мені не потрібні сповіщення в режимі реального часу, я, принаймні, хочу мати можливість бачити, що експортеру не вдалося доставити дані. Навіть булевий прапор "Ей перевіри свої дані" був би початком.

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

Я думаю, що ваша людина може зробити якесь попередження про показник 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/isissue/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 робив повний GC. Якщо ви використовуєте Java, це може статися. Наше виправлення полягало в тому, щоб явно використовувати збирач сміття G1 (Java 8+) із заданим обмеженням тривалості активності в GC, щоб запобігти цим часовим розривам у збиранні даних.