Мониторинг Windows-серверов с помощью Nagios. Часть 2::Журнал СА 8.2003
www.samag.ru
Журнал «БИТ. Бизнес&Информационные технологии»      
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
Журнал "Системный администратор"
Журнал «БИТ»
Наука и технологии
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Контакты
   

Jobsora


  Опросы
1001 и 1 книга  
12.02.2021г.
Просмотров: 2475
Комментарии: 0
Коротко о корпусе. Как выбрать системный блок под конкретные задачи

 Читать далее...

11.02.2021г.
Просмотров: 2350
Комментарии: 0
Василий Севостьянов: «Как безболезненно перейти с одного продукта на другой»

 Читать далее...

20.12.2019г.
Просмотров: 9239
Комментарии: 0
Dr.Web: всё под контролем

 Читать далее...

04.12.2019г.
Просмотров: 10002
Комментарии: 2
Особенности сертификаций по этичному хакингу

 Читать далее...

28.05.2019г.
Просмотров: 11183
Комментарии: 2
Анализ вредоносных программ

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

 Мониторинг Windows-серверов с помощью Nagios. Часть 2

Архив номеров / 2003 / Выпуск №8 (9) / Мониторинг Windows-серверов с помощью Nagios. Часть 2

Рубрика: Администрирование /  Продукты и решения

АНДРЕЙ БЕШКОВ

Мониторинг Windows серверов с помощью Nagios

Часть 2

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

На данный момент 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.

Рисунок 1

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

.iso.org.dod.internet.mgmt.mib2.system.sysUpTime

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

  • iso – 1
  • org – 3
  • dod – 6
  • internet – 1

Это значит, что тот же самый путь выражается как .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.

Рисунок 2

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

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

Внутри этих ветвей хранятся данные о сетевых картах, установленных на нашей машине. Подветвь interfaces обладает очень интересной конструкцией. Объект .inter-faces.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 и Trap. Если менеджер передает агенту команды GetRequest, GetNextRequest, то внутри должна быть та строка сообщества Read-Only, которая запрограммирована в агенте.

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

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

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

Одной из основных проблем с безопасностью протокола SNMP являются имена сообществ, установленные изготовителем оборудования по умолчанию. Многие производители используют в качестве имен всех перечисленных сообществ слово «public». Многие администраторы после установки оборудования напрочь забывают о необходимости сменить имена сообществ. В таком случае любой более или менее осведомленный о протоколе SNMP злоумышленник может получить доступ к важным функциям оборудования. Вторая большая проблема состоит в том, что пакеты протокола SNMP передаются через сеть открытым текстом. Получается, что узнать нужные строки сообществ не так уж и сложно. Подобное плачевное состояние с безопасностью протокола породило довольно забавную шутку. По мнению сетевых острословов, SNMP расшифровывается как «Se-curity 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, перейдем к практическому применению полученных знаний.

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

Рисунок 3

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

Рисунок 4

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

Рисунок 5

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

Рисунок 6

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

Рисунок 7

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

Рисунок 8

Теперь обратимся к вкладке MBrowser, ради возможностей которой все это, собственно, и затевалось. Для того чтобы получить данные, хранящиеся в какой-либо подветви, нужно дважды кликнуть на корневом элементе «iso». Возьмем, к примеру, OID:

.iso.org.dod.internet.mgmt.mib-2.system.sysContact

содержащий описание системы. Пройдя через всю иерархию к нужной точке внутри дерева, нажимаем кнопку «Walk».

Рисунок 9

На экране должно отобразиться что-то подобное снимку, приведенному на следующей странице. Давайте разберемся, что мы видим. Самое верхнее поле содержит символьную нотацию 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

К сожалению, данные, предоставляемые 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. Ну а сейчас давайте кратко разберемся с вопросами «почему» и «как это работает».

Рисунок 10

Используя интерфейс расширения агентов SNMP, мы внедряем в Windows свой нестандартный обработчик SNMP perfmib.dll, который, опираясь на базу mib.bin и конфигурацию, сохраненную в файле perfmib.ini, позволяет нам получить доступ к объектам производительности. Соответствие между объектами производительности и OID хранится в базе mib.bin. Распаковав дистрибутив, приступим с нетерпением к инсталляции программы SNMP4W2K-STD. Запускаем файл SNMP4W2K-STD.exe. Согласившись с условиями лицензии, выбираем директорию для инсталляции C:Program FilesSNMP4W2K-STD. Как только полоса копирования файлов перестанет мелькать, нам будет предложено две опции «View Readme File» и «Run Installed Application». Недрогнувшей рукой отключаем первую опцию и нажимаем «ОК». После этого появится окно командного интерпретатора с несколькими вопросами, которые нужно уточнить. Соглашаясь с выбором, предлагаемым по умолчанию, нужно будет нажать несколько раз клавишу «Y». Программа инсталляции самостоятельно внесет изменения в реестр и перезапустит службу SNMP. Если браузер SNMP работает, закрываем его. Для того чтобы новые ветви, добавленные SNMP4W2K, появились в GetIf, нужно скопировать MIB-файлы программы SNMP4W2K, находящиеся в директории C:Program FilesSNMP4W2K-STDMibs в директорию, где лежат базы MIB нашего браузера C:Program FilesGetif 2.2Mibs. Снова удаляем файл .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

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

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

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

.iso.org.dod.internet.private.enterprises.microsoft.software.systems.os.windowsNT.performance.memmory.memmoryCommitLimit

соответствующее системному счетчику «ПамятьПредел выделенной виртуальной памяти», делим его на 100 и получаем величину, показывающую, сколько байт принимается за 1% памяти. В моем случае получилась величина 3 184 967 байт. Отсюда следует вывод, что на моей машине 1% – это почти 3 мегабайта памяти. Получаем данные о количестве израсходованной памяти:

.iso.org.dod.internet.private.enterprises.microsoft.software.systems.os.windowsNT.performance.memmory.memmoryCommittedBytes

соответствующие счетчику «ПамятьБайт выделенной виртуальной памяти». В моей системе это 53 776 337 байт. Делим полученную величину на размер одного процента, равного 3 184 967 байт, и получаем 16.88%. Значит, свободной памяти еще достаточно. Именно такую методику расчетов мы будем использовать при настройке порогов критического состояния 90% – 286 647 030 байт и уровня предупреждения 80% – 254 797 360 байт для сервиса, с помощью которого 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, читаем текстовое описание объектов, содержащихся внутри массива, прикрепленного к этой ветке.

Имя объекта

Содержимое

hrStorageDescr.1

A:

hrStorageDescr.2

C: Label:  Serial Number 445c03ba

hrStorageDescr.3

D:

hrStorageDescr.4

Virtual Memory

Как мы видим, объект номер 1 – это дисковод гибких дисков, а номера 2 и 3, соответственно, C: (жесткий диск) и D: (CD-ROM). Также интересен номер 4, представляющий объект, содержащий данные о количестве доступной виртуальной памяти. Идем по нашему массиву дальше и обращаемся к OID hrStorageAllocationUnits, описывающему размер в байтах одного блока памяти каждого из вышеназванных устройств.

Имя объекта

Содержимое

hrStorageAllocationUnits.1

0

hrStorageAllocationUnits.2

2048

hrStorageAllocationUnits.3

0

hrStorageAllocationUnits.4

65536

Как видим, размер блока для диска C: равен 2 048 байтам, а для виртуальной памяти соответствует 65 536 байт. Теперь нужно узнать общий размер памяти каждого из перечисленных устройств, используя OID hrStorageSize.

Имя объекта

Содержимое

hrStorageSize.1

0

hrStorageSize.2

1044209

hrStorageSize.3

0

hrStorageSize.4

4859

Стоит отметить, что размер считается в блоках, о которых мы говорили ранее. Значит, чтобы узнать размер диска C: в байтах, умножаем hrStorageAllocationUnits.2 на hrStorageSize.2 и в результате всех этих вычислений получаем цифру, примерно равную 2 гигабайтам. Таким же способом вычисляем размер виртуальной памяти и получаем 318 439 424 байта. Теперь внимание, подходим к самому главному. Данные о том, сколько памяти уже израсходовано, находятся внутри hrStorageUsed.

Имя объекта

Содержимое

hrStorageUsed.1

0

hrStorageUsed.2

418859

hrStorageUsed.3

0

hrStorageUsed.4

0

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

Догадаться, как узнать, сколько блоков в 1%, несложно. Я думаю, вы и сами легко сможете рассчитать для диска C: порог в 80% и 90% заполнения. Для моей системы это соответственно 835 367 и 938 788 блоков. При достижении этих значений Nagios должен будет отправлять нам предупреждение.

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

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

Я думаю, выбранных нами объектов достаточно для надежного мониторинга. По своему усмотрению вы можете добавить любые другие объекты к этому списку. У вас, например, могут работать службы, которые на моей тестовой машине отсутствуют. Благо, количество данных, хранящихся в базе MIB, позволяет собирать очень подробную статистику.

Завершив работу с Windows, переходим к FreeBSD. Для получения данных через SNMP Nagios использует модуль check_snmp. Ну а тот, в свою очередь, опирается на пакет программ net-snmp, предназначенный для работы с протоколом SNMP. Многим из администраторов этот пакет известен под старым названием ucd-snmp. Вы можете использовать либо ucd-snmp, либо net-snmp. Я же по своей давно укоренившейся привычке стараюсь использовать новейшее из доступного на данный момент программного обеспечения. Поэтому, выбрав net-snmp, скачиваю самую последнюю версию пакета отсюда: http://net-snmp.sourceforge.net. На момент написания статьи это была версия 5.0.8. Распаковываю архив исходного кода и начинаю установку.

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

После того как я запустил скрипт configure, на экране появилось несколько вопросов, на которые обязательно нужно дать ответ.

# ./configure

Defaul version  of SNMP to use (3): 3

# Версия протокола SNMP, которую надлежит использовать по умолчанию для всех запросов.

# Можно написать 1, 2c, 3. Я, как всегда, выбрал самую новую.

System contact infomation  root@: tigrisha@sysadmins.ru

# Адрес лица, ответственного за работу SNMP. Можно писать что угодно.

System Location (Unknown): home

# Географическое местоположение этой машины. Снова можно писать все, что придет в голову.

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

# Сюда демон snmpd будет записывать файлы журналов своей работы

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

# А тут подсистема SNMP будет хранить свою рабочую информацию

Убедившись в том, что скрипт configure завершил работу без ошибок, начинаем сборку.

# make

Затем, задав с помощью команды umask права на все вновь создаваемые файлы, проводим инсталляцию.

# umask 022

# make install

Все выполняемые файлы программ из этого пакета устанавливаются в /usr/local/bin/. Этот факт желательно запомнить, потому что в будущем подобные знания нам очень пригодятся. По завершении установки в /usr/local/bin появятся следующие утилиты для работы с SNMP:

  • snmpbulkget
  • snmpbulkwalk
  • snmpcheck
  • snmpconf
  • snmpdelta
  • snmpdf
  • snmpget
  • snmpget.old
  • snmpgetnext
  • snmpinform

Не стоит отчаиваться, если процедура инсталляции по каким-либо причинам у вас не сработает. Net-snmp, как и ucd-snmp, можно установить из портов или пакетов, поставляющихся вместе с FreeBSD. Например, в дистрибутиве FreeBSD 4.7, на которой работает описываемая система, обе вышеназванных программы можно получить с 4 диска, содержащего коллекцию пакетов. Оба упомянутых пакета находятся внутри ветки Net. Я надеюсь, вы умеете самостоятельно устанавливать программы из портов или пакетов. Если брать программы из этой коллекции, то мы можем стать обладателями довольно свежих экземпляров net-snmp версии 5.0.3_2 или ucd-snmp версии 4.2.5_2. Каким путем пойти, оставляю полностью на ваше усмотрение. Все три способа установки проверены мною лично. Могу сказать, что они работают нормально, и наступить на грабли можно только при фатальном невезении.

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

# /usr/local/etc/rc.d/snmpd.sh stop

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

Я надеюсь, что все помнят: подключаемые модули Nagios находятся в пакете nagios-plugins. Я использовал версию 1.3.0 – beta 3. Несмотря на то, что этот пакет у вас, скорее всего, уже установлен, модуля check_snmp в директории /usr/local/libexec/, скорее всего, нет. Такой поворот событий встречается довольно часто. А произошло это потому, что на машину сначала был установлен nagios-plugins и только затем одна из версий snmp. Скрипт configure, выполняемый перед компиляцией модулей, пытаясь удовлетворить все зависимости, запрашиваемые пакетом, не нашел на вашей машине ни ucd-snmp, ни net-snmp. Значит, нам нужно сконфигурировать пакет nagios-plugins заново. После распаковки переходим в каталог с исходными текстами nagios-plugins и выполняем следующие команды:

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

# gmake all

# gmake install

Разобравшись с первоначальной настройкой, приступим к изучению того, как это работает. Для сбора данных модуль check_snmp использует программу snmpget. Давайте попробуем выполнить из командной строки проверку времени работы Windows-машины с момента последней перезагрузки.

#/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

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

-v 1

# Версия протокола. Windows поддерживает  версии 1 и 2c. Лучше использовать 2с, потому что версия 1 небезопасна.

–m ALL

# Приказываем использовать все имеющиеся файлы MIB

–c QWEmn90

# Имя сообщества, используемое для доступа к данным. Позволяет только чтение. 

win2000rus

# Имя или IP-адрес машины, которой нужно отправить запрос.

OID

# Идентификатор объекта, в котором находятся интересующие нас данные.

В свою очередь, результаты работы snmpget обрабатываются check_snmp и передаются Nagios. Вот тут нас поджидают две ловушки. Проблема первая состоит в том, что формат вызова snmpget зависит от того, из какого пакета производилась установка средств для работы с SNMP.

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

Версия net-snmp:

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

Версия ucd-snmp:

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

Выполните обе команды и, в зависимости от версии SNMP-программ, полюбуйтесь на появившиеся ошибки. Вторая проблема состоит в том, что snmpget упрямо не хочет работать с OID, созданными SNMP4W2K и SNMP4NT. К примеру, попробуйте выполнить два разных варианта команды, получающей с удаленной машины данные о загрузке процессора. Обратите внимание, OID для краткости записан в цифровом виде.

Версия net-snmp:

# /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

Версия ucd-snmp:

# /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

Казалось бы, вид ошибок, полученных в ответ на команды, должен повергнуть нас в жесточайшее разочарование. Но не тут то было. Вместо snmpget мы станем использовать программу snmpwalk, которая гораздо стабильнее работает с нестандартными OID. Итак, переделываем наши команды и снова радуемся жизни.

Версия net-snmp:

# /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

Версия ucd-snmp:

# /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

Разобравшись с этими мелкими проблемами, переходим к работе по исправлению модуля check_snmp. Идем в директорию plugins и открываем на редактирование файл исходного кода check_snmp.c. Ищем в нем вот такой фрагмент текста, отвечающий за вызов команды snmp_get:

/* 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);

Найдя нужный фрагмент, заменяем его на вариант для своей версии пакета snmp.

Версия net-snmp:

/* 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);

Версия ucd-snmp:

/* 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

Теперь пришло время снова проверить работоспособность модуля check_snmp. Для этого мы попытаемся получить многократно упоминаемые ранее данные о загрузке процессора Windows-машины. Заодно узнаем, насколько правильно работает OID из коллекции SNMP4W2K:

#/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

Судя по полученному ответу, модуль наконец-то заработал как положено. Загрузка процессора равна 12%, что, в общем, очень даже неплохо.

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

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

}

Давайте разберемся со значением макросов, передаваемых команде check_snmp.

  • $USER1$ – путь к директории /usr/local/nagios/libexec/;
  • $HOSTADDRESS$ – адрес проверяемой машины;
  • $ARG1$ – OID, данные которого мы будем читать;
  • $ARG2$ – имя сообщества SNMP;
  • $ARG3$ – порог, при достижении которого нужно генерировать предупреждение;
  • $ARG4$ – порог критического состояния;
  • $ARG5$ – данные, которые необходимо добавить к выводимому результату. Например, для удобства можно к результатам запросов о свободной памяти дописывать строку «bytes».

Обратите внимание на опцию -l "". Она позволяет заменить строку, добавляющую в результате статус snmp-запроса. Обычно статус выглядит так «SNMP OK». Мне эта строка показалась лишней, поэтому я заменяю ее пустотой.

В дальнейшем я предполагаю, что вы, прочитав первую часть статьи, внесли все необходимые для работы с машиной win2000rus данные в файлы hosts.cfg, hostgroups.cfg, поэтому говорить о них мы не будем. Разобравшись с определением команд, переходим к описанию тестируемых сервисов.

# Сервис, показывающий  данные о проценте использования файла подкачки

define service{

 use    generic-service

 host_name  win2000rus

 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

 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

 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

 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

 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% заполнения, соответствующих

# 25 479 7360 байтам, и критическое состояние, наступающее при заполнении 90% памяти,

# устанавливаем на отметку в 286 647 030  байт. В результат, возвращаемый модулем,

# добавляем строку “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

 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

}

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

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

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


Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru