[comment]: # translation:outdated [comment]: # ({0895dff3-0895dff3}) # 2 SNMP agent [comment]: # (tags: snmp) [comment]: # ({/0895dff3-0895dff3}) [comment]: # ({afba29a9-f312fc02}) #### 概述 您可能需要在打印机、网络交换机、路由器或UPS等设备上使用SNMP监控，这些设备通常支持SNMP协议，且在这些设备上尝试安装完整的操作系统和Zabbix agents是不切实际的。 为了能够从这些设备获取SNMP agents提供的数据，必须通过指定`--with-net-snmp` flag来[4-配置源代码](/manual/installation/install#4-配置源代码)支持SNMP的Zabbix server。 SNMP检查仅通过UDP协议执行。 Zabbix server和proxy守护进程通过单次请求query多个SNMP设备的值。这会影响所有类型的SNMP 监控项（常规SNMP 监控项、带动态索引的SNMP 监控项以及SNMP低级发现），并应使SNMP处理更加高效。有关其内部工作原理的技术细节，请参阅[批量处理](#internal-workings-of-bulk-processing)部分。对于无法正确处理批量请求的设备，可以通过每个接口的"使用批量请求"设置来禁用此功能。 如果Zabbix server和proxy守护进程收到不正确的SNMP响应，它们会记录类似以下的行： SNMP response from host "gateway" does not contain all of the requested variable bindings 虽然这些日志不能涵盖所有问题情况，但对于识别应禁用批量请求的个别SNMP设备非常有用。 在query尝试失败后，Zabbix server/proxy将始终至少重试一次：通过SNMP库的重试机制或内部的[批量处理](#internal-workings-of-bulk-processing)机制。 ::: notewarning 如果监控SNMPv3设备，请确保msgAuthoritativeEngineID（也称为snmpEngineID或"引擎ID"）永远不会被两个设备共享。根据[RFC 2571](http://www.ietf.org/rfc/rfc2571.txt)（第3.1.1.1节），每个设备的引擎ID必须是唯一的。 ::: ::: notewarning RFC3414要求SNMPv3设备持久化其engineBoots。某些设备未遵守此要求，导致重启后其SNMP消息因过期而被丢弃。在这种情况下，需要在server/proxy上手动清除SNMP缓存（通过使用[运行时控制](/manual/concepts/server#运行时控制)），或者需要重启server/proxy。 ::: [comment]: # ({/afba29a9-f312fc02}) [comment]: # ({cac544a8-cac544a8}) #### 配置 SNMP 监控 要通过SNMP监控设备，需执行以下步骤： [comment]: # ({/cac544a8-cac544a8}) [comment]: # ({59be3ff2-501ff4eb}) ##### 步骤1 找出您要监控的监控项的SNMP string（或OID）。 要get SNMP字符串列表，请使用**snmpwalk**命令（属于 [net-snmp](http://www.net-snmp.org/)软件，您应该已在 Zabbix安装过程中安装）或等效工具： snmpwalk -v 2c -c public . 由于此处的'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 IF-MIB::ifHCInOctets.3 请注意，string中的最后一个数字是您要 监控的端口号。另请参阅：[Dynamic indexes](/manual/config/items/itemtypes/snmp/dynamicindex)。 这将为您提供类似以下内容： .1.3.6.1.2.1.31.1.1.1.6.3 = Counter64: 3472126941 同样，OID中的最后一个数字是端口号。 ::: notetip 一些最常用的SNMP OID由Zabbix [translated automatically to a numeric representation](/manual/config/items/itemtypes/snmp/special_mibs)。 ::: 在上面的最后一个示例中，值类型为"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"等，具体取决于显示提示的存在。 [comment]: # ({/59be3ff2-501ff4eb}) [comment]: # ({5361495b-929235a8}) ##### 步骤 2 [Create a host](/manual/config/hosts/host) 对应设备的SNMP接口。 ![](../../../../../assets/en/manual/config/items/itemtypes/snmp/snmp_host.png) 为主机添加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* | 选择认证协议 - *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凭据（安全名称、认证协议/口令、加密协议）错误时： - Zabbix会收到net-snmp的ERROR响应，除非是*加密口令*错误时Zabbix会收到net-snmp的TIMEOUT错误； - （自Zabbix 6.0.13起）SNMP接口可用性将切换为红色（不可用）。 ::: notewarning 若更改*认证协议*、 *认证口令*、*加密协议*或*加密口令*时未修改*安全名称*， 则需手动清除server/proxy的缓存（通过[运行中的-server](/manual/concepts/server#运行中的-server)）或 重启server/proxy后才会生效。若同时修改*安全名称*， 所有参数将立即更新。 ::: 可使用提供的SNMP模板（如*Template SNMP Device*等）， 这些模板会自动添加一组监控项。但模板可能与主机不兼容。 点击*添加*保存主机。 [comment]: # ({/5361495b-929235a8}) [comment]: # ({dc981b60-290ebad1}) ##### 步骤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. ![](../../../../../assets/en/manual/config/items/itemtypes/snmp_item.png) 所有必填字段都用红色星号标记。 现在保存监控项并前往*Monitoring* > *Latest data*查看你的SNMP数据! [comment]: # ({/dc981b60-290ebad1}) [comment]: # ({de096def-6021e1bd}) ##### 示例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 [comment]: # ({/de096def-6021e1bd}) [comment]: # ({6a3e4710-45af5cf0}) ##### 示例2 运行时间监控: | 参数 | 描述 | |--|--------| | **OID** | MIB::sysUpTime.0 | | **Key** | router.uptime | | **Value type** | float | | **Units** | uptime | | **Preprocessing step: Custom multiplier** | 0.01 | [comment]: # ({/6a3e4710-45af5cf0}) [comment]: # ({a39f60d5-c57b8645}) #### 批量处理的内部工作原理 Zabbix server和proxyquerySNMP设备 单个请求中的多个值。这会影响多种类型的SNMP 监控项: - 常规SNMP 监控项 - SNMP 监控项 [with dynamic indexes](/manual/config/items/itemtypes/snmp/dynamicindex) - 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 每个接口都有一个"使用批量请求"设置 允许禁用该设备的批量请求。 [comment]: # ({/a39f60d5-c57b8645})