Учебное пособие

Самоучитель системного администратора

       

7.3. Nagios

Nagios является программой мониторинга информационных систем на основе открытого кода. Продукт является практически стандартом для систем мониторинга. Он позволяет (в том числе):

  • контролировать хосты (загрузка процессора, использование диска, журналы и т. д.) с разнообразными операционными системами — Windows, Linux, AIX, Solaris и т. д.;
  • контролировать сетевые службы (SMTP, POP3, HTTP, SSH и т. д.);
  • подключать дополнительные модули расширения (плагины) на любом языке программирования (Shell, C++, Perl, Python, PHP, C# и др. — архитектура модулей должна быть открыта), использовать собственные способы проверки служб;
  • осуществлять параллельную проверку систем (для повышения производительности);
  • отправлять оповещения в случае возникновения проблем с помощью электронной почты, сообщений SMS и т. п.;
  • автоматически реагировать на события службы или хоста.

Установка Nagios

Nagios является OpenSource-проектом, который доступен для установки как в исходных кодах, так и в подготовленных пакетах для различных клонов Linux. Понятно, что установка из исходных кодов имеет более свежую версию, чем подготовленные пакеты.

Установка из подготовленных пакетов осуществляется по правилам соответствующей версии операционной системы. Например, для Ubuntu команда будет выглядеть примерно так:

apt-get install nagios2

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

Процедура быстрой установки программы на Ubuntu описана на сайте в разделе документации (http://nagios.sourceforge.net/docs/3_0/quickstart-ubuntu.html). Обратите только внимание на то, что за установкой из исходных кодов должна последовать и установка необходимых плагинов и дополнений.

После завершения установки работу программы можно проверить, открыв страницу http://localhost/nagios/ (вместо localhost следует использовать имя сервера Nagios в случае открытия страницы с удаленного компьютера). На запрос параметров авторизации необходимо ввести имя nagiosadmin и тот пароль, который вы назначили для этой учетной записи на предыдущих шагах.

На рис. 7.14 показана одна из страниц программы — структура контролируемой Nagios небольшой системы (схема строится в Nagios автоматически).

Рис. 7.14.
Схема сети в Nagios

Немного о логике работы Nagios

Nagios можно представить условно в виде двух частей: сервера (собственно о его установке и велась речь в предыдущем подразделе) и клиента, т. е. системы, которая контролируется при помощи агента или без его установки.

Существуют различные версии агентов, устанавливаемых на операционные системы. Наиболее часто для систем на основе Linux используется программа NRPE (ссылка на этот плагин присутствует на официальном сайте Nagios — http://www.nagios.org/), а для Windows-компьютеров — NSClient++ (http://trac. nakednuns.org/nscp/).

    Примечание

    Исторически первым клиентом для Windows был вариант программы NPRE. В целях совместимости в NSClient++ сохранен протокол, используемый в NPRE. Вы можете в настройках клиента указать использование как любого варианта работы, так и обоих (некоторые плагины, например, разработаны под конкретную версию клиента). Учтите, что в некоторых случаях NPRe предоставляет больше возможностей для контроля, например, с его помощью легко настроить выполнение сценариев на самой контролируемой системе.

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

При помощи клиентов происходит активный мониторинг работы: сервер инициирует на клиенте заданную настройками команду и анализирует полученные данные. Кроме того, возможен пассивный режим работы в тех случаях, когда данные на сервер пересылаются по инициативе клиента. Например, так происходит обработка SNMP-трапов.

Как уже говорилось, для получения информации от клиента на сервере Nagios запускаются специальные команды (или программы). В терминах Nagios эти команды принято называть плагинами (plugin).

    Примечание

    Плагины несложно найти в Сети: с сайта Nagios есть ссылка на проекты на SourceForge.net, можно использовать сайт обмена плагинами http://www. monitoringexchange.org/ и другие источники.

Для того чтобы система мониторинга могла их использовать, такие команды должны быть описаны в специальном конфигурационном файле — commands.cfg. Именно эти описания в терминах Nagios и называются командами контроля.

Кроме описания самой команды, системе мониторинга надо знать, какие системы проверять, как часто запускать команду проверки, надо ли делать перерывы в ее использовании (например, не выполнять в определенные дни недели или в заданные периоды суток и т. п.). Совокупность таких настроек в Nagios принято называть службой (service), а определяются они отдельным блоком в файле, описывающим параметры контролируемой системы. Поскольку параметров в службе много (около полутора десятков) и многие из них обычно повторяются, то принято описывать повторяющиеся части в шаблонах (template), а непосредственно в описании службы просто указывать на такой шаблон (описания шаблонов хранятся в файле templates.cfg). Обратите внимание, что в шаблонах допускаются вложения: какую-то часть параметров можно выделить в отдельный шаблон и использовать его в других описаниях.

Каждая контролируемая система должна быть описана в конфигурации Nagios. Для удобства делается это в отдельных файлах (по типам устройств), которые при старте сервера включаются в общую конфигурацию. Первоначально ссылки на эти файлы "по направлениям" закомментированы, поэтому при необходимости начала контроля какого-либо класса устройств прежде всего следует удалить символ "#" в соответствующей строке файла nagios.cfg, а потом добавить блок описания системы в надлежащий файл.

В результате Nagios периодически выполняет на контролируемых системах заданные команды, собирает результаты и в случае возникновения критического события оповещает операторов. Результаты контроля можно сохранять (по умолчанию данные о производительности не хранятся) и представлять в графическом виде для анализа (см. разд. "Построение графиков в Nagios”). Также Nagios позволяет назначить команды, которые будут выполнены при возникновении событий. Таким способом можно автоматически устранять возникающие неисправности.

Если в системе будет контролироваться много компьютеров и устройств, то их удобно сгруппировать. В Nagios можно создать группы из компьютеров (устройств) и служб. Например, если нужно наблюдать за состоянием всех служб на серверах, то следует создать группу, в которую включить названия этих систем. А если вы хотите контролировать состояние, например, службы разрешения имен DNS, которая работает на нескольких физических системах, то в этом случае удобно создать группу для службы: достаточно будет видеть состояние всей группы как нормальное, чтобы быть уверенным в работе служб DNS на всех компьютерах. Так можно упростить администрирование и настройки мониторинга.

Из общих конфигурационных настроек отметим еще и параметры операторов — тех людей, кому программа будет отправлять сообщения в случае возникновения тех или иных событий. В Nagios индивидуальных операторов также можно объединять в группы и настраивать отправку сообщений определенного типа в конкретной группе специалистов. Также можно настраивать периоды времени. Их можно использовать для применения, например, различных типов контроля в рабочие и выходные дни, для разных способов оповещения администраторов (например, днем по электронной почте, а ночью — на пейджер) и т. д.

Оповещения могут эскалироваться: в случае появления повторяющихся событий оповещение может быть послано по иерархии следующему специалисту.

Структура конфигурационных файлов Nagios

Список стандартных файлов конфигурации Nagios приведен в табл. 7.1.

Таблица 7.1.
Список конфигурационных файлов Nagios

Имя файла

Назначение

nagios.cfg

Файл основных настроек конфигурации. Содержит имя и адрес администратора Nagios, ссылки на файлы конфигурации, импортируемые при старте системы

resource.cfg

Файл описания ресурсов. Содержит синонимы для скрытия путей фактического расположения команд Nagios от конечного пользователя для повышения безопасности

cgi.cfg

Параметры настроек Web-сервера. В этом файле описываются дополнительные пользователи Nagios и предоставленные им права доступа

Папки objects и др.

Папки с отдельными файлами, которые импортируются в конфигурацию при старте Nagios. Эти папки описаны в файле nagios.cfg

Описание команд Nagios

Команды Nagios описываются в файле commands.cfg (путь по умолчанию /usr/local/nagios/etc/object/commands.cfg).

На практике в файле commands.cfg обычно необходимо указать расположение исполняемого файла, его название, которое будет использовано в Nagios, и параметры строки запуска. По умолчанию в файле конфигурации установленной системы уже содержатся некоторые описания типовых команд проверки (проверки пингом — check_ping, проверки http-сервера — check_http и многие другие). По этим образцам легко можно создать собственные команды проверки, хотя обычно используют готовые разработки, которые, практически для любого варианта контроля, можно легко найти в Сети. Далее приведен пример описания простейшей команды — проверки достижимости хоста при помощи команды ping:

Это описание создает команду с именем check-host-alive, в качестве исполняемого файла используется команда check_ping из установленных утилит Nagios. Символы, заключенные в знаки доллара, указывают используемые переменные. В терминах Nagios это макросы (macros), которые заменяются значениями в момент выполнения. Поскольку обычно мы привыкли к другому определению макросов, в этой книге будем называть эти названия переменными. $hostaddress$ традиционно заменяется при вызове на имя тестируемой системы, а $arg1$, $arg2$ и т. д. — последовательно на аргументы, указываемые в описании службы. Ключи w и c определяют значения, которые будут использованы для формирования статуса предупреждения (w) или ошибки (с). Как правило, можно указывать абсолютные или относительные значения (или все вместе: в типовой конфигурации, например, параметр w указывается как 3000.0,80%). Последний ключ (-р) указывает, что команда ping должна послать пять проверочных пакетов.

Службы Nagios

Службы обычно описываются в файлах конфигурации отдельно для каждого типа контролируемых систем (в общую конфигурацию Nagios такие файлы импортируются директивами cgf_file=... в файле nagios.cfg). Построение файлов конфигураций начинается с описания шаблонов, за которыми следуют описания хостов и потом описания служб.

В описании службы уже можно не повторять общие значения из шаблонов, поэтому типовое определение службы может выглядеть примерно так:

В этом примере служба с названием Memory Usage использует для работы настройки из шаблона generic-service для хоста, описанного под именем winserver. В качестве команды служба запускает check_nt с параметрами командной строки memuse и -w 80 -c 90 (вторые параметры указывают, какое возвращаемое значение используемой памяти нужно считать критическим — 90%, а для какого установить состояние в предупреждение — от 80 до 90%; сами параметры перечисляются через символ "!").

Обычно для контроля однотипных устройств можно использовать одинаковую команду. В этом случае в описании службы достаточно перечислить все такие устройства через запятую:

Для служб можно определять зависимости (dependencies). Делается это для того, чтобы скрыть "лишние" предупреждения. Например, если часть систем находится в локальной сети после маршрутизатора, то можно определить зависимость их от этого устройства. Понятно, что если этот маршрутизатор выйдет из строя, то и все устройства, находящиеся за ним, окажутся недоступными. Настройка зависимости позволит в случае его аварии скрыть предупреждения о недоступности зависимых устройств пока не восстановится работа коммутатора и не выполнять на них проверку состояния соответствующих служб.

Описание контролируемых систем в Nagios

Для удобства различные типы контролируемых систем принято описывать в различных конфигурационных файлах. Перечень типовых используемых файлов конфигураций приведен в usr/local/nagios/etc/nagios.cfg, причем часть файлов закомментирована. Так, если потребуется контролировать коммутаторы в сети, то раскомментируйте строку #cfg_file=/usr/local/nagios/etc/objects/switch.cfg и т. д.

Само описание хоста (оно будет содержаться в файле windows.cfg, или switch.cfg, или printer.cfg и т. д.) минимально может выглядеть в этом случае следующим образом:

В описании хоста можно включать два параметра, которые будут определять действия, выполняемые в случае возникновения сбоев в работе системы:

Nagios будет выполнять команду проверки check-host-alive и, как только будет обнаружена смена состояния хоста, начнется выполнение программы server-reboot. Таким способом можно, например, запускать остановившиеся службы на контролируемых серверах, перезагружать системы и т. п.

Для удобства анализа хосты можно объединять в группы. Для этого необходимо описать группу в файле конфигурации следующим образом:

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

Описание временных параметров

Временные параметры используются в различных конфигурациях: в описаниях хостов (период, когда нужно осуществлять мониторинг, и период, когда нужно отправлять сообщения), служб и контактов (периоды, когда можно отправлять сообщения по хостам и по службам). Синтаксис определения нового периода легко понятен по примерам, включенным в файл /usr/local/nagios/etc/objects/timeperiods.cfg.

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

Использование встроенных в Nagios команд контроля

При стандартной установке Nagios и плагинов в нем присутствует ряд команд (плагинов), которые можно использовать для контроля систем. Список их приведен в табл. 7.2.

Таблица 7.2.
Список плагинов Nagios

Утилита

Назначение

check_apt

Контроль обновлений систем Linux, осуществляемых с помощью команд apt-get. Позволяет запустить процесс обновления при соответствующей настройке

check_breeze

Контроль мощности сигнала Wi-Fi стандарта Breezecom

check_by_ssh

Этот плагин позволяет запускать на удаленной системе команды, используя протокол SSH

check_clamd

Проверка соединения CLAMD (антивирусная программа) с удаленным хостом

check_cluster

Проверка состояния хостов в кластере Linux

check_dhcp

Проверка доступности DHCP-серверов в сети

check_dig

Проверка работы DNS-службы на хосте (используется команда dig)

check_disk

Проверка объемов использования дискового пространства (собственных и примонтированных дисков)

check_disk_smb

Проверка объемов использования дисков, подключенных по протоколу SMB (обычно это диски от Windows-систем)

check_dns

Проверка работы сервера DNS с использованием программы nslookup

check_dummy

Плагин для настройки: просто возвращает численный параметр и строку, описанные при его запуске

check_file_age

Проверка времени создания файлов

check_flexlm

Проверка службы Flexlm license manager

check_ftp

Проверка ftp-соединения с удаленным хостом

check_hpjd

Проверка состояния принтеров Hewlett Packard c установленной картой JetDirect (проверка осуществляется с использованием протокола SNMP)

check_http

Проверка http-соединений с удаленной системой. Проверка может осуществляться как по протоколу HTTP, так и по протоколу HTTPS. Можно контролировать время установки соединения, срок действия сертификатов сервера, а также ответ сервера (по поиску в ответе некоторой заданной строки, в том числе, допускается использование регулярных выражений)

check_icmp

Проверка удаленных хостов по протоколу ICMP

check_ide_smart

Проверка состояния локального диска (в Linux-системе) по S.M.A.R.T.-технологии

check_ifoperstatus

Проверка состояния работы сетевого интерфейса на заданной Linux-системе

check_ifstatus

Проверка состояния сетевого интерфейса на заданной Linux-системе

check_imap

Проверка работы удаленного хоста по протоколу IMAP. Можно анализировать ответ сервера на посылаемую на него строку imap-запроса

check_ircd

Проверка IRCD-плагина Nagios

checkJabber

Проверка JABBER-подключения к удаленному хосту

checkjdap

Проверка LDAP-сервера (можно отправить запрос на поиск соответствующего атрибута)

checkjdaps

То же проверка LDAP-сервера, только с использованием защищенных соединений (по протоколу SSL)

checkjoad

Проверка загрузки Linux-системы

checkjog

Проверка журналов Linux-системы на наличие некоторой последовательности символов

check_mailq

Проверка числа сообщений в очереди почтового сервера (работает с различными версиями sendmail, qmail)

check_mrtg

Проверяет заданную переменную в логе MRTG (Multi Router Traffic Grapher) на минимальное/максимальное значения (для контроля параметров производительности необходимо использовать check_mrtgtraf)

check_mrtgtraf

Проверяет значения исходящего и входящего трафика коммутаторов, записанные в журнал MRTG. Требуется первоначальная установка пакета MRTG (http://ee-staff.ethz.ch/~oetiker/webtools/mrtg/mrtg.html)

check_nagios

Проверяет состояние процесса Nagios на локальной машине

check_nntp

Проверка NNTP-соединения с указываемым хостом

check_nntps

То же, но с использованием протокола NNTPS

check_nrpe

NRPE плагин Nagios

check_nt

Этот плагин осуществляет сбор данных со службы NSClient на Windows-системах

check_ntp

Проверка NTP-сервера. Вместо этого плагина рекомендуется использовать check_ntp_peer

check_ntp_peer

Проверка NTP-сервера. Позволяет оценивать, в том числе, дрожание (jitter) сигнала времени

check_ntp_time

Этот плагин проверяет разницу времени между локальным сервером и указываемым удаленным серверов времени

check_nwstat

Используется для сбора данных с Novell-серверов. Требует установки дополнительных пакетов

check_oracle

Проверяет подключение к серверу Oracle, позволяет оценить размеры баз данных и наличие свободного места, состояние буферов кэширования и т. д.

check_overcr

Проверяет состояние Over-CR collector daemon на удаленной системе (http://www.molitor.org/overcr)

check_ping

Проверяет соединение с удаленной системой с использованием пакетов ping

check_pop

Проверка удаленных хостов по протоколу POP. Позволяет отправить на почтовый сервер строку запроса и проанализировать ответ сервера

check_procs

Проверяет состояние процессов Linux-системы

check_real

Проверяет состояние службы REAL (RTCP-подключений)

check_rpc

Проверяет состояние RPC-службы на указанном хосте

check_sensors

Проверяет состояние аппаратных датчиков системы Linux. Информация с датчиков получается с помощью пакета lm_sensors

check_simap

Проверяет IMAP-подключение по безопасному каналу к серверу. Контролируется время ответа и содержание (по анализу ответа на заданный запрос), валидность сертификатов

check_smtp

Проверяет SMTP-подключение к серверу. Ответ почтового сервера может анализироваться на наличие заданных строк. Также контролируется время отклика

check_snmp

Проверка удаленных систем (и получение с них данных) по протоколу SNMP

check_spop

Проверяет POP-подключение по безопасному каналу к серверу. Контролируется время ответа и содержание (по анализу ответа на заданный запрос), валидность сертификатов

check_ssh

Проверка подключения к SSH-серверу

check_ssmtp

Проверяет SMTP-подключение по безопасному каналу к серверу. Ответ почтового сервера может анализироваться на наличие заданных строк. Также контролируется время отклика

check_swap

Проверяет свободное пространство в swap-файле локальной системы

check_tcp

Проверка TCP-подключения к указанной системе. Проверяется наличие отклика, его время, наличие в отклике заданных строк и т. п.

check_time

Проверка времени на указанном хосте

check_udp

Проверка UDP-подключения к указанной системе. Проверяется наличие отклика, его время, наличие в отклике заданных строк и т. п.

check_ups

Проверка состояния источников бесперебойного питания на локальной или удаленной Linux-системе. Для работы плагина требуется, чтобы в системе был установлен UPSD daemon (http://www.networkupstools.org)

check_users

Проверка числа пользователей, вошедших в локальную систему

check_wave

Проверка уровня WI-FI-сигнала

Каждый из этих плагинов содержит справочную информацию, описывающую особенности его применения (вывод справки по команде <плагин> -h).

Для того чтобы задействовать плагин для мониторинга систем, в Nagios должна быть описана использующая его команда. В файле commands.cfg приведено несколько наиболее часто употребляемых примеров контроля систем. При практическом использовании Nagios этот файл должен быть расширен за счет ваших собственных команд контроля.

Мониторинг серверов Windows в Nagios

Для мониторинга систем на основе Windows разработано несколько различных агентов. Наиболее часто используемыми из них являются NSClient++, NC_NET (http://sourceforge.net/projects/nc-net) и OpMonAgent (http://www.opmon.org/ project/opmonagent.zip). Функционал данных агентов практически идентичен, поэтому мы рассмотрим использование агента NSClient++, являющегося, на взгляд автора, наиболее популярным из упомянутого списка.

Агент NSClient++ доступен со страницы http://trac.nakednuns.org/nscp/. Эту программу можно загрузить как в виде архива (zip), так и установочным файлом (msi), причем для 32- и 64-битных платформ следует использовать различные версии агента. Если вы загрузили архив, то его необходимо распаковать в желаемую папку и установить службу Windows командой

NSClient++ -install

Удобнее воспользоваться msi-файлом, поскольку в этом случае мастер установка сразу внесет в конфигурацию агента часть настроек по результатам ваших ответов (рис. 7.15).

Рис. 7.15.
Настройка параметров программы NSClient++.
Настройки пользователя, введенные на этапе установки, будут сохранены программой в файле конфигурации

После установки необходимо разрешить взаимодействие службы с рабочим столом, для чего следует открыть свойства службы (Панель управления | Администрирование | Службы | найти службу NSClientpp... (полное название зависит от версии) и открыть ее свойства) и включить опцию Разрешить взаимодействие с рабочим столом.

Перед запуском службы следует обязательно проверить параметры ее работы. Для этого откройте файл nsc.ini (в папке установки агента) и снимите комментарий с тех строк, которые соответствуют модулям программы, предполагаемым к использованию для мониторинга системы. Достаточно подробные описания параметров конфигурации приведены в документации плагина на странице http://trac. nakednuns.org/nscp/wiki/doc/Configuration.

При настройке конфигурации следует исходить из принципа, что не следует включать больше опций, чем это необходимо в текущий момент. Например, если вы не планируете получать информацию посредством WMI-запросов, то и не стоит загружать модуль CheckWMI.dll.

Обратите внимание на возможность запуска агента в диагностическом режиме. При этом вы сможете как увидеть потенциальные ошибки в конфигурационном файле, так и отладить собственные запросы (рис. 7.16).

Рис. 7.16.
Окно программы NSClient++ в диагностическом режиме

Для запуска NSClient++ в диагностическом режиме достаточно в командной строке набрать

NSClient++ /test

В окне NSClient++ вы сможете, во-первых, увидеть результаты загрузки всех модулей, а во-вторых, вводить собственные команды и видеть результаты выполнения как запросов со стороны сервера Nagios, так и локальных команд. На рис. 7.16 показано окно отладки плагина, в котором введена команда CheckDriveSize ShowAll MinWarnFree=20% MinCritFree=10% Drive=D:\ и виден ответ системы.

Плагин NSClient++ позволяет контролировать параметры, приведенные в табл. 7.3. Подробности использования подробно описаны в технической документации (http://trac.nakednuns.org/nscp/wiki/CheckCommands) и по имеющимся примерам легко составить собственные команды контроля состояния Windows.

Таблица 7.3.
Параметры Windows, контролируемые NSClient++

Параметр

Описание

CheckFileSize

Контролирует размер файла или папки

CheckDriveSize

Контролирует размер свободного или использованного пространства жестких или сменных дисков (тип диска можно выбирать в команде)

CheckFile

Контролирует файлы по критериям даты их создания, времени последнего доступа, записи в файл или по размеру файла

CheckEventLog

Ищет сообщения об ошибках в файле журнала. Поскольку таких сообщения обычно много, использование данного контроля сильно загружает систему

CheckCPU

Контролирует загрузку процессора в течение задаваемого периода времени

CheckUpTime

Контролирует время работы системы

CheckServiceState

Контролирует состояние службы Windows (критическое сообщение формируется в случае несоответствия фактического состояния службы заданному в качестве параметра в команде). Можно контролировать все службы одновременно с заданием исключения. В качестве названия службы надо указывать то, которое отображается в свойствах службы

CheckProcState

Контролирует состояние процессов Windows. Фактически позволяет наблюдать за состоянием процесса, найденного по имени исполняемого файла. Можно контролировать также по числу одновременно запущенных процессов

CheckMem

Контролирует состояние виртуальной и физической памяти; доступен параметр количества записанных страниц памяти (commited pages)

CheckCounter

Контролирует значения счетчиков производительности. Объекты счетчиков желательно — в целях удобства использования — задавать в описаниях команд (служб)

CheckAlwaysOK
CheckAlwaysCRITICAL
CheckAlwaysWARNING
CheckMultiple
CheckOK
CheckCRITICAL
CheckWARNING
CheckVersion

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

Перечисленным списком не ограничиваются возможности контроля Windows-систем. Вы можете добавить контролируемые параметры, например, за счет использования внешних сценариев.

Мониторинг систем Windows может осуществляться на основе различных протоколов. Наиболее часто используемыми являются протоколы NSClient и NRPE (для "пассивного" мониторинга можно использовать также протокол NSCA, о котором более подробно можно прочесть в онлайновой документации). На практике можно использовать любой из них, необходимо только включить/выключить соответствующие модули в файле настроек клиента (nsc.ini). В то же время, на взгляд автора, протокол NRPE несколько более гибок в использовании и обеспечивает шифрование данных обмена. При использовании протокола NRPE синтаксис команд строится следующим образом:

check_nrpe ... -c <команда> -a <аргументы>

Например, проверка доступной физической памяти может быть осуществлена так:

check_nrpe -H 192.168.0.9 -c CheckMem -a MaxWarn=70% MaxCrit=>80% type=physical

Мониторинг Windows-систем на основе WMI

В состав NSClient++ входит модуль CheckWMI.dll, позволяющий контролировать Windows-систему с использованием инструментария WMI.

Модуль CheckWMI фактически состоит из двух подмодулей: CheckWMIValue и CheckWMI. Модуль CheckWMIValue оптимизирован для контроля численных значений. Например, текущей загруженности процессора (это число процентов загрузки) или разрешения монитора (число пикселов) и т. п. В этой команде вы можете просто указать контролируемые параметры и минимальные/максимальные допустимые для них значения, например, так:

CheckWMIValue "Query=Select PelsWidth from win32_DisplayConfiguration"
MinCrit=640 MinWarn=800 Check:Width=PelsWidth

Приведенная здесь команда составлена для использования в режиме отладки (nsclient++ /test). Она запрашивает разрешение дисплея по горизонтали и сообщает о критическом состоянии в случае, если оно равно или менее 640, и выдает предупреждение, если значение не превосходит 800. Из особенностей использования этой команды отметим, что после строки запроса (которая заключена в кавычки) нужно писать параметры минимальных/максимальных значений и только потом указывать название параметра, который контролируется командой (PelsWidth). Поясним также опцию Check, используемую в командной строке. После Check необходимо вписать название параметра, которое будет применяться в системе контроля (можно сохранить и название из описания в WMI, но часто более удобно ввести собственное название), и название, соответствующее объекту класса (то, которое отображается, например, в утилите просмотра WMI Object Browser).

Другие примеры (в том числе в вариантах для конфигурации Nagios) приведены на странице http://trac.nakednuns.org/nscp/wiki/CheckWMIValue.

Модуль CheckWMI нужно использовать в тех случаях, когда предполагается либо анализ строкового параметра, возвращаемого в результате WMI-запроса, либо запрос нескольких значений. При использовании CheckWMI строки запроса несколько усложняются из-за необходимости использования фильтров. Синтаксис CheckWMI описан на странице http://nsclient.org/nscp/wiki/CheckWMI/ CheckWMI. По своему построению запросы CheckWMI сходны с фильтрами, используемыми для анализа журналов работы системы.

Мониторинг серверов Linux в Nagios

Контроль работы серверов Linux осуществляется с использованием плагина NRPE, причем на сервере Nagios он должен быть установлен как плагин, а на контролируемой системе Linux — в качестве демона. Для установки может быть использована как подготовленная версия, так и исходные коды плагина.

Кроме стандартного комплекта администратор может использовать при мониторинге любой из доступных плагинов, которые широко представлены в Интернете.

Используя протокол NRPE, можно на контролируемом хосте вызвать команду check_nrpe для проверки другого хоста. Таким способом можно контролировать некоторую подсеть через один компьютер. При такой организации контроля на хосте, используемом в качестве прокси, обязательно должны быть установлены как демон протокола NRPE, так и плагин.

Мониторинг систем с использованием протокола SNMP

Для работы по протоколу SNMP в Nagios должен быть установлен соответствующий плагин. Он включен в состав плагинов Nagios, но воспользоваться им можно только в том случае, если предварительно был установлен пакет net-snmp. Поэтому, если предполагается использование SNMP-модуля, данный пакет необходимо загрузить с сервера http://net-snmp.sourceforge.net/, после чего заново перекомпилировать плагины и повторно установить их. Автор рекомендовал бы при новой установке сначала выполнить команду make clean, которая очистила бы настройки предыдущей инсталляции.

    Примечание

    На сайте http://net-snmp.sourceforge.net/ необходимый пакет представлен только в исходных кодах или в RPM-формате.

После настройки возможности контроля по протоколу SNMP необходимо протестировать1 работоспособность на простейших запросах. Например, проверить длительность работы устройства:

/usr/local/nagios/libexec/check_snmp -H <адрес_устройства> -C <community> -o
sysUpTime. 0

В ответ вы должны получить примерно такое сообщение:

SNMP OK — Timeticks: (622339555) 72 days, 0:43:15.55 |

Команда check_snmp может запрашивать параметр, принимающий численное значение, и проверять соответствие его значения некоторому диапазону. Так, можно указать значения для состояния предупреждения и критического состояния (ключи -w и -с) или диапазон значений (через двоеточие). Обратите внимание, что если вы хотите, чтобы, например, критическим значением интерпретировалось бы возвращаемое число в диапазоне от а до b (b > a), то диапазон нужно указывать b:a. Если указать диапазон в "привычном" виде, как a:b, то если возвращаемое значение попадает в этот диапазон, то результат будет считаться нормальным состоянием, а если не попадает — то как предупреждение или критическое (в зависимости от использованного ключа). Кроме того, команда может проверять возвращаемое строковое значение (значение, с которым проверяется ответ, следует указать в ключе -s) или даже выполнять проверку с использованием регулярных выражений (ключи -r, -R). Также в запросе можно проверять сразу несколько параметров, перечисляя их OID через запятую, например так:

После того как запрос будет составлен и отлажен, достаточно описать новую команду в файле commands.cfg и добавить нужные службы в файлы описания контролируемых устройств.

В Сети можно найти достаточное число примеров настройки Nagios для контроля устройств с использованием протокола SNMP, которые можно применить на практике. Так, по адресу http://wiki.nagios.org/index.php/Howtos:snmp-apc-smart-ups содержится описание настроек, с помощью которых можно контролировать состояние источников бесперебойного питания от APC (состояние батареи, параметры напряжения, температуру и т. д.).

Мониторинг коммутационного оборудования

Активное оборудование сети — коммутаторы, концентраторы, модемы и т. п. контролируются по протоколу SNMP (управляемые модели). Можно получать состояния портов оборудования, выдавать предупреждения в случае возникновения на портах некоторого числа ошибок передачи пакетов, наблюдать за температурой устройства и количеством VPN-сессий. Достаточно только выбрать соответствующие идентификаторы по описанию для мониторинга по протоколу SNMP. В большинстве случаев этого достаточно для контроля.

Однако, кроме указанных параметров, администраторы часто хотят знать реальную загрузку оборудования, процент использования пропускной способности. Эти значения нельзя получить, запрашивая тот или иной параметр состояния оборудования. Они вычисляются на основе анализа периодически получаемых данных. Специально для такого мониторинга создана одна из самых популярных программ — MRTG. Ее возможности обработки параметров коммутаторов используются в Nagios.

Программа MRTG по протоколу SNMP с активного оборудования собирает статистику, которая при помощи плагина check_mrtgtraf впоследствии передается в Nagios для отображения.

После установки программы MRTG необходимо создать файлы настроек, в которых указать устройства и значения параметров, которые программа будет собирать. Эти настройки должны быть приведены в файле /etc/mrtg.conf. Формирование конфигурации MRTG достаточно сложная задача, поэтому в пакете предусмотрена специальная программа, которая автоматически опросит устройство и сформирует файл конфигурации — cfgmaker. При ее запуске в качестве параметров нужно указать строку community и адрес устройства. Вывод программы следует перенаправить в файл, значения из которого мы потом просто импортируем в файл настроек. В качестве имени такого файла удобно использовать имя (или адрес) опрашиваемого устройства:

cfgmaker community@адрес > /etc/mrtg/адрес.cfg

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

После редактирования файла настроек можно запустить программу mrtg, указав в качестве параметра конфигурацию устройства. Для систем с кодировкой UTF-8 команда запуска будет выглядеть так:

env LANG=C /usr/bin/mrtg /etc/mrtg.cfg

При установке пакета MRTG в системе настраивается автоматический сбор информации с коммутаторов один раз в течение пяти минут. При желании этот период можно увеличить, если соответствующим образом отредактировать файл /etc/cron.d/mrtg.

Графики производительности по отдельным портам устройств можно просмотреть, если открыть в обозревателе папку http://nagiosserver/mrtg/ и выбрать соответствующий файл. При желании можно сформировать общий индексный файл для упрощения отображения. Делается это с помощью команды indexmaker. Необходимые ключи для формирования файла легко уточнить по справочной информации после вызова indexmaker -h.

Всед за описанной настройкой можно использовать команды Nagios check_mrtg и check_mrtgtraf для сбора данных производительности. Команда check_mrtgtraf требует указания следующих параметров:

check_mrtgtraf -F <имя_файла_журнала> -a -w входящий,исходящий-c входящий,исходящий -e период_устаревания

В этом примере параметр -a указывает, будет ли браться в учет максимальное значение (max) за период анализа или же программа оценит среднее значение (avg). После ключей w и c указываются пары лимитов для исходящего и входящего трафика по данному порту. По какому порту система будет контролировать данные, определяется выбранным файлом журнала. На рис. 7.17 приведен пример графика, формируемого пакетом mrtg.

Рис. 7.17.
График загрузки порта коммутатора

Использование собственных программ мониторинга

Nagios позволяет легко создать собственные плагины для мониторинга любой системы. В качестве таковых могут быть использованы любые исполняемые файлы. Необходимо только обеспечить, чтобы они сообщали код завершения работы в соответствии с табл. 7.4.

Таблица 7.4.
Коды возврата программ мониторинга системы для Nagios

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

Построение графиков в Nagios

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

Для реализации такой возможности необходимо установить дополнительный плагин. Одним из наиболее популярных плагинов для создания графиков в Nagios является пакет nagiosgraph, доступный к загрузке с сайта http://sourceforge.net/ projects/nagiosgraph/.

На рис. 7.18 представлен пример страницы контроля состояния служб, на которой при подведении курсора мыши к соответствующему параметру динамически отображается график его изменения. При желании администратор может перейти к выбору графика по любой службе и за заданный период времени.

Рис. 7.18.
Пример страницы с динамическим графиком

Настройка интерфейса Nagios

Для Nagios разработано много дополнений, которые позволяют настроить отображение данных мониторинга в соответствии с потребностями администратора. Так, вместо тактического обзора (рис. 7.19) можно использовать настраиваемые карты сети, на которых Nagios будет отображать состояние каждого устройства.

Рис. 7.19.
Стандартный вариант отображения суммарного состояния системы в Nagios

На рис. 7.20 (пример с сайта http://www.nagvis.org) приведен реальный вариант карты мониторинга, построенной при помощи пакета NagVis.

Рис. 7.20.
Отображение состояния сети при использовании пакета NagVis

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


1В примерах использован протокол SNMP версии 1. В реальных условиях обычно используется протокол версии 3, поэтому примеры необходимо дополнить параметрами аутентификации.

 

 

 

Top.Mail.Ru
Top.Mail.Ru