Кто же устережёт самих сторожей?, или как (и зачем) я мониторю мониторинг.

Как вы понимаете, современный сервис мониторинга это очень сложная штука. Некоторые, как Sensu, выносят всю сложность во внешние сервисы, и потому требуют установки и администрирования нескольких компонентов, таких как очередь и база данных.

Остальные реализуют некоторый функционал этих компонентов сами, упрощая администрирование мониторинга, но усложняя его внутреннее устройство. К примеру, для работы Zabbix нужна только база, а очереди и транспорт он реализует сам. Для работы Icinga2 даже база не нужна, пока не возникнет надобность в тесной интеграции с веб-интерфейсом.

В любом случае, чтобы быть уверенным в том, что сам мониторинг работает, приходится настраивать мониторинг мониторинга.

Мой опыт

Yo Dawg

В моей практике так сложилось, что на проектах всегда была пара служебных серверов, выполняющих роль 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 пока не падал.

Comments

comments powered by Disqus