您可能需要在打印机、网络交换机、路由器或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设备非常有用。
在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 string(或OID)。
要get SNMP字符串列表,请使用snmpwalk命令(属于 net-snmp软件,您应该已在 Zabbix安装过程中安装)或等效工具:
由于此处的'2c'代表SNMP version,您也可以将其替换为 '1',以表示设备上的SNMP版本1。
这将为您提供SNMP字符串及其最新值的列表。如果 没有,则可能是SNMP 'community'与标准'public'不同, 在这种情况下,您需要找出它是什么。
然后您可以浏览列表,直到找到要监控的string,例如, 如果您想监控交换机端口3上的传入字节,您将使用 此行中的IF-MIB::ifHCInOctets.3
string:
您现在可以使用snmpget命令查找 'IF-MIB::ifHCInOctets.3'的数字OID:
请注意,string中的最后一个数字是您要 监控的端口号。另请参阅:Dynamic indexes。
这将为您提供类似以下内容:
同样,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"等,具体取决于显示提示的存在。
Create a host 对应设备的SNMP接口。
为主机添加SNMP接口:
输入IP地址/DNS名称和端口号
从下拉菜单中选择SNMP version
根据所选SNMP version添加接口凭据:
保持使用批量请求复选框勾选以启用批量操作
processing of SNMP requests
SNMPv3参数 | 描述 |
---|---|
Context name | 输入上下文名称以标识SNMP子网上的监控项。 上下文名称自Zabbix 2.2起支持SNMPv3 监控项。 此字段支持用户宏解析。 |
Security name | 输入安全名称。 此字段支持用户宏解析。 |
Security level | 选择安全级别: noAuthNoPriv - 不使用认证和加密协议 AuthNoPriv - 使用认证协议,不使用加密协议 AuthPriv - 同时使用认证和加密协议 |
Authentication protocol | 选择认证协议 - MD5、SHA1、SHA224、SHA256、SHA384或SHA512。 |
Authentication passphrase | 输入认证口令。 此字段支持用户宏解析。 |
Privacy protocol | 选择加密协议 - DES、AES128、AES192、AES256、AES192C(思科)或AES256C(思科)。 注意: - 某些旧系统可能不支持net-snmp的AES256; - 某些新系统(如RHEL9)可能弃用net-snmp包对DES的支持。 |
Privacy passphrase | 输入加密口令。 此字段支持用户宏解析。 |
当SNMPv3凭据(安全名称、认证协议/口令、加密协议)错误时:
若更改认证协议、 认证口令、加密协议或加密口令时未修改安全名称, 则需手动清除server/proxy的缓存(通过运行中的-server)或 重启server/proxy后才会生效。若同时修改安全名称, 所有参数将立即更新。
可使用提供的SNMP模板(如Template SNMP Device等), 这些模板会自动添加一组监控项。但模板可能与主机不兼容。 点击添加保存主机。
为监控创建一个监控项.
现在回到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数据!
通用示例:
参数 | 描述 |
---|---|
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
运行时间监控:
参数 | 描述 |
---|---|
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 监控项类型的批量处理优势在于 如下所述:
然而,存在一个技术问题,即并非所有设备都具备此能力 每个请求返回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 每个接口都有一个"使用批量请求"设置 允许禁用该设备的批量请求。