Table of Contents
2 SNMP代理
概述
您可能希望在打印机、网络交换机、路由器或 UPS 等设备上使用 SNMP 监控，这些设备通常启用 SNMP，并且在这些设备上尝试设置完整的操作系统和 Zabbix agent 是不切实际的。
为了能够在这些设备上检索 SNMP agent提供的数据，Zabbix 服务器必须 初始配置 通过指定 --with-net-snmp 支持 SNMP 标志。
SNMP 检查仅通过 UDP 协议执行。
如果 Zabbix server 和proxy 守护进程收到不正确的 SNMP 响应，则会记录类似以下内容的行：
虽然它们不能涵盖所有有问题的情况，但它们对于识别应禁用组合请求的单个 SNMP 设备很有用。
在查询尝试失败后，Zabbix server/proxy 将始终重试至少一次：通过 SNMP 库的重试机制或通过内部 组合处理 机制。
如果监控 SNMPv3 设备，请确保 msgAuthoritativeEngineID（也称为 snmpEngineID 或“Engine ID”）不会由两个设备共享。根据 RFC 2571（第 3.1.1.1 节），它对于每个设备必须是唯一的。
RFC3414 要求 SNMPv3 设备保留其 engineBoots。有些设备不这样做，导致其 SNMP 消息在重新启动后被丢弃为过期消息。在这种情况下，需要在server/proxy 上手动清除 SNMP 缓存（通过使用 -R snmp_cache_reload）或重新启动server/proxy。
配置SNMP监控
要通过SNMP开始监控设备，必须执行以下步骤：
步骤1
找出您要监控的监控项的 SNMP 字符串（或 OID）。
要获取 SNMP 字符串列表，请使用 snmpwalk 命令（net-snmp 软件的一部分，您应该已在 Zabbix 安装过程中安装该软件）或等效工具：
由于此处的“2c”代表 SNMP 版本，因此您也可以将其替换为“1”，以指示设备上的 SNMP 版本 1。
这应该会为您提供 SNMP 字符串及其最后一个值的列表。如果没有，则 SNMP“communtiy”可能与标准“public”不同，在这种情况下您需要找出它是什么。
然后，您可以浏览列表，直到找到要监控的字符串，例如如果您想要监控端口 3 上进入交换机的字节，可以使用以下行中的 IF-MIB::ifHCInOctets.3 字符串：
您现在可以使用 snmpget 命令找出 'IF-MIB::ifHCInOctets.3' 的数字 OID：
请注意，字符串中的最后一个数字是您要监控的端口号。另请参阅：动态索引。
这应该会给你类似以下内容：
同样，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 版本
- 根据所选的 SNMP 版本添加接口凭据：
- SNMPv1、v2 仅需要community凭据（通常为“public”）
- SNMPv3 需要更具体的选项（见下文）
- 为 原生SNMP 批量请求 (GetBulkRequest-PDUs) 指定最大重复值（默认值：10）；仅适用于 SNMPv2 和 v3 中的
discovery[]和walk[]监控项。请注意，将此值设置得太高可能会导致 SNMP 代理检查超时。 - 选中 使用组合请求 复选框以允许 组合处理 SNMP 请求（与原生SNMP 批量请求“walk”和“get”无关）
| SNMPv3 参数 | 说明 |
|---|---|
| 上下文名称 | 输入上下文名称以识别 SNMP 子网上的监控项。 用户宏在此字段中解析。 |
| 安全名称 | 输入安全名称。 用户宏在此字段中解析。 |
| 安全级别 | 选择安全级别： noAuthNoPriv - 不使用身份验证或隐私协议 AuthNoPriv - 使用身份验证协议，不使用隐私协议 AuthPriv - 同时使用身份验证和隐私协议 |
| 身份验证协议 | 选择身份验证协议 - MD5、SHA1、SHA224、SHA256、SHA384 或 SHA512。 |
| 身份验证密码 | 输入身份验证密码。 在此字段中解析用户宏。 |
| 隐私协议 | 选择隐私协议 - DES、AES128、AES192、AES256、AES192C（思科）或 AES256C（思科）。 请注意： - 在某些较旧的系统上，net-snmp 可能不支持 AES256； - 在某些较新的系统（例如 RHEL9）上，net-snmp 软件包可能会放弃对 DES 的支持。 |
| 隐私密码 | 输入隐私密码。 在此字段中解析用户宏。 |
- Zabbix 从 net-snmp 接收到一个 ERROR，除了错误的 Privacy passphrase 在这种情况下 Zabbix 从 net-snmp 接收到一个 TIMEOUT 错误；
- SNMP 接口可用性将切换为红色（不可用）。
如果在不更改 安全名称 的情况下对 身份验证协议、 身份验证密码、隐私协议 或 隐私密码 进行更改，则仅在手动清除server/proxy 上的缓存（使用 -R snmp_cache_reload）或重新启动server/proxy 后才会生效。如果 安全名称 也发生更改，则所有参数将立即更新。
您可以使用提供的 SNMP 模板之一，该模板将自动添加一组监控项。在使用模板之前， 请验证它是否与主机兼容。
单击“添加”以保存主机。
Privacy protocol support
Depending on your operating system and net-snmp configuration, some privacy protocols may not be available:
On some newer operating systems (for example, RHEL9) support of DES is dropped for the net-snmp package.
Encryption protocols AES192 and stronger are not supported out-of-the-box on the operating systems older then RHEL 8, CentOS 8, Oracle Linux 8, Debian 12, Ubuntu LTS 22.04, openSUSE Leap 15.5.
To check whether net-snmp library supports AES192+, use one of the following options:
net-snmp-config:net-snmp-config --configure-options
If the output contains --enable-blumenthal-aes, AES192+ is supported.
Note that net-snmp-config is part of the development package for SNMP (libsnmp-dev for Debian/Ubuntu, net-snmp-devel for CentOS/RHEL/OL/SUSE) and may not be installed by default.
snmpget:snmpget -v 3 -x AES-256
If the output contains Invalid privacy protocol specified after -3x flag: AES-256, AES192+ is not supported. If the output contains No hostname specified., AES192+ is not supported.
If your net-snmp library does not support AES192 and higher protocols, recompile net-snmp with --enable-blumenthal-aes option, then recompile Zabbix server specifying the option --with-net-snmp=/home/user/yourcustomnetsnmp/bin/net-snmp-config.
步骤3
创建一个监控项。
现在返回 Zabbix 并单击您之前创建的 SNMP 主机的 监控项。根据您在创建主机时是否使用模板，您将获得与您的主机关联的 SNMP 监控项列表或只是一个空列表。我们将假设您将使用刚刚使用 snmpwalk 和 snmpget 收集的信息自己创建监控项，因此单击 监控项。
在新监控项表单中填写所需的参数：
| 参数 | 描述 |
|---|---|
| 名称 | 输入监控项名称。 |
| 类型 | 在此处选择SNMP 代理。 |
| 密钥 | 输入有意义的密钥。 |
| 主机接口 | 确保选择 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)。 此项的超时设置可在 监控项配置 表单中设置。 您可以将其用作主监控项，使用预处理从主监控项中提取数据的依赖监控项。 可以在单个 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 接口；批量请求的最大重复次数在接口级别配置。 此项返回带有 -Oe -Ot -On 参数的 snmpwalk 实用程序的输出。 您可以在 SNMP 发现 中将此项用作主项。 get[OID] - 异步检索 单个 值。 例如： get[1.3.6.1.2.1.31.1.1.1.6.3]此项的超时设置可以在 监控项配置 表单中设置。 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 轮询器的数量由 StartSNMPPollers 参数定义。 请注意，对于任何方法返回的网络流量统计信息，必须在 预处理 选项卡中添加 每秒更改 步骤；否则，您将从 SNMP 设备获得累积值，而不是最新更改。 |
所有必填输入字段都标有红色星号。
现在保存监控项并转到 监控 → 最新数据 获取您的 SNMP数据。
示例 1
一般示例：
| 参数 | 说明 |
|---|---|
| OID | 1.2.3.45.6.7.8.0（或 .1.2.3.45.6.7.8.0） |
| 键 | <用作触发器引用的唯一字符串> 例如，“my_param”。 |
请注意，OID 可以采用数字或字符串形式给出。但是，在某些情况下，字符串 OID 必须转换为数字表示。 实用程序 snmpget 可用于此目的：
示例 2
监控正常运行时间：
| 参数 | 说明 |
|---|---|
| OID | MIB::sysUpTime.0 |
| Key | router.uptime |
| Value type | 浮点数 |
| Units | uptime |
| Multiplier | 0.01 |
| 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 请求的方式（请参阅下一节）。
批量处理的内部工作原理
Zabbix 服务器和代理可能会在单个请求中向 SNMP 设备查询多个值。这会影响几种类型的 SNMP 监控项：
单个接口上具有相同参数的所有 SNMP 监控项都计划同时查询。前两种类型的监控项由轮询器以最多 128 个监控项分批采集，而低级发现规则如前所述单独处理。
在较低级别，有两种用于查询值的操作：获取多个指定对象和遍历 OID 树。
对于“getting”，使用最多 128 个变量绑定的 GetRequest-PDU。对于“walking”，对于 SNMPv1 使用 GetNextRequest-PDU，对于 SNMPv2 和 SNMPv3 使用“max-repetitions”字段最多为 128 的 GetBulkRequest。
因此，每种 SNMP 监控项类型的组合处理的好处概述如下：
- 常规SNMP监控项受益于“getting” 的改进;
- 有动态索引的SNMP监控项受益于“getting”和“walking”改进：“getting”用于索引验证，“walking”用于构建缓存;
- SNMP低级发现规则受益于“walking”的改进。
然而，有一个技术问题，并非所有设备都能够根据请求返回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 数据包丢失，而不是设备的限制。
但是，如果设备由于其他原因无法正确处理组合请求，并且上述启发式方法不起作用，则每个接口都有一个“使用组合请求”设置，允许禁用该设备的组合请求。