2 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 次。重试机制不适用于 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。
Zabbix 会缓存 SNMPv3 EngineID → IP 映射，并在后续检查中重用已缓存的 EngineID，而不是每次都发送探测，从而减少网络流量。 如果 EngineID 无法重用，则会通过带探测的重试来发现新的 EngineID。
配置 SNMP 监控
要通过 SNMP 开始监控设备，需要执行以下步骤：
第 1 步
找出您想要监控的监控项的 SNMP 字符串（或 OID）。
要获取 SNMP 字符串列表，请使用 snmpwalk 命令（它是 net-snmp 软件的一部分，通常应作为 Zabbix 安装的一部分被安装），或使用等效工具：
snmpwalk -v 2c -c public <host IP> .这里的“2c”表示 SNMP 版本，您也可以将其替换为“1”，表示设备上使用的是 SNMP Version 1。
这应该会返回一份 SNMP 字符串及其最新值的列表。
如果没有返回，则可能是因为 SNMP 的“community”不是标准的“public”，在这种情况下，您需要先确认实际使用的 community 是什么。
然后，您可以在列表中查找您想要监控的字符串，例如：
如果您想监控交换机 3 号端口的入站字节数，则应使用以下这一行中的 IF-MIB::ifHCInOctets.3 字符串：
IF-MIB::ifHCInOctets.3 = Counter64: 3409739121现在，您可以使用 snmpget 命令来查找 IF-MIB::ifHCInOctets.3 对应的数字 OID：
snmpget -v 2c -c public -On <host IP> IF-MIB::ifHCInOctets.3请注意，字符串中的最后一个数字就是您要监控的端口号。
另请参见：动态索引。
这应该会返回类似如下内容：
.1.3.6.1.2.1.31.1.1.1.6.3 = Counter64: 3472126941同样，OID 中的最后一个数字也是端口号。
一些最常用的 SNMP OID 会由 Zabbix 自动转换为数字表示形式。
在上面的最后一个示例中，值类型是“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-PDUs）指定 max repetition 值（默认值：10）；仅适用于 SNMPv2 和 v3 中的
discovery[]和walk[]监控项。 请注意，将此值设置得过高可能会导致 SNMP agent 检查超时。 - 勾选 Use combined requests 复选框，以允许对 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，但如果 Privacy passphrase 错误，则 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。
-
在早于 RHEL 8、CentOS 8、Oracle Linux 8、Debian 12、Ubuntu LTS 22.04、openSUSE Leap 15.5 的操作系统上，默认不支持 AES192 及更强的加密协议。
要检查 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，然后在重新编译 Zabbix 服务器时指定选项 --with-net-snmp=/home/user/yourcustomnetsnmp/bin/net-snmp-config。
第 3 步
创建一个用于监控的监控项。
现在，返回 Zabbix，点击你之前创建的 SNMP 主机的监控项。 根据你在创建主机时是否使用了模板，你看到的将是与你的主机关联的 SNMP 监控项列表，或者只是一个空列表。 这里我们假设你将根据刚刚使用 snmpwalk 和 snmpget 获取的信息自行创建监控项，因此请点击创建监控项。
在新监控项表单中填写必填参数：
| 参数 | 说明 |
|---|---|
| 名称 | 输入监控项名称。 |
| 类型 | 此处选择 SNMP agent。 |
| 键值 | 输入一个有意义的键值。 |
| 主机接口 | 请确保选择 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）。 此监控项的超时设置可在监控项配置表单中设置。如果设备不可达，建议设置较低的超时值以避免长时间延迟，因为如果之前的请求超时或失败，最多会重试 5 次（例如，3 秒超时可能导致等待 15 秒）。 你可以将其用作主监控项，并通过预处理让依赖监控项从主监控项中提取数据。 可以在一次 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]，则输出将是一个拼接后的列表。SNMPv2 和 v3 接口使用 GetBulk 请求，SNMPv1 接口使用 GetNext；批量请求的 max repetitions 在接口级别配置。 max repetitions 参数通过确定单个批量响应中返回的 OID 最大数量来影响批量请求。 较高的值会产生更大的批量响应，从而减少所需的传输次数。但是，并非所有设备都支持非常高的值，这可能会导致问题。 此监控项返回带有 -Oe -Ot -On 参数的 snmpwalk 工具输出。 你可以在SNMP 发现中将此监控项用作主监控项。 get[OID] - 异步获取单个值。 例如： get[1.3.6.1.2.1.31.1.1.1.6.3]此监控项的超时设置可在监控项配置表单中设置。如果设备不可达，建议设置较低的超时值以避免长时间延迟，因为如果之前的请求超时或失败，最多会重试 5 次（例如，3 秒超时可能导致等待 15 秒）。 OID - （旧版）输入单个文本或数字 OID，以同步方式获取单个值，也可以选择与其他值组合。 例如： 1.3.6.1.2.1.31.1.1.1.6.3。对于此选项，监控项检查超时将等于服务器配置文件中设置的值。 为获得更好的性能，建议使用 walk[OID] 和 get[OID] 监控项。所有 walk[OID] 和 get[OID] 监控项都以异步方式执行——无需在启动其他检查之前先接收某个请求的响应。DNS 解析同样也是异步的。异步检查的最大并发数为 1000（由 MaxConcurrentChecksPerPoller 定义）。异步 SNMP poller 的数量由 StartSNMPPollers 参数定义。 请注意，对于通过任意方法返回的网络流量统计数据，必须在预处理标签页中添加一个每秒速率变化步骤；否则你得到的将是来自 SNMP 设备的累计值，而不是最新变化值。 |
所有必填输入字段都以红色星号标记。
现在保存该监控项，然后前往 监控 > 最新数据 查看你的 SNMP 数据。
示例 1
通用示例：
| Parameter | Description |
|---|---|
| OID | 1.2.3.45.6.7.8.0（或 .1.2.3.45.6.7.8.0） |
| Key | <用作触发器引用的唯一字符串> 例如，"my_param"。 |
请注意，OID 可以使用数字形式或字符串形式。 但是，在某些情况下，字符串 OID 必须转换为数字表示形式。 可使用 snmpget 工具实现此目的：
snmpget -On localhost public enterprises.ucdavis.memory.memTotalSwap.0示例 2
监控运行时间：
| Parameter | Description |
|---|---|
| OID | MIB::sysUpTime.0 |
| Key | router.uptime |
| Value type | 浮点数 |
| Units | 运行时间 |
| Preprocessing step: Custom multiplier | 0.01 |
原生 SNMP 批量请求
walk[OID1,OID2,...] 监控项允许使用 SNMP 的原生批量请求功能（GetBulkRequest-PDU），该功能在 SNMP 2/3 版本中可用。
SNMP 中的 GetBulk 请求会执行多个 GetNext 请求，并在单个响应中返回结果。 这可用于常规 SNMP 监控项以及 SNMP 发现，以尽量减少网络往返次数。
SNMP walk[OID1,OID2,...] 监控项可用作主监控项，在一次请求中收集数据，并配合依赖监控项按需使用预处理解析响应。
请注意，使用原生 SNMP 批量请求与组合 SNMP 请求这一选项无关，后者是 Zabbix 自身用于合并多个 SNMP 请求的方式（请参见下一节）。
对于 SNMP 批量监控项，最多会进行五次重试，以避免在某个数据包丢失时发生失败。
带有 get 和 walk 的 SNMP 监控项的超时时间（在监控项配置表单中设置）是针对整个会话设置的。
无论数据是否被完整获取，都会应用超时；如果数据仅被部分接收（例如，多个 OID 中只有一个成功收集到数据），则该监控项会变为不支持状态，并显示消息“Only partial data received”。
如果达到超时时间，则会进行重试，超时时间将被重置，并重新发送最后一个请求，从而在单个数据包丢失或到达过晚时，允许从最后一个请求继续会话。
如果设备不可达，建议考虑设置较低的超时值以避免长时间延迟，因为如果之前的尝试超时或失败，最多会进行 5 次重试（例如，3 秒超时可能导致等待 15 秒）。
组合处理的内部工作原理
Zabbix 服务器和 proxy 可以在一次请求中向 SNMP 设备查询多个值。 这会影响以下几种类型的 SNMP 监控项：
单个接口上所有参数相同的 SNMP 监控项都会被安排在同一时间查询。 前两类监控项由 poller 以批次方式处理，每批最多 128 个监控项，而低级别发现规则仍像以前一样单独处理。
在更底层，查询值时会执行两类操作：获取多个指定对象，以及遍历 OID 树。
对于“获取”，使用 GetRequest-PDU，最多包含 128 个变量绑定。 对于“遍历”，SNMPv1 使用 GetNextRequest-PDU，而 SNMPv2 和 SNMPv3 使用 GetBulkRequest，且 "max-repetitions" 字段最大为 128。
因此，组合处理对每种 SNMP 监控项类型的收益如下：
- 常规 SNMP 监控项受益于“获取”方面的改进；
- 带动态索引的 SNMP 监控项同时受益于“获取”和“遍历”方面的改进：“获取”用于索引验证，“遍历”用于构建缓存；
- SNMP 低级别发现规则受益于“遍历”方面的改进。
但是，存在一个技术问题：并非所有设备都能够在每次请求中返回 128 个值。 有些设备总是返回正确响应，但另一些设备在潜在响应超过某个限制后，要么返回 "tooBig(1)" 错误，要么完全不响应。
为了找到适合给定设备的最佳查询对象数量，Zabbix 使用以下策略。 它会谨慎地从一次请求查询 1 个值开始。 如果成功，则在一次请求中查询 2 个值。 如果再次成功，则在一次请求中查询 3 个值，并继续以类似方式将查询对象数量乘以 1.5，从而得到以下请求大小序列：1、2、3、4、6、9、13、19、28、42、63、94、128。
但是，一旦设备拒绝返回正确响应（例如，对 42 个变量的请求），Zabbix 会做两件事。
首先，对于当前监控项批次，它会将单次请求中的对象数量减半，并查询 21 个变量。 如果设备在线，那么在绝大多数情况下该查询都应当成功，因为已知 28 个变量是可行的，而 21 明显少于这个数量。 但是，如果这样仍然失败，那么 Zabbix 会回退为逐个查询值。 如果此时仍然失败，那么可以确定设备没有响应，问题就不在于请求大小。
其次，对于后续的监控项批次，Zabbix 会从上一次成功的变量数量开始（在我们的示例中为 28），然后每次将请求大小递增 1，直到触及限制。 例如，假设最大响应大小为 32 个变量，则后续请求的大小将依次为 29、30、31、32 和 33。 最后一个请求将失败，而 Zabbix 之后将不再发出大小为 33 的请求。 从那时起，Zabbix 对该设备每次最多查询 32 个变量。
如果使用这个变量数量的大型查询失败，可能意味着两种情况之一。 设备用于限制响应大小的精确标准无法得知，但我们会尝试用变量数量来近似判断。 因此，第一种可能是：这个变量数量在一般情况下接近设备实际的响应大小限制；有时响应小于该限制，有时则大于该限制。 第二种可能是：某个方向上的 UDP 数据包只是丢失了。 基于这些原因，如果 Zabbix 遇到查询失败，它会减少允许的最大变量数量，以便更深入地进入设备可稳定处理的范围，但最多只会这样做两次。
在上面的示例中，如果包含 32 个变量的查询恰好失败，Zabbix 会将数量减少到 31。 如果这也失败，Zabbix 会再将数量减少到 30。 但是，Zabbix 不会将数量降到 30 以下，因为它会认为进一步的失败是由于 UDP 数据包丢失，而不是设备限制所致。
但是，如果某个设备由于其他原因无法正确处理组合请求，并且上述启发式方法不起作用，则每个接口都有一个 "Use combined requests" 设置，可用于为该设备禁用组合请求。
如果组合请求导致部分响应或格式错误的响应，从而造成错误的每秒速率（delta）计算（例如，接口计数器出现明显尖峰），请为受影响的接口禁用 Use combined requests，以强制对每个监控项分别查询；这通常可以防止错误尖峰。
或者，也可以考虑使用异步 get[] 或 walk[] 监控项，它们以异步方式执行，不受按接口进行 Use combined requests 批处理的影响——可以用来替代旧式同步 OID 检查，以避免与组合请求相关的问题。
请查找与概述部分所示类似的 server/proxy 日志条目，以帮助识别受影响的设备。
此外，如果接口经常变为不可用，则可能需要在 Zabbix server 或 Zabbix proxy 配置文件中增大 UnavailableDelay 参数，以降低请求频率。
如果在发现或 OID 遍历期间接收到部分数据，监控项可能会变为不支持。