操作系统：CentOS版本5.7（最终）Net-SNMP：net-snmp-5.3.2.2-14.el5_7.1（来自RPM）
我的NMS定期通知我这台机器上的SNMP已经closures了。 该服务在10到30分钟之间恢复。 我的NMS还ping和检查SSH，这些服务在SNMP中断期间不受影响。
SNMPD日志文件显示它正在工作，显然正在接收数据包（来自127.0.0.1的本地代理或来自我的NMS的172.16.37.37），但试图在本地snmpwalk或从NMS系统进行snmpwalk失败并超时。
我有7台运行CentOS 5.7和RHEL 5.7的混合服务器，这些特定版本的Net-SNMP是从RPM安装的 – 除了这个之外，他们都没有这个问题。 5台机器（包括NMS系统和这个问题服务器）使用一台交换机连接在同一个机架上。
重新启动SNMPD并不能解决问题 – 最终会自行清除。 任何build议，我可以开始诊断问题？ 这是一个封闭的子网，所以不使用IPTables。 SNMPDconfiguration如下：
# Following entries were added by HP Insight Management Agents at # Tue May 15 10:58:17 CLT 2012 dlmod cmaX /usr/lib64/libcmaX64.so rwcommunity public 127.0.0.1 rocommunity public 127.0.0.1 rwcommunity 3adRabRu 172.16.37.37 rocommunity 3adRabRu 172.16.37.37 rwcommunity 3adRabRu 172.16.37.36 rocommunity 3adRabRu 172.16.37.36 trapcommunity callmetraps trapsink 172.16.37.37 callmetraps trapsink 172.16.37.36 callmetraps syscontact Lukasz Piwowarek syslocation Santiago, Chile # ---------------------- END -------------------- agentAddress udp:161 com2sec rwlocal default public com2sec rolocal default public com2sec subnet default 3adRabRu group rwv2c v2c rwlocal group rov2c v2c rolocal group rov2c v2c subnet view all included .1 access rwv2c "" any noauth exact all all none access rov2c "" any noauth exact all none none 这一个有几个问题需要解决。
看看您的configuration，我将OpenNMS视为监控解决scheme，HP ProLiant服务器硬件，可能的软件包版本和驱动程序问题，以及您可能对snmpd选项进行的一些调整。
你在最新版本的OpenNMS？ 当前修订版本是1.10.3您正在轮询NMS系统的机器还是不相关的？ 这是一个旧版本的OpenNMS的问题，还是这是一个新的安装？
我还会看到在您的snmpd.confconfiguration的第一行中加载的HP ProLiantpipe理代理模块。 这为ProLiant支持工具包和HP健康代理提供支持。 这是您正在监控的唯一一台惠普服务器吗？ 要testingHP snmpconfiguration，您可以通过https：//server.ip：2381访问System Management Homepage。 系统传感器（温度，存储，ILO）是否正确显示？ 如果他们不这样做，那么您的SNMP设置存在问题。
在OpenNMS方面，轮询器提供了令人难以置信的灵活的日志logging选项。 我们可以帮助您获得所需的信息，但是如果它只影响一个节点，我不认为这是一个普通的OpenNMS问题。 你可以从数据库中删除节点，并重新发现它来testing这个理论。
对于有问题的主机，您可能需要编辑/etc/sysconfig/snmpd.options以减less日志冗余 ，以防出现问题。
我的猜测是这是OpenNMS轮询/数据库问题，或者是HP代理和snmp在单个问题系统上的交互。
您是否尝试过增加SNMP超时并在NMS上重试？ 可能是因为你的服务器有时候速度不够快，或者你的networking丢失了数据包。
而且，正如@rnxrx已经指出的，你需要查找端口161来查看snmpd是否在监听。
我find了原因，但没有解决办法。 看来MySQL正在使整个系统无响应。 它如何pipe理影响从SNMP到SSH的所有内容，以及整个系统的响应能力（即时响应需要30秒以上的命令）已经超出了我的想象。 这是一个96GB内存的双CPU机器，用于4小时的数据相关性极强的数据处理，但是在我们运行我们的程序（在MySQL中有数百万个插入程序）之后，整个系统即使在闲置时也会爬行。 重新启动MySQL将立即清除问题。