Мониторинг через Sensu

Один из моих проектов требует распределенной по миру инфраструктуры, которая должна работать 24x7. Понятно, что не всегда всё работает как надо и самым простым способом понять, что происходит с системой является мониторинг.

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

  • Конфигурация храниться в БД, что создает неудобства для бекапа и копирования конфигов
  • Для настройки и эксплуатации надо использовать не вполне очевидный веб-интерфейс

В качестве альтернативы мы рассматривали nagios-образные системы, в именно:

  • nagios - устаревшая нерасширяемая система с откровенно страшным интерфейсом,
  • ichinga2 - улучшенный форк nagios, в котором устранено ряд проблем, но интерфейс по прежнему сложен и запутан,
  • shinken - реализация тех же идей на Python,
  • sensu - реализация тех же идей на Ruby с использованием RabbitMQ как коммуникационного протокола

Последние два привлекли меня минималистичностью реализациии и возможностью легкого скриптинга. Поэтому дальше я исследовал исключительно их.

Выбор между Shinken и Sensu пал на Sensu потому, что настроить его для мониторинга Windows (а это более половины всей моей инфраструктуры) показалось проще.

Концепция работы у sensu построена на следующих сущностях

  • server - компонент, которые управляет исполнением проверок с использованием расписания из его конфига. В системе один.
  • client - компонент, который исполняет проверку по внешней команде и отправляет результаты запросившему. В системе может быть сколько угодно.
  • check - проверка, программная логика проверки, оформленная в виде исполняемоего файла. Проверки не распространяются по клиентами средствами sensu, эта работа “ложится” на администратора
  • uchiwa - веб-интерфейс для визуализации состояния проверок. Позволяет только “скрыть” проблему, которую выявил мониторинг.

Установка на большинство систем делается через стандартные репозитории, предоставляемыми разработчиками проекта. Кроме самой Sensu на практике полезно использовать репозиторий “проверок” sensu-community-plugins, которые пишутся сообществом. Я считаю, что лучше писать все проверки на Ruby, т.к. исполняться они будут в стабильной с точки зрения конфигурации среде интерпретатора Ruby, которые поставляется с sensu-client.

У системы есть ряд недостатков

  • надо заботиться о доставке проверок. Я решил эту проблему за счет использования salt и развертывания всего через него.
  • для обеспечения безопасности надо шифровать соединение с RabbitMq, что немного усложняет установку клиента
  • все настройки редактируются через конфиг сервера (это удобно) и требуют перезапуска сервера для применения изменений (а вот это неудобно)
  • глубина истории проверок - всего 10 проверок. Если вам надо выяснить что-то про вчерашний день - придется использовать что-то еще. Например flapjack.
  • в системе вообще нет ничего для построения графиков, для этого можно использовать внешнюю систему типа graphite. У меня так и сделано - метрики систем собираются через sensu, а помом отправляются в graphite.

Но пока эти недостатаки не мешают мне пользоваться легковесной системой Sensu.

Written on October 26, 2014