Мониторинг однотипных микросервисов в Docker

[Gudsaf]

Ситуация: докер с 2-10 контейнерами, количество контейнеров изменяется динамически, в каждом контейнере развернуто одно и то же приложение, каждое приложение отдает один и тот же набор из одних и тех же пяти метрик. Простое горизонтальное масштабирование сервиса.

Проблема: надо собирать метрики и суммировать их по всем сервисам на выходе получая все тот же набор из 5 метрик, но только каждая метрика - сумма метрик полученных от приложений.

В общем как планирую решать задачу:
- сервисы уже отдают метрики через Prometheus, метрики в текстовом виде публикуются на localhost:8080/metrics
- сервисы надо будет научить авторегистрации в заббиксе: они будут регистрироваться при запуске приложения на сервере заббикса
- когда они будут регистрироваться, заббикс будет складывать их в специальную хост группу
- для данной хост группы будет настроен опрос метрик не чаще (важно) чем раз в 30 секунд
- так же будет сделана агрегация (суммирование) по метрикам в данной хост группе
- основная проблема, когда один из контейнеров сервиса динамически будет выключен: решаю при помощи триггера и действия,
- создам триггер который на базе функции nodata() будет с максимальной частотой (раз в 30 секунд) проверять были ли данные от инстанса микросервиса
- в действии укажу использовать ранее описанный триггер: когда триггер сработает хост будет удален из специальной хост группы
- суммирование будет уже идти по хост группе где нету "отвалившихся сервисов"


Выглядит как один огромный костыль.
Раскритикуйте, работоспособен ли такой подход, может есть что-то более правильное?

[Alex_UUU]

Имхо, задача делится миним на 2 этапа:
1. Дискаверингом определяешь какие докеры есть и создаешь прототипы метрик.
2. Вроде бы в последней (5.4? или уже в 6) разработчики изменили формулы триггеров, но добавили возможность создания расчетного элемента данных по однотиптым

[Gudsaf]

1. Дискаверингом определяешь какие докеры есть и создаешь прототипы метрик.

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

2. Вроде бы в последней (5.4? или уже в 6) разработчики изменили формулы триггеров, но добавили возможность создания расчетного элемента данных по однотиптым

Это конечно круто, текущая версия 5.4, но фраза "вроде бы добавили" конечно мало добавляет интереса к сказанному.

[Alex_UUU]

1. Я не ковырял авторегистрацию, но в дискаверинге есть время хранения данных. И например, если стоит 10 минут, то когда заббикс сделает новый дискаверинг, и там не будет ранее определенныхЮ он их пометит и через 10 минут удалит автоматом.
2. В 5.4 уже есть: https://www.zabbix.com/documentation...ated/aggregate

[Kos]

1. Я не ковырял авторегистрацию, но в дискаверинге есть время хранения данных. И например, если стоит 10 минут, то когда заббикс сделает новый дискаверинг, и там не будет ранее определенных, он их пометит и через 10 минут удалит автоматом.

Подозреваю, вы о разных дискаверингах говорите.
То, о чём говорит автор темы, - авторегистрация; из примерно той же оперы - сетевое обнаружение. Задача обоих - найдя нужный объект в живой сети, сделать для него объект "хост" в Zabbix-е.
То, о чём говорите Вы, больше похоже на низкоуровневое обнаружение (LLD), когда для уже существующего хоста создаются такие объекты как "элемент данных" и "триггер". Там действительно есть время хранения данных, только задать 10 минут нельзя: там минимум 1 час (либо ноль, если надо удалять сразу).

[Gudsaf]

1. Я не ковырял авторегистрацию, но в дискаверинге есть время хранения данных. И например, если стоит 10 минут, то когда заббикс сделает новый дискаверинг, и там не будет ранее определенныхЮ он их пометит и через 10 минут удалит автоматом.
2. В 5.4 уже есть: https://www.zabbix.com/documentation...ated/aggregate

не, дискаверинг не то, там временные ограничения не те совсем - удалять надо как только так сразу, без задержек.

Если удалять с задержкой, то есть риск на шаге агрегации метрики лишний раз посчитать метрику уже упавшего контейнера. Ну типа контейнер упал, а мы его не удалил из группы агрегации, и в этот момент производится опрос метрик, и последующая агрегация - в результате агрегации будет взято крайнее значение уже упавшего контейнера и это значение сложится с текущими значениями метрики из других контейнеров (а должно взять 0 или не взять вообще, чтобы не суммировать). Я еще сейчас смотрю API к заббиксу, может выйдет когда контейнер завершается - отправлять заббиксу информацию о том что он завершается, чтобы его там поудаляли из всяких агрегаций.

То, о чём говорит автор темы, - авторегистрация; из примерно той же оперы - сетевое обнаружение. Задача обоих - найдя нужный объект в живой сети, сделать для него объект "хост" в Zabbix-е.

Толко как я понял, заббикс не ищет в случае авторегистрации хост - наоборот хост сам приходит к нему и говорит что он есть, а дальше заббикс его начинает порашивать.

[Kos]

Только, как я понял, заббикс не ищет в случае авторегистрации хост - наоборот, хост сам приходит к нему и говорит, что он есть, а дальше заббикс его начинает опрашивать.

Да, именно так.
Моё замечание касалось того, что не надо путать дискаваринг сетевой и дискаверинг низкоуровневый - это разного плана процессы: один создаёт хосты, а другой - айтемы/триггеры.

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

Если при старте контейнера для него автоматом создаётся хост (через авторегистрацию, с добавлением в нужные группы), то по завершении работы контейнера было бы логично через API этот хост удалять (при этом из всех групп и, соответственно, завязанных на них агрегаций, Zabbix должен будет удалить сам).