2 SNMP agent

概述

您可能需要在打印机、网络交换机、路由器或UPS等设备上使用SNMP监控,这些设备通常支持SNMP协议,且在这些设备上尝试安装完整的操作系统和Zabbix agents是不切实际的。

为了能够从这些设备获取SNMP agents提供的数据,必须通过指定--with-net-snmp flag来4-配置源代码支持SNMP的Zabbix server。

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

Zabbix server和proxy守护进程通过单次请求query多个SNMP设备的值。这会影响所有类型的SNMP 监控项(常规SNMP 监控项、带动态索引的SNMP 监控项以及SNMP低级发现),并应使SNMP处理更加高效。有关其内部工作原理的技术细节,请参阅批量处理部分。对于无法正确处理批量请求的设备,可以通过每个接口的"使用批量请求"设置来禁用此功能。

如果Zabbix server和proxy守护进程收到不正确的SNMP响应,它们会记录类似以下的行:

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

虽然这些日志不能涵盖所有问题情况,但对于识别应禁用批量请求的个别SNMP设备非常有用。

在query尝试失败后,Zabbix server/proxy将始终至少重试一次:通过SNMP库的重试机制或内部的批量处理机制。

如果监控SNMPv3设备,请确保msgAuthoritativeEngineID(也称为snmpEngineID或"引擎ID")永远不会被两个设备共享。根据RFC 2571(第3.1.1.1节),每个设备的引擎ID必须是唯一的。

RFC3414要求SNMPv3设备持久化其engineBoots。某些设备未遵守此要求,导致重启后其SNMP消息因过期而被丢弃。在这种情况下,需要在server/proxy上手动清除SNMP缓存(通过使用运行时控制),或者需要重启server/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'不同, 在这种情况下,您需要找出它是什么。

然后您可以浏览列表,直到找到要监控的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中的最后一个数字是端口号。

一些最常用的SNMP OID由Zabbix 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。这些类型大致对应于"Counter32"、 "Counter64"、"UInteger32"、"integer"、"float"、"Double"、"Timeticks"、 "Gauge32"、"IpAddress"、"OCTET string"、"object IDENTIFIER"在 snmpget输出中,但也可能显示为"string"、"Hex-string"、 "OID"等,具体取决于显示提示的存在。

步骤 2

Create a host 对应设备的SNMP接口。

为主机添加SNMP接口:

  • 输入IP地址/DNS名称和端口号

  • 从下拉菜单中选择SNMP version

  • 根据所选SNMP version添加接口凭据:

    • SNMPv1、v2仅需社区字符串(通常为'public')
    • SNMPv3需要更多特定选项(见下文)
  • 保持使用批量请求复选框勾选以启用批量操作

    processing of SNMP requests

SNMPv3参数 描述
Context name 输入上下文名称以标识SNMP子网上的监控项。
上下文名称自Zabbix 2.2起支持SNMPv3 监控项。
此字段支持用户宏解析。
Security name 输入安全名称。
此字段支持用户宏解析。
Security level 选择安全级别:
noAuthNoPriv - 不使用认证和加密协议
AuthNoPriv - 使用认证协议,不使用加密协议
AuthPriv - 同时使用认证和加密协议
Authentication protocol 选择认证协议 - MD5SHA1SHA224SHA256SHA384SHA512
Authentication passphrase 输入认证口令。
此字段支持用户宏解析。
Privacy protocol 选择加密协议 - DESAES128AES192AES256AES192C(思科)或AES256C(思科)。
注意:
- 某些旧系统可能不支持net-snmp的AES256;
- 某些新系统(如RHEL9)可能弃用net-snmp包对DES的支持。
Privacy passphrase 输入加密口令。
此字段支持用户宏解析。

当SNMPv3凭据(安全名称、认证协议/口令、加密协议)错误时:

  • Zabbix会收到net-snmp的ERROR响应,除非是加密口令错误时Zabbix会收到net-snmp的TIMEOUT错误;
  • (自Zabbix 6.0.13起)SNMP接口可用性将切换为红色(不可用)。

若更改认证协议认证口令加密协议加密口令时未修改安全名称, 则需手动清除server/proxy的缓存(通过运行中的-server)或 重启server/proxy后才会生效。若同时修改安全名称, 所有参数将立即更新。

可使用提供的SNMP模板(如Template SNMP Device等), 这些模板会自动添加一组监控项。但模板可能与主机不兼容。 点击添加保存主机。

步骤3

为监控创建一个监控项.

现在回到Zabbix,点击你之前创建的SNMP 主机的监控项。根据你在创建主机时是否使用了模板,你将看到与主机关联的SNMP 监控项列表或只是一个空列表。我们假设你将使用snmpwalk和snmpget收集的信息自行create 监控项,所以点击创建监控项。在新的监控项表单中:

  • 输入监控项名称

  • 将'类型'字段改为'SNMP agent'

  • 输入一个有意义的'Key'

  • 确保'主机 interface'字段中包含你的交换机/路由器

  • 将之前获取的文本或数字OID输入到'SNMP OID'字段,例如: .1.3.6.1.2.1.31.1.1.1.6.3

  • 将'Type of information'设置为Numeric (unsigned)

  • 如果需要不同于默认值,输入'Update interval'和'History storage'周期

  • Preprocessing标签页中,添加一个Change per second步骤

    (important, otherwise you will get cumulative values from the SNMP device instead of the latest change). Choose a custom multiplier if you want one.

所有必填字段都用红色星号标记。

现在保存监控项并前往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

批量处理的内部工作原理

Zabbix server和proxyquerySNMP设备 单个请求中的多个值。这会影响多种类型的SNMP 监控项:

  • 常规SNMP 监控项

  • SNMP 监控项 with dynamic indexes

  • SNMP [low-level discovery

    rules](/manual/discovery/low_level_discovery/examples/snmp_oids)

单个接口上所有具有相同参数的SNMP 监控项 计划在同一时间进行查询。前两种类型的监控项 由轮询器批量获取,每批最多128个监控项,而低级 发现规则将如之前一样单独处理。

在底层,执行的操作主要分为两类 查询数值:获取多个指定的objects并遍历OID tree.

对于"获取"操作,使用最多包含128个变量的GetRequest-PDU 对于"walking"操作,SNMPv1使用GetNextRequest-PDU而 使用"max-repetitions"字段值最大为128的GetBulkRequest进行 SNMPv2 和 SNMPv3.

因此,每种SNMP 监控项类型的批量处理优势在于 如下所述:

  • 常规SNMP 监控项受益于"获取"改进;
  • 具有动态索引的SNMP 监控项同时受益于"获取"和 "walking"改进:使用"getting"进行索引验证 "walking"用于构建缓存;
  • SNMP低级发现规则受益于"walking"改进。

然而,存在一个技术问题,即并非所有设备都具备此能力 每个请求返回128个值。其中一些总是返回正确的响应, 但其他设备要么返回"tooBig(1)"错误,要么根本不响应 一旦潜在响应超过某个限制。

为了找到给定情况下最佳的objects数量以query 设备,Zabbix采用以下策略。它首先谨慎地开始 在一个请求中查询1个值。如果成功,则queries 2 请求中的值。如果再次成功,它将queries 3个值 一个请求并继续类似地乘以查询的数量 objects 乘以 1.5,得到以下请求大小序列:1, 2, 3, 4, 6, 9, 13, 19, 28, 42, 63, 94, 128.

然而,一旦设备拒绝提供正确响应(例如, 对于42个变量,Zabbix会执行两项操作。

首先,对于当前的监控项批次,它将objects的数量减半 单次请求和queries 21个变量。如果设备处于活动状态,则 query在绝大多数情况下应该都能正常工作,因为28 已知可正常工作的变量数量远超过21个。 然而,如果仍然失败,Zabbix将回退到查询值 逐个尝试。如果此时仍然失败,则该设备 未响应且请求大小不是问题

Zabbix为后续的监控项批次所做的第二件事是开始 带有最后一次成功的变量数量(在我们的示例中为28)和 继续以1为增量递增请求大小,直到达到限制为止。对于 例如,假设最大响应大小为32个变量 后续请求的大小将为29、30、31、32和33。最后一个 请求将失败且Zabbix永远不会问题大小为33的请求 再次. 从那时起, Zabbix将最多query32个变量 此设备。

如果大型queries在此变量数量下失败,可能意味着以下情况之一 两件事。设备用于限制响应的确切标准 大小无法确定,但我们尝试通过数量来近似估算 变量。因此第一种可能性是这个变量数量 在一般情况下围绕设备的实际响应大小限制: 有时响应小于限制值,有时则超过限制值 那。第二种可能性是任一方向的UDP数据包 只是丢失了。因此,如果Zabbix收到一个失败的query,它 减少尝试get更深层次时的最大变量数 设备的舒适范围,但(从2.2.8版本开始)最多仅限两个 时间

在上面的示例中,如果包含32个变量的query恰好失败, Zabbix会将计数减少到31。如果这次也失败,Zabbix 将计数减少至30。然而,Zabbix不会减少计数 低于30,因为它会假定后续故障是由于UDP导致的 数据包丢失,而非设备限制。

然而,如果设备因其他原因无法正确处理批量请求 由于Zabbix的原因以及上述启发式方法失效 2.4 每个接口都有一个"使用批量请求"设置 允许禁用该设备的批量请求。