Сегодня существует множество разнообразных систем мониторинга и регулярно появляются новые. Мы, в fastenv, этим обстоятельством удивлены. Ведь великолепному Nagios уже более 15 лет! В рамках данной статьи хочется мотивировать читателя выбрать именно его для своих задач. А так же начать ему посвященный цикл.
Первым делом развеем пару мифов.
Нагиус взрослый проект, который уже реализовал почти всё, что может потребоваться при решении задачи мониторинга. Им нет необходимости выпускать новые релизы раз в месяц. Стабильные релизы выходят раз в 6-12 месяцев. В тоже время коммиты в их git репозиторий идут регулярно. Последний — менее одного дня назад на момент написания этих строк. Иными словами, нагиус здоров и бодрствует!
Действительно, глядя на список плагинов может сложиться впечатление, что многие из них устарели, не рабочие, а новые почти никто не пишет. Дело вот в чем. Nagios имеет очень простое api взаимодействия core<->plugin, которое совместимо между всеми его версиями. Более того, это api взяли на вооружение многочисленные его форки, что делает их плагины так же пригодными для нагиуса. В итоге, с одной стороны, некогда написанный под вторую версию плагин остается рабочим и под четвертую. С другой — множество плагинов пишется под форки. Вот их неполный список: icinga, naemon, shinken, op5.
Нагиус стремится соответствовать лучшим традициям unix-style. Это инструмент, который делает только свое дело и, поверьте, справляется он очень хорошо. Нагиус — это система сбора метрик и формирования алертов. Всё. Хотите графики? Нету. Хотите хранить данные? Извините. Управление конфигурацией? Конечно нет.
Так в чём же смысл?
Настройка нагиуса представляет из себя большей частью описание объектов мониторинга. Ключевое свойство последних — наследование. Объект может унаследовать как один, так и несколько шаблонов, в каждом из которых можно добавить или переопределить какое-то свойство. В чём удобство? Покажем на примере. У Вас имеется три датацентра, в каждом ДЦ имеется сетевое обрудование, linux и windows сервера. Задача — лаконично настроить мониторинг.
cfg_dir=/home/nagios/settings/datacenters |
С этого момента нагиус начнет рекурсивно просматривать все директории в datacenters и искать *.cfg. Каждый такой файл будет обработан.
mkdir -pv /home/nagios/settings/datacenters/dc-{1,2,3,all} |
cat > groups.cfg <<"EOFF" define hostgroup{ hostgroup_name Dc-all-hosts alias All servers hostgroup_members dc-1-hosts,dc-2-hosts,dc-3-hosts # Эти группы будут определены для каждого dc } define servicegroup{ servicegroup_name Dc-all-services alias All services servicegroup_members dc-1-services,dc-2-services,dc-3-services } EOFF |
cat > templates.cfg <<"EOFF" define host{ name dc-common-host use generic-host check_period 24x7 check_interval 5 check_command check-host-alive contact_groups fastenv-team register 0 } define host{ name dc-net-host use dc-common-host check_interval 0.1 # Нет жизни без сети.. register 0 } define service{ name dc-common-service use generic-service register 0 notification_period 24x7 notification_interval 30 max_check_attempts 3 check_interval 1 contact_groups fastenv-team } EOFF |
Рассмотрим определение сервиса. Ключевое слово use наследует стандартный шаблон generic-service, ключевое слово register информирует, что это всего лишь шаблон, а не итоговый объект. Далее мы добавили самые общие параметры:
define service{ use dc-common-service host_name localhost service_description Check 80 port hostgroup_name Dc-all-hosts check_command check_port!80 } |
define service{ use dc-common-service host_name localhost service_description Check 443 port hostgroup_name Dc-all-hosts,!dc-3-hosts check_command check_port!443 } |
define service{ use dc-2-service host_name win1-dc-2-host service_description Check 3389 port hostgroup_name dc-2-windows-hosts check_command check_port!3389 } |
Что главное хотелось донести. Сопровождение нагиуса тем проще и быстрее, чем лучше продумана архитектура мониторинга. Ну а при работе с ним вы не почувствуете скованности, т.к. за 15 лет предусмотрели почти всё.)
define servicedependency{ hostgroup_name dc-2-hosts service_description Check 443 port dependent_service_description Check 80 port dependent_hostgroup_name dc-1-hosts execution_failure_criteria c notification_failure_criteria c,w,u } |
Апи выдержано в концепции минимализма. Существует всего 4 статуса: OK, WARNING, CRITICAL и UNKNOWN. Им соответствуют просто коды завершения плагина: 0, 1, 2 и >2. Если плагин хочет вернуть какое-то сообщение, то он должен сформировать на стандартный выход:
Some text | data=1 |
Расположенное после вертикальной черты — называется perfdata. Это опциональные данные, которые можно обработать на стороне сервера. Как и полагается в нагиусе, команду обработки perfdata следует сперва задать.
Напишем простейший плагин:
cat > check_admins.sh <<"EOFF" #!/bin/bash echo "Fastenv is working | status=1" exit 0 EOFF |
Сам сервер очень легковесный. В большинстве установок ему хватит 1 ядра и 256 мегабайт памяти. Для запуска проверок на самих хостах в общем случае потребуется установить nrpe сервер. Если же говорить о мониторинге unix хостов, то все проверки можно запускать по ssh используя стандартный «транспортный» плагин check_by_ssh. В таком случае со стороны цели вообще никаких настроек может не потребоваться.
В следующей статье мы поговорим об этом подробнее и покажем, как силами нагиуса можно настроить деплой своих плагинов.
Действительно, в наш век рюшек и свистелок больших данных, сложно представить систему наблюдения за инфраструктурой без визуализации и хранения истории.
В этом вопросе разработчики строго следуют своей концепции. На стороне сервера нет никакой системы складирования данных, но сделаны все необходимые верёвочки для интеграции. Но давайте обо всём по порядку.
В первую очередь отметим, что нагиус все же хранит историю алертов. Она пишется в специальный status-лог, по которому из веб интерфейса можно сформировать отчет.
Теперь займемся интеграцией. Как уже говорилось, плагин вправе вернуть сообщение специального формата:
| var1=1 .. varN=k |
которое называется perfomance data. На стороне нагиуса можно описать команду, которая будет выполняться всякий раз, как плагин вернул данные. Для удобства сервер предоставляет множество информации в специальных переменных, которую можно использовать для дальнейшей обработки.
Делается это примерно так:
define command{ command_name fastenv-simple-perfdata command_line /usr/bin/printf "%b" "$HOSTNAME$:$SERVICEDESC$:$SERVICESTATE$:$SERVICEPERFDATA$\n" >> /home/nagios/perfdata.log } |
Как Вы понимаете, тут можно сразу писть в mysql, постить в твиттер или делать что-то похожее. Мы же просто пишем в лог.
service_perfdata_file_processing_command=fastenv-simple-perfdata |
process_performance_data=1 |
С хранением, полагаю, разобрались.
Полон простоты и механизм отображения. Для этого в настрйках сервиса задается параметр action_url:
action_url http://graph/render?host=$HOST$.. |
Иными словами Вы описываете ссылку в которой нагиус подставит связанные с сервисом переменные. Пройдя по ней Ваш любимый бекенд отрисует нужный график.
С визуализацией полный порядок. Разработчики не навязывают Вам свое мнение, и не ограничивают какой-то одной базой. Они предлагают использовать профессиональные решения ориентированные именно под эту задачу, предоставляя возможность интегрировать именно то, что нравится.
Вот неполный список графических бекендов, которые можно подружить с нагиусом:
Думаю мой читатель уже знает, чего ждать от стандартного интерфейса. Он аскетичен и не перегружен. Но что действительно важно — он не единственный. Существуют альтернативы развиваемые как командой нагиуса, так и сообществом. Хороший пример последнего — thruk.