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

Глава 7 
Таблица 7.1
(окончание) 
Параметр Описание 
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.dll
фактически состоит из двух подмодулей: 
CheckWMIValue
и соб-
ственно 
CheckWMI
. Подмодуль 
CheckWMIValue
оптимизирован для контроля числен-
ных значений — например, текущей загруженности процессора (это число процен-
тов загрузки) или разрешения монитора (число пикселов) и т. п. Работая с ним, вы 
можете просто указать контролируемые параметры и минимальные/максимальные 
допустимые для них значения, например, так: 
CheckWMIValue "Query=Select PelsWidth from win32_DisplayConfiguration" 
MinCrit=640 MinWarn=800 Check:Width=PelsWidth 

---

Мониторинг информационной системы 
319 
Приведенная здесь команда составлена для использования в режиме отладки 
(
nsclient++ /test
). Она запрашивает разрешение дисплея по горизонтали и сооб-
щает о критическом состоянии в случае, если оно равно или менее 640, и выдает 
предупреждение, если значение не превосходит 800. Из особенностей использова-
ния этой команды отметим, что после строки запроса (которая заключена в кавыч-
ки) нужно указать параметры минимальных/максимальных значений и только по-
том указывать название параметра, который контролируется командой (здесь: 
PelsWidth
). Поясним также опцию 
Check
, присутствующую в командной строке. По-
сле 
Check
необходимо вписать название параметра, которое будет применяться
в системе контроля (можно сохранить и название из описания в WMI, но часто более 
удобно ввести собственное название), и название, соответствующее объекту класса 
(то, которое отображается, например, в утилите просмотра 
WMI Object Browser
). 
Другие примеры (в том числе в вариантах для конфигурации Nagios) вы легко най-
дете поиском на странице документации агента NSClient++ (см. ранее приведенную 
ссылку). 
Подмодуль 
CheckWMI
нужно использовать в тех случаях, когда предполагается либо 
анализ строкового параметра, возвращаемого в результате WMI-запроса, либо за-
прос нескольких значений. При использовании подмодуля
CheckWMI
строки запроса 
несколько усложняются из-за необходимости использования фильтров. Синтаксис 
подмодуля
CheckWMI
вы также найдете на странице документации агента 
NSClient++ (см. ранее приведенную ссылку). По своему построению запросы под-
модуля
CheckWMI
сходны с фильтрами, используемыми для анализа журналов рабо-
ты системы. 
Мониторинг в Nagios серверов Linux 
Контроль работы серверов Linux осуществляется с использованием плагина NRPE, 
причем на сервере Nagios он должен быть установлен как плагин, а на контроли-
руемой системе Linux — в качестве демона. Для установки может быть использо-
вана как подготовленная версия, так и исходные коды плагина. 
Кроме стандартного комплекта администратор может задействовать при монито-
ринге любой из доступных плагинов, которые широко представлены в Интернете. 
Используя протокол NRPE, можно на контролируемом хосте вызвать команду 
check_nrpe
для проверки другого хоста. Этим способом можно контролировать не-
которую подсеть через один компьютер. При такой организации контроля на хосте, 
используемом в качестве прокси, обязательно должны быть установлены как демон 
протокола NRPE, так и плагин. 
Мониторинг систем
с использованием протокола SNMP 
Для работы по протоколу SNMP в Nagios должен быть установлен соответствую-
щий плагин. Он включен в состав плагинов Nagios, но воспользоваться им можно 
только в том случае, если предварительно был установлен пакет net-snmp. Поэтому, 

---

320 
Глава 7 
если предполагается использование SNMP-модуля, этот пакет необходимо загру-
зить с сервера 
http://net-snmp.sourceforge.net/
, после чего заново перекомпилиро-
вать плагины и повторно установить их. Авторы рекомендуют при новой установке 
сначала выполнить команду 
make clean
, которая очистила бы настройки предыду-
щей инсталляции. 
П
РИМЕЧАНИЕ
На сайте 
http://net-snmp.sourceforge.net/
необходимый пакет представлен только
в исходных кодах или в RPM-формате. 
После настройки контроля по протоколу SNMP необходимо протестировать рабо-
тоспособность системы на простейших запросах. Например, проверить длитель-
ность работы устройства: 
/usr/local/nagios/libexec/check_snmp -H <
адрес_устройства
> -C <
community
>
-o sysUpTime.0 
П
РИМЕЧАНИЕ
В примерах использован протокол SNMP версии 1. В реальных условиях обычно ис-
пользуется протокол версии 3, поэтому примеры необходимо дополнить параметрами 
аутентификации. 
В ответ вы должны получить примерно такое сообщение: 
SNMP OK — Timeticks: (622339555) 72 days, 0:43:15.55 | 
Команда 
check_snmp
может запрашивать параметр, принимающий численное значе-
ние, и проверять соответствие его значения некоторому диапазону. Так, можно ука-
зать значения для состояния предупреждения и критического состояния (ключи: 
-w
и 
-с
) или диапазон значений (через двоеточие). Обратите внимание, что если вы 
хотите, чтобы, например, критическим значением интерпретировалось возвращае-
мое число в диапазоне от 
а
до 
b 
(
b
> 
a
), то диапазон нужно указывать так: 
b:a
. Если 
указать диапазон в привычном виде: 
a:b
, то, если возвращаемое значение 
попадает 
в этот диапазон, результат будет считаться нормальным состоянием, а если не по-
падает — то как предупреждение или критическое (в зависимости от использован-
ного ключа). Кроме того, команда может проверять возвращаемое строковое значе-
ние (значение, с которым проверяется ответ, следует указать в ключе 
-s
) или даже 
выполнять проверку с использованием регулярных выражений (ключи 
-r
,
-R
).
В запросе также можно проверять сразу несколько параметров, указывая их OID 
через запятую, — например, так: 
//usr/local/nagios/libexec/check_snmp -H <адрес> -C  -o 
.1.3.6.1.2.1.2.2.1.7.101,.1.3.6.1.2.1.2.2.1.7.102,.1.3.6.1.2.1.2.2.1.7.103 
SNMP OK — 1 1 1 | iso.3.6.1.2.1.2.2.1.7.101=1 iso.3.6.1.2.1.2.2.1.7.102=1 
iso.3.6.1.2.1.2.2.1.7.103=1 
После того как запрос будет составлен и отлажен, достаточно описать новую
команду в файле 
commands.cfg
и добавить нужные службы в файлы описания конт-
ролируемых устройств. 
В Сети можно найти достаточное число примеров настройки Nagios для контроля 
устройств с использованием протокола SNMP, которые можно применить на прак-

---

Мониторинг информационной системы 
321 
тике. Так, по адресу: 
http://wiki.nagios.org/index.php/Howtos:snmp-apc-smart-ups
содержится описание настроек, с помощью которых можно контролировать со-
стояние источников бесперебойного питания (UPS): состояние батареи, параметры 
напряжения, температуру и пр. 
Сервер протоколов 
Постановка задачи 
Иногда нужно, чтобы протоколы со всех серверов сети аккуратно собирались на 
одном центральном сервере. Зачем? Просматривать протоколы серверов нужно
далеко не всегда, а только в том случае, когда что-то «сломалось». Тогда можно 
удаленно зайти на интересующий нас сервер и просмотреть его журналы. Собст-
венно, никакой необходимости в централизованном сервере протоколов нет. 
Но представим другую ситуацию: когда нам нужно ежедневно не только собирать, 
но и обрабатывать протоколы. Каждый день заходить на каждый сервер и копиро-
вать его протоколы как-то не очень хочется. Проще заставить это сделать за нас 
компьютер. Точнее, несколько компьютеров — каждый сервер вместо того, чтобы 
записывать сообщение в собственный журнал, будет отправлять его на централь-
ный сервер. В итоге мы получим некий архив протоколов на одном сервере. А там 
осталось дело за малым — написать на bash/awk сценарий для их обработки (в за-
висимости от того, что нужно сделать). 
Мы же немного усложним нашу задачу. Мы станем не просто «сваливать в кучу» 
протоколы со всех серверов, а сразу будем помещать их в базу данных (MySQL)
и анализировать программой loganalyzer. 
Нам не известно, какие именно вы задачи перед собой ставите, но у этого решения 
есть два преимущества. Во-первых, вы получаете удобный веб-интерфейс, позво-
ляющий просматривать логи серверов сети. Во-вторых, все журналы будут хра-
ниться в базе данных MySQL, что весьма удобно. Ведь можно через phpMyAdmin
1
отправить любой запрос к этим данным, сделать любую выборку. Можно также 
написать приложение на PHP (или любом другом языке с поддержкой MySQL), что 
гораздо удобнее написания сценариев на bash/awk. Хранение журналов в базе дан-
ных открывает огромные возможности по их обработке, в противовес их хранению 
в обычных текстовых файлах. 
Перед тем как приступить к настройке, рекомендуем ознакомиться с веб-ин-
терфейсом, чтобы вы представляли, как все это будет выглядеть, и приняли реше-
ние, нужно ли это вам. Демо-версия анализатора loganalyzer доступна по адресу:
http://demo.phplogcon.org/
. За исключением рекламы, все будет выглядеть именно 
так. 
1
PHPMyAdmin — веб-приложение с открытым кодом, написанное на языке PHP и представляющее 
собой веб-интерфейс для администрирования СУБД MySQL. 

---

322