Мониторинг с помощью SNMP-ловушек

Вернуться в оглавление Pandora FMS

Сетевые устройства, поддерживающие SNMP, такие как коммутаторы, маршрутизаторы, серверы, принтеры или Access Panel, могут отправлять сигналы тревоги (или SNMP-ловушки) при наступлении определенных событий, таких как выход из строя интерфейса, слишком высокая загрузка процессора или сети, изменение состояния источника бесперебойного питания (ИБП или UPS) или заполнение раздела диска. Каждое устройство имеет свою собственную «коллекцию» возможных событий, которая отражается в коллекции, называемой MIB, в данном случае отличной от MIB, используемой для запроса устройства.

Ловушки отправляются только тогда, когда что-то происходит, таким образом, синхронно (не повторяясь во времени) устройством к приемнику ловушек SNMP. Pandora FMS имеет консоль приема ловушек, которая позволяет визуализировать ловушки, посылаемые контролируемыми объектами, и добавлять предупреждения к этим ловушкам. b>SNMP-ловушки принимаются через демон операционной системы, который запускается SNMP-сервером Pandora FMS при запуске сервера Pandora FMS. Этот демон сохраняет ловушки в журнале, расположенном по умолчанию в

/var/log/pandora/pandora_snmptrap.log

Ловушки обычно принимаются в «сыром» формате, т.е. с числовыми OID, в том случае, если MIB, установленный в ОС, не способен их разрешить. SNMP-консоль Pandora FMS Enterprise позволяет создавать правила для переименования числовых OID в буквенно-цифровые OID или простые описательные текстовые строки (например, «Интерфейс упал»), чтобы сделать работу с ловушками более интуитивно понятной. Pandora FMS также позволяет загружать MIBs ловушек любого производителя для автоматического определения этих правил, более подробную информацию вы можете получить в обучающем видео «Загрузка MIBs в Pandora FMS».

Чтобы работать с ловушками SNMP, сначала измените следующий параметр в /etc/pandora/pandora_server.conf, чтобы включить SNMP-консоль:

snmpconsole 1

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

 translate_variable_bindings 1
 translate_enterprise_strings 1

Вы также должны настроить файл /etc/snmp/snmptrapd.conf с необходимыми параметрами, например:

 authCommunity log public
 disableAuthorization yes

При такой конфигурации ловушки будут создаваться для сообщества public и не будут требовать авторизации.

Ловушки SNMPv3 отклоняются, если пользователь, отправляющий их, не добавлен в /etc/snmp/snmptrapd.conf с помощью директивы ''createUser''. Например:

 disableAuthorization yes
 createUser -e 0x0102030405 snmpv3user SHA mypassword AES

Для доступа к консоли приема ловушек перейдите в Monitoring > SNMP > SNMP Console, где отобразится список полученных ловушек. Значок лупы можно использовать для отображения всей информации о ловушке, так же как и с событиями. В этом разделе вы найдете подробную информацию о любой ловушке SNMP.

Для каждой ловушки отображаются следующие столбцы:

Status

Зеленый квадрат, если ловушка была проверена, и красный, если она не была проверена.

SNMP Agent

Агент, отправивший ловушку.

Enterprise string

OID или Object Identifier (Идентификатор объекта) отправленной ловушки. Одна ловушка может отправить только один фрагмент данных в этом поле.

Time Stamp

Время, прошедшее с момента получения ловушки.

Предупреждение

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

Действие

Действие с кнопками для подтверждения или удаления ловушки.

Цвета

Кроме того, ловушки имеют разный цвет (видимый как цвет фона линии ловушки) в зависимости от типа ловушки.

• Синий: ловушки типа обслуживания.
• Фиолетовый: ловушки информационного типа.
• Зеленый: ловушки типа normal.
• Желтый: ловушки типа warning.
• Rojo: ловушки типа critical.

Нажатие на Toggle Filter отображает или убирает поля для фильтрации ловушек.

Для эффективного управления ловушками можно подтверждать ловушки, чтобы администратор мог отличить ловушки, которые он уже просмотрел, от ловушек, которые не были просмотрены.

Чтобы подтвердить ловушку, нажмите на кружок слева от ловушки.

Также можно подтвердить несколько ловушек, отметив их и нажав кнопку Validate.

Можно удалять ловушки после их обработки, как по отдельности, так и путем множественного выбора и действия Delete.

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

Pandora FMS также имеет систему предупреждений для получаемых SNMP-ловушек. Они по большей части основаны на правилах фильтрации, ищут совпадения во всех возможных полях в соответствии с правилами, которые вы установили для запуска предупреждения. Вы можете узнать больше об предупреждениях Pandora FMS по этой ссылке.

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

Enterprise string

Основной OID ловушки. Ищется наличие строки, она может быть даже частью OID; например, 1.21.34.2.3 в более длинном OID. Вы можете использовать его таким же образом в поле и искать, как если бы это было: *1.21.34.2.3* (нет необходимости использовать звездочки в качестве подстановочных знаков).

Custom Value/OID

Производит поиск в полях Value ловушки, а также в полях Custom OID и Custom Value, т.е. в остальных полях TRAP. Здесь работает поиск по регулярному выражению. Например, если у вас есть ловушка, которая будет посылать строку «Testing TRAP 225», можно найти любую ловушку с подстрокой «Testing TRAP», используя регулярное выражение «Testing.*TRAP.*»

SNMP Agent

IP-адрес Агента, отправляющего ловушку. Он также позволяет использовать регулярное выражение или подстроку.

Trap type

Фильтрует по типу ловушки. Большинство генерируемых ловушек обычно имеют тип Other; если вы ничего не указали, ищет ловушки любого типа.

Single value

Фильтрует по значению ловушки. Это относится только к простому значению первичного OID, а не к какому-либо вторичному OID.

Variable bindings/Data #1-20'

Это регулярные выражения, которые пытаются сопоставить переменные от 1 до 20. Если происходит попадание, включается предупреждение. Значение переменной хранится в макросе _snmp_fx_ соответствующем (_snmp_f1_, _snmp_f2_, …). Хотя для двадцати переменных можно задать только одно регулярное выражение, макросы _snmp_fx_ доступны для всех них (_snmp_f11_, _snmp_f12_, …).

Field 1

Поле для установки параметра команды тревоги Field 1. Это поле, которое будет использоваться в случае, если вы решили сгенерировать событие, или при генерировании целевого email в случае, если вы выбрали действие eMail (если вам нужно перезаписать email по умолчанию в действии). Для получения дополнительной информации о предупреждениях в Pandora FMS перейдите по следующей ссылке

Field 2

Поле для установки параметра команды тревоги Field 2. Например, в случае отправки электронного письма это будет являтся темой сообщения. Если оставлен пустым, используется то, что было определено в действии.

Field 3

Поле для установки параметра команды тревоги Field 3. В случае отправки электронного письма это будет текстом сообщения. Если оставлен пустым, используется то, что было определено в действии.

Min. Number of Alerts

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

Max. Number of Alerts

Поле, определяющее максимальное количество раз, сколько действие будет выполнено в заданном интервале (или time threshold).

Time Threshold

Поле, в котором определяется время, которое должно пройти до сброса счетчика тревог. Этот счетчик используется для поля Min. Number of alerts.

Priority

Комбинация, с помощью которой устанавливается приоритет тревоги.

Alert Action

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

Position

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

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

• _data_: Целая ловушка
• _agent_: Имя Агента
• _address_: IP-Адрес
• _timestamp_: Дата ловушки
• _snmp_oid_: OID ловушки
• _snmp_value_: Значение OID ловушки

У вас есть основной OID .1.3.6.1.4.1.2789.2005, который идентифицирует ловушку, которая может содержать сообщения о перегреве процессора (и еще больше других сообщений). От производителя известно, что для этого типа оповещения используются две переменные, первая из которых идентифицирует его как перегрев, а вторая - значение температуры; обе являются текстовыми строками.

Для определения первой части ловушки используется только основной OID для выполнения первой фильтрации:

Вторая часть определения ловушки содержит основную часть. В первую переменную ловушки мы помещаем строку Head alert

Наконец, в Field 1 используйте макропеременные, содержащие значение переменных 1 и 2 полученной ловушки ( _snmp_f1_ и _snmp_f2_ ), сопровождаемые описательным текстом:

Таким образом, при срабатывании оповещения сгенерированное событие будет выглядеть так:

На сервере есть несколько параметров, которые используются для защиты системы от поступления шторма ловушек из одного и того же источника. Для этого используются следующие параметры конфигурации в файле pandora_server.conf>

• snmp_storm_protection> Максимальное количество ловушек, обрабатываемых в интервале защиты.
• snmp_storm_timeout> Интервал в секундах защиты от шторма ловушек. В течение этого интервала могут быть обработаны только X ловушек из одного источника (одного IP-адреса).
• snmp_storm_silence_period> Если он больше 0 при каждом срабатывании storm protection для определенного источника, текущее время плюс время отключения звука будут суммироваться. До истечения этого времени новые ловушки не будут регистрироваться для данного источника.

Когда эта защита срабатывает, это отражается в событии на консоли:

Защита от шторма ловушек в сочетании с фильтрацией ловушек (см. ниже) означает, что если вы получаете сотни тысяч ловушек в день, вы можете работать с несколькими тысячами ловушек, отсеивая лишние или бесполезные.

Некоторые системы получают большое количество ловушек, из которых только небольшой процент представляет интерес для мониторинга. С помощью Pandora FMS можно фильтровать ловушки, получаемые сервером, чтобы избежать излишней загрузки приложения. В разделе Monitoring > SNMP > SNMP Filters вы можете определить различные фильтры.

Добавьте описание и столько фильтров, сколько вам нужно, используя кнопку +:

Ловушка, соответствующая любому из них, будет автоматически отброшена сервером. Фильтр применяется как регулярное выражение к записи, соответствующей ловушке в журнале SNMP (по умолчанию /var/log/pandora/pandora_snmptrap.log), которая имеет следующий фиксированный формат:

%4y-%02.2m-%l[**]%02.2h:%02.2j:%02.2k[**]%a[**]%N[**]%w[**]%W[**]%q[**]%v\n

Будучи:

• %y> Текущий год.
• %m> Текущий месяц (числовое значение).
• %l> День текущего месяца.
• %h> Текущее время.
• %j> Текущая минута.
• %k> Текущая секунда.
• %a> Адрес происхождения (только ловушки версии 1).
• %N> OID.
• %w> Тип ловушки (числовой).
• %W> Описание ловушки.
• %q> Подтип ловушки (числовой).
• %v> Список переменных, разделенных табуляцией (custom OID).

Например, для фильтрации всех ловушек, отправленных хостом 192.168.50.20, мы можем определить следующий фильтр:

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

Этот вид позволяет просматривать статистику ловушек, как по источникам (IP-адресам), так и по OID. Это позволяет эффективно управлять фильтрами, определяя IP-адреса, которые генерируют больше всего ловушек, и OID, которые повторяются чаще всего. Система отображает статистику ловушек за последние 30 дней.

Чтобы облегчить оператору понимание ловушек, посылаемых мониторизируемыми устройствами, можно загрузить в Pandora FMS MIB-файлы производителя или отредактировать ловушки подстраиваясь под предпочтения пользователя .

«Редактирование ловушки» - это процесс «настройки» того, как ловушка выглядит на консоли. Чтобы отредактировать ловушку, перейдите в раздел Monitoring > SNMP > SNMP trap editor.

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

Появится страница, аналогичная следующей:

Таким образом, при просмотре ловушек с OID .1.3.6.1.4.1.2789.2005 они будут отображаться как «Blue box sample», и их будет легче различать: Их содержание (включая исходный OID) должно оставаться неизменным.

Custom OID - это регулярное выражение совместимое с Perl, которое будет соответствовать части строки ловушки, содержащей привязки переменных. Обычно нет необходимости переводить ловушку.

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

Пример переопределенной пользователем ловушки:

Эта опция используется для загрузки MIBS и расширения внутренней базы переводов Pandora FMS, чтобы при поступлении ловушки она автоматически переводилась по ее описанию. Перейдите Monitoring > SNMP > MIB uploader.

Для загрузки MIBs производителя нажмите на иконку Upload file(s), выберите файл и нажмите на кнопку Go.

После загрузки система включает его в свою библиотеку ловушек.

Описанные выше предупреждения относятся к случаям, когда ловушка хорошо определена, всегда одинакова и не имеет релевантной информации для спасения.

В других случаях может появиться ловушка следующего вида:

OID: .1.3.6.1.4.1.2789.2005
Value: 666
Custom data: 1.3.6.1.4.1.2789.2005.1 = STRING: "ID-00342"
.1.3.6.1.4.1.2789.2005.2 = STRING: "Automated check" .1.3.6.1.4.1.2789.2005.3 = STRING: "NIC Offline"
.1.3.6.1.4.1.2789.2005.4 = STRING: "4897584AH/345"

Эта ловушка, помимо OID и значения, содержит сложную информацию, основанную на нескольких OID и нескольких значениях. Ловушка может иметь в своей сложной части совершенно свободную структуру, основанную на парах OID и значений (счетчики, числовые, буквенно-цифровые, даты и т.д.).

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

Если вы подробно изучите расширенную информацию (Variable bindings), то найдете несколько полезных сведений. В частности, первое поле с OID, заканчивающееся на 2005.1, выглядит как идентификатор, а третье поле с OID, заканчивающееся на 2005.3, выглядит как сообщение об ошибке. Поля 2 и 4, похоже, не очень полезны, поскольку, например, 4º - это неизвестный нам код.

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

Chassis Alert: <сообщение об ошибке> в устройстве <идентификатор>

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

Это можно сделать в Pandora FMS с помощью расширенных регулярных выражений и селекторов. Более подробную информацию о регулярных выражениях можно найти, перейдя по этой ссылке.

Селекторы, использующие символы ( и ), позволяют «копировать» информацию, используя поисковое выражение.

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

.*.1.3.6.1.4.1.2789.2005.1 \= STRING\: \"([0-9\-\_A-Za-z]+)\"

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

.*.1.3.6.1.4.1.2789.2005.3 \= STRING\: \"([\sA-Za-z]+)\".*

После того как у вас есть информационные поля, их следует использовать в предупреждении. Для этого используются специальные макросы _snmp_f1_, _snmp_f2_, … _snmp_fn_, которые имеют смысл для предупреждений SNMP-ловушек.

Для построения сообщения используйте следующую строку:

Chassis Alert: _snmp_f2_ в устройстве _snmp_f1_

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

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

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

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

Это ловушка, полученная от коммутатора:

Таким образом, требуется сообщение:

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

Предупреждения, определяемые в ловушках, полностью независимы от механизма оповещения Pandora FMS, поэтому невозможно установить корреляции типа “тревога срабатывает, если температура поднимается до 29 градусов и срабатывает ловушка падения вторичного источника питания”. Предупреждения такого типа также не могут быть представлены (поскольку они в принципе не связаны ни с одним модулем Pandora FMS), поэтому невозможно связать мониторинг консоли ловушки с такими элементами, как отчеты или карты.

Специальный модуль SNMPTrap, содержащий ловушку, пересылаемую с консоли SNMP:

Для этого в Pandora FMS есть метод под названием Agent SNMP Trap Forwarding.. Эта опция (общая для сервера) направляет ловушку в специальный Модуль Агента под названием SNMPTrap в виде текстовой строки, если и только если IP-адрес источника ловушки определен как IP-адрес агента. Когда это происходит, ловушка поступает в виде строки текста Агенту в этом Модуле, который является Модулем, который определяется только при поступлении первой ловушки.

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

Так выглядит модуль «SNMPTrap»:

Это одна характеристика Enterprise и настраивается она в Setup > Setup > Enterprise с помощью следующей опции:

Параметр конфигурации для включения пересылки ловушек агентам:

Если этот параметр изменен, для начала работы службу сервера Pandora FMS необходимо перезапустить.

Другое решение - настроить предупреждение о ловушке, которая активирует более одного модуля агента. Например, ловушка заключается в записи в файл logs, и у вас есть агент, который читает этот файл и перепрыгивает, когда в нем появляется запись «1». Таким образом, модуль будет прыгать при получении нужной ловушки, и корреляция может быть установлена на основе полученной ловушки.

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

Для детальной обработки данных ловушки вся информация о ловушке может быть отправлена в скрипт, как результат предупреждения. Этот пример будет показан в журнале SNMP-консоли Pandora FMS:

2010-08-26 12:01:46 pandora 10.201.246.2 .1.3.6.1.4.1.1722 .1.3.6.1.4.1.1722.2.10.1.1.1 233 .1.3.6.1.4.1.1722.2.10.1.1.3 =

STRING:
AIX_Software_Failure .1.3.6.1.4.1.1722.2.10.1.1.2 = STRING: 08 25 2010 08:23:43:697685 .1.3.6.1.4.1.1722.2.10.1.1.8 =

STRING: 1: A
software error PERM with label CORE_DUMP, identifier C69F5C9B occurred at Wed Aug 2 5 10:22:28 DFT 2010 on dvs02 for

resource
SYSPROC. Cause is SOFTWARE PROGRAM ABNORMALLY TERMINATED. .1.3.6.1.4.1.1722.2.10.1.1.6 = STRING: 8
.1.3.6.1.4.1.1722.2.10.1.1.11 = STRING: An application may not work properly .1.3.6.1.4.1.1722.2.10.1.1.10 = STRING: An

application
may not work properly .1.3.6.1.4.1.1722.2.10.1.1.12 = INTEGER: 4 .1.3.6.1.6.3.1.1.4.3.0 = OID: .1.3.6.1.4.1.1722

На изображениях видно, как создается специальное предупреждение, которое выполняет скрипт с полным содержимым ловушки ( _data_ ) и как создается SNMP-предупреждение. В данном случае он был отображен для конкретного OID (.1.3.6.1.4.1.1722.2.10.1.1.1) но он мог бы быть более общим, например, (.1.3.6.1.4.1.1722) для вызова скрипта для любого типа ловушек этой типологии.

Выполняется скрипт, который обрабатывает эти данные и «анализирует» ловушку для записи данных непосредственно в Pandora FMS, генерируя XML и оставляя его в /var/spool/pandora/pandora/data_in в виде данных как если бы они пришли от агента. Базовый скрипт для этого случая может, например, генерировать сложную информацию, поскольку в этой ловушке довольно много информации, а именно:

• Источник IP.
• Главное событие (Cold start)
• Секундарные события (описательные): AIX_Software_Failure, 1: A software error PERM with label CORE_DUMP, identifier C69F5C9B occurred at Wed Aug 2 5 10:22:28 DFT 2010 on dvs02 for resource SYSPROC. Cause is SOFTWARE PROGRAM ABNORMALLY TERMINATED, An application may not work properly, An application may not work properly.

Разработав скрипт, который «разбирает» каждое из этих данных, например, «miscript.pl», и сохраняет в /var/spool/sandora/data_in XML с общим именем плюс случайное число, например: snmp_gateway.31415.data

Созданный XML должен выглядеть следующим образом.

<?xml version='1.0' encoding='ISO-8859-1'?>
<agent_data description='' group='' os_name='aix' os_version='' interval='300'

version='3.1(Build 100608)' timestamp='2010/08/26 12:20:26' agent_name='10.201.246.2'>
  <module>
    <name><![CDATA[Critical_Event]]></name>
    <description><![CDATA[]]></description>
    <type>async_proc</type>
    <data><![CDATA[1]]></data>
  </module>
<module>
    <name><![CDATA[events]]></name>
    <description><![CDATA[]]></description>
    <type>async_string</type>
    <datalist>
      <data><value><![CDATA[AIX_Software_Failure]]></value></data>
      <data><value><![CDATA[A software error PERM with label CORE_DUMP, identifier C69F5C9B occurred at Wed

Aug 2 5 10:22:28 DFT 2010 on dvs02 for resource SYSPROC.]]></value></data>
      <data><value><![CDATA[Cause is SOFTWARE PROGRAM ABNORMALLY TERMINATED, An application may not work

properly, An application may not work properly.]]></value></data>
    </datalist>
  </module>
</agent_data>

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

Одним из самых проблематичных вопросов для мониторинга является «распределенная» инфраструктура, особенно если каждая версия меняет свою реализацию для сбора информации, как, например, VmWare ESX. В этой небольшой главе мы попытаемся объяснить, как осуществлять мониторинг систем ESX с помощью внешнего менеджера SNMP-ловушек.

Ловушки ESX выглядят следующим образом:

.1.3.6.1.4.1.6876.4.3.301 = STRING: "host"  .1.3.6.1.4.1.6876.4.3.302 = STRING: "c7000-06-01.tsm.inet"

   .1.3.6.1.4.1.6876.4.3.303 = ""
.1.3.6.1.4.1.6876.4.3.304 = STRING: "Green" .1.3.6.1.4.1.6876.4.3.305 = STRING: "Yellow"

.1.3.6.1.4.1.6876.4.3.306 = STRING: "Host
cpu usage - Metric Usage = 1%"

.1.3.6.1.4.1.6876.4.3.301 = STRING: "host" .1.3.6.1.4.1.6876.4.3.302 = STRING: "dl360-00.tsm.inet" .1.3.6.1.4.1.6876.4.3.303 = "" .1.3.6.1.4.1.6876.4.3.304 = STRING: "Yellow".1.3.6.1.4.1.6876.4.3.305 = STRING: "Green" .1.3.6.1.4.1.6876.4.3.306 = STRING: "Host memory usage - Metric Usage = 84%"

.1.3.6.1.4.1.6876.4.3.301 = STRING: "host" .1.3.6.1.4.1.6876.4.3.302 = "" .1.3.6.1.4.1.6876.4.3.303 = "" .1.3.6.1.4.1.6876.4.3.304 = STRING: "Red" .1.3.6.1.4.1.6876.4.3.305 = STRING: "Green" .1.3.6.1.4.1.6876.4.3.306 = STRING: "Datastore usage on disk - Metric Storage space actually used = 55%"

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

1. Создать handler script. В своей работе вы можете использовать скрипт, представленный ниже.
2. Создайте команду предупреждения.
3. Создайте действие предупреждения с помощью вышеуказанных команд. Иногда с пользовательскими опциями для каждого агента «получателя», которого вы хотите (если у вас несколько групп ESX, вы наверняка выберете, чтобы данные находились на разных агентах).
4. Создайте предупреждение ловушки SNMP, которое отображает OID Enterprise (информация о ловушке для всех типов данной конкретной технологии и/или IP-адрес источника ловушки.

#!/usr/bin/perl
# (c) Sancho Lerena 2010 <[email protected]>
# Specific Pandora FMS trap collector for ESX

use POSIX qw(setsid strftime);

sub show_help {
    print "\nSpecific Pandora FMS trap collector for ESX\n";
    print "(c) Sancho Lerena 2010 <[email protected]>\n";
    print "Usage:\n\n";
    print "   esx_trap_manager.pl <destination_agent_name> <TRAP DATA>\n\n";
    exit;
}

sub writexml {
    my ($hostname, $xmlmessage ) = @_;
    my $file = "/var/spool/pandora/data_in/$hostname.".rand(1000).".data";

    open (FILE, ">> $file") or die "[FATAL] Cannot write to XML '$file'";
    print FILE $xmlmessage;
    close (FILE);
}

if ($#ARGV == -1){
    show_help();
}

$chunk = "";

# First parameter is always destination host for virtual server
$target_host = $ARGV[0];

foreach $argnum (1 .. $#ARGV) {
    if ($chunk ne ""){
        $chunk .= " ";
    }
    $chunk .= $ARGV[$argnum];
}

my $hostname = "";
my $now = strftime ("%Y-%m-%d %H:%M:%S", localtime());
my $xmldata = "<agent_data agent_name='$target_host' timestamp='$now' version='1.0'

os='Other' os_version='ESX_Collectordime ' interval='9999999999'>";

if ($chunk =~ m/.1.3.6.1.4.1.6876.4.3.302 \= STRING\: ([A-Za-z0-9\-\.]*)\s\.1/){
    $hostname = "_".$1;
}

if ($chunk =~ m/Host cpu usage \- Metric Usage \= ([0-9]*)\z/){
    $value = $1;
    $module_name = "CPU_OCUPADA$hostname";
}

if ($chunk =~ m/Host memory usage \- Metric Usage = ([0-9\.]*)\z/){
    $value = $1;
    $module_name = "MEMORIA_OCUPADA$hostname";
}

if ($chunk =~ m/Datastore usage on disk \- Metric Storage space actually used \= ([0-9\.]*)\z/){
    $value = $1;
    $module_name = "DISCO_OCUPADO$hostname";
}

$xmldata .= "<module><name>$module_name</name><type>async_data</type><data>

$value</data></module>\n";

$xmldata .= "</agent_data>\n";
writexml ($target_host, $xmldata);

В этом примере скрипт команды был помещен в /tmp, измените его на подходящее место и убедитесь, что он может быть выполнен (chmod 755):

Создайте конкретное действие для отправки всей информации на определенные ловушки агентов. В этом случае информация будет отправлена агенту по имени WINN1247VSR. Приведенная выше команда принимает в качестве параметров имя агента, который будет переносить всю информацию (ESX Virtual Center), и «куски» данных TRAP, которые могут быть неограниченными и включают всю информацию, которая отправляется в ловушку.

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

Вы также можете фильтровать по IP-источнику для каждого виртуального центра, фильтруя по IP-адресу источника (отправленному в ловушке).

Вот пример того, как будет выглядеть информация. Имея эти данные, вы можете управлять ими как стандартными модулями.

С Pandora FMS можно включить пересылку SNMP-ловушек на внешний хост, включив snmp_forward_trap в токене в конфигурационном файле Pandora.

 snmp_forward_trap 1
 snmp_forward_ip 192.168.1.145
 snmp_forward_version 1
 snmp_forward_secName
 snmp_forward_engineid
 snmp_forward_authProtocol
 snmp_forward_authPassword
 snmp_forward_privProtocol
 snmp_forward_privPassword
 snmp_forward_secLevel

 snmp_forward_trap 1
 snmp_forward_ip 192.168.1.145
 snmp_forward_version 2c
 snmp_forward_secName
 snmp_forward_engineid
 snmp_forward_authProtocol
 snmp_forward_authPassword
 snmp_forward_privProtocol
 snmp_forward_privPassword
 snmp_forward_secLevel

Этот пример особенно сложен из-за того, что необходимы знания для работы с SNMP v3. Мы будем считать, что удаленный SNMP-агент, определенный в snmp_forward_ip имеет следующую запись в своем конфигурационном файле /etc/snmp/snmptrapd.conf>

createUser -e 0x0102030405 myuser MD5 mypassword DES myotherpassword

Тогда конфигурация в конфигурационном файле Pandora FMS будет такой:

 snmp_forward_trap 1
 snmp_forward_ip 192.168.1.145
 snmp_forward_version 3
 snmp_forward_secName myuser
 snmp_forward_engineid 0x0102030405
 snmp_forward_authProtocol MD5
 snmp_forward_authPassword mypassword
 snmp_forward_privProtocol DES
 snmp_forward_privPassword myotherpassword
 snmp_forward_secLevel authNoPriv

Для получения дополнительной информации посетите NET-SNMP v3 Traps

Возможно, по какой-то причине вы предпочитаете управлять демоном snmptrapd независимо от Pandora FMS (останавливать или запускать его независимо от основного Daemon Pandora FMS). Для этого необходимо иметь в виду несколько моментов:

1. В любом случае Вы должны включить параметр snmpconsole в Сервере Pandora FMS.

2. Журналы, настроенные на сервере Pandora FMS, должны совпадать с теми, которые генерируются при независимом вызове snmptrapd

3. Вызов snmptrapd должен быть в определенном формате поскольку стандартный вызов системного демона недействителен. Вызов должен выглядеть следующим образом (особенно важен параметр -A):

/usr/sbin/snmptrapd -A -t -On -n -a -Lf /var/log/pandora/pandora_snmptrap.log -p /var/run/pandora_snmptrapd.pid --

format1=SNMPv1[**]%4y-%02.2m-%l[**]%02.2h:%02.2j:%02.2k[**]%a[**]%N[**]%w[**]%W[**]%q[**]%v\n --format2=SNMPv2[**]%4y-

%02.2m-%l[**]%02.2h:%02.2j:%02.2k[**]%b[**]%v\n

4. Вы должны настроить в файле конфигурации сервера token:

snmp_trapd manual

5. При настройке этой функции необходимо выполнить следующую операцию:

• Изменить конфигурацию в /etc/pandora/pandora_server.conf.
• Остановить сервер Pandora FMS.
• Подтвердить, что процесс snmptrapd больше не выполняется (и если да, подождите, пока он «затухнет» или «выключить его»).
• Запустить snmptrapd вручную(в формате, указанном выше).
• Запустить сервер de Pandora FMS.

Процесс snmptrapd может быть остановлен и запущен без необходимости остановки и запуска процесса сервера Pandora FMS, только в том случае, если файлы pandora_snmptrap.log.index и pandora_snmptrap.log не будут изменены. Если эти файлы изменены, необходимо перезапустить сервер Pandora FMS. Если вам необходимо внешне вращать журнал ловушек, вам следует перезапустить сервер Pandora FMS после удаления ранее упомянутых файлов.

Если ловушки SNMP отправляются внешнему менеджеру через ненадежное соединение, часть информации будет потеряна. Вместо этого Pandora FMS позволяет пересылать ловушки с локального snmptrapd на ваш сервер Pandora FMS надежным способом.

• Агент SNMP отправляет ловушки на локальный snmptrapd.
• Локальный агент Pandora FMS считывает ловушки из файла журналаsnmptrapd и отправляет их на указанный сервер Pandora FMS в файле данных XML, сохраняя его в XML-буфере и при необходимости повторяя попытку позже.
• Сервер данных считывает ловушки из файлов данных XML и сбрасывает их в обычный текстовый файл.
• Консоль SNMP обрабатывает ловушки из обычного текстового файла.

• Локальный snmptrapd, который получает ловушки.
• Локальный агент Pandora FMS.
• Установка Pandora FMS.

Отредактируйте файл /etc/snmp/snmptrapd.conf и убедитесь, что вы сохраняете журналы в файл в формате, совместимом с Pandora FMS (при необходимости вы можете переименовать файл журнала):

[snmp] logOption f /var/log/snmptrapd.log
format1 SNMPv1[**]%4y-%02.2m-%l[**]%02.2h:%02.2j:%02.2k[**]%a[**]%N[**]%w[**]%W[**]%q[**]%v\n
format2 SNMPv2[**]%4y-%02.2m-%l[**]%02.2h:%02.2j:%02.2k[**]%b[**]%v\n

Плагин grep_snmptrapd grep_snmptrapd, поставляемый с Агентом Pandora FMS, будет использоваться для чтения данных из файла журнала snmptrapd .

Отредактируйте файл конфигурации локального агента, /etc/pandora/pandora_agent.conf, и добавьте следующую строку, при необходимости изменив путь к файлу журнала snmptrad:

module_plugin grep_snmptrapd /var/log/snmptrapd.log

Вы должны указать SNMP-консоли обрабатывать ловушки из внешнего файла журнала, записанного сервером данных.

Отредактируйте файла конфигурации сервера /etc/pandora/pandora_server.conf>

• Убедитесь, что консоль SNMP включена:

snmpconsole 1

• Убедитесь, что сервер данных (Data Server) включен:

dataserver 1

• Настройте вешний файл журнала SNMP. Если он не существует, консоль SNMP создаст его:

snmp_extlog /var/log/pandora/pandora_snmptrap.ext.log

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

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

Host Address

IP-адрес назначения для отправки ловушки.

Community

Пароль сообщества SNMP, к которому вы пытаетесь получить доступ с помощью генератора ловушек.

Enterprise string

Настройте OID (Object Identifier) ловушки. Например: ''1.3.6.1.2.1.2.2.1.8''

. Value

Значение, которое вы хотите присвоить ловушке и которое затем появится как Data.

SNMP Agent

ВВедите агент, на котором мы будем имитировать ловушку, обязательно укажите его IP-адрес.

SNMP Type

Выберите тип SNMP из следующих вариантов:

• Cold Start: Указывает, что агент был запущен или перезапущен.
• Warm Start: Указывает, что конфигурация агента была изменена.
• Link down: Указывает на то, что интерфейс связи вышел из строя (неактивен).
• Link up: Указывает, что один интерфейс связи был активирован.
• Authentication failure: Указывает, что агент получил запрос от неавторизованной (контролируемой сообществом) NMS.
• EGP neighbor loss: Указывает, что в системах, где маршрутизаторы используют протокол EGP, близлежащий хост вышел из строя.
• Enterprise: Эта категория содержит все новые ловушки, включая ловушки поставщиков.

Вернуться в оглавление Документации Pandora FMS