С распределёнными приложениями появляется проблема, которую обычно не приходится решать в монолитных: как узнать, что приложение работает нормально? Не в смысле выполняет бизнес задачи и радует сердца пользователей яркими иконками, а в принципе работает. Все ли ключевые сервисы запущены? Загрузка процессора и памяти в норме? Место на диске не закончилось? И так далее.
К счастью, во вселенной хватает инструментов, чтобы на такие вопросы отвечать, и collectd — один из них.
Что такое collectd
collectd — это очень маленький фоновый процесс, который собирает метрики откуда только может (процессор, диски, память, сенсоры, счётчики ОСи) и передаёт туда, куда скажут. Он работает только на никсовых системах, но есть и коммерческий виндовый родственник — ssc-serv. collectd не пытается быть умнее всех, поэтому практически вся его функциональность достигается за счёт плагинов.
Плагины collectd
Есть три основные группы плагинов:
Есть еще несколько мелких разновидностей плагинов, которые до группы не дотягивают. Например, есть network плагин, через который несколько collectd-процессов на разных хостах могут общаться друг с другом. Есть еще exec и python, с которыми можно написать шелл- или питон-скрипт и сделать свой сборщик метрик. Например, скрипт, который будет говорить сколько виртуальных машин запущено сейчас в Google Compute Engine (в моей зоне ответственности — от 3 до 132 одновременно, так что актуально). Наконец, есть пара плагинов для отправки уведомлений. Например, notify_email.
Но самые интересные плагины, конечно, это плагины для сбора и хранения метрик.
Плагины для сбора метрик
Для всего, что можно замерить у хоста, скорее всего уже есть collectd плагин. Есть плагины для CPU, памяти, диска, Apache/nginx, температурных датчиков, траффика, пинга, запущенных процессов, сенсоров, последовательного порта, SMART и всего остального. Хотя большинство плагинов выключены по-умолчанию, включить что-то назад — элементарно. В файле настроек ( /etc/collectd/collectd.conf ) достаточно просто раскомментировать нужный плагин и, собственно, всё.
1 2 3 4 5 6 7 8 9 10 11 12 |
#LoadPlugin dns #<Plugin dns> # Interface "eth0" # IgnoreSource "192.168.0.1" # SelectNumericQueryTypes false #</Plugin> LoadPlugin syslog <Plugin syslog> LogLevel info </Plugin> |
Плагины для хранения метрик
Это плагины, куда стекаются собранные данные. Их тоже навалом. Например, метрики можно хранить в CSV, RRDtool, AMQP-совместимой очередью сообщений (вроде RabbitMQ), Kafka, Carbon и Graphite, http, mongo, redis и несколько других.
Мониторинг нескольких хостов
В распределённом приложении серверов/сервисов обычно больше, чем один, и поэтому одновременно работающих collectd тоже будет несколько. Хранить собранные ими данные на разных машинах можно, но скорее всего неразумно. В идеале они должны стекаться в какое-то центральное хранилище, прямо под монитором с графиками. Вариантов же, как это сделать, хватает:
- Использовать network плагин. Одни collectd могут в него сохранять метрики, как в хранилище, в то время как кто-то другой будет из него читать, как из сенсора.
- Публиковать данные в AMQP-брокер сообщений, вроде RabbitMQ или ActiveMQ. Как и с предыдущим плагином, одни collectd могут публиковать туда собранные данные, а остальные (или остальной) их собирать.
- Публиковать данные в Carbon (подробности дальше).
Создание графиков
Собрать данные мониторинга в виде текста или бинарников, конечно, приятно, но абсолютно бесполезно. Ну не воспринимаем мы колонки цифр на глаз. Считывать информацию с графика намного проще. Но тут проблема — collectd не умеет рисовать. Вообще. В конце концов, в его названии есть только «собирать», а о рисовании там ни слова. Но есть выход, даже несколько.
- Для collectd есть collection3 и collectd-web вэб приложения, которые умеют рендерить RRD файлы с метриками. Честно говоря, я с опаской смотрю на всё, что в 2016-м содержит папку cgi-bin, но, в принципе, если оно работает, то почему бы и нет.
- И гугло-таблицы, и MS Office, и линуксовый офис — все умеют импортировать CSV и что-то рисовать из него. А CSV, генерируемый collectd, — прост до безобразия.
12345$ head ~/collectd/csv/myhost/memory/memory-free-2016-12-19#epoch,value#1482105608.337,398675968.000000#1482105618.337,398028800.000000#1482105628.338,398028800.000000 - Можно брать RRD (Round-Robin Database) файлы и натравливать на них rrdtool. Про RRDtool вообще стоит написать отдельный пост, настолько эта штуковина прекрасна. По-умолчанию collectd хранит данные именно в RRD, да и устанавливается вместе с rrdtool. А последний, кроме управления RR-базами, умеет рисовать и графики по ним. Много графиков. Утилитка работает из командной строки, так что её запросто использовать из скриптов, а миллион входящих параметров может превратить из графика конфетку. У меня, правда, пока получается только такое:
- Carbon и Graphite-web — это сервис для сбора временных рядов данных (например, как менялся объём используемой памяти в течение дня) и его фронт-энд с графиками. collectd и Карбон замечательно дружат через плагин, а Графит понимает, как организовать входящий поток данных по категориям.
Установка (это вместо заключения)
Да, collectd можно устанавливать, и это просто. Чтобы собрать его из сырцов есть инструкция (скачать, распаковать, ./configure, make), а в убунтоподобных системах сработает apt-get install collectd . После установки сервис запуститься автоматически и с разумным набором включённых плагинов, так что поиграть с данными можно сразу. В Docker контейнерах, кстати, он тоже отлично работает.
С графиками чуть сложнее. Кривая обучения у rrdtool не такая крутая, как у vim, но подумать придётся. Вэб фронт-энды тоже устанавливаются не элементарно. С другой стороны, если один раз разобраться, то навык тут же прошивается в спинно-мозговые рефлексы, и его уже не забыть.