SNMP ловушки не регистрируются

Вопрос или проблема

(Извините, я разместил оригинал не в том форуме)

Я занимаюсь настройкой Zabbix на Alma 9 и столкнулся с странной проблемой с SNMP ловушками. У нас есть SIP-коммутатор с включенным SNMP, который указывает на сервер, но по какой-то причине snmptrapd не обрабатывает входящие ловушки.

Zabbix установлен и работает. snmp и ловушка работают.

[root@dev:~]$ ps ax | grep snmp
   1472 ?        S      0:00 /usr/sbin/zabbix_server: snmp trapper [processed data in 0.000060 sec, idle 1 sec]
   1527 ?        Sl     0:00 /usr/sbin/zabbix_server: snmp poller #1 [got 0 values, queued 0 in 5 sec, awaiting 0]
   2174 ?        Ss     0:00 /usr/sbin/snmptrapd -Lsd -f
   2585 pts/1    S+     0:00 grep --color=auto snmp

выполнение snmptrapwalk работает

snmptrap -v 2c -c public 10.5.5.122 '' SNMPv2-MIB::snmpMIB IF-MIB::linkDown s eth0

2025-01-10T16:51:09+0000 ZBXTRAP 10.5.5.122
PDU INFO:
  receivedfrom                   UDP: [10.5.5.122]:47786->[10.5.5.122]:162
  version                        1
  transactionid                  2
  requestid                      1130383097
  errorstatus                    0
  messageid                      0
  notificationtype               TRAP
  errorindex                     0
  community                      public
VARBINDS:
  DISMAN-EVENT-MIB::sysUpTimeInstance type=67 value=Timeticks: (337607) 0:56:16.07
  SNMPv2-MIB::snmpTrapOID.0      type=6  value=OID: SNMPv2-MIB::snmpMIB
  IF-MIB::linkDown               type=4  value=STRING: "eth0"

На нашем SIP-коммутаторе, если я перезапущу один из модулей, это вызовет SNMP ловушку. Используя TCP dump, я вижу, что она отправляется на сервер Zabbix.

tcpdump -i ens18 -T snmp -n dst portrange 161-162

17:14:35.573815 IP 10.7.7.113.33830 > 10.5.5.122.snmptrap: V2Trap(174) .1.3.6.1.2.1.1.3.0=1877147173 .1.3.6.1.6.3.1.1.4.1.0=.1.3.6.1.4.1.17236.2.1 .1.3.6.1.4.1.17236.1.1="КРИТИЧНО : 003 010008 000007 10/01/2025 17:14:35 : Потеряна связь с 0XA070771 (SIP Switch 3 - BT)"
17:14:36.427854 IP 10.7.7.113.43173 > 10.5.5.122.snmptrap: V2Trap(152) .1.3.6.1.2.1.1.3.0=1877147258 .1.3.6.1.6.3.1.1.4.1.0=.1.3.6.1.4.1.17236.2.1 .1.3.6.1.4.1.17236.1.1="КРИТИЧНО : 003 010000 000000 10/01/2025 17:14:36 : Сервер приложений остановлен"
17:14:37.434487 IP 10.7.7.113.54710 > 10.5.5.122.snmptrap: V2Trap(222) .1.3.6.1.2.1.1.3.0=1877147359 .1.3.6.1.6.3.1.1.4.1.0=.1.3.6.1.4.1.17236.2.1 .1.3.6.1.4.1.17236.1.1="МАЖОРНО : 007 023009 000000 10/01/2025 17:14:37 : Shout.Ocp.OcpLink (127.0.0.1:10012) не удалась. Причина: Неожиданная ошибка в потоке Heartbeat."
17:14:41.627673 IP 10.7.7.113.34462 > 10.5.5.122.snmptrap: V2Trap(230) .1.3.6.1.2.1.1.3.0=1877147778 .1.3.6.1.6.3.1.1.4.1.0=.1.3.6.1.4.1.17236.2.1 .1.3.6.1.4.1.17236.1.1="МАЖОРНО : 007 023009 000000 10/01/2025 17:14:41 : Shout.Ocp.OcpLink (127.0.0.1:10012) не удалась. Причина: Невозможно читать за пределами потока."

Да, в логах ничего нет. Это то, что у меня написано в /etc/snmp/snmptrap.conf

#Zabbix 1 и 2
disableAuthorization yes
authCommunity execute public

#Получатель SNMP ловушек для Zabbix
perl do "/usr/bin/zabbix_trap_receiver.pl";

Я также попробовал использовать bash-скрипт, всё равно безуспешно. Selinux отключен, как и фаервол. Я не получаю никаких сообщений об ошибках, и в /var/log/messages ничего не указывает на какие-либо проблемы. Я несколько озадачен, так как, похоже, ничто не работает неправильно.

Ответ или решение

Настройка SNMP в Zabbix на Alma 9 может иногда вызывать затруднения, особенно когда SNMP Traps не фиксируются должным образом. Давайте рассмотрим потенциальные причины этой проблемы и способы их устранения.

Теория:

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

Когда SNMP Trap отправляется с устройства, snmptrapd на сервере должен его получить, обработать и передать Zabbix для дальнейшего анализа и логирования. Если вы видите ловушки в tcpdump, но они не обрабатываются snmptrapd, это значит, что цепочка обработки проблемы где-то прервана.

Примеры (анализ текущей конфигурации):

Конфигурация snmptrapd: Судя по вашему snmptrap.conf, вы отключили авторизацию и указали сообщество ‘public’. Также указана строка для вызова perl-скрипта Zabbix, что является правильным шагом для передачи данных в Zabbix, но если скрипт некорректно настроен или недоступен, это может быть причиной проблемы. Проверьте, существует ли файл /usr/bin/zabbix_trap_receiver.pl и доступен ли он для выполнения.
Блокировка скриптов: Поскольку SElinux и firewall отключены, маловероятно, что они блокируют скрипт. Однако проверьте доступность и работоспособность скрипта, например, запустив его вручную.
Логи и файл вывода: Проверьте файл конфигурации на наличие настроек, которые указывают на вывод логов snmptrapd. Если они отсутствуют, или если вывод перенаправляется в неподходящее место, то имеет смысл это исправить. Добавьте или проверьте строку в snmptrapd.conf, например: traphandle default /usr/bin/zabbix_trap_receiver.pl и authCommunity log,execute,net public.
Перезапуск служб: После изменения конфигурации всегда перезапускайте snmptrapd и Zabbix для обновления конфигурации.
Проверка прав доступа: Убедитесь, что скрипт zabbix_trap_receiver.pl имеет корректные разрешения на исполнение. Чекните права с помощью команды chmod +x /usr/bin/zabbix_trap_receiver.pl.

Применение (решение проблемы):

Проверка скрипта zabbix_trap_receiver.pl: Убедитесь, что скрипт настроен правильно. Проверьте его содержание, рабочие параметры и доступность. Возможно, потребуется его перенастройка или замена на другой более стабильный скрипт, например, bash-скрипт, который вы тоже пробовали использовать.
Включение детализированных логов: Настройте snmptrapd для более детального логирования, которое может оказать важную информацию о том, где может происходить сбой. В зависимости от вашего уровня доступа к системным журналам, добавление строк для более детального логирования может помочь раскрыть текущие проблемы.
Профилактическая проверка службы Zabbix: Убедитесь в том, что настройки Zabbix для обработки SNMP трепок корректны и сервис имеет необходимые права для их обработки.

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