简单网络管理协议 (SNMP) 自 1988 年推出以来，一直是监控网络环境不可或缺的一部分。它已成为网络监控领域的事实标准。许多制造商都支持该协议，并在其网络设备上实现了 SNMP 代理。这些代理允许监控解决方案查询各种数据，例如带宽、CPU 负载、网络接口等，而无需在网络设备上安装额外的代理。 

尤其是在网络设备数量不断增加的情况下，SNMP 这种简单且成熟的方法听起来对于快速将组件纳入监控非常有帮助。不幸的是，SNMP 存在一些缺陷。本文的第一部分将解释 SNMP 的工作原理，而第二部分将更深入地探讨 SNMP 的问题以及如何处理这些问题。

该协议提供了两种从设备检索数据的方法：轮询和陷阱。通过 SNMP 轮询，监控解决方案以用户指定的时间间隔从 SNMP 代理查询数据。这种主动轮询用于基于状态的监控，通常是推荐的方法。然而，SNMP 轮询的缺点是，如果事件发生在两次查询之间，例如网络接口状态的短暂变化，管理员不会注意到。

SNMP 轮询的替代方案是基于事件的变体，称为 SNMP 陷阱。如果在受监控的设备上发生特定事件，它会向监控实例发送错误消息。SNMP 陷阱的缺点之一是通过 UDP 传输的数据包可能会丢失。由于 UDP 不确认网络数据包的接收，因此如果包含陷阱数据的数据包被丢弃，管理员甚至不知道是否发送了警报。因此，具有讽刺意味的是，网络上的问题阻止了对网络设备另一个问题的检测。

SNMP 陷阱的另一个缺点可能是触发消息的泛滥。例如，假设核心交换机不再可用。在这种情况下，在大型网络环境中，可能会导致数千台交换机发送陷阱。即使它没有上游过滤机制，陷阱接收器也可能在如此大量的错误消息负载下崩溃。然后在紧急情况下监控不可用。此外，如果陷阱接收器的 IP 地址发生更改，管理员必须重新配置网络中的所有组件。

三种协议变体

在其存在 30 多年的时间里，已经出现了该标准的三个变体。SNMPv1 仅用于旧设备或仅支持 SNMPv2c 的设备，或者根本不支持。与 v1 相比，SNMPv2c 包含批量查询，例如，允许同时检索多个值和 64 位计数器，这对于监控带宽超过 1 GBit/s 的交换机端口是必不可少的。版本名称中的“c”代表 community（团体），它在 SNMP 中扮演密码的角色。v2c 是 SNMP 最常用的协议变体。

由于 v1 和 v2c 中的网络通信（包括团体）都是明文的，因此 SNMPv3 除了加密之外，还引入了强大的身份验证。v3 包括三个安全级别：NoAuthNoPriv（无身份验证，无隐私）、AuthNoPriv（身份验证，无隐私）和 AuthPriv（身份验证，隐私）。然而，v3 下的加密需要在受监控的设备上消耗更多的处理能力，而身份验证则需要管理员进行额外的配置工作。根据具体情况，使用 SNMPv2c 进行监控或将监控流量外包给单独的 VLAN 可能更有意义。

设备上的不良实现

使用 SNMP 进行监控依赖于受监控设备制造商对该协议的实现。不幸的是，这种实现通常很差，有时甚至与协议规范相矛盾，并且经常包含编程和安全错误。因此，通过 SNMP 查询的数据可能不一致或错误，批量查询可能会崩溃或耗时过长而导致超时。

您一次又一次地发现制造商给出不正确的单位信息并且不记录的情况。例如，他们使用华氏度而不是摄氏度，或者不提及传输的值对应于 1/10 °C。另一个例子可以在传感器中找到，当 0 °C 的输出值可以是环境传感器的准确温度规格时。但是，它也可能意味着温度传感器有缺陷或无法访问。如果文档中缺少此信息，则会导致误解和误报。因此，必须始终在正确的上下文中查看数据。

除了已经提到的安全性和实施困难之外，SNMP 很快就会达到其性能限制。如果管理员想要设置接近实时的监控，他们必须设置更高的 SNMP 轮询间隔；通常，这些间隔大约为每分钟一次轮询。查询之间的时间窗口越短，网络中组件的负载增加就越显着。

在某些情况下，至少如果由于实现不良或其他原因导致设备上的轮询使监控变得不可能，那么在紧急情况下不轮询特定值也可能是有意义的。然而，这又与您应该监控网络环境中所有对象的方法相矛盾。

当您使用 SNMP 进行监控时，使用能够处理此类缺陷的监控软件是有意义的。该解决方案应自行为检测到的设备启动有意义的数据查询，并自动纠正错误的值。当然，开发此类软件需要相应的专业知识，包括 SNMP 和受监控设备。然而，这可以使管理员免于手动配置其网络组件以进行监控，并防止他们接收不准确的数据。即使对于大型网络环境，这也最大限度地减少了管理工作，并且 IT 经理可以确信他们的决策是基于正确的监控数据。

近期预计不会有值得称赞的继任者

对于 IT 行业而言，SNMP 是历史悠久的。然而，鉴于我们描述的缺点，令人惊讶的是，目前还没有能够满足现代基础设施要求的 SNMP 的可靠继任者，尤其是在软件定义网络和机器学习日益普及的情况下。2015 年推出的 Redfish 证明了设备监控可以以不同的方式完成。Redfish 协议采用统一的方法，通过 REST API 实现对服务器平台的远程访问。Redfish 的目标是取代现在被认为是安全漏洞的 IPMI 接口（智能平台管理接口）。

一些制造商在网络监控领域使用专有接口，但将其集成到监控平台需要一定的开发工作。如果使用的监控软件尚不支持，这种异构性也会增加网络基础设施的负担。

流遥测可能是未来有希望的候选者。在这种情况下，路由器、交换机等网络组件将数据持续流式传输到监控实例。因此，管理员可以确定他们需要哪些信息、以什么频率以及来自哪个设备或应用程序。这种方法的优点是可以实现实时监控，并且数据已经为基于 AI 和 ML 的分析做好准备。因此，流遥测可以帮助推动大型网络环境中的自动化、故障排除和流量优化。

一些制造商（如 Arista、Cisco 和 Juniper）目前正在研究他们自己的流遥测项目。然而，标准化仍然遥遥无期。因此，流遥测是否会获得相关性以及标准化是否会随之而来还有待观察。

尽管年代久远，但仍然不可或缺

尽管该协议年代久远且存在缺陷，但 SNMP 在未来一段时间内仍将继续使用。即使建立了替代方案，它也不会在一夜之间取代 SNMP，而是在未来几年内继续并行使用。然而，现在应该清楚的是，出于上述原因，使用一刀切的方法监控 SNMP 是没有意义的。仅仅执行标准查询以读取 SNMP 数据结构的监控解决方案很快就会变成一场赌博——因为可能会传输不正确的值。