3 SNMP agent
概述
您可能希望在打印机、网络交换机、路由器或 UPS 等设备上使用 SNMP 监控，这些设备通常都支持 SNMP，而在这些设备上尝试部署完整操作系统和 Zabbix agent 并不现实。
为了能够检索这些设备上的 SNMP agent 提供的数据，Zabbix 服务器必须先通过指定 --with-net-snmp 标志进行 初始配置，以启用 SNMP 支持。
建议同时 安装 MIB 文件，以确保监控项值能够以正确的格式显示。
如果没有 MIB 文件，可能会出现格式问题，例如以 HEX 而不是 UTF-8 显示值，或反之。
SNMP 检查仅通过 UDP 协议执行。
如果 Zabbix 服务器和 proxy 守护进程收到错误的 SNMP 响应，它们会记录类似以下内容的日志行：
SNMP response from host "gateway" does not contain all of the requested variable bindings虽然这些日志不能覆盖所有有问题的情况，但它们有助于识别那些应禁用组合请求的单个 SNMP 设备。
对于 SNMP walk 和 get 监控项，Zabbix 服务器/proxy 将最多重试 5 次（自 Zabbix 7.0.14 起）。
该重试机制不适用于 DNS 解析失败。
对于旧版 SNMP 检查（单个 OID 编号或字符串），Zabbix 服务器/proxy 在查询失败后至少会重试一次：要么通过 SNMP 库自身的重试机制，要么通过内部的 组合处理 机制。
如果监控 SNMPv3 设备，请确保 msgAuthoritativeEngineID（也称为 snmpEngineID 或 "Engine ID"）绝不能被两台设备共用。 根据 RFC 2571（第 3.1.1.1 节），它对每台设备都必须是唯一的。
RFC3414 要求 SNMPv3 设备持久保存其 engineBoots。 某些设备并未这样做，这会导致它们在重启后，其 SNMP 消息因被视为过期而被丢弃。 在这种情况下，需要在服务器/proxy 上手动清除 SNMP 缓存（使用 -R snmp_cache_reload），或者重启服务器/proxy。
配置SNMP监控
通过 SNMP 开始监控设备时，必须执行以下步骤：
步骤1
找出您想要监控的监控项的SNMP string（或OID）。
要get SNMP字符串列表，可使用snmpwalk命令（属于net-snmp软件的一部分，安装Zabbix时应该已包含）或等效工具：
snmpwalk -v 2c -c public <host IP> .由于此处的'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:
snmpget -v 2c -c public -On <host IP> IF-MIB::ifHCInOctets.3请注意，string中的最后一个数字是您要监控的端口号。 另请参阅：Dynamic indexes.
这将为您提供类似以下内容的结果：
.1.3.6.1.2.1.31.1.1.1.6.3 = Counter64: 3472126941同样，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 步
创建主机，使其对应于某个设备。
为主机添加一个 SNMP 接口：
- 输入 IP 地址/DNS 名称和端口号。
- 从下拉列表中选择 SNMP version。
- 根据所选的 SNMP 版本添加接口凭据：
- SNMPv1、v2 只需要 community（通常为 'public'）。
- SNMPv3 需要更具体的选项（见下文）。
- 为 原生 SNMP 批量请求（GetBulkRequest-PDU）指定最大重复值（默认值：10）；仅适用于 SNMPv2 和 v3 中的
discovery[]和walk[]监控项。 请注意，将此值设置得过高可能会导致 SNMP agent 检查超时。 - 勾选 Use combined requests 复选框，以允许对 SNMP 请求进行组合处理（这与原生 SNMP 批量请求 "walk" 和 "get" 无关）。
| SNMPv3 parameter | Description |
|---|---|
| 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，唯独 Privacy passphrase 错误时，Zabbix 会从 net-snmp 收到 TIMEOUT 错误。
- SNMP 接口可用性将变为红色（不可用）。
在不更改 Security name 的情况下，对 Authentication protocol、Authentication passphrase、Privacy protocol 或 Privacy passphrase 所做的更改，通常会在 Zabbix 中更新相应的 SNMPv3 接口时自动应用。 如果 Security name 也发生了更改，则所有参数都会立即更新。
你可以使用提供的某个 SNMP 模板，它会自动添加一组监控项。在使用模板之前，请先确认它与该主机兼容。
点击 Add 保存主机。
SNMPv3
The following parameters are required for SNMPv3:
- Context name - Enter context name to identify item on SNMP subnet.
User macros are resolved in this field. - Security name - Enter security name.
User macros are resolved in this field. - Security level - Select security level:
- noAuthNoPriv - no authentication nor privacy protocols are used;
- AuthNoPriv - authentication protocol is used, privacy protocol is not;
- AuthPriv - both authentication and privacy protocols are used.
- Authentication protocol - Select authentication protocol: MD5, SHA1; with net-snmp 5.8 and newer SHA224, SHA256, SHA384, or SHA512.
- Authentication passphrase - Enter authentication passphrase.
User macros are resolved in this field. - Privacy protocol - Select privacy protocol: DES, AES128, AES192, AES256, AES192C (Cisco), or AES256C (Cisco).
See notes about privacy protocol support. - Privacy passphrase - Enter privacy passphrase.
User macros are resolved in this field.
In case of wrong SNMPv3 credentials (security name, authentication protocol/passphrase, privacy protocol):
- Zabbix receives an ERROR from net-snmp, except for wrong Privacy passphrase in which case Zabbix receives a TIMEOUT error from net-snmp.
- SNMP interface availability will switch to red (unavailable).
Changes in Authentication protocol, Authentication passphrase, Privacy protocol or Privacy passphrase, made without changing the Security name, are normally applied automatically when the corresponding SNMPv3 interface is updated in Zabbix. In cases where Security name is also changed, all parameters will be updated immediately.
隐私协议支持
根据您的操作系统和 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：
net-snmp-config --configure-options如果输出包含 --enable-blumenthal-aes，则表示支持 AES192+。
请注意，net-snmp-config 是 SNMP 开发包的一部分（Debian/Ubuntu 上为 libsnmp-dev，CentOS/RHEL/OL/SUSE 上为 net-snmp-devel），默认情况下可能未安装。
snmpget：
snmpget -v 3 -x AES-256如果输出包含 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工具：
snmpget -On localhost public enterprises.ucdavis.memory.memTotalSwap.0示例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遍历期间接收到部分数据，监控项可能会变得不受支持。