0

我正在使用 gosnmp 遍历 snmp 接口表,1.3.6.1.2.1.2.2.1 和 1.3.6.1.2.1.31.1.1.1。完成此任务所需的时间有很大差异,我认为这取决于计算机上的负载和网络拥塞。在针对 V1 设备的测试中,我在 29 秒后超时。这是因为组成 snmpwalk 命令的 getnext 请求之一超过了超时时间吗?有没有办法区分调用繁忙的设备和许多 getnext 请求失败之一(想要更长的超时)和调用死设备(想要更短的超时)。在snmpwalk中间超时后,只有最后一个getnext重试了吗?我假设 gosnmp 的 snmpwalk 包装了标准的 snmpwalk。Retries 和 Timeout 字段是否仅映射到 -r 和 -t 命令行参数?这些是针对同一设备的三个连续测试的日志。

{"经过时间":28596.288132,"time":"2021-10-11T18:24:14-04:00","message":"testSnmpWalk 成功"}

{“错误”:“请求超时(重试 0 次后)”,“经过时间”:29571.202639,“时间”:“2021-10-11T18:43:37-04:00”,“消息”:“testSnmpWalk 失败” }

{"经过时间":14645.645597,"time":"2021-10-11T18:44:40-04:00","message":"testSnmpWalk 成功"}

4

2 回答 2

0

我的解决方案是使用 exec.Cmd 调用 net-SNMP。有一些工作来管道和解析结果,但我对性能感到满意。

于 2021-12-01T19:55:44.117 回答
-1

这可能是由于制造商实施。您可以关闭内联 SNMP 作为解决方案。还有很多方法可以解决

于 2021-10-12T16:26:49.040 回答