LinuxShare

Содержание статьи
Вступление
Принципы работы SNMP
Настройка SNMP на платформе Windows 2000
Вспомогательные инструменты для работы с SNMP
Установка дополнительно пакета ПО для SNMP
Выбор параметров мониторинга Windows системы
Настройка NetSNMP под FreeBSD
Тестирование SNMP функционала
Тестирование модулей Nagios
Настройка Nagios для сервисов SNMP

Вступление

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

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

Сегодня мы изучим второй способ мониторинга. Для получения необходимых данных мы будем использовать SNMP (Simple Network Management Protocol). Большинство знаний, приобретенных после прочтения этой статьи, можно будет применить для настройки не только систем мониторинга на основе Nagios. Понимание принципов работы SNMP и практические навыки обращения с Windows в этом аспекте позволят передать нужные нам данные другим системам мониторинга, работающим с SNMP. Например, это могут быть mrtg, OpenNMS, Dec PolyCenter Network Manager, HP Open View, IBM AIX NetView/600, IBM Tivoli, Micromuse Netcool и любые другие программы обладающие подобной функциональностью.

Принципы работы SNMP

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

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

• время работы с момента последней перезагрузки
• загрузка процессора
• количество портов принтера
• статус каждого порта
• количество подключенных принтеров
• статус каждого принтера
• общее количество заданий в очереди
• количество заданий в очереди каждого принтера
• общее количество выполненных заданий
• количество заданий, выполненных каждым принтером
• список IP- адресов или пользователей, создававших задания
• количество и размер заданий, отправленных каждым пользователем
• таблица интерфейсов подключения к локальной сети
• статус каждого из этих интерфейсов
• количество, размер, вид пакетов, прошедших через каждый интерфейс
• общий размер оперативной памяти
• размер свободной оперативной памяти

Количество доступной информации впечатляет. Самой приятной изюминкой в реализации SNMP является тот факт, что все сложности по взаимодействию с реальным оборудованием ложатся на плечи агента, который, в свою очередь, предоставляет стандартный интерфейс доступа к данным оборудования. Таким образом, менеджер может легко общаться с агентами, созданными разными производителями оборудования. Для того, чтобы агент мог правильно описать оборудование, в которое он встроен, а менеджер - понять, о чем идет речь, они должны оба опираться на одну и ту же модель подконтрольного ресурса. Данные модели хранятся в базе данных управляющей информации - MIB (Management Information Base) - которая полностью описывает список доступных характеристик ресурса. Пользуясь ею, менеджер может узнать, какие сведения агент способен предоставить, что они означают и какими свойствами аппаратуры можно управлять. Повсеместно MIB принято представлять в виде древовидной структуры. Определенные части этого дерева являются обязательными для всех реализаций SNMP.

• System - обобщенные данные о системе (имя, время работы с момента последней перезагрузки)
• Interfaces - данные о сетевых интерфейса (статус, количество, типы, размер пакетов,)
• At (Address translation table) - таблица трансляции адресов. Уже не используется. Поддерживается только ради совместимости со старыми версиями.
• TCP - данные протокола TCP (количество соединений, получено и отправлено пакетов, количество ошибок )
• ICMP - данные протокола обмена управляющими сообщениями ICMP (количество сообщений получено и отправлено, количество ошибок и их виды )
• EGP - протокол обмена информацией о состоянии маршрутизации (получено и отправлено пакетов, количество ошибок)
• UDP - данные протокола UDP (получено и отправлено датаграмм, количество ошибок)
• SNMP - статистика работы одноименного протокола (количество входящих и исходящих пакетов, обработано запросов, ошибки)
• IP - данные о функционировании этого протокола (количество пакетов получено и отправлено, количество ошибок и их разновидности )

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

Например, для того чтобы узнать время работы системы с момента последней перезагрузки нужно пройти через ветку. iso.org.dod.internet.mgmt.mib2.system.sysUpTime. Буквенная запись используется для удобства человека, менеджеры и агенты оперируют числами. Соответственно, каждая часть пути имеет свой числовой идентификатор.

Это значит, что тот же самый путь выражается как .1.3.6.1.2.1.1.3. Если у Вас сегодня плохое настроение, то можно использовать подобное смешанное написание .iso.3.dod.1.mgmt.1.1.sysUpTime.

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

В связи с тем, что префикс iso.org.dod.internet.mgmt.mib2 встречается почти в каждом OID, большинство людей вообще перестало его писать. Подразумевается наличие этого префикса, поэтому очень часто можно встретить такой вид записи system.sysUpTime.

Несмотря на то, что в каждой ветви дерева может находиться несколько экземпляров объектов, в некоторых находится только один. В этом случае все зависит о целесообразности. Например, нет смысла держать внутри ветви system.sysUpTime два экземпляра объекта, потому что время работы системы может быть только одно. В случае, если экземпляр объекта один, ему присваивается номер "0". Доступ к его данным можно получить, обратившись к нему либо как system.sysUpTime, либо system.sysUpTime.0.

Примером хранения нескольких экземпляров объекта являются ветви:

• interfaces.ifTable.ifEntry.ifType - тип сетевой карты
• interfaces.ifTable.ifEntry.ifIndex - уникальный ключ
• interfaces.ifTable.ifEntry.ifMtu - максимальный размер пакета данных

Внутри этих ветвей хранятся данные о сетевых картах, установленных на нашей машине. Подветвь interfaces обладает очень интересной конструкцией. Объект .interfaces.ifNumber содержит в себе цифру "2", это говорит нам, что в системе установлено две сетевые карты. Внутри ветви interfaces.ifTable.ifEntry находится массив данных сетевых интерфейсов. По сути дела это хэш массив. В некоторых книгах он еще называется ассоциативным массивом. Ветвь interfaces.ifTable.ifEntry.ifIndex объявляет два ключа с уникальными цифровыми идентификаторами. В дальнейшем эти ключи используются для того, чтобы не путать между собой экземпляры объектов внутри каждой нижележащей ветви. Таким образом, получается, что ко второй сетевой карте относятся следующие экземпляры объектов:

• interfaces.ifTable.ifEntry.ifType.16777219
• interfaces.ifTable.ifEntry.ifIndex.16777219
• interfaces.ifTable.ifEntry.ifMtu.16777219

Ну а к первой сетевой карте относятся соответственно:

• interfaces.ifTable.ifEntry.ifType.1
• interfaces.ifTable.ifEntry.ifIndex.1
• interfaces.ifTable.ifEntry.ifMtu.1

Разобравшись с форматом дерева, перейдем к операциям, которые можно выполнять с помощью SNMP.

• GetRequest - самая распространенная операция. Позволяет получить содержимое объекта из MIB. Обычно в разных статьях сокращается до Get.
• GetNextRequest - операция получения следующего экземпляра из таблицы. Представим себе такую ситуацию. В нашем маршрутизаторе есть некоторое количество портов. Мы хотим узнать, какие из них активны в данный момент. С помощью GetRequest читаем данные первого экземпляра внутри ветви. Но вся проблема в том, что мы не знаем, сколько еще экземпляров осталось внутри. Вот тут-то нам пригодится GetNextRequest. С помощью этой операции мы проходим по всему списку объектов. Как только нам встречается первый объект из другой ветки, операция прекращается. Сокращенное название звучит как GetNext.
• SetRequest - судя по названию, каждый может догадаться что эта команда служит для внесения данных в MIB. Часто о ней говорят просто как о команде Set.
• GetResponse - выполняется агентом в ответ на команды GetRequest, GetNextRequest, SetRequest. Если это ответ на первые две, то внутрь будут вложены запрошенные данные, ну а если на третью, то внутри будет подтверждение об успешном выполнении. Самые распространенные устные названия для этой команды Reply или Response.
• Trap - содержит внутри себя специальный OID, показывающий что это ловушка, а также информацию о том какой, MIB объект установил ловушку и данные этого объекта. Тут и сокращать-то нечего, поэтому название никогда не искажается.

Следующее интересное для нас понятие - "Имена Сообществ" (Community Names). Они являются своеобразным эквивалентом паролей и используются для того, чтобы разграничить, какие приказы агенту может отдавать тот или иной менеджер. Каждая из пяти перечисленных ранее операций должна содержать в себе правильное имя сообщества, иначе она не будет выполнена. Если агент настроен соответствующим образом, то в результате запроса с ошибочным именем сообщества менеджеру будет отправлена ловушка с жалобой на попытку ошибочной аутентификации. Имена сообществ бывают четырех видов Read-Only, Read-Write, Read-Create и Trap. Если менеджер передает агенту команды GetRequest, GetNextRequest, то внутри должна быть та строка сообщества Read-Only которая запрограммирована в агенте.

Если же происходит попытка передать агенту на выполнение команду SetRequest, то для начала проверяется тип изменяемого объекта MIB. Тип должен быть read-write. И только затем происходит проверка переданного менеджером имени сообщества на совпадение со строкой Read-Write. Внесение изменений происходит, только если обе проверки завершились с положительным результатом.

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

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

Одной из основных проблем с безопасностью протокола SNMP являются имена сообществ, установленные изготовителем оборудования по умолчанию. Многие производители используют в качестве имен всех перечисленных сообществ слово "public". Многие администраторы после установки оборудования напрочь забывают о необходимости сменить имена сообществ. В таком случае любой более или менее осведомленный о протоколе SNMP злоумышленник может получить доступ к важным функциям оборудования. Вторая большая проблема состоит в том, что пакеты протокола SNMP передаются через сеть открытым текстом. Получается, что узнать нужные строки сообществ не так уж и сложно. Подобное плачевное состояние с безопасностью протокола породило довольно забавную шутку. По мнению сетевых острословов, SNMP расшифровывается как "Security Not My Problem". Положение существенно улучшилось с введением второй версии протокола SNMP. Для противодействия злоумышленникам используются Symmetric Privacy Protocol (SPP), призванный защитить от прослушивания, и авторизация на основе Digest Authentication Protocol (DAP). Ну а до тех пор, пока SNMP v.2 не стал повсеместным стандартом, мы будем защищаться тем, что постараемся везде, где только возможно, перестать использовать команду SetRequest. Нам для проведения мониторинга совершенно нет необходимости ее применять. Таким образом, никто не сможет внести изменения в данные, находящиеся внутри оборудования. Еще одним способом борьбы со злоумышленниками должно стать запрещение пропускать пакеты протокола SNMP из Интернет во внутреннюю сеть. Так же необходимо жестко ограничить круг IP адресов менеджеров, которым позволено обращаться к агентам, находящимся внутри нашего оборудования. Если после прочтения этого краткого курса вам все еще непонятны какие-либо моменты теории работы SNMP, значит стоит почитать список часто задаваемых вопросов. Сделать это можно, передав любой поисковой машине запрос snmp faq. В случае, если такой помощи окажется недостаточно, стоит обратиться к документации, описывающей протокол. Лучшим источником таких сведений являются RFC 1156, 1213, 1157, 1146, 2571, 2574. Покончив с кратким обзором основ SNMP, перейдем к практическому применению полученных знаний.

Настройка SNMP на платформе Windows 2000

Для того, чтобы на машине win2000rus заработала служба SNMP, нужно установить добавочные системные компоненты. Давайте пройдемся по цепочке меню Пуск->Настройка->Панель управления. Дважды кликнем пиктограмму "Установка и удаление программ". В открывшемся окне жмем кнопку "Добавление и удаление компонентов Windows".

Ставим галочку напротив "Средства управления и наблюдения".

Нажимаем кнопку "Состав" и обязательно убеждаемся что "Протокол SNMP" тоже помечен галочкой.

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

Затем начинаем редактировать свойства службы SNMP. Сообщество Read-Only из public переименовываем в "QWEmn90" а сообщество Read-Wrie, скажем, в "Zxasd098".

Заменив значения по умолчанию таким сложными для запоминания и случайного угадывания именами, мы повышаем безопасность использования SNMP. Честно говоря, сообщество Read-Write надежнее всего вообще отключить удалением соответствующего имени из списка. В список узлов, от которых можно принимать пакеты SNMP, добавляем адрес нашего сервера Nagios и самой Windows машины, тем самым выполняя еще один реверанс в сторону безопасности. Помня, что жизнь под Windows - это цепь постоянных перезагрузок, перезапускаем службу SNMP, для того чтобы изменения в настройках вступили в силу. Конечно можно было бы обойтись просто перезагрузкой службы SNMP, но полная перезагрузка машины все же будет надежнее.

Вспомогательные инструменты для работы с SNMP

Закончив с предварительным конфигурированием, побеспокоимся о своем удобстве. Установим на Windows машину браузер SNMP. Интерфейс командной строки - это хорошо, но все же графическими средствами бродить по веткам SNMP гораздо приятнее.

Для использования под Windows можно взять стандартный агент MS SMS Netmon на сайте производителя http://www.microsoft.com/smsmgmt/. Я буду использовать утилиту по имени GetIf версии 2.2, полученную тут http://www.wtcs.org/snmp4tpc/FILES/Tools/SNMP/getif/getif-2.2.zip. Она умеет делать много полезных вещей, но, самое главное, отлично работает с SNMP. У всех желающих есть возможность там же взять более современную версию 2.3. Хотя лично мне она не очень нравится из-за изменений в интерфейсе. В процессе инсталляции жмем несколько раз кнопку "Next". Не прошло и минуты, как мы стали счастливыми обладателями SNMP браузера. Для Unix - систем взять браузер можно здесь http://snmpbrowser.sourceforge.net/.

В дальнейшем все инструкции приводятся для работы с GetIf. Впрочем, остальные версии браузеров SNMP должны быть очень похожи в обращении. Запустим браузер первый раз и начнем заполнение полей необходимых для выполнения SNMP команд. В поле "Host Name" пишем адрес либо имя нашей Windows машины. Затем в поля "Read commuinty" и "Write community" вносим "QWEmn90" и "Zxasd098". Нажимаем кнопку "Start". Если все пустые строки заполнились данными, а не надписями "error" или "none" и получилось что-то подобное рисунку, значит SNMP работает исправно.

Теперь обратимся к вкладке MBrowser, ради возможностей которой все это собственно и затевалось. Для того, что бы получить данные, хранящиеся в какой-либо подветви, нужно дважды кликнуть на корневом элементе "iso". Возьмем, к примеру, OID iso.org.dod.internet.mgmt.mib-2.system.sysDescr, содержащий описание системы. Пройдя через всю иерархию к нужной точке внутри дерева, нажимаем кнопку "Walk".

На экране должно отобразиться что-то подобное снимку приведенному выше. Давайте разберемся, что мы видим. Самое верхнее поле содержит символьную нотацию OID чуть ниже располагается цифровая форма записи того же самого. Еще ниже находится дерево MIB. Справа от дерева 4 информационных поля, описывающих выбранный объект. Среди них тип объекта (Type), доступ разрешаемый к объекту (Access), список значений, которые может принимать объект (Enums). Например, для OID, описывающего состояние сетевых интерфейсов .iso.org.dod.internet.mgmt.mib-2.IfTable.IfTable.IfEntry.IfOperStatus, доступны значения "up", "down", "testing". Затем идет статус объекта (Status) - является ли объект обязательным или нет. Еще ниже находится область, в которой выводится подробное разъяснение значения данных выбранного объекта. Хочу заметить, что, по моему мнению, это одна из самых полезных возможностей, предоставляемых браузером. Даже в символьной записи не всегда понятно, данные о какой функциональности устройства предоставляет та или иная ветвь дерева. Опускаясь еще немного вниз, видим окно, в котором отображаются результаты запросов, выполненных по нажатию клавиши "Walk". Это и есть содержимое объектов, находящихся в выбранной подветви. Ниже всех находится группа полей ввода, обеспечивающая возможность изменения данных, находящихся внутри выбранного объекта. Впрочем, есть возможность редактировать и любой другой объект, к которому есть доступ Read-Write. Для это нужно изменить OID, установленный по умолчанию в строке редактирования. После того, как все необходимые данные введены в поля редактирования, жмем кнопку "Set" и смотрим на результат. Отсюда следует вывод, что мы можем не только просматривать данные, но и довольно легко редактировать их. Спору нет, все возможности, предоставленные нам программой GetIf, очень даже полезны, но кое-что все же нужно улучшить. Например, расширить базу MIB, которую она использует, потому что в комплекте MIB поставляемом по умолчанию не хватает многих жизненно важных OID. Берем архив необходимых нам MIB здесь http://www.wtcs.org/snmp4tpc/FILES/Tools/SNMP/getif/GETIF-MIBS.ZIP. Распаковываем его во временную директорию, затем все файлы с расширением .mib копируем в папку, где у нас установлена программа GetIf. Обычно это C:/Program Files/GetIf 2.2/Mibs/. После копирования удаляем файл .index, содержащий внутри себя список файлов, в которых находятся MIB. Запускаем Getif, файл .index будет создан заново и заполнен новым списком MIB файлов автоматически. Посмотрев на вкладку MBrowser, осознаем сколько полезного добавилось в нашу базу. Если же такое обилие Вас пугает, то можно ограничиться копированием только следующих:

• Mib_ii
• MIB_II_TRANSMISSION
• RFC_BASE_MINIMUM
• PRIVATE_ENTERPRISES/Microsoft_win2k
• PRIVATE_ENTERPRISES/Microsoft_Apps

Порыскав несколько минут по дереву, находим OID, содержащий данные о загрузке процессора.

.iso.org.dod.internet.mgmt.mib-2.host.hrDevice.hrProcessorTable.hrProcessorEntry.hrProcessorLoad

Установка дополнительно пакета ПО для SNMP

К сожалению, данные, предоставляемые Windows для доступа через SNMP, все еще слишком скудны. Хотелось бы иметь более информативную картину процессов, происходящих внутри подопытной машины. Очень хочется, чтобы данные счетчиков производительности (performance counters), о которых шла речь в первой части этой статьи, были доступны нам через SNMP. Добиться подобного приятного эффекта можно с помощью программы, называемой SNMP4W2K. Для Windows NT, соответственно, она будет называться SNMP4NT. Все семейство вышеописанных программ распространяется в двух вариантах. Бесплатная стандартная версия называется SNMP4W2K-STD и SNMP4NT-STD. Соответственно, платная версия зовется SNMP4W2K-PLUS и SNMP4NT-PLUS. В связи с падением спроса на саму Windows NT ,а затем и на платную версию SNMP4NT-PLUS, автор недавно выложил ее в свободный доступ. Нынче вне зависимости от толщины кошелька ее могут скачать все желающие. Разница между версиями состоит в размерах базы MIB и стоимости 50$ за одну лицензию. Бесплатная версия, кроме большого количества стандартных счетчиков, содержит еще и счетчики следующих сервисов Windows:

• Print Services
• SMTP Services
• NNTP Services

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

• SQL Server 2000
• Exchange Server 2000
• ISA Server
• Media Services
• Active Directory
• IIS Global Services

Лично мне хватает данных, предоставляемых стандартной версией, поэтому я буду использовать именно ее. Скачиваем отсюда http://www.wtcs.org/snmp4tpc/FILES/SNMP4W2K/STD/SNMP4W2K-STD.zip дистрибутив SNMP4W2K. Подробнее ознакомиться с теорией функционирования пакета, почитать список часто задаваемых вопросов и взять версию для Window NT можно на сайте автора http://www.wtcs.org/snmp4tpc/. Ну а сейчас давайте кратко разберемся с вопросами "почему" и "как это работает".

Используя интерфейс расширения агентов SNMP, мы внедряем в Windows свой нестандартный обработчик SNMP perfmib.dll, который, опираясь на базу mib.bin и конфигурацию, сохраненную в файле perfmib.ini, позволяет нам получить доступ к объектам производительности. Соответствие между объектами производительности и OID хранится в базе mib.bin. Распаковав дистрибутив, приступим с нетерпением к инсталляции программы SNMP4W2K-STD. Запускаем файл SNMP4W2K-STD.exe. Согласившись с условиями лицензии, выбираем директорию для инсталляции C:\Program Files\SNMP4W2K-STD\. Как только полоса копирования файлов перестанет мелькать, нам будет предложено две опции "View Readme File" и "Run Installed Application". Недрогнувшей рукой отключаем первую опцию и нажимаем "ОК". После этого появится окно командного интерпретатора с несколькими вопросами, которые нужно уточнить. Соглашаясь с выбором, предлагаемым по умолчанию, нужно будет нажать несколько раз клавишу "Y". Программа инсталляции самостоятельно внесет изменения в реестр и перезапустит службу SNMP. Если браузер SNMP работает, закрываем его. Для того, чтобы новые ветви, добавленные SNMP4W2K, появились в GetIf, нужно скопировать MIB файлы программы SNMP4W2K, находящиеся в директории C:\Program Files\SNMP4W2K-STD\Mibs\ в директорию, где лежат базы MIB нашего браузера C:\Program Files\Getif 2.2\Mibs\. Снова удаляем файл .index и, запустив GetIf, идем любоваться веткой .iso.org.dod.internet.private.enterprises. Все подветви, находящиеся внутри нее, появились благодаря SNMP4W2K. Стоит обратить внимание на один побочный эффект SNMP4W2K. Например, если вы хотите работать с данными сервиса или программы, доступными только через SNMP4W2K, то вам нужно сначала установить саму программу и только затем ставить SNMP4W2K. Яркий пример такого подхода - служба IIS. Если она установлена после SNMP4W2K, то совокупность OID, дающих доступ к ее внутренним данным, работать не будет, потому что SNMP4W2K в момент инсталляции не нашел на машине службу IIS, а значит решил, что захламлять машину лишними MIB не стоит. Если же поступить наоборот - сначала установить IIS, а затем SNMP4W2K, то все будет работать как положено. За решением этой проблемы можно увлекательно потерять не один час рабочего времени. Вот такой вот образец чрезмерной самостоятельности программы SNMP4W2K.

Так как на моей машине нет сервисов вроде WINS, SMTP, DNS то большинство полезной для наблюдения информации находится в объектах ветви .iso.org.dod.internet.private.enterprises.microsoft.software.systems.os.windowsNT.performance.

Выбор параметров мониторинга Windows системы

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

.iso.org.dod.internet.private.enterprises.microsoft.software.systems.os.windowsNT.performance.
cpuprocessorTable.cpuprocessorEntry.cpuPercentProcessorTime.

Внимание! Вышеуказанный OID состоит из одной строки. Пришлось разрубить его на две части что бы не нарушал форматирование страницы.

К сожалению, процесс использования SNMP не так уж и прост. Для того, чтобы увидеть количество занятой виртуальной памяти, нам придется провести некоторые расчеты. Берем содержимое OID .iso.org.dod.internet.private.enterprises.microsoft.software.systems.os.windowsNT.performance.memmory.memmoryCommitLimit, соответствующее системному счетчику "\Память\Предел выделенной виртуальной памяти", делим его на 100 и получаем величину, показывающую, сколько байт принимается за один процент памяти. В моем случае получилась величина 3.184.967 байт. Отсюда следует вывод, что на моей машине один процент это почти три мегабайта памяти. Получаем данные о количестве израсходованной памяти

 .iso.org.dod.internet.private.enterprises.microsoft.software.systems.os.windowsNT.performance.memmory.memmoryCommittedBytes, соответствующие счетчику "\Память\Байт выделенной виртуальной памяти". В моей системе это 53776337 байт. Делим полученную величину на размер одного процента, равного 3184967 байт, и получаем 16.88%. Значит, свободной памяти еще достаточно. Именно такую методику расчетов мы будем использовать при настройке порогов критического состояния 90% - 286647030 байт и уровня предупреждения 80% - 254797360 байт для сервиса, с помощью которого Nagios будет следить за потреблением памяти.

Следующий ресурс, за которым нужно следить - свободное место на жестких дисках Windows машины. К сожалению, мне так и не удалось заставить работать ветки .iso.org.dod.internet.private.enterprises.microsoft.software.systems.os.windowsNT.performance.pdiskphysicalDiskTable и .iso.org.dod.internet.private.enterprises.microsoft.software.systems.os.windowsNT.performance.ldisklogicalDiskTable, отвечающие за физические устройства жестких дисков и логические тома файловых систем. Но огорчаться по этому поводу не стоит. Вместо OID, созданных SNMP4W2K, мы будем использовать стандартную ветвь .iso.org.dod.internet.mgmt.mib-2.host.hrStorage.hrStorageTable. Первым делом обращаемся к ветке .iso.org.dod.internet.mgmt.mib-2.host.hrStorage.hrStorageTable.hrStorageEntry.hrStorageDescr чтобы узнать, какое из устройств нас интересует. Используя OID hrStorageDescr, читаем текстовое описание объектов, содержащихся внутри массива, прикрепленного к этой ветке.

.iso.org.dod.internet.private.enterprises.microsoft.software.systems.os.windowsNT.performance.pagefilepaging-FileTable.pagefilepaging-FileEntry.pagefilePercentUsage

# tar zxvf net-snmp-5.0.8.tar.gz

# ./configure

Defaul version  of SNMP to use (3): 3

System contact infomation  root@somedomain.com

System Location (Unknown): home

Location to write log file /var/log/snmpd.log:  /var/log/snmpd.log

Location to write persistent information  /var/net/snmp:  /var/net/snmp

# make

# umask 022
# make install

snmpbulkget
snmpbulkwalk
snmpcheck
snmpconf
snmpdelta
snmpdf
snmpget
snmpget.old
snmpgetnext
snmpinform
snmpnetstat
snmpset
snmpstatus
snmptable
snmptest
snmptranslate
snmptrap
snmpusm
snmpvacm
snmpwalk

# /usr/local/etc/rc.d/snmpd.sh stop
# chmod  ugo-x /usr/local/etc/rc.d/snmpd.sh

# ./configure --prefix=/usr/local/nagios --with-nagios-user=nagios --with-nagios-grp=nagios
# gmake all
# gmake install

#/usr/local/nagios/libexec/check_snmp -H win2000rus -C QWEmn90 -o system.sysUpTime.0
SNMP problem - No data recieved from host
CMD: /usr/local/bin/snmpget -m ALL -v 1 -c  QWEmn90  win2000rus system.sysUpTime.0

# /usr/local/bin/snmpget -v2c -m ALL -c QWEmn90 win2000rus system.sysUpTime.0

# /usr/local/bin/snmpget -m ALL -c QWEmn90 -v2c win2000rus system.sysUpTime.0

# /usr/local/bin/snmpget -v2c -m ALL -c QWEmn90 win2000rus .1.3.6.1.4.1.311.1.1.3.1.1.2.1.3.1

# /usr/local/bin/snmpget -m ALL -c QWEmn90 -v2c win2000rus .1.3.6.1.4.1.311.1.1.3.1.1.2.1.3.1

# /usr/local/bin/snmpwalk -v2c -m ALL -c QWEmn90 win2000rus .1.3.6.1.4.1.311.1.1.3.1.1.2.1.3.1

# /usr/local/bin/snmpwalk -m ALL -c QWEmn90 -v2c win2000rus .1.3.6.1.4.1.311.1.1.3.1.1.2.1.3.1

	/* create the command line to execute */
	command_line = ssprintf
		(command_line,
		 "%s -m ALL -v 1 %s %s %s",
		 PATH_TO_SNMPGET, server_address, community, oid);

        /* create the command line to execute */
	command_line = ssprintf
		(command_line,
		 "%s -v2c -m ALL -c %s %s %s",
		 "/usr/local/bin/snmpwalk",community ,server_address , oid);

        /* create the command line to execute */
	command_line = ssprintf
		(command_line,
		 "%s -m ALL -c %s -v2c %s  %s",
		 "/usr/local/bin/snmpwalk", community, server_address, oid);

# gmake all
# gmake install

#/usr/local/nagios/libexec/check_snmp -H win2000rus -C QWEmn90 -o .1.3.6.1.4.1.311.1.1.3.1.1.2.1.3.1
SNMP OK - INTEGER: 12

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 ""
}

# Сервис, показывающий данные о проценте использования файла подкачки
define service {
  use generic-service
  host_name win2000rus
  service_description SNMP Page File Usage
  is_volatile 0
  check_period 24x7
  max_check_attempts 3
  normal_check_interval 1
  retry_check_interval 1
  contact_groups win-admins
  notification_interval 120
  notification_period 24x7
  notification_options c,r
  # Порог предупреждения устанавливаем на 80%, а критическое состояние на 90%
  # Обратите внимание на знак "%", передаваемый в последнем аргументе.
  # Мы присоединяем этот знак к результатам, возвращаемым после
  # выполнения запроса.
  check_command check_snmp_oid!.1.3.6.1.4.1.311.1.1.3.1.1.6.1.3!QWEmn90!80!90!%
}

# Данные о загрузке процессора, собираемые через SNMP4W2K
define service {
  use generic-service
  host_name win2000rus
  service_description SNMP CPU Load
  is_volatile 0
  check_period 24x7
  max_check_attempts 3
  normal_check_interval 1
  retry_check_interval 1
  contact_groups win-admins
  notification_interval 120
  notification_period 24x7
  notification_options c,r
  check_command check_snmp_oid!.1.3.6.1.4.1.311.1.1.3.1.1.2.1.3.1!QWEmn90!80!90!%
} 

# Данные о загрузке процессора, собираемые через стандартную ветку
# .iso.org.dod.internet.mgmt.mib-2.host.hrDevice.hrProcessorTable.hrProcessorEntry.hrProcessorLoad
define service {
  use generic-service
  host_name win2000rus
  service_description SNMP hrProcessorLoad
  is_volatile 0
  check_period 24x7
  max_check_attempts 3
  normal_check_interval 1
  retry_check_interval 1
  contact_groups win-admins
  notification_interval 120
  notification_period 24x7
  notification_options c,r
  check_command check_snmp_oid!.1.3.6.1.2.1.25.3.3.1.2.2!QWEmn90!80!90!%
}

# Время работы системы с момента последней перезагрузки
define service {
  use generic-service
  host_name win2000rus
  service_description SNMP Up Time
  is_volatile 0
  check_period 24x7
  max_check_attempts 3
  normal_check_interval 1
  retry_check_interval 1
  contact_groups win-admins
  notification_interval 120
  notification_period 24x7
  notification_options c,r
  # Обратите внимание на то, что пороги предупреждения и 
  # критического состояния для данного сервиса смысла не 
  # имеют, поэтому отключены с помошью пустых кавычек "".
  # Дописывать в результат тоже ничего не будем, а значит
  # снова нужно использовать ""
  check_command check_snmp_oid!.1.3.6.1.2.1.1.3!QWEmn90!""!""!""
}

# Процент использования виртуальной памяти
define service {
  use generic-service
  host_name win2000rus
  service_description SNMP Virtual Memory usage
  is_volatile 0
  check_period 24x7
  max_check_attempts 3
  normal_check_interval 1
  retry_check_interval 1
  contact_groups win-admins
  notification_interval 120
  notification_period 24x7
  notification_options c,r
  check_command
  # Порог предупреждения устанавливаем на достижении 80% заполнения,
  # соответствующих 254797360 байтам, и критическое состояние,
  # наступающее при заполнении 90% памяти, устанавливаем на отметку в
  # 286647030 байт.
  # В результат, возвращаемый модулем, добавляем строку "bytes"
  check_snmp_oid!.1.3.6.1.4.1.311.1.1.3.1.1.1.3.0!QWEmn90!254797360!286647030!bytes
}

# Сколько места израсходовано на диске C:\
define service {
  use generic-service
  host_name win2000rus
  service_description SNMP Space used on disk C:\
  is_volatile 0
  check_period 24x7
  max_check_attempts 3
  normal_check_interval 1
  retry_check_interval 1
  contact_groups win-admins
  notification_interval 120
  notification_period 24x7
  notification_options c,r
  # Порог предупреждения наступает при расходе 80% пространства диска -
  # соответственно, 835367 блока.
  # Критическое состояние наступает при заполнении 90% пространства.
  # Для моей машины это 938788 блоков.
  # В отчет, возвращаемый модулем, добавляем строку "blocks"
  check_command check_snmp_oid!.1.3.6.1.2.1.25.2.3.1.6.2!QWEmn90!835367!938788!blocks
}

# /usr/local/etc/rc.d/nagios