Documentation
Table of Contents
2 SNMP agent
概述
您可能需要在打印机、网络交换机、路由器或UPS等设备上使用SNMP监控，这些设备通常支持SNMP功能，且在这些设备上尝试安装完整的操作系统和Zabbix agents是不切实际的。
为了能够从这些设备获取SNMP agents提供的数据，Zabbix server必须通过指定--with-net-snmp flag来initially configured支持SNMP功能。 建议同时install MIB files以确保监控项值能以正确格式显示。 若缺少MIB文件，可能会出现问题的情况，例如以HEX格式而非UTF-8显示数值，反之亦然。
SNMP检查仅通过UDP协议执行。
当接收到错误的SNMP响应时，Zabbix server和proxy守护进程会记录类似以下内容的日志行：
虽然这些日志不能涵盖所有问题场景，但对于识别应禁用组合请求的特定SNMP设备非常有用。
对于SNMP walk和get 监控项，Zabbix server/proxy将重试最多5次（自Zabbix 7.0.14起）。该重试机制不适用于DNS解析失败的情况。
对于传统SNMP检查（单OID编号或string），Zabbix server/proxy在query尝试失败后至少会重试一次：通过SNMP库的重试机制或内部组合处理机制实现。
若监控SNMPv3设备，请确保msgAuthoritativeEngineID（也称为snmpEngineID或"引擎ID"）永远不会被两个设备共享。 根据RFC 2571（第3.1.1.1节），该ID必须每个设备唯一。
RFC3414要求SNMPv3设备持久化存储其engineBoots值。 部分设备未遵守此要求，导致重启后其SNMP消息因过期而被丢弃。 在此情况下，需在server/proxy上手动清除SNMP缓存（通过运行时控制），或重启server/proxy。
配置SNMP监控
通过 SNMP 开始监控设备时，必须执行以下步骤：
步骤1
找出您想要监控的监控项的SNMP string（或OID）。
要get SNMP字符串列表，可使用snmpwalk命令（属于net-snmp软件的一部分，安装Zabbix时应该已包含）或等效工具：
由于此处的'2c'代表SNMP version，您也可以将其替换为'1'，以表示设备上的SNMP版本1。
这将为您提供SNMP字符串列表及其最新值。 如果未成功，则可能是SNMP 'community'与标准'public'不同，此时您需要查明实际的community值。
然后您可以浏览列表，直到找到想要监控的string，例如 如果您想监控交换机端口3的入站字节流量，您需要使用该行中的IF-MIB::ifHCInOctets.3 string：
IF-MIB::ifHCInOctets.3 = Counter64: 3409739121您现在可以使用 snmpget 命令来查找 'IF-MIB::ifHCInOctets.3' 对应的数字OID:
请注意，string中的最后一个数字是您要监控的端口号。 另请参阅：Dynamic indexes.
这将为您提供类似以下内容的结果：
同样，OID中的最后一个数字是端口号。
Zabbix最常用的SNMP OID包括translated automatically to a numeric representation。
在上面的最后一个示例中，值类型为"Counter64"，在内部对应ASN_COUNTER64类型。 支持的完整类型列表包括ASN_COUNTER, ASN_COUNTER64, ASN_UINTEGER, ASN_UNSIGNED64, ASN_INTEGER, ASN_INTEGER64, ASN_FLOAT, ASN_DOUBLE, ASN_TIMETICKS, ASN_GAUGE, ASN_IPADDRESS, ASN_OCTET_STR以及ASN_OBJECT_ID. 这些类型大致对应于snmpget输出中的"Counter32"、"Counter64"、"UInteger32"、"integer"、"float"、"Double"、"Timeticks"、"Gauge32"、"IpAddress"、"OCTET string"、"object IDENTIFIER"，但也可能根据显示提示的存在而显示为"string"、"Hex-string"、"OID"等其他形式。
步骤2
Create a host 对应设备。
为 主机 添加 SNMP 接口：
- 输入 IP 地址/DNS 名称和端口号。
- 从下拉菜单中选择 SNMP 版本。
- 根据所选的 SNMP 版本添加接口凭据：
- SNMPv1 和 v2 仅需要 community（通常为 'public'）。
- SNMPv3 需要更多特定选项（见下文）。
- 指定用于原生 SNMP 批量请求（GetBulkRequest-PDUs）的最大重复值（默认值：10）；仅适用于 SNMPv2 和 v3 中的
discovery[]和walk[]监控项。 请注意，该值设置过高可能导致 SNMP agent 检查超时。 - 勾选 使用组合请求 复选框以允许对 SNMP 请求进行组合处理（与原生 SNMP 批量请求 "walk" 和 "get" 无关）。
| SNMPv3 参数 | 描述 |
|---|---|
| Context name | 输入上下文名称以在 SNMP 子网中标识 监控项。 此字段中将解析用户宏。 |
| Security name | 输入安全名称。 此字段中将解析用户宏。 |
| Security level | 选择安全级别： noAuthNoPriv - 不使用认证和隐私协议 AuthNoPriv - 使用认证协议，不使用隐私协议 AuthPriv - 同时使用认证和隐私协议 |
| Authentication protocol | 选择认证协议 - MD5, SHA1；使用 net-snmp 5.8 及更新版本支持 SHA224, SHA256, SHA384 或 SHA512。 |
| Authentication passphrase | 输入认证短语。 此字段中将解析用户宏。 |
| Privacy protocol | 选择隐私协议 - DES, AES128, AES192, AES256, AES192C（Cisco）或 AES256C（Cisco）。 有关隐私协议支持的说明，请参阅相关注释。 |
| Privacy passphrase | 输入隐私短语。 此字段中将解析用户宏。 |
如果 SNMPv3 凭据（安全名称、认证协议/短语、隐私协议）错误：
- Zabbix 会从 net-snmp 接收到一个 ERROR，但 隐私短语 错误时，Zabbix 会从 net-snmp 接收到 TIMEOUT 错误。
- SNMP 接口可用性将变为红色（不可用）。
在不更改 Security name 的情况下对 Authentication protocol、Authentication passphrase、Privacy protocol 或 Privacy passphrase 所做的更改，通常会在 Zabbix 中更新对应的 SNMPv3 接口时自动应用。 如果同时更改了 Security name，所有参数将立即更新。
您可以使用提供的 SNMP 模板之一，它将自动添加一组 监控项。在使用模板之前，请确认其与 主机 兼容。
点击 Add 保存 主机。
隐私协议支持
根据您的操作系统和 net-snmp 的配置，某些隐私协议可能不可用：
在某些较新的操作系统上（例如，RHEL9），net-snmp 软件包已不再支持 DES。
加密协议 AES192 及更高级别在 RHEL 8、CentOS 8、Oracle Linux 8、Debian 12、Ubuntu LTS 22. 04、openSUSE Leap 15. 5 之前的旧版操作系统上默认不支持。
要检查 net-snmp 库是否支持 AES192+，请使用以下选项之一：
net-snmp-config：
如果输出包含 --enable-blumenthal-aes，则表示支持 AES192+。
请注意，net-snmp-config 是 SNMP 开发包的一部分（Debian/Ubuntu 上为 libsnmp-dev，CentOS/RHEL/OL/SUSE 上为 net-snmp-devel），默认情况下可能未安装。
snmpget：
如果输出包含 Invalid privacy protocol specified after -3x flag: AES-256，则表示不支持 AES192+。 如果输出包含 No hostname specified.，则表示不支持 AES192+。
如果您的 net-snmp 库不支持 AES192 及更高级别的协议，请使用 --enable-blumenthal-aes 选项重新编译 net-snmp，然后在指定 --with-net-snmp=/home/user/yourcustomnetsnmp/bin/net-snmp-config 选项的情况下重新编译 Zabbix server。
步骤3
创建用于监控的配置
因此，现在返回Zabbix并为您之前创建的SNMP 主机点击监控项。 根据您在创建主机时是否使用了模板，您将获得与该主机关联的SNMP 监控项列表或仅显示空列表。 我们将基于您将自行create 监控项的假设开展工作，使用您刚刚通过snmpwalk和snmpget收集的信息，因此请点击创建监控项。
在新监控项表单中填写所需参数:
| 参数 | 描述 |
|---|---|
| Name | 输入 监控项 名称. |
| Type | 在此处选择 SNMP agent。 |
| Key | 输入具有明确含义的键值 |
| Host interface | 确保选择SNMP接口，例如交换机/路由器的接口。 |
| SNMP OID | 使用以下任一支持的格式输入OID值： walk[OID1,OID2,...] - 获取值的子树。 例如： walk[1.3.6.1.2.1.2.2.1.2,1.3.6.1.2.1.2.2.1.3]。此选项利用原生SNMP批量请求（GetBulkRequest-PDUs）异步处理。 此监控项的超时设置可在配置表单中配置。若设备不可达，建议设置较低超时值以避免长时间延迟，因为若先前请求超时或失败（例如3秒超时可能导致15秒等待时间），最多会进行5次重试（自Zabbix 7.0.14起）。 您可将其作为主监控项，配合通过预处理从主项提取数据的依赖监控项使用。 单个snmp walk中可指定多个OID，例如 walk[OID1,OID2,...]以异步逐个处理OID。若批量请求未返回结果，则会尝试不使用批量请求获取单条记录。 支持以MIB名称作为参数；因此 walk[1.3.6.1.2.1.2.2.1.2]和walk[ifDescr]将返回相同输出。若指定多个OID/MIB（如 walk[ifDescr,ifType,ifPhysAddress]），则输出为串联列表。GetBulk请求用于SNMPv2和v3接口，GetNext用于SNMPv1接口；批量请求的最大重复次数在接口级别配置。 最大重复次数参数通过确定单个批量响应中返回的OID最大数量来影响批量请求。 较高值会产生较大的批量响应，减少所需传输次数。但并非所有设备都支持极高值，可能导致问题。 此监控项返回带-Oe -Ot -On参数的snmpwalk工具输出。 您可在SNMP discovery中将此监控项用作主监控项。 get[OID] - 异步获取单个值。 例如： get[1.3.6.1.2.1.31.1.1.1.6.3]此监控项的超时设置可在配置表单中配置。若设备不可达，建议设置较低超时值以避免长时间延迟，因为若先前请求超时或失败（例如3秒超时可能导致15秒等待时间），最多会进行5次重试（自Zabbix 7.0.14起）。 OID - （传统方式）输入单个文本或数字OID以同步获取单个值，可选与其他值组合。 例如： 1.3.6.1.2.1.31.1.1.1.6.3。此选项的监控项检查超时将等于服务器configuration file中设置的值。 推荐使用 walk[OID]和get[OID]监控项以获得更佳性能。所有walk[OID]和get[OID]监控项均异步执行——无需等待一个请求响应即可启动其他检查。DNS解析同样异步处理。异步检查的最大并发数为1000（由maxconcurrentchecksperpoller定义）。异步SNMP轮询器数量由startsnmppollers参数定义。 注意：对于通过任何方法返回的网络流量统计，必须在预处理选项卡中添加每秒变化步骤；否则您将get来自SNMP设备的累计值而非最新变化。 |
所有必填字段均以红色星号标记.
现在保存监控项并前往Monitoring > Latest data查看您的SNMP数据
示例1
通用示例：
| 参数 | 描述 |
|---|---|
| OID | 1.2.3.45.6.7.8.0（或.1.2.3.45.6.7.8.0） |
| Key | <用作触发器引用的唯一string> 例如："my_param"。 |
注意：OID可以以数字或string形式给出。 但在某些情况下，string形式的OID必须转换为数字表示。 为此可以使用snmpget工具：
示例2
运行时间监控：
| 参数 | 描述 |
|---|---|
| OID | MIB::sysUpTime.0 |
| Key | router.uptime |
| Value type | float |
| Units | uptime |
| Preprocessing step: Custom multiplier | 0.01 |
原生SNMP批量请求
walk[OID1,OID2,...] 监控项语法允许使用SNMP 2/3版本中原生的批量请求功能（GetBulkRequest-PDU）。
SNMP中的GetBulk请求会执行多个GetNext请求并将结果合并返回。该功能既可用于常规SNMP 监控项采集，也可用于SNMP自动发现，从而减少网络往返次数。
SNMP walk[OID1,OID2,...] 监控项可作为主监控项，通过预处理让依赖的监控项按需解析批量请求的响应数据。
注意：原生SNMP批量请求与Zabbix自有的SNMP请求合并功能（参见下一节）无关。
为防止数据包丢失导致失败，SNMP批量监控项最多会重试5次（自Zabbix 7.0.14起）。使用get和walk的SNMP 监控项超时时间（在配置表单中设置）作用于整个会话。无论数据是否完整获取都会触发超时；若仅获取部分数据（例如仅成功采集多个OID中的一个），则监控项会变为"不受支持"状态并显示"Only partial data received"消息。超时后将自动重试并重置超时计时器，从最后一个请求继续会话（适用于单数据包丢失或延迟场景）。建议设置较低超时值以避免设备不可达时的长时间等待（例如3秒超时可能导致15秒等待，因为最多会进行5次重试）。
组合处理的内部机制
Zabbix server和proxy可以在单个请求中query SNMP设备的多个值。 这会影响以下几种SNMP 监控项类型：
- 常规SNMP 监控项
- 带动态索引的SNMP 监控项 with dynamic indexes
- SNMP low-level discovery rules
具有相同参数的单个接口上的所有SNMP 监控项会被安排在同一时间进行查询。 前两种类型的监控项由轮询器以最多128个监控项为一批次获取，而底层发现规则则像之前一样单独处理。
在底层，查询值时会执行两种操作：获取多个指定的objects和遍历OID树。
对于"获取"操作，使用最多包含128个变量绑定的GetRequest-PDU。 对于"遍历"操作，SNMPv1使用GetNextRequest-PDU，而SNMPv2和SNMPv3则使用带有"max-repetitions"字段（最多128）的GetBulkRequest。
因此，每种SNMP 监控项类型从组合处理中获得的好处如下所述：
- 常规SNMP 监控项受益于"获取"改进；
- 带动态索引的SNMP 监控项同时受益于"获取"和"遍历"改进："获取"用于索引验证，"遍历"用于构建缓存；
- SNMP底层发现规则受益于"遍历"改进。
然而，存在一个技术问题：并非所有设备都能在每个请求中返回128个值。 有些设备总是返回正确的响应，但其他设备要么返回"tooBig(1)"错误，要么在潜在响应超过某个限制时根本不响应。
为了找到给定设备要query的objects的最佳数量，Zabbix采用以下策略。 它谨慎地从每个请求查询1个值开始。 如果成功，则在下一个请求中queries2个值。 如果再次成功，则在下一个请求中queries3个值，并类似地继续将查询的objects数量乘以1.5，产生以下请求大小序列：1, 2, 3, 4, 6, 9, 13, 19, 28, 42, 63, 94, 128。
然而，一旦设备拒绝提供正确的响应（例如，对于42个变量），Zabbix会做两件事。
首先，对于当前的监控项批次，它将单个请求中的objects数量减半，并queries21个变量。 如果设备正常运行，那么query在绝大多数情况下应该有效，因为已知28个变量可以工作，而21个明显少于这个数字。 然而，如果仍然失败，Zabbix会回退到逐个查询值。 如果此时仍然失败，则设备肯定没有响应，请求大小不是问题。
Zabbix对后续监控项批次做的第二件事是，从最后一个成功的变量数量（在我们的例子中是28）开始，并继续将请求大小递增1，直到达到限制。 例如，假设最大响应大小为32个变量，则后续请求的大小将为29、30、31、32和33。 最后一个请求将失败，Zabbix将永远不会再次问题大小为33的请求。 从那时起，Zabbix将为此设备query最多32个变量。
如果大量queries在这个变量数量下失败，可能意味着两种情况之一。 设备用于限制响应大小的确切标准无法得知，但我们尝试使用变量数量来近似。 因此，第一种可能性是，这个变量数量大约处于设备实际响应大小限制的一般情况下：有时响应小于限制，有时大于限制。 第二种可能性是，任一方向的UDP数据包丢失。 出于这些原因，如果Zabbix获得一个失败的query，它会减少最大变量数量，以尝试get进入设备更舒适的范围，但最多减少两次。
在上面的例子中，如果带有32个变量的query失败，Zabbix会将数量减少到31。 如果这也失败，Zabbix会将数量减少到30。 然而，Zabbix不会将数量减少到30以下，因为它会假设进一步的失败是由于UDP数据包丢失，而不是设备的限制。
然而，如果设备由于其他原因无法正确处理组合请求，并且上述启发式方法不起作用，每个接口都有一个"使用组合请求"设置，可以禁用该设备的组合请求。
如果组合请求导致部分或格式错误的响应，从而导致不正确的每秒（增量）计算（例如，接口计数器中的明显峰值），请为受影响的接口禁用使用组合请求，以强制每个监控项单独queries；这通常可以防止虚假峰值。 或者，考虑使用异步get[]或walk[] 监控项，它们是异步执行的，不受每个接口使用组合请求批处理的限制——它们可以用来替代传统的同步OID检查，以避免与组合请求相关的问题。 查找类似于概述部分中显示的server/proxy日志条目，以帮助识别受影响的设备。
此外，如果接口频繁变得不可用，可能需要增加unavailabledelay或unavailabledelay配置文件中的UnavailableDelay参数以减少请求频率。 如果在发现或OID遍历期间接收到部分数据，监控项可能会变得不受支持。