collectd: используем JavaScript для сбора метрик

Exec плагин

Среди всего разнообразия плагинов в collectd есть один особенный: если из-за какой-нибудь техногенной катастрофы у collectd останется только Exec, то им вполне можно заменить все остальные.

Как следует из названия, Exec запускает стороннее приложение или скрипт и интерпретирует её вывод в качестве данных для себя. Если быть точным, то он ищет строки вроде таких:

Что самое прекрасное, Exec абсолютно по барабану, на каком языке написан скормленный ему скрипт.  Хоть на JavaScript. В принципе, в некоторых сценариях использовать JavaScript было бы очень хорошей затеей. Например, когда приходится иметь дело с RESTful сервисом возвращающим JSON.

Но прежде чем мы попробуем скормить collectd данные из JavaScript приложения, стоит присмотреться поближе к формату PUTVAL-строк.

Аргументы для PUTVAL

Формат PUTVAL строк очень многое позаимствовал из rrdtool. Он использует те же типы данных, те же временные метки, даже синтаксис, и тот очень похож. Обобщённый формат выглядит так:

Первый аргумент — строка вида  hostname/source-instance/datatype-instance , может быть чем угодно, если она однозначно идентифицирует источник данных. -instance-компонент, кстати, опционален. Правда, у   datatype  есть некоторые ограничения.

datatype задаёт, какого типа данные мы пытаемся скормить collectd, и как он должен их хранить. У  rrdtool есть две группы типов: счётчикоподобные (COUNTER и компания), для сохранения не самого значения, а скорости, с которой оно меняется, и обычные, численные (GAUGE), которые сохраняются как есть. PUTVAL понимает эти типы, и мы можем использовать, например, тот же   gauge для хранения чисел между 0 и 2^32.

Кроме них у collectd есть собственные типы, которые он определяет в   /usr/share/collectd/types.db . Например, там есть   temperature (тот же gauge, но от минус до плюс бесконечности), count (gauge, от нуля до бесконечности), и уйма других. Эти тоже можно использовать, или даже добавить свой.

Вторым аргументом в PUTVAL подаётся   interval в секундах. Он опционален и показывает, как часто мы планируем подавать новые значения.

Наконец, в конце идут разделенные двоеточием timestamp и value.  timestamp , временная метка, может быть либо юниксовым временем в секундах, либо  N в качестве «сейчас». А  value  — просто число, либо   U  для «undefined«.

Подаём данные из JavaScript в collectd

Предположим, у нас есть очень полезное JavaScript приложение  sensor.js , которое собирает данные мониторинга чего-то (количество пользователей онлайн, например), и мы хотим их передавать в collectd.

С чего начинать?

1. Делаем sensor.js исполняемым

Во-первых, нужно, чтобы скрипт запускался. А чтобы скрипт запускался, ему нужно дать пермишен ‘execute’ (линукс же вокруг), а так же шебанг, чтобы никса знала, как именно его исполнять. chmod +x sensor.js  исправит первый недостаток, а node.js в шебанге разберется с запуском:

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

Следующем шагом будет офорить эту полезность в формат, понятный collectd.

2. Форматируем вывод для collectd

Для этого нужно собрать PUTVAL строку. Думаю, для начала вполне сойдёт что-то вроде этого:

Мы используем   gauge тип («храни числа как есть») и «сейчас» ( N) в качестве временной метки. Опциональный   Interval параметр так и остался опциональным.

Правда, у нас жёстко прошито имя хоста ( hostname/ ), да и данные-то предполагалось подавать регулярно, а не раз в вечность.

Но это можно исправить.

3. Используем имя и интервал прямиком из collectd

Когда collectd запускает скрипт, он так же создаёт две переменные окружения: COLLECTD_HOSTNAME и COLLECTD_INTERVAL, которые мы вполне можем использовать. Ну и так как данные будут подаваться регулярно,   Interval  параметр всё-таки стоит указывать. Вот, в итоге, что у нас получилось:

И если запустить его руками:

То, что нужно. Но запускать его руками не было частью плана. Будем аутсорсить привилегию в collectd.

4. Подключаем sensor.js к collectd

Это, кстати, очень просто сделать. Раскомментируем строки Exec плагина в файле настроек —   /etc/collectd/collectd.conf , и укажем в нём, где лежит sensor.js:

Кстати, использовать   root пользователя в конфигурации Exec нельзя. Он не простит.

4.1 Пробный запуск

Теперь, если мы перезапустим collectd, первым знаком, что всё хорошо, будет отсутствие ошибок со словом ‘exec’ в них:

Пока хорошо. Правда, отсутствие ошибок не значит, что всё хорошо, так что стоит проверить, сохранил ли collectd хоть что-нибудь. По умолчанию, он хранит все свои данные в RRD файлах по этому адресу  /var/lib/collectd/rrd . Если там есть что-то от mysensor (название, которое мы указали в PUTVAL), то это вин:

Да, тотальный вин.

Итак

Как оказалось, использовать JavaScript для подачи данных в collectd — очень просто. И кроме «У-у-у, теперь я сделал это и на JavaScript!», существуют и разумные для того причины. В наши суровые времена очень много полезных с точки зрения мониторинга данных берутся из RESTful сервисов в JSON формате. Использовать JavaScript для работы с ними — сам Айк велел.

Я использовал связку JavaScript (node.js) + collectd + Graphite  для мониторинга continuous integration серверов и остался очень доволен. GitLab и Google Compute Engine идут в комплекте с прекрасным JSON API, поэтому получать данные о количестве виртуальных машин, билдов и тестируемых веток — одно удовольствие. Всего за несколько часов, включая время на кофе и Гугл, получилась вот такая полезная красота: