АНДРЕЙ БЕШКОВ
Мониторинг Windows-серверов с помощью Nagios.
Часть 1
С момента публикации первой статьи о Nagios прошло довольно много времени, но вопросы и пожелания все продолжают приходить. Самый часто встречающийся вопрос – как настроить слежение за серверами, работающими под управлением семейства операционных систем Windows. В этой статье мы рассмотрим два способа, используя которые можно добиться осуществления наших желаний. Как всегда система, мониторинга Nagios работает под управлением моей любимой системы FreeBSD 4.7. Приверженцы Linux, Solaris и других UNIX-подобных систем тоже не останутся в стороне. Все описанные ниже приемы с незначительными изменениями можно с успехом применять и в их системах.
В качестве подопытной системы будет использоваться русская версия Windows 2000 Professional. Такой выбор обусловлен тем фактом, что настроить программное обеспечение для исправной работы с русской версией сложнее, чем с аналогичной английской. Придется решать проблемы, связанные с локализацией, а значит, статья получится гораздо полезнее и интереснее. Последовательность действий по настройке программного обеспечения выглядит практически одинаково для всех версий Windows. Я надеюсь, что никому из вас не приходит в голову мысль серьезно рассматривать в качестве операционной системы для установки на сервер Windows 3.1, 3.11, 95, 98, ME. Поэтому дальше в этой статье о них не будет сказано ни слова, соответственно, вы можете с полным правом считать, что все методы, описанные ниже, работать с ними, скорее всего, не будут.
В дальнейшем предполагается, что вы прочитали первую статью, подробно описывающую основы установки и настройки Nagios, либо в февральском номере журнала «Системный администратор», либо на моем сайте http://onix.opennet.ru.
Покончив с формальностями, приступим к изучению конструкции и принципов работы подсистемы сбора данных о производительности. Такая система встроена в каждую версию Windows-системы старше, чем Windows ME.
Для сбора статистики о своем функционировании Windows NT, Windows 2000, Windows XP используют объекты производительности. Делать подобные утверждения о Windows 2003 не буду, потому что потрогать ее пока не удалось. Каждый компонент системы в процессе работы генерирует данные о производительности и складывает их в счетчики (performance counters) собственного объекта производительности. На самом деле объект – это абстракция, введенная для облегчения понимания материала. Логичнее всего было бы представлять объект как группу счетчиков, связанную с наблюдаемой службой или ресурсом. Чаще всего название объекта совпадает с названием родительского системного компонента. В большинстве случаев объекты производительности соответствуют компонентам оборудования компьютера – память, процессор, жесткие диски. В то же время многие службы и программы могут создавать свои собственные объекты производительности. Иллюстрацией такого утверждения являются объекты службы «Обозреватель компьютеров» или серверной программы Internet Information Server. К примеру, объект «Файл подкачки» содержит внутри себя набор счетчиков, говорящих о состоянии одного или нескольких файлов виртуальной памяти, используемых системой. Некоторые подсистемы имеют всего один экземпляр объекта производительности, другие же могут иметь несколько. К первому виду относятся «Система», «Память», «Сервер». «Жесткий диск» и «Процессор», соответственно, ко второму. Согласитесь, что жестких дисков в компьютере может быть несколько, а значит, внутри системы они должны быть представлены отдельными подсистемами. В то же время оперативная память, вне зависимости от количества чипов, является единым компонентом. А посему иметь больше одного экземпляра объекта производительности ей не положено. В случае если подсистема обладает несколькими экземплярами объекта, есть возможность следить за счетчиками всех экземпляров или за одним общим. В зависимости от языка операционной системы, объекты и счетчики называются по-разному. К примеру, посмотрим, как будет называться один и тот же счетчик в локализованных версиях Windows 2000:
Название счетчика
|
Локализация
|
Committed Bytes
|
Английская
|
Byte vincolati
|
Итальянская
|
Zugesicherte Bytes
|
Немецкая
|
Байт выделенной виртуальной памяти
|
Русская
|
Octets dedies
|
Французская
|
Bytes comprometidos
|
Испанская
|
Bytes confirmados
|
Португальская
|
По моему мнению, идеи более глупой, чем подобное чрезмерное увлечение локализацией, придумать нельзя. Представьте себе процесс написания программы, использующей в своей работе счетчики. Придется постоянно переделывать программу для каждой новой локализованной версии Windows. В дальнейшем все приводимые примеры будут опираться на русские версии перечисленных операционных систем семейства Windows.
Чтобы закрепить все вышесказанное, давайте рассмотрим несколько примеров счетчиков:
TIGROIDПpoцeccop(_Total)\% загруженности процессора
TIGROIDПpoцeccop(0)\% загруженности процессора
TIGROIDПpoцeccop(1)\% загруженности процессора
Первый компонент – это имя моего домашнего компьютера, на котором я пишу статьи и провожу тестовые инсталляции. «Процессор» – название объекта. Как вы могли бы догадаться, (_Total) – экземпляр, инкапсулирующий внутри себя данные о производительности всех процессоров системы. Соответственно, (0) и (1) – экземпляры объектов первого и второго процессоров. И наконец, «% загруженности процессора» – название самого счетчика. В повседневной практике сложилась традиция для краткости записывать названия счетчиков без имен компьютеров. Я считаю, что нам также стоит придерживаться ее.
Счетчики бывают следующих типов:
- Моментальный – всегда содержит последнее значение использования ресурса. В качестве разъяснения приводим счетчик Очередь печати(_Total)Заданий, собирающий данные о количестве заданий в очереди печати.
- Усредненный – хранит среднее число, созданное на основе двух последних значений счетчика. Примером такого типа является счетчик ПамятьСтраниц/сек., содержащий в себе среднее значение частоты смены страниц памяти в секунду.
Существует возможность создавать счетчики других типов. Но для этого необходимо иметь пакет Platform Software Development Kit. Впрочем, обсуждение подобных методик выходит далеко за границы этой статьи. Просмотреть список объектов и счетчиков, существующих в системе, а также полюбоваться на их содержимое можно с помощью модуля «Монитор производительности», входящего в состав консоли управления Microsoft. А если говорить совсем просто, то открыть вышеописанный модуль можно выполнив программу perfmon.exe. После ее запуска мы должны увидеть примерно такое окно:
Рассмотрим подробнее, что за чудо дизайна предстало перед нами. Слева мы видим дерево модуля, справа – координатная плоскость для отображения графиков. Сверху у нас находится панель инструментов. Ну а внизу – список счетчиков, используемых для построения графика. Для добавления еще одного счетчика в список нажимаем кнопку «+», находящуюся на панели инструментов.
С помощью такого диалога можно просмотреть полный список счетчиков, объектов и их экземпляров, существующих в системе на данный момент. Для того чтобы узнать, как правильно называется тот или иной счетчик, добавьте его в список отображения. Очень полезно во время просмотра списка доступных счетчиков нажать кнопку «Объяснения», так как названия счетчиков недостаточно информативны. К примеру, как вам такой шедевр ясности с первого взгляда: «% времени DPC»? Ладно, оставим названия на совести создателей системы. Хотя если есть желание, можно нажать кноку «Объяснение» и на экране появится маленькое окошко с кратким и не всегда понятным объяснением предназначения того или иного счетчика. Выбрав нужный счетчик, жмем кнопку «Добавить». Затем правой клавишей мыши щелкаем в центре графика и выбираем пункт меню «Свойства». В появившемся диалоговом окне наше внимание привлекает вкладка «Данные».
Теперь-то каждый из вас сможет не только выбрать счетчики по вкусу, но и правильно записать их название. Ну а если самому от руки перепечатывать названия счетчиков в другие программы не хочется, то можно выполнить еще одну хитрость.
Правой клавишей кликаем в центр графика и выбираем «Сохранить как». В открывшемся диалоге вводим имя файла test.html и жмем «Сохранить». Затем любым редактором открываем получившийся файл и среди кучи всяких ненужных данных, ближе к концу файла, видим полное и правильно написанное название счетчика. Затем с помощью буфера обмена его можно будет вставить в любую программу.
Вкратце обсудив принципы, лежащие в основе сбора данных о производительности Windows-машин, посмотрим, как можно с пользой для дела применять только что полученные знания.
Подопытная Windows-машина называется win2000rus. Для начала давайте выполним обязательные действия, необходимые для того, чтобы Nagios узнал об этой машине. Делать это придется вне зависимости от того, какой способ мониторинга мы изберем. Поэтому внесем ее данные в файл hosts.cfg.
С помощью такого диалога можно просмотреть полный список счетчиков, объектов и их экземпляров, существующих в системе на данный момент. Для того чтобы
# Описываем хост по имени win2000rus
define host{
use generic-host
host_name win2000rus
alias Windows 2000 Russian
address win2000rus
check_command check-host-alive
max_check_attempts 10
notification_interval 120
notification_period 24x7
notification_options d,u,r
}
Теперь добавляем его в файл hostgroups.cfg, описывающий группы хостов.
define hostgroup{
hostgroup_name win-servers
alias Windows Servers
contact_groups win-admins
members win2000rus
}
Создаем в файле contacts.cfg запись для человека, отвечающего за Windows-сервера.
define contact{
contact_name serge
alias Sergei Petrov
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-by-email, notify-by-epager
host_notification_commands host-notify-by-email, host-notify-by-epager
email serge@test.ru
pager 172345885@pager.icq.com
}
Пожалуйста, убедитесь, что вы внесли группу контактов win-admins в файл contactgroups.cfg.
define contactgroup{
contactgroup_name win-admins
alias Windows admins
members serge
}
NSClient
Закончив с обязательными действиями, перейдем к обсуждению первого способа мониторинга. Он состоит в том, чтобы установить на Windows-машину программу NSClient, доставшуюся нам в наследство от проекта NetSaint. Запустившись как сервис, она начнет через каждые пять секунд читать содержимое определенных системных счетчиков Windows. Полученные величины записываются в круговой буфер, в котором хранятся данные за последние 24 часа. Занимаясь сбором статистики, программа ожидает входящие соединения от клиентов на 1248-й порт. Для считывания данных и передачи их серверу мониторинга будет использоваться программа check_nt из стандартной коллекции модулей Nagios.
Давайте посмотрим, какие именно сведения о функционировании подопытного Windows-сервера можно получить с помощью check_nt:
- загрузка одного или всех процессоров за последние 24 часа;
- наличие свободного места на любом подключенном к системе жестком диске;
- состояние запущенных процессов;
- данные об использовании оперативной памяти;
- время работы системы с момента последней перезагрузки;
- состояние запущенных сервисов;
- дату изменения любого файла;
- данные любого системного счетчика.
Покончив с теорией, перейдем к инсталляции.
С сайта производителя http://nsclient.ready2run.nl/download.htmhttp://nsclient.ready2run.nl берем последнюю версию программы NSClient. Я использовал версию 1.0.7.1. После распаковки дистрибутива должны появиться следующие директории:
- LinuxBin – исполняемые файлы для Linux;
- UnixSource – исходный код для всех версий UNIX;
- NTSource – исходный код для всех версий Windows;
- Win_2k_XP_Bin – исполняемые файлы для Windows 2000 и XP;
- Win_NT4_Bin – исполняемые файлы для Windows NT.
Заглянув в директорию NTSource, понимаем – программа написана на Delphi. Впрочем, это обстоятельство никоим образом не мешает нам использовать ее для своих далеко идущих целей. Создаем директорию c:Program FilesNSClient. Затем, в зависимости от установленной у нас операционной системы, копируем в нее содержимое либо из директории Win_2k_XP_Bin, либо из Win_NT4_Bin. Пользуясь меню «Пуск –> Выполнить» запускаем командный интерпретатор cmd.exe. В появившемся окне набираем:
> C:Program FilesNSClientpNSClient /install
По окончании установки система должна продемонстрировать нам подобное окошко:
Это значит, что программе удалось прописать себя в реестре подобающим образом.
С помощью программы regedit откроем реестр. Ищем ветку HKEY_LOCAL_MACHINESOFTWARENSClientParams.
Внутри расположились параметры password и port. Я думаю, предназначение каждого из них очевидно. Думаю, вы согласитесь с утверждением, что возможность просматривать статистику должна быть предоставлена только программам, запущенным на сервере мониторинга. Меняем содержимое параметра “password” на что-нибудь длинное и трудноподбираемое, например «PxRT890mY».
Теперь любой, кто попытается подключиться для получения данных на порт 1248, должен будет предъявить пароль.
Проверим, как себя чувствует наш новый сервис NetSaint NT agent. Выбираем меню «Пуск –> Настройка –> Панель управления». Затем дважды кликаем по пиктограмме «Администрирование», в открывшемся окне так же поступаем со значком «Службы». Должно получиться что-то подобное:
Запустив службу и вернувшись в окно «Администрирование», щелкаем по значку «Просмотр событий». Во вновь открывшемся окне выбираем «Журнал приложений». Находим уведомление от программы NSClient и кликаем на нем дважды.
Нам нужно было увидеть следующую строку «NSClient 1.0.7.0 has started. Language code : 0x0419», опираясь на ее содержимое, мы можем узнать цифровой код языка, используемого в системе. Для русского языка это 0x0419, а для английского, соответственно, 0x0409. В файле C:Program FilesNSClientcounters.defs находится описание системных счетчиков для всех известных программе языков. Просмотрев его до конца, понимаем, что кодом 0x0419 тут явно не пахнет. Отсюда вывод – для русской версии Windows получим дырку от бублика вместо статистики. Осознав, что такое несправедливое положение вещей нас не устраивает, добавляем в counters.defs новую секцию с названиями счетчиков, соответствующими нашему языку:
[0x0419]
NT4_SystemTotalProcessorTime = "Система\% загрузки процессора"
NT4_SystemSystemUpTime = "СистемаВремя работы системы"
NT4_MemoryCommitLimit = "ПамятьПредел выделенной виртуальной памяти"
NT4_MemoryCommitByte = "ПамятьБайт выделенной виртуальной памяти"
W2K_SystemTotalProcessorTime = "Процессор(_Total)\% загруженности процессора"
W2K_SystemSystemUpTime = "СистемаВремя работы системы"
W2K_MemoryCommitLimit = "ПамятьПредел выделенной виртуальной памяти"
W2K_MemoryCommitByte = "ПамятьБайт выделенной виртуальной памяти"
Сохранив файл, перезапускаем сервис NetSaint NT agent. Тем, кому религия не позволяет вносить изменения в файлы собственноручно, предлагаю скачать модифицированную версию здесь: http://onix.opennet.ru/files. Еще раз бегло просматриваем журнал событий, дабы убедиться в отсутствии ошибок при перезапуске сервиса. Также стоит удостовериться, что вся цепочка событий происходила в таком порядке:
NSClient is now responding to queries.
NSClient 1.0.7.0 has started. Language code : 0x0419
NSClient is reading C:Program FilesNSClientcounters.defs for counters definitions. Language code : 0x0419
NSClient has stopped
|
Закончив возню с Windows, переходим к UNIX. В дальнейшем я предполагаю, что Nagios установлен в директорию /usr/local/nagios/. Запускается он с правами пользователя nagios, принадлежащего к группе nagios.
По крайней мере, именно так это происходит во FreeBSD. Если вы используете другую операционную систему, то вполне возможно настройки будут слегка отличаться. Для начала берем на сайте проекта Nagios: http://www.nagios.org/download самую свежую версию модулей. В моем случае это был файл nagiosplug-1.3-beta1.tar.gz. Распакуем архив:
# tar zxvf nagiosplug-1.3-beta1.tar.gz
К сожалению, в официальном пакете модулей, подключаемых к Nagios, находится старая версия исходного текста программы check_nt. Если оставить все как есть, то некоторые функции сбора данных станут для нас недоступны.
Сейчас мы легко в течение нескольких секунд устраним это досадное неудобство. Из дистрибутива, оставленного на Windows- машине, берем файл check_nt.c, расположившийся в директории UnixSource, и заменяем им старую версию, находящуюся на UNIX-машине в директории ./nagiosplug-1.3-beta1/plugins/.
Осталось исправить еще одну ошибку. Она касается только тех, кто использует FreeBSD или Solaris. Открываем файл ./nagiosplug-1.3-beta1/plugins/utils.c и ищем там строку:
nchars = vsnprintf (str, size, fmt, ap);
Найдя, заменяем ее на вот это:
nchars = vsprintf (str, fmt, ap);
Если не выполнить исправления, то все результаты работы модуля check_nt будут выглядеть таким образом:
Memory usage: total:??????? Mb - used: ??????? Mb (???????%) - free: ??????? Mb (???????%)
c: - total: ??????? Gb - used: ??????? Gb (???????%) - free ??????? Gb (???????%)
CPU Load (1 min. 12???????
|
Смотрится такое сборище вопросов весьма забавно. Жаль, но для нас такие данные абсолютно бесполезны. После работы над ошибками, возвратившись в главную директорию дистрибутива, проводим конфигурирование, сборку и инсталляцию.
# cd ..
# ./configure --prefix=/usr/local/nagios --with-nagios-user=nagios --with-nagios-grp=nagios
# gmake all
# gmake install
Стоит отметить тот факт, что для компиляции используется gmake вместо стандартной утилиты make. Иначе сборка сразу же после старта заканчивается сообщением о фатальной ошибке:
Making all in plugins
“/tmp/nagiosplug-1.3-beta1/plugins/Makefile”, line 760: Need an operator
make: fatal errors encountered – cannot continue
*** Error code 1
|
По завершению инсталляции приступаем к созданию новых команд, пользуясь которыми Nagios будет собирать данные. Описание всех используемых команд должно располагаться в файле checkcommands.cfg. Формат этого файла довольно прост.
Каждая команда начинается с открывающего тега define command{. Затем с помощью ключевого слова command_name определяется имя команды. Следующая строка command_line определяет имя модуля, вызываемого для осуществления проверки и параметры, передаваемые ему процессом Nagios. Особое внимание следует обратить на макросы подстановки значений $USER1$, $HOSTADDRESS$, $ARG1$, $ARG2$.
Давайте посмотрим, зачем нужен каждый из них:
- $USER1$ – путь, где нужно искать выполняемые модули. В нашем случае он равен /usr/local/nagios/libexec/. Значение этого макроса определяется в файле resource.cfg;
- $HOSTADDRESS$ – IP-адрес машины, подвергаемой проверке. Задается в определении сервисов внутри файла services.cfg;
- $ARG1$, $ARG2$ – параметры командной строки, передаваемые модулю проверки. Чаще всего используются для задания временных интервалов, порогов предупреждений и критических состояний.
Завершается определение команды с помощью закрывающего тега }. Итак, приступим к разбору содержимого файла checkcommands.cfg.
Завершается определение команды с помощью закрывающего тега }. Итак, приступим к разбору содержимого файла checkcommands.cfg.
# Определяем команду check_nt_cpuload . Использоваться она будет для сбора данных о загруженности процессора
define command{
command_name check_nt_cpuload
command_line $USER1$/check_nt -H $HOSTADDRESS$ -v CPULOAD -l $ARG1$ -s $ARG2$
}
# Команда check_nt_memuse. Показывает данные об использовании памяти. Имеется в виду виртуальная память.
define command{
command_name check_nt_memuse
command_line $USER1$/check_nt -H $HOSTADDRESS$ -v MEMUSE -w $ARG1$ -c $ARG2$ -s $ARG3$
}
# Команда check_nt_uptime. Отображает время работы системы с момента последней перезагрузки
define command{
command_name check_nt_uptime
command_line $USER1$/check_nt -H $HOSTADDRESS$ -v UPTIME -s $ARG1$
}
# Команда check_nt_disk_space. Отображает размер свободного пространства на любом жестком диске системы
define command{
command_name check_nt_disk_space
command_line $USER1$/check_nt -H $HOSTADDRESS$ -v USEDDISKSPACE –l $ARG1$ -w $ARG2$ -c $ARG3$ -s $ARG4$
}
# Описываем команду check_nt_service. Позволяет проверить, запущен ли в системе тот или иной сервис. Обратите внимание
# на необязательную опцию -d SHOWALL, позволяющую вывести более подробные диагностические сообщения.
define command{
command_name check_nt_service
command_line $USER1$/check_nt -H $HOSTADDRESS$ -v SERVICESTATE -d SHOWALL –l $ARG1$ -s $ARG2$
}
# Самая простая из всех вышеописанных команд check_nt_client_version позволяет узнать версию
# программы NSClient., работающую в системе
define command{
command_name check_nt_client_version
command_line $USER1$/check_nt -H $HOSTADDRESS$ -v CLIENTVERSION –s $ARG1$
}
# Команда check_nt_file_age дает возможность проверить время модификации любого файла на локальной машине
define command{
command_name check_nt_file_age
command_line $USER1$/check_nt -H $HOSTADDRESS$ -v FILEAGE -l $ARG1$ -w $ARG2$ -c $ARG3$ -s $ARG4$
}
# Определяем команду check_nt_process. Предоставляет механизм, с помощью которого можно узнать, существует ли
# в системе тот или иной процесс. Обратите внимание на необязательную опцию -d SHOWALL, позволяющую вывести
# более подробные диагностические сообщения о состоянии процесса.
define command{
command_name check_nt_process
command_line $USER1$/check_nt -H $HOSTADDRESS$ -v PROCSTATE –d SHOWALL -l $ARG1$ -s $ARG2$
}
# Команда check_nt_counter дает возможность просмотреть содержимое любого счетчика производительности, и поэтому
# является самой универсальной из всех описанных команд.
define command{
command_name check_nt_counter
command_line $USER1$/check_nt -H $HOSTADDRESS$ -v COUNTER -l $ARG1$ -w $ARG2$ -c $ARG3$ -s $ARG4$
}
После того как с файлом команд покончено, перейдем к файлу сервисов. Детально формат этого файла рассматривался в первой статье о Nagios. Здесь мы только рассмотрим формат строчки check_command, напрямую связанной с обсуждавшимися ранее макросами и $ARG1$ в частности.
check_command check_nt_process!"calc.exe,notepad.exe,mspaint.exe"!PxRT890mY
В приведенной выше строке check_command – ключевое слово, check_nt_process – название макрокоманды, описанной с файле checkcommands.cfg. Все параметры, передаваемые макросам $ARG1$, $ARG2$, $ARG3$ и так далее, должны быть отделены друг от друга восклицательным знаком. Таким образом, выходит, что значение "calc.exe,notepad.exe,mspaint.exe" будет передано в $ARG1$, а пароль PxRT890mY – в $ARG1$.
Определившись с синтаксисом, переходим к файлу services.cfg:
# На нашем сервере работают несколько самодельных программ. Они должны выполняться круглосуточно, поэтому мы создали
# следующий сервис. Для примера будут использоваться общедоступные программы «Калькулятор», «Paint», «Блокнот»,
# поставляющиеся с каждым дистрибутивом Windows.
define service{
use generic-service
host_name win2000rus
service_description User Programs
is_volatile 0
check_period 24x7
max_check_attempts 3
normal_check_interval 1
retry_check_interval 1
contact_groups win-admins
notification_interval 120
notification_period 24x7
notification_options c,r
# Обратите внимание на тот факт, что мы следим не за самими программами, а за их процессами в памяти. Имена процессов
# можно узнать с помощью встроенного в Windows стандартного диспетчера задач. Также стоит внимательно присмотреться
# к формату списка процессов.
check_command check_nt_process!"calc.exe,notepad.exe,mspaint.exe"!PxRT890mY
}
# Этот сервис показывает версию программы NSClient, работающей в системе.
define service{
use generic-service
host_name win2000rus
service_description NSClient Version
is_volatile 0
check_period 24x7
max_check_attempts 3
normal_check_interval 1
retry_check_interval 1
contact_groups win-admins
notification_interval 120
notification_period 24x7
notification_options c,r
# Формат команды очень простой. В $ARG1$ передается пароль
check_command check_nt_client_version!PxRT890mY
}
# Каждый час удаленный сервер базы данных кладет в локальную папку общего доступа c:\upload\ файл update.dbf.
# В этом файле находятся обновления базы данных. Если время создания файла не меняется больше, чем 70 минут,
# значит, происходит что-то нехорошее, и нужно перейти в состояние предупреждения.
# В случае, когда нет изменений в течении 90 минут, сервис переходит в критическое состояние.
define service{
use generic-service
host_name win2000rus
service_description File age
is_volatile 0
check_period 24x7
max_check_attempts 3
normal_check_interval 1
retry_check_interval 1
contact_groups win-admins
notification_interval 120
notification_period 24x7
notification_options c,r
# Все пути к файлам должны содержать двойной символ «\».
check_command check_nt_file_age!"c:\\upload\\update.dbf "!70!90!PxRT890mY
}
# Этот сервис показывает количество свободной виртуальной памяти, которое вычисляется таким образом.
# NSClient читает содержимое счетчика «\Память\Предел выделенной виртуальной памяти» и делит его на 100. показывающая,
# Так получается величина, сколько байт памяти принимается за один процент. Затем данные из счетчика «\Память\Байт памяти»
# выделенной виртуальной делятся на количество байт в одном проценте. Так мы узнаем, сколько процентов занято.
# К счастью, лично заниматься подобными операциями нет необходимости. NSClient сделает все сам.
define service{
use generic-service
host_name win2000rus
service_description Free Memory
is_volatile 0
check_period 24x7
max_check_attempts 3
normal_check_interval 1
retry_check_interval 1
contact_groups win-admins
notification_interval 120
notification_period 24x7
notification_options c,r
# Переход в состояние предупреждения происходит, если занято 70% памяти. Критический статус наступает, когда
# израсходовано 90% памяти.
check_command check_nt_memuse!70%!90%!PxRT890mY
}
# Этот сервис позволяет увидеть загрузку процессора.
define service{
use generic-service
host_name win2000rus
service_description CPU Load
is_volatile 0
check_period 24x7
max_check_attempts 3
normal_check_interval 1
retry_check_interval 1
contact_groups win-admins
notification_interval 120
notification_period 24x7
notification_options c,r
# Нагрузка считается в интервале за одну минуту. Переход в состояние предупреждения происходит при достижении уровня
# в 80%, а критический статус наступает, если загрузка 90% и более. Все эти характеристики задаются цифрами 1, 80, 90.
check_command check_nt_cpuload!1,80,90!PxRT890mY
}
# Время бесперебойной работы системы с момента последней перезагрузки.
define service{
use generic-service
host_name win2000rus
service_description Up time
is_volatile 0
check_period 24x7
max_check_attempts 3
normal_check_interval 1
retry_check_interval 1
contact_groups win-admins
notification_interval 120
notification_period 24x7
notification_options c,r
check_command check_nt_uptime!PxRT890mY
}
# Проверяем, функционирует ли сервис MS SQL SERVER и самописный сервис vmxposman.
define service{
use generic-service
host_name win2000rus
service_description CPU Load
is_volatile 0
check_period 24x7
max_check_attempts 3
normal_check_interval 1
retry_check_interval 1
contact_groups win-admins
notification_interval 120
notification_period 24x7
notification_options c,r
# Проблема в том, что в программе управления сервисами Windows показывает полные названия сервисов,
# предназначенные для человека. Нам нужно название, которое используется для внутренних нужд Windows.
# Узнать эту тайну можно либо посмотрев ветвь реестра: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services.,
# либо установив бесплатную утилиту 'Service Manager NT', доступную для скачивания по следующему адресу:
# http://www.rnks.informatik.tu-cottbus.de/~fsch/english/nttols.htm. Обратите внимание на тот факт,
# что по аналогии с процессами имена сервисов тоже можно перечислять через запятую.
check_command check_nt_service!”mssqlserver,vmxposman”
}
# Следим за количеством заданий, находящихся в очереди принтера.
define service{
use generic-service
host_name win2000rus
service_description Print Queue
is_volatile 0
check_period 24x7
max_check_attempts 3
normal_check_interval 1
retry_check_interval 1
contact_groups win-admins
notification_interval 120
notification_period 24x7
notification_options c,r
# Используя команду check_nt_counter, можно получить данные с любого счетчика. В данным случае –
# \Очередь печати(_Total)\Заданий Строка «%.0f job(s)» указывает модулю применить к результату
# преобразование к типу float и вывести число в формате с точностью ноль знаков после запятой.
# Затем к числу для наглядности добавляется строка «job(s)». Если вам непонятно, что это значит, –
# посмотрите документацию по функции printf ( ) языка С. Переход в состояние предупреждения происходит
# при накоплении 5 заданий, а критический статус наступает, если их становится 10 и более.
check_command check_nt_counter! "\Очередь печати(_Total)\Заданий", "%.0f job(s)"!5!10!PxRT890mY
}
# Проверяем процент использования файла подкачки
define service{
use generic-service
host_name win2000rus
service_description Paging File
is_volatile 0
check_period 24x7
max_check_attempts 3
normal_check_interval 1
retry_check_interval 1
contact_groups win-admins
notification_interval 120
notification_period 24x7
notification_options c,r
# Тут мы снова используем check_nt_counter, хотя и немного другим способом.
# Строка «Usage %.2f %%» указывает модулю применить к результату преобразование к типу float
# и вывести число в формате с точностью два знака после запятой. Затем для наглядности приклеиваем
# спереди строку «Usage». Обратите внимание на двойной знак «%» в строке форматирования.
# Снова вспомнив хорошими словами функцию printf ( ), понимаем, что в результате из двух получится
# один символ «%». Переход в состояние предупреждения происходит при достижении уровня в 80 процентов,
# а критический статус наступает, если файл подкачки заполнен на 90 и более процентов.
check_command check_nt_counter! "\Файл подкачки(_Total)\% использования", "Usage %.2f %%"!80%!90%!PxRT890mY
}
Стоит отметить тот факт, что названия счетчиков, используемых в определении двух последних сервисов, написаны русскими буквами в кодировке cp1251.
Если нарушить это требование, то NSClient не сможет понять, чего мы хотим от него добиться, и будет возвращать заведомо неправильные данные. Кодировка cp1251 используется для записи текстов по умолчанию всеми русскими Windows-системами.
Вот тут-то нас и поджидает проблема. Дело в том, что в большинстве UNIX-подобных систем для символов русского языка используется кодировка KOI8-R. Конечно, можно перенастроить консоль, на которой работаете под cp1251, но такой подход лично мне кажется неудобным.
Поэтому я поступил гораздо проще. Используя FTP, перенес файл checkcommands.cfg на Windows-машину. Затем с помощью стандартного редактора «Блокнот» внес требуемые изменения. Сохранился, перенес файл обратно на UNIX-машину и заменил старую копию в /usr/local/nagios/etc/.
В принципе нужного результата можно добиться разными путями. Немного подумав, я решил сделать это другим более простым способом. Набрал все нужные русскоязычные надписи в формате koi8-r. Из пакетов установил несколько программ для конвертирования текстов в разные кодировки:
siconv-0.2.1
fconv-1.1
ru-xcode-1.0
ru-dt1489-1.4
ru-mtc-1.3
После тестирования выяснилось, что удобнее всего использовать утилиту ru-mtc.
Для конвертирования нужно выполнить такую последовательность команд:
# cat checkcommands.cfg | mtc –f koi8 –t win 1251 > checkcommands.tmp
# mv checkcommands.tmp checkcommands.cfg
Теперь осталось только заставить Nagios перечитать файлы конфигурации:
# /usr/local/etc/rc.d/nagios.sh restart
Убедившись в отсутствии ошибок, можно начать ставить разные садистские эксперименты по проверке того, насколько надежно и оперативно система мониторинга реагирует на критические ситуации, происходящие на Windows-машине. Например, для того чтобы посмотреть, как работает слежение за очередью принтера, можно выключить питание принтера и отправить несколько заданий на печать. Впрочем, я думаю, вы и сами сможете придумать разные способы создаия критических ситуаций. Наигравшись вдоволь, можно переходить ко второму способу мониторинга, который я опишу в следующей статье.