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 - 同时使用身份验证和隐私协议
身份验证协议选择身份验证协议 - MD5SHA1SHA224SHA256SHA384SHA512
身份验证密码输入身份验证密码。
在此字段中解析用户宏。
隐私协议选择隐私协议 - DESAES128AES192AES256AES192C(思科)或 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 数据包丢失,而不是设备的限制。

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