В этой части нашего плана развёртывания Icinga на Debian GNU/Linux 12 "Bookworm" мы рассмотрим особенности настройки поддержки протокола SNMP и интеграции механизма получения SNMP Trap с интерфейсом Icinga 2 API. Предполагается, что на предыдущих этапах мы уже успешно развернули фронтэнд Icinga Web 2 и провели базовую настройку и наполнение данными модуля Icinga Director.
Опрос по протоколу SNMP
Ранее в статье "Настройка мониторинга сетевых устройств в Icinga Director (на примере контроллеров управления ИБП) на Debian 8.6. Опрос по протоколу SNMP" мы в подробностях рассматривали процесс
настройки поддержки протокола SNMP в Icinga Director. Ели развёртывание сервера Icinga и наполнение конфигурации Icinga Director выполняется "с нуля", то эта статья поможет разобраться в этом вопросе и выполнить все необходимые действия по конфигурированию Icinga Director.
В нашем же случае, вся конфигурация Icinga Director, связанная с SNMP, успешно перенесена со старого сервера с помощью механизма Configuration Baskets, поэтому выполнять данную настройку заново нет необходимости. Остаётся лишь выполнить установку пакета поддержки протокола SNMP:
# apt-get install snmp
В упомянутой выше статье использовался файл /etc/icingaweb2/modules/monitoring/config.ini для настройки веб-интерфейса Icinga Web с IDO DB на сокрытие полей, содержащих пароли и секретные фразы SNMP.
Отличительной особенностью настройки нового веб-интерфейса Icinga Web c Icinga DB является то, что теперь такую настройку нужно проводить через механизм управления ролями доступа.
В веб-консоли Icinga Web 2 в меню настроек выберем пункт "Access Control" и в свойствах той пользовательской роли, которую мы хотим настроить, выбираем модуль "icingadb". Развернём настройки доступа к модулю и в самом низу списка, согласно документа "Icinga DB Web Security", зададим значение поля "icingadb/protect/variables":
Для вступления изменений прав доступа к роли необходимо перелогиниться в веб-интерфейсе Icinga Web.
После этого в веб-интерфейсе Icinga Web, например на странице свойств Хоста, все переменные, подпадающие под указанную нами маску имени будут отображаться в виде "звёздочек".
Получение SNMP трапов
Ранее в статье "Настройка мониторинга сетевых устройств в Icinga Director (на примере контроллеров управления ИБП). Получение SNMP Trap" мы в подробностях рассматривали процесс интеграции механизма получения SNMP трапов с конфигурацией Icinga Director. Здесь мы не будем повторно рассматривать весь процесс настройки, а лишь пройдёмся по тем ключевым моментам, которые имеют какие-то особенности в контексте нового развёртывания сервера мониторинга Icinga на Debian 12.
Особенности настройки snmptrapd и snmpd в Debian 12
Переходим на консоль нашего сервера Icinga и устанавливаем необходимые пакеты из официальных репозиториев Debian:
# apt-get install snmpd snmptrapd snmptt
Настраиваем конфигурацию службы snmptrapd:
# nano /etc/snmp/snmptrapd.conf
По умолчанию этот файл содержит только закомментированные строки. Раскомментируем/добавим строки с параметрами traphandle, authCommunity. Подробнее об этих параметрах мы говорили ранее. Здесь в качестве дополнительного примера добавлены параметры createUser и authUser для определения правил, разрешающих приём трапов SNMPv3 с аутентификацией.
Результирующий конфигурационный файл может иметь следующий вид:
traphandle default /usr/sbin/snmptthandler
#
## Debug config: Disable any SNMP TRAP Authorization
#disableAuthorization yes
#
## Debug config: Write logs to syslog:
#authCommunity log,execute,net myCorpTrap
#authCommunity log,execute,net myCorpProbe
#authCommunity log,execute,net public
#authCommunity log,execute,net COMPAQ
#
## Normal config: Not write logs:
authCommunity execute,net myCorpTrap
authCommunity execute,net myCorpProbe
authCommunity execute,net public
authCommunity execute,net COMPAQ
#
#ignoreAuthFailure yes
#
# SNMPv3 TRAP settings for any engineID
createUser icinga2 SHA 'my!cinGaSekReT' DES 'my!cinGaSecRet'
authUser execute,net icinga2
#
# SNMPv3 TRAP settings for specific engineID (-e)
createUser -e 0x8000D68505D040BA000372 kom-up036 SHA 'my!SekR9eT' DES 'my!Se8Ret5'
authUser execute,net kom-up036
createUser -e 0x8000D68505D040BA0000DA kom-up037 SHA 'my!SekReT8' DES 'my!Sec9Ret'
authUser execute,net kom-up037
В отличии от ранее описанного процесса конфигурирования на Debian 8, на современной Debian 12 нам нет необходимости настраивать запуск UDP прослушивателя на порту 162 для службы snmptrapd через файл /etc/default/snmptrapd, так как сейчас за управление этим прослушивателем отвечает сокет snmptrapd.socket и служба snmptrapd.service.
По умолчанию этот сокет и служба настроены на запуск IPv4 UDP и IPv6 UDP прослушивателей на порту 162. И если мы захотим изменить эту конфигурацию (поменять номер порта, интерфейса или отключить IPv6), то нам придётся настроить переопределения для обоих объектов - snmptrapd.socket и snmptrapd.service.
Для примера, давайте отключим в конфигурации snmptrapd прослушиватель UPv6 UDP ([::]:162).
# ss -tunlp | grep snmp
udp UNCONN 0 0 127.0.0.1:161 0.0.0.0:* users:(("snmpd",pid=6935,fd=6))
udp UNCONN 0 0 0.0.0.0:162 0.0.0.0:* users:(("snmptrapd",pid=7224,fd=3),("systemd",pid=1,fd=46))
udp UNCONN 0 0 [::]:162 [::]:* users:(("snmptrapd",pid=7274,fd=4),("systemd",pid=1,fd=47))
Остановим службу и сокет:
# systemctl stop snmptrapd.service
# systemctl stop snmptrapd.socket
Создадим переопределение для юнита службы snmptrapd.service
# systemctl edit snmptrapd.service
Внесём в файл корректировку:
### Editing /etc/systemd/system/snmptrapd.service.d/override.conf
### Anything between here and the comment below will become the new contents of the file
[Service]
ExecStart=
ExecStart=/usr/sbin/snmptrapd -LOw -f udp:162
### Lines below this comment will be discarded
### /lib/systemd/system/snmptrapd.service
# [Unit]
# Description=Simple Network Management Protocol (SNMP) Trap Daemon.
#
# [Service]
# Type=notify
# User=Debian-snmp
# ExecStart=/usr/sbin/snmptrapd -LOw -f udp:162 udp6:162
# ExecReload=/bin/kill -HUP $MAINPID
Сохраним изменения и закроем текстовый редактор (произойдёт создание и сохранение файла переопределений /etc/systemd/system/snmptrapd.service.d/override.conf).
По аналогии создадим переопределение для сокета snmptrapd.socket:
# systemctl edit snmptrapd.socket
Внесём в файл корректировку:
### Editing /etc/systemd/system/snmptrapd.socket.d/override.conf ### Anything between here and the comment below will become the new contents of the file [Socket] ListenDatagram= ListenDatagram=0.0.0.0:162 ### Lines below this comment will be discarded ### /lib/systemd/system/snmptrapd.socket # [Unit] # Description=sockets for SNMP trap messages # # [Socket] # BindIPv6Only=ipv6-only # ListenDatagram=0.0.0.0:162 # ListenDatagram=[::]:162 # # Enable other listening addresses as needed - UNIX, TCP, TCP6. # # They must match listening addresses/ports defined in snmptrapd.service # # or snmptrapd.conf. # # ListenStream=0.0.0.0:162 # # ListenStream=[::]:162 # # [Install] # WantedBy=sockets.target
Сохраним изменения и закроем тактовый редактор (произойдёт создание и сохранение файла переопределений /etc/systemd/system/snmptrapd.socket.d/override.conf).
Выполним перезагрузку конфигурации systemd:
# systemctl daemon-reload
Заново запустим сокет и службу (ошибок при запуске быть не должно):
# systemctl start snmptrapd.socket
# systemctl start snmptrapd.service
Проверим, какие теперь с системе видны прослушиватели для snmp:
# ss -tunlp | grep snmp
udp UNCONN 0 0 127.0.0.1:161 0.0.0.0:* users:(("snmpd",pid=6935,fd=6))
udp UNCONN 0 0 0.0.0.0:162 0.0.0.0:* users:(("snmptrapd",pid=7235,fd=3),("systemd",pid=1,fd=46))
Как видим, прослушиватель [::]:162 больше не присутствует.
Теперь поговорим о службе snmpd. Как видим из последнего вывода, служба snmpd держит в системе IPv4 UDP прослушиватель на порту 161. Но эта служба и её открытый порт, как таковые, в нашем случае на самом сервере мониторинга не нужны. Поэтому просто выключим автоматический запуск службы:
# systemctl stop snmpd
# systemctl disable snmpd
Проверим как изменилась ситуация по открытым портам:
# ss -tunlp | grep snmp
udp UNCONN 0 0 0.0.0.0:162 0.0.0.0:* users:(("snmptrapd",pid=1307,fd=3),("systemd",pid=1,fd=139))
Вот теперь мы добились желаемого результата - на сервере висит только один открытый порт "ловушки" SNMP, на который будут приниматься SNMP трапы с хостов локальной сети.
Не забываем внести в nftables правило, разрешающее подключения на порт UDP 162.
Особенности настройки snmptt в Debian 12
Со службой-"ловушкой" трапов разобрались, переходим к получению MIB-файлов и настройке snmptt.
Процедура соответствует разделам "Получаем MIB-файлы" и "Настраиваем SNMP Trap Translator (snmptt)", описанным в ранее упомянутой статье "Настройка мониторинга сетевых устройств в Icinga Director (на примере контроллеров управления ИБП). Получение SNMP Trap". То есть, следуя информации из этих разделов, мы:
- Соберём нужные MIB-файлы в каталог ~/.snmp/mibs/;
- Создадим и выполним скрипт конвертации MIB-файлов (~/.snmp/snmptt-mib-convert.sh) для наполнения конфигурации в /etc/snmp/snmptt.conf;
- Подключим наполненный файл /etc/snmp/snmptt.conf в конфигурации /etc/snmp/snmptt.ini;
- Внесём дополнительные корректировки в /etc/snmp/snmptt.ini и перезапустим службу snmptt.service;
Из отличительных особенностей по сравнению с предыдущим описанием, можно лишь отметить, что в конфигурационном файле snmptt.ini версии 1.5 в Debian 12 появился параметр "ipv6_enable=1", который включен по умолчанию и его можно выключить, если IPv6 не используется. Иначе, если этот параметр будет оставаться включенным и при этом в системе не будет установлен perl модуль Net::IP, то при попытке запуска службы snmptt.service мы будем получать ошибку. В этом случае в систему Debian 12 потребуется доустановить пакет, содержащий этот модуль:
# apt-get install libnet-ip-perl
В нашем же случае IPv6 не используется, поэтому можно просто выключить соответствующий параметр (ipv6_enable=0) в конфигурации /etc/snmp/snmptt.ini. После этого служба snmptt.service должна успешно запуститься.
Новый скрипт submit_snmp_trap для работы c Icinga API
Как уже было отмечено ранее, согласно правил, которые мы добавили в snmptt.conf, нормализованный трап будет передаваться скрипту submit_snmp_trap. Однако скрипт submit_snmp_trap, описанный ранее, теперь нам не подойдёт. Проблема в том, что используемый в прошлом варианте скрипта командный файл (/var/run/icinga2/cmd/icinga2.cmd) в качестве Command Transport в Icinga DB не поддерживается.
В качестве Command Transport в Icinga DB поддерживается только Icinga API, информацию о чём мы можем найти в документе "Icinga DB Web Migration". Поэтому нам придётся переделать ранее описанный скрипт submit_snmp_trap под использование Icinga API.
В написании нового скрипта нам может помочь пример отсылки результата Passive Check в Icinga через интерфейс Icinga API из документации.
Для начала создадим отдельного пользователя Icinga API:
# nano /etc/icinga2/conf.d/api-users.conf
Добавим в конец файла информацию о новом пользователе Icinga API с ограниченным набором прав (разрешаем ему только посылать process-check-result и только для службы с именем "SNMP Trap"):
...
object ApiUser "snmp-trap" {
password = "a4f9V87f27e87c"
permissions = [
{
permission = "actions/process-check-result"
filter = {{ service.name == "SNMP Trap" }}
}
]
}
При указании пароля пользователя не стоит увлекаться спец.символами, так как нужно помнить о том, что этот пароль будет передаваться в составе URL при отправке HTTP запросов к Icinga API.
Чтобы добавленный пользователь Icinga API заработал, перезапустим службу icinga2:
# systemctl restart icinga2.service
Создадим файл нового скрипта и сделаем его исполняемым:
# 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"
ICINGA_API_CREDS="--user snmp-trap:a4f9V87f27e87c"
ICINGA_API_URL="https://kom-mon01.holding.com:5665"
#HOST="$1"
HOST=`$echocmd $1 | tr '[:upper:]' '[:lower:]'`
SERVICE="$2"
RC="$3"
OUTPUT="$4"
data='{ "type": "Service", "filter": "host.name==\"'$HOST'\" && service.name==\"'$SERVICE'\"", "exit_status": '$RC', "plugin_output": "'$OUTPUT'" }'
curl $ICINGA_API_CREDS \
--noproxy '*' --insecure --silent --header 'Accept: application/json' --request POST \
"$ICINGA_API_URL/v1/actions/process-check-result" \
--data "$data"
exit 0
Данный скрипт будет преобразовывать полученный от snmptt нормализованный трап, форматировать данные в JSON формат и передавать эти данные HTTP POST запросом на URL адрес Icinga API.
Скрипт использует утилиту curl, поэтому её придётся доустановить:
# apt-get install curl
Чтобы проверить работу скрипта, выполним его вызов примерно так, как это будет выполнять snmptt:
# /usr/lib/nagios/plugins/submit_snmp_trap kom-up002.holding.com "SNMP Trap" 1 "This is test trap..."
В случае успеха мы должны получить от Icinga API ответ типа:
{"results":[{"code":200,"status":"Successfully processed check result for object 'kom-up002.holding.com!SNMP Trap'."}]}
Если в процессе такой проверки возникли проблемы, то стоит понять отрабатывает ли вообще сама по себе используемая в нём команда отправки HTTP POST запроса через curl.
Для этого можно выполнить тестовый вызов такой команды примерно следующим образом:
# curl --noproxy "*" --user 'snmp-trap:a4f9V87f27e87c' --insecure --header 'Accept: application/json' --request POST "https://kom-mon01.holding.com:5665/v1/actions/process-check-result" --data '{ "type": "Service", "filter": "host.name==\"kom-up002.holding.com\" && service.name==\"SNMP Trap\"", "exit_status": '1', "plugin_output": "Test trap..." }'
В случае успеха мы должны получить от Icinga API ответ типа:
{"results":[{"code":200,"status":"Successfully processed check result for object 'kom-up002.holding.com!SNMP Trap'."}]}
Если же запрос не даёт такого результата и мы, например, получаем сообщение "curl: (52) Empty reply from server)", то нужно диагностировать подключение к API из curl, используя советы из документа
"REST API".
Диагностика и устранение проблем
Для решения проблем, возникающих при настройке SNMP Trap в Icinga, можно воспользоваться советами из секции "Поиск и устранение проблем" ранее упомянутой статьи "Настройка мониторинга сетевых устройств в Icinga Director (на примере контроллеров управления ИБП). Получение SNMP Trap".
Совет применительно просмотра лог-файла /var/log/syslog в Debian 12 работать не будет, так как в этой ОС по умолчанию используется journald. То есть для просмотра событий связанных с snmptrapd в системном логе используем команду вида:
# journalctl --system -f | grep snmptrapd
Например, в нашем случае при изучении этого лога было обнаружено множество сообщений следующего вида:
May 10 13:26:11 KOM-MON01 snmptrapd[377973]: Could not write to file /var/spool/snmptt/#snmptt-trap-1715336771271629! Trap will be lost!
May 10 13:26:11 KOM-MON01 snmptrapd[377975]: Could not write to file /var/spool/snmptt/#snmptt-trap-1715336771320304! Trap will be lost!
May 10 13:26:17 KOM-MON01 snmptrapd[377996]: Could not write to file /var/spool/snmptt/#snmptt-trap-1715336777637668! Trap will be lost!
Это говорит о том, что у пользователя Debian-snmp, от имени которого работает служба snmptrapd.service в Debian 12 нет права на запись трапов в каталог /var/spool/snmptt.
Проверим то, как выставлены права в Debian 12 по умолчанию:
# ls -la /var/spool/snmptt/
total 8
drwxr-xr-x 2 snmptt snmptt 4096 Nov 6 2022 .
drwxr-xr-x 6 root root 4096 May 9 14:16 ..
Как видим, право на запись в каталог есть только у пользователя snmptt. Добавим право на запись для группы snmptt:
# chmod -R g+w /var/spool/snmptt/
При этом пользователь Debian-snmp в Debian 12 по умолчанию не имеет отношения к группе snmptt, поэтому нам потребуется добавить его в эту группу:
# usermod -a -G snmptt Debian-snmp
# id Debian-snmp
uid=108(Debian-snmp) gid=115(Debian-snmp) groups=115(Debian-snmp),116(snmptt)
После этого ошибки записи в /var/spool/snmptt из системного лога должны исчезнуть, а трапы должны начать доходить от службы snmptrapd до Icinga.
RSS - Записи
Добавить комментарий