Почему бы просто не использовать локальную конфигурацию?(а не обнаружение служб)
В настоящее время не нужно управлять списком служб для мониторинга вручную: слишком много служб, службы меняются слишком часто и т. д.
ТакжеВ настоящее время у нас обычно есть надлежащие инструменты управления конфигурацией (выберите любой из ваших любимых инструментов ... Docker, Kubernetes, Puppet, Ansible ...), которые обычно имеют центральный перечень услуг (на самом деле, не просто инвентарь, а описанияконфигурации и инструмент управления сверху вниз).
Возможны следующие варианты:
- Управление списком агентов вручную
- Решение для мониторинга имеет базу данных служб длямонитор: необходимо реализовать решение для синхронизации центральной инвентаризации с решением для мониторинга.
- Решение для мониторинга не имеет базы данных служб для мониторинга: мониторинг просто получает обновленный список служб из центральнойинвентарь (kubernetes, Puppet ... или CMDB для тех, у кого есть тот, который актуален).
Примечание. Прометей не намерен изначально поддерживать все возможные реестры сервисов.Вместо этого рекомендуется генерировать YAML или JSON , запрашивая ваш любимый реестр служб.
Обнаружение служб и дилемма Push-vs-Pull
Некоторые люди выступают за то, чтобы агенты мониторинга просто передавали метрики в платформу мониторинга, настроенную локально на сервере (т. Е. Выдвигали метрики, а не отключали от платформы мониторинга).Я не буду перефразировать всю дискуссию здесь (см. Push требует Service Discovery и Почему вы тянете, а не толкаете? )
Один из пунктов (БрайанБразилия из Robust-Perception) заключается в том, что мониторинг часто сводится к ПРОВЕРКЕ: проверке того, что вы знаете, что развернули, почему оно развернуто, как оно должно вести себя, почему оно должно вести себя определенным образом (какое приложение, какой шаблон используют ...),Таким образом, платформу мониторинга необходимо настроить со списком услуг и ожидаемым состоянием.