Sensu — фреймворк для мониторинга

Немного истории

В 2011 году в DevOps-среде возникло движение, объединившееся под хештегом #monitoringsucks, и критиковавшее существующие системы мониторинга за отсутствие гибкости. Что именно их не устраивало — прекрасно иллюстрирует эта презентация.
Если вкратце — хочется людям некоего стандарта API для взаимодействия между компонентами мониторинга, ну и появления самих этих компонент, чтоб из них строить гибкий и умный мониторинг.

Итогом этой волны недовольства стали массовые обсуждения проблем и привлечение внимания к интересным утилитам типа Sensu и Riemann.

В 2013 году хештег в сообществе сменился — теперь это #monitoringlove. Произошло это благодаря развитию opensource-утилит для мониторинга.

Из новых утилит наибольший интерес представляет Sensu. Riemann я не стал всерьез рассматривать, поскольку на данный момент у него нет никаких средств для обеспечения отказоустойчивости, да и сама идея писать конфиг на Clojure мне не сильно нравится.

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

Основные факты о Sensu:

* Написан на Ruby, использует EventMachine (я бы предпочел Python, но ладно).
* Конфиги в JSON
* Может использовать плагины от Nagios.
* Работает через RabbitMQ, в PUSH-режиме, когда клиенты сами шлют серверу
результаты проверок по мере готовности.
* Есть пакеты DEB, RPM и даже MSI.
* Есть модули для puppet и cookbook для Chef.

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

Система состоит из трех основных компонентов: sensu-server, sensu-api, и на клиентах sensu-client. Также доступна sensu-dashboard. Установка тривиальна и подробно освещена в документации, для последней на данный момент версии 0.12 она доступна тут. Как я уже упоминал, есть deb, rpm и msi пакеты.

Базовые понятия

Для того, чтобы понять, как все это работает, надо разобраться в терминологии. Я не ставлю целью перевод официальной документации, а хочу дать базовые понятия, чтоб было понятно, о чем будет в дальнейшем идти речь.

У нас есть следующие сущности:

Клиент (Client)

Это некий сервер с установленным и настроенным sensu-client, который публикует информацию о себе в RabbitMQ и таким образом регистрируется в системе мониторинга Sensu. От сервера Sensu он получает набор проверок, и выполняет их, складывая результат в RabbitMQ.

Для самоидентификации ему нужна конфигурация, которая выглядит примерно так (взято из документации):

{   "client": {     "name": "i-424242",     "address": "127.0.0.1",     "subscriptions": [       "production",       "webserver",       "mysql"     ]   } } 

Все довольно очевидно, за исключением «подписок» (subscriptions). Подписки представляют собой список ролей, ассоциированных с этим сервером, и определяют список выполняющихся на нем проверок. Более тонкая настройка описана в официально документации, из полезного можно добавить любые поля, значения из которых можно будет использовать в проверках, а также интервал времени, который должен пройти для генерации события об уходе клиента в оффлайн.

Проверка (Check)

Проверки определяют команды, которые будут запускаться на клиентах, и их параметры. Полностью совместимы с плагинами Nagios, т.е. используют exit code как критерий успешности проверки, а STDOUT или STDERR как источник данных. Проверки настраиваются в конфигурации sensu-server, типичная проверка выглядит так (пример из документации):

{   "checks": {     "chef_client": {       "command": "check-chef-client.rb",       "subscribers": [         "production"       ],       "interval": 60       "handlers": [         "pagerduty",         "irc"       ]     }   } } 

Из интересного тут опять-таки подписки и хендлеры. Подписки определяют, на каких клиентах будет эта команда запущена.

А набор хендлеров определяют список команд, которые будут выполнены при обработке данных от этой проверки. О них мы дальше поговорим.

Стоит отметить, что проверка может быть «метрикой» (metric), т.е. данные из ее STDOUT будут всегда просто передаваться в хендлеры. Таким образом можно слать данные метрик куда-нибудь для хранения или рисования графиков (например, в Graphite). Подробности в документации.

Хендлеры (Handlers)

Хендлеры определяют команды, которые будут запускаться на сервере мониторинга при поступлении данных от проверок, и их параметры. Например, этот хендлер при получении от какой-либо проверки не-нулевого exit code выполнит команду mail -s 'sensu event' email@address.com (пример из документации):

{   "handlers": {     "mail": {       "type": "pipe",       "command": "mail -s 'sensu event' email@address.com"     }   } } 

Тут все очевидно, хендлеров в репозитории плагинов куча. Можно слать в Pagerduty, и письма отправлять, и в Graylog2 слать в gelf. Подробности в документации.

Всего вышеперечисленного уже достаточно, чтобы соорудить работающую систему. Есть еще мутаторы, расширения и API, но это нам сейчас не важно.

Приступаем к самому интересному

Sensu позиционируется именно как «фреймворк для мониторинга», и это значит, что «из коробки» в нем ничего привычного по энтерпрайз-системам типа Zabbix нет. Вся функциональность добавляется благодаря плагинам.

Попробуем сделать что-нибудь полезное. Возьмем простую задачу — выполнять проверки относительно Redis на клиентах, в случае проблем выводить алерт на панель Dashing, а также для истории слать сообщение в Graylog2 и email на адрес admin@example.com. А еще снимать метрики с Redis и отправлять на хранение в Graphite, а потом по агрегированным значениям keys тоже выполнять проверки.

Клиенты имеют адреса 192.168.1.2N, Graphite развернут на 192.168.1.80:8082, RabbitMQ и Redis тоже на 192.168.1.80. Graylog2 слушает на 192.168.1.81, там же развернута Dashing.

Конфигурация

Начнем с конфигурации клиентов.

Допустим, у нас есть N серверов в роли redis.

Конфигурация клиента выглядит так:

/etc/sensu/config.json

{   "client": {     "graphite_server": "192.168.1.80:8082",     "address": "192.168.1.2N",     "name": "clientN",     "subscriptions": [       "redis"     ]   }   "rabbitmq": {     "vhost": "/sensu",     "host": "192.168.1.80",     "password": "password",     "port": 5672,     "user": "sensu"   } } 

и размещается на каждом из N клиентов.

Все остальные файлы конфигураций только на сервере Sensu.

Основные настройки:

/etc/sensu/conf.d/settings.json

{   "api": {     "host": "192.168.1.80",     "port": 4567   },   "redis": {     "host": "192.168.1.80",     "port": 6379   },   "rabbitmq": {     "vhost": "/sensu",     "host": "192.168.1.80",     "password": "password",     "port": 5672,     "user": "sensu"   },   "mailer": {     "mail_from": "sensu@example.com",     "smtp_port": "25",     "mail_to": "admin@example.com",     "smtp_address": "localhost"   },   "dashing": {     "auth_token": "YOUR_AUTH_TOKEN",     "host": "http://192.168.1.81:8088"   },   "gelf": {     "server": "192.168.1.81"     "port": "12201",   } } 

Как вы видите, мы настроили не только сам Sensu, но и параметры для хендлеров dashing, gelf и mailer.

Теперь определим сами эти хендлеры:

/etc/sensu/conf.d/handlers.json

{   "handlers": {     "default": {       "type": "set",       "handlers": [         "mailer",         "dashing",         "gelf"       ]     },     "gelf": {       "type": "pipe",       "command": "/etc/sensu/handlers/gelf.rb"     },     "mailer": {       "type": "pipe",       "command": "/etc/sensu/handlers/mailer.rb"     },     "dashing": {       "type": "pipe",       "command": "/etc/sensu/handlers/dashing.rb"     },     "graphite": {       "mutator": "only_check_output",       "type": "amqp",       "exchange": {         "durable": true,         "type": "topic",         "name": "metrics"       }     }   } } 

Тут все просто. Заметьте, что в Graphite мы данные шлем через AMQP. Хендлеры надо разложить на сервере мониторинга в /etc/sensu/handlers.

Теперь настроим проверки, которые будут выполняться на клиентах:

/etc/sensu/conf.d/checks.json

{   "checks": {     "redis_processes": {       "interval": 60,       "command": "/etc/sensu/plugins/processes/check-procs.rb -p redis -c 8 -C 0 -w 7 -W 1",       "subscribers": [         "redis",       ],       "handlers": [         "default"       ]     },     "redis_memory": {       "dependencies": [         "redis_processes"       ],       "command": "/etc/sensu/plugins/redis/check-redis-memory.rb -c 204800 -w 51200",       "interval": 60,       "subscribers": [         "redis",       ],       "handlers": [         "default"       ]     },     "redis_metric": {       "handlers": [         "graphite"       ],       "interval": 60,       "dependencies": [         "redis_processes"       ],       "command": "/etc/sensu/plugins/redis/redis-graphite.rb --scheme stats.:::name:::.redis",       "subscribers": [         "redis",       ],       "type": "metric"     },     "redis_keys_from_graphite": {       "interval": 60,       "command": "/etc/sensu/plugins/graphite/check-data.rb -s :::graphite_server::: -t stats.:::name:::.redis.db0.keys -w 500 -c 900 -a 120",       "subscribers": [         "redis"       ],       "dependencies": [         "redis_processes"       ],       "handlers": [         "default"       ]     }   } } 

Проверки осуществляются плагинами Sensu, которые надо разложить на клиентах в /etc/sensu/plugins. Для знакомых с Nagios тут ничего нового, интересна только метрика redis_metric, из которой мы в Graphite данные кладем, а потом в проверке redis_keys_from_graphite достаем и проверяем данные за последние 10 минут. Вообще, почти каждый плагин имеет ключ —help, который выдает вполне вменяемую справку по использованию.

Вот и вся конфигурация. Все наглядно, все можно хранить в репозитории, и это прекрасно.

Конечно, надо настроить еще Dashing и Graphite, но это я оставлю за рамками статьи. Инструкция по настройке Sensu + Graphite можно найти тут, а с Dashing все и так понятно.

А еще у Sensu есть простенький dashboard, на котором можно увидеть список клиентов, проверок, и сработавших алертов. Через API и с помощью dashboard можно выключать генерацию алертов для любых хостов или проверок, а также видеть общее состояние системы.
Выглядит он как-то так (скрин не мой):

Выводы

Как мы видим, Sensu берет на себя только роль маршрутизатора и организатора, а вся грязная работа делается внешними программами. Это позволяет сохранять небольшой размер исходного кода, и общую простоту системы. Регистрация клиентов через RabbitMQ позволяет избавиться от механизма «обнаружения» клиентов, что особенно удобно для облаков. Масштабируется все очень просто, пример HA + load balancing можно увидеть тут.

Я использую Sensu в продакшне, параллельно с Zabbix, уже около месяца, ну и в тестовом варианте пару месяцев использовал. Гибкость Sensu позволила настроить мониторинг ключевых параметров и метрик проекта с выводом на панель Dashing, в то время как Zabbix я использую уже очень давно, и занимается он сейчас более комплексным мониторингом. В общем, для многих проектов, особенно в облаках, Sensu будет прекрасным выбором, поскольку дает возможность гибко маршрутизировать события, а также хорошо приспособлен к динамической натуре облаков. В презентациях я встречал цифры в тысячи серверов под наблюдением Sensu, так что с производительностью проблем нет.

В заключение хочу указать на минусы и плюсы Sensu (все IMHO):

Минусы Sensu

• Имеющиеся хендлеры уведомлений куцые по настройкам. Это сейчас главный минус, если вы не пользуетесь сервисами типа PagerDuty. Единственное решение — писать свой хитрый хендлер.
• Конфиг в json, а не в yaml.
• Нужен внешний хранитель метрик, он же рисователь графиков.
• Не слишком полная документация. К счастью, проект простой, можно разобраться, просто читая код.

Плюсы Sensu

• Конфиг можно хранить в git, раскладывать все с помощью Chef/Puppet.
• Масштабируемость.
• Отказоустойчивость.
• Гибкость выбора системы хранения данных.
• Поддержка плагинов Nagios.
• Авто-подключение клиентов.
• Механизм подписок.
• Данные публикуются клиентами по мере генерации.
• Результаты проверок можно гибко направлять в разные хендлеры.