Ceph SNMP 监控告警集成指南：CEPH-MIB 结构、OID 映射与 Prometheus/Alertmanager 网关配置-港品优选

Ceph SNMP 监控告警集成指南：CEPH-MIB 结构、OID 映射与 Prometheus/Alertmanager 网关配置

【免费下载链接】cephCeph is a distributed object, block, and file storage platform项目地址: https://gitcode.com/gh_mirrors/ce/ceph

Ceph 本身并不提供 SNMP agent 功能，因此本仓库通过一份纯告警（NOTIFICATION-only）的 MIB 文件monitoring/snmp/CEPH-MIB.txt，将 Prometheus 告警规则与 SNMP Trap 体系对接起来：任何定义为 critical 的告警规则都会在 CEPH-MIB 中拥有一个对应的 OID，再由 Alertmanager 的 webhook 转发给外部 SNMP 网关，最终把 Ceph 集群健康状态以 SNMP Trap 形式送达传统网管平台（NMS）。读完本文，你将掌握如何用snmptranslate查询 CEPH-MIB 的 OID、理解1.3.6.1.4.1.50495企业 OID 树下的分类结构、了解告警规则与 OID 的对应关系，并能搭建起一套可用的 Ceph → Prometheus → Alertmanager → SNMP 网关的告警链路。

CEPH-MIB 概览：纯 Notification 实现

仓库中的 MIB 定义文件位于 monitoring/snmp/CEPH-MIB.txt，配套说明文档为 monitoring/snmp/README.md。MIB 模块在文件头部通过MODULE-IDENTITY声明，企业号（enterprise）为50495：

ceph MODULE-IDENTITY LAST-UPDATED "202111010000Z" ORGANIZATION "The Ceph Project" CONTACT-INFO "Email: <dev@ceph.io>" DESCRIPTION "The MIB module for Ceph. In it's current form it only supports Notifications, since Ceph itself doesn't provide any SNMP agent functionality. Notifications are provided through a Prometheus/Alertmanager webhook passing alerts to an external gateway service that is responsible for formatting, forwarding and authenticating to the SNMP receiver." ::= { enterprises 50495 }

关键事实（均可从 MIB 源码确认）：

纯告警 MIB：CEPH-MIB 只定义NOTIFICATION-TYPE，不定义OBJECT-TYPE。原因在文档中写得很清楚——Ceph 没有内置 SNMP agent，无法主动响应snmpget/snmpwalk，因此所有信息都以 Trap/Notification 的形式单向推送。
版本演进：从 MIB 的REVISION注释可以看出，2021-11-01 版本做了多项重构：MIB 结构对齐smilint检查、精简并缩短了命名、因切换到 snmp_notifier 网关而移除了对象定义并更新了通知定义、增加了MODULE-COMPLIANCE合规声明，并同步了最新的 Prometheus 告警规则。
lint 说明：MIB 头部保留了smilint -l 6 -i notification-not-reversible ./CEPH-MIB.txt的检查记录，并注明忽略notification-not-reversible警告，因为所使用的 SNMP 网关不依赖 SNMPv1 语义。

查看 MIB 中的 OID：snmptranslate 用法

要列出 CEPH-MIB 支持的 OID，使用snmptranslate命令，该命令来自net-snmp-utils软件包：

snmptranslate -Pu -Tz -M ~/git/ceph/monitoring/snmp:/usr/share/snmp/mibs -m CEPH-MIB

参数含义：

参数	作用
`-Pu`	只打印未解析/未加载的对象（配合`-Tz`输出完整树）
`-Tz`	以树状形式打印 MIB 中的所有 OID
`-M <path>`	指定 MIB 搜索路径，冒号分隔多个目录；这里将仓库的`monitoring/snmp`目录与系统 MIB 目录组合
`-m CEPH-MIB`	只加载指定的 MIB 模块，避免加载系统全部 MIB

这一命令组合也被仓库的自动化测试直接复用：在 monitoring/ceph-mixin/tests_alerts/validate_rules.py 中，校验逻辑会执行snmptranslate -Pu -Tz -M ../../snmp:/usr/share/snmp/mibs -m CEPH-MIB，用解析出的 OID 列表反向核对每条 Prometheus 规则中声明的 OID 是否真实存在于 MIB 文件中。若系统未安装snmptranslate，测试会提示 “snmptranslate missing, unable to cross check”，跳过交叉校验但其余检查照常执行。

OID 树结构：Ceph 通知的分类体系

CEPH-MIB 的 OID 全部挂在企业号 50495 之下，其主干结构（来自 monitoring/snmp/CEPH-MIB.txt 中的OBJECT IDENTIFIER定义）如下：

internet private enterprise ceph ceph Notifications Prometheus Notification org cluster (alerts) source Category 1.3.6.1 .4 .1 .50495 .1 .2 .1 .2 (Ceph Health) .3 (MON) .4 (OSD) .5 (MDS) .6 (MGR) .7 (PGs) .8 (Nodes) .9 (Pools) .10 (Rados) .11 (cephadm) .12 (prometheus) .13 (hardware)

对应到 MIB 源码中的OBJECT IDENTIFIER定义，可以精确还原完整分支：

OID 前缀	标识符	含义
`1.3.6.1.4.1.50495.1`	`cephCluster`	Ceph 集群分支
`1.3.6.1.4.1.50495.1.1`	`cephMetadata`	元数据占位分支（注释说明：为未来可能的 agent 扩展预留，用于提供集群配置概览）
`1.3.6.1.4.1.50495.1.2`	`cephNotifications`	通知分支
`1.3.6.1.4.1.50495.1.2.1`	`prometheus`	通知来源：Prometheus
`1.3.6.1.4.1.50495.1.2.1.1`	`promGeneric`	通用告警
`1.3.6.1.4.1.50495.1.2.1.2`	`promHealthStatus`	集群健康状态
`1.3.6.1.4.1.50495.1.2.1.3`	`promMon`	MON 监控
`1.3.6.1.4.1.50495.1.2.1.4`	`promOsd`	OSD 监控
`1.3.6.1.4.1.50495.1.2.1.5`	`promMds`	MDS/CephFS 监控
`1.3.6.1.4.1.50495.1.2.1.6`	`promMgr`	MGR 监控
`1.3.6.1.4.1.50495.1.2.1.7`	`promPGs`	PG 状态
`1.3.6.1.4.1.50495.1.2.1.8`	`promNode`	节点监控
`1.3.6.1.4.1.50495.1.2.1.9`	`promPool`	存储池监控
`1.3.6.1.4.1.50495.1.2.1.10`	`promRados`	RADOS 层监控
`1.3.6.1.4.1.50495.1.2.1.11`	`promCephadm`	cephadm 编排
`1.3.6.1.4.1.50495.1.2.1.12`	`promPrometheus`	Prometheus 自身
`1.3.6.1.4.1.50495.1.2.1.14`	`promNVMeGateway`	NVMe 网关
`1.3.6.1.4.1.50495.2.1`	`cephAlertGroups`	合规分组（Conformance）
`1.3.6.1.4.1.50495.2.2`	`cephCompliances`	合规声明（Compliance）

使用规则非常直观：每条告警按类别放入对应的告警分支。例如，要表达一个 MGR 相关的问题通知，就使用1.3.6.1.4.1.50495.1.2.1.6.x这个 OID。

完整的 Notification 清单与告警映射

MIB 中每一条NOTIFICATION-TYPE都对应一条具体的 Prometheus 告警语义。以下是 monitoring/snmp/CEPH-MIB.txt 中定义的完整通知清单：

Generic（通用，分支 .1）

OID	通知名	触发条件
`…1.1.1`	`promGenericNotification`	通用告警：当 Prometheus 规则未提供 OID 时发出
`…1.1.2`	`promGenericDaemonCrash`	一个或多个守护进程近期崩溃且尚未归档

Ceph Health（健康状态，分支 .2）

OID	通知名	触发条件
`…1.2.1`	`promHealthStatusError`	集群长时间处于`health_error`状态
`…1.2.2`	`promHealthStatusWarning`	集群长时间处于`health_warn`状态

MON（分支 .3）

OID	通知名	触发条件
`…1.3.1`	`promMonLowQuorum`	进入 quorum 的 monitor 数量偏低，法定人数告急
`…1.3.2`	`promMonDiskSpaceCritical`	monitor 磁盘空间严重不足

OSD（分支 .4）

OID	通知名	触发条件
`…1.4.1`	`promOsdDownHigh`	大量 OSD 处于 down 状态（超过 10%）
`…1.4.2`	`promOsdDown`	一个或多个 OSD 处于 down 状态
`…1.4.3`	`promOsdNearFull`	OSD 即将写满（NEARFULL）
`…1.4.4`	`promOsdFlapping`	OSD 在 5 分钟内每分钟至少被标记 down/up 一次（抖动）
`…1.4.5`	`promOsdHighPgDeviation`	某 OSD 的 PG 数量偏离平均值超过 30%
`…1.4.6`	`promOsdFull`	OSD 达到 FULL 阈值，写入被阻塞
`…1.4.7`	`promOsdHighPredictedFailures`	预测将失败的设备过多，正常自愈无法应对
`…1.4.8`	`promOsdHostDown`	OSD 所在宿主机宕机

MDS / CephFS（分支 .5）

OID	通知名	触发条件
`…1.5.1`	`promMdsDamaged`	CephFS 文件系统损坏
`…1.5.2`	`promMdsReadOnly`	文件系统被标记为 READ-ONLY
`…1.5.3`	`promMdsOffline`	文件系统不可用/离线（所有 MDS rank 均不可用）
`…1.5.4`	`promMdsDegraded`	文件系统处于降级状态
`…1.5.5`	`promMdsNoStandby`	MDS 守护进程失败且无备用（standby）可用

MGR（分支 .6）

OID	通知名	触发条件
`…1.6.1`	`promMgrModuleCrash`	mgr 模块近期崩溃
`…1.6.2`	`promMgrPrometheusInactive`	mgr 的 prometheus 模块无响应（`up{job="ceph"} == 0`）

PGs（分支 .7）

OID	通知名	触发条件
`…1.7.1`	`promPGsInactive`	一个或多个 PG 超过 5 分钟处于 inactive
`…1.7.2`	`promPGsUnclean`	一个或多个 PG 超过 15 分钟未恢复为 clean
`…1.7.3`	`promPGsUnavailable`	一个或多个 PG 不可用，阻塞相关对象的 I/O
`…1.7.4`	`promPGsDamaged`	一个或多个 PG 损坏
`…1.7.5`	`promPGsRecoveryFull`	因 OSD 写满导致 PG 恢复（recovery）受阻
`…1.7.6`	`promPGsBackfillFull`	因 OSD 写满导致 PG 回填（backfill）受阻

Nodes（节点，分支 .8）

OID	通知名	触发条件
`…1.8.1`	`promNodeRootVolumeFull`	根卷（OSD 与 MON store 所在）空间危险（剩余 < 5%）
`…1.8.2`	`promNodeNetworkPacketDrops`	某接口丢包速率 > 1 packet/s
`…1.8.3`	`promNodeNetworkPacketErrors`	某接口错误包速率 > 1 packet/s
`…1.8.4`	`promNodeStorageFilling`	按过去 48 小时平均填充速率，某挂载点将在 5 天内写满

Pools（存储池，分支 .9）

OID	通知名	触发条件
`…1.9.1`	`promPoolFull`	存储池容量达到或超过 90%
`…1.9.2`	`promPoolFilling`	按过去 48 小时平均填充速率，存储池将在 5 天内写满

Rados（分支 .10）

OID	通知名	触发条件
`…1.10.1`	`promRadosUnfound`	在所有 OSD 均在线的情况下仍有对象找不到（unfound）
`…1.10.2`	`promRadosRBDMirrorImagesVeryHigh`	RBD 镜像复制（replication）数量过高
`…1.10.3`	`promRadosRBDMirrorUnsyncImages`	本地 RBD 镜像与远端未同步
`…1.10.4`	`promRadosRBDMirrorUnsyncImagesHigh`	未同步的 RBD 镜像占比过高
`…1.10.5`	`promRadosRBDMirrorHighBandwidth`	RBD 镜像传输期间检测到高带宽占用

cephadm（分支 .11）

OID	通知名	触发条件
`…1.11.1`	`promCephadmDaemonDown`	cephadm 判定某个守护进程已 down
`…1.11.2`	`promCephadmUpgradeFailure`	cephadm 升级集群时遇到问题

Prometheus（分支 .12）

OID	通知名	触发条件
`…1.12.1`	`promPrometheusJobMissing`	Prometheus 抓取任务（scrape job）未定义

Hardware / NVMe（分支 .13/.14）

OID	通知名	触发条件
`…1.13.1`~`…1.13.6`	hardware 相关通知	硬件层面的各类告警（设备预测性故障、硬件健康等）
`…1.14.1`	`promNVMeGatewayNicDown`	用于 NVMe 网关客户端流量的网卡（NIC）down

说明：OID 表中…表示统一前缀1.3.6.1.4.1.50495.1.2.1。上表完全取自 MIB 文件中的NOTIFICATION-TYPE定义；其中 hardware 分支（.13）与 NVMe 分支（.14）在 monitoring/ceph-mixin/prometheus_alerts.yml 中对应着CephDeviceFailurePredicted系列与 NVMe-oF 网关相关的规则。

告警规则如何绑定 OID：从 Alert 到 Trap

MIB 与 Prometheus 规则的“对齐”机制是这套集成的核心。查看告警规则的 jsonnet 源文件 monitoring/ceph-mixin/prometheus_alerts.libsonnet，可以看到每条规则在labels中携带一个oid标签：

{ alert: 'CephHealthError', 'for': '5m', expr: 'ceph_health_status == 2', labels: { severity: 'critical', type: 'ceph_default', oid: '1.3.6.1.4.1.50495.1.2.1.2.1' }, annotations: { summary: 'Ceph is in the ERROR state%(cluster)s' % $.MultiClusterSummary(), description: "The cluster state has been HEALTH_ERROR for more than 5 minutes%(cluster)s...", }, },

再如 MON quorum 告警CephMonDownQuorumAtRisk对应 OID1.3.6.1.4.1.50495.1.2.1.3.1、OSD 大量宕机告警CephOSDDownHigh对应1.3.6.1.4.1.50495.1.2.1.4.1，与 MIB 中promMonLowQuorum、promOsdDownHigh的定义一一对应。这正是 README 中所说 “The MIB is aligned to the Prometheus rules. Any rule that defines a critical alert should have a corresponding oid in the CEPH-MIB.txt file” 的工程实现：凡是 critical 级别的告警规则，都必须分配一个 MIB 中已声明的 OID。

这些规则会被渲染成最终的 Prometheus 规则文件 monitoring/ceph-mixin/prometheus_alerts.yml，由 ceph-mixin 提供完整监控告警解决方案（详见 monitoring/ceph-mixin/README.md）。

SNMP 网关：连接 Alertmanager 与网管系统的桥梁

由于 Ceph 没有 SNMP agent，生成 SNMP 通知必须借助一个SNMP 网关：Prometheus Alertmanager 通过自身的 webhook 功能把告警转发给网关，网关负责格式化、转发并对 SNMP 接收端（trap receiver / NMS）完成鉴权。仓库推荐使用的网关是maxwo/snmp_notifier（README 中注明这是一个广泛使用、用 Go 实现的通用 SNMP 网关），其使用方式（语法与参数）与 Prometheus、Alertmanager 乃至 node-exporter 非常相似，学习成本低。

典型链路如下：

Ceph 集群 │ ceph_exporter / mgr prometheus 模块暴露指标 ▼ Prometheus（加载 ceph-mixin 告警规则，匹配 OID 标签） │ Alertmanager webhook ▼ SNMP 网关（snmp_notifier） │ SNMPv2c/v3 Trap ▼ 网管系统（NMS / trap receiver）

SNMP 通知的后缀结构：网关附加信息

除了告警本身对应的 OID 外，SNMP 网关还会向通知中追加额外的组成部分（后缀），README 中给出的对照表如下：

后缀	说明
`.1`	OID（告警对应的对象标识符）
`.2`	告警的严重级别（severity）。当告警被解决时，severity 为`info`，且 description 被设置为`Status:OK`
`.3`	告警文本内容

也就是说，一条由网关发出的 Trap 在1.3.6.1.4.1.50495主干之外，还会携带上述三个后缀对应的子 OID，网管系统可以据此同时拿到“是哪条告警”、“严重程度”和“告警描述”三部分信息，并在恢复通知上通过info级别与Status:OK描述实现告警的自动闭合。

一致性校验：MIB 与规则的双向核对

仓库在 monitoring/ceph-mixin/tests_alerts/validate_rules.py 中实现了对告警规则与 MIB 的自动化校验，其关键逻辑是：

规则中每个oid标签必须匹配正则^1.3.6.1.4.1.50495.1.2.\d+.\d+.\d+$，否则报 “invalid OID format provided”；
若规则声明的 OID 在 MIB 文件中不存在，报 “rule defines an OID … that is missing from the MIB file”；
若snmptranslate可用，则调用它解析CEPH-MIB.txt（通过 monitoring/ceph-mixin/tests_alerts/settings.py 中的MIB_FILE = '../../snmp/CEPH-MIB.txt'定位 MIB 文件）生成真实 OID 列表，与规则声明做交叉核对；
同时检查description与summary字段是否包含非 ASCII 字符（会导致 SNMP trap 关联出错）。

测试数据位于 monitoring/ceph-mixin/tests_alerts/test_alerts.yml，其中每条测试告警都声明了对应的 OID。这套机制保证了“Prometheus 规则 ↔ CEPH-MIB ↔ 实际发出的 Trap”三者的一致性，如果你要为自定义告警添加新的 OID，也应遵循同样的流程：先在 CEPH-MIB.txt 中新增NOTIFICATION-TYPE并加入cephNotificationGroup通知组，再在告警规则的labels.oid中引用它。

实战步骤：验证与部署

结合上述原理，一套最小可行的验证与部署流程如下：

1. 校验 MIB 合法性并导出 OID 树

# 安装 net-snmp-utils（提供 snmptranslate） # Debian/Ubuntu: apt install snmp-mibs-downloader net-snmp-utils snmptranslate -Pu -Tz -M ~/git/ceph/monitoring/snmp:/usr/share/snmp/mibs -m CEPH-MIB

2. 将 OID 标签加入告警规则

编辑 monitoring/ceph-mixin/prometheus_alerts.libsonnet（或直接编辑渲染产物 monitoring/ceph-mixin/prometheus_alerts.yml），为需要发送 Trap 的告警在labels中声明oid。使用 jsonnet 渲染：

jsonnet -J vendor prometheus_alerts.libsonnet

3. 配置 Alertmanager webhook

在 Alertmanager 配置中加入 snmp_notifier 的 webhook receiver，将带有oid标签的告警转发给网关：

route: group_by: ['alertname'] group_wait: 30s group_interval: 5m repeat_interval: 4h receiver: 'snmp-notifications' routes: - match_re: oid: '1.3.6.1.4.1.50495.*' receiver: 'snmp-notifications' receivers: - name: 'snmp-notifications' webhook_configs: - url: 'http://<snmp-gateway-host>:9464/' send_resolved: true

4. 启动 SNMP 网关并指向 trap 接收端

snmp_notifier 的典型启动参数与 Prometheus 系列工具风格一致，例如指定 SNMP 版本、community、trap 目标地址与 MIB 目录：

./snmp_notifier \ --snmp.trap-addr=<nms-host>:162 \ --snmp.community=public \ --snmp.version=2c \ --snmp.mib-dir=~/git/ceph/monitoring/snmp \ --web.listen-address=:9464

5. 触发一条告警验证

例如将某个 OSD 置为 down（ceph osd down <id>）并等待规则评估周期，观察网管系统是否收到promOsdDown（OID1.3.6.1.4.1.50495.1.2.1.4.2）的 Trap；恢复后应收到 severity 为info、描述为Status:OK的解决通知。

小结

Ceph 的 SNMP 支持走的是“MIB 定标准、Prometheus 定告警、网关做翻译”的架构：CEPH-MIB.txt以企业号 50495 定义了覆盖健康状态、MON、OSD、MDS、MGR、PG、节点、存储池、RADOS、cephadm、Prometheus 与硬件/NVMe 的完整通知分类树；告警规则通过labels.oid与 MIB 一一绑定，并由仓库自带的测试脚本交叉校验一致性；最终由 Alertmanager 通过 webhook 将告警交给 snmp_notifier 之类的 SNMP 网关，以.1（OID）、.2（severity）、.3（描述文本）三段式结构把 Ceph 集群状态送入传统网管体系。这套方案让没有 SNMP agent 的 Ceph 集群依然可以被 NMS 纳管，实现了云原生监控（Prometheus）与存量网管协议（SNMP）的无缝衔接。

【免费下载链接】cephCeph is a distributed object, block, and file storage platform项目地址: https://gitcode.com/gh_mirrors/ce/ceph

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析