Мониторинг (отслеживание состояния сервисов), наряду с резеврным копированием является, наверное, одной из самых старых и популярных задач для системного администратора. Разумеется, существует великое множество различных инструментов для ее выполнения. В этом развесистом великолепии с трудом ориентируются даже бывалые специалисты. В данном тексте я собрал основные системы мониторинга с кратким описанием и сравнением плюсов, минусов и особенностей. Разумеется, статья не претендует на всеобъемлющее описание всех систем мониторинга планеты (их слишком много), но поможет хотя бы соориентироваться и понять, куда искать.

Monit

Достаточно древняя разработка. Официальный слоган - That barking on daemons. Работает строго локально, самостоятельный демон, написан на C. Расширяемость нулевая - плагины не поддерживает. Основная задача - отслеживать работу демонов и перезапускать умершие, зависшие или вышедшие за квоту ресурсов. Обладает довольно своеобразным конфигом (не похож ни на что вообще). Не смотря на нулевую расширяемость в базе имеет большую часть необходимых проверок. Может проверять процесс по факту наличия, занимаемые ресурсы, подключаться к процессу (по сети или сокету), проверять ответ от сервера (на факт наличия, а так же на содержание), проверять соотвествие определенным протоколам (HTTP, FTP, POP/IMAP/SMTP - полный список смотреть в документации). Поддерживает работу с SSL, имеет встроенный веб-интерфейс. Проверка производится по расписанию, раз в определенное время. По результатам проверки может принимать определенные решения (прибить процесс, перезапустить, уведомить админа). Прост, надежен как автомат Калашникова. В активе компании-автора есть многосервисная платная система M/Monit - для управления группами сервров, но с ней я не сталкивался.

Munin

Не смотря на то, что изначально этот проект создавался для рисования графиков, он может служить и мониторинговой системой (так, как имеет в базе систему уведомлений). Строго клиент-серверная система, на целевых узлах запускается процесс-клиент. Процесс-сервер подключается к клиентам по расписанию и собирает числовые данные (метрики), складирует их у себя и отрисовывает графики. Он же отвечает за уведомления - интеллект клиента у мунина близок к нулю. Легко расширяется: строго говоря, все метрики munin рисует, используя данные плагинов (без плагинов метрик не будет). Плагины легко пишутся - язык произвольный, так как мунин ожидает только числа (данные) метрик в определенном формате и код ответа. В силу своей архитектуры monit не способен производить действий на клиентских узлах (например - перезапускать зависший процесс). Язык написания самого демона - перл.

Ganglia

Достаточно старый инструмент, созданный в CERN. Писали ученые и для ученых, а потому инструмент своеобразный. Основное назначение ганглии - сбор данных о производительности большого количества однотипных машин (вычислительные кластеры). Обладает производительностью, поражающей воображение (десятки тысяч наблюдаемых узлов на очень среднем сервере), но трешхолд довольно большой (данные собираются отложенно, так что если надо смотреть нагрузку в реальном времени - это не к нему. Клиент-серверная архитектура: клиент собирает данные, аккумулирует их у себя и раз в определенное время отсылает на сервер. В случае, если какая-то метрика перешагнула пороговое значение, ответ будет отправлен вне очереди. Сервер собирает данные со всех клиентов, аггрегирует их и сохраняет в базе. Веб-интерфейс живет отдельным компонентом, он связывается с сервером по внутреннему протоколу и отображает различные графики. В силу специфики ганглии интерфейс очень необычный, но прекрасно подходит для сравнительного анализа данных с групп серверов (например, построение графика зависимости нагрузки на CPU сервера 10 от сетевой нагрузки на сервера с 50 по 90 делается в два клика мышью). Ганглия расширяема, но написание плагина представляет из себя нетривиальную задачу - дело в том, что с точки зрения ганглии, плагин - это библиотека. Это накладывает требования на язык реализации плагина (только C или Python) и внутреннюю структуру кода (описано в документации). Сами демоны написаны на C, веб-интерфейс - на PHP. Обладает очень корявой системой уведомлений, чаще всего ганглию скрещивают с Исингой (см ниже)

Nagios / Icinga

Довольно древний инстурмент, изначально назывался Nagios (автор - Этан Галстадт). В процессе разработки в стане разработчиков произошел раскол и появился форк (Icinga). Сейчас эти системы развиваются самостоятельно, но общего в них много больше, чем разницы. Nagios существует в бесплатной (core) и платной редакциях, Icinga - честный Open source. Изначально серверно-ориентированный демон на голом С, управление демоном ведется через C-подобный конфиг (внешне напоминает конфиг ISC BIND). Все проверки собираются в живую очередь и выполняются в строгой очередности. Это налагает определенные ограничения на масштабируемость - сервер удержит большое количество проверок без труда, но чем их больше, тем больше времени проходит между ними. По личному опыту, пара тысяч проверок (400 серверов х 5 проверок на сервер) делает систему мониторинга практически бессмысленной - между проверками проходит слишком много времени. В качестве опции существует приложение-клиент под названием NRPE, он позволяет проводить проверку локально, на клиенте (для тех случаев, когда проверить сервис удаленно невозможно), но это именно опция. Кроме того, проверки через клиента проводятся по инициативе сервера, так что на масштабируемость это никак не влияет. Nagios очень хорошо расширяется, плагины пишутся очень просто (и существует их великое множество). Nagios славится мощной и гибкой системой уведмолений - в базе она умеет писать письма и слать смс и сообщения на пейджер, но есть целый набор плагинов - от автоматического звонка голосом до светофора (не фигурально, а буквально - управляется эта радость через ModBus). Icinga имеет два веб-интерфейса на выбор - классический CGI и более современный на PHP. Субъективно CGI удобнее, хотя и менее гибок. Прародитель (nagios core) имеет только CGI-версию интерфейса. Важно отметить, что nagios не умеет и не желает собирать статистику ответов, соответственно ждать от нее красивых графиков в стиле Munin/Ganglia/Cacti бессмысленно. Существует мост для связи Icinga с Ganglia, это довольно популярный тандем, в котором Icinga отвечает, в первую очередь, за карту сети, обзор хостов и уведомления.

Cacti

Изначально этот инструмент позиционируется для быстрой и простой сборки статистики по SNMP, но, с применением плагинов (notify + treshold) он обретает возможности системы монитоинга. Это PHP-приложение, настройки и конфигурации хранятся в базе MySQL (статистика хранится в RRD, что благотворно сказывается на производительности сервиса). Очень простая установка и первичная настройка (все делается через веб), в целом неплохо масштабируется (особенно, если применять костыли вида spine - многопоточного SNMP-опросника), большое количество базовых шаблонов для проверки различных типов устройств. Основной минус приложения - в его SNMP-центричности. Данный сервис хорошо подходит для сбора данных с активного оборудования, терпимо - для сбора типичной статистики работы сервиса (дисковое пространство, загрузка CPU etc) и отвратительно - для сбора сложных и нетипичных метрик. Кастомизация плохая.

OpenNMS

Старший брат сервиса, рассмотренного выше. Это сложный, многокомпонентый “комбайн”, написанный на Java (собственный app-server, томкат не нужен), ориентированный на большие инфраструктуры с передачей статистики по SNMP. Большая сложность и гибкость сервиса превращают настройку в нетривиальное дело - для некрупных инфраструктур этот сервис явно избыточен. Так же, как и cacti, сервис придуман для работы с SNMP, а значит, основное применение сервиса - это мониторинг сетевых устройств. Сервис страдает практически полным отсутствием документации и очень плохо расширяем (по сути это монолитное java-приложение, внутренние настройки живут в виде неудобочитаемых XML-файлов, что превращает нетривиальную настройку в пытку).

Graphite + CollectD + Whisper

Каждый компонент этого набора сам по себе не решает проблему мониторинга. Если все выше перечисленные продукты - это готовые решения уровня “сел и поехал”, то эта солянка больше напоминает мебель из IKEA (с той только разницей, что из этого набора с равной вероятностью можно собрать стол или подводную лодку). Фантастический неудобные файлы конфигурации, низкая стабильность кода (версии вида 0.1.192-alpha - нормальное дело) и тотальное отсутствие документации с лихвой компенсируется скоростью работы и масштабируемостью. Если вам надо собирать данные с серверной фермы класса github и видеть данные в практически реальном времени - вы нашли свой инструмент. Как и всякий молодой, сложный и специфичный инструмент - эта связка требует очень серьезной доработки до нужного состояния. Но. Эта штука работает быстро, действительно, ‘‘невероятно’’ быстро.

Zabbix

Авторы этого инструмента при разработке брали примером серьезные системы мониторинга enterprice-класса. По сути - zabbix - это мониторинг enterprice-класса, но при этом он opensource. Обладает трехзвенной архитектурой (сервер-прокси-клиент, прокси опционален, но помогает снизить нагрузку), данные хранит в SQL, веб-интерфейс - полностью самостоятельное приложение на php. Сами демоны мониторинга написаны на C/C++. Все настройки так же хранятся в базе данных, а меняются через веб. Система обладает на редкость развесистым функционалом и покрывает любые, даже самые безумные “хотелки”. Множество различных проверок, графики “от чего угодно и куда угодно”, эскалации проблем и отслеживание SLA, app-level проверки, имитация хождения пользователя по сайту (с поддержкой javascript, cookies, GET/POST/PUT), карты и схемы, настраиваемые панели (dashboards) с любыми метриками на выбор. Система имеет свой API, распределенную модель прав доступа, умеет кластеризоваться для снижения нагрузки на узлы, умеет шаблоны проверок. В отличае от большинства перечисленных выше систем, zabbix может производить действия на клиентах (например - перезапустить определенный процесс), что дает множество интересных перспектив. Система прекрасно расширяется и очень гибко настраивается. Разумеется, не обходится и без дегтя, и главный бочонок сидит в SQL. Дело в том, что в SQL заббикс хранит абсолютно все - настройки, статистику, метрики, узлы. Активно работающий zabbix выедает IOPS с поражающей воображение скоростью, админы судорожно пьют корвалол и читают database performance optimization guides (что помогает, впрочем, мало) - или молятся на свой data storage. Несколько помогает снижение количество метрик и частоты их сбора, но это снижает пользу самой системы мониторинга (какой смысл в системе мониторинга, если она не мониторит?). Дополнительная пара ложек дегтя прячется в сложности zabbix. Черезвычайно гибкая по сути, система очень непроста в установке (даже с учетом того, что у нее прекрасно написана документация, в ней освещены практически все вопросы). Внедрение заббикса с нуля свободно может занять месяц труда администратора, а оптимизация под задачи бизнеса и вовсе процесс практически вечный. В целом - это хороший вариант для крупного бизнеса, которому нужны специфичные метрики (и который готов платить за столь масштабное внедрение). Затратив прорву времени, сил и денег (на оборудование), босс получает возможность одним взглядом окинуть всю инфраструктуру и сразу понять, где проблема.