Развёртывание и настройка Icinga 2 на Debian 8.6. Часть 13.2. Настройка мониторинга сетевых устройств в Icinga Director (на примере контроллеров управления ИБП). Получение SNMP Trap

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

  • snmptrapd – Служба SNMP Trap Daemon из состава Net-SNMP. Данная служба отвечает за прослушивание на сервере мониторинга UDP-порта и получение от внешних сетевых устройств сообщений SNMP Trap
  • snmptt – Служба SNMP Trap Translator (SNMPTT). Данный элемент отвечает за разбор и интерпретацию сообщений SNMP Trap, полученных от службы snmptrapd. В частности он преобразует числовые идентификаторы OID в читаемый формат, используя подключаемые MIB-файлы.
  • submit_snmp_trap – Скрипт, который принимает от службы snmptt нормализованное Trap-сообщение и, преобразовав данные этого сообщения в понятный для Icinga формат, отправляет их в командный pipe-файл Icinga.
  • "SNMP Trap" - специальная пассивная Служба Icinga, в которую будут "прилетать" данные из pipe-файла Icinga. Данная Служба будет служить нам для визуализации конечного результата в веб-интерфейсе Icinga Web 2, а также организации оповещений администратора о проблеме.


Настраиваем сетевые устройства на отсылку сообщений SNMP Trap

Как и в прошлый раз, в качестве сетевых устройств, отсылающих сообщения SNMP Trap, мы будем использовать пару контроллеров управления источниками бесперебойного питания (ИБП) фирм EATON и APC.

В нашем примере используется ИБП EATON Powerware 9125 6kVA c контроллером управления X-Slot ConnectUPS Web/SNMP Card с прошивкой firmware v4.38. Настройку конфигурации получателей SNMP Trap в этом случае можно произвести через веб-интерфейс. В разделе Configuration > SNMP Trap Receivers добавляем IP-адрес нашего сервера Icinga, который будет выступать в качестве получателя сообщений SNMP Trap. Задаём строку Community String, отличную от используемой по умолчанию ("public"), например "mySecr8Trap".

Следующим настроим ИБП APC Smart-UPS 5000 RM с контроллером управления UPS Network Management Card AP9617 с прошивкой firmware - Application Module "sumx" v3.7.2/APC OS "aos" v3.7.3. В данном случае в веб-интерфейсе контроллера управления перейдём в Administration > Notification > SNMP Traps > trap receivers. Здесь включим опцию Trap Generation и укажем IP-адрес нашего сервера Icinga, а также строку  Community Name.

Данных минимальных настроек достаточно для того, чтобы контроллеры управления ИБП смогли отсылать сообщения SNMP Trap на наш сервер Icinga.



Настраиваем SNMP Trap Daemon (snmptrapd)

Переходим на консоль нашего сервера Icinga и выполняем устанавливаем необходимых пакетов из официальных репозиториев Debian Jessie:

# apt-get install snmpd snmptrapd snmptt

Настраиваем конфигурацию службы snmptrapd. В файл /etc/snmp/snmptrapd.conf добавляем строки:

...
traphandle default /usr/sbin/snmptthandler
#disableAuthorization yes
authCommunity log,execute,net mySecr8Trap
#ignoreAuthFailure yes

Данная настройка обозначает то, что получаемые службой snmptrapd сообщения SNMP Trap передаются службе-транслятору SNMPTT для обработки с помощью snmptthandler. Параметр authCommunity определяет необходимость аутентификации SNMP-агентами посредствам предоставления строки подключения Community string (в нашем примере это "mySecr8Trap").

В некоторых случаях SNMP-агенты (сетевые устройства, отсылающие трапы) не умеют работать со строкой подключения Community string и поэтому не могут быть аутентифицированы службой snmptrapd. В таком случае придётся отключить проверку строки подключения, закомментировав параметр authCommunity и включив параметр disableAuthorization.

***

Разрешим запуск UDP-прослушивателя на порту 162 для службы snmptrapd, изменив файл /etc/default/snmptrapd:

...
TRAPDRUN=yes
...

При этом UDP-прослушиватель SNMP-агента на порту 161 для службы snmpd, как таковой, на самом сервере мониторинга нам не нужен, поэтому выключим его запуск, изменив файл /etc/default/snmpd

...
SNMPDRUN=no
...

Для вступления изменений в силу, перезапустим службы:

# systemctl restart snmpd.service
# systemctl restart snmptrapd.service

Убедимся в том, что UDP-прослушиватель на порту 161 от службы snmpd исчез, а на порту 162 от службы snmptrapd появился:

# netstat -nlup | grep snmp

udp  0  0  0.0.0.0:162  0.0.0.0:*  32650/snmptrapd

При необходимости добавим на нашем сервере мониторинга правило iptables, разрешающее входящий UDP трафик на соответствующий порт:

# iptables -A INPUT -i eth0 -p udp -m udp --dport 162 -m comment --comment "SNMP Traps" -j ACCEPT

Со службой-"ловушкой" трапов разобрались, переходим к получению MIB-файлов и настройке snmptt



Получаем MIB-файлы

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

# apt-get install snmp-mibs-downloader

Чтобы выполнить обновление стандартных mib-файлов в подкаталогах каталога /var/lib/mibs, можно использовать команду:

# /usr/bin/download-mibs

***

Далее загрузим с сайтов производителей mib-файлы, поставляемые к оборудованию. Для размещения этих файлов в профиле пользователя создадим специальный каталог ~/.snmp/mibs (утилита snmpttconvertmib будет искать mib-файлы в этом каталоге)

# mkdir -p ~/.snmp/mibs
# mv /tmp/*-MIB.txt ~/.snmp/mibs
# ls -la ~/.snmp/mibs/
..
-rw-r--r-- 1 root root 2548811 Apr 21 13:15 PowerNet-MIB.txt
-rw-r--r-- 1 root root   74964 Apr 21 13:15 XUPS-MIB.txt

В данном примере основной mib-файл PowerNet-MIB.txt относится к ИБП APC,  а другой основной mib-файл XUPS-MIB.txt относится к ИБП Eaton. Однако этих файлов нам будет недостаточно, так как mib-файлы производителей содержат в себе директиву импорта данных из других mib-файлов:

Для успешной конвертации с помощью утилиты snmpttconvertmib, которую мы будем делать на следующем этапе, нам потребуется собрать все соответствующие mib-файлы в одном месте. В моём примере помимо обновлённого с помощью утилиты download-mibs набора стандартных mib-файлов, дополнительно потребовалось отыскать на просторах интернета ещё несколько файлов (EATON-OIDS, EATON-EMP-MIB, RFC-1212, RFC-1215). Кстати, внушительную коллекцию mib-файлов разных производителей мне удалось обнаружить по ссылке GitHub.com- librenms – mibs.



Настраиваем SNMP Trap Translator (snmptt)

Собранные нами mib-файлы в чистом виде не годятся для работы транслятора snmptt. Поэтому с помощью специальной утилиты snmpttconvertmib нам потребуется сконвертировать информацию о трапах из mib-файлов в специальные правила, с помощью которых snmptt будет приводить получаемые трапы в читаемый для человека вид. Эти правила по умолчанию хранятся в конфигурационном файле /etc/snmp/snmptt.conf.   

Чтобы не возиться отдельно с конвертацией каждого mib-файла, создадим простой скрипт, который будет считывать все mib-файлы, помещённые нами ранее в каталог ~/.snmp/mibs и с помощью утилиты snmpttconvertmib конвертировать их в правила обработки трапов для snmptt.

# touch ~/.snmp/snmptt-mib-convert.sh
# chmod 700 ~/.snmp/snmptt-mib-convert.sh

Наполним скрипт содержимым:

#!/bin/bash
#
for vMIB in ~/.snmp/mibs/*.txt
do
echo "Processing $vMIB"
snmpttconvertmib --in=$vMIB --out=/etc/snmp/snmptt.conf --exec='/usr/lib/nagios/plugins/submit_snmp_trap $r "SNMP Trap" 1' | grep translations
done

Здесь submit_snmp_trap это имя скрипта, который нормализует данные для Icinga (сделаем его далее), а "SNMP Trap" это имя пассивной Службы Icinga, которую мы создадим в Icinga Director чуть позднее.

Перед запуском конвертации, на всякий случай сохраним оригинальный файл snmpt.conf, после чего выполним скрипт конвертации:

# cp /etc/snmp/snmptt.conf /etc/snmp/snmptt.conf.backup
# ~/.snmp/snmptt-mib-convert.sh

В результате конвертации файл snmptt.conf будет дополнен множеством блоков типа:

...
#
EVENT xupstdOnMaintenanceBypass .1.3.6.1.4.1.534.1.11.4.1.0.48 "Status Events" MAJOR
FORMAT The UPS has been placed on Maintenance / Manual Bypass by an operator. $*
EXEC /usr/lib/nagios/plugins/submit_snmp_trap $r "SNMP Trap" 1 "The UPS has been placed on Maintenance / Manual Bypass by an operator. $*"
SDESC
The UPS has been placed on Maintenance / Manual Bypass by an operator.
Variables:
  1: xupsAlarmID
  2: xupsAlarmDescr
  3: xupsTrapMessage
EDESC
#
...

Каждый такой блок является конвертированным правилом обработки трапа, прочитанного из mib-файла производителя. В частности, оператор EXEC в блоке отвечает за вызов команды, которая будет передавать нормализованный средствами snmptt трап во внешнее приложение (в нашем случае это скрипт submit_snmp_trap).

***

В данном примере мы используем наполнение стандартного конфигурационного файла snmptt.conf, хотя можно сделать и собственный отдельный файл. В случае создания собственного файла, его нужно будет подключить в секции [TrapFiles] конфигурационного файла /etc/snmp/snmptt.ini:

...
[TrapFiles]
snmptt_conf_files = <<END
/etc/snmp/snmptt.conf
END
...

Как я уже сказал, мы используем стандартный snmptt.conf, поэтому нам делать дополнительные правки файла snmptt.ini на предмет подключения conf-файлов не требуется.

***

Дополнительно в snmptt.ini в секции [General] может потребоваться включить параметр net_snmp_perl_enable, чтобы snmptt задействовал дополнительный функционал нормализации значений OID:

...
[General]
...
net_snmp_perl_enable = 1
...

Пример проблемы, связанной с выключенным состоянием этого параметра опишу далее в секции "Поиск и устранение проблем". Чтобы данный параметр работал успешно, необходимо, чтобы в систему был установлен пакет net-snmp-perl

# dpkg -l | grep net-snmp-perl

ii   libnet-snmp-perl   6.0.1-2   all   Script SNMP connections

***

Ещё в snmptt.ini в секции [DaemonMode] можно задействовать параметр duplicate_trap_window, чтобы snmptt игнорировал повторяющиеся трапы в течение некоторого интервала времени :

...
[DaemonMode] ... duplicate_trap_window = 300 ...

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

***

После всех изменений, вносимых в конфигурационные файлы snmptt.ini и snmptt.conf, необходимо перезапускать службу snmptt:

# systemctl restart snmptt.service

Переходим к настройке скрипта submit_snmp_trap.



Настраиваем скрипт submit_snmp_trap

Как уже было отмечено ранее, согласно правил, которые мы добавили в snmptt.conf, нормализованный трап будет передаваться скрипту submit_snmp_trap. Создадим этот скрипт:

# touch /usr/lib/nagios/plugins/submit_snmp_trap
# chmod +x /usr/lib/nagios/plugins/submit_snmp_trap

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

Наполним скрипт содержимым:

#!/bin/sh
#
# Arguments:
#  $1 = host_name (Short name of host that the service is associated with)
#  $2 = svc_description (Description of the service)
#  $3 = return_code (An integer that determines the state of the service check.
#       0=OK, 1=WARNING, 2=CRITICAL, 3=UNKNOWN).
#  $4 = plugin_output (A text string that should be used
#       as the plugin output for the service check)
#
echocmd="/bin/echo"
CommandFile="/var/run/icinga2/cmd/icinga2.cmd"
#
datetime=`date +%s`
cmdline="[$datetime] PROCESS_SERVICE_CHECK_RESULT;$1;$2;$3;$4"

## Normal mode (comment lines in Debug mode)
`$echocmd $cmdline >> $CommandFile`

## Debug mode (comment lines in Normal mode)
#LogFile="/var/log/snmptt/script.log"
#`$echocmd $cmdline >> $CommandFile 2>> $LogFile`
#error=$?
#$echocmd $error >> $LogFile
#exit 0

Данный скрипт будет преобразовывать полученный от snmptt нормализованный трап и передавать его в удобоваримом для Icinga виде в командный pipe-файл icinga2.cmd.



Настраиваем права доступа к pipe-файлу icinga.cmd

Учитывая то обстоятельство, что в скрипте submit_snmp_trap мы используем запись в командный pipe-файл icinga2.cmd, нам потребуется обеспечить права доступа к этому файлу для учётной записи, от имени которой работает служба snmptt. Давайте посмотрим, какие разрешения установлены на командный pipe-файл icinga2.cmd:

# ls -la /var/run/icinga2/cmd/icinga2.cmd

prw-rw---- 1 nagios www-data 0 Apr 22 15:40 /var/run/icinga2/cmd/icinga2.cmd

Кстати, про доступ к этому файлу уже упоминалось ранее в заметке про установку Icinga Web 2.
Там же я рассматривал пример того, как проверить доступ к этому pipe-файлу от имени другого пользователя.
В типичной ситуации достаточно было бы добавить пользователя snmptt в группу www-data

# usermod -a -G www-data snmptt
# id snmptt

uid=114(snmptt) gid=121(snmptt) groups=121(snmptt),33(www-data)

Однако в нашем случае этого оказалось недостаточно. После "разбора полётов" с неработающей отсылкой данных из службы snmptt в pipe-файл icinga.cmd стало понятно ("наше с кисточкой" Владимиру Валерьевичу), что служба snmptt имеет проблемы в случае, если используется попытка доступа к объектам файловой системы, для которых в качестве группы доступа выбрана не основная группа пользователя snmptt, а дополнительная. Возможно это какая-то особенность работы snmptt в Debian.

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

В конечном итоге в /etc/rc.local был добавлен "костыль", который в процессе загрузки системы ожидает создания pipe-файла icinga2.cmd, а после его появления добавляет нужные нам права доступа для пользователя службы snmptt. Добавляем данный фрагмент кода в конец файла /etc/rc.local перед строкой "exit 0":

...
# Set (rw) permissions to Icinga2 command pipe-file for snmptt.service user
#
icmd="/var/run/icinga2/cmd/icinga2.cmd" # Icinga2 command pipe-file path
ituser=snmptt                           # SNMP Trap Translator service user
intervals=180                           # Loop duration in 5-seconds intervals
#
count=0
while [ $count -lt $intervals ]; do
  if [ -e $icmd ]; then
    /bin/echo "Icinga2 command pipe-file exist. Add ACL for snmptt.service user"
    /bin/setfacl -m u:$ituser:rx /var/run/icinga2
    /bin/setfacl -m u:$ituser:rx /var/run/icinga2/cmd
    /bin/setfacl -m u:$ituser:rw $icmd
    break
  else
    /bin/echo "Icinga2 command pipe-file NOT exist. Sleep 5 sec...."
    count=`expr $count + 1`
    sleep 5
  fi
done

Чтобы проверить результат, перезагружаем сервер и смотрим события в логе /var/log/syslog

# cat /var/log/syslog | grep Icinga
...
15:45:17 ... rc.local[431]: Icinga2 command pipe-file NOT exist. Sleep 5 sec....
15:45:18 ... systemd[1]: Starting Icinga host/service/network monitoring system...
15:45:19 ... systemd[1]: Started Icinga host/service/network monitoring system.
...
15:45:23 ... rc.local[431]: Icinga2 command pipe-file exist. Add ACL for snmptt.service user

Проверяем то, что права доступа к pipe-файлу действительно выставлены так, как мы это задумали:

# ls -la /var/run/icinga2/cmd/icinga2.cmd

prw-rw----+ 1 nagios www-data 0 Apr 24 15:45 /var/run/icinga2/cmd/icinga2.cmd

# getfacl -p /var/run/icinga2 | grep snmptt

user:snmptt:r-x

# getfacl -p /var/run/icinga2/cmd | grep snmptt

user:snmptt:r-x

# getfacl -p /var/run/icinga2/cmd/icinga2.cmd | grep snmptt

user:snmptt:rw-

Теперь проблем с записью в pipe-файл Icinga у службы snmptt быть не должно.



Настраиваем пассивную Службу в Icinga Director

Как мы помним, одним из параметров вызова скрипта submit_snmp_trap является имя пассивной Службы Icinga "SNMP Trap". Теперь нам нужно перейти в веб-интерфейс Icinga Director и создать данную Службу.

Создадим Шаблон Службы, с именем "SNMP Trap". Для этого в веб-интерфейсе Icinga Web 2 переходим в раздел навигации Icinga Director > Services , на закладке Templates нажимаем ссылку Add и описываем новый Шаблон Службы.

В качестве Check command выберем команду-"пустышку" dummy. Обязательно определим параметр Accept passive checks в Yes.

Теперь созданный Шаблон Службы нужно привязать в Icinga к интересующим нас Хостам (контроллерам управления ИБП, добавленным в Icinga в качестве объектом мониторинга). Сделать это можно разными способами.

Например, с привязкой к созданному Шаблону Службы "SNMP Trap" можно создать правило Apply-Rule, которое породит создание Службы "SNMP Trap" для Хостов по заданным нами условиям, например, по по членству в Группах Хостов, которые мы создавали в предыдущей части "APC Smart-UPS". Обратите внимание на то, что в Apply-Rule мы должны использовать именно то имя Службы, которое мы задавали ранее в настройках snmptt.conf

Другой вариант назначения Шаблона Службы "SNMP Trap" на конечные Хосты – создать Шаблон Хостов, например с именем "SNMP Host", и привязать к нему Шаблон Службы "SNMP Trap".

А уже затем Шаблон Хостов "SNMP Host" привязать к самим Хостам.

В не зависимости от способа привязки созданного нами Шаблона Службы "SNMP Trap" к конечным Хостам результат должен быть одинаковым. А именно, в перечне Служб интересующих нас Хостов (модулей управления ИБП) должна появиться новая пассивная Служба с именем "SNMP Trap".

Первичную инициализацию Службы "SNMP Trap" для любого из Хостов мы можем выполнить в свойствах этой службы, щелкнув по ссылке Check now 

Служба перейдёт в состояние ОК

Теперь наш Хост в Icinga готов принимать трапы в Службу "SNMP Trap".



Проверяем результат

Некоторые сетевые устройства имеют функцию отсылки тестового сообщения SNMP Trap. Обладает такой возможностью и рассматриваемый в нашем примере контроллер управления ИБП APC Smart-UPS. В веб-интерфейсе контроллера управления перейдём в раздел Administration > Notification, в меню SNMP Traps выберем test и произведём отправку тестового трапа:

В веб-консоли Icinga Web 2 посмотрим как изменится при этом статус Службы "SNMP Trap" для соответствующего Хоста:

Как видим, отправленное с сетевого устройства сообщение SNMP Trap успешно получено в нашей системе мониторинга. Если же подобного результата нет, то переходим к следующей секции "Поиск и устранение проблем", хотя информация из неё, на мой взгляд, будет полезна при любом результате.



Поиск и устранение проблем

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

В первую очередь нам необходимо убедиться в том, что трап успешно попадает в службу snmptrapd. События получения трапов от внешних устройств-отправителей в службу snmptrapd в конфигурации по умолчанию фиксируются в логе /var/log/syslog:

# tail -n 0 -f /var/log/syslog | grep snmptrapd

...
Apr 24 16:37:20 KOM-AD01-MON20 snmptrapd[527]: 2017-04-24 16:37:20 kom-ad01-up011.holding.com [10.1.1.6] (via UDP: [10.1.1.6]:51421->[10.1.1.20]:162) TRAP, SNMP v1, community public#012#011iso.3.6.1.4.1.318 Enterprise Specific Trap (636) Uptime: 8 days, 6:39:57.30#012#011iso.3.6.1.2.1.1.3.0 = Timeticks: (71519730) 8 days, 6:39:57.30#011iso.3.6.1.6.3.1.1.4.1.0 = OID: iso.3.6.1.4.1.318.0.636
...

***

Далее, согласно заданной нами конфигурации в /etc/snmp/snmptrapd.conf, полученный трап передаётся в обработчик snmptthandler службы snmptt. Поэтому следующим этапом будет проверка лога /var/log/snmptt/snmptt.log. Типичная регистрация полученного от snmptrapd в snmptt трапа выглядит так:

# tail -n 0 -f /var/log/snmptt/snmptt.log

...
Mon Apr 24 16:37:20 2017 .1.3.6.1.4.1.318.0.636 INFORMATIONAL "Status Events" kom-ad01-up011.holding.com - APC: Test trap.: Test Trap.
...

Полученный трап snmptt пытается идентифицировать согласно правил в файле /etc/snmp/snmptt.conf. Чтобы понять, каков результат процедуры сопоставления данных полученного трапа с правилами snmptt.conf, нам может потребоваться включить режим отладки в файле /etc/snmp/snmptt.ini в секции [Debugging], указав файл, в который будет записываться отладочная информация.

...
[Debugging]
DEBUGGING = 2
DEBUGGING_FILE = /var/log/snmptt/debug.log
...

После включения/отключения режима отладки перезапускаем службу snmptt для вступления изменений в силу.

# systemctl restart snmptt.service

При включении отладки в указанный нами лог будет записываться подробная информация. В частности, разбирая первую же проблему, с помощью этого лога я обнаружил наличие невозможности преобразования OID, полученного с контроллера управления ИБП APC, в цифровой формат  

# tail -n 0 -f /var/log/snmptt/debug.log

...
Symbolic trap variable name detected (iso.3.6.1.2.1.1.3.0).  Will attempt to translate to a numerical OID
  Could not translate - Net-SNMP Perl module not enabled - will leave as-is
...

То есть, snmptt сбивало с толку значение OID, начинающееся с "iso.". И чтобы исправить эту проблему, и пришлось включать упомянутый выше параметр net_snmp_perl_enable в конфигурационном файле snmptt.ini, после чего трап успешно был распознан и сопоставлен с одним из правил в snmptt.conf.

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

# tail -n 0 -f /var/log/snmptt/debug.log

...
FORMAT line:
APC: Test trap.: Test Trap.
.1.3.6.1.4.1.318.0.636 INFORMATIONAL "Status Events" kom-ad01-up011.holding.com - APC: Test trap.: Test Trap.
EXEC line(s):
EXEC command:/usr/lib/nagios/plugins/submit_snmp_trap kom-ad01-up011.holding.com "SNMP Trap" 1 "APC: Test trap.: Test Trap."
...

В нашем случае эта команда запуска скрипта submit_snmp_trap с входными параметрами, в которые записаны данные, извлечённые из трапа и преобразованные из OID в читаемый вид.

После окончания отладки обязательно отключаем в snmptt.ini режим отладки (DEBUGGING = 0), чтобы не перегружать наш сервер.

***

Дополнительно на время отладки может помочь логирование всех трапов, для которых snmptt не смог применить ни одно из правил имеющихся в snmptt.conf. Для этого настроим опции в snmptt.ini

...
[Logging]
unknown_trap_log_enable = 1
unknown_trap_log_file = /var/log/snmptt/unknown.log
...

***

Как понятно из ранее упомянутого лога /var/log/snmptt/debug.log, на следующем этапе нормализованные данные трапа передаются в качестве параметра в скрипт /usr/lib/nagios/plugins/submit_snmp_trap. Поэтому, в первую очередь, нужно проверять право доступа на исполнение этого скрипта для пользователя, от имени которого выполняется служба snmptt.

# ls -la /usr/lib/nagios/plugins/submit_snmp_trap

-rwxr-xr-x 1 root root 741 Apr 21 18:56 /usr/lib/nagios/plugins/submit_snmp_trap

Если с правами всё в порядке и учтены замечания, описанные выше в секции "Права доступа к pipe-файлу icinga.cmd", то возможно, проблема кроется в том, как данные для отправки в Icinga, формируются в нужный для Icinga формат внутри скрипта submit_snmp_trap. Чтобы понять то, какие именно данные отправляются скриптом в pipe-файл Icinga, закомментируйте в скрипте единственную строчку отправки данных в pipe-файл Icinga в блоке Normal mode и раскомментируйте пять строчек в блоке Debug mode. Это приведёт к тому, что вместо отправки данных в pipe-файл Icinga, будет выполнятся запись результата работы скрипта в лог-файл /var/log/snmptt/script.log.

Когда строка данных, отправляемая скриптом в Icinga известна, можно попробовать вручную отправить эту строку в Icinga от имени пользователя службы snmptt:

# su -p snmptt
snmptt@KOM-AD01-MON20:~$ /bin/echo [`date +%s`] 'PROCESS_SERVICE_CHECK_RESULT;kom-ad01-up011.holding.com;SNMP Trap;1;Manual Test' >> /var/run/icinga2/cmd/icinga2.cmd

***

На конечном этапе, когда данные успешно отправлены в pipe-файл, в основном лог-файле Icinga должно появиться соответствующее событие:

# tail -n 0 -f /var/log/icinga2/icinga2.log
...
[2017-04-24 16:37:22 +0300] information/ExternalCommandListener: Executing external command: [1493041042] PROCESS_SERVICE_CHECK_RESULT;kom-ad01-up011.holding.com;SNMP Trap;1;APC: Test trap.: Test Trap.
...

На данном этапе могут возникать проблемы с тем, что мы неправильно указали службу, которая должна принимать в Icinga трапы (в нашем примере используется Служба с именем "SNMP Trap"). Может быть проблема с именем Хоста Icinga - неверный регистр, неверный формат имени Хоста, для Службы которого предназначается сообщение (например в pipe приходит сообщение для Хоста "kom-ad01-up011.holding.com", а в Icinga Хост имеет имя "KOM-AD01-UP011"). Это может быть IP вместо имени, если в обратной зоне DNS нет возможности разрешить IP в имя. В таком случае в логе мы можем увидеть ошибки типа:

# tail -f /var/log/icinga2/icinga2.log
...
[2017-04-25 10:05:12 +0300] information/ExternalCommandListener: Executing external command: [1493103912] PROCESS_SERVICE_CHECK_RESULT;10.3.2.10;SNMP Trap;1;APC: Test trap.: Test Trap.
[2017-04-25 10:05:12 +0300] warning/ExternalCommandListener: External command failed: Error: Cannot process passive service check result for non-existent service 'SNMP Trap' on host '10.3.2.10'
...

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

Дополнительные источники информации:

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