Если требуется получить с коммутатора сразу несколько "веток" с данными, то на ум часто приходит способ последовательного опроса. К примеру, собирая счетчики ошибок с портов, при первом опросе получаем счетчики CRC, затем спрашиваем Undersize, потом Jabber и т.п. Минус такого подхода проявится тогда, когда потребуется опросить несколько сотен или тысяч устройств. Суммарное время опроса в этом случае будет вполне ощутимым.
Однако, используя python и библиотеку netsnmp, есть возможность одновременно опрашивать сразу несколько веток. При этом как запросы, так и ответы от коммутатора, размещаются внутри одного пакета. Необходимым условием такого вопроса является одинаковая длина ветки, т.е. количество возвращаемых значений при обходе (walk) OID1 должно быть равно аналогичному числу для OID2. В противном случае опрос прекратится как будет достигнут конец самой короткой ветки OID.
Разберем ситуацию на примере ifInOctets и ifOutOctets - это 32-битные счетчики RX и TX, соответственно. Очевидно, что число значений в этих ветках одинаково (не может быть интерфейс с RX, но без TX или наоборот). Для этого воспользуемся скриптом. Python и net-snmp должны быть установлены в системе.
Мы увидим примерно следующее:
index: .1.3.6.1.2.1.2.2.1.10, vid: 1, type: COUNTER, value: 1786930814
index: .1.3.6.1.2.1.2.2.1.16, vid: 1, type: COUNTER, value: 2988734099
index: .1.3.6.1.2.1.2.2.1.10, vid: 2, type: COUNTER, value: 0
index: .1.3.6.1.2.1.2.2.1.16, vid: 2, type: COUNTER, value: 0
index: .1.3.6.1.2.1.2.2.1.10, vid: 3, type: COUNTER, value: 393989022
index: .1.3.6.1.2.1.2.2.1.16, vid: 3, type: COUNTER, value: 3964530413
index: .1.3.6.1.2.1.2.2.1.10, vid: 4, type: COUNTER, value: 0
index: .1.3.6.1.2.1.2.2.1.16, vid: 4, type: COUNTER, value: 0
index: .1.3.6.1.2.1.2.2.1.10, vid: 5, type: COUNTER, value: 2308865632
index: .1.3.6.1.2.1.2.2.1.16, vid: 5, type: COUNTER, value: 23052390
index: .1.3.6.1.2.1.2.2.1.10, vid: 6, type: COUNTER, value: 0
index: .1.3.6.1.2.1.2.2.1.16, vid: 6, type: COUNTER, value: 0
index: .1.3.6.1.2.1.2.2.1.10, vid: 7, type: COUNTER, value: 0
index: .1.3.6.1.2.1.2.2.1.16, vid: 7, type: COUNTER, value: 0
...
Если при этом мы снимали дамп, то, заглянув в него, можем увидеть такую картину:
Как видно, в одном snmp-пакете размещен один get-next-request на два параметра .1.3.6.1.2.1.2.2.1.10 и .1.3.6.1.2.1.2.2.1.16. Аналогичным образом возвращается и ответ - результаты приходят в одном пакете. Таким образом, общее число передаваемых по сети пакетов меньше, меньше и суммарное время их ожидания. Надежность передачи при этом возрастает, т.к. чем меньше пакетов, тем меньше общее число потерь. При регулярном массовом опросе сети это очень важно.
Однако, используя python и библиотеку netsnmp, есть возможность одновременно опрашивать сразу несколько веток. При этом как запросы, так и ответы от коммутатора, размещаются внутри одного пакета. Необходимым условием такого вопроса является одинаковая длина ветки, т.е. количество возвращаемых значений при обходе (walk) OID1 должно быть равно аналогичному числу для OID2. В противном случае опрос прекратится как будет достигнут конец самой короткой ветки OID.
Разберем ситуацию на примере ifInOctets и ifOutOctets - это 32-битные счетчики RX и TX, соответственно. Очевидно, что число значений в этих ветках одинаково (не может быть интерфейс с RX, но без TX или наоборот). Для этого воспользуемся скриптом. Python и net-snmp должны быть установлены в системе.
Мы увидим примерно следующее:
index: .1.3.6.1.2.1.2.2.1.10, vid: 1, type: COUNTER, value: 1786930814
index: .1.3.6.1.2.1.2.2.1.16, vid: 1, type: COUNTER, value: 2988734099
index: .1.3.6.1.2.1.2.2.1.10, vid: 2, type: COUNTER, value: 0
index: .1.3.6.1.2.1.2.2.1.16, vid: 2, type: COUNTER, value: 0
index: .1.3.6.1.2.1.2.2.1.10, vid: 3, type: COUNTER, value: 393989022
index: .1.3.6.1.2.1.2.2.1.16, vid: 3, type: COUNTER, value: 3964530413
index: .1.3.6.1.2.1.2.2.1.10, vid: 4, type: COUNTER, value: 0
index: .1.3.6.1.2.1.2.2.1.16, vid: 4, type: COUNTER, value: 0
index: .1.3.6.1.2.1.2.2.1.10, vid: 5, type: COUNTER, value: 2308865632
index: .1.3.6.1.2.1.2.2.1.16, vid: 5, type: COUNTER, value: 23052390
index: .1.3.6.1.2.1.2.2.1.10, vid: 6, type: COUNTER, value: 0
index: .1.3.6.1.2.1.2.2.1.16, vid: 6, type: COUNTER, value: 0
index: .1.3.6.1.2.1.2.2.1.10, vid: 7, type: COUNTER, value: 0
index: .1.3.6.1.2.1.2.2.1.16, vid: 7, type: COUNTER, value: 0
...
Если при этом мы снимали дамп, то, заглянув в него, можем увидеть такую картину:
Как видно, в одном snmp-пакете размещен один get-next-request на два параметра .1.3.6.1.2.1.2.2.1.10 и .1.3.6.1.2.1.2.2.1.16. Аналогичным образом возвращается и ответ - результаты приходят в одном пакете. Таким образом, общее число передаваемых по сети пакетов меньше, меньше и суммарное время их ожидания. Надежность передачи при этом возрастает, т.к. чем меньше пакетов, тем меньше общее число потерь. При регулярном массовом опросе сети это очень важно.
Комментариев нет:
Отправить комментарий