После того, как в сети появились узлы, опрашиваемые по SNMPv3, отсутствие срабатываний этого триггера перестало быть надёжным критерием доступности узла по SNMP. Все элементы данных SNMPv3 на узле могут быть в неподдерживаемом состоянии, однако Zabbix при этом считает узел доступным по SNMP и триггер не срабатывает. Как выяснилось, Zabbix не считает проблемой, если узел ответил ошибкой аутентификации. Формально устройство действительно отвечает по протоколу SNMP, но фактически данные с него не снимаются.
Я решил испрвить эту ситуацию, в очередной раз внеся правку в исходный текст Zabbix. К счастью, сделать это оказалось совсем не сложно. Интересующий нас фрагмент кода находится в файле src/zabbix_server/poller/checks_snmp.c в функции zbx_get_snmp_response_error. Удалим специальную обработку ошибок аутентификации SNMPv3, интерпретируя эти ошибки как недоступность элемента данных:
Index: zabbix-3.4.12-1+buster/src/zabbix_server/poller/checks_snmp.c =================================================================== --- zabbix-3.4.12-1+buster.orig/src/zabbix_server/poller/checks_snmp.c +++ zabbix-3.4.12-1+buster/src/zabbix_server/poller/checks_snmp.c @@ -391,17 +391,7 @@ static int zbx_get_snmp_response_error(c { zbx_snprintf(error, max_error_len, "Cannot connect to \"%s:%hu\": %s.", interface->addr, interface->port, snmp_api_errstring(ss->s_snmp_errno)); - - switch (ss->s_snmp_errno) - { - case SNMPERR_UNKNOWN_USER_NAME: - case SNMPERR_UNSUPPORTED_SEC_LEVEL: - case SNMPERR_AUTHENTICATION_FAILURE: - ret = NOTSUPPORTED; - break; - default: - ret = NETWORK_ERROR; - } + ret = NETWORK_ERROR; } else if (STAT_TIMEOUT == status) {Эту тривиальную заплатку можно взять по ссылке zabbix3_4_12_snmpv3_auth_errors.patch.
Комментариев нет:
Отправить комментарий