Snmpwalk случайным образом возвращает меньше переменных (оканчивающихся на SNMPv2-MIB :: snmpSetSerialNo.0) - PullRequest
Новая
       71

Snmpwalk случайным образом возвращает меньше переменных (оканчивающихся на SNMPv2-MIB :: snmpSetSerialNo.0)

0 голосов
/ 18 марта 2019

Я создаю новый MiB, который включает в себя объект groupProcessInfo, задачей которого является возвращение статуса процессов приложения X, где X заменяется именем приложения.

Каждый процесс в MiB определяется следующим образом: 

appXState OBJECT-TYPE
        SYNTAX          OCTET STRING (SIZE(0..255))
        MAX-ACCESS      read-only
        STATUS          current
        DESCRIPTION     "X service"
        ::= { groupProcessInfo 10 1 }
appXMemUsage OBJECT-TYPE
        SYNTAX          Integer32
        MAX-ACCESS      read-only
        STATUS          current
        DESCRIPTION     "X service"
        ::= { groupProcessInfo 10 2 }

и присвоено объекту: 

groupProcessInfo OBJECT IDENTIFIER ::= { myMIB 1 }

Существует основной сценарий bash, который определяет состояние процессов, использующих утилиты или другие сценарии bash, эти сценарии занимают различное количество времени, поэтому при использовании snmpwalk или snmpget мне нужно указать большее время ожидания (-t).

Основной скрипт bash передается в snmpd.conf с помощью команды: 

pass .1.3.6.1.4.1.x.y.3.10 /etc/snmp/scripts/process.sh

Когда я пытаюсь получить значения appXState или appXMemUsage, используя snmpget или snmpgetnext, он работает, и всегда возвращается правильное значение, но snmpwalk не работает должным образом.

Когда я запускаю эту команду: 

$ snmpwalk -Cp -Ct -v 2c -t 20 -m +MY-MIB -c testing localhost groupProcessInfo

Иногда он возвращает меньше переменных, время обхода которых значительно меньше.

Примечания:

1. Режим трассировки Snmpwalk

Когда это происходит в режиме трассировки (-D все), snmpagent возвращается в качестве последней переменной SNMPv2-MIB :: snmpSetSerialNo.0 , которой нет в дереве OID. Это не происходит в прогонах, когда все переменные из дерева возвращаются правильно.

Вывод режима трассировки: 

trace: snmp_comstr_parse(): snmp_auth.c, 130:
dumph_recv:   SNMP version
dumpx_recv:    02 01 01
dumpv_recv:      Integer:       1 (0x01)
trace: snmp_comstr_parse(): snmp_auth.c, 142:
dumph_recv:   community string
dumpx_recv:    04 07 74 65 73 74 69 6E 67
dumpv_recv:      String:        testing
trace: _snmp_parse(): snmp_api.c, 4142:
dumph_recv:   PDU
trace: snmp_pdu_parse(): snmp_api.c, 4362:
dumpv_recv:     Command RESPONSE
trace: snmp_pdu_parse(): snmp_api.c, 4447:
dumph_recv:     request_id
dumpx_recv:      02 04 0E 5E DD 9C
dumpv_recv:        Integer:     241098140 (0xE5EDD9C)
trace: snmp_pdu_parse(): snmp_api.c, 4458:
dumph_recv:     error status
dumpx_recv:      02 01 00
dumpv_recv:        Integer:     0 (0x00)
trace: snmp_pdu_parse(): snmp_api.c, 4469:
dumph_recv:     error index
dumpx_recv:      02 01 00
dumpv_recv:        Integer:     0 (0x00)
trace: snmp_pdu_parse(): snmp_api.c, 4487:
dumph_recv:     VarBindList
trace: snmp_pdu_parse(): snmp_api.c, 4503:
dumph_recv:       VarBind
trace: snmp_parse_var_op(): snmp.c, 164:
dumph_recv:         Name
dumpx_recv:          06 0A 2B 06 01 06 03 01 01 06 01 00
dumpv_recv:            ObjID: SNMPv2-MIB::snmpSetSerialNo.0
trace: snmp_pdu_parse(): snmp_api.c, 4512:
dumph_recv:         Value
dumpx_recv:          02 04 12 55 CB EF
dumpv_recv:            Integer: 307612655 (0x1255CBEF)
trace: _sess_process_packet(): snmp_api.c, 5244:
sess_process_packet: received message id#0 reqid#241098140 len 50
trace: snmp_synch_input(): snmp_client.c, 183:
snmp_synch: Response (ReqID: 241098140 - Cmd 162)
Variables found: 11
Total traversal time = 7.302387 seconds

2. strace snmpwalk

Когда вышеприведенная команда запускается с использованием утилиты strace, когда возвращается меньше переменных, она действует так, как будто все переменные были возвращены и скрипт завершился без ошибок. 

exit_group(0)                           = ?
+++ exited with 0 +++

Спасибо за ваши подсказки.

1 Ответ

0 голосов
/ 01 апреля 2019

Мне удалось решить проблему, используя только одно общедоступное сообщество по умолчанию, одного пользователя и одну группу. Группа должна иметь доступ только к одному представлению с множественными определениями поддеревьев OID: 

com2sec notConfigUser    default          public

Сообщество определено только в строке com2sec, но больше нигде. 

view    all           included   .1.3.6.1.4.1.x.y
view    all           included   .1.3.6.1.4.1.2021
view    all           included   .1                         80
view    systemview    included   .1.3.6.1.2.1.1
view    systemview    included   .1.3.6.1.2.1.25.1.1
view    systemview    included   .1.3.6.1.4.1

Определено одно представление для нескольких поддеревьев, но не больше представлений, чем «все» и «представление системы». 

access  notConfigGroup ""      any       noauth    exact  all none none

notConfigGroup имеет доступ к представлению «все».

...