Кто же устережёт самих сторожей?, или как (и зачем) я мониторю мониторинг.
Как вы понимаете, современный сервис мониторинга это очень сложная штука. Некоторые, как Sensu, выносят всю сложность во внешние сервисы, и потому требуют установки и администрирования нескольких компонентов, таких как очередь и база данных.
Остальные реализуют некоторый функционал этих компонентов сами, упрощая администрирование мониторинга, но усложняя его внутреннее устройство. К примеру, для работы Zabbix нужна только база, а очереди и транспорт он реализует сам. Для работы Icinga2 даже база не нужна, пока не возникнет надобность в тесной интеграции с веб-интерфейсом.
В любом случае, чтобы быть уверенным в том, что сам мониторинг работает, приходится настраивать мониторинг мониторинга.
Мой опыт
В моей практике так сложилось, что на проектах всегда была пара служебных серверов, выполняющих роль DNS-сервера, локального репозитория и т.п. На одном из них как раз и размещался мониторинг.
В давние времена, когда я использовал Zabbix, на втором сервере также был установлен Zabbix-сервер, который мониторил соседа, и в случае его смерти принял бы последний дамп его базы (увы, для Zabbix очень сложно перенести все настройки без dump-restore базы). Таким образом, оба Zabbix-сервера мониторили друг-друга, и я был относительно спокоен.
Теперь, когда я использую Icinga2, которую полностью разворачиваю вместе с конфигами из Ansible за пару минут, нет смысла держать второй такой сервер.
Поэтому для мониторинга Icinga2 я выбрал гораздо более простой (и потому более надежный) сервис Monit. У него очень мощный, и при этом хорошо читаемый формат конфигов, и у меня с ним был отличный опыт на личном VPS.
Теперь мое спокойствие обеспечивает следующая конфигурация:
- на сервере мониторинга Monit следит за тем, что Icinga2 жива
check process icinga2
with pidfile /var/run/icinga2/icinga2.pid
mode passive
- на соседе Monit следит, что сервер мониторинга жив
check host monitoring with address monitoring.example.com
if failed icmp type echo count 5 with timeout 15 seconds then alert
Ну и конечно Icinga2 следит за тем, что оба процесса Monit на серверах живы.
Проще не придумаешь, и потому я даже более спокоен, чем в схеме с двумя Zabbix-серверами.
Если вам эта схема кажется параноидальной - вы абсолютно правы, определенная степень паранойи это необходимая часть профессии сисадмина. Очень неприятно узнать о том, что мониторинг упал с Segfault пару дней назад, и из-за этого ты пропустил несколько важных алертов с боевых серверов.
UPDATE
Забыл рассказать про схему, которую использовал с Sensu. Там было лучше всего - я использовал кластер из RabbitMQ с durable очередями и Redis с auto failover. А сам Sensu отлично умеет масштабирование и HA с несколькими серверами из коробки.
Ну и насколько это было нужно, из личного опыта, в реторспективе:
- Zabbix падал, и второй хост это засекал;
- Sensu падал, и второй хост это засекал;
- Icinga2 пока не падал.