使用 Zabbix SNMP 模板监控 HPE ProLiant BL920 服务器：硬件健康、温度、电源与磁盘阵列全解析-平芜编程栈

指标监控
可观测性
告警
运维

【免费下载链接】zabbix

Real-time monitoring of IT components and services, such as networks, servers, VMs, applications and the cloud.

项目地址：https://gitcode.com/gh_mirrors/zabbix2/zabbix

本篇技术指南基于 Zabbix 官方随仓库发布的HPE ProLiant BL920 by SNMP模板（关联文档）展开，讲解如何通过 SNMP 对 HPE ProLiant BL920 刀片服务器（搭配 HP iLO 4 及以上管理固件）实现"零外部脚本"的硬件监控。读完本文，你将掌握该模板的适用前提、26 个可调宏、13 个基础监控项、7 个基础触发器，以及温度、电源、风扇、阵列控制器、物理/虚拟磁盘、网络适配器等 13 条低层发现（LLD）规则与对应原型触发器的工作原理与调优方法，可直接部署到生产环境。

模板概览：设计目标与适用前提

该模板由 Zabbix 官方维护，定位是开箱即用的服务器硬件监控方案，核心设计目标有两个：

纯 SNMP 采集：全部监控项基于 SNMP agent 轮询或 SNMP trap 采集，不依赖任何外部脚本，也不要求在服务器上安装 Zabbix agent。与仓库内其他 HPE 模板（如 hp_dl360_snmp、hp_dl380_snmp）一样遵循"模板即配置"的理念。
面向 iLO 4 及以上固件：模板面向 HPE ProLiant BL920 服务器，要求 iLO（Integrated Lights-Out）管理处理器版本为 4 及以上，由 iLO 通过 SNMP 暴露硬件健康数据。

版本要求方面，模板的zabbix_export声明版本为8.0，要求 Zabbix8.0 及以上版本；官方测试机型为 HPE ProLiant BL920。模板本体位于 template_server_hp_bl920_snmp.yaml，归属模板组Templates/Server hardware，带有class=hardware、subclass=server、target=hp、target=hp-bl920的标签，便于在 Zabbix 中检索与筛选。

模板在底层读取六张 MIB 表，全部对象都在 Compaq/HPE 私有企业子树（1.3.6.1.4.1.232）与标准 MIB 中：

MIB	用途	典型 OID
SNMPv2-MIB	系统名称、描述、位置、联系人与网络 uptime	`1.3.6.1.2.1.1.x`
HOST-RESOURCES-MIB	硬件 uptime	`1.3.6.1.2.1.25.1.1.0`
CPQSINFO-MIB	硬件型号、序列号	`1.3.6.1.4.1.232.2.2.*`
CPQHLTH-MIB	整体健康、温度、电源、风扇传感器	`1.3.6.1.4.1.232.6.*`
CPQIDA-MIB	阵列控制器、缓存、物理/虚拟磁盘	`1.3.6.1.4.1.232.3.*`
CPQNIC-MIB	物理网卡适配器状态	`1.3.6.1.4.1.232.18.*`

部署与接入：从导入到接入主机

Zabbix 应在 "Templates out of the box" 的通用指引下完成模板导入与主机配置（该模板以 YAML 形式随仓库提供，可直接导入 Zabbix 8.0）。接入步骤如下：

导入模板：在 Zabbix 前端Alerts → Actions之外的Data collection → Templates页面通过 "Import" 导入 template_server_hp_bl920_snmp.yaml，导入后模板出现在Templates/Server hardware组中。
服务器侧启用 SNMP：按照 HPE 官方文档在 iLO 中开启 SNMP 服务并配置读团体字符串（v1/v2c）或 v3 凭据。模板对服务器的前置依赖仅此一项——开启 SNMP 并保证 Zabbix Server/Proxy 可到达 iLO 的管理地址。
关联模板：在主机配置中将HPE ProLiant BL920 by SNMP关联到对应主机，并在 SNMP 接口中填入 iLO 地址与团体字符串。
验证采集：接入后观察SNMP agent availability（键zabbix[host,snmp,available]）是否变为 available，随后检查Overall system health status等监控项是否有值。

模板已内置SNMP traps (fallback)监控项（键snmptrap.fallback），用于接收未被其他 snmptrap 项匹配到的全部 SNMP trap，确保 iLO 主动上送的告警事件不会遗漏。

宏体系：26 个阈值宏的语义与默认值

模板通过宏参数化所有触发阈值，便于不修改表达式即可适配不同机房的告警策略。全部宏以{$HEALTH.STATUS.*}、{$PSU.STATUS.*}、{$FAN.STATUS.*}、{$DISK.*}、{$VDISK.*}、{$SNMP.*}命名空间组织，完整清单如下：

宏	说明	默认值
`{$HEALTH.STATUS.CRIT}`	整体健康状态的严重阈值	`4`
`{$HEALTH.STATUS.WARN}`	整体健康状态的警告阈值	`3`
`{$PSU.STATUS.CRIT}`	电源传感器严重阈值	`4`
`{$PSU.STATUS.WARN}`	电源传感器警告阈值	`3`
`{$FAN.STATUS.CRIT}`	风扇传感器严重阈值	`4`
`{$FAN.STATUS.WARN}`	风扇传感器警告阈值	`3`
`{$DISK.ARRAY.STATUS.CRIT}`	磁盘阵列严重状态	`4`
`{$DISK.ARRAY.STATUS.WARN}`	磁盘阵列警告状态	`3`
`{$DISK.ARRAY.CACHE.STATUS.CRIT:"cacheModCriticalFailure"}`	阵列缓存严重状态（critical failure）	`8`
`{$DISK.ARRAY.CACHE.STATUS.WARN:"invalid"}`	阵列缓存警告状态（无效）	`2`
`{$DISK.ARRAY.CACHE.STATUS.WARN:"cacheModDegradedFailsafeSpeed"}`	阵列缓存警告状态（降速失效保护模式）	`7`
`{$DISK.ARRAY.CACHE.STATUS.WARN:"cacheReadCacheNotMapped"}`	阵列缓存警告状态（读缓存无法映射）	`9`
`{$DISK.ARRAY.CACHE.STATUS.WARN:"cacheModFlashMemNotAttached"}`	阵列缓存警告状态（Flash 内存未挂载）	`6`
`{$DISK.ARRAY.CACHE.STATUS.OK:"enabled"}`	阵列缓存正常状态	`3`
`{$DISK.ARRAY.CACHE.BATTERY.STATUS.CRIT:"failed"}`	缓存电池严重状态（失效）	`4`
`{$DISK.ARRAY.CACHE.BATTERY.STATUS.CRIT:"capacitorFailed"}`	缓存电池严重状态（电容失效）	`7`
`{$DISK.ARRAY.CACHE.BATTERY.STATUS.WARN:"degraded"}`	缓存电池警告状态（降级）	`5`
`{$DISK.ARRAY.CACHE.BATTERY.STATUS.WARN:"notPresent"}`	缓存电池警告状态（不存在）	`6`
`{$VDISK.STATUS.CRIT}`	虚拟磁盘严重状态	`3`
`{$VDISK.STATUS.OK}`	虚拟磁盘正常状态	`2`
`{$DISK.STATUS.WARN}`	物理磁盘警告状态	`4`
`{$DISK.STATUS.FAIL}`	物理磁盘严重（失败）状态	`3`
`{$DISK.SMART.STATUS.FAIL:"replaceDrive"}`	S.M.A.R.T. 严重状态（需更换）	`3`
`{$DISK.SMART.STATUS.FAIL:"replaceDriveSSDWearOut"}`	S.M.A.R.T. 严重状态（SSD 磨损）	`4`
`{$SNMP.TIMEOUT}`	SNMP agent 可用性判断窗口	`5m`
`{$SNMP.UPTIME.WARN}`	"主机重启"问题自动恢复的 uptime 阈值	`10m`

从 YAML 宏配置可见，带上下文标签的宏（如{$DISK.ARRAY.CACHE.STATUS.CRIT:"cacheModCriticalFailure"}）会通过上下文匹配 CPQIDA-MIB 值映射后的字符串状态，其余为纯数字比较。所有数值型宏在 YAML 中都通过正则^-?([0-9]+|(([0-9]+)\.([0-9]+)))$约束为数字，避免误填导致表达式失效。

基础监控项与触发器：13 项 + 7 触发

模板不依赖 LLD 的基础监控项覆盖系统身份、健康总览与可用性：

监控项	键	数据来源	关键预处理
Overall system health status	`hp.server.status[cpqHeMibCondition]`	CPQHLTH-MIB`cpqHeMibCondition`（OID`1.3.6.1.4.1.232.6.1.3.0`）	6h 心跳去重
Hardware model name	`hp.server.hw.model[cpqSiProductName]`	CPQSINFO-MIB	6h 心跳去重，回写资产 MODEL
Hardware serial number	`hp.server.hw.serialnumber[cpqSiSysSerialNum]`	CPQSINFO-MIB	6h 心跳去重，回写资产 SERIALNO_A
System temperature status	`hp.server.sensor.temp.status[cpqHeThermalCondition]`	CPQHLTH-MIB	6h 心跳去重
Uptime (network)	`hp.server.net.uptime[sysUpTime]`	SNMPv2-MIB`sysUpTime`	乘数 0.01（百分秒→秒）
Uptime (hardware)	`hp.server.hw.uptime[hrSystemUptime]`	HOST-RESOURCES-MIB	不支持值置 0；乘数 0.01
System location	`hp.server.location[sysLocation]`	SNMPv2-MIB	6h 心跳去重，回写资产 LOCATION
System contact details	`hp.server.contact[sysContact]`	SNMPv2-MIB	1d 心跳去重，回写资产 CONTACT
System object ID	`hp.server.objectid[sysObjectID]`	SNMPv2-MIB	6h 心跳去重
System name	`hp.server.name[sysName]`	SNMPv2-MIB	6h 心跳去重，回写资产 NAME
System description	`hp.server.descr[sysDescr]`	SNMPv2-MIB	1d 心跳去重
SNMP traps (fallback)	`snmptrap.fallback`	SNMP trap	—
SNMP agent availability	`zabbix[host,snmp,available]`	Zabbix 内部	—

其中多个身份类监控项通过inventory_link自动回写主机资产字段（型号、序列号、位置、联系人、名称），省去手工维护资产信息的成本。

基础触发器共 7 个，覆盖三类告警场景：

健康告警：System status is in critical state（High，cpqHeMibCondition={$HEALTH.STATUS.CRIT}）与System status is in warning state（Warning，依赖前者）。
变更告警（Info，需手动确认）：
- Device has been replaced：序列号发生变化且新序列号非空；
- System name has changed：系统名变化；
重启与可用性：
- Host has been restarted（Warning）：uptime 计数器下降即判定重启，并通过对 32 位 SNMP 计数上限（2^32 百分秒 ≈ 497 天）的边界判断排除计数器回绕误报；恢复表达式为 uptime 超过{$SNMP.UPTIME.WARN}自动恢复，无需手动关闭；
- No SNMP data collection（Warning）：max(zabbix[host,snmp,available],{$SNMP.TIMEOUT})=0，即连续{$SNMP.TIMEOUT}（默认 5 分钟）内 SNMP 不可达。

LLD 体系：13 条发现规则与原型监控项

模板的核心价值在于低层发现（LLD）：服务器实际安装的传感器、电源、风扇、磁盘与网卡数量未知，模板通过 13 条发现规则动态枚举并生成对应监控项，拓扑变更（换盘、加内存、拔风扇）无需人工改配置。

温度发现：7 条规则分治传感器位置

温度传感器由CPQHLTH-MIB::cpqHeTemperatureTable（OID 前缀1.3.6.1.4.1.232.6.2.6.8.1）驱动，模板按cpqHeTemperatureLocale值拆分出 7 条发现规则：

发现规则	键	过滤条件（SENSOR_LOCALE）
Temperature discovery	`temp.discovery`	4\|8\|9\|12\|13（systemBoard/storage/removableMedia/chassis/bridgeCard）
Temperature ambient discovery	`temp.ambient.discovery`	ambient(11) 且索引匹配`0.1`
Temperature CPU discovery	`temp.cpu.discovery`	cpu(6)
Temperature memory discovery	`temp.memory.discovery`	memory(7)
Temperature PSU discovery	`temp.psu.discovery`	powerSupply(10)
Temperature I/O discovery	`temp.io.discovery`	ioBoard(5)
Temperature system discovery	`temp.system.discovery`	system(3)

{#SENSOR_LOCALE}与温度传感器位置数值的对应关系由值映射CPQHLTH-MIB::cpqHeTemperatureLocale定义：1=other、2=unknown、3=system、4=systemBoard、5=ioBoard、6=cpu、7=memory、8=storage、9=removableMedia、10=powerSupply、11=ambient、12=chassis、13=bridgeCard。

每个温度原型组包含两个原型监控项：

温度值：hp.server.sensor.temp.value[cpqHeTemperatureCelsius.<位置>.#{SNMPINDEX}]，单位 °C（FLOAT），如 CPU 传感器键为hp.server.sensor.temp.value[cpqHeTemperatureCelsius.CPU.{#SNMPINDEX}]；I/O 与 ambient 因索引含特殊字符，键中对应段使用引号包裹（如"I/O.{#SNMPINDEX}"）；
传感器状态：hp.server.sensor.temp.condition[...]，值映射为CPQHLTH-MIB::cpqHeTemperatureCondition：1=other、2=ok、3=degraded、4=failed。

每个传感器状态原型自动生成 3 个触发器：

= 1（other）：Info，"Temperature could not be determined"，需手动关闭；
= 3（degraded）：Warning，"温度超出正常工作范围"。注意 MIB 语义：若cpqHeThermalDegradedAction设为 shutdown(3)，degraded 状态会直接触发系统关机；
= 4（failed）：High，"检测到可能永久损坏系统的状态"。同样注意：MIB 语义下 failed 会导致系统自动关机，因此实际能采到该值的概率很低。

电源与风扇发现

PSU discovery（键psu.discovery）：枚举CPQHLTH-MIB::cpqHeFltTolPowerSupplyStatus表，原型监控项hp.server.sensor.psu.status[cpqHeFltTolPowerSupplyCondition.{#SNMPINDEX}]，命名含{#CHASSIS_NUM}/{#BAY_NUM}上下文（如 "Chassis 1, bay 2"）。PSU 状态语义：1=other、2=ok、3=degraded（组件超范围）、4=failed（可能永久损坏）。两个原型触发器分别为 critical（Average）与 warning（Warning，依赖前者）。
FAN discovery（键fan.discovery）：枚举CPQHLTH-MIB::cpqHeFltTolFanCondition，原型hp.server.sensor.fan.status[cpqHeFltTolFanCondition.{#SNMPINDEX}]。注意 README 中 MIB 原文的表述：ok(2)表示风扇正常，冗余风扇故障归入 degraded、非冗余风扇故障归入 failed(4)。原型触发器 critical（Average）与 warning（Warning，依赖前者）。

磁盘阵列：控制器、缓存、物理盘、虚拟盘四层结构

存储监控完全基于 CPQIDA-MIB，呈四层递进结构：

Array controller discovery（array.discovery）：枚举cpqDaCntlrTable，原型包含控制器状态hp.server.hw.diskarray.status[cpqDaCntlrCondition.{#SNMPINDEX}]（代表控制器及关联逻辑盘、物理盘、加速器的整体状况）与型号hp.server.hw.diskarray.model[cpqDaCntlrModel.{#SNMPINDEX}]（值映射含从ida到sa-p840ar、p408i-sb等 100 余种控制器型号文本）。触发器：critical（High）/ warning（Average）。
Array controller cache discovery（array.cache.discovery）：枚举cpqDaAccelTable，两个原型监控项：
- 缓存状态hp.server.hw.diskarray.cache.status[cpqDaAccelStatus.{#SNMPINDEX}]，值映射CPQIDA-MIB::cpqDaAccelStatus：1=other、2=invalid（未安装/未配置）、3=enabled（至少一个逻辑盘启用缓存）、4=tmpDisabled、5=permDisabled、6=cacheModFlashMemNotAttached、7=cacheModDegradedFailsafeSpeed、8=cacheModCriticalFailure（控制器已进入 Zero Memory RAID 模式）、9=cacheReadCacheNotMapped；
- 缓存电池状态hp.server.hw.diskarray.cache.battery.status[cpqDaAccelBattery.{#SNMPINDEX}]，值映射CPQIDA-MIB::cpqDaAccelBattery：1=Other、2=Ok（充满）、3=Recharging（充电期间写缓存等操作暂停，充满自动恢复）、4=Failed（36 小时未充上电，需维修）、5=Degraded、6=Not Present、7=Capacitor failed（电容 10 分钟未充上电）。
缓存原型触发器共 5 个：critical 匹配cacheModCriticalFailure（Average）；warning 匹配cacheModDegradedFailsafeSpeed/cacheReadCacheNotMapped/cacheModFlashMemNotAttached任一（Warning）；"not in optimal state" 在状态既非enabled也非invalid时告警（Warning）；电池 critical（Average）与电池 warning（Warning，依赖前者）。
Physical disk discovery（physicaldisk.discovery）：枚举cpqDaPhyDrvTable，6 个原型监控项：
- 状态cpqDaPhyDrvStatus：1=other、2=ok、3=failed、4=predictiveFailure；
- S.M.A.R.T. 状态cpqDaPhyDrvSmartStatus：1=other、2=ok、3=replaceDrive、4=replaceDriveSSDWearOut；
- 序列号cpqDaPhyDrvSerialNum（用于换盘检测）、型号cpqDaPhyDrvModel、介质类型cpqDaPhyDrvMediaType（1=Other、2=rotatingPlatters、3=solidState）、容量（单位 MB，预处理乘数 1048576 换算为字节）。
触发器 4 个：Physical disk failed（High）、warning（Warning，依赖 failed）、S.M.A.R.T. failed（High，匹配 replaceDrive 或 replaceDriveSSDWearOut，依赖 failed）、Disk has been replaced（Info，序列号变化且新序列号非空，需手动关闭）。
Virtual disk discovery（virtualdisk.discovery）：枚举cpqDaLogDrvTable，3 个原型：状态cpqDaLogDrvStatus（值映射含 ok/failed/recovering/rebuilding/expanding/erasing 等 25 种状态文本，2=ok、3=failed）、布局类型cpqDaLogDrvFaultTol（值映射为2=none、3=RAID-1/RAID-10、5=RAID-5、6…7=RAID-6、8=RAID-50、9=RAID-60、10=RAID-1 ADM、11=RAID-10 ADM等 RAID 级别文本）、容量（乘数 1048576 换算字节）。触发器 2 个：Virtual disk failed（High）与Virtual disk is not in OK state（Warning，依赖前者）。

网络接口发现

Network interface discovery（键net.if.discovery）：枚举CPQNIC-MIB::cpqNicIfPhysAdapterTable，原型hp.server.net.if.status[cpqNicIfPhysAdapterStatus.{#SNMPINDEX}]，命名含{#ADAPTER_NAME}/{#ADAPTER_INDEX}。状态值映射CPQNIC-MIB::cpqNicIfPhysAdapterStatus：1=unknown、2=ok、3=generalFailure、4=linkFailure。触发器 2 个：Adapter has failed（High，状态=3）与Adapter has lost link（Average，状态=4，依赖前者）。

预处理机制：降低采集负载的三件套

模板几乎所有监控项都配置了预处理，目的是在 iLO 上减少轮询压力、降低数据库写入量：

Discard unchanged with heartbeat（心跳去重）：大多数监控项配置6h（System description/System contact details为1d）。SNMP 每轮仍会轮询，但若值与上次一致则不入库，只有值变化或超过心跳时长（6 小时/1 天）才强制入库一次，保证图形与趋势数据连续性的同时显著压缩存储。
Custom multiplier（乘数）：sysUpTime/hrSystemUptime的原始单位是百分秒，乘数0.01换算为秒；物理盘与虚拟盘容量单位是 MB，乘数1048576（2^20）换算为字节。
Check for not supported value（不支持值检查）：Uptime (hardware)在取不到硬件 uptime 时通过Custom on fail: Set value to: 0兜底，避免监控项直接进入 not supported 状态导致图形断档。

告警依赖与运维建议

模板触发器大量使用依赖（dependencies）构建告警收敛树：warning 级触发器总是依赖同源的 critical 级触发器，例如温度 warning 依赖温度 critical、PSU warning 依赖 PSU critical、物理盘 warning 依赖物理盘 failed。当严重问题发生时，只上报最高严重级别的问题，避免同一根因产生告警风暴。在 Zabbix 问题界面中，次级问题会以"已依赖"状态被抑制。

生产环境调优建议：

阈值按机房环境调整：机柜进风温度、冗余电源策略不同的机房，可在主机级或模板级覆盖{$PSU.STATUS.*}、{$FAN.STATUS.*}、{$DISK.*}宏，而无需改动触发器表达式。
延长可用性判断：网络抖动频繁的环境可调大{$SNMP.TIMEOUT}（默认 5m），避免瞬时断连产生噪音告警。
理解 MIB 语义再改阈值：温度 failed(4) 与 PSU failed(4) 的 MIB 语义是"可能永久损坏系统"，此时 iLO 往往已触发自动关机保护，告警更多用于事后审计；真正的日常预警应关注 degraded(3) 状态。
换盘/换机检测：Device has been replaced、Disk has been replaced、System name has changed均为 Info 级且需手动确认（manual close），用于资产变更审计，不应直接静默。

反馈渠道

模板使用中如发现问题，可通过 Zabbix 官方支持站点（support.zabbix.com）提交 issue，或在 Zabbix 官方社区论坛的模板建议与反馈板块（Suggestions and Feedback）进行讨论、分享调优经验。仓库内其余 HPE 服务器模板（hp_bl460_snmp、hp_dl360_snmp、hp_dl380_snmp）结构与本模板一致，本文的宏体系、LLD 分层与预处理思路可平滑迁移到这些同类模板上。