Product SiteDocumentation Site

12.4. Мониторинг

Мониторинг — это общее понятие, и разные его аспекты преследуют разные цели: с одной стороны, отслеживание использования машинных ресурсов позволяет предсказать их исчерпание и необходимость их увеличения; с другой стороны, уведомление администратора, когда сервис стал недоступен или работает некорректно, означает, что возникающие проблемы будут устраняться скорее.
Munin покрывает первую область, отображая графики истории ряда параметров (используемой ОЗУ, занятого дискового пространства, загрузки процессора, сетевого трафика, нагрузки Apache/MySQL, и т. п.). Nagios покрывает вторую область, регулярно проверяя, что сервисы работают и доступны, и посылая аварийные уведомления по соответствующим каналам (e-mail, текстовые сообщения и т. п.). Оба построены модульно, что позволяет легко создавать новые плагины для мониторинга специфических параметров и сервисов.

АЛЬТЕРНАТИВА Zabbix, комплексный инструмент мониторинга

Хотя Munin и Nagios используются очень широко, они — не единственные игроки на поле мониторинга, и каждый из них выполняет только половину задачи (отображение графиков с одной стороны, аварийные оповещения с другой). Zabbix же объединяет обе части мониторинга; у него также есть веб-интерфейс для настройки наиболее общих аспектов. Он развивался скачкообразно на протяжении последних нескольких лет и теперь может считаться достойным конкурентом. На сервере следует установить zabbix-server-pgsql (или zabbix-server-mysql), возможно вместе с zabbix-frontend-php, чтобы получить веб-интерфейс. На узлах, которые надлежит мониторить, следует установить zabbix-agent, отправляющий данные на сервер.
→ http://www.zabbix.org/

АЛЬТЕРНАТИВА Icinga, ответвление Nagios

Из-за расхождения во взглядах на модель разработки Nagios (который контролируется компанией) часть разработчиков создала ответвление Nagios под названием Icinga. Icinga остаётся совместимым — по крайней мере пока — с настройками и плагинами Nagios, но добавляет дополнительный функционал.
→ http://www.icinga.org/

12.4.1. Настройка Munin

Назначение Munin — наблюдать за множеством машин, и вполне естественно, что он имеет клиент-серверную архитектуру. Центральный узел — построитель графиков — собирает данные со всех наблюдаемых узлов и создаёт графики истории.

12.4.1.1. Настройка узлов для мониторинга

Первый шаг — установка пакета munin-node. Демон, устанавливаемый этим пакетом, слушает порт 4949 и отправляет данные, собранные всеми активными плагинами. Каждый плагин представляет собой простую программу, возвращающую описание собранных данных и последнее измеренное значение. Плагины хранятся в /usr/share/munin/plugins/, но на деле используются только те из них, символьные ссылки на которые присутствуют в /etc/munin/plugins/.
После установки пакета набор активных плагинов определяется в зависимости от доступного программного обеспечение и текущей настройки узла. Однако такая автоматическая настройка должна поддерживаться каждым плагином, и, как правило, бывает неплохо проверить результаты и исправить их вручную. Может оказаться небезынтересным просмотреть Галерею плагинов, хотя не все плагины сопровождаются исчерпывающей документацией. К счастью, все плагины являются сценариями, и большинство их довольно просты и содержат подробные комментарии. Так что просмотр содержимого /etc/munin/plugins/ — хороший способ понять, для чего нужен каждый плагин, и определиться, какие из них следует удалить. Аналогичным образом можно включить интересный плагин, найденный в /usr/share/munin/plugins/, просто создав символьную ссылку на него с помощью ln -sf /usr/share/munin/plugins/plugin /etc/munin/plugins/. Заметьте, что когда имя плагина заканчивается символом подчёркивания «_», плагину требуется параметр. Этот параметр должен храниться в имени символьной ссылки; например, плагин «if_» следует включить, создав символьную ссылку if_eth0, тогда он будет отслеживать сетевой трафик на интерфейсе eth0.
Когда плагины настроены, следует отредактировать конфигурацию демона, описав правила контроля доступа к собранным данным. Для этого служат директивы allow в файле /etc/munin/munin-node.conf. Настройка по умолчанию — allow ^127\.0\.0\.1$, она разрешает доступ только с локального узла. Обычно администратору требуется добавить аналогичную строку, содержащую IP-адрес узла построения графиков, а затем перезапустить демон с помощью service munin-node restart.

УГЛУБЛЯЕМСЯ Создание локальных плагинов

Munin содержит подробную документацию о том, как плагины должны себя вести, и как разрабатывать новые плагины.
→ http://munin-monitoring.org/wiki/plugins
Лучше всего тестировать плагин, запуская его в тех же самых условиях, в которых он будет вызываться munin-node; их можно имитировать, запустив munin-run plugin от имени суперпользователя. Возможный второй параметр этой команды (например config) передаётся как параметр плагину.
Когда плагин вызывается с параметром config, он должен описать себя, вернув набор полей: 
$ sudo munin-run load config
graph_title Load average
graph_args --base 1000 -l 0
graph_vlabel load
graph_scale no
graph_category system
load.label load
graph_info The load average of the machine describes how many processes are in the run-queue (scheduled to run "immediately").
load.info 5 minute load average
Разные доступные поля описаны в «Справочнике по плагинам», доступному как часть «Руководства Munin».
→ http://munin.readthedocs.org/en/latest/reference/plugin.html
Будучи вызванным без параметра, плагин просто возвращает последние измеренные значения; к примеру, вызов sudo munin-run load может вернуть load.value 0.12.
Наконец, когда плагин вызывается с параметром autoconf, он должен вернуть «yes» (и статус выхода 0) или «no» (и статус выхода 1) в зависимости от того, следует ли включать плагин на этом узле.

12.4.1.2. Настройка построителя графиков

«Построитель графиков» — это просто компьютер, собирающий данные и создающий на их основании графики. Необходимое для него программное обеспечение находится в пакете munin. Стандартная конфигурация запускает munin-cron (раз в 5 минут), который собирает данные со всех узлов, перечисленных в /etc/munin/munin.conf (по умолчанию там указан только локальный узел), сохраняет данные в файлах RRD (Round Robin Database — формат файлов, разработанный для хранения данных, меняющихся со временем), хранящихся в /var/lib/munin/, и генерирующий HTML-страницу с графиками в /var/cache/munin/www/.
Итак, все наблюдаемые машины должны быть перечислены в конфигурационном файле /etc/munin/munin.conf. Каждая машина указывается как целая секция с именем, соответствующим машине, и как минимум записью address, содержащей её IP-адрес. 
[ftp.falcot.com]
    address 192.168.0.12
    use_node_name yes
Секции могут быть более сложными и описывать дополнительные графики, которые могут быть созданы путём сочетания данных с разных машин. Примеры, приведённые в конфигурационном файле, будут неплохой начальной точкой для настройки.
Последний шаг — публикация сгенерированных страниц; для этого требуется настроить веб-сервер таким образом, чтобы содержимое /var/cache/munin/www/ было доступно на сайте. Доступ к этому сайту зачастую будет ограничен с помощью или механизма аутентификации, или правил контроля доступа по IP-адресам. Подробности см. в Раздел 11.2, «Web Server (HTTP)».

12.4.2. Настройка Nagios

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

12.4.2.1. Установка

Первый шаг установки Nagios заключается в установке пакетов nagios3, nagios-plugins и nagios3-doc. В процессе установки настраивается веб-интерфейс и создаётся первый пользователь nagiosadmin (для которого запрашивается пароль). Других пользователей можно добавить в файл /etc/nagios3/htpasswd.users с помощью команды htpasswd из состава Apache. Если во время установки не отображался диалог Debconf, с помощью dpkg-reconfigure nagios3-cgi можно задать пароль пользователя nagiosadmin.
Открыв в обозревателе http://server/nagios3/, можно попасть в веб-интерфейс; заметьте, что Nagios отслеживает некоторые параметры машины, на которой он запущен. Однако некоторые интерактивные функции, такие как добавление комментариев к узлу, не работают. Они выключены в конфигурации Nagios по умолчанию, которая сильно ограничена в целях безопасности.
Как описано в /usr/share/doc/nagios3/README.Debian, для включения некоторых функций требуется отредактировать /etc/nagios3/nagios.cfg и установить в нём значение параметра check_external_commands в «1». Нам также потребуется дать права на запись в каталог, используемый Nagios, с помощью таких команд: 
# service nagios3 stop
[...]
# dpkg-statoverride --update --add nagios www-data 2710 /var/lib/nagios3/rw
# dpkg-statoverride --update --add nagios nagios 751 /var/lib/nagios3
# service nagios3 start
[...]

12.4.2.2. Настройка

Веб-интерфейс Nagios довольно симпатичный, но не позволяет менять настройки или добавлять наблюдаемые узлы и сервисы. Вся конфигурация управляется через файлы, указанные в центральном конфигурационном файле /etc/nagios3/nagios.cfg.
В эти файлы не стоит погружаться, не вникнув в некоторые базовые принципы Nagios. В конфигурации перечисляются объекты следующих типов:
  • host (узел) — машина, которую необходимо наблюдать;
  • hostgroup (группа узлов) — набор узлов, которые следует сгруппировать вместе при отображении или для учёта некоторых общих элементов конфигурации;
  • service (сервис) — тестируемый элемент, относящийся к узлу или группе узлов. Это, как правило, проверка сетевого сервиса, хотя сюда может входить и проверка, держатся ли некоторые параметры на приемлемом уровне (например свободное дисковое пространство или загрузка процессора);
  • servicegroup (группа сервисов) — набор сервисов, которые следует сгруппировать вместе при отображении;
  • contact (контакт) — лицо, которому следует направлять аварийные предупреждения;
  • contactgroup (группа контактов) — набор таких контактов;
  • timeperiod (временной интервал) — промежуток времени, в течение которого должны быть проверены некоторые сервисы;
  • command (команда) — командная строка, выполняемая для проверки данного сервиса.
У каждого объекта, в соответствии с его типом, есть набор свойств, которые можно менять. Полный список слишком длинен, чтобы приводить его здесь, поэтому отметим только самые важные свойства и отношения между объектами.
Сервис использует команду для проверки состояния некой функциональности на узле (или группе узлов) на протяжении временного интервала. В случае проблемы Nagios отправляет предупреждение всем членам группы контактов, привязанной к сервису. Предупреждение отправляется каждому члену в соответствии с каналом, описанным в соответствующем объекте контакта.
Система наследования позволяет легко разделять наборы свойств между объектами без дублирования информации. Более того, начальная конфигурация уже включает набор стандартных объектов; зачастую для определения новых узлов, сервисов и контактов достаточно сделать их потомками стандартных объектов. Файлы в /etc/nagios3/conf.d/ — хороший источник информации о том, как это работает.
Администраторы Falcot Corp используют следующую конфигурацию:

Пример 12.3. Файл /etc/nagios3/conf.d/falcot.cfg

define contact{
    name                            generic-contact
    service_notification_period     24x7
    host_notification_period        24x7
    service_notification_options    w,u,c,r
    host_notification_options       d,u,r
    service_notification_commands   notify-service-by-email
    host_notification_commands      notify-host-by-email
    register                        0 ; Template only
}
define contact{
    use             generic-contact
    contact_name    rhertzog
    alias           Raphael Hertzog
    email           hertzog@debian.org
}
define contact{
    use             generic-contact
    contact_name    rmas
    alias           Roland Mas
    email           lolando@debian.org
}

define contactgroup{
    contactgroup_name     falcot-admins
    alias                 Falcot Administrators
    members               rhertzog,rmas
}

define host{
    use                   generic-host ; Name of host template to use
    host_name             www-host
    alias                 www.falcot.com
    address               192.168.0.5
    contact_groups        falcot-admins
    hostgroups            debian-servers,ssh-servers
}
define host{
    use                   generic-host ; Name of host template to use
    host_name             ftp-host
    alias                 ftp.falcot.com
    address               192.168.0.6
    contact_groups        falcot-admins
    hostgroups            debian-servers,ssh-servers
}

# команда 'check_ftp' с пользовательскими параметрами
define command{
    command_name          check_ftp2
    command_line          /usr/lib/nagios/plugins/check_ftp -H $HOSTADDRESS$ -w 20 -c 30 -t 35
}

# Стандартный сервис Falcot
define service{
    name                  falcot-service
    use                   generic-service
    contact_groups        falcot-admins
    register              0
}

# Сервисы, проверяемые на www-host
define service{
    use                   falcot-service
    host_name             www-host
    service_description   HTTP
    check_command         check_http
}
define service{
    use                   falcot-service
    host_name             www-host
    service_description   HTTPS
    check_command         check_https
}
define service{
    use                   falcot-service
    host_name             www-host
    service_description   SMTP
    check_command         check_smtp
}

# Сервисы, проверяемые на ftp-host
define service{
    use                   falcot-service
    host_name             ftp-host
    service_description   FTP
    check_command         check_ftp2
}
В этом конфигурационном файле описаны два наблюдаемых узла. Первый — веб-сервер, на нём проверяются порты HTTP (80) и HTTPS (443). Nagios также проверяет, что на порту 25 запущен SMTP-сервер. Второй узел — FTP-сервер, для него проверяется среди прочего, что он отвечает в течение 20 секунд. При превышении этого порога отправляется предупреждение; при задержке более 30 секунд ситуация считается критической. Веб-интерфейс Nagios также показывает, что наблюдается сервис SSH: это общая настройка всех узлов группы ssh-servers. Соответствующий стандартный сервис определён в /etc/nagios3/conf.d/services_nagios2.cfg.
Обратите внимание на использование наследования: то, что объект наследует другому объекту, указывается с помощью «use имя-родителя». Родительский объект должен быть идентифицируемым, для чего ему должно быть установлено свойство «name идентификатор». Если родительский объект не является реальным объектом, а служит только для создания потомков, следует установить есу свойство «register 0»; оно укажет Nagios, что объект не надо учитывать, и тогда нехватка некоторых параметров, которые в ином случае были бы обязательными, будет проигнорирована.

ДОКУМЕНТАЦИЯ Список свойств объектов

Более глубокое понимание различных способов настройки Nagios можно получить с помощью документации, предоставляемой пакетом nagios3-doc. Эта документация непосредственно доступна через веб-интерфейс, с помощью ссылки «Документация» в верхнем левом углу. Она включает список всех типов объектов со всеми свойствами, которыми они могут быть наделены. Там же описано, как создавать новые плагины.

УГЛУБЛЯЕМСЯ Удалённые проверки с помощью NRPE

Многие плагины Nagios позволяют проверять ряд параметров локально на узле; если требуется производить такие проверки на многих машинах, в то время как центральная установка будет их собирать информацию, нужно установить плагин NRPE (Nagios Remote Plugin Executor). Пакет nagios-nrpe-plugin должен быть установлен на сервере Nagios, а nagios-nrpe-server — на узлах, где следует запускать локальные проверки. Последний читает конфигурацию из /etc/nagios/nrpe.cfg. Этот файл должен содержать список проверок, которые могут запускаться удалённо, и IP-адреса машин, которые могут их запускать. На стороне Nagios эти удалённые проверки включаются путём добавления соответствующих сервисов с использованием новой команды check_nrpe.