2 SNMP代理

概述

您可能希望在打印机、网络交换机、路由器或 UPS 等设备上使用 SNMP 监控，这些设备通常启用 SNMP，并且在这些设备上尝试设置完整的操作系统和 Zabbix agent 是不切实际的。

为了能够在这些设备上检索 SNMP agent提供的数据，Zabbix 服务器必须 初始配置 通过指定 --with-net-snmp 支持 SNMP 标志。

SNMP 检查仅通过 UDP 协议执行。

如果 Zabbix server 和proxy 守护进程收到不正确的 SNMP 响应，则会记录类似以下内容的行：

  1. SNMP response from host "gateway" does not contain all of the requested variable bindings

虽然它们不能涵盖所有有问题的情况，但它们对于识别应禁用组合请求的单个 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 安装过程中安装该软件）或等效工具：

  1. snmpwalk -v 2c -c public <host IP> .

由于此处的“2c”代表 SNMP 版本，因此您也可以将其替换为“1”，以指示设备上的 SNMP 版本 1。

这应该会为您提供 SNMP 字符串及其最后一个值的列表。如果没有，则 SNMP“communtiy”可能与标准“public”不同，在这种情况下您需要找出它是什么。

然后，您可以浏览列表，直到找到要监控的字符串，例如如果您想要监控端口 3 上进入交换机的字节，可以使用以下行中的 IF-MIB::ifHCInOctets.3 字符串：

  1. IF-MIB::ifHCInOctets.3 = Counter64: 3409739121

您现在可以使用 snmpget 命令找出 ‘IF-MIB::ifHCInOctets.3’ 的数字 OID：

  1. snmpget -v 2c -c public -On <host IP> IF-MIB::ifHCInOctets.3

请注意，字符串中的最后一个数字是您要监控的端口号。另请参阅：动态索引。

这应该会给你类似以下内容：

  1. .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

创建与设备对应的主机。

2 SNMP代理 - 图1

为主机添加 SNMP 接口：

  • 输入 IP 地址/DNS 名称和端口号
  • 从下拉列表中选择 SNMP 版本
  • 根据所选的 SNMP 版本添加接口凭据：
  • SNMPv1、v2 仅需要community凭据（通常为“public”）
  • SNMPv3 需要更具体的选项（见下文）
  • 为 原生SNMP 批量请求 (GetBulkRequest-PDUs) 指定最大重复值（默认值：10）；仅适用于 SNMPv2 和 v3 中的 discovery[] 和 walk[] 监控项。请注意，将此值设置得太高可能会导致 SNMP 代理检查超时。
  • 选中 使用组合请求 复选框以允许 组合处理 SNMP 请求（与原生SNMP 批量请求“walk”和“get”无关）
如果 SNMPv3 凭证错误（安全名称、身份验证 协议/密码、隐私协议）：
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 模板之一，该模板将自动添加一组监控项。在使用模板之前， 请验证它是否与主机兼容。

单击“添加”以保存主机。

步骤3

创建一个监控项。

现在返回 Zabbix 并单击您之前创建的 SNMP 主机的 监控项。根据您在创建主机时是否使用模板，您将获得与您的主机关联的 SNMP 监控项列表或只是一个空列表。我们将假设您将使用刚刚使用 snmpwalk 和 snmpget 收集的信息自己创建监控项，因此单击 监控项。

在新监控项表单中填写所需的参数：

2 SNMP代理 - 图2

参数描述
名称输入监控项名称。
类型在此处选择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

一般示例：

参数说明
OID1.2.3.45.6.7.8.0（或 .1.2.3.45.6.7.8.0）
键<用作触发器引用的唯一字符串>
例如，“my_param”。

请注意，OID 可以采用数字或字符串形式给出。但是，在某些情况下，字符串 OID 必须转换为数字表示。 实用程序 snmpget 可用于此目的：

  1. snmpget -On localhost public enterprises.ucdavis.memory.memTotalSwap.0
示例 2

监控正常运行时间：

参数说明
OIDMIB::sysUpTime.0
Keyrouter.uptime
Value type浮点数
Unitsuptime
Multiplier0.01
Preprocessing step: Custom multiplier0.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 数据包丢失，而不是设备的限制。

但是，如果设备由于其他原因无法正确处理组合请求，并且上述启发式方法不起作用，则每个接口都有一个“使用组合请求”设置，允许禁用该设备的组合请求。