Автор:Бешков Андрей
В предыдущей статье этого цикла мы говорили о том, как научить Nagios следить за Windows-серверами, пользуясь сведениями, предоставляемыми SNMP. Теперь пришла пора рассказать, как можно собирать данные о жизнедеятельности серверов, работающих под управлением разных диалектов UNIX. Для этого мы будем снова использовать SNMP. Если вас мучают вопросы, что такое этот пресловутый SNMP, как он работает и для чего предназначен, то, наверное, стоит ознакомиться с RFC 1156, 1157, 1213, 1146, 2571, 2574 и заодно прочитать предыдущую статью. Перед началом повествования следует сказать, что система мониторинга, на которой будут выполняться все действия, описанные ниже, у меня работает под управлением FreeBSD. За время, прошедшее с момента публикации предыдущей статьи, Nagios дорос до версии 1.2, также изменилась с 4.7 на 4.10 версия системы FreeBSD, используемой на моем сервере. Теперь уже нет необходимости компилировать Nagios из исходников, все прекрасно ставится из портов. Впрочем, стоит, как всегда, сделать традиционную оговорку: все, что я рассказывал в предыдущих статьях о Nagios и о чем буду говорить впредь, вполне надежно работает и под управлением других UNIX-подобных операционных систем.
Вдобавок необходимо заметить, что пакет usd-snmp, использовавшийся нами для работы с SNMP прежде, теперь превратился в net-snmp версии 5.1.1

Перейдем к задаче на сегодня. Необходимо настроить мониторинг серверов, работающих под управлением FreeBSD 4.10 и ALT Linux 2.3. Соответственно, для примера им даны имена reddaemon и penguin. Впрочем, стоит заметить, что net-snmp успешно работает и на многих других UNIX-подобных системах:

  • HP-UX (9.0, 10.20, 11.0);
  • Ultrix (от 4.2 до 4.5);
  • OSF (3.2, 4.0);
  • Solaris (SPARC/ULTRA от 2.3 до 2.8) (Intel 2.9) SunOS (4.1.4 и выше);
  • NetBSD (от 1.0 до 1.5 alpha);
  • FreeBSD (от 2.2 и выше);
  • Linux (ядра от 1.3 и выше);
  • BSDI (от 2.1 до 4.0.1);
  • AIX (3.2.5, 4.1.5);
  • OpenBSD (2.6, 2.8);
  • OS X (10.1.1, 10.1.2);
  • Irix (от 5.1 до 6.5);
  • QNX 6.2.1A;
  • Dynix/PTX 4.4.

На данный момент идут работы по портированию net-snmp на Windows. В результате уже сейчас можно сказать, что программа работает на 90% при условии компиляции с помощью Visual C++ и cygwin32.

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

# cd /usr/ports/net-mgmt/net-snmp

# make install clean

# cd /usr/ports/net-mgmt/nagios-plugins

# make install clean

Пакет net-snmp4, все еще присутствующий в дереве портов, устанавливать не стоит из-за сильной устарелости.

На подопытных серверах также необходимо проинсталлировать net-snmp. Для FreeBSD это делается вышеуказанным способом, но nagios-plugins ставить не следует. Для ALT Linux 2.3 требуется выполнить следующие команды.

# apt-get update

# apt-get install net-snmp net-snmp-utils

На этом процедуру инсталляции можно считать завершенной. Для того чтобы система могла отвечать на SNMP-запросы, внутри нее должен работать демон snmpd. Ему, как и всем порядочным программам, для успешного функционирования необходимо иметь конфигурационный файл. В качестве такового обычно выступает snmpd.conf. При работе с Linux он, как правило, располагается в /etc/snmp/, а для FreeBSD соответственно актуальна директория /usr/local/etc/.

Файл конфигурации одинаков для всех Unix систем, поэтому мы изучим его на примере, используемом для Linux.

# Местонахождение системы в реальном мире

syslocation Rostov-on-Don Kranoarmejskaya str. Building 1 testlab 407

# Контакты администратора

syscontact Andrew Beshkov admin@example.com tel. 390-34-89

# Сервисы, предоставляемые системой

sysservices = 79

Думаю, что есть необходимость подробно объяснить процедуру, с помощью которой рассчитывается содержимое переменной sysservices. Нужно выбрать из списка уровень и подставить его номер вместо L в формулу 2L-1.

  1. physical (концентраторы);
  2. datalink/subnetwork (мосты);
  3. internet (IP-шлюзы);
  4. end-to-end (IP-хост);
  5. OSI (протоколы OSI);
  6. OSI (протоколы OSI);
  7. applications (SMTP, POP3 и прочие сервисы).

К примеру, для маршрутизатора расчет будет выглядеть так: 23-1=4. А для обычного хоста 24-1 + 27-1 = 72. Если вы хотите мониторить все уровни, то лучше всего использовать цифру 79.

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

Следующим интересным моментом является безопасность. В традиционном SNMP для версий протокола 1 и 2с за нее отвечают строки сообществ (community strings). Их стоит воспринимать как своеобразные аналоги паролей. Сообщества бывают двух видов – private и public. Отличаются они друг от друга лишь тем, что первое позволяет изменять данные внутри наблюдаемого устройства, а второе дает возможность только просматривать их. Самым простым способом определить эти сообщества является внесение в конфигурационный файл следующих строк:

rocommunity InK12345

rwcommunity 12r341289j

Как вы уже могли догадаться, rocommunity дает право читать данные, а rwcommunity предоставляет полный доступ. Впрочем rwcommunity тоже можно удалить, если вы не собираетесь изменять данные внутри устройства с помощью snmp. Вышеприведенные опции составляют минимальный рабочий файл конфигурации. Но квалифицированные системные администраторы обычно так не делают, потому что иначе будет трудно различать это устройство среди огромного множества других SNMP-приборов.
Итак, давайте посмотрим, что за сведения могут предоставить нам подопытные устройства. Для этого запускаем на них демон snmpd. Чтобы это сделать, кладем на Linux-машине файл snmpd.conf в /etc/snmp и затем выполняем следующую команду:

# service snmpd start

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

# chkconfig snmpd on

И обязательно убеждаемся в успешности выполнения предыдущей команды с помощью:

# chkconfig snmpd —list

Для FreeBSD файл с настройками должен находиться в /usr/local/etc/snmp/. Кроме этого, нужно включить запуск демона в скрипте /usr/local/etc/rc.d/snmpd.sh. Чтобы это сделать, ищем внутри него строку snmpd_enable= «NO» и вписываем в нее слово «YES». Затем вручную запускаем демон.

# /usr/local/etc/rc.d/snmpd.s

Стоит отметить тот факт, что, кроме snmpd, в комплект net-snmp входит демон snmptrapd, отвечающий за обработку SNMP-ловушек. По умолчанию он выключен, стоит помнить, что в системе не должно работать ненужного программного обеспечения, поэтому без особой надобности не будем его включать. Говорить о том, как можно использовать эти самые ловушки, мы будем в следующей статье.

Теперь можно проверить, что за сведения предоставляют наши сервера. Сделать это можно как минимум двумя способами. C помощью утилит командной строки snmpget или snmpwalk.

# snmpwalk -m ALL -c InK12345 -v1 penguin .iso.org.dod.internet.mgmt.mib-2.system
SNMPv2-MIB::sysDescr.0 = STRING: Linux altlinux.unreal.net 2.4.27-std-up-alt1 #1 Sun Oct 17 22:42:45 MSD 2004 i686
SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10
SNMPv2-MIB::sysUpTime.0 = Timeticks: (1751738) 4:51:57.38
SNMPv2-MIB::sysContact.0 = STRING: Andrew Beshkov
SNMPv2-MIB::sysName.0 = STRING: penguin.example.com
SNMPv2-MIB::sysLocation.0 = STRING: Rostov-on-Don Kranoarmejskaya str. Building 1 testlab 407
SNMPv2-MIB::sysServices.0 = INTEGER: 0
SNMPv2-MIB::sysORLastChange.0 = Timeticks: (3) 0:00:00.03
SNMPv2-MIB::sysORID.1 = OID: IF-MIB::ifMIB
SNMPv2-MIB::sysORID.2 = OID: SNMPv2-MIB::snmpMIB
SNMPv2-MIB::sysORID.3 = OID: TCP-MIB::tcpMIB
SNMPv2-MIB::sysORID.4 = OID: IP-MIB::ip
SNMPv2-MIB::sysORID.5 = OID: UDP-MIB::udpMIB
SNMPv2-MIB::sysORID.6 = OID: SNMP-VIEW-BASED-ACM-MIB::vacmBasicGroup
SNMPv2-MIB::sysORID.7 = OID: SNMP-FRAMEWORK-MIB::snmpFrameworkMIBCompliance
SNMPv2-MIB::sysORID.8 = OID: SNMP-MPD-MIB::snmpMPDCompliance
SNMPv2-MIB::sysORID.9 = OID: SNMP-USER-BASED-SM-MIB::usmMIBCompliance
SNMPv2-MIB::sysORDescr.1 = STRING: The MIB module to describe generic objects for network interface sub-layers
SNMPv2-MIB::sysORDescr.2 = STRING: The MIB module for SNMPv2 entities
SNMPv2-MIB::sysORDescr.3 = STRING: The MIB module for managing TCP implementations
SNMPv2-MIB::sysORDescr.4 = STRING: The MIB module for managing IP and ICMP implementations
SNMPv2-MIB::sysORDescr.5 = STRING: The MIB module for managing UDP implementations
SNMPv2-MIB::sysORDescr.6 = STRING: View-based Access Control Model for SNMP.
SNMPv2-MIB::sysORDescr.7 = STRING: The SNMP Management Architecture MIB.
SNMPv2-MIB::sysORDescr.8 = STRING: The MIB for Message Processing and Dispatching.
SNMPv2-MIB::sysORDescr.9 = STRING: The management information definitions for the SNMP User-based Security Model.

Опция –m ALL указывает, что нужно показать все дерево ниже выбранного OID, после -с располагается комьюнити string, затем идут версия snmp-протокола, имя машины и OID запрашиваемой ветви. Стоит отметить, что OID можно записывать разными способами. В большинстве случаев префикс iso.org.dod.internet.mgmt.mib-2. можно не писать, так как он предполагается по умолчанию, соответственно мы получим тот же самый результат, если напишем просто system. Для указания OID вместо длинных названий можно использовать цифровые идентификаторы. К примеру, этот же куст дерева можно адресовать следующей комбинацией цифр .1.3.6.1.2.1.1. Если есть желание увидеть все MIB-дерево, то можно выполнить вышеуказанную команду, вовсе не указывая OID. Думаю, вы будете впечатлены размерами листингов, которые система выведет вам. Использовать командный интерфейс полезно, но, к сожалению, это не всегда помогает получить правильное представление о строении MIB-дерева.

В этом нам помогут утилиты, называемые MIB-браузерами. Для Linux и FreeBSD лучше всего подойдет программа mbrowse. Обычно она по умолчанию входит во многие дистрибутивы. В действии эта программа выглядит следующим образом.
Nagios
Для систем Windows существует достаточно много подобных утилит. О том, какую из них и почему стоит выбрать, я подробно рассказывал в предыдущей статье [1].

Конечно, обилие доступных данных поражает, но все же хотелось бы точно знать, как это использовать с наибольшей выгодой. Давайте вновь вернемся к предмету нашего разговора. Кроме стандартных ветвей, net-snmp создает свою собственную ветвь .iso.org.dod.internet.private. enterprises.ucdavis, которая содержит в себе все необходимые данные. В цифровом формате адрес этой ветви выглядит так: .1.3.6.1.4.1.2021. Стоит отметить, что в некоторых snmp-браузерах (snmp browser) данная ветка может быть недоступна через свое символьное обозначение, но в то же время запросы, выполняемые с помощью цифровых OID, будут вполне работоспособны. Думаю, вы со мной согласитесь, что это немного неудобно, поэтому, чтобы включить распознавание символьных имен, нам нужно будет скопировать MIB-базы из /usr/share/snmp/mibs/в рабочую директорию используемого браузера.

Как показывают тесты, все работает достаточно неплохо, но, к сожалению, наша система сейчас отвечает на SNMP-запросы, приходящие с любого IP-адреса. К тому же, по умолчанию используется первая версия протокола SNMP, которая передает все данные в открытом виде. Необходимо это исправить и заодно поднять уровень безопасности. Для этого вносим в файл snmpd.conf следующие строки вместо rocommunity и rwcommunity:

com2sec nagios 10.10.21.55/32 InK12345

group MyROGroup v2c nagios

view all included .1 80

access MyROGroup "" any noauth exact all none none

Стоит отметить, что опции rocommunity и rwcommunity – всего лишь оболочки вокруг более мощного набора команд VACM (Version based Access Control Module), которым мы воспользовались ранее.

Таким образом, мы сказали, что система, подвергаемая мониторингу, может принимать SNMP-запросы лишь от машины с адресом 10.10.21.55, которая является сервером мониторинга, и привязали этот адрес к внутреннему имени системы безопасности «nagios». Затем разрешили этому имени символизировать группу MyROGroup, а заодно закрепили за ним право передавать SNMP-команды только с помощью версии протокола 2с. Следующей строкой создали вид на определенную область SNMP-дерева. В данном случае с помощью запросов можно просматривать все, что лежит ниже .1 или .iso. Пользуясь этой опцией, можно ограничить дерево, доступное запросу до одной ветки или даже до единственного OID. И заключительной строкой указываем настройки безопасности для нашей группы MyROGroup. После этого не забываем перезапустить демон SNMP и проверить, как все работает.

# snmpwalk –m ALL -c InK12345 -v2с penguin .iso.org.dod.internet.mgmt.mib-2.system

Обратите внимание на опцию –v2c. Если все прошло нормально, выполняем ту же команду с –v1 и убеждаемся, что она не возвращает никаких сведений. Как вы, наверное, уже догадались, мы полностью отключили возможность вносить извне изменения в данные, находящиеся внутри наблюдаемого объекта. Выполняем проверку того, как работает модуль check_snmp, установленный на сервере Nagios. К примеру, неплохо было бы посмотреть Uptime системы

# /usr/local/nagios/libexec/check_snmp -H penguin -o .1.3.6.1.2.1.3.0 -C InK12345 -P 2c
Invalid SNMP version 2c

По каким-то странным причинам автор забыл включить в него возможность работы с протоколом версии 2с. Ошибка, говорящая, что эта версия не поддерживается, – не совсем то, что мы ожидали получить, поэтому давайте возьмем в руки большой напильник и самостоятельно поправим модуль check_snmp. Для этого нужно отредактировать файл /usr/ports/net-mgmt/nagios-plugins/work/nagios-plugins-1.3.1/plugins/check_snmp.c. Ищем в нем следующую строку:

-P, —protocol=[1|3]\n\

и заменяем ее на:

-P, —protocol=[1|2c|3]\n\

Затем, найдя условие такого вида:

if (proto == NULL || (strcmp(proto,DEFAULT_PROTOCOL) == 0) ) { /* default protocol version */

asprintf(&proto, DEFAULT_PROTOCOL);

asprintf(&authpriv, "%s%s", "-c ", community);

}

Вставляем после него вот такие строки:

else if ( strcmp (proto, "2c") == 0 ) { /* snmpv2c args */

asprintf(&proto, "%s", "2c");

asprintf(&authpriv, "%s%s", "-c ", community);

}

Проводим перекомпиляцию, а затем и замену старого модуля новым.

# make install

После этого команда с ключом -P 2c должна отработать нормально. Вписываем в файл checkcommands.cfg описание команды check_snmp_oid, с помощью которой будем проводить мониторинг и вызывать модуль check_snmp.

define command{

command_name check_snmp_oid

command_line $USER1$/check_snmp -H $HOSTADDRESS$ -o $ARG1$ -C $ARG2$ -w $ARG3$ -c $ARG4$ -u $ARG5$ -l "" -P $ARG6$

}
Затем в файле hosts.cfg рассказываем о наших серверах.

# Описываем шаблон хоста

define host{

name generic-host

notifications_enabled 1

event_handler_enabled 1

flap_detection_enabled 1

process_perf_data 1

retain_status_information 1

retain_nonstatus_information 1

max_check_attempts 10

notification_interval 120

notification_period 24×7

notification_options d,u,r

register 0

}

define host{

use generic-host

host_name Linux

alias Standard Linux Server

address penguin

check_command check-host-alive

}

define host{

use generic-host

host_name FreeBSD

alias Standart FreeBSD Server

address reddaemon

check_command check-host-alive

}

И, конечно же, не забываем причислить их к группе хостов onix-servers, внеся следующие строки в файл host groups.cfg

define hostgroup{

hostgroup_name onix-servers

alias Onix Servers

contact_groups onix-admins

members Linux, FreeBSD

}

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

# Описываем шаблон сервиса

define service{

name generic-service

active_checks_enabled 1

passive_checks_enabled 1

parallelize_check 1

obsess_over_service 1

check_freshness 0

notifications_enabled 1

event_handler_enabled 1

flap_detection_enabled 1

process_perf_data 1

retain_status_information 1

retain_nonstatus_information 1

notification_interval 120

notification_period 24×7

notification_options w,u,c,r

max_check_attempts 3

normal_check_interval 1

retry_check_interval 1

contact_groups onix-admins

register 0

}

Данный сервис показывает время работы системы с момента последней перезагрузки. Для этого используется OID .iso.org.dod.internet.mgmt.mib-2.system.sysUpTime.0. Почти такого же эффекта можно добиться с помощью .iso.org.dod .internet.mgmt.mib-2.host.hrSystem.hrSystemUptime.0. Хотя тут стоит сделать маленькое примечание: второй OID показывает не время, прошедшее с последнего перезапуска системы, а момент последней инициализации SNMP.

define service{

use generic-service

host_name Linux

service_description System Uptime

is_volatile 0

check_period 24×7

check_command check_snmp_oid!.1.3.6.1.2.1.1.3.0!InK12345! ""! ""! ""!2c

}

Следующим интересным для нас моментом будет совокупность сервисов, отображающих количество занятых блоков разделов /, home, и совокупный процент использованных блоков физической и своп-памяти. Для того чтобы понять, где находятся необходимые сведения, посмотрите ветку .iso.org.dod.internet.mgmt.mib-2.host.hrStorage.hrStorage Table. Принцип анализа ветви довольно прост. В hrStorage Index содержится список уникальных идентификаторов, описывающих каждое устройство. А hrStorageType в свою очередь хранит типы устройств. hrStorageDesc заполнен текстовыми описаниями объектов. Для моей системы это выглядит так:

hrStorageDescr.2 = STRING: Real Memory

hrStorageDescr.3 = STRING: Swap Space

hrStorageDescr.4 = STRING: /

hrStorageDescr.5 = STRING: /home

hrStorageDescr.6 = STRING: /proc/bus/usb

В hrStorageAllocationUnits указан размер блока для каждого из устройств:

hrStorageAllocationUnits.2 = INTEGER: 1024 Bytes

hrStorageAllocationUnits.3 = INTEGER: 1024 Bytes

hrStorageAllocationUnits.4 = INTEGER: 4096 Bytes

hrStorageAllocationUnits.5 = INTEGER: 4096 Bytes

hrStorageAllocationUnits.6 = INTEGER: 1024 Bytes

Ну а hrStorageSize указывает, сколько блоков в каждом устройстве.

hrStorageSize.2 = INTEGER: 54156

hrStorageSize.3 = INTEGER: 216836

hrStorageSize.4 = INTEGER: 273087

hrStorageSize.5 = INTEGER: 196780

hrStorageSize.6 = INTEGER: 0

И наконец, самое интересное. Как вы уже, наверное, догадались, hrStorageUsed содержит данные о том, сколько блоков занято на каждом из устройств.

hrStorageUsed.2 = INTEGER: 52564

hrStorageUsed.3 = INTEGER: 11220

hrStorageUsed.4 = INTEGER: 235014

hrStorageUsed.5 = INTEGER: 8755

hrStorageUsed.6 = INTEGER: 0

Теперь дело за малым: высчитать, сколько блоков соответствуют заполнению устройств на 80% и 90%. И затем создать на основе этих данных правила проверки.

В качестве примера приведем описание сервиса, показывающего, как обстоят дела с заполнением корневого раздела.

define service{

use generic-service

host_name Linux

service_description Space on /

is_volatile 0

check_period 24×7

check_snmp_oid!.1.3.6.1.2.1.25.2.3.1.6.4!InK12345!218470!245778!blocks!2c

}

Надеюсь, что на основе приведенного примера вы сможете создать описание всех необходимых сервисов. В мире UNIX-систем большинство задач можно решить разными способами. Сейчас вы в этом убедитесь. Давайте в очередной раз расширим функциональность демона snmpd, внеся в snmpd.conf следующие строчки.

disk / 180000

disk /home 760000

Таким образом, мы указываем, что хотим следить за свободным местом на разделах /и home еще одним способом. Вышеуказанные строки говорят демону snmp, что мы хотим установить флаг ошибки в случае, если на разделе /занято 180 Мб, а /home заполнен на 760 Мб. Впрочем, ничего страшного не случится, если ограничения не устанавливать вовсе. Кстати, стоит отметить, что ограничение можно описывать не только в килобайтах, но и в процентах. Теперь интересующие нас данные находятся внутри ветви .iso.org.dod.internet.private.enterprises.ucdavis.dskTable.dskEntry. Принцип построения таблицы стандартен. Идентификатор dskPath содержит данные об именах разделов.

dskPath.1 = STRING: /

dskPath.2 = STRING: /home

dskDevice устанавливает соответствие между разделами и физическими устройствами диска.

dskDevice.1 = STRING: /dev/sda1

dskDevice.2 = STRING: /dev/sda6

В dskMinimum dskMinPercent содержатся пороговые значения для поднятия флага ошибки. Соответственно, dskTotal, dskAvail, dskUsed отображают общее, доступное и задействованное пространство дисков. Следующая ветвь, называемая dskPercent, для нас наиболее интересна, так как содержит величину заполнения дисков в процентах.

dskPercent.1 = INTEGER: 86

dskPercent.2 = INTEGER: 4

Именно ее мы и будем контролировать. Конечно, можно контролировать состояние ветвей dskErrorFlag и dskErrorMsg.

dskErrorFlag.1 = INTEGER: 1

dskErrorFlag.2 = INTEGER: 0

dskErrorMsg.1 = STRING: /: less than 80% free (= 86%)

dskErrorMsg.2 = STRING:

Но это не очень удобно, так как в этом случае у системы есть лишь два состояния – «нормальное» и «критическое». Соответственно, нет промежуточного перехода в виде состояния «предупреждение». Разобравшись с теорией, давайте создадим сервис, который будет контролировать состояние раздела /новым способом.

define service{

use generic-service

host_name Linux

service_description Space on / check 2

is_volatile 0

check_period 24×7

check_command check_snmp_oid!.1.3.6.1.4.1.2021.9.1.9.1!InK12345!80!90!%

}

Думаю, создать сервисы, выполняющие проверку остальных разделов, вы сможете сами. Идем дальше. Если мы хотим следить за загрузкой процессора, добавляем в snmpd.conf вот это:

load 12 20 30

Этой строкой мы говорим демону, что желаем видеть статистику нагрузки на процессор за последнюю минуту, за пять и пятнадцать минут. К сожалению, интервалы жестко закодированы, и изменить их невозможно. И, как обычно, указываем необязательные пороговые ограничения в 12%, 20% и 30%, при превышении которых snmpd будет устанавливать флаг ошибки. Смотрим ветку .iso.org.dod. internet.private.enterprises.ucdavis.laTable.laEntry и понимаем, что нам наиболее интересны подветви laLoad, laLoadInt, laLoadFloat.

В этих подветках содержатся одни и те же данные, но с разным округлением. Соответственно сервис для проверки загрузки процессора за последнюю минуту будет выглядеть вот так:

define service{

use generic-service

host_name Linux

service_description CPU Load 1 min

is_volatile 0

check_period 24×7

check_command check_snmp_oid!.1.3.6.1.4.1.2021.10.1.5.1!InK12345!60!90!%

}

Следующей интересной для нас особенностью является возможность запускать сторонние скрипты при получении того или иного SNMP-запроса. И опять добавляем в snmpd.conf новые строки:

exec users /bin/sh /usr/bin/count_users.sh

exec mailqueue /bin/sh /usr/bin/count_mail.sh

Затем создаем файлы count_users.sh count_mail.sh:, с их помощью мы будем считать количество пользователей, работающих на данный момент в системе, и размер почтовой очереди postfix.

Содержимое файла count_users.sh:

who | wc -l

exit 0

Содержимое файла count_mail.sh:

mailq | tail -n 1 | cut -f5 -d " "

exit 0

Теперь смотрим, что у нас находится внутри ветки .iso.org.dod.internet.private.enterprises.ucdavis.extTable.extEntry.

\extNames.1 = STRING: users

extNames.2 = STRING: mailqueue

extCommand.1 = STRING: /bin/sh /usr/bin /count_users.sh

extCommand.2 = STRING: /bin/sh / usr/bin/count_mail.sh

extResult.1 = INTEGER: 0

extResult.2 = INTEGER: 0

extOutput.1 = STRING: 1

extOutput.2 = STRING: 2

extErrFix.1 = INTEGER: 0

extErrFix.2 = INTEGER: 0

extErrFixCmd.1 = STRING:

extErrFixCmd.2 = STRING:

Нас интересует extOutput, в которой находится первая строка из того, что скрипт выводит на экран, и extResult с кодом возврата скрипта, переданным командой exit. Судя по приведенному выше списку значений, у нас в системе находится один пользователь, а в почтовой очереди есть два письма. Сервисы для проверки результатов работы обоих скриптов будут выглядеть так:

define service{

use generic-service

host_name Linux

service_description Users

is_volatile 0

check_period 24×7

check_command check_snmp_oid!.1.3.6.1.4.1.2021.8.1.101.1!InK12345!20!30!users

}

define service{

use generic-service

host_name Linux

service_description Mail queue

is_volatile 0

check_period 24×7

check_command check_snmp_oid!.1.3.6.1.4.1.2021.8.1.101.2!InK12345!40!80!messages

}

Конечно, в реальном мире скрипты-проверки могут быть гораздо сложнее и возвращать с помощью команды exit коды, указывающие на те или иные проблемы в сети. В этом случае есть возможность с помощью добавочной опции execfix указывать на программу, запускаемую snmpd и отвечающую за попытки автоматического исправления ошибок, обнаруженных проверочным скриптом. К примеру, таким образом можно описать программу исправления аварийного положения с почтовой очередью.

execfix mailqueue /bin/sh /usr/bin/repair_mailqueue.sh

Конечно, эта возможность опциональна, но упомянуть о ней все же стоило. Любопытный читатель может спросить, а что делать, если мой скрипт выводит несколько строк полезной информации, и мне нужно считать их все до единой. Я отвечу, что это не проблема. Нужно всего лишь добавить в snmpd.conf вот такую строку:

exec .1.3.6.1.4.1.2021.50 multi_line_test /bin/sh/tmp/mytest.sh

И создать скрипт /tmp/mytest.sh следующего содержания.

echo "first line"

echo "second line"

exit 5

В результате осмотра ветви .1.3.6.1.4.1.2021.50 можно увидеть следующие данные:

.1.3.6.1.4.1.2021.50.1.1 = INTEGER: 1

.1.3.6.1.4.1.2021.50.2.1 = STRING: "multi_line_test"

.1.3.6.1.4.1.2021.50.3.1 = STRING: "/bin/sh /tmp/mytest.sh"

.1.3.6.1.4.1.2021.50.100.1 = INTEGER: 5

.1.3.6.1.4.1.2021.50.101.1 = STRING: "first line"

.1.3.6.1.4.1.2021.50.101.2 = STRING: "second line"

.1.3.6.1.4.1.2021.50.102.1 = INTEGER: 0

.1.3.6.1.4.1.2021.50.103.1 = ""

Как видите, и такой функционал нам вполне доступен. Следующая возможность, на которую хотелось бы обратить ваше внимание, – функция проверки размера файла. Итак, добавляем в snmpd.conf вот такую надпись:

file /tmp/tinka.txt 12

тем самым указывая, что файл не должен быть более 12 Кб. Затем смотрим, что хранит в себе ветка .iso.org.dod.internet .private.enterprises.ucdavis.fileTable.fileEntry:

fileIndex.1 = INTEGER: 1

fileName.1 = STRING: /tmp/tinka.txt

fileSize.1 = INTEGER: 15 kB

fileMax.1 = INTEGER: 12 kB

fileErrorFlag.1 = INTEGER: true(1)

fileErrorMsg.1 = STRING: /tmp/tinka.txt: size exceeds 12kb (= 15kb)

Написать соответствующий сервис, в общем-то, несложно, если мы хотим самостоятельно проверять размер файла.

define service{

use generic-service

host_name Linux

service_description size of /tmp/tinka.txt

is_volatile 0

check_period 24×7

check_command check_snmp_oid!.1.3.6.1.4.1.2021.15.1.3.1!InK12345!12!20!kbytes

}

Но есть и другой путь: можно опереться на появление кода и сообщения об ошибке в fileErrorFlag и fileErrorMsg. И все же мне кажется, что это не очень удобно.

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

proc httpd 3 6

proc automount 1 1

proc csserver 2

Этими строками мы указываем snmpd, что в системе должно быть от двух до четырех процессов httpd и только один automount. В то же время программа csserver вообще может быть не запущена, но если она все же работает, то процессов не должно быть более двух. Если же минимальный и максимальный пороги не указаны, то процессов может быть сколько угодно. Давайте посмотрим, что snmpd нам скажет в ответ на такие приказания. Для этого открываем ветвь .iso.org.dod.internet.private.enterprises.ucdavis.prTable.prEntry.

prIndex.1 = INTEGER: 1

prIndex.2 = INTEGER: 2

prIndex.3 = INTEGER: 3

prNames.1 = STRING: httpd

prNames.2 = STRING: automount

prNames.3 = STRING: csserver

prMin.1 = INTEGER: 3

prMin.2 = INTEGER: 1

prMin.3 = INTEGER: 0

prMax.1 = INTEGER: 6

prMax.2 = INTEGER: 1

prMax.3 = INTEGER: 3

prCount.1 = INTEGER: 1

prCount.2 = INTEGER: 1

prCount.3 = INTEGER: 0

prErrorFlag.1 = INTEGER: 1

prErrorFlag.2 = INTEGER: 0

prErrorFlag.3 = INTEGER: 0

prErrMessage.1 = STRING: Too few httpd running (# = 1)

prErrMessage.2 = STRING:

prErrMessage.3 = STRING:

prErrFix.1 = INTEGER: 0

prErrFix.2 = INTEGER: 0

prErrFix.3 = INTEGER: 0

prErrFixCmd.1 = STRING:

prErrFixCmd.2 = STRING:

prErrFixCmd.3 = STRING:

Надеюсь, смысл приведенных данных всем ясен. Тут, как всегда, возможно два пути для слежения: самим контролировать значения из подветви prCount, либо опираться на код ошибки prErrorFlag и сообщение в prErrMessage. По аналогии с execfix можно использовать ключевое слово procfix для описания программы, запускаемой в случае, если с тем или иным процессом стряслось что-то неладное. Я думаю, что на основе примеров, приведенных выше, вы сможете легко самостоятельно написать определения нужных сервисов. Следующей интересной для нас веткой является .iso.org.dod.internet.private.enterprises.ucdavis.memory. В ней хранятся подробные данные о состоянии оперативной памяти. Для моей машины эта ветвь выглядит так:

memIndex.0 = INTEGER: 0

memErrorName.0 = STRING: swap

memTotalSwap.0 = INTEGER: 216836

memAvailSwap.0 = INTEGER: 209784

memTotalReal.0 = INTEGER: 54156

memAvailReal.0 = INTEGER: 9320

memTotalFree.0 = INTEGER: 219104

memMinimumSwap.0 = INTEGER: 16000

memShared.0 = INTEGER: 0

memBuffer.0 = INTEGER: 5728

memCached.0 = INTEGER: 13832

memSwapError.0 = INTEGER: 0

memSwapErrorMsg.0 = STRING:

Наибольший интерес вызывают OID memTotalSwap mem AvailSwap, означающие общий размер свопа и его свободную часть. Затем стоит обратить внимание на memTotalReal и memAvailReal, указывающие на размер физической памяти. Перспективнее всего следить за memAvailReal и memAvailSwap. Но тут есть определенные проблемы. Дело в том, что исчерпание физической памяти еще не означает для системы каких-то ужасных последствий, все ненужное в данный момент будет складироваться в своп. Поэтому выводить предупреждения по поводу того, что физическая память закончилась, не стоит. Сервис, следящей за этим компонентом системы, должен выглядеть так:

define service{

use generic-service

host_name Linux

service_description Physical memory Free

is_volatile 0

check_period 24×7

check_command check_snmp_oid!.1.3.6.1.4.1.2021.4.6.0!InK12345!""!""!kbytes!2c

}

И соответственно мониторинг заполнения свопа можно реализовать так же. Но это решение, на мой взгляд, не очень изящно. Можно сделать гораздо лучше. Давайте будем следить за показателем memTotalFree, который показывает общее количество свободной памяти системы. Это весьма удобно, так как он равен сумме memAvailReal и memAvailSwap. Тут возникает некоторая проблема с нетривиальностью проверки. Обычно ситуация обстоит так, что чем больше проверяемая величина, тем ближе мы к критическому порогу, но сейчас все наоборот. Необходимо сказать модулю, что, чем больше памяти нам доступно, тем лучше. Поэтому сервис будет выглядеть так:

define service{

use generic-service

host_name Linux

service_description Total memory Free

is_volatile 0

check_period 24×7

check_command check_snmp_oid!.1.3.6.1.4.1.2021.4.11.0!InK12345!20000:10000!9999:0!kbytes!2c

}

Таким образом, сигнал «предупреждение» будет отправляться, если свободной памяти останется от двадцати до десяти тысяч байт, а критические оповещения появятся, как только планка опустится еще ниже.

Также неплохо было бы следить за сетевыми интерфейсами с помощью ветки .iso.org.dod.internet.mgmt.mib-2. interfaces.ifTable.ifEntry. Думаю, что примеров, приведенных в статье, достаточно, чтобы сделать это самостоятельно.

Разобравшись с проверками сервисов, работающих через snmp 2c, давайте посмотрим, как выполнить все то же самое с помощью третьей версии протокола. Зачем нам это нужно? Все очень просто: с точки зрения безопасности snmp 2с существенно лучше, чем версия 1, но, несмотря на это, в ней все же есть недостатки. Дело в том, что при ее использовании строки сообществ передаются по сети в открытом виде. Думаю, это не то, что нам хотелось бы получить. Изумленный читатель может сказать: «Давайте совсем откажемся от использования 2с». К сожалению, такой идеалистический подход не всегда возможно воплотить в жизнь. Иногда приходится использовать именно 2с, потому что не во всем имеющемся оборудовании есть поддержка третьей версии. К тому же, настройка snmpd для работы с третьей версией snmp – дело весьма нетривиальное. Ниже я расскажу как этого добиться «малой кровью».

Итак, приступим. В основе идеологии безопасности для третьей версии лежит понятие модуля безопасности пользователей USM (User-based Security Module). Он отвечает за хранение списка пользователей и их атрибутов. Соответственно каждый пользователь обозначается уникальным именем в терминах snmp, оно называется securityName. К нему привязываются протокол аутентификации и ключ аутентификации, соответственно, authProtocol и authKey. Вдобавок к этому существует протокол шифрования privProtocol и ключ шифрования privKey. Стоит отметить, что authKey и privKey генерируются на основе пароля, переданного пользователем. Пароль должен содержать не менее восьми символов.

Стандарт snmp версии 3 описывает три вида пакетов. Первый не подписывается и не шифруется. Второй: отправляющая сторона подписывает пакет ключем authKey с помощью протокола authProtocol. В качестве протокола генерации подписи на данный момент могут выступать алгоритмы MD5 или SHA. Третий: подписывает и плюс к этому данные пакета могут шифроваться с помощью протокола privProtocol и ключа privKey. В качестве протокола шифрования пока можно использовать только DES.

Ознакомиться подробнее с идеями, лежащими в основе USM, можно в RFC 2574.

Одной из самых странных идей, с которой приходится сталкиваться, является способ управлением пользователями, применяемый для третьей версии протокола. Для этого существует утилита snmpusm, но создать с ее помощью пользователя с нуля невозможно. Она позволяет лишь клонировать настройки существующего пользователя в атрибуты вновь создаваемого. Налицо проблема курицы и яйца. Нужно создать первого пользователя, но утилита для управления пользователями делать это не умеет.

Несколько раз перечитав man snmpusm, понимаем, что созданием легендарного первопользователя должен заниматься демон snmpd. Ничего не скажешь, весьма сильный ход и главное – какой нечеловеческой логикой это продиктовано.

Итак, нам нужно внести в snmp такие строки:

rwuser initial

rwuser nagios

rouser nagios

createUser initial MD5 t2inKES10er DES

Или их аналог с расширенным описанием VACM:

group MyRWGroup usm nagios

group MyROGroup usm nagios

group MyRWGroup usm initial

access MyRWGroup "" any noauth exact all all none

createUser initial MD5 t2inKES10er DES

Затем перезапускаем snmpd. Пользователь initial будет создан автоматически. В качестве пароля ему указано t2inKES10er, алгоритмом подписи пакетов назначаем MD5, а для шифрования данных используется DES. Создав первого пользователя, мы могли бы на этом остановиться. Но делать этого все же не стоит из соображений безопасности. Поэтому с помощью клонирования создаем нового пользователя по имени nagios.

# snmpusm -v3 -u initial -n "" -l authNoPriv -a MD5 -A t2inKES10er localhost create nagios initial
User successfully created.

Так как он унаследовал все настройки от initial, сразу же меняем ему пароль на что-нибудь труднозапоминаемое вроде R18nm12KDM.

# snmpusm -v3 -u nagios_user -n "" -l authNoPriv -a MD5 -A t2inKES10er localhost passwd t2inKES10er R18nm12KDM

SNMPv3 Key(s) successfully changed.

Затем удаляем из snmpd.conf все упоминания о пользователей initial, а также все строки с MyRWGroup и rwuser. Тем самым мы лишили пользователя initial всех прав и отобрали у пользователя nagios возможность внесения изменений в данные snmp. Не забываем перезапустить демона snmpd, чтобы новые настройки вступили в силу. На сервере мониторинга для проверки выполняем команду:

# snmpget -v3 -u nagios -n "" -a MD5 -A R18nm12KDM -x DES 10.10.21.75 sysUpTime.0
system.sysUpTime.0 = Timeticks: (71318) 0:11:53.18

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

# /usr/local/nagios/libexec/check_snmp -H 10.10.21.75 -o sysUpTime.0 -L authPriv -U nagios_user1 -a MD5 -A R18nm12KDM -X R18nm12KDM -P 3
system.sysUpTime.0 = Timeticks: (71352) 0:11:54.10

Теперь осталось создать описание своей команды check_snmp_oid_v3 в файле checkcommands.cfg. С помощью нее мы будем проводить мониторинг и вызывать модуль check_snmp.

define command{

command_name check_snmp_oid_v3

command_line $USER1$/check_snmp -H $HOSTADDRESS$ -o $ARG1$ -w $ARG2$ -c $ARG3$ -L $ARG4$ -U $ARG5$ -a $ARG6$ \

-A $ARG7$ -X $ARG8$ -u $ARG9$ -l "" -P $ARG10$

}

Теперь давайте создадим сервис Total Memory Free v3 для демонстрации того, как нужно использовать команду check_snmp_oid_v3. Записываем в services.cfg следующие строки:

define service{

use generic-service

host_name Linux

service_description Total memory Free v3

is_volatile 0

check_period 24×7

check_command check_snmp_oid_v3!.1.3.6.1.4.1.2021.4.11.0!20000:10000!9000:0!authPriv!nagios!MD5!R18nm12KDM!R18nm12KDM!kbytes!3

}

Теперь данные будут доставляться к нам в шифрованном виде. Напоследок стоит сказать, что все описания сервисов, предназначенные для сервера Linux, можно скопировать и, изменив имя машины, следить за FreeBSD.

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

им даны имена reddaemon и penguin. Впрочем, стоит заметить, что net-snmp успешно работает и на многих других UNIX-подобных системах:

 

  • HP-UX (9.0, 10.20, 11.0);
  • Ultrix (от 4.2 до 4.5);
  • OSF (3.2, 4.0);
  • Solaris (SPARC/ULTRA от 2.3 до 2.8) (Intel 2.9) SunOS (4.1.4 и выше);
  • NetBSD (от 1.0 до 1.5 alpha);
  • FreeBSD (от 2.2 и выше);
  • Linux (ядра от 1.3 и выше);
  • BSDI (от 2.1 до 4.0.1);
  • AIX (3.2.5, 4.1.5);
  • OpenBSD (2.6, 2.8);
  • OS X (10.1.1, 10.1.2);
  • Irix (от 5.1 до 6.5);
  • QNX 6.2.1A;
  • Dynix/PTX 4.4.

На данный момент идут работы по портированию net-snmp на Windows. В результате уже сейчас можно сказать, что программа работает на 90% при условии компиляции с помощью Visual C++ и cygwin32. Отсюда можно сделать вывод, что, приложив некоторые усилия, мы смогли бы мониторить любую из этих операционных систем, благо процедуры установки и настройки net-snmp для каждой из них почти не отличаются друг от друга. Первым делом на сервере мониторинга, работающем под FreeBSD, устанавливаем самую новую версию пакетов net-snmp и nagios-plugins. # cd /usr/ports/net-mgmt/net-snmp # make install clean # cd /usr/ports/net-mgmt/nagios-plugins # make install clean Пакет net-snmp4, все еще присутствующий в дереве портов, устанавливать не стоит из-за сильной устарелости. На подопытных серверах также необходимо проинсталлировать net-snmp. Для FreeBSD это делается вышеуказанным способом, но nagios-plugins ставить не следует. Для ALT Linux 2.3 требуется выполнить следующие команды. # apt-get update # apt-get install net-snmp net-snmp-utils На этом процедуру инсталляции можно считать завершенной. Для того чтобы система могла отвечать на SNMP-запросы, внутри нее должен работать демон snmpd. Ему, как и всем порядочным программам, для успешного функционирования необходимо иметь конфигурационный файл. В качестве такового обычно выступает snmpd.conf. При работе с Linux он, как правило, располагается в /etc/snmp/, а для FreeBSD соответственно актуальна директория /usr/local/etc/. Файл конфигурации одинаков для всех Unix систем, поэтому мы изучим его на примере, используемом для Linux. # Местонахождение системы в реальном мире syslocation Rostov-on-Don Kranoarmejskaya str. Building 1 testlab 407 # Контакты администратора syscontact Andrew Beshkov admin@example.com tel. 390-34-89 # Сервисы, предоставляемые системой sysservices = 79 Думаю, что есть необходимость подробно объяснить процедуру, с помощью которой рассчитывается содержимое переменной sysservices. Нужно выбрать из списка уровень и подставить его номер вместо L в формулу 2L-1.

  1. physical (концентраторы);
  2. datalink/subnetwork (мосты);
  3. internet (IP-шлюзы);
  4. end-to-end (IP-хост);
  5. OSI (протоколы OSI);
  6. OSI (протоколы OSI);
  7. applications (SMTP, POP3 и прочие сервисы).

К примеру, для маршрутизатора расчет будет выглядеть так: 23-1=4. А для обычного хоста 24-1 + 27-1 = 72. Если вы хотите мониторить все уровни, то лучше всего использовать цифру 79. Можно создать файлы конфигурации с помощью программы snmpconf, но я предпочитаю делать все самостоятельно. По крайней мере, так достигается глубинное понимание механизмов работы используемого программного обеспечения. Следующим интересным моментом является безопасность. В традиционном SNMP для версий протокола 1 и 2с за нее отвечают строки сообществ (community strings). Их стоит воспринимать как своеобразные аналоги паролей. Сообщества бывают двух видов – private и public. Отличаются они друг от друга лишь тем, что первое позволяет изменять данные внутри наблюдаемого устройства, а второе дает возможность только просматривать их. Самым простым способом определить эти сообщества является внесение в конфигурационный файл следующих строк: rocommunity InK12345 rwcommunity 12r341289j Как вы уже могли догадаться, rocommunity дает право читать данные, а rwcommunity предоставляет полный доступ. Впрочем rwcommunity тоже можно удалить, если вы не собираетесь изменять данные внутри устройства с помощью snmp. Вышеприведенные опции составляют минимальный рабочий файл конфигурации. Но квалифицированные системные администраторы обычно так не делают, потому что иначе будет трудно различать это устройство среди огромного множества других SNMP-приборов. Итак, давайте посмотрим, что за сведения могут предоставить нам подопытные устройства. Для этого запускаем на них демон snmpd. Чтобы это сделать, кладем на Linux-машине файл snmpd.conf в /etc/snmp и затем выполняем следующую команду: # service snmpd start Если есть желание, чтобы демон стартовал автоматически при запуске машины, выполняем еще и такую команду: # chkconfig snmpd on И обязательно убеждаемся в успешности выполнения предыдущей команды с помощью: # chkconfig snmpd —list Для FreeBSD файл с настройками должен находиться в /usr/local/etc/snmp/. Кроме этого, нужно включить запуск демона в скрипте /usr/local/etc/rc.d/snmpd.sh. Чтобы это сделать, ищем внутри него строку snmpd_enable= «NO» и вписываем в нее слово «YES». Затем вручную запускаем демон. # /usr/local/etc/rc.d/snmpd.s Стоит отметить тот факт, что, кроме snmpd, в комплект net-snmp входит демон snmptrapd, отвечающий за обработку SNMP-ловушек. По умолчанию он выключен, стоит помнить, что в системе не должно работать ненужного программного обеспечения, поэтому без особой надобности не будем его включать. Говорить о том, как можно использовать эти самые ловушки, мы будем в следующей статье. Теперь можно проверить, что за сведения предоставляют наши сервера. Сделать это можно как минимум двумя способами. C помощью утилит командной строки snmpget или snmpwalk. # snmpwalk -m ALL -c InK12345 -v1 penguin .iso.org.dod.internet.mgmt.mib-2.system SNMPv2-MIB::sysDescr.0 = STRING: Linux altlinux.unreal.net 2.4.27-std-up-alt1 #1 Sun Oct 17 22:42:45 MSD 2004 i686 SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10 SNMPv2-MIB::sysUpTime.0 = Timeticks: (1751738) 4:51:57.38 SNMPv2-MIB::sysContact.0 = STRING: Andrew Beshkov SNMPv2-MIB::sysName.0 = STRING: penguin.example.com SNMPv2-MIB::sysLocation.0 = STRING: Rostov-on-Don Kranoarmejskaya str. Building 1 testlab 407 SNMPv2-MIB::sysServices.0 = INTEGER: 0 SNMPv2-MIB::sysORLastChange.0 = Timeticks: (3) 0:00:00.03 SNMPv2-MIB::sysORID.1 = OID: IF-MIB::ifMIB SNMPv2-MIB::sysORID.2 = OID: SNMPv2-MIB::snmpMIB SNMPv2-MIB::sysORID.3 = OID: TCP-MIB::tcpMIB SNMPv2-MIB::sysORID.4 = OID: IP-MIB::ip SNMPv2-MIB::sysORID.5 = OID: UDP-MIB::udpMIB SNMPv2-MIB::sysORID.6 = OID: SNMP-VIEW-BASED-ACM-MIB::vacmBasicGroup SNMPv2-MIB::sysORID.7 = OID: SNMP-FRAMEWORK-MIB::snmpFrameworkMIBCompliance SNMPv2-MIB::sysORID.8 = OID: SNMP-MPD-MIB::snmpMPDCompliance SNMPv2-MIB::sysORID.9 = OID: SNMP-USER-BASED-SM-MIB::usmMIBCompliance SNMPv2-MIB::sysORDescr.1 = STRING: The MIB module to describe generic objects for network interface sub-layers SNMPv2-MIB::sysORDescr.2 = STRING: The MIB module for SNMPv2 entities SNMPv2-MIB::sysORDescr.3 = STRING: The MIB module for managing TCP implementations SNMPv2-MIB::sysORDescr.4 = STRING: The MIB module for managing IP and ICMP implementations SNMPv2-MIB::sysORDescr.5 = STRING: The MIB module for managing UDP implementations SNMPv2-MIB::sysORDescr.6 = STRING: View-based Access Control Model for SNMP. SNMPv2-MIB::sysORDescr.7 = STRING: The SNMP Management Architecture MIB. SNMPv2-MIB::sysORDescr.8 = STRING: The MIB for Message Processing and Dispatching. SNMPv2-MIB::sysORDescr.9 = STRING: The management information definitions for the SNMP User-based Security Model. Опция –m ALL указывает, что нужно показать все дерево ниже выбранного OID, после -с располагается комьюнити string, затем идут версия snmp-протокола, имя машины и OID запрашиваемой ветви. Стоит отметить, что OID можно записывать разными способами. В большинстве случаев префикс iso.org.dod.internet.mgmt.mib-2. можно не писать, так как он предполагается по умолчанию, соответственно мы получим тот же самый результат, если напишем просто system. Для указания OID вместо длинных названий можно использовать цифровые идентификаторы. К примеру, этот же куст дерева можно адресовать следующей комбинацией цифр .1.3.6.1.2.1.1. Если есть желание увидеть все MIB-дерево, то можно выполнить вышеуказанную команду, вовсе не указывая OID. Думаю, вы будете впечатлены размерами листингов, которые система выведет вам. Использовать командный интерфейс полезно, но, к сожалению, это не всегда помогает получить правильное представление о строении MIB-дерева. В этом нам помогут утилиты, называемые MIB-браузерами. Для Linux и FreeBSD лучше всего подойдет программа mbrowse. Обычно она по умолчанию входит во многие дистрибутивы. В действии эта программа выглядит следующим образом. Nagios Для систем Windows существует достаточно много подобных утилит. О том, какую из них и почему стоит выбрать, я подробно рассказывал в предыдущей статье [1]. Конечно, обилие доступных данных поражает, но все же хотелось бы точно знать, как это использовать с наибольшей выгодой. Давайте вновь вернемся к предмету нашего разговора. Кроме стандартных ветвей, net-snmp создает свою собственную ветвь .iso.org.dod.internet.private. enterprises.ucdavis, которая содержит в себе все необходимые данные. В цифровом формате адрес этой ветви выглядит так: .1.3.6.1.4.1.2021. Стоит отметить, что в некоторых snmp-браузерах (snmp browser) данная ветка может быть недоступна через свое символьное обозначение, но в то же время запросы, выполняемые с помощью цифровых OID, будут вполне работоспособны. Думаю, вы со мной согласитесь, что это немного неудобно, поэтому, чтобы включить распознавание символьных имен, нам нужно будет скопировать MIB-базы из /usr/share/snmp/mibs/в рабочую директорию используемого браузера. Как показывают тесты, все работает достаточно неплохо, но, к сожалению, наша система сейчас отвечает на SNMP-запросы, приходящие с любого IP-адреса. К тому же, по умолчанию используется первая версия протокола SNMP, которая передает все данные в открытом виде. Необходимо это исправить и заодно поднять уровень безопасности. Для этого вносим в файл snmpd.conf следующие строки вместо rocommunity и rwcommunity: com2sec nagios 10.10.21.55/32 InK12345 group MyROGroup v2c nagios view all included .1 80 access MyROGroup "" any noauth exact all none none Стоит отметить, что опции rocommunity и rwcommunity – всего лишь оболочки вокруг более мощного набора команд VACM (Version based Access Control Module), которым мы воспользовались ранее. Таким образом, мы сказали, что система, подвергаемая мониторингу, может принимать SNMP-запросы лишь от машины с адресом 10.10.21.55, которая является сервером мониторинга, и привязали этот адрес к внутреннему имени системы безопасности «nagios». Затем разрешили этому имени символизировать группу MyROGroup, а заодно закрепили за ним право передавать SNMP-команды только с помощью версии протокола 2с. Следующей строкой создали вид на определенную область SNMP-дерева. В данном случае с помощью запросов можно просматривать все, что лежит ниже .1 или .iso. Пользуясь этой опцией, можно ограничить дерево, доступное запросу до одной ветки или даже до единственного OID. И заключительной строкой указываем настройки безопасности для нашей группы MyROGroup. После этого не забываем перезапустить демон SNMP и проверить, как все работает. # snmpwalk –m ALL -c InK12345 -v2с penguin .iso.org.dod.internet.mgmt.mib-2.system Обратите внимание на опцию –v2c. Если все прошло нормально, выполняем ту же команду с –v1 и убеждаемся, что она не возвращает никаких сведений. Как вы, наверное, уже догадались, мы полностью отключили возможность вносить извне изменения в данные, находящиеся внутри наблюдаемого объекта. Выполняем проверку того, как работает модуль check_snmp, установленный на сервере Nagios. К примеру, неплохо было бы посмотреть Uptime системы # /usr/local/nagios/libexec/check_snmp -H penguin -o .1.3.6.1.2.1.3.0 -C InK12345 -P 2c Invalid SNMP version 2c По каким-то странным причинам автор забыл включить в него возможность работы с протоколом версии 2с. Ошибка, говорящая, что эта версия не поддерживается, – не совсем то, что мы ожидали получить, поэтому давайте возьмем в руки большой напильник и самостоятельно поправим модуль check_snmp. Для этого нужно отредактировать файл /usr/ports/net-mgmt/nagios-plugins/work/nagios-plugins-1.3.1/plugins/check_snmp.c. Ищем в нем следующую строку: -P, —protocol=[1|3]\n\ и заменяем ее на: -P, —protocol=[1|2c|3]\n\ Затем, найдя условие такого вида: if (proto == NULL || (strcmp(proto,DEFAULT_PROTOCOL) == 0) ) { /* default protocol version */ asprintf(&proto, DEFAULT_PROTOCOL); asprintf(&authpriv, "%s%s", "-c ", community); } Вставляем после него вот такие строки: else if ( strcmp (proto, "2c") == 0 ) { /* snmpv2c args */ asprintf(&proto, "%s", "2c"); asprintf(&authpriv, "%s%s", "-c ", community); } Проводим перекомпиляцию, а затем и замену старого модуля новым. # make install После этого команда с ключом -P 2c должна отработать нормально. Вписываем в файл checkcommands.cfg описание команды check_snmp_oid, с помощью которой будем проводить мониторинг и вызывать модуль check_snmp. define command{ command_name check_snmp_oid command_line $USER1$/check_snmp -H $HOSTADDRESS$ -o $ARG1$ -C $ARG2$ -w $ARG3$ -c $ARG4$ -u $ARG5$ -l "" -P $ARG6$ } Затем в файле hosts.cfg рассказываем о наших серверах. # Описываем шаблон хоста define host{ name generic-host notifications_enabled 1 event_handler_enabled 1 flap_detection_enabled 1 process_perf_data 1 retain_status_information 1 retain_nonstatus_information 1 max_check_attempts 10 notification_interval 120 notification_period 24×7 notification_options d,u,r register 0 } define host{ use generic-host host_name Linux alias Standard Linux Server address penguin check_command check-host-alive } define host{ use generic-host host_name FreeBSD alias Standart FreeBSD Server address reddaemon check_command check-host-alive } И, конечно же, не забываем причислить их к группе хостов onix-servers, внеся следующие строки в файл host groups.cfg define hostgroup{ hostgroup_name onix-servers alias Onix Servers contact_groups onix-admins members Linux, FreeBSD } Настройку оповещений и контактов пропускаем, так как эта тема обсуждалась ранее неоднократно. Самое время заняться описанием сервисов, за которыми мы будем следить. # Описываем шаблон сервиса define service{ name generic-service active_checks_enabled 1 passive_checks_enabled 1 parallelize_check 1 obsess_over_service 1 check_freshness 0 notifications_enabled 1 event_handler_enabled 1 flap_detection_enabled 1 process_perf_data 1 retain_status_information 1 retain_nonstatus_information 1 notification_interval 120 notification_period 24×7 notification_options w,u,c,r max_check_attempts 3 normal_check_interval 1 retry_check_interval 1 contact_groups onix-admins register 0 } Данный сервис показывает время работы системы с момента последней перезагрузки. Для этого используется OID .iso.org.dod.internet.mgmt.mib-2.system.sysUpTime.0. Почти такого же эффекта можно добиться с помощью .iso.org.dod .internet.mgmt.mib-2.host.hrSystem.hrSystemUptime.0. Хотя тут стоит сделать маленькое примечание: второй OID показывает не время, прошедшее с последнего перезапуска системы, а момент последней инициализации SNMP. define service{ use generic-service host_name Linux service_description System Uptime is_volatile 0 check_period 24×7 check_command check_snmp_oid!.1.3.6.1.2.1.1.3.0!InK12345! ""! ""! ""!2c } Следующим интересным для нас моментом будет совокупность сервисов, отображающих количество занятых блоков разделов /, home, и совокупный процент использованных блоков физической и своп-памяти. Для того чтобы понять, где находятся необходимые сведения, посмотрите ветку .iso.org.dod.internet.mgmt.mib-2.host.hrStorage.hrStorage Table. Принцип анализа ветви довольно прост. В hrStorage Index содержится список уникальных идентификаторов, описывающих каждое устройство. А hrStorageType в свою очередь хранит типы устройств. hrStorageDesc заполнен текстовыми описаниями объектов. Для моей системы это выглядит так: hrStorageDescr.2 = STRING: Real Memory hrStorageDescr.3 = STRING: Swap Space hrStorageDescr.4 = STRING: / hrStorageDescr.5 = STRING: /home hrStorageDescr.6 = STRING: /proc/bus/usb В hrStorageAllocationUnits указан размер блока для каждого из устройств: hrStorageAllocationUnits.2 = INTEGER: 1024 Bytes hrStorageAllocationUnits.3 = INTEGER: 1024 Bytes hrStorageAllocationUnits.4 = INTEGER: 4096 Bytes hrStorageAllocationUnits.5 = INTEGER: 4096 Bytes hrStorageAllocationUnits.6 = INTEGER: 1024 Bytes Ну а hrStorageSize указывает, сколько блоков в каждом устройстве. hrStorageSize.2 = INTEGER: 54156 hrStorageSize.3 = INTEGER: 216836 hrStorageSize.4 = INTEGER: 273087 hrStorageSize.5 = INTEGER: 196780 hrStorageSize.6 = INTEGER: 0 И наконец, самое интересное. Как вы уже, наверное, догадались, hrStorageUsed содержит данные о том, сколько блоков занято на каждом из устройств. hrStorageUsed.2 = INTEGER: 52564 hrStorageUsed.3 = INTEGER: 11220 hrStorageUsed.4 = INTEGER: 235014 hrStorageUsed.5 = INTEGER: 8755 hrStorageUsed.6 = INTEGER: 0 Теперь дело за малым: высчитать, сколько блоков соответствуют заполнению устройств на 80% и 90%. И затем создать на основе этих данных правила проверки. В качестве примера приведем описание сервиса, показывающего, как обстоят дела с заполнением корневого раздела. define service{ use generic-service host_name Linux service_description Space on / is_volatile 0 check_period 24×7 check_snmp_oid!.1.3.6.1.2.1.25.2.3.1.6.4!InK12345!218470!245778!blocks!2c } Надеюсь, что на основе приведенного примера вы сможете создать описание всех необходимых сервисов. В мире UNIX-систем большинство задач можно решить разными способами. Сейчас вы в этом убедитесь. Давайте в очередной раз расширим функциональность демона snmpd, внеся в snmpd.conf следующие строчки. disk / 180000 disk /home 760000 Таким образом, мы указываем, что хотим следить за свободным местом на разделах /и home еще одним способом. Вышеуказанные строки говорят демону snmp, что мы хотим установить флаг ошибки в случае, если на разделе /занято 180 Мб, а /home заполнен на 760 Мб. Впрочем, ничего страшного не случится, если ограничения не устанавливать вовсе. Кстати, стоит отметить, что ограничение можно описывать не только в килобайтах, но и в процентах. Теперь интересующие нас данные находятся внутри ветви .iso.org.dod.internet.private.enterprises.ucdavis.dskTable.dskEntry. Принцип построения таблицы стандартен. Идентификатор dskPath содержит данные об именах разделов. dskPath.1 = STRING: / dskPath.2 = STRING: /home dskDevice устанавливает соответствие между разделами и физическими устройствами диска. dskDevice.1 = STRING: /dev/sda1 dskDevice.2 = STRING: /dev/sda6 В dskMinimum dskMinPercent содержатся пороговые значения для поднятия флага ошибки. Соответственно, dskTotal, dskAvail, dskUsed отображают общее, доступное и задействованное пространство дисков. Следующая ветвь, называемая dskPercent, для нас наиболее интересна, так как содержит величину заполнения дисков в процентах. dskPercent.1 = INTEGER: 86 dskPercent.2 = INTEGER: 4 Именно ее мы и будем контролировать. Конечно, можно контролировать состояние ветвей dskErrorFlag и dskErrorMsg. dskErrorFlag.1 = INTEGER: 1 dskErrorFlag.2 = INTEGER: 0 dskErrorMsg.1 = STRING: /: less than 80% free (= 86%) dskErrorMsg.2 = STRING: Но это не очень удобно, так как в этом случае у системы есть лишь два состояния – «нормальное» и «критическое». Соответственно, нет промежуточного перехода в виде состояния «предупреждение». Разобравшись с теорией, давайте создадим сервис, который будет контролировать состояние раздела /новым способом. define service{ use generic-service host_name Linux service_description Space on / check 2 is_volatile 0 check_period 24×7 check_command check_snmp_oid!.1.3.6.1.4.1.2021.9.1.9.1!InK12345!80!90!% } Думаю, создать сервисы, выполняющие проверку остальных разделов, вы сможете сами. Идем дальше. Если мы хотим следить за загрузкой процессора, добавляем в snmpd.conf вот это: load 12 20 30 Этой строкой мы говорим демону, что желаем видеть статистику нагрузки на процессор за последнюю минуту, за пять и пятнадцать минут. К сожалению, интервалы жестко закодированы, и изменить их невозможно. И, как обычно, указываем необязательные пороговые ограничения в 12%, 20% и 30%, при превышении которых snmpd будет устанавливать флаг ошибки. Смотрим ветку .iso.org.dod. internet.private.enterprises.ucdavis.laTable.laEntry и понимаем, что нам наиболее интересны подветви laLoad, laLoadInt, laLoadFloat. В этих подветках содержатся одни и те же данные, но с разным округлением. Соответственно сервис для проверки загрузки процессора за последнюю минуту будет выглядеть вот так: define service{ use generic-service host_name Linux service_description CPU Load 1 min is_volatile 0 check_period 24×7 check_command check_snmp_oid!.1.3.6.1.4.1.2021.10.1.5.1!InK12345!60!90!% } Следующей интересной для нас особенностью является возможность запускать сторонние скрипты при получении того или иного SNMP-запроса. И опять добавляем в snmpd.conf новые строки: exec users /bin/sh /usr/bin/count_users.sh exec mailqueue /bin/sh /usr/bin/count_mail.sh Затем создаем файлы count_users.sh count_mail.sh:, с их помощью мы будем считать количество пользователей, работающих на данный момент в системе, и размер почтовой очереди postfix. Содержимое файла count_users.sh: who | wc -l exit 0 Содержимое файла count_mail.sh: mailq | tail -n 1 | cut -f5 -d " " exit 0 Теперь смотрим, что у нас находится внутри ветки .iso.org.dod.internet.private.enterprises.ucdavis.extTable.extEntry. \extNames.1 = STRING: users extNames.2 = STRING: mailqueue extCommand.1 = STRING: /bin/sh /usr/bin /count_users.sh extCommand.2 = STRING: /bin/sh / usr/bin/count_mail.sh extResult.1 = INTEGER: 0 extResult.2 = INTEGER: 0 extOutput.1 = STRING: 1 extOutput.2 = STRING: 2 extErrFix.1 = INTEGER: 0 extErrFix.2 = INTEGER: 0 extErrFixCmd.1 = STRING: extErrFixCmd.2 = STRING: Нас интересует extOutput, в которой находится первая строка из того, что скрипт выводит на экран, и extResult с кодом возврата скрипта, переданным командой exit. Судя по приведенному выше списку значений, у нас в системе находится один пользователь, а в почтовой очереди есть два письма. Сервисы для проверки результатов работы обоих скриптов будут выглядеть так: define service{ use generic-service host_name Linux service_description Users is_volatile 0 check_period 24×7 check_command check_snmp_oid!.1.3.6.1.4.1.2021.8.1.101.1!InK12345!20!30!users } define service{ use generic-service host_name Linux service_description Mail queue is_volatile 0 check_period 24×7 check_command check_snmp_oid!.1.3.6.1.4.1.2021.8.1.101.2!InK12345!40!80!messages } Конечно, в реальном мире скрипты-проверки могут быть гораздо сложнее и возвращать с помощью команды exit коды, указывающие на те или иные проблемы в сети. В этом случае есть возможность с помощью добавочной опции execfix указывать на программу, запускаемую snmpd и отвечающую за попытки автоматического исправления ошибок, обнаруженных проверочным скриптом. К примеру, таким образом можно описать программу исправления аварийного положения с почтовой очередью. execfix mailqueue /bin/sh /usr/bin/repair_mailqueue.sh Конечно, эта возможность опциональна, но упомянуть о ней все же стоило. Любопытный читатель может спросить, а что делать, если мой скрипт выводит несколько строк полезной информации, и мне нужно считать их все до единой. Я отвечу, что это не проблема. Нужно всего лишь добавить в snmpd.conf вот такую строку: exec .1.3.6.1.4.1.2021.50 multi_line_test /bin/sh/tmp/mytest.sh И создать скрипт /tmp/mytest.sh следующего содержания. echo "first line" echo "second line" exit 5 В результате осмотра ветви .1.3.6.1.4.1.2021.50 можно увидеть следующие данные: .1.3.6.1.4.1.2021.50.1.1 = INTEGER: 1 .1.3.6.1.4.1.2021.50.2.1 = STRING: "multi_line_test" .1.3.6.1.4.1.2021.50.3.1 = STRING: "/bin/sh /tmp/mytest.sh" .1.3.6.1.4.1.2021.50.100.1 = INTEGER: 5 .1.3.6.1.4.1.2021.50.101.1 = STRING: "first line" .1.3.6.1.4.1.2021.50.101.2 = STRING: "second line" .1.3.6.1.4.1.2021.50.102.1 = INTEGER: 0 .1.3.6.1.4.1.2021.50.103.1 = "" Как видите, и такой функционал нам вполне доступен. Следующая возможность, на которую хотелось бы обратить ваше внимание, – функция проверки размера файла. Итак, добавляем в snmpd.conf вот такую надпись: file /tmp/tinka.txt 12 тем самым указывая, что файл не должен быть более 12 Кб. Затем смотрим, что хранит в себе ветка .iso.org.dod.internet .private.enterprises.ucdavis.fileTable.fileEntry: fileIndex.1 = INTEGER: 1 fileName.1 = STRING: /tmp/tinka.txt fileSize.1 = INTEGER: 15 kB fileMax.1 = INTEGER: 12 kB fileErrorFlag.1 = INTEGER: true(1) fileErrorMsg.1 = STRING: /tmp/tinka.txt: size exceeds 12kb (= 15kb) Написать соответствующий сервис, в общем-то, несложно, если мы хотим самостоятельно проверять размер файла. define service{ use generic-service host_name Linux service_description size of /tmp/tinka.txt is_volatile 0 check_period 24×7 check_command check_snmp_oid!.1.3.6.1.4.1.2021.15.1.3.1!InK12345!12!20!kbytes } Но есть и другой путь: можно опереться на появление кода и сообщения об ошибке в fileErrorFlag и fileErrorMsg. И все же мне кажется, что это не очень удобно. Напоследок хотелось бы рассказать о возможности слежения за количеством процессов того или иного приложения, работающих в системе. proc httpd 3 6 proc automount 1 1 proc csserver 2 Этими строками мы указываем snmpd, что в системе должно быть от двух до четырех процессов httpd и только один automount. В то же время программа csserver вообще может быть не запущена, но если она все же работает, то процессов не должно быть более двух. Если же минимальный и максимальный пороги не указаны, то процессов может быть сколько угодно. Давайте посмотрим, что snmpd нам скажет в ответ на такие приказания. Для этого открываем ветвь .iso.org.dod.internet.private.enterprises.ucdavis.prTable.prEntry. prIndex.1 = INTEGER: 1 prIndex.2 = INTEGER: 2 prIndex.3 = INTEGER: 3 prNames.1 = STRING: httpd prNames.2 = STRING: automount prNames.3 = STRING: csserver prMin.1 = INTEGER: 3 prMin.2 = INTEGER: 1 prMin.3 = INTEGER: 0 prMax.1 = INTEGER: 6 prMax.2 = INTEGER: 1 prMax.3 = INTEGER: 3 prCount.1 = INTEGER: 1 prCount.2 = INTEGER: 1 prCount.3 = INTEGER: 0 prErrorFlag.1 = INTEGER: 1 prErrorFlag.2 = INTEGER: 0 prErrorFlag.3 = INTEGER: 0 prErrMessage.1 = STRING: Too few httpd running (# = 1) prErrMessage.2 = STRING: prErrMessage.3 = STRING: prErrFix.1 = INTEGER: 0 prErrFix.2 = INTEGER: 0 prErrFix.3 = INTEGER: 0 prErrFixCmd.1 = STRING: prErrFixCmd.2 = STRING: prErrFixCmd.3 = STRING: Надеюсь, смысл приведенных данных всем ясен. Тут, как всегда, возможно два пути для слежения: самим контролировать значения из подветви prCount, либо опираться на код ошибки prErrorFlag и сообщение в prErrMessage. По аналогии с execfix можно использовать ключевое слово procfix для описания программы, запускаемой в случае, если с тем или иным процессом стряслось что-то неладное. Я думаю, что на основе примеров, приведенных выше, вы сможете легко самостоятельно написать определения нужных сервисов. Следующей интересной для нас веткой является .iso.org.dod.internet.private.enterprises.ucdavis.memory. В ней хранятся подробные данные о состоянии оперативной памяти. Для моей машины эта ветвь выглядит так: memIndex.0 = INTEGER: 0 memErrorName.0 = STRING: swap memTotalSwap.0 = INTEGER: 216836 memAvailSwap.0 = INTEGER: 209784 memTotalReal.0 = INTEGER: 54156 memAvailReal.0 = INTEGER: 9320 memTotalFree.0 = INTEGER: 219104 memMinimumSwap.0 = INTEGER: 16000 memShared.0 = INTEGER: 0 memBuffer.0 = INTEGER: 5728 memCached.0 = INTEGER: 13832 memSwapError.0 = INTEGER: 0 memSwapErrorMsg.0 = STRING: Наибольший интерес вызывают OID memTotalSwap mem AvailSwap, означающие общий размер свопа и его свободную часть. Затем стоит обратить внимание на memTotalReal и memAvailReal, указывающие на размер физической памяти. Перспективнее всего следить за memAvailReal и memAvailSwap. Но тут есть определенные проблемы. Дело в том, что исчерпание физической памяти еще не означает для системы каких-то ужасных последствий, все ненужное в данный момент будет складироваться в своп. Поэтому выводить предупреждения по поводу того, что физическая память закончилась, не стоит. Сервис, следящей за этим компонентом системы, должен выглядеть так: define service{ use generic-service host_name Linux service_description Physical memory Free is_volatile 0 check_period 24×7 check_command check_snmp_oid!.1.3.6.1.4.1.2021.4.6.0!InK12345!""!""!kbytes!2c } И соответственно мониторинг заполнения свопа можно реализовать так же. Но это решение, на мой взгляд, не очень изящно. Можно сделать гораздо лучше. Давайте будем следить за показателем memTotalFree, который показывает общее количество свободной памяти системы. Это весьма удобно, так как он равен сумме memAvailReal и memAvailSwap. Тут возникает некоторая проблема с нетривиальностью проверки. Обычно ситуация обстоит так, что чем больше проверяемая величина, тем ближе мы к критическому порогу, но сейчас все наоборот. Необходимо сказать модулю, что, чем больше памяти нам доступно, тем лучше. Поэтому сервис будет выглядеть так: define service{ use generic-service host_name Linux service_description Total memory Free is_volatile 0 check_period 24×7 check_command check_snmp_oid!.1.3.6.1.4.1.2021.4.11.0!InK12345!20000:10000!9999:0!kbytes!2c } Таким образом, сигнал «предупреждение» будет отправляться, если свободной памяти останется от двадцати до десяти тысяч байт, а критические оповещения появятся, как только планка опустится еще ниже. Также неплохо было бы следить за сетевыми интерфейсами с помощью ветки .iso.org.dod.internet.mgmt.mib-2. interfaces.ifTable.ifEntry. Думаю, что примеров, приведенных в статье, достаточно, чтобы сделать это самостоятельно. Разобравшись с проверками сервисов, работающих через snmp 2c, давайте посмотрим, как выполнить все то же самое с помощью третьей версии протокола. Зачем нам это нужно? Все очень просто: с точки зрения безопасности snmp 2с существенно лучше, чем версия 1, но, несмотря на это, в ней все же есть недостатки. Дело в том, что при ее использовании строки сообществ передаются по сети в открытом виде. Думаю, это не то, что нам хотелось бы получить. Изумленный читатель может сказать: «Давайте совсем откажемся от использования 2с». К сожалению, такой идеалистический подход не всегда возможно воплотить в жизнь. Иногда приходится использовать именно 2с, потому что не во всем имеющемся оборудовании есть поддержка третьей версии. К тому же, настройка snmpd для работы с третьей версией snmp – дело весьма нетривиальное. Ниже я расскажу как этого добиться «малой кровью». Итак, приступим. В основе идеологии безопасности для третьей версии лежит понятие модуля безопасности пользователей USM (User-based Security Module). Он отвечает за хранение списка пользователей и их атрибутов. Соответственно каждый пользователь обозначается уникальным именем в терминах snmp, оно называется securityName. К нему привязываются протокол аутентификации и ключ аутентификации, соответственно, authProtocol и authKey. Вдобавок к этому существует протокол шифрования privProtocol и ключ шифрования privKey. Стоит отметить, что authKey и privKey генерируются на основе пароля, переданного пользователем. Пароль должен содержать не менее восьми символов. Стандарт snmp версии 3 описывает три вида пакетов. Первый не подписывается и не шифруется. Второй: отправляющая сторона подписывает пакет ключем authKey с помощью протокола authProtocol. В качестве протокола генерации подписи на данный момент могут выступать алгоритмы MD5 или SHA. Третий: подписывает и плюс к этому данные пакета могут шифроваться с помощью протокола privProtocol и ключа privKey. В качестве протокола шифрования пока можно использовать только DES. Ознакомиться подробнее с идеями, лежащими в основе USM, можно в RFC 2574. Одной из самых странных идей, с которой приходится сталкиваться, является способ управлением пользователями, применяемый для третьей версии протокола. Для этого существует утилита snmpusm, но создать с ее помощью пользователя с нуля невозможно. Она позволяет лишь клонировать настройки существующего пользователя в атрибуты вновь создаваемого. Налицо проблема курицы и яйца. Нужно создать первого пользователя, но утилита для управления пользователями делать это не умеет. Несколько раз перечитав man snmpusm, понимаем, что созданием легендарного первопользователя должен заниматься демон snmpd. Ничего не скажешь, весьма сильный ход и главное – какой нечеловеческой логикой это продиктовано. Итак, нам нужно внести в snmp такие строки: rwuser initial rwuser nagios rouser nagios createUser initial MD5 t2inKES10er DES Или их аналог с расширенным описанием VACM: group MyRWGroup usm nagios group MyROGroup usm nagios group MyRWGroup usm initial access MyRWGroup "" any noauth exact all all none createUser initial MD5 t2inKES10er DES Затем перезапускаем snmpd. Пользователь initial будет создан автоматически. В качестве пароля ему указано t2inKES10er, алгоритмом подписи пакетов назначаем MD5, а для шифрования данных используется DES. Создав первого пользователя, мы могли бы на этом остановиться. Но делать этого все же не стоит из соображений безопасности. Поэтому с помощью клонирования создаем нового пользователя по имени nagios. # snmpusm -v3 -u initial -n "" -l authNoPriv -a MD5 -A t2inKES10er localhost create nagios initial User successfully created. Так как он унаследовал все настройки от initial, сразу же меняем ему пароль на что-нибудь труднозапоминаемое вроде R18nm12KDM. # snmpusm -v3 -u nagios_user -n "" -l authNoPriv -a MD5 -A t2inKES10er localhost passwd t2inKES10er R18nm12KDM SNMPv3 Key(s) successfully changed. Затем удаляем из snmpd.conf все упоминания о пользователей initial, а также все строки с MyRWGroup и rwuser. Тем самым мы лишили пользователя initial всех прав и отобрали у пользователя nagios возможность внесения изменений в данные snmp. Не забываем перезапустить демона snmpd, чтобы новые настройки вступили в силу. На сервере мониторинга для проверки выполняем команду: # snmpget -v3 -u nagios -n "" -a MD5 -A R18nm12KDM -x DES 10.10.21.75 sysUpTime.0 system.sysUpTime.0 = Timeticks: (71318) 0:11:53.18 Из полученного ответа можно сделать вывод, что передача и обработка шифрованных и подписанных snmp пакетов работает как следует. Теперь давайте протестируем как модуль check_snmp умеет выполнять запросы с помощью третьей версии snmp. # /usr/local/nagios/libexec/check_snmp -H 10.10.21.75 -o sysUpTime.0 -L authPriv -U nagios_user1 -a MD5 -A R18nm12KDM -X R18nm12KDM -P 3 system.sysUpTime.0 = Timeticks: (71352) 0:11:54.10 Теперь осталось создать описание своей команды check_snmp_oid_v3 в файле checkcommands.cfg. С помощью нее мы будем проводить мониторинг и вызывать модуль check_snmp. define command{ command_name check_snmp_oid_v3 command_line $USER1$/check_snmp -H $HOSTADDRESS$ -o $ARG1$ -w $ARG2$ -c $ARG3$ -L $ARG4$ -U $ARG5$ -a $ARG6$ \ -A $ARG7$ -X $ARG8$ -u $ARG9$ -l "" -P $ARG10$ } Теперь давайте создадим сервис Total Memory Free v3 для демонстрации того, как нужно использовать команду check_snmp_oid_v3. Записываем в services.cfg следующие строки: define service{ use generic-service host_name Linux service_description Total memory Free v3 is_volatile 0 check_period 24×7 check_command check_snmp_oid_v3!.1.3.6.1.4.1.2021.4.11.0!20000:10000!9000:0!authPriv!nagios!MD5!R18nm12KDM!R18nm12KDM!kbytes!3 } Теперь данные будут доставляться к нам в шифрованном виде. Напоследок стоит сказать, что все описания сервисов, предназначенные для сервера Linux, можно скопировать и, изменив имя машины, следить за FreeBSD. На этой радостной ноте хотелось бы попрощаться, а заодно пообещать, что в следующей статье мы будем изучать настройку системы мониторинга для слежения за оборудованием знаменитой фирмы CISCO.

Я думаю каждый из нас озадачивался вопросом мониторинга серверов, потому как узнавать что что то стряслось от пользователей это всё таки признак плохого тона. Давайте рассмотрим систему мониторинга серверов Nagios. Nagios — программа с открытым кодом, предназначенная для мониторинга компьютерных систем и сетей. Она следит за указанными узлами и службами, и оповещает администратора в том случае, если какие-то из служб прекращают (или возобновляют) свою работу. Nagios (произносится как «нагиос»), первоначально созданная под именем Netsaint, разработана Этаном Галстадом (Ethan Galstad). Он же поддерживает и развивает систему сегодня, совместно с командой разработчиков, которые занимаются как официальными, так и неофициальными плагинами. Первоначально Nagios была разработана для работы под GNU/Linux, но она также хорошо работает и под другими Unix-подобными ОС. Nagios распространяется по лицензии GNU General Public License Version 2. Итак что же она может? А может она следующее:

  • Мониторинг сетевых служб (SMTP, POP3, HTTP, NNTP, ICMP, SNMP)
  • Мониторинг состояния хостов (загрузка процессора, использование диска, системные логи). В большинстве сетевых операционных систем, даже Microsoft Windows с модулем NRPE_NT
  • Поддержка удаленного мониторинга через шифрованные туннели SSH или SSL
  • Простая архитектура модулей расширений (плагинов) позволяет, используя любой язык программирования по выбору (Shell, C++, Perl, Python, PHP, C# и другие), легко разрабатывать свои собственные способы проверки служб
  • Параллельная проверка служб
  • Возможность определять иерархии хостов сети с помощью «родительских» хостов, позволяет обнаруживать и различать хосты, которые вышли из строя, и те, которые недоступны
  • Отправка оповещений в случае возникновения проблем со службой или хостом (с помощью почты, пейджера, смс, или любым другим способом, определенным пользователем через модуль системы)
  • Возможность определять обработчики событий произошедших со службами или хостами для проактивного разрешения проблем
  • Автоматическая ротация лог-файлов
  • Возможность организации совместной работы нескольких систем мониторинга с целью повышения надёжности

Скачать данное чудо можно с официального сайта проекта На данный момент на этом ресурсе уже присутсвуют некоторые статьи по настройке и конфигурированию Nagios, находятся они в разделе Библиотека

Автор Бешков Андрей
Пройдя парадным маршем через установку, настройку и примеры успешного использования Nagios в реальной жизни, мы завоевали для себя довольно просторное место под солнцем. После предыдущих статей у читателей накопилось некоторое количество вопросов. Это значит, что, несмотря на все былые успехи, пришло время прекратить расширять свои владения и перейти на интенсивный путь развития. Слегка замедлим свой бег вперед и займемся благоустройством захваченного пространства.

Как обычно, в начале статьи хотелось бы упомянуть то обстоятельство, что описываемые действия выполнялись на хосте, работающем под управлением FreeBSD 4.8. Однако переживать по это поводу не стоит, так как все обсуждаемые приемы будут отлично работать с любым дистрибутивом Unix-подобных операционных систем, для которых существует версия Nagios. Единственным щекотливым моментом может быть различие в именах директорий, где расположились Nagios и остальное вспомогательное программное обеспечение, необходимое для нашей работы. Надеюсь, с этим мелкими проблемами вы сможете разобраться самостоятельно.

Первым делом хотелось бы научить Nagios говорить на чистом русском языке. Как всегда, вспоминаем, что в этом мире нет ничего невозможного. Примерно девять месяцев назад я завершил работы по локализации Nagios версии 1.06 beta. Затем, по мере выхода новых версий продукта, та же судьба постигла официальные релизы 1.0 и 1.1. Методика русификация для всех версий одинакова, поэтому я буду описывать ее на примере версии 1.1, как наиболее свежей и, надеюсь, наиболее распространенной. Плюс ко всему, именно эта версия установлена у меня.

Итак, что же нам нужно сделать для того чтобы Nagios заговорил по русски? Первым делом скачиваем дистрибутив версии Nagios, которая установлена у вас с официального сайта http://www.nagios.org. Затем здесь htpp://onix.opennet.ru/files/, берем соответствующие файлы локализации.
Распаковываем дистрибутив и пакет локализации в любое удобное место, например в директорию /tmp.

# tar zxvf nagios-1.1.tar.gz
# tar zxvf nagios_rus_1_1.tar.gz
Копируем все необходимые файлы из пакета локализации в распакованный дистрибутив и затем, как обычно, проводим конфигурирование.

# cp -R /tmp/nagios_rus_1_1/* /tmp/nagios-1.1/
# cd nagios-1.1
# ./configure —prefix=/usr/local/nagios —with-cgi-url=/nagios/cgi-bin —with-html-url=/nagios/ \
—with-nagios-user=nagios —with-nagios-grp=nagios —with-gd-lib=/usr/local/lib \
—with-gd-inc=/usr/local/include/gd
Я думаю, объяснять назначение ключей команды configure смысла нет. Поэтому сразу же переходим к компиляции.

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

# /usr/local/etc/nagios.sh stop
Вот теперь можно спокойно выполнять инсталляцию.

# make install
В результате файлы из директории дистрибутива должны заменить те файлы, которые Nagios использовал до сегодняшнего дня. Таким образом, файлы из /tmp/nagios-1.1/html должны попасть в /usr/local/nagios/share/, а скомпилированные файлы из /tmp/nagios-1.1/cgi в /usr/local/nagios/sbin/.

Снова запустив Nagios и обратившись к Web-интерфейсу, должны увидеть что-то вроде такой картинки.

Судя по всему, русификация прошла без сучка-без задоринки.

Следующая проблема, нуждающаяся в исправлении — неработающая карта сети. При попытке воспользоваться пунктами "Карта сети" (statusmap.cgi) и "3D карта сети" (statuswrl.cgi) на экране вместо карты обычно появляется такое меню:

Nagios

Причин этому может быть две. Первая: не работает библиотека GD, которую мы установили вместе с Nagios. И вторая: в используемом нами браузере отсутствует или неправильно работает подключаемый модуль для отображения vrml.

Итак, начнем с первой проблемы. Если вы помните, перед компилированием Nagios мы использовали команду configure. Следует обратить особое внимание на параметры —with-gd-lib и —with-gd-inc, которые указывают на директории, где в нашей системе находятся заголовочные и библиотечные файлы пакета GD. Команда configure пытается автоматически подключить нужные файлы к проекту, но ей не всегда это удается. Обычно в процессе конфигурирования на экран выводятся соответствующие сообщения, но вся проблема в том, что туда же сыпется довольно много прочих диагностических сообщений, и поэтому найти и понять то, что нам нужно в этом винегрете, довольно сложно. Для более точного диагностирования проблемы очистим дистрибутив от файлов, созданных во время предыдущей компиляции командой:

# make clean
Затем перенаправим все сообщения команды configure в файл make.log c помощью следующей конструкции.

# ./configure —prefix=/usr/local/nagios —with-cgi-url=/nagios/cgi-bin —with-html-url=/nagios/ \
—with-nagios-user=nagios —with-nagios-grp=nagios —with-gd-lib=/usr/local/lib \
—with-gd-inc=/usr/local/include/gd > make.log
Если во время компоновки библиотека GD не найдена, то внутри файла make.log среди всего прочего будут вот такие надписи:

checking for gdImagePng in -lgd (order 1)… no
checking for gdImagePng in -lgd (order 2)… no
checking for gdImagePng in -lgd (order 3)… no

*** GD, PNG, and/or JPEG libraries could not be located… *********

Boutell's GD library is required to compile the statusmap, trends
and histogram CGIs. Get it from http://www.boutell.com/gd/, compile
it, and use the —with-gd-lib and —with-gd-inc arguments to specify
the locations of the GD library and include files.

NOTE: In addition to the gd-devel library, you'll also need to make
sure you have the png-devel and jpeg-devel libraries installed
on your system.

NOTE: After you install the necessary libraries on your system:
1. Make sure /etc/ld.so.conf has an entry for the directory in
which the GD, PNG, and JPEG libraries are installed.
2. Run 'ldconfig' to update the run-time linker options.
3. Run 'make clean' in the Nagios distribution to clean out
any old references to your previous compile.
4. Rerun the configure script.

NOTE: If you can't get the configure script to recognize the GD libs
on your system, get over it and move on to other things. The
CGIs that use the GD libs are just a small part of the entire
Nagios package. Get everything else working first and then
revisit the problem. Make sure to check the nagios-users
mailing list archives for possible solutions to GD library
problems when you resume your troubleshooting.

********************************************************************
Ну а в случае, если вам повезло и вы нашли в указанном выше файле вот такое:

checking for gdImagePng in -lgd (order 1)… yes
GD library was found!
Значит с GD у вас все в порядке, и вы можете спокойно пойти попить кофе, пока я расскажу остальным, как избавиться от проблем с этой неуловимой библиотекой. По традиции начинаем с FreeBSD. Посмотреть, устанавливалась ли библиотека GD в эту систему стандартными средствами, то есть с помощью пакетов или портов, можно командой:

# pkg_info | grep gd
gd-1.8.4_6 A graphics library for fast image creation
Теперь мы знаем полное название пакета. Смотрим куда, установились его файлы.

# pkg_-L gd-1.8.4_6

Information for gd-1.8.4_6:

Files:
/usr/local/bin/bdftogd
/usr/local/bin/gd2copypal
/usr/local/bin/gd2topng
/usr/local/bin/gdparttopng
/usr/local/bin/gdtopng
/usr/local/bin/pngtogd
/usr/local/bin/pngtogd2
/usr/local/bin/webpng
/usr/local/include/gd/gd.h
/usr/local/include/gd/gd_io.h
/usr/local/include/gd/gdcache.h
/usr/local/include/gd/gdfontg.h
/usr/local/include/gd/gdfontl.h
/usr/local/include/gd/gdfontmb.h
/usr/local/include/gd/gdfonts.h
/usr/local/include/gd/gdfontt.h
/usr/local/lib/libgd.a
/usr/local/lib/libgd.so
/usr/local/lib/libgd.so.2
/usr/local/share/doc/gd/index.html
Итак, судя по выводу, параметры команды configure, относящиеся к библиотке GD, должны выглядеть так —with-gd-lib=/usr/local/lib —with-gd-inc=/usr/local/include/gd.

Давайте посмотрим, как можно добиться подобного эффекта для Linux-систем, основанных на rpm. В качестве примера возьмем ALT Linux.

# rpm -qa | grep gd
libgd2-devel-2.0.4-alt2
gdm-2.4.4.5-alt1
gdk-pixbuf-loaders-0.22.0-alt2
gdk-pixbuf-0.22.0-alt2
libgd2-2.0.4-alt2
libgda2-1.0.0-alt1
gnome2-utils-gdict-applet-2.4.0-alt2
libgda2-devel-1.0.0-alt1
В отличие от FreeBSD, в Linux системах библиотека GD обычно разделена на два отдельных пакета. Судя по всему, нас интересуют rpm файлы libgd2 и libgd2-devel. Первый содержит динамически загружаемые библиотеки, ну а второй, соответственно, заголовочные файлы.

# rpm -ql libgd2
/usr/lib/libgd.so.2
/usr/lib/libgd.so.2.0.4

# rpm -ql libgd2-devel
/usr/include/gd.h
/usr/include/gd_io.h
/usr/include/gdcache.h
/usr/include/gdfontg.h
/usr/include/gdfontl.h
/usr/include/gdfontmb.h
/usr/include/gdfonts.h
/usr/include/gdfontt.h
/usr/lib/libgd.so
/usr/share/doc/gd-2.0.4
/usr/share/doc/gd-2.0.4/index.html
Ну и наконец, универсальный способ, подходящий для любой Unix-подобной операционной системы. Им можно воспользоваться в случае, если все предыдущие попытки не дали никаких результатов. Нужно самостоятельно отыскать, где находятся файлы libgd.* и gd.h

#find / -name libgd.*
/usr/lib/libgd.so.1.2
/usr/lib/libgd.so.1
/usr/lib/libgd.so

#find / -name gd.h
/usr/include/gd.h
Теперь вы можете уверенно сказать, чему должны быть равны параметры —with-gd-lib и —with-gd-inc команды configure. Выполняем ее со всеми необходимыми настройками и, как описано выше, проверяем, найдена ли библиотека GD. Ну и наконец, проводим компиляцию и инсталляцию, не забыв остановить демона Nagios. После этого карта сети (statusmap.cgi) должна приобрести вид, примерно похожий на этот:

Nagios

Теперь все те, кто ушли пить кофе, могут возвращаться. Сейчас мы начнем починку 3D карты. Не работает она по причине того, что ваш браузер не знает, что делать с vrml файлом, который возвращается в ответ на запросы к скрипту statuswrl.cgi. Для того, чтобы все заработало как положено, нужно установить в используемый браузер модуль для работы с vrml, или отдельную программу, предназначенную для тех же целей.

Программного обеспечения, подходящего работы с VRML (Virtual Reality Modeling Language), написано воз и маленькая тележка. Как обычно, пальма первенства по количеству экземпляров принадлежит Windows. Затем идет MAC OS и, наконец, бронзовое третье место занимает Linux.

Итак, начнем с фаворита. При необходимости работать под управлением Windows и MAC систем я предпочитаю использовать Cortona VRML Client по той простой причине, что он совместим с большинством наиболее распространенных браузеров, к числу которых несомненно относятся Internet Explorer, Netscape Navigator, Mozilla, iCab. Интересным фактом является то обстоятельство, что этот подключаемый модуль можно использовать даже из офисных приложений Microsoft PowerPoint, Microsoft Word. К сожалению, разработчики Cortona почему-то решили полностью проигнорировать Linux. Скачать дистрибутив можно с сайта http://www.parallelgraphics.com/products/cortona/download/. Что делать после совершения этого сакраментального действа, мы обсудим немного позднее.

Следующая достойная нашего внимания программа называемая Cosmo player и живет по этому адресу http://ca.com/cosmo/html/. Работает в виде отдельного приложения и, конечно же, только под Windows и MAC.

ExpressVR-конкурент Cortona для всем известной яблочной платформы. Под другими операционными системами не живет, попыток экспансии не предпринимает и, судя по последним тенденциям, скорее всего, через некоторое время будет окончательно вытеснен своим многофункциональным противником. Предназначен только для Netscape Navigator и Internet Explorer. Скачать дистрибутив можно отсюда http://members.aol.com/maxmac/vrml/download.html.

FreeWRL — отдельное приложение, работающее в качестве самостоятельного vrml браузера. Функционирует на платформах Linix и MAC и располагается по этому адресу http://www.crc.ca/FreeWRL/.

На самом деле, программ, подходящих для наших целей, гораздо больше, чем вы могли бы подумать. Я постарался упомянуть лишь наиболее известные из них. Если же вы хотите непременно огласить весь список, то вам нужно провести поиск по слову vrml на следующие серверах, в народе ласково называемых софтомогильниками:

http://sourceforge.net/
http://freshmeat.net/
http://tucows.com/
http://filesearch.ru/

Ну а здесь http://www.chuvsu.ru/download/vrml/browsers/ можно найти очень неплохую подборку vrml клиентов для Windows. Как говорится, все ароматы Франции в одном флаконе. Надеюсь, что среди подобного разнообразия вы сможете самостоятельно подобрать себе инструмент по вкусу.

Ну а теперь сделаем перерыв в изучении теории и попрактикуемся в том, как правильно провести инсталляцию и использование Cortona VRML Client в связке с браузером Microsoft Internet Explorer. Сделать это можно двумя способами. Начнем с самого простого.

С помощью браузера идем по адресу http://www.parallelgraphics.com/products/cortona/download/ и, выбрав нужный тип браузера, пользуемся кнопкой "online install".

Nagios

Обратите внимание на пустой прямоугольник в центре страницы. Его появление означает, что в вашем браузере нет vrml модуля. Нажимаем на кнопку "Install Now". После того, как процесс скачивания закончится, перед нами появится следующее окно.

Nagios

Жмем "Yes" в знак того, что мы доверяем цифровой подписи ParallelGraphics LTD. Подобный механизм цифровых подписей для всех скачиваемых программ помогает избежать подмены или порчи дистрибутива во время его путешествия через сеть. На следующем экране выставляем во всех окошках галочки. Таким образом, мы назначаем vrml клиента программой по умолчанию для обработки файлов wrl, wrml и wrz.

Nagios

По окончании инсталляции текущая страница в браузере должна обновиться. И в центре нее появится вращающий куб.

Nagios

На этом первый способ инсталляции можно считать оконченным. Если в процессе выполнения этих инструкций что-то пошло не так, как должно было, и установка завершилась неудачно, то огорчаться не стоит. Можно выполнить все требуемые действия вручную. Итак, переходим ко второму способу инсталляции. Скачиваем дистрибутив, подходящий для нашего браузера. После запуска принимаем лицензионное соглашение и несколько раз жмем кнопку "Next". После распаковки файлов на экране должно появиться что-то вроде такой картинки.

Nagios

Система может задуматься на минуту-другую а затем снова очнется и начнет задавать вопросы.

Nagios

Требуется уточнить, каким образом мы будем отрисовывать vrml сцены. Выбирайте один из пунктов в зависимости от программного обеспечения, установленного в вашей системе. Если вы ошибетесь, и у вас нет выбранного компонента, то ничего страшного не произойдет. Система самостоятельно переключит отрисовку в программный режим.

Nagios

Лично я — человек ленивый, и поэтому не люблю читать всяческие readme файлы без нужды, поэтому на следующем экране отключаю такую возможность. А вот во втором окошке галочку лучше оставить нетронутой, потому что это позволит нам проверить, правильно ли работает vrml. Вслед за нажатием кнопки ?Next? на экране появится 3D сцена, изображающая постепенно расцветающую розу.

Nagios

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

Nagios

Для того, чтобы избавиться от этой надоедливой помехи, закрываем окно консоли и щелкаем правой клавишей мыши в середине окна с 3D сценой.

Nagios

В отрывшемся меню выберем пункт "Preferences". А затем, воспользовавшись вкладкой "Render", выбираем альтернативный механизм рендеринга.

Nagios

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

Nagios

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

А теперь вновь одним прыжком вернемся к плоской карте сети statusmap.cgi. Для наглядности давайте представим, что наша система мониторинга наблюдает за сетью, изображенной на следующем рисунке.

Nagios

У нас есть две отдельные подсети, созданные на основе управляемых коммутаторов 3com. Каждому из них выдан собственный ip адрес. Таким образом, мы имеем возможность проверять их работоспособность с помощью подключаемого модуля check_ping. Внутренняя сеть включает в себя следующие компьютеры:

Nagios — система мониторинга
Linux — рабочая станция на основе Linux
Win_2000 — рабочая станция на основе Windows 2000 Professional

Вторая сеть у нас используется как демилитаризованная зона. В нее включены сервера c именами WWW и Mail. Думаю, названия говорят сами за себя, и поэтому неудивительно, что на них запущены сервисы IMAP, POP3, SMTP и HTTP. Между собой сети соединены с помощью машины, фигурирующей под именем Inner_Firewall. Выход в Интернет защищает аппаратный межсетевой экран, называемый Outer_Firewall. В файле hosts.cfg содержатся следующие данные, полностью описывающие нашу сеть и ее хосты:

define host{
name generic-host
notifications_enabled 1
event_handler_enabled 1
flap_detection_enabled 1
process_perf_data 1
retain_status_information 1
retain_nonstatus_information 1
register 0
}

define host{
use generic-host
host_name Win_2000
alias Standard Windows Server
address bianca
parents 3com_Lan
check_command check-host-alive
max_check_attempts 10
notification_interval 120
notification_period 24×7
notification_options d,u,r
}

define host{
use generic-host
host_name Linux
alias Linux Server
address lira
parents 3com_Lan
check_command check-host-alive
max_check_attempts 10
notification_interval 120
notification_period 24×7
notification_options d,u,r
}

define host{
use generic-host
host_name 3com_Lan
alias 3COM inner Lan switch
address 3com-lan
check_command check-host-alive
max_check_attempts 10
notification_interval 120
notification_period 24×7
notification_options d,u,r
}

define host{
use generic-host
host_name Inner_Firewall
alias Firewall PC
parents 3com_Lan
address inner-firewall
check_command check-host-alive
max_check_attempts 10
notification_interval 120
notification_period 24×7
notification_options d,u,r
}

define host{
use generic-host
host_name 3com_Dmz
alias 3COM dmz switch
address 3com-dmz
parents Inner_Firewall
check_command check-host-alive
max_check_attempts 10
notification_interval 120
notification_period 24×7
notification_options d,u,r
}

define host{
use generic-host
host_name Mail
alias Mail Server
address mailer
parents 3com_Dmz
check_command check-host-alive
max_check_attempts 10
notification_interval 120
notification_period 24×7
notification_options d,u,r
}

define host{
use generic-host
host_name WWW
alias WWW Server
address web
parents 3com_Dmz
check_command check-host-alive
max_check_attempts 10
notification_interval 120
notification_period 24×7
notification_options d,u,r
}

define host{
use generic-host
host_name Outer_Firewall
alias Hardware Firewall
address outer-firewall
parents 3com_Dmz
check_command check-host-alive
max_check_attempts 10
notification_interval 120
notification_period 24×7
notification_options d,u,r
}

Я думаю, что цитировать файл services.cfg с описанием сервисов нужды нет, потому что в нем нет ничего интересного, да и для повествования он некритичен, кроме того, каждый из вас может заполнить его нужными сведениями за пять минут. Если же у кого-то из читателей это действо вызывает затруднение, то тогда им прямая дорога в первую статью о Nagios. Прочитать ее можно так же в старых номерах журнала "Системный администратор".

К сожалению, Nagios пока не умеет самостоятельно строить карту сети, более или менее приближенную к реальному расположению наблюдаемых объектов внутри нее. Несмотря на то, что у нас есть две подсети на карте, все машины отображаются так, как будто они находятся в одном и том же сетевом облаке, то есть все свалено в одну кучу. С одной стороны, это упрощает процедуру рисования карты, но с другой, усложняет жизнь администратора. Представьте себе ситуацию, когда из строя выходит машина Inner_Firewall. При следующем цикле выполнения проверок нас засыплет лавина уведомления о критическом состоянии хостов Inner_Firewall, WWW, Mail, 3com_Dmz и Outer_Firewall. Хотя на самом деле не работает только первый из всех вышеперечисленных компьютеров. Получается, что администратор должен самостоятельно догадаться, что привело к таким массовым сбоям. Для того, чтобы впредь избежать подобных неприятностей, нам необходимо объяснить Nagios, как построена наша сеть и каким образом добираться до ее самых удаленных уголков. Делается это с помощью создания отношений "родитель" — "потомок" между всеми нашими хостами. После таких изменений критические уведомления будут приходить только для компьютера Inner_Firewall, все остальные машины, задействованные в данной проблеме, получат статус "недоступно". Согласитесь, это все-таки более соответствует действительному положению вещей в контролируемых сетях.

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

Nagios

Для правильной диагностики неполадок иерархия должна выглядеть так, как изображено на предыдущей схеме. С точки зрения Nagios, бывают два вида хостов — "локальные" и "удаленные". Локальными считаются те, кто находится в том же сетевом сегменте, что и система мониторинга. Между ними не должно быть ни маршрутизаторов, ни межсетевых экранов. Если бы у нас были неуправляемые коммутаторы, не поддающиеся мониторингу, то локальными хостами считались бы Linux и Win_2000. Но в связи с тем, что между ними есть промежуточное звено в виде коммутатора 3com_Lan, который можно подвергнуть мониторингу, они переходят в разряд удаленных. А единственным локальным становится 3com_Lan.

Добиться этого можно применением тега parents в определении хостов. Стоит обратить внимание на тот странный факт, что фирменная документация в разделе "Determining Status and Reachability of Network Hosts" этот тег почему-то называет parent_hosts. Хотя если покопаться в исходных текстах Nagios, то понимаем, что на самом деле должен быть просто parents. Если в описании хостов неукоснительно придерживаться указания использовать тег parent_host, то при попытке сделать nagios reload для того, чтобы применить изменения в конфигурации, получим вот такие ошибки:

Running configuration check…
Nagios 1.1
Copyright (c) 1999-2003 Ethan Galstad (nagios@nagios.org)
Last Modified: 06-02-2003
License: GPL

Reading configuration data…

Error: Could not add object property in file '/usr/local/nagios/etc/hosts.cfg' on line 74.

***> One or more problems was encountered while processing the config files…

Check your configuration file(s) to ensure that they contain valid
directives and data defintions. If you are upgrading from a previous
version of Nagios, you should be aware that some variables/definitions
may have been removed or modified in this version. Make sure to read
the HTML documentation on the main and host config files, as well as the
'Whats New' section to find out what has changed.

failed — aborting reload.
Ошибка будет именно на той строке, где впервые появляется тег parent_host. Думаю, других доказательств не нужно.

Машины, считающиеся локальными по отношению к Nagios, находятся на одну ступеньку ниже в иерархии, и поэтому не должны использовать тег parents в своем описании. Все остальные машины, относящиеся к группе удаленных, в вышеуказанном теге пишут имя ближайшего родителя. Таким образом, для хостов Inner_Firewall, Linux и Win_2000 родителем является 3com_Lan. В свою очередь, Inner_Firewall указан родителем для 3com_Dmz. А 3com_Dmz выполняет ту же роль для хостов WWW, Outer_Firewall, Mail.

Итак, разобравшись с понятием иерархии, посмотрим, как оно влияет на отображение наших сетей на карте.

Nagios
Nagios
Nagios
Nagios
Nagios

Думаю, выглядит довольно впечатляюще. Какой из способов отображения карты будет использоваться по умолчанию, указывает параметр default_statusmap_layout. Для трехмерной карты такой параметр называется, соответственно, default_statuswrl_layout. Оба этих параметра скрываются внутри файла cgi.cfg. Кроме заметного с первого взгляда лоска, мы, к тому же, приобрели более точное диагностирование сетевых неполадок.

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

Кстати, не забудьте скачать отсюда http://nagios.org/download/extras.html файлы с коллекциями иконок, обычно называемые image packs.

Итак, начнем с файла hostextinfo.cfg.

define hostextinfo{
# Тег, с которого должно начинаться описание хоста

host_name 3com_Lan
# Имя хоста, к которому относится описание

icon_image 3Com.png
# Имя файла иконки, которая будет отображаться рядом с именем хоста
# Иконка может быть в формате GIF, PNG или JPG. Может содержать внутри
# себя прозрачные области. Желательно, чтобы иконки были размером 40×40
# пикселей. Располагаться они должны в директории logos.
# Обычно эта директория находится в /usr/local/nagios/share/images/logos

icon_image_alt 3Com LAN Switch
# Надпись, отображаемая, если web-серверу не удается загрузить иконку

vrml_image 3Com.png
# Имя файла, который будет использоваться как текстура для куба,
# изображающего хост на трехмерной карте.
# Может быть в формате PNG, JPG, GIF. Картинка не должна содержать
# прозрачных областей, иначе это будет выглядеть очень странно. Должна
# храниться в той же директории, что и иконка, описанная тегом icon_image

statusmap_image 3Com.gd2
# Имя файла, где хранится изображение, которое будет использоваться как иконка
# хоста на плоской сетевой карте. Может быть в формате PNG, JPG, GIF,
# но все-таки лучше, если для этого фала будет использоваться формат GD2,
# потому что для каждого цикла рисования карты иконка будет снова и снова
# приводиться к виду, удобному для библиотеки GD. А это значит, что мы будет
# зря выполнять одни и те же бесполезные вычисления. Может содержать внутри
# себя прозрачные области. Желательно чтобы иконки были размером 40×40
# пикселей. Располагаться они должны в директории logos.
# Обычно эта директория находится в /usr/local/nagios/share/images/logos

2d_coords 160,99
# Двумерные координаты точки, в которой будет находиться центр иконки хоста
# на плоской карте. Могут быть только положительными числами.
# Рисование карты начинается из точки 0,0 которая является верхним левым углом карты.
# Координаты перечисляются в следующем порядке x, y,

3d_coords 20.0,32.0,6.0
# Координаты центра куба, символизирующего хост в пространстве трехмерной
# карты. Могут быть как положительными, так и отрицательными числами.
# Размер одной стороны куба 0.5 единиц.
# Отрисовка карты начинается центра трехмерной карты, который
# находится в точке с координатами 0.0, 0.0, 0.0.
# Координаты перечисляются в следующем порядке x, y, z
notes_url http://192.168.80.2/nagios/notes/3com_lan.txt
# Ссылка на адрес, по которому лежит файл c дополнительными сведениями о хосте
# При щелке на специальный значок в браузере будет открыт это файл
# Это полезно для записи всяческих сведений, которые не влезли в стандартный
# шаблон описания хоста Nagios. Например, там можно написать данные, отвечающие
# на вопрос, кто из администраторов отвечает за управление этим сервером. И к кому
# обращаться в случае проблем.
# Обратите внимание на URL, используемый для указания путь к файлу. Для того, чтобы
# файлы с записками можно было хранить на том же хосте, что и Nagios, я создал
# директорию /usr/local/nagios/share/notes, и поэтому мы теперь можем получить к ней доступ
# именно по такому URL.
}

define hostextinfo{
host_name Win_2000
notes_url http://listios.lan.domain.ru/Win_2000.html
# Кстати, стоит отметить, что добавочные записки о хостах могут хранить
# не только на том же хосте, где работает Nagios, но и на любом другом.
# Главное, чтобы там работал web-сервер и URL был правильно прописан
icon_image win40.png
icon_image_alt Windows workstation
vrml_image win40.png
statusmap_image win40.gd2
2d_coords 163,195
3d_coords 15.0,38.0,6.0
}

define hostextinfo{
host_name Linux
notes_url http://10.10.5.7/hostinfo.pl?host=Linux1
# В качестве URL для хранения добавочных записок можно использовать даже
# CGI. В зависимости от данных, переданных в запросе, вы будет получать
# сведения о том или ином хосте.
icon_image_alt Linux Workstation
vrml_image mandrake.gd2
statusmap_image mandrake.gd2
2d_coords 60,198
3d_coords 30.0,38.0,6.0
}

define hostextinfo{
host_name Mail
notes_url http://192.168.80.2/nagios/notes/mail.html
icon_image MailServer.png
icon_image_alt Mail Server
vrml_image MailServer.png
statusmap_image MailServer.gd2
2d_coords 520,183
3d_coords 20.0,44.0,6.0
}

define hostextinfo{
host_name WWW
notes_url http://192.168.80.2/nagios/notes/www_notes.html
icon_image openbsd.png
icon_image_alt WWW Server
vrml_image openbsd.gd2
statusmap_image openbsd.gd2
2d_coords 439,186
3d_coords 20.0,54.0,6.0
}

define hostextinfo{
host_name Inner_Firewall
notes_url http://192.168.80.2/nagios/notes/inner_fw_notes.html
icon_image freebsd40.png
icon_image_alt Inner Firewall
vrml_image freebsd40.png
statusmap_image freebsd40.gd2
2d_coords 326,96
3d_coords 17.0,55.0,6.0
}

define hostextinfo{
host_name Outer_Firewall
notes_url http://192.168.80.2/nagios/notes/outer_fw_notes.html
icon_image firebox_small.png
icon_image_alt Outer Firewall
vrml_image firebox_small.png
statusmap_image firebox_small.gd2
2d_coords 620,80
3d_coords 16.0,42.0,6.0
}

define hostextinfo{
host_name 3com_Dmz
notes_url http://192.168.80.2/nagios/notes/3com_dmz.html
icon_image 3Com.png
icon_image_alt 3Com DMZ LAN Switch
vrml_image 3Com.png
statusmap_image 3Com.gd2
2d_coords 480,73
3d_coords 14.0,56.0,6.0
}

Теперь пришло самое время обсудить содержимое файла serviceextinfo.cfg. Принципы построения обоих файлов довольно схожи.

define serviceextinfo{
host_name WWW
# Имя хоста,на котором работает сервис

service_description HTTP
# Имя сервиса из файла services.cfg

notes_url http://192.168.80.2/nagios/notes/service_www.html
# Уже многократно виденный нами URL для дополнительных записок

icon_image apache.png
# Имя файла иконки, которая будет отображаться рядом с именем сервиса
# Иконка может быть в формате GIF, PNG или JPG. Может содержать внутри
# себя прозрачные области. Желательно, чтобы иконки были размером 40×40
# пикселей. Располагаться они должны в директории logos.
# Обычно эта директория находится в /usr/local/nagios/share/images/logos

icon_image_alt Web Service
# Надпись, отображаемая, если web-серверу не удается загрузить иконку привязанную,
# к сервису
}

define serviceextinfo{
host_name WWW
service_description SMTP
notes_url http://192.168.80.2/nagios/notes/service_www.html
icon_image apache.png
icon_image_alt Web Service
}

define serviceextinfo{
host_name Mail
service_description SMTP
notes_url http://192.168.80.2/nagios/notes/service_smtp.html
icon_image smtp.png
icon_image_alt Web Service
}

define serviceextinfo{
host_name Mail
service_description POP3
notes_url http://192.168.80.2/nagios/notes/service_pop3.html
icon_image pop3_imap.png
icon_image_alt Web Service
}

define serviceextinfo{
host_name Mail
service_description IMAP
notes_url http://192.168.80.2/nagios/notes/service_imap.html
icon_image pop3_imap.png
icon_image_alt Web Service
}

Для того, чтобы Nagios увидел созданные нами фалы hostextinfo.cfg, serviceextinfo.cfg, нужно внести в файл cgi.cfg следующие директивы.

xedtemplate_config_file=/usr/local/nagios/etc/hostextinfo.cfg
xedtemplate_config_file=/usr/local/nagios/etc/serviceextinfo.cfg
Я думаю, вы сможете самостоятельно положить файлы иконок в директорию /usr/local/nagios/share/images/logos/. Кстати, стоит обязательно убедиться, что все файлы, создаваемые вами, принадлежат пользователю, от имени которого работает Nagios, иначе вы будете очень долго недоумевать, почему никаких изменений в картах не видно, хотя все сделано точно, как в этой статье. К таким файлам относятся hostextinfo.cfg serviceextinfo.cfg иконки, записки и прочая мелкая живность.

Кстати, создавать самостоятельно файлы иконок в формате библиотеки GD довольно просто. Мы говорили об этих файлах во время обсуждения тега statusmap_image файла hostextinfo.cfg. Для этого нужно взять файлы иконки в формате png и преобразовать его в формат GD с помощью утилиты pngtogd2, поставлявшейся вместе с библиотекой GD. Желательно, чтобы создаваемый файл был сохранен без компрессии изображения. Это позволит увеличить скорость работы функций библиотеки GD, отвечающих за загрузку в память и рисование иконок внутри интерфейса Nagios. Если данные внутри файла не сжаты, значит не нужно тратить время на их распаковку. Учитывая малый размер наших картинок, сжатие не принесет никакой выгоды.

Например, для конвертации файла www.png в www.gd2 нужно подать следующую команду.

$ /usr/local/bin/png2gd2 www.png www.gd2 4000 1
Я думаю, с первыми двумя параметрами все ясно. Третий указывает размер порции кодирования, и четвертый — это, соответственно, наличие компрессии. После некоторого количества наблюдений замечено, что в качестве размера порции кодирования можно писать какое угодно число. Для исходных файлов малого размера, к которым относятся и наши иконки, этот параметр смысла не имеет.

И не забудьте подать процессу nagios команду reload, которая заставит его обновить конфигурацию. Во FreeBSD это обычно делается так /usr/local/etc/rc.d/nagios.sh reload.

Если есть желание, можно нарисовать свои собственные иконки и использовать их вместо стандартных. Я именно так поступил с сервисами HTTP, SMTP, POP3 и IMAP. Для HTTP использовалось перо, потерянное индейцем Apache, а для всех остальных изображение открытого и закрытого почтового конверта. И хотя картинки получились размером чуть более, чем 40×40 пикселей, Nagios работал с ними довольно хорошо. Полюбоваться на результат можно на следующей картинке.

Nagios

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

Nagios

Если нажать на него, то можно почитать дополнительные сведения из файла, который мы описали тегом notes_url.

Координаты точек, в которых должны рисоваться иконки и объекты наших хостов на плоской и трехмерной картах сети, не будут использоваться Nagios до тех пор, пока мы не выставим вот таким образом значения тегов default_statusmap_layout и default_statuswrl_layout в файле cgi.cfg.

default_statusmap_layout=0
default_statuswrl_layout=0
Если все сделали правильно, то плоская карта сети будет выглядеть вот так. Впечатляет, не правда ли?

Nagios

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

Nagios

Ну а если вместо вожделенной карты на экране появилась следующая надпись:
You have not supplied any host drawing coordinates, so you cannot use this layout method.
Read the FAQs for more information on specifying drawing coordinates or select a different layout method.
Значит, вы что-то напутали с тегами координат отрисовки.

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

Все заголовки страниц и вставки делятся на глобальные и локальные. Глобальные действуют на все страницы cgi, а локальные только на те, для которых они были определены. Тексты, записанные в файлах заголовков и разрывов страниц, вставляются в начало и конец тега страницы, создаваемой cgi. Обычно текст страницы после обработки выглядит так:

глобальный заголовок
локальный заголовок
основной текст страницы Nagios
глобальная вставка
локальная вставка
Давайте посмотрим, что нужно сделать для того, чтобы это работало на примере файла status.cgi. В директории /usr/local/nagios/share/ssi нужно создать следующие файлы

common-footer.ssi — файл глобального заголовка
common-header.ssi — файл глобальной вставки
status-footer.ssi — файл локального заголовка
status-header.ssi — файл локальной вставки
Я думаю, все уже сообразили, что имя для файлов локального заголовка и локальной вставки образуется с помощью сращивания имени подопытного файла cgi с надписями -footer.ssi и -header.ssi. Нужно помнить, что содержимое всех вышеперечисленных файлов перед добавлением в целевой файл никак не обрабатывается, то есть создать динамические заголовки и вставки без безумных ухищрений не получится, потому что нет возможности использовать в качестве генератора данных cgi или что-либо другое. Получается, что включаемые файлы должны содержать в себе только чистый html.

Давайте рассмотрим содержимое всех файлов, применявшихся в это примере:

Файл common-footer.ssi

 


 

По вопросам техподдержки обращаться на tigrisha@sysadmins.ru или
http://onix.opennet.ru

Файл common-header.ssi

 


Nagios

Файл status-footer.ssi

 


 

Разделитель страницы status.cgi

 

Файл status-header.ssi

 


 

Тестовый заголовок status.cgi

Как вы могли убедиться, все это работает довольно просто.

Nagios

Еще одной вкусностью, которой я с вами поделюсь, будет способность привязывать проигрывание звуковых файлов к определенным событиям. Например, моя система мониторинга при умирании какого либо сервиса начинает изображать жалобно мычащую корову. Такая возможность очень полезна для администраторов, которые не хотят постоянно смотреть на web-интерфейс Nagios или ежеминутно проверять свой почтовый ящик на предмет уведомлений о проблемах. Нужно всего лишь открыть в браузере или прикрепить на Active Desktop одну из этих страниц tac.cgi, status.cgi. После этого можно минимизировать браузер и заниматься своими делами. Как только случится какое-либо интересующие нас событие, Nagios начнет воспроизводить звук, связанный с ним. Для осуществления наших желаний есть следующие теги:
host_unreachable_sound — хост недоступен
host_down_sound — хост не работает
service_critical_sound — сервис в критическом состоянии
service_warning_sound — сервис в состоянии предупреждения
service_unknown_sound — состояние сервиса неизвестно
normal_sound — все работает отлично, нет никаких проблем
Опцию normal_sound практически никто не использует. Но на всякий случай я решил ее упомянуть. Хотя в некоторых центрах мониторинга ее задействуют для проигрывания тихой спокойной музыки которая указывает что система работает нормально и на экран смотреть не нужно.

Для того чтобы звуковое оповещение заработало, нужно поместить файлы звуков в формате wav внутрь директории /usr/local/nagios/share/media/, как всегда, не забыть о правах пользователя и принадлежности файлов. А затем добавить следующие записи в файл cgi.cfg.

host_unreachable_sound=hostunreachable.wav
host_down_sound=host down.wav
service_critical_sound=servicecritical.wav
service_warning_sound=servicewarning.wav
service_unknown_sound=service unknown.wav
normal_sound=noproblem.wav
В случае,если в процессе мониторинга будет обнаружено одновременно несколько проблем, Nagios начнет проигрывать звук для наиболее кричной из них. После десятка или двух повторений одного и того же звука вам, наверно, захочется отключить звук. Сделать это довольно легко: нужно просто войти в режим управления сервисом или хостом и подать команду подтверждения проблемы.

После подобной обработки записи в таблице сервисов или хостов примут вот такой вид.

Nagios

Автор Бешков Андрей С момента публикации первой статьи о Nagios прошло довольно много времени, но вопросы и пожелания читателей все продолжают приходить. Самый часто встречающийся вопрос как настроить слежение за серверами, работающими под управлением семейства операционных систем Windows. В этой статье мы рассмотрим два способа, используя которые можно добиться осуществления наших желаний. Как всегда система мониторинга Nagios работает под управлением моей любимой системы FreeBSD 4.7. Приверженцы Linux, Solaris и других Unix-подобных систем тоже не останутся в стороне. Все описанные ниже приемы с незначительными изменениями можно с успехом применять и в их системах. В качестве подопытной системы будет использоваться русская версия Windows 2000 Professional. Такой выбор обусловлен тем фактом, что настроить программное обеспечение для исправной работы с русской версией сложнее, чем с аналогичной английской. Придется решать проблемы связанные с локализацией, а значит, статья получится гораздо полезнее и интереснее. Последовательность действий по настройке программного обеспечения выглядит практически одинаково для всех версий Windows. Я надеюсь, что никому из Вас не приходит в голову мысль серьезно рассматривать в качестве операционной системы для установки на сервер Windows 3.1, 3.11, 95, 98, ME. Поэтому дальше в этой статье о них не будет сказано ни слова, соответственно Вы можете с полным правом считать, что все методы, описанные ниже, работать с ними скорее всего не будут. Впрочем если есть желание можете проверить эти гипотезы лично. В дальнейшем, предполагается, что Вы прочитали первую статью, подробно описывающую основы установки и настройки Nagios, либо в февральском номере журнала "Системный админитсратор", либо на моем сайте. Покончив с формальностями, приступим к изучению конструкции и принципов работы подсистемы сбора данных о производительности. Такая система встроена в каждую 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\Процессор(_Total)\% загруженности процессора \\TIGROID\Процессор(0)\% загруженности процессора \\TIGROID\Процессор(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 24×7 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 24×7 host_notification_period 24×7 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 } Пожалуйста убедитесь что вы внесли группу контактов 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.htm берем последнюю версию программы 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 Files\NSClient. Затем, в зависимости от установленной у нас операционной системы, копируем в нее содержимое либо из директории Win_2k_XP_Bin, либо из Win_NT4_Bin. Пользуясь следующими меню Пуск ->Выполнить запускаем командный интерпретатор cmd.exe. В появившемся окне набираем: > C:\Program Files\NSClient\pNSClient /install По окончанию установки система должна продемонстрировать нам подобное окошко. Это значит, программе удалось прописать себя в реестре подобающим образом. С помощью программы regedit откроем реестр. Ищем ветку \HKEY_LOCAL_MACHINE\SOFTWARE\NSClient\Params. Внутри расположились параметры password и port. Я думаю, предназначение каждого из них очевидно. Интуиция подсказывает мне — Вы согласитесь с утверждением, что возможность просматривать статистику должна быть предоставлена только программам, запущенным на сервере мониторинга. Меняем содержимое параметра password на что-нибудь длинное и трудно- подбираемое, например, "PxRT890mY". Теперь любой, кто попытается подключиться для получения данных на порт 1248, должен будет предъявить пароль. Проверим, как себя чувствует наш новый сервис NetSaint NT agent. Выбираем следующие меню Пуск->Настройка->Панель управления. Затем дважды кликаем по пиктограмме "Администрирование", в открывшемся окне так же поступаем со значком "Службы". Должно получиться что-то подобное: Нам нужно было увидеть следующую строку "NSClient 1.0.7.0 has started. Language code : 0x0419", опираясь на ее содержимое, мы можем узнать цифровой код языка, используемого в системе. Для русского языка это 0x0419, а для английского, соответственно, 0x0409. В файле C:\Program Files\NSClient\counters.defs находится описание системных счетчиков для всех известных программе языков. Просмотрев его до конца, понимаем, что кодом 0x0419 тут явно не пахнет. Отсюда вывод — для русской версии Windows получим дырку от бублика вместо статистики. Осознав, что такое несправедливое положение вещей нас не устраивает, добавляем в counters.defs новую секцию с названиями счетчиков, соответствующими нашему языку: [0x0419] Description = "Russian" 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 Files\NSClient\counters.defs for counters definitions. Language code : 0x0419 NSClient has stopped Закончив возню с Windows, переходим к Unix. В дальнейшем я предполагаю, что Nagios установлен в директорию /usr/local/nagios/. Запускается он с правами пользователя nagios, принадлежащего к группе nagios. По крайней мере, именно так это происходит во FreeBSD. Если Вы используете другую операционную систему, то вполне возможно настройки будут слегка отличаться. Для начала берем на сайте проекта 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. # Описываем хост по имени win2000rus # Определяем команду 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 24×7 max_check_attempts 3 normal_check_interval 1 retry_check_interval 1 contact_groups win-admins notification_interval 120 notification_period 24×7 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 24×7 max_check_attempts 3 normal_check_interval 1 retry_check_interval 1 contact_groups win-admins notification_interval 120 notification_period 24×7 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 24×7 max_check_attempts 3 normal_check_interval 1 retry_check_interval 1 contact_groups win-admins notification_interval 120 notification_period 24×7 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 24×7 max_check_attempts 3 normal_check_interval 1 retry_check_interval 1 contact_groups win-admins notification_interval 120 notification_period 24×7 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 24×7 max_check_attempts 3 normal_check_interval 1 retry_check_interval 1 contact_groups win-admins notification_interval 120 notification_period 24×7 notification_options c,r # Переход в состояние предупреждения происходит, если занято 70% памяти. # Критический статус наступает, когда израсходовано 90% памяти check_command check_nt_memuse!70%!90%!PxRT890mY } # Время работы системы с момента последней перезагрузки. define service{ use generic-service host_name win2000rus service_description Up time is_volatile 0 check_period 24×7 max_check_attempts 3 normal_check_interval 1 retry_check_interval 1 contact_groups win-admins notification_interval 120 notification_period 24×7 notification_options c,r check_command check_nt_uptime!PxRT890mY } # Проверяем, функционирует ли сервис MS SQL SERVER и # самописный сервис vmxposman define service{ use generic-service host_name win2000rus service_description Runing Services is_volatile 0 check_period 24×7 max_check_attempts 3 normal_check_interval 1 retry_check_interval 1 contact_groups win-admins notification_interval 120 notification_period 24×7 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 24×7 max_check_attempts 3 normal_check_interval 1 retry_check_interval 1 contact_groups win-admins notification_interval 120 notification_period 24×7 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 24×7 max_check_attempts 3 normal_check_interval 1 retry_check_interval 1 contact_groups win-admins notification_interval 120 notification_period 24×7 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 машине. Например, для того чтобы посмотреть, как работает слежение за очередью принтера можно выключить питание принтера и отправить несколько заданий на печать. Впрочем, я думаю, вы и сами сможете придумать разные способы создать критические ситуации.

 Бешков Андрей
   tigrisha@sysadmins.ru
   http://onix.opennet.ru/monitoring/nagios.html

               С увеличением размера подконтрольных сетей перед каждым
   администратором встает вопрос о создании единой системы мониторинга
   серверов и сервисов. Внедрение такой системы позволит повысить
   производительность работы компании и уменьшить время простоя
   оборудования. Несмотря на свои неоспоримые достоинства, коммерческие
   системы вроде Solar Winds, 3COM Network Superviser и HP OpenView в
   данной статье рассматриватся не будут из-за своих довольно высоких
   цен. Для выполнения вышеописанной задачи мы будем использовать
   инструмент по имени Nagios. Кроме него в сети существует множество
   других бесплатных систем мониторинга. Наиболее известными являются Big
   Brother, Angel Network Monitor, HiWayS, MARS, Autostatus, NocMonitor,
   RITW.

   Давайте рассмотрим главные задачи системы мониторинга. Она должна
   оповещать администратора с помощью электронной почты, пейджера или sms
   сообщений, если с наблюдаемыми объектами случаются какие-либо
   неприятности. Также оповещения должны отсылаться, когда состояние
   объекта возвращается в норму. Вдобавок ко всем способам, перечисленным
   выше, Nagios позволяет использовать в качестве инструмента оповещения
   программы, разработанные пользователями.

   Перед тем, как мы станем более подробно обсуждать возможности Nagios,
   Вам стоит посмотреть на демонстрационную систему, которую Tom Welsh
   установил специально для этих нужд. Быстренько идем на сайт
   http://nagios.square-box.com/. Для авторизации используем имя
   пользователя guest и пароль guest.

   Набродившись по разным меню и полюбовавшись на все красоты
   web-интерфейса давайте поговорим о достоинствах Nagios. На основе
   увиденного мы можем сделать вывод: Nagios позволяет производить
   мониторинг таких сетевых сервисов как SMTP, TELNET, SSH, HTTP, DNS,
   POP3, IMAP, NNTP и многих других. Еще можно следить за использованием
   ресурсов серверов, таких как расход дискового пространства, свободная
   память и загруженность процессора. Существует возможность создавать
   свои собственные обработчики событий. Эти обработчики будут
   выполняться при возникновении тех или иных событий, инициированных
   проверками сервисов или серверов. Такой подход позволит активно
   реагировать на происходящие события и пытаться автоматически решать
   возникшие проблемы. К примеру, можно создать обработчик событий,
   который будет самостоятельно перезапускать повисший сервис. Еще одним
   достоинством системы мониторинга Nagios является возможность управлять
   ею удаленно с помощью wap интерфейса мобильного телефона. Используя
   концепцию "родительских" хостов, легко описать иерархию и зависимости
   между всеми хостами. Такой подход чрезвычайно полезен для больших
   сетей, потому что позволяет производить сложную диагностику. А это
   качество, в свою очередь, помогает отличить не работающие хосты, от
   тех, что недоступны в данный момент из-за неполадок в работе
   промежуточных звеньев. Nagios умеет строить графики работы наблюдаемых
   систем и карты контролируемой сетевой инфраструктуры.

   Из своей практики работы с Nagios приведу пример, показывающий,
   насколько полезен он оказался для меня. На внешнем сетевом интерфейсе
   нашего брандмауэра с периодичность в несколько часов начиналась потеря
   пакетов. Из-за неисправности терялось до 20 процентов проходящего
   трафика. По истечении минуты — другой интерфейс снова начинал работать
   как положено. По причине плавающего характера этой неполадки несколько
   недель я не мог понять, почему при работе с Интернет периодически
   происходят кратковременные сбои. Без Nagios поиск неисправности
   затянулся бы надолго.

   Многим из администраторов хорошо знаком предок Nagios по имени
   NetSaint. Несмотря на то, что сайт проекта  NetSaint все еще исправно
   функционирует, новые разработки базируются уже на исходном коде
   Nagios. Поэтому всем рекомендуется потихоньку перебираться на Nagios.
   Изначально проект разрабатывался для Linux, но наша система
   мониторинга будет работать на основе  FreeBSD 4.5. В документации,
   поставляемой с Nagios, говорится, что он будет стабильно работать и со
   многими другими Unix подобными системами. Для отображения
   web-интерфейса Nagios нам понадобится  сервер Apache. Вы вольны,
   использовать любой другой, но в данной статье будет рассматриваться
   именно Apache, как наиболее распространенный  на Unix платформах
   web-сервер. Можно установить систему мониторинга вообще без
   web-интерфейса, но мы так делать не станем, потому что это существенно
   уменьшает удобство пользования.

   Для создания графиков нам понадобится библиотека GD Graphics, которую
   написал Thomas Boutel. Она необходима для создания изображений в
   формате  PNG, JPEG и WBMP. Последний чаще всего используется клиентами
   беспроводных устройств. Подавляющее большинство браузеров пока не
   умеет работать с  WBMP, поэтому для нас он интереса не представляет.
   До перехода на версию 2.0.6 была возможность работать с форматом  GIF,
   но от нее пришлось отказаться из-за проблем с патентным
   законодательством. Для сжатия информации внутри изображений GIF
   используется  алгоритм LZW. Эксклюзивными правами на него обладает
   Unisys. В связи с вышеуказанными проблемами, сетевому сообществу
   рекомендуется использовать свободные от подобных неудобств форматы PNG
   и JPEG. В свою очередь, библиотека GD опирается на библиотеки  zlib,
   LibPng и jpeg. У нас есть три пути, следуя которыми мы можем
   установить все необходимые библиотеки. В статье они будут подробно
   описаны по очереди. Я люблю все собирать и устанавливать вручную,
   потому, как подобный подход   дает более полное понимание происходящих
   процессов и возможность использовать самое свежее программное
   обеспечение. Итак, начнем нашу эпопею со способа красноречиво
   называемого в народе "закат солнца вручную".

   Первый ингредиент — библиотека zlib, написанная двумя программистами-
   Jean-loup Gailly и Mark Adler. Она проектировалась как API общего
   назначения для сжатия данных без потерь. Как ни странно, но в нашем
   проекте она будет использоваться по своему прямому назначению, то есть
   для сжатия изображений. Берем новейшую версию
   http://www.gzip.org/zlib. На момент написания это была весрия
   1.1.4. Распаковываем и компилируем.
# tar zvxf zlib-1.1.4.tar.gz
# cd zlib-1.1.4
# ./configure
# make test
# make install

   Как Вы могли бы предположить, LibPng служит для создания изображений в
   формате PNG. Я использовал версию 1.2.5. Взять ее можно тут:

   http://www.graphicswiz.com/png/libpng.html

   Собирается LibPng  довольно-таки странным и нестандартным путем.
# tar zxvf libpng-1.2.5.tar.gz
# cd libpng-1.2.5

   Ориентируясь на тип операционной системы, из директории scripts
   выбираем нужный нам makefile и копируем его в директорию с исходными
   файлами. Для нашего случая исходный файл называется  makefile.freebsd.
# cp ./scripts/makefile.freebsd

   Затем создаем директорию zlib и кладем в нее из дистрибутива zlib все
   файлы с расширением *.h
# mkdir zlib

   Вот теперь можно проводить компилляцию. Что мы с радость выполняем.
# make all
# make test

   В результате на экране вы должны увидеть что-то  вроде этого:
Testing pngtest.png:
Pass 0: rwrwrwrwrwrwrwrwrw
Pass 1: rwrwrwrwrwrwrwrwrw
Pass 2: rwrwrwrwrwrwrwrw
Pass 3: rwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrw
Pass 4: rwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrw
Pass 5: rwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrw
Pass 6: rwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrw
PASS (9782 zero samples)
Filter 0 was used 21 times
Filter 1 was used 15 times
Filter 2 was used 52 times
Filter 3 was used 10 times
Filter 4 was used 33 times
tIME = 7 Jun 1996  17:58:08 +0000
Current memory allocation:          0 bytes
Maximum memory allocation:     337346 bytes
Total   memory allocation:    1023516 bytes
Number of allocations:        198
libpng passes test
mkdir /usr/local/include/libpng

   И наконец пришло время инсталляции. Тут уж все должно пройти легко и
   просто.
# make install

   Теперь берем  по адресу http://www.ijg.org/files/ библиотеку jpeg
   версии 6b. Я надеюсь, самые догадливые читатели уже поняли, что она
   понадобится нам для создания изображений в формате jpeg. Поверив моим
   заявлениям о том, что процедура установки довольно проста, начнем ее
   выполнение.
# tar zxvf jpegsrcv6b.tar.gz
# cd jpeg-6b
# ./configure
# make

   После тестовой сборки должны увидеть такую картину:
# make test
rm -f testout*
./djpeg -dct int -ppm -outfile testout.ppm  ./testorig.jpg
./djpeg -dct int -bmp -colors 256 -outfile testout.bmp  ./testorig.jpg
./cjpeg -dct int -outfile testout.jpg  ./testimg.ppm
./djpeg -dct int -ppm -outfile testoutp.ppm ./testprog.jpg
./cjpeg -dct int -progressive -opt -outfile testoutp.jpg ./testimg.ppm
./jpegtran -outfile testoutt.jpg ./testprog.jpg
cmp ./testimg.ppm testout.ppm
cmp ./testimg.bmp testout.bmp
cmp ./testimg.jpg testout.jpg
cmp ./testimg.ppm testoutp.ppm
cmp ./testimgp.jpg testoutp.jpg
cmp ./testorig.jpg testoutt.jpg

   Следующей командой устанавливаем библиотеку jpeg.
# make install

   Наконец, после всех этих мытарств можно заняться  инсталляцией
   библиотеки GD. Скачиваем исходные тексты с сайта проекта
   http://www.boutell.com/gd/. Как всегда, распаковываем и
   конфигурируем дистрибутив.
# tar zxvf gd-2.0.6.tar.gz
# cd gd-2.0.6
# ./configure —x-includes=/usr/local/include ┬x-libraries=/usr/local/lib

   Ключи -x-includes и -x-libraries указывают скрипту конфигурации, где у
   нас находятся заголовочные и библиотечные файлы всех установленных
   ранее библиотек.
# make all

   Если компиляция завершилась с ошибками, то нам необходимо удалить
   временные файлы, созданные в процессе работы команды make.
# make devclean

   После выполнения чистки нужно принять меры к устранению причин
   возникновения ошибок. При необходимости подправьте ключи команды
   configure, а затем проведите повторную компиляцию. И если предыдущие
   шаги завершились нормально, запускаем инсталляцию.
# make install

   Теперь давайте обсудим второй способ установки. При наличии
   устойчивого соединения с Интернетом можно попытаться установить
   библиотеки GD,  zlib, LibPng и  jpeg с помощью механизма портов. Мы
   запустим установку GD, а она, в свою очередь, автоматически выполнит
   скачивание, компиляцию и установку всех необходимых библиотек на
   основе  зависимостей между ними.
# cd /usr/ports/graphics/gd
# make install

   Третий способ установки не требует подключения к сети Интернет. Скорее
   всего, он является самым простым и, видимо, лучше всего подходит для
   начинающих администраторов. Как и во втором способе, все необходимое
   будет автоматически установлено из пакетов, поставлявшихся вместе с
   операционной системой FreeBSD. По аналогии со вторым способом за
   удобство придется заплатить свежестью  устанавливаемого программного
   обеспечения. В CD привод кладем компакт диск с пакетами и запускаем
   программу sysinstall.
# /stand/sysinstall

   А затем, последовательно пройдя через все перечисленные ниже меню,
   выполняем инсталляцию.

   Configure->Packages->CD/DVD->graphics->gd-1.8.4_3->ok->install->ok

   Аналогичного эффекта можно добиться, используя команду pkg_add.
   Посмотрим, куда у нас все это установилось. Файлы библиотек лежат в
   /usr/local/lib, а заголовочные файлы в /usr/local/include/gd. Не стоит
   огорчаться, если, несмотря на все попытки, библиотеку не удалось
   установить ни одним из трех способов. Хотя я с трудом представляю, как
   такое возможно. Отложите установку до лучших времен. Наличие
   вышеназванных библиотек необходимо только для правильной работы
   модулей построения графиков и генерирования сетевой карты. Nagios
   работает стабильно и остается очень полезным инструментом даже без
   этих модулей.

   Пришло время детально разобраться с архитектурой системы мониторинга.
   Обычно комплекс на основе Nagios состоит из двух частей — главной
   программы, в документации чаше всего называемой core program, и
   подключаемых модулей соответственно plugins. Модульный дизайн
   позволяет отделить логику основной программы от процесса выполнения
   проверок. Это в свою очередь дает возможность всем желающим без особых
   усилий расширять область применения Nagios через написание собственных
   подключаемых модулей.

   Скачиваем последнюю версию главной программы и подключаемых модулей с
   официального сайта проекта  http://www.nagios.org/download/. На
   момент написания статьи были доступны версии nagios-1.0b6 и
   nagiosplug-1.3-beta1. Засучив рукава, приступим к установке главной
   программы.
# tar zxvf nagios-1.0b6.tar.gz
# cd nagios-1.0b6

   Теперь нужно решить, в какой каталог мы хотим инсталлировать Nagios.
   По умолчанию предполагается каталог /usr/local/nagios/. Думаю, нам
   тоже стоит придерживаться его, потому что в прилагающейся к
   дистрибутиву документации указан именно этот каталог.  При последующем
   устранении ошибок или проблем с конфигурированием будет гораздо проще
   читать документацию. Создаем каталог, куда мы впоследствии будем
   проводить инсталляцию. Не совсем понятно, почему ее должен создавать
   администратор, а не программа инсталляции. Надеюсь,  в следующих
   версиях этот недочет будет исправлен.
# mkdir /usr/local/nagios

   С помощью скрипта adduser либо каким-нибудь другим способом создаем
   пользователя nagios, состоящего в группе nagios.
# adduser nagios
# ./configure —prefix=/usr/local/nagios —with-cgi-url=/nagios/cgi-bin —with-
html-url=/nagios/ \
—with-nagios-user=nagios —with-nagios-grp=nagios —with-gd-lib=/usr/local/lib
 \
—with-gd-inc=/usr/local/include/gd

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

   —prefix=/usr/local/nagios — Сюда мы будем  устанавливать файлы после
   компиляции. Вот и пригодилась созданная вручную директория
   /usr/local/nagios.

   —with-cgi-url=/nagios/cgi-bin — URL с помощью которого мы будем
   обращаться к CGI скриптам web-интерфейса nagios. В конце URL символ
   "/" добавлять не нужно. В качестве примера для вымышленного сайта
   somesite.ru можно привести абсолютный URL одного из CGI скриптов
   httt://somesite.ru/nagios/cgi-bin/statusmap.cgi.

   —with-html-url=/nagios/ — URL где будут находиться html файлы, в
   которых хранятся  главное меню web-интерфейса и документация.

   —with-nagios-user=nagios — пользователь, которому будут принадлежать
   файлы инсталляции.

   —with-nagios-grp=nagios — соответственно группа этого пользователя.

   —with-gd-lib=/usr/local/lib — тут у нас лежит библиотека GD

   —with-gd-inc=/usr/local/include/gd  — а здесь находятся  ее
   заголовочные файлы.

   Осмыслив все прочитанное и разобравшись с опциями команды configure,
   проводим сборку и инсталляцию.
# make all
# make install
Следующий шаг является необязательным, но желательно его все же выполнить.    С
 помощью команды make install-init можно создать скрипт, который будет выполнят
ь запуск Nagios  после перезагрузки системы. Вдобавок к этому у нас появится во
зможность управлять    работой процесса Nagios с помощью команд stop, reload, s
tart, restart, reload, force-reload.    Давайте подробнее рассмотрим каждую из
этих команд.

   start — запускает процесс Nagios.

   stop —  останавливает текущий процесс Nagios.

   restart — останавливает выполняющийся процесс Nagios и запускает новый

   reload — отправляет процессу Nagios сигнал SIGHUP, заставляя его
   перечитать конфигурационные файлы, а затем продолжить мониторинг

   force-reload — производит принудительную перезагрузку конфигурационных
   файлов

   status — показывает статус работающего процесса

   Для FreeBSD файл скрипта  должен располагаться в директории
   /usr/local/etc/rc.d и называться nagios.sh. В зависимости от типа
   операционной системы, инсталлятор должен сам выбрать подходящие права
   доступа, местоположение  и имя скрипта. Например, для систем на основе
   Slackware должны получить соответственно /etc/rc.d/init.d и rc.nagios.
   Ну что же давайте, попытаемся выполнить установку скрипта.
# make install-init

   Получаем следующие ошибки:
/usr/bin/install -c -m 755 -d -o root -g root /usr/local/etc/rc.d
install: unknown group root
*** Error code 67
Stop in /tmp/nagios-1.0b6.

   Жаль, но установка с наскоку не удалась. Ну и ладно, вот исправим
   ошибки программистов, писавших скрипт, и все заработает как надо.  С
   помощью любимого текстового редактора начинаем редактировать файл
   Makefile.

   Идем на строку 32 и ищем символы

   INIT_OPTS=-o root -g root

   Обдумав увиденную строку, понимаем, что под FreeBSD пользователь root
   входит в группу wheel. Вносим изменения.

   INIT_OPTS=-o root -g wheel

   Переходим на строку 154

   $(INSTALL) -m 774 $(INIT_OPTS) daemon-init
   $(DESTDIR)$(INIT_DIR)/nagios

   Правильно задаем имя файла nagios.sh вместо nagios. Не стоит давать
   общий доступ на чтение для файла скрипта. Вполне хватит режима доступа
   100. Измененная строка будет выглядеть так:

   $(INSTALL) -m 100 $(INIT_OPTS) daemon-init
   $(DESTDIR)$(INIT_DIR)/nagios.sh

   Сохраняем файл и снова выполняем команду инсталляции.
# make install-init

   Итак, скрипт автозапуска создан, но он все еще не готов к работе. Все
   дело в том, что при перезагрузке файл nagios.sh будет выполнен без
   единого параметра командной строки, а для безукоризненной работы нужно
   запускать его с параметром start. Сейчас мы это исправим. Открываем
   файл для редактирования и выполняем поиск строки:

   echo "Usage: nagios {start|stop|restart|reload|force-reload|status}"

   Затем сразу после нее вставляем вот это:

   /usr/local/etc/rc.d/nagios.sh start

   Внесенными изменениями мы заставляем nagios.sh, запущенный без
   обязательных параметров, рекурсивно выполнить самого себя с параметром
   start.

   Еще одна ошибка — это путь к файлу, в котором будут храниться внешние
   команды, переданные на выполнение процессу Nagios. После инсталляции
   подразумевается, что файл должен располагаться в
   /usr/local/nagios/var/rw/nagios.cmd. Но, к сожалению, директория
   /usr/local/nagios/var/rw/ автоматически не создается. К тому же, не
   совсем понятен смысл создания отдельной директории для единственного
   файла  nagios.cmd. Чтобы исправить вышеуказанную ошибку, ищем строку

   NagiosCmd=${prefix}/var/rw/nagios.cmd

   и заменяем ее на такую:

   NagiosCmd=${prefix}/var/nagios.cmd

   Теперь файл nagios.cmd будет создаваться в директории
   /usr/local/nagios/var/.

   К сожалению, это не последняя проблема, связанная с файлом nagios.cmd.
   При каждом перезапуске процесса Nagios файл внешних команд сначала
   удаляется, а затем создается вновь. Беда в том, что создается
   nagios.cmd с правами процесса. Соответственно, он принадлежит
   пользователю nagios и группе nagios. На первый взгляд, здесь нет
   никакой проблемы. Поразмышляв некоторое время, мы понимаем, что
   главным поставщиком внешних команд для процесса Nagios будет
   web-интерфейс. Сервер Apache обычно запускается с правами пользователя
   nobody группы nogroup. А это значит, что процесс web-сервера не сможет
   вносить новые данные в файл nagios.cmd. Самым простым решением было бы
   дать доступ на запись всем, но с точки зрения безопасности такое
   решение выглядит довольно неприглядно. Вторым способом разрешения
   конфликта могло бы стать введение пользователя nobody в группу nagios.
   Но с безопасностью опять возникают неувязки. Самым лучшим выходом из
   этой ситуации является частичная передача прав на файл пользователю
   nobody. В результате такой операции файлом должен владеть пользователь
   nobody и группа nagios. Таким образом, доступ к файлу получат и
   процесс nagios, и web-сервер. Ищем в файле nagios.sh вот такие строки

   sleep 1

   status_nagios nagios

   и добавляем сразу за ними команду

   chown nobody $NagiosCmd

   Покончив с файлом nagios.sh, можно быть уверенным, что уж теперь — то
   он будет работать, как положено.

   С помощью команды make install-config создаем файлы конфигурации,
   заполняем их значениями по умолчанию и помещаем в директорию
   /usr/local/nagios/etc/.
# make install-config

   Заглянув в директорию /usr/local/nagios/, мы видим, что после
   инсталляции внутри нее образовалось еще 5 директорий.
# ls  /usr/local/nagios
bin     etc     sbin    share   var

   Опишем, для чего нужна каждая из этих директорий.

   bin — здесь находится выполняемый файл основной программы. Он же демон
   Nagios.

   etc — конфигурационные файлы

   sbin — тут лежат файлы CGI для web-интерфейса

   share — здесь находятся html файлы web-интерфейса и документация

   var — файлы протоколов и данные о состоянии проверяемых объектов

   Можете себя поздравить с окончанием установки главной программы
   Nagios. Можно было сделать все то же самое с помощью портов или
   пакетов. К сожалению, на такой способ установки времени у меня не
   хватило. Поэтому  сказать об  удобстве или подводных камнях такого
   пути ничего не могу. Есть подозрение, что возможно возникновение
   проблем с конфигурированием, да и свежесть установленного программного
   обеспечения будет весьма сомнительна. Еще одной причиной не
   использовать порты стало желание заняться русификацией системы.
   Подробнее о результатах этого эксперимента будет рассказано в
   следующей статье. Несмотря на то, что инсталляция главной программы
   закончена, толку нам от этого пока никакого. Без установленных модулей
   Nagios совершенно бесполезен, так как не имеет возможности
   взаимодействовать с объектами, за которыми нужно наблюдать. Настало
   время приняться за инсталляцию этих самых модулей.  С помощью make,
   поставляющегося вместе с операционной системой, собрать их не удалось.
   Посему для компиляции будем пользоваться gmake.
# tar zxvf nagiosplug-1.3-beta1.tar.gz
# cd nagiosplug-1.3-beta1
# ./configure —prefix=/usr/local/nagios —with-nagios-user=nagios    —with-na
gios-grp=nagios

   Значение ключей конфигурации аналогично тем, что мы использовали при
   компиляции главной программы. Почитать детальные объяснения о
   назначении каждого ключа можно с помощью команды ./configure ┬help.
# gmake all
# gmake install

   После компиляции подключаемые модули устанавливаются в директорию
   /usr/local/nagios/libexec. Некоторые из них написаны на С, другие на
   perl. В принципе, модуль может быть написан на любом языке. Каждый
   модуль является выполняемым файлом. Это дает возможность использовать
   модули не только в комплексе с Nagios, но и с другими программами.
   Можно выполнять проверки даже из командной строки. Каждый модуль
   должен поддерживать опцию ┬help или -h, иначе он не может считаться
   совместимым с Nagios. Такие жесткие требования позволяют легко
   разобраться с любым модулем. Давайте посмотрим, какие параметры
   командной строки должен получать модуль check_dns.
# check_dns -h
check_dns (nagios-plugins 1.3.0-alpha1) 1.1.1.1
The nagios plugins come with ABSOLUTELY NO WARRANTY. You may    redistribute
copies of the plugins under the terms of the GNU General Public    License.
For more information about these matters, see the file named    COPYING.
Copyright (c) 1999 Ethan Galstad (nagios@nagios.org)
Usage: check_dns -H host [-s server] [-t timeout]
       check_dns —help
       check_dns —version
-H, —hostname=HOST   The name or address you want to query
-s, —server=HOST
   Optional DNS server you want to use for the lookup
-t, —timeout=INTEGER
   Seconds before connection times out (default: 10)
-h, —help
   Print detailed help
-V, —version
   Print version numbers and license information
This plugin uses the nslookup program to obtain the IP address
for the given host/domain query.  A optional DNS server to use may
be specified.  If no DNS server is specified, the default server(s)
specified in /etc/resolv.conf will be used.

   Прочитав и обдумав вывод предыдущей команды, можно понять, что модуль
   check_dns  принимает один обязательный параметр ┬H и два
   необязательных параметра -s, -t. Итак, по порядку ┬H имя или адрес
   проверяемого хоста. В параметре -s определяется адрес сервера DNS,
   используемого для перевода имени в адрес, если в первом параметре
   вместо адреса передано имя хоста. Затем -t устанавливает таймаут, по
   истечении которого служба считается нефункционирующей. Для проверки
   сервиса DNS машины с адресом 192.168.10.254 нужно выполнить следующую
   команду.
# check_dns -H 192.168.10.254
DNS ok — 0 seconds response time, Address(es) is/are  192.168.10.254

   Интуиция странным образом подсказывает мне, что DNS работает
   нормально.

   Закончив установку и разобравшись с механизмом работы подключаемых
   модулей, прейдем к настройке Nagios. Давайте осмотрим содержимое
   директории конфигурационных файлов.
# cd /usr/local/nagios/etc
# ll
total 92
-rw-rw-r—  1 nagios  nagios  17028 Nov 11 15:41 cgi.cfg-sample
-rw-rw-r—  1 nagios  nagios   4480 Nov 11 15:41 checkcommands.cfg-sample
-rw-rw-r—  1 nagios  nagios   1577 Nov 11 15:41 contactgroups.cfg-sample
-rw-rw-r—  1 nagios  nagios   1485 Nov 11 15:41 contacts.cfg-sample
-rw-rw-r—  1 nagios  nagios   1651 Nov 11 15:41    dependencies.cfg-sample
-rw-rw-r—  1 nagios  nagios   2022 Nov 11 15:41 escalations.cfg-sample
-rw-rw-r—  1 nagios  nagios   1658 Nov 11 15:41 hostgroups.cfg-sample
-rw-rw-r—  1 nagios  nagios   5774 Nov 11 15:41 hosts.cfg-sample
-rw-rw-r—  1 nagios  nagios   4277 Nov 11 15:41 misccommands.cfg-sample
-rw-rw-r—  1 nagios  nagios  21332 Nov 11 15:41 nagios.cfg-sample
-rw-rw—-  1 nagios  nagios   3074 Nov 11 15:41 resource.cfg-sample
-rw-rw-r—  1 nagios  nagios  17668 Nov 11 15:41 services.cfg-sample
-rw-rw-r—  1 nagios  nagios   1594 Nov 11 15:41 timeperiods.cfg-sample

   В названии каждого файла есть фрагмент -sample, значит,  все
   вышеперечисленные файлы являются не полноценными конфигурациями, а
   всего лишь примерами. На случай, если нам вдруг захочется посмотреть,
   что там у них внутри, скопируем их  в директорию sample. Может быть,
   когда-то они нам еще пригодятся.
# mkdir sample
# cp * ./sample

   Переименовываем все файлы, отсекая цепочку символов -sample. Таким
   образом, мы готовим файлы к тому, чтобы Nagios смог их заметить и
   правильно воспринять. В результате должно получиться что-то вроде:
# ll
total 94
-rw-rw-r—  1 nagios     nagios  17028 Nov 11 16:13 cgi.cfg
-rw-rw-r—  1 nagios  nagios   4480 Nov 11 16:13 checkcommands.cfg
-rw-rw-r—  1 nagios  nagios   1577 Nov 11 16:13 contactgroups.cfg
-rw-rw-r—  1 nagios  nagios   1485 Nov 11 16:13 contacts.cfg
-rw-rw-r—  1 nagios  nagios   1651 Nov 11 16:13 dependencies.cfg
-rw-rw-r—  1 nagios  nagios   2022 Nov 11 16:13 escalations.cfg
-rw-rw-r—  1 nagios  nagios   1658 Nov 11 16:13 hostgroups.cfg
-rw-rw-r—  1 nagios  nagios   5774 Nov 11 16:13 hosts.cfg
-rw-rw-r—  1 nagios  nagios   4277 Nov 11 16:13 misccommands.cfg
-rw-rw-r—  1 nagios  nagios  21332 Nov 11 16:13 nagios.cfg
-rw-rw—-  1 nagios  nagios   3074 Nov 11 16:13 resource.cfg
drwxr-xr-x  2 root    nagios    512 Nov 11 16:07 sample
-rw-rw-r—  1 nagios  nagios  17668 Nov 11 16:13 services.cfg
-rw-rw-r—  1 nagios  nagios   1594 Nov 11 16:13 timeperiods.cfg

   К сожалению, файлы все еще не готовы к употреблению. Nagios даже не
   сможет стартовать, если мы попытаемся его запустить. Разобраться в
   содержимом файлов примеров, созданных во время инсталляции, довольно
   сложно. Самым лучшим выходом из подобной ситуации будет уничтожение
   всех конфигурационных данных и создание их вручную под моим чутким
   руководством. Такой подход принесет более глубокое понимание
   используемой методики настройки. Обнуляем  все необходимые файлы.
# cp /dev/null hosts.cfg services.cfg contacts.cfg contactgroups.cfg    hostgro
ups.cfg
# cp /dev/null dependencies.cfg escalations.cfg

   Начиная с версии 1.0b2, в Nagios появилась возможность использовать
   шаблоны внутри конфигурационных файлов. Такая методика настройки
   позволяет многократно снизить время создания рабочей конфигурации.

   Перед нами стоит задача описать два хоста mail.regata.ru и
   proxy.regata.ru.

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

   Содержимое файла hosts.cfg

   # Описываем шаблон хоста
   define host{
   name                            generic-host
   # Имя шаблона —  будем ссылаться на него позже при описании каждого
   хоста

   notifications_enabled           1
   # Включаем уведомления

   event_handler_enabled           1
   # Включаем обработчик событий

   flap_detection_enabled          1
   # Включаем обнаружение мерцания

   process_perf_data               1
   # Собирать статистику об эффективности  работы процесса

   retain_status_information       1
   # Сохранять статусную информацию между перезагрузками программы

   retain_nonstatus_information    1
   # Сохранять нестатусную информацию между перезагрузками программы

   register                        0
   # Указываем, что все вышеописанное — это шаблон. Запрещаем
   регистрировать
   #  это описание как хост
   }

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

   define host{
   use                     generic-host
   # Ссылка на используемый шаблон

   host_name         mail
   # Имя хоста

   alias                   Mail Server
   # Псевдоним хоста

   address                 mail.regata.ru
   # Имя хоста в формате fqdn или его адрес

   check_command           check-host-alive
   # Команда проверки хоста выполняется обычно с помощью ping. Подробнее
   можно
   # почитать в файле checkcommands.cfg

   max_check_attempts      10
   # Количество попыток повторного тестирования после того, как одна из
   попыток
   # возвратила ошибочный статус.

   notification_interval   120
   # Интервал в минутах, по прошествию которого нужно повторно отсылать
   # уведомление, если сервер все еще не работает.

   notification_period     24×7
   # Период времени, в течение которого серверу разрешено беспокоить
   администратора
   # своими уведомлениями. В данном случае это круглые сутки. Подробнее о
   периодах
   # можно почитать в файле timeperiods.cfg.

   notification_options    d,u,r
   # Список событий, при наступлении которых необходимо отсылать
   # уведомления. Соответственно d,u,r (DOWN, UNREACHABLE, RECOVERY)
   # означает события "работает", "недоступен", "восстановлен".
   }

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

   define host{
   use                     generic-host
   host_name         proxy
   # Имя хоста. Также стоит обратить внимание на изменившиеся записи
   alias и address.
   alias                   Proxy Server
   address                 proxy.regata.ru
   check_command           check-host-alive
   max_check_attempts      10
   notification_interval   120
   notification_period     24×7
   notification_options    d,u,r
   }

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

   Содержимое файла hostgroups.cfg

   define hostgroup{
   hostgroup_name  regata-servers
   # Имя группы

   alias           Regata Servers
   # Псевдоним группы

   contact_groups  regata-admins
   # Список групп контактов, которые нужно уведомлять

    members         mail proxy
   # Список серверов, принадлежащих к группе
   }

   Пришло время  вплотную заняться описанием сервисов, за которыми нужно
   наблюдать. Как и во всех остальных конфигурационных файлах, первым
   делом необходимо создать шаблон сервиса. Мы разберем его подробно.
   Затем, второй и третьей записью, будут описаны сервисы HTTP и PING,
   базирующиеся на хосте proxy.regata.ru. Соответственно, далее мы
   работаем с mail.regata.ru, на котором  у нас базируются  SMTP и IMAP.

   Содержимое файла services.cfg

   # Описываем шаблон сервиса

   define service{
   name    generic-service
   # Имя шаблона

   active_checks_enabled  1
   # Включить активные проверки

   passive_checks_enabled  1
   # Принимать результаты пассивных проверок

   parallelize_check  1
   # Активные проверки лучше выполнять паралельно,
   # такой подход повышает скорость работы

   obsess_over_service  0
   # Эту опцию стоит включать только при создании распределенной
   # системы мониторинга.

   check_freshness   0
   # Следить за свежестью результатов проверок. По умолчанию отключено

   notifications_enabled  1
   # Уведомления включены

   event_handler_enabled  1
   # Включить обработчики событий

   flap_detection_enabled  1
   # Использовать обнаружение мерцания

   process_perf_data  1
   # Собирать данне об эффективности выполнения проверок

   retain_status_information 1
   # Сохранять информацию о статусе между перезапусками Nagios

   retain_nonstatus_information 1
   # Сохранять нестатусную информацию между перезапусками Nagios

   register   0
   #  Запрещаем регистрировать это описание как сервис
   }

   # Описываем сервис HTTP для хоста proxy.regata.ru

   define service{
   use    generic-service
   # Имя используемого шаблона

   hostname proxy.regata.ru
   # Имя хоста

   service_description HTTP
   # Описание сервиса

   is_volatile 0
   # Для стандартных сервисов лучше оставить значение 0
   # К нестандартным сервисам стоит относить те сервисы, которые
   # после каждой проверки автоматически возвращаются в состояние "ОК"
   # вне зависимости от режима, в котором они находились до проверки.

   check_period     24×7
   # Период, в течение которого можно выполнять проверки

   max_check_attemps    3
   # Максимальное количество повторных проверок

   normal_check_interval   5
   # Интервал между нормальными проверками

   retry_check_interval   1
   # Интервал между повторными проверками. Применяется, если
   # нормальная проверка завершилась неудачно

   contact_groups  regata-admins
   # Группа контактов, используемая для оповещения

   notification_interval    120
   # Интервал (в минутах), после которого нужно послать повторное
   уведомление,
   # если сервис так и не восстановился

   notification_period     24×7
   # Период, в течение которого можно производить отправку уведомлений

   notification_options     w,u,c,r
   # Список событий, при наступлении которых необходимо
   # отсылать уведомления.

   check_command check_http
   #  Имя команды, выполняемой для проверки сервиса
   }

   # Описываем сервис PING для хоста proxy.regata.ru

   define service{
   use    generic-service
   # Имя используемого шаблона

   hostname proxy.regata.ru
   # Имя хоста

   service_description PING
   # Описание сервиса

   is_volatile 0

   check_period     24×7
   # Период, в течение которого можно выполнять проверки

   max_check_attemps    3
   # Максимальное количество повторных проверок

   normal_check_interval   5
   # Интервал между нормальными проверками

   retry_check_interval   1
   # Интервал между повторными проверками. Применяется, если
   # нормальная проверка завершилась неудачно

   contact_groups  regata-admins
   # Группа контактов, используемая для оповещения

   notification_interval    120
   # Интервал (в минутах), после которого нужно послать повторное
   уведомление,
   # если сервис так и не восстановился

   notification_period     24×7
   # Период, в течение которого можно производить отправку уведомлений

   notification_options     w,u,c,r
   # Список событий, при наступлении которых необходимо
   # отсылать уведомления.

   check_command check_ping
   #  Имя команды, выполняемой для проверки сервиса
   }

   # Описываем сервис SMTP для хоста mail.regata.ru

   define service{
   use    generic-service
   hostname mail.regata.ru
   service_description  SMTP
   # Описание сервиса

   is_volatile 0
   check_period     24×7
   max_check_attemps    3
   normal_check_interval   5
   retry_check_interval   1
   contact_groups  regata-admins
   notification_interval    120
   notification_period     24×7
   notification_options     w,u,c,r
   check_command check_smtp
   #  Имя команды, выполняемой для проверки сервиса
   }

   # Описываем сервис IMAP для хоста mail.regata.ru

   define service{
   use    generic-service
   hostname mail.regata.ru
   service_description  IMAP
   # Описание сервиса

   is_volatile 0
   check_period     24×7
   max_check_attemps    3
   normal_check_interval   5
   retry_check_interval   1
   contact_groups  regata-admins
   notification_interval    120
   notification_period     24×7
   notification_options     w,u,c,r
   check_command check_imap
   #  Имя команды, выполняемой для проверки сервиса
   }

   Как Вы, возможно, сумели догадаться, имена команд, вызываемых для
   выполнения проверки того или иного сервиса, определяются параметром
   check_command. Сами же команды описываются в файле checkcommands.cfg.
   По странному стечению обстоятельств команда check_imap в этом файле не
   описана, несмотря на то, что среди модулей, установленных в директорию
   /usr/local/nagios/libexec/, файл check_imap присутствует. Видимо, это
   еще одна ошибка программистов Nagios. Ну и ладно, нам не привыкать
   делать все собственными руками. Разместим в любом месте файла
   checkcommands.cfg следующие строки:

   # 'check_imap' command definition
   define command{
           command_name    check_imap
           command_line    $USER1$/check_imap -H $HOSTADDRESS$
           }

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

   Содержимое файла contacts.cfg

   define contact{
   contact_name                    tigrisha
   # Имя контакта

   alias                           Andrei Beshkov
   # Имя человека

   service_notification_period     24×7
   # Период времени, в течение которого разрешено посылать уведомления
   # о состоянии сервисов

   host_notification_period        24×7
   # Период времени, в течение которого разрешено посылать уведомления
   # о состоянии хостов

   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                          admin@regata.ru
   # Почтовый адрес

   pager                           154363565@pager.icq.com
   # Адрес системы пейджинга
   }

   define contact{
   contact_name                    amon
   # Имя контакта

   alias                           Dmitry Larin
   # Имя человека

   service_notification_period     24×7
   # Период времени, в течение которого разрешено посылать уведомления о
   состоянии сервисов

   host_notification_period        24×7
   # Период времени, в течение которого разрешено посылать уведомления о
   состоянии хостов

   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                           amon@regata.ru
   # Почтовый адрес

   pager                           123345865@pager.icq.com
   # Адрес системы пейджинга
   }

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

   Содержимое файла contactgroups.cfg

   define contactgroup{
   contactgroup_name       regata-admins
   # Имя контактной группы

   alias                   regata.ru Admins
   # Псевдоним группы

   members                 tigrisha amon
   # Список контактов состоящих в группе
   }

   Файл dependencies.cfg отвечает за зависимости между хостами. Ну а файл
   escalations.cfg, в свою очередь, описывает эскалацию оповещений. В
   связи с тем, что рассматриваемый нами пример состоит всего из двух
   хостов, файлы зависимостей и эскалации нам не пригодятся. Отсюда
   вытекает приятный факт, говорящий, что необходимости заполнять их у
   нас нет. Возможно, в следующей статье я подробно опишу работу с
   файлами зависимостей и эскалации.

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

   1)Вручную как процесс переднего плана.

   2)Вручную как фоновый процесс.

   3)Вручную как демон.

   4)Автоматически как демон, при старте системы.

   Для проверки конфигурации воспользуемся третьим способом. Собравшись с
   духом, можно попытаться запустить систему и начать мониторинг.
   Воспользуемся для этих целей скриптом nagios.sh.
# /usr/local/etc/rc.d/nagios.sh

   После этого должно произойти одно из двух: либо Nagios начнет
   работать, либо на экране появится следующая ошибка.
Starting network monitor: nagios
/bin/sh:  -l: unrecognized option

   Не пугайтесь, если Вам довелось наступить на эти грабли. Приведенное
   выше сообщение об ошибке значит, что операционная система, на которой
   Вы работаете, не поддерживает опцию -l команды su. В случае с FreeBSD
   дело обстоит именно таким образом. Поэтому команда должна выглядеть
   так su -. В файле /usr/local/etc/rc.d/ nagios.sh ищем строку,
   содержащую символы su -l и удаляем из нее букву l. Вот теперь-то все
   должно работать, как положено. Снова запускаем Nagios. Проверяем, как
   он себя чувствует, с помощью ключа командной строки status.
# /usr/local/etc/rc.d/nagios.sh  status
  PID  TT  STAT      TIME COMMAND
  101  ??  Ss     0:20.81 /usr/local/nagios/bin/nagios -d /usr/local/nagios/etc

   Если, несмотря на все принятые предосторожности, Nagios продолжает
   кричать об ошибках, то стоит убедиться, что директория
   /usr/local/nagios/ вместе со всем свои содержимым принадлежит
   пользователю nagios и группе nagios. В случае ежели подобные  ожидания
   не оправдываются, выполняем смену владельца.
# chown -R nagios:nagios /usr/local/nagios/

   Ну, если и это не помогло, то Вам стоит запустить Nagios в режиме
   отладки.
#  /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg

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

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

   Nagios уже выполняет мониторинг сервисов и при наступлении критических
   событий отправляет оповещения всем, кому положено. Но по одним
   оповещениям понять, что происходит, не так уж и легко. Согласитесь,
   что в интерактивном режиме смотреть статистику работы и разбираться с
   проблемами гораздо легче. Исходя из этого, давайте, обратим наши взоры
   к процедуре настройки web-интерфейса. В данной статье предполагается,
   что на машине, занимающейся системой мониторинга, работает web-сервер
   Apache. Он обязан быть хотя бы минимально настроен и должен
   функционировать достаточно стабильно.

   В файле настроек Apache httpd.conf  ищем такой фрагмент текста:
    <Directory "/usr/local/apache/cgi-bin">
        AllowOverride None
        Options None
        Order allow,deny
        Allow from all
    </Directory>

   Сразу же после них добавляем такие строки:
ScriptAlias /nagios/cgi-bin/ "/usr/local/nagios/sbin/"
    <Directory "/usr/local/nagios/sbin/">
        AllowOverride AuthConfig
        Options ExecCGI
        Order allow,deny
        Allow from all
    </Directory>
Alias /nagios/ /usr/local/nagios/share/
   <Directory "/usr/local/nagios/share/">
       AllowOverride AuthConfig
       Options None
       Order allow,deny
       Allow from all
   </Directory>

   Выполнив эту, процедуру мы создали два псевдонима. Первый — для cgi
   директории nagios, находящейся в "/usr/local/nagios/sbin/". Доступ к
   ней можно получить, выполнив подобный http запрос http://ваш
   сайт/nagios/cgi-bin/. Второй псевдоним указывает, что в директории
   /usr/local/nagios/share/ находятся html файлы web-интерфейса и
   справочной документации. Просмотреть эти страницы можно, посетив
   адрес  http://ваш сайт /nagios/. При попытке посетить эти страницы,
   получаем ошибку. Для того чтобы псевдонимы и авторизация заработали,
   нужно создать файл .htaccess в директории /usr/local/nagios/sbin/ и
   внести в него следующие строки:
AuthName "Nagios Access"
AuthType Basic
AuthUserFile /usr/local/nagios/etc/htpasswd.users
require valid-user

   Для вступления в силу выполненных изменений осталось лишь
   перезапустить Apache.
# /usr/local/apache/bin/apachectl restart

   Таким образом, мы объясняем web-серверу, что доступ к файлам
   директории /usr/local/nagios/sbin/ может получить только
   авторизованный пользователь. Если есть желание, чтобы пользователи не
   смогли войти даже на главную страницу Nagios без ввода пароля, то
   нужно скопировать файл .htaccess из директории /usr/local/nagios/sbin/
   в /usr/local/nagios/share/.

   Список паролей и имен пользователей должен находится в файле
   /usr/local/nagios/etc/htpasswd.users, который  на данный момент еще не
   существует. Заводим нового пользователя и заодно с помощью ключа ┬c
   создаем файл.
# /usr/local/apache/bin/tpasswd -c /usr/local/nagios/etc/htpasswd.users    tigr
isha
New password: ******
Re-type new password: ******

Adding password for user tigrisha

   С помощью той же команды, но без ключа ┬с, создаем еще одного
   пользователя.
# /usr/local/apache/bin/htpasswd  /usr/local/nagios/etc/htpasswd.users amon
New password: ******
Re-type new password: ******
Adding password for user amon

   Теперь давайте займемся конфигурационным файлом
   /usr/local/nagios/etc/cgi.cfg. Нам нужно изменить некоторые параметры:

   authorized_for_system_information=tigrisha, amon
   # Список пользователей, которым разрешен просмотр
   # информации о работе процесса Nagios

   authorized_for_configuration_information= tigrisha, amon
   # Список пользователей, которым разрешен просмотр
   # информации о конфигурации всех хостов и сервисов.
   # По умолчанию пользователь может смотреть
   # конфигурацию только хостов и сервисов,
   # принадлежащих к его контактной группе.

   authorized_for_system_commands=tigrisha, amon
   # Список пользователей, авторизованных для выполнения
   # через cmd.cgi команд управления процессом Nagios.

   authorized_for_all_services=tigrisha, amon
   authorized_for_all_hosts=tigrisha, amon
   # Эти два параметра определяют список пользователей, которым разрешен
   просмотр
   # информации обо всех наблюдаемых хоста и сервисах.
   # По умолчанию пользователь может видеть
   # только те хосты и сервисы,  которые принадлежат к его контактной
   группе.

   refresh_rate=10
   # Частота обновления (в секундах) информации, просматриваемой через
   web-интерфейс.
   # По умолчанию установлено 90 секунд, но нам такой большой интервал не
   подходит.
   # Поэтому поставим 10 секунд.

   Теперь в файл nagios.cfg вносим следующие изменения

   date_format=euro
   # Устанавливаем формат даты более привычный для России

   use_authentication=1
   # Включаем аутентификацию пользователей

   check_external_commands=1
   # Разрешаем обрабатывать команды, передаваемые процессу Nagios через
   web-интерфейс.

   command_file=/usr/local/nagios/var/nagios.cmd
   # Местоположение файла внешних команд.

   Для того чтобы внесенные изменения вступили в силу, перезапускаем
   процесс Nagios:
# /usr/local/etc/rc.d/nagios.sh restart

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