Ceph SNMP 监控告警集成指南CEPH-MIB 结构、OID 映射与 Prometheus/Alertmanager 网关配置【免费下载链接】cephCeph is a distributed object, block, and file storage platform项目地址: https://gitcode.com/gh_mirrors/ce/cephCeph 本身并不提供 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为50495ceph MODULE-IDENTITY LAST-UPDATED 202111010000Z ORGANIZATION The Ceph Project CONTACT-INFO Email: devceph.io DESCRIPTION The MIB module for Ceph. In its current form it only supports Notifications, since Ceph itself doesnt 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 源码确认纯告警 MIBCEPH-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 中的 OIDsnmptranslate 用法要列出 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.1cephClusterCeph 集群分支1.3.6.1.4.1.50495.1.1cephMetadata元数据占位分支注释说明为未来可能的 agent 扩展预留用于提供集群配置概览1.3.6.1.4.1.50495.1.2cephNotifications通知分支1.3.6.1.4.1.50495.1.2.1prometheus通知来源Prometheus1.3.6.1.4.1.50495.1.2.1.1promGeneric通用告警1.3.6.1.4.1.50495.1.2.1.2promHealthStatus集群健康状态1.3.6.1.4.1.50495.1.2.1.3promMonMON 监控1.3.6.1.4.1.50495.1.2.1.4promOsdOSD 监控1.3.6.1.4.1.50495.1.2.1.5promMdsMDS/CephFS 监控1.3.6.1.4.1.50495.1.2.1.6promMgrMGR 监控1.3.6.1.4.1.50495.1.2.1.7promPGsPG 状态1.3.6.1.4.1.50495.1.2.1.8promNode节点监控1.3.6.1.4.1.50495.1.2.1.9promPool存储池监控1.3.6.1.4.1.50495.1.2.1.10promRadosRADOS 层监控1.3.6.1.4.1.50495.1.2.1.11promCephadmcephadm 编排1.3.6.1.4.1.50495.1.2.1.12promPrometheusPrometheus 自身1.3.6.1.4.1.50495.1.2.1.14promNVMeGatewayNVMe 网关1.3.6.1.4.1.50495.2.1cephAlertGroups合规分组Conformance1.3.6.1.4.1.50495.2.2cephCompliances合规声明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通用分支 .1OID通知名触发条件…1.1.1promGenericNotification通用告警当 Prometheus 规则未提供 OID 时发出…1.1.2promGenericDaemonCrash一个或多个守护进程近期崩溃且尚未归档Ceph Health健康状态分支 .2OID通知名触发条件…1.2.1promHealthStatusError集群长时间处于health_error状态…1.2.2promHealthStatusWarning集群长时间处于health_warn状态MON分支 .3OID通知名触发条件…1.3.1promMonLowQuorum进入 quorum 的 monitor 数量偏低法定人数告急…1.3.2promMonDiskSpaceCriticalmonitor 磁盘空间严重不足OSD分支 .4OID通知名触发条件…1.4.1promOsdDownHigh大量 OSD 处于 down 状态超过 10%…1.4.2promOsdDown一个或多个 OSD 处于 down 状态…1.4.3promOsdNearFullOSD 即将写满NEARFULL…1.4.4promOsdFlappingOSD 在 5 分钟内每分钟至少被标记 down/up 一次抖动…1.4.5promOsdHighPgDeviation某 OSD 的 PG 数量偏离平均值超过 30%…1.4.6promOsdFullOSD 达到 FULL 阈值写入被阻塞…1.4.7promOsdHighPredictedFailures预测将失败的设备过多正常自愈无法应对…1.4.8promOsdHostDownOSD 所在宿主机宕机MDS / CephFS分支 .5OID通知名触发条件…1.5.1promMdsDamagedCephFS 文件系统损坏…1.5.2promMdsReadOnly文件系统被标记为 READ-ONLY…1.5.3promMdsOffline文件系统不可用/离线所有 MDS rank 均不可用…1.5.4promMdsDegraded文件系统处于降级状态…1.5.5promMdsNoStandbyMDS 守护进程失败且无备用standby可用MGR分支 .6OID通知名触发条件…1.6.1promMgrModuleCrashmgr 模块近期崩溃…1.6.2promMgrPrometheusInactivemgr 的 prometheus 模块无响应up{jobceph} 0PGs分支 .7OID通知名触发条件…1.7.1promPGsInactive一个或多个 PG 超过 5 分钟处于 inactive…1.7.2promPGsUnclean一个或多个 PG 超过 15 分钟未恢复为 clean…1.7.3promPGsUnavailable一个或多个 PG 不可用阻塞相关对象的 I/O…1.7.4promPGsDamaged一个或多个 PG 损坏…1.7.5promPGsRecoveryFull因 OSD 写满导致 PG 恢复recovery受阻…1.7.6promPGsBackfillFull因 OSD 写满导致 PG 回填backfill受阻Nodes节点分支 .8OID通知名触发条件…1.8.1promNodeRootVolumeFull根卷OSD 与 MON store 所在空间危险剩余 5%…1.8.2promNodeNetworkPacketDrops某接口丢包速率 1 packet/s…1.8.3promNodeNetworkPacketErrors某接口错误包速率 1 packet/s…1.8.4promNodeStorageFilling按过去 48 小时平均填充速率某挂载点将在 5 天内写满Pools存储池分支 .9OID通知名触发条件…1.9.1promPoolFull存储池容量达到或超过 90%…1.9.2promPoolFilling按过去 48 小时平均填充速率存储池将在 5 天内写满Rados分支 .10OID通知名触发条件…1.10.1promRadosUnfound在所有 OSD 均在线的情况下仍有对象找不到unfound…1.10.2promRadosRBDMirrorImagesVeryHighRBD 镜像复制replication数量过高…1.10.3promRadosRBDMirrorUnsyncImages本地 RBD 镜像与远端未同步…1.10.4promRadosRBDMirrorUnsyncImagesHigh未同步的 RBD 镜像占比过高…1.10.5promRadosRBDMirrorHighBandwidthRBD 镜像传输期间检测到高带宽占用cephadm分支 .11OID通知名触发条件…1.11.1promCephadmDaemonDowncephadm 判定某个守护进程已 down…1.11.2promCephadmUpgradeFailurecephadm 升级集群时遇到问题Prometheus分支 .12OID通知名触发条件…1.12.1promPrometheusJobMissingPrometheus 抓取任务scrape job未定义Hardware / NVMe分支 .13/.14OID通知名触发条件…1.13.1~…1.13.6hardware 相关通知硬件层面的各类告警设备预测性故障、硬件健康等…1.14.1promNVMeGatewayNicDown用于 NVMe 网关客户端流量的网卡NICdown说明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 到 TrapMIB 与 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_notifierREADME 中注明这是一个广泛使用、用 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 receiverSNMP 通知的后缀结构网关附加信息除了告警本身对应的 OID 外SNMP 网关还会向通知中追加额外的组成部分后缀README 中给出的对照表如下后缀说明.1OID告警对应的对象标识符.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-MIB2. 将 OID 标签加入告警规则编辑 monitoring/ceph-mixin/prometheus_alerts.libsonnet或直接编辑渲染产物 monitoring/ceph-mixin/prometheus_alerts.yml为需要发送 Trap 的告警在labels中声明oid。使用 jsonnet 渲染jsonnet -J vendor prometheus_alerts.libsonnet3. 配置 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: true4. 启动 SNMP 网关并指向 trap 接收端snmp_notifier 的典型启动参数与 Prometheus 系列工具风格一致例如指定 SNMP 版本、community、trap 目标地址与 MIB 目录./snmp_notifier \ --snmp.trap-addrnms-host:162 \ --snmp.communitypublic \ --snmp.version2c \ --snmp.mib-dir~/git/ceph/monitoring/snmp \ --web.listen-address:94645. 触发一条告警验证例如将某个 OSD 置为 downceph osd down id并等待规则评估周期观察网管系统是否收到promOsdDownOID1.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 网关以.1OID、.2severity、.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），仅供参考
