Prometheus, Alert Manager в проде

1. Кластеризация Prometheus

Prometheus - это stateless-система, кластеризация ему в принципе не нужна. Для надежности их просто поднимают пять ровно одинаковых, работающих параллельно и независимо друг от друга.

Состояние алертов хранит alert-manager, он и разбирается с тем чтобы на одно и тоже событие пять раз не слать уведомления.

2. Насколько удобно добавлять хосты в автоматическом режиме?

Есть из коробки service discovery на базе любого провайдера - consul, kubernetes-api,..

Если статические хосты хочешь обновлять - то выкатываешь просто обновленный конфиг и готово.

3. Готова ли эта связка для 4к+ хостов?

Готова для всего.

В случае prometheus может иметь смысл «вертикальное» масштабирование, то есть выстраивание инстансов в иерархию по типу дерева. Каждый prometheus нижнего уровня читает метрики со своих N машин. Prometheus второго уровня читает уже агрегированные метрики с инстансов первого уровня, третий уровень со второго и т.п.

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

Спасибо за ответ.

В случае prometheus может иметь смысл «вертикальное» масштабирование, то есть выстраивание инстансов в иерархию по типу дерева. Каждый prometheus нижнего уровня читает метрики со своих N машин. Prometheus второго уровня читает уже агрегированные метрики с инстансов первого уровня, третий уровень со второго и т.п.

Это уже федеративность, если не путаюсь в терминологии.

Что будет, если у меня упадёт главный prometheus, который агрегируют с нижних «веток» ?

          G
        /  \ 
       /    \
      /      \
     /        \
    E          F 
   / \        / \
  /   \      /   \
 A    B     C     D

Я себе как-то так представляю. Упадёт A, B, C, D - страшно,но не очень.

Упадёт G - завалится всё.

Это аналог нагиос-мастера. Умер мастер и всё, поллеры (nsca) курят бамбук.

Если говорить о вот этом решении

Prometheus - это stateless-система, кластеризация ему в принципе не нужна. Для надежности их просто поднимают пять ровно одинаковых, работающих параллельно и независимо друг от друга.

То нам надо будет обеспечивать запись одинаковых данных своими силами (телеграф, скрипты+крон и т.д.)?

Делай два идентичных.

Тогда ещё один глупый вопрос - в алерт менеджере можно указать два? Один основной и один фейловер?

Автоматически Alert manager переключится между нодами prometheus?

В этой «деревянной» картинке каждая точка - это пять одинаковых инстансов.

Инстансы E1-E5 опрашивают метрики со всех инстансов A1,..A5,B1,..B5

То нам надо будет обеспечивать запись одинаковых данных своими силами (телеграф, скрипты+крон и т.д.)?

Запись чего и куда? Prometheus изкоробочно интегрируется со всякими хранилищами time series. Когда в такие хранилища поступают значения одной и той же метрики с разных мест, они мерджатся в один ряд.

То есть с инстанса A1 ты получаешь

12:30  1746
12:35  1893

а с A2

12:31  1758
12:37  1845

То в бд будет в результате ряд:

12:30  1746
12:31  1758
12:35  1893
12:37  1845

При работе с метриками главная фишка в том что «одинаковость» и синхронизированность данных тебе не нужна. Нужно получить хотя бы одно значение. Большее количество значений никому не мешает.

Наоборот. В прометее ты указываешь алертменеджер(ы). Алертменеджер сам умеет дедуплицировать алерты, если они пришли с одинаковыми лейблами. Если же нет, то ты можешь дедупликацию настроить у него в конфиге сам.

Понял, спасибо.

Тестируем два разных подхода к мониторингу, сейчас подниму icinga2 и займусь Prometheus.

Да, большее количество значений это хорошо.

И то, что мерджатся это понятно.

Просто думал, что там идёт разделение и хост А отправляет в Prometheus А, хост В - Prometheus В.

Тогда при отпадании Prometheus В мы потеряем метрики с хоста В.

Но тут уже писали, что все инстансы одинаковые, поэтому такой пробелмы быть не должно. Буду ковырять, спасибо.