Всем доброго времени суток!

Эта серия статей призвана рассказать Вам о написании собственных мониторов/сенсоров для системы мониторинга Munin. На протяжении нескольких статей мы с Вами попробуем создать плагин Munin для удаленного контроля температур и напряжений на VMware ESXi хосте с использованием утилиты esxcli.

Для начала, прежде чем переходить непосредственно к мониторингу ESXi, я бы хотел коротко и максимально просто рассказать Вам об этой системе. Пример изложенный ниже касается мониторинга linux-like OS, конечно есть и реализация агента Munin для Windows, но о ней как-нибудь в другой раз.

Итак, что же это такое, почему именно эта система мониторинга и как её «едят».

Из чего состоит Munin.

Munin — это система мониторинга с агентами. То есть, она состоит из двух основных компонентов  — непосредственно самого сервера и клиентской части (в терминологии Munin — нода), которая как правило устанавливается на тот компьютер, мониторинг которого мы хотим осуществлять.

Серверная часть запускается по заданному расписанию (по-умолчанию каждые 5 минут), она опрашивает все свои ноды, строит для нас красивые графики и при необходимости уведомляет нас о имеющихся проблемах.

Нода же, является сервисом (демоном), который тихо-мирно сидит на своем компьютере и на порту TCP/4949 ждет когда «придет» сервер. Самое главное что умеет этот тихий сервис — запускать плагины.

Плагин это и есть самая интересная для нас часть ноды. Именно плагины отслеживают необходимые нам параметры, производят все вычисления и возвращают результаты в специальном виде, понятном серверу Munin.

Архитектура плагина. Кратко.

На самом деле никакой архитектуры тут нет! Плагином может быть любая программа или скрипт, достаточным для работы условием является только поддержка запуска с параметром config (конфигурационный режим) и возврат значений в stdout.

Возвращаемые значения — а вот тут, к сожалению, есть определенные ограничения. Основное заключается в том, что сервер очень любит рисовать все на графиках и как следствие принимает от плагина только числовые значения. Таким образом, если мы хотим отслеживать состояние чего-либо, то нам необходимо договориться как это будет выглядеть в «числах». Например: «0» — все работает, «1» — работает но не все, «2» — совсем ничего не работает.

Итак, какой же минимальный набор информации должен возвращать любой плагин?

С параметром config
graph_title — название нашего графика (обратите внимание что на одном графике может отображать несколько метрик)
graph_vlabel — единицы измерения (название оси ординат)
graph_category  — категория в которую войдет наш график
<имя_метрики>.label— название метрики
<имя_метрики>.warning — «желтый» порог (предупреждение)
<имя_метрики>.critical — «красный» порог (критическое состояние)

Без параметров
<имя_метрики>.value — непосредственное числовое значение данной метрики

Пример плагина.

Так как лучше один раз увидеть, чем сто раз услышать, то давайте рассмотрим все вышеизложенное на примере. Для этого мы возьмем  плагин для Munin — uptime от Nicolas Salles и я с Вашего позволения опущу все неинтересные нам в данный момент строки.

#!/bin/sh
...
if [ "$1" = "config" ]; then
        echo 'graph_title Uptime'
        ...
        echo 'graph_vlabel uptime in days'
        echo 'graph_category system'
        echo 'uptime.label uptime'
        ...
        exit 0
fi
awk '{printf "uptime.value %.2f\n",$1/86400}' /proc/uptime

Во первых, по первой строке — #!/bin/sh, видно что это скрипт для sh.

Во-вторых, если он запущен с параметром config, то он просто напросто возвращает:
graph_title Uptime — это название графика
graph_vlabel uptime in days — единица измерения
graph_category system — категория в которой находится наш график
uptime.label uptime — название для метрики uptime

И если скрипт запускается без параметра, он печатает:
uptime.value xxx
, где xxx — это просто отформатированная строка из файла /proc/uptime

Результат работы этого плагина можно посмотреть тут:

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

Заключение

Таким образом, на мой взгляд, у Munin есть два существенных достоинства перед другими системами мониторинга:
— благодаря нетребовательности к языку написания плагинов, он обладает крайне низким порогом вхождения;
— учитывая, что единственным ограничением для плагина является лишь возврат значения в числовом виде, можно создать сенсор/монитор для контроля практически любой необходимой нам метрики.

Ну и конечно, как и везде, в Munin не обойдется и без пары ложек дегтя:
— опрос для всех мониторов/сенсоров производиться по расписанию, с довольно большим временным интервалом, что конечно не позволяет оперативно реагировать на возникающие события;
— как и для других систем мониторинга с агентами, не всегда есть возможность установить агент на целевую систему.

Спасибо за внимание!