При настройке некоторых хостов в Check_MK для мониторинга только по протоколу SNMP я обнаружил несколько хостов, где snmpbulkwalk кажется, что "зависает", а затем истекает время ожидания при обработке определенного OID.
например:
OMD[prod]:~$ snmpbulkwalk -v 2c -c public compute01.domain.com .1.3.6.1.4.1.2021
UCD-SNMP-MIB::memIndex.0 = INTEGER: 0
UCD-SNMP-MIB::memErrorName.0 = STRING: swap
UCD-SNMP-MIB::memTotalSwap.0 = INTEGER: 88109052 kB
UCD-SNMP-MIB::memAvailSwap.0 = INTEGER: 88109052 kB
UCD-SNMP-MIB::memTotalReal.0 = INTEGER: 131860964 kB
UCD-SNMP-MIB::memAvailReal.0 = INTEGER: 94429952 kB
UCD-SNMP-MIB::memTotalFree.0 = INTEGER: 182539004 kB
UCD-SNMP-MIB::memMinimumSwap.0 = INTEGER: 16000 kB
UCD-SNMP-MIB::memShared.0 = INTEGER: 0 kB
UCD-SNMP-MIB::memBuffer.0 = INTEGER: 188772 kB
UCD-SNMP-MIB::memCached.0 = INTEGER: 6685180 kB
UCD-SNMP-MIB::memSwapError.0 = INTEGER: noError(0)
UCD-SNMP-MIB::memSwapErrorMsg.0 = STRING:
UCD-SNMP-MIB::laIndex.1 = INTEGER: 1
UCD-SNMP-MIB::laIndex.2 = INTEGER: 2
UCD-SNMP-MIB::laIndex.3 = INTEGER: 3
UCD-SNMP-MIB::laNames.1 = STRING: Load-1
UCD-SNMP-MIB::laNames.2 = STRING: Load-5
UCD-SNMP-MIB::laNames.3 = STRING: Load-15
UCD-SNMP-MIB::laLoad.1 = STRING: 3.91
Timeout: No Response from compute01.domain.com
snmpwalk, с другой стороны, отлично работает:
OMD[prod]:~$ snmpwalk -v 2c -c public compute01.domain.com .1.3.6.1.4.1.2021
UCD-SNMP-MIB::memIndex.0 = INTEGER: 0
UCD-SNMP-MIB::memErrorName.0 = STRING: swap
UCD-SNMP-MIB::memTotalSwap.0 = INTEGER: 88109052 kB
UCD-SNMP-MIB::memAvailSwap.0 = INTEGER: 88109052 kB
UCD-SNMP-MIB::memTotalReal.0 = INTEGER: 131860964 kB
UCD-SNMP-MIB::memAvailReal.0 = INTEGER: 94424732 kB
UCD-SNMP-MIB::memTotalFree.0 = INTEGER: 182533784 kB
UCD-SNMP-MIB::memMinimumSwap.0 = INTEGER: 16000 kB
UCD-SNMP-MIB::memShared.0 = INTEGER: 0 kB
UCD-SNMP-MIB::memBuffer.0 = INTEGER: 188772 kB
UCD-SNMP-MIB::memCached.0 = INTEGER: 6685188 kB
UCD-SNMP-MIB::memSwapError.0 = INTEGER: noError(0)
UCD-SNMP-MIB::memSwapErrorMsg.0 = STRING:
UCD-SNMP-MIB::laIndex.1 = INTEGER: 1
UCD-SNMP-MIB::laIndex.2 = INTEGER: 2
UCD-SNMP-MIB::laIndex.3 = INTEGER: 3
UCD-SNMP-MIB::laNames.1 = STRING: Load-1
UCD-SNMP-MIB::laNames.2 = STRING: Load-5
UCD-SNMP-MIB::laNames.3 = STRING: Load-15
UCD-SNMP-MIB::laLoad.1 = STRING: 3.97
UCD-SNMP-MIB::laLoad.2 = STRING: 4.51
UCD-SNMP-MIB::laLoad.3 = STRING: 4.35
UCD-SNMP-MIB::laConfig.1 = STRING: 12.00
UCD-SNMP-MIB::laConfig.2 = STRING: 12.00
UCD-SNMP-MIB::laConfig.3 = STRING: 12.00
UCD-SNMP-MIB::laLoadInt.1 = INTEGER: 397
UCD-SNMP-MIB::laLoadInt.2 = INTEGER: 451
UCD-SNMP-MIB::laLoadInt.3 = INTEGER: 434
UCD-SNMP-MIB::laLoadFloat.1 = Opaque: Float: 3.970000
UCD-SNMP-MIB::laLoadFloat.2 = Opaque: Float: 4.510000
UCD-SNMP-MIB::laLoadFloat.3 = Opaque: Float: 4.350000
...
Это происходит на 3 разных серверах с идентичными конфигурациями, и я не могу найти в журналах или конфигурации snmpd ничего, что могло бы указывать на какую-либо проблему.
Есть идеи, в чем может быть проблема, или что еще я могу посмотреть?
Snmpbulkwalk инициирует внутренние повторы сервера для обхода Mib-дерева. Сервер не отвечает, пока он не получит максимальное количество повторений переменных или не будет достигнут конец MIB-дерева. Получение некоторых переменных может потребовать драгоценного времени.
Важное примечание: snmpwalk точно проходит через запрошенное поддерево, но snmpbulkwalk может получить дополнительные переменные (после достижения конца поддерева) из-за поведения, описанного выше. Таким образом, он может наткнуться на эти дополнительные переменные, которые никогда не будут затронуты с помощью snmpwalk.
Попробуйте уменьшить параметр, соответствующий параметру "max-repetitions" и / или увеличить параметр времени ожидания для snmpbulkwalk.
У меня такая же проблема с snmpbulkwalk при запросе столбцов таблиц для некоторого сетевого оборудования. Уменьшение max-repetitions помогает.