Почему запрос snmpwalk будет выполнен с использованием тайм-аута gosnmp через 29 секунд?
Я использую gosnmp для просмотра таблиц интерфейса snmp, 1.3.6.1.2.1.2.2.1 и 1.3.6.1.2.1.31.1.1.1. Существует большая разница во времени, необходимом для выполнения этой задачи, я предполагаю, что это зависит от нагрузки на компьютеры и перегрузки сети. В тестах с устройствами V1 я получаю тайм-аут через 29 секунд. Это потому, что один из запросов getnext, составляющих команду snmpwalk, превышает время ожидания? Есть ли способ отличить вызов занятого устройства и один из многих сбоев запроса getnext (требуется более длительный тайм-аут) от вызова неработающего устройства (требуется более короткий тайм-аут). После тайм-аута в середине snmpwalk повторяется ли только последний getnext? Я предполагаю, что snmpwalk gosnmp является оболочкой для стандартного snmpwalk. Поля Retries и Timeout просто сопоставляются с параметрами командной строки -r и -t? Это журналы трех последовательных тестов одного и того же устройства.
{"Истекшее время": 28596.288132, "время": "2021-10-11T18: 24: 14-04: 00", "сообщение": "testSnmpWalk успешно"}
{"error": "request timeout (after 0 retries)", "Elapsed Time": 29571.202639, "time": "2021-10-11T18: 43: 37-04: 00", "message": "testSnmpWalk failed" }
{"Истекшее время": 14645.645597, "время": "2021-10-11T18:44:40-04: 00", "сообщение": "testSnmpWalk выполнено успешно"}
2 ответа
Мое решение состояло в том, чтобы использовать exec.Cmd для вызова net-SNMP. Пришлось немного поработать, чтобы передать и проанализировать результаты, но я доволен производительностью.
Это может быть связано с реализацией производителя.Вы можете отключить встроенный SNMP в качестве решения. Есть еще много способов решить