用 Nightingale Categraf 采集监控 CephPrometheus 插件接入、内置仪表盘与告警规则全解析【免费下载链接】nightingaleNightingale is to monitoring and alerting what Grafana is to visualization.项目地址: https://gitcode.com/GitHub_Trending/ni/nightingaleCeph 是业界最流行的分布式存储之一其监控通常包含集群健康状态、OSD 状态、PG 分布、容量与读写性能等核心维度。本文基于 Nightingale 仓库中内置的 Ceph 集成integrations/Ceph完整讲解从 Ceph 侧开启 Prometheus 支持、使用 Categraf 的 prometheus 插件抓取指标到在夜莺中导入内置仪表盘与告警规则的一站式方案。读完本文你将掌握一条无需自研采集器、可直接落地的 Ceph 监控链路并能理解内置集成在夜莺服务端的加载原理。Ceph 监控背景为什么直接抓 Prometheus 指标Ceph 从 Luminous12.x版本开始在 Ceph Managermgr中内置了 prometheus 模块可以把集群的健康状态、OSD 性能、PG 状态、容量使用等核心指标以 Prometheus 文本协议暴露在 HTTP 端点上。这意味着监控侧不需要再额外部署 ceph_exporter 之类的旁路采集进程只需要一个能够抓取 Prometheus 协议的采集器即可。从仓库中 Ceph 集成自带的仪表盘 JSONdashboards/ceph_by_categraf.json可以看到夜莺内置仪表盘实际消费的指标都来自ceph_前缀系列例如ceph_health_status集群健康状态0 HEALTH_OK1 WARN2 ERRceph_cluster_total_bytes/ceph_cluster_total_used_bytes集群总容量与已用容量ceph_osd_up/ceph_osd_inOSD 的 up / in 状态ceph_pg_*PG 的数量与状态ceph_osd_op_w_in_bytes/ceph_osd_op_r_out_bytesOSD 读写吞吐ceph_monitor_clock_skew_seconds/ceph_monitor_avail_percentMonitor 时钟偏移与存储水位这些指标均由 Ceph mgr 的 prometheus 模块直接产生后续的抓取、存储、可视化与告警全部在 Nightingale 侧完成。第一步在 Ceph 侧开启 Prometheus 支持集成文档给出的开启命令非常简洁见 markdown/README.mdceph mgr module enable prometheus执行后Ceph 默认会在 mgr 节点上监听9283端口暴露/metrics端点。可以先用 curl 验证curl http://mgr-host:9283/metrics | head看到ceph_health_status、ceph_osd_up等指标输出即代表 Ceph 侧已经就绪。如果启用了多个 mgrPrometheus 模块默认只会由 active mgr 暴露抓取该地址即可。第二步使用 Categraf 的 prometheus 插件完成采集夜莺的官方采集器 Categraf 内置了 prometheus 插件input.prometheus其作用就是周期性地抓取指定 URL 上的 Prometheus 指标并上报。既然 Ceph 已经暴露了/metrics直接使用该插件抓取即可无需任何定制代码。集成文档给出的配置位于 Categraf 的conf/input.prometheus/prometheus.toml[[instances]] urls [ http://192.168.11.181:9283/metrics ] labels {serviceceph,clusterceph-cluster-001}其中192.168.11.181:9283是示例的 mgr 地址实际部署时请替换为你的 Ceph 集群 active mgr 的主机 IP 与端口。几个关键点说明如下urls要抓取的指标端点可以配置多个地址数组例如多集群场景下列出多个 mgr 端点。labels为抓取到的所有指标统一附加标签。这里打了serviceceph和clusterceph-cluster-001两个标签其中cluster标签非常重要——夜莺内置的 Ceph 仪表盘通过label_values(ceph_health_status,cluster)生成 cluster 下拉变量仪表盘上所有面板的 PromQL 都带cluster$cluster过滤条件。因此这里的cluster标签值需要与你的 Ceph 集群标识保持一致仪表盘才能正确筛选出数据。抓取链路为Ceph mgr (9283) → Categraf input.prometheus → Nightingale 服务端。Categraf 把带service、cluster标签的指标上报后夜莺或对接的 Prometheus 数据源即可查询这些ceph_*指标。第三步导入夜莺内置仪表盘 Ceph - Cluster By Categraf采集打通后即可在夜莺界面使用内置仪表盘。集成文档说明夜莺内置仪表盘中已经内置了 Ceph 的仪表盘导入即可使用。对应文件为 dashboards/ceph_by_categraf.json仪表盘名称为Ceph - Cluster By Categraf。仪表盘变量该仪表盘定义了 2 个模板变量来自 JSON 中configs.var字段变量类型取值来源说明DATASOURCEdatasourceprometheus选择查询用的 Prometheus 数据源clusterquerylabel_values(ceph_health_status,cluster)从已采集数据中动态列出所有 cluster 标签值对应 Categraf 配置里打的cluster标签面板结构与核心指标仪表盘以多个 row 分组覆盖了 Ceph 监控的关键维度CLUSTER STATE 行Write/Read Throughput、Cluster Capacity、Available Capacity、Number of Objects、Bytes Written/Read、Alerts、Write/Read IOPS、Used Capacity、Difference、Mon Session Num、Monitors In Quorum 等 stat 面板。典型表达式如sum(irate(ceph_osd_op_w_in_bytes{cluster$cluster}[5m]))表示写入吞吐(ceph_cluster_total_bytes - ceph_cluster_total_used_bytes) / ceph_cluster_total_bytes表示可用容量占比。OSD STATE 行OSDs OUT / DOWN / UP / IN 数量、Avg PGs、Avg Apply Latency、Avg Commit Latency、Avg Op Write/Read Latency。例如count(ceph_osd_up{cluster$cluster} 0.0) OR vector(0)统计 down 的 OSD 数。CLUSTER 行Capacity、IOPS、Throughput 时序面板以及按 pool 维度展开的 Pool Used Bytes、Pool RAW Used Bytes、Objects Per Pool、Pool Quota Bytes、Pool Objects Quota、OSD Type Count其中 pool 名称通过ceph_pool_bytes_used *on (pool_id) group_left(name)(ceph_pool_metadata)关联获得。Alerts 行Alerts from CephThanos基于ALERTS指标统计当前 firing 数量、Top Sluggish OSDs、Down OSDs 表格。Ceph Versions 行按ceph_osd_version、ceph_mon_version、ceph_mds_version、ceph_rgw_version维度展示各组件版本分布。OBJECTS 行Objects in the Cluster、PGs State、Stuck PGs、Recovery Operations。LATENCY 行OSD Apply/Commit 延迟分布表、读写操作延迟分布、Avg OSD Op Latency 等用于定位慢盘与延迟抖动。第四步导入夜莺内置告警规则同样地夜莺内置告警规则中已经内置了 Ceph 的告警规则导入即可使用。告警规则定义在 alerts/ceph_by_categraf.json 中共 15 条覆盖健康状态、OSD、PG、Monitor、延迟等维度各规则的关键参数如下均来自告警规则 JSON规则名称查询表达式级别持续时间告警含义CephErrorStateceph_health_status 11300s集群进入 ERR 状态超过 5 分钟CephWarnStateceph_health_status 121800s集群处于 WARN 状态超过 30 分钟CephOsdReweightedceph_osd_weight 123600sOSD 被 reweight 过久需要人工介入CephOSDUtilizationceph_osd_utilization 90160sOSD 使用率超过 90%CephPgActivatingceph_pg_activating 01300sPG 长时间处于 activating数据不可用CephPgBackfillTooFullceph_pg_backfill_toofull 02300sPG 位于已满 OSD 上可能即将不可用CephPgDownceph_pg_down 01180sPG 长时间 down数据不可用CephPgIncompleteceph_pg_incomplete 01120sPG 长时间 incompleteCephPgInconsistentceph_pg_inconsistent 0260sPG 数据不一致CephPgUnavailableceph_pg_total - ceph_pg_active 01300s存在不可用 PGCephTargetDownup{jobceph} 01600sCeph 采集目标失联exporter 或集群整体故障MonitorAvailableStorageceph_monitor_avail_percent 30260sMonitor 存储空间不足 30%MonitorClockSkewTooHighabs(ceph_monitor_clock_skew_seconds) 0.1260sMonitor 时钟偏移过大需检查 NTPOsdApplyLatencyTooHighceph_osd_perf_apply_latency_seconds 10290sOSD apply 延迟过高OsdDownceph_osd_up 021800sOSD down 超过 30 分钟所有规则统一具备以下通用配置在导入时由夜莺内置集成逻辑装配cate: prometheus、prod: metric基于 Prometheus 数据源进行查询prom_eval_interval为 15 秒enable_stime/etime为00:00~23:59enable_days_of_week覆盖周一至周日即全天候生效notify_repeat_step: 60分钟表示未恢复前每 60 分钟重复通知一次notify_recovered: 1表示恢复后发送恢复通知。以 CephErrorState 为例其 JSON 中附带了annotations.action处置建议导入后在告警详情里可直接看到应急步骤立即用ceph health detail看具体是哪一项 ERR2) 常见为 PG inactive/incomplete、OSD 大量 down、或 full osd 导致集群只读3) 先恢复 down 的 OSD 或释放已满 OSD 的空间这是绝大多数 ERR 的根因4) 恢复期间不要执行扩缩容或调整 crush map避免加重数据迁移。此外规则模板中还使用了{{ $labels.ceph_daemon }}、{{ $labels.cluster }}等标签变量如 CephOsdReweighted、MonitorClockSkewTooHigh告警通知会动态填充具体的 OSD/Monitor 与集群名方便定位。源码视角内置集成在夜莺中是如何加载的从“导入即可使用”的表象背后是夜莺服务端对integrations/目录的自动装载机制。核心实现在 center/integration/init.go服务启动时若配置未指定builtinIntegrationsDir则默认读取运行目录下的integrations目录init.go 第 54-57 行对每个组件目录如Ceph注册内置组件记录builtin_component并把markdown/下的 README 作为组件说明保存其中README.lang.md语言副本只进内存、按请求头X-Language返回对应语言init.go 第 83-105 行扫描alerts/*.json解析出告警规则写入内置负载builtin_payloadtypealert供告警规则页面展示与一键导入init.go 第 162-211 行扫描dashboards/*.json解析出仪表盘定义注册为内置仪表盘init.go 第 213 行起组件目录内还有icon/图标通过/api/n9e/integrations/icon/...提供与i18n/多语言词条表两个约定目录。因此Ceph 这个集成的标准目录结构即为integrations/Ceph/ ├── alerts/ceph_by_categraf.json # 15 条告警规则 ├── dashboards/ceph_by_categraf.json # Ceph - Cluster By Categraf 仪表盘 ├── i18n/en_US.json # 英文词条 ├── icon/ceph.png # 组件图标 └── markdown/README.md # 本文所依据的采集与接入说明这套约定意味着新增一个监控对象时只要按同样结构放置 alerts/dashboards/markdown 文件重启后即可在夜莺的“内置”功能中找到并导入是一种可复制、可扩展的集成模式。验证与排障指标是否采到在夜莺的 Prometheus 数据源中执行ceph_health_status若能查到带cluster标签的序列说明采集链路正常。仪表盘是否有数据打开 Ceph - Cluster By Categraf确认右上角cluster变量能下拉出 Ceph 集群标识若为空请检查 Categraf 配置中labels是否打了cluster标签。告警是否生效up{jobceph}这条 CephTargetDown 规则依赖jobceph标签请确认 Categraf prometheus 插件上报时 job 标识与之一致采集实例的 job 名称可通过插件配置指定否则该规则会一直无数据。其余规则均直接基于ceph_*指标无需额外配置。规则持续时间每条规则的prom_for_duration如 CephErrorState 为 300s表示条件需持续满足该时长才触发告警可有效过滤瞬时抖动导入后也可按需调整。至此一条“Ceph 原生暴露指标 → Categraf 抓取打标 → 夜莺存储查询 → 内置仪表盘可视化 → 内置告警规则通知”的完整监控闭环即告完成后续只需在夜莺中为告警规则绑定通知渠道与接收人即可投入生产使用。【免费下载链接】nightingaleNightingale is to monitoring and alerting what Grafana is to visualization.项目地址: https://gitcode.com/GitHub_Trending/ni/nightingale创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 用 Nightingale + Categraf 采集监控 Ceph：Prometheus 插件接入、内置仪表盘与告警规则全解析
用 Nightingale Categraf 采集监控 CephPrometheus 插件接入、内置仪表盘与告警规则全解析【免费下载链接】nightingaleNightingale is to monitoring and alerting what Grafana is to visualization.项目地址: https://gitcode.com/GitHub_Trending/ni/nightingaleCeph 是业界最流行的分布式存储之一其监控通常包含集群健康状态、OSD 状态、PG 分布、容量与读写性能等核心维度。本文基于 Nightingale 仓库中内置的 Ceph 集成integrations/Ceph完整讲解从 Ceph 侧开启 Prometheus 支持、使用 Categraf 的 prometheus 插件抓取指标到在夜莺中导入内置仪表盘与告警规则的一站式方案。读完本文你将掌握一条无需自研采集器、可直接落地的 Ceph 监控链路并能理解内置集成在夜莺服务端的加载原理。Ceph 监控背景为什么直接抓 Prometheus 指标Ceph 从 Luminous12.x版本开始在 Ceph Managermgr中内置了 prometheus 模块可以把集群的健康状态、OSD 性能、PG 状态、容量使用等核心指标以 Prometheus 文本协议暴露在 HTTP 端点上。这意味着监控侧不需要再额外部署 ceph_exporter 之类的旁路采集进程只需要一个能够抓取 Prometheus 协议的采集器即可。从仓库中 Ceph 集成自带的仪表盘 JSONdashboards/ceph_by_categraf.json可以看到夜莺内置仪表盘实际消费的指标都来自ceph_前缀系列例如ceph_health_status集群健康状态0 HEALTH_OK1 WARN2 ERRceph_cluster_total_bytes/ceph_cluster_total_used_bytes集群总容量与已用容量ceph_osd_up/ceph_osd_inOSD 的 up / in 状态ceph_pg_*PG 的数量与状态ceph_osd_op_w_in_bytes/ceph_osd_op_r_out_bytesOSD 读写吞吐ceph_monitor_clock_skew_seconds/ceph_monitor_avail_percentMonitor 时钟偏移与存储水位这些指标均由 Ceph mgr 的 prometheus 模块直接产生后续的抓取、存储、可视化与告警全部在 Nightingale 侧完成。第一步在 Ceph 侧开启 Prometheus 支持集成文档给出的开启命令非常简洁见 markdown/README.mdceph mgr module enable prometheus执行后Ceph 默认会在 mgr 节点上监听9283端口暴露/metrics端点。可以先用 curl 验证curl http://mgr-host:9283/metrics | head看到ceph_health_status、ceph_osd_up等指标输出即代表 Ceph 侧已经就绪。如果启用了多个 mgrPrometheus 模块默认只会由 active mgr 暴露抓取该地址即可。第二步使用 Categraf 的 prometheus 插件完成采集夜莺的官方采集器 Categraf 内置了 prometheus 插件input.prometheus其作用就是周期性地抓取指定 URL 上的 Prometheus 指标并上报。既然 Ceph 已经暴露了/metrics直接使用该插件抓取即可无需任何定制代码。集成文档给出的配置位于 Categraf 的conf/input.prometheus/prometheus.toml[[instances]] urls [ http://192.168.11.181:9283/metrics ] labels {serviceceph,clusterceph-cluster-001}其中192.168.11.181:9283是示例的 mgr 地址实际部署时请替换为你的 Ceph 集群 active mgr 的主机 IP 与端口。几个关键点说明如下urls要抓取的指标端点可以配置多个地址数组例如多集群场景下列出多个 mgr 端点。labels为抓取到的所有指标统一附加标签。这里打了serviceceph和clusterceph-cluster-001两个标签其中cluster标签非常重要——夜莺内置的 Ceph 仪表盘通过label_values(ceph_health_status,cluster)生成 cluster 下拉变量仪表盘上所有面板的 PromQL 都带cluster$cluster过滤条件。因此这里的cluster标签值需要与你的 Ceph 集群标识保持一致仪表盘才能正确筛选出数据。抓取链路为Ceph mgr (9283) → Categraf input.prometheus → Nightingale 服务端。Categraf 把带service、cluster标签的指标上报后夜莺或对接的 Prometheus 数据源即可查询这些ceph_*指标。第三步导入夜莺内置仪表盘 Ceph - Cluster By Categraf采集打通后即可在夜莺界面使用内置仪表盘。集成文档说明夜莺内置仪表盘中已经内置了 Ceph 的仪表盘导入即可使用。对应文件为 dashboards/ceph_by_categraf.json仪表盘名称为Ceph - Cluster By Categraf。仪表盘变量该仪表盘定义了 2 个模板变量来自 JSON 中configs.var字段变量类型取值来源说明DATASOURCEdatasourceprometheus选择查询用的 Prometheus 数据源clusterquerylabel_values(ceph_health_status,cluster)从已采集数据中动态列出所有 cluster 标签值对应 Categraf 配置里打的cluster标签面板结构与核心指标仪表盘以多个 row 分组覆盖了 Ceph 监控的关键维度CLUSTER STATE 行Write/Read Throughput、Cluster Capacity、Available Capacity、Number of Objects、Bytes Written/Read、Alerts、Write/Read IOPS、Used Capacity、Difference、Mon Session Num、Monitors In Quorum 等 stat 面板。典型表达式如sum(irate(ceph_osd_op_w_in_bytes{cluster$cluster}[5m]))表示写入吞吐(ceph_cluster_total_bytes - ceph_cluster_total_used_bytes) / ceph_cluster_total_bytes表示可用容量占比。OSD STATE 行OSDs OUT / DOWN / UP / IN 数量、Avg PGs、Avg Apply Latency、Avg Commit Latency、Avg Op Write/Read Latency。例如count(ceph_osd_up{cluster$cluster} 0.0) OR vector(0)统计 down 的 OSD 数。CLUSTER 行Capacity、IOPS、Throughput 时序面板以及按 pool 维度展开的 Pool Used Bytes、Pool RAW Used Bytes、Objects Per Pool、Pool Quota Bytes、Pool Objects Quota、OSD Type Count其中 pool 名称通过ceph_pool_bytes_used *on (pool_id) group_left(name)(ceph_pool_metadata)关联获得。Alerts 行Alerts from CephThanos基于ALERTS指标统计当前 firing 数量、Top Sluggish OSDs、Down OSDs 表格。Ceph Versions 行按ceph_osd_version、ceph_mon_version、ceph_mds_version、ceph_rgw_version维度展示各组件版本分布。OBJECTS 行Objects in the Cluster、PGs State、Stuck PGs、Recovery Operations。LATENCY 行OSD Apply/Commit 延迟分布表、读写操作延迟分布、Avg OSD Op Latency 等用于定位慢盘与延迟抖动。第四步导入夜莺内置告警规则同样地夜莺内置告警规则中已经内置了 Ceph 的告警规则导入即可使用。告警规则定义在 alerts/ceph_by_categraf.json 中共 15 条覆盖健康状态、OSD、PG、Monitor、延迟等维度各规则的关键参数如下均来自告警规则 JSON规则名称查询表达式级别持续时间告警含义CephErrorStateceph_health_status 11300s集群进入 ERR 状态超过 5 分钟CephWarnStateceph_health_status 121800s集群处于 WARN 状态超过 30 分钟CephOsdReweightedceph_osd_weight 123600sOSD 被 reweight 过久需要人工介入CephOSDUtilizationceph_osd_utilization 90160sOSD 使用率超过 90%CephPgActivatingceph_pg_activating 01300sPG 长时间处于 activating数据不可用CephPgBackfillTooFullceph_pg_backfill_toofull 02300sPG 位于已满 OSD 上可能即将不可用CephPgDownceph_pg_down 01180sPG 长时间 down数据不可用CephPgIncompleteceph_pg_incomplete 01120sPG 长时间 incompleteCephPgInconsistentceph_pg_inconsistent 0260sPG 数据不一致CephPgUnavailableceph_pg_total - ceph_pg_active 01300s存在不可用 PGCephTargetDownup{jobceph} 01600sCeph 采集目标失联exporter 或集群整体故障MonitorAvailableStorageceph_monitor_avail_percent 30260sMonitor 存储空间不足 30%MonitorClockSkewTooHighabs(ceph_monitor_clock_skew_seconds) 0.1260sMonitor 时钟偏移过大需检查 NTPOsdApplyLatencyTooHighceph_osd_perf_apply_latency_seconds 10290sOSD apply 延迟过高OsdDownceph_osd_up 021800sOSD down 超过 30 分钟所有规则统一具备以下通用配置在导入时由夜莺内置集成逻辑装配cate: prometheus、prod: metric基于 Prometheus 数据源进行查询prom_eval_interval为 15 秒enable_stime/etime为00:00~23:59enable_days_of_week覆盖周一至周日即全天候生效notify_repeat_step: 60分钟表示未恢复前每 60 分钟重复通知一次notify_recovered: 1表示恢复后发送恢复通知。以 CephErrorState 为例其 JSON 中附带了annotations.action处置建议导入后在告警详情里可直接看到应急步骤立即用ceph health detail看具体是哪一项 ERR2) 常见为 PG inactive/incomplete、OSD 大量 down、或 full osd 导致集群只读3) 先恢复 down 的 OSD 或释放已满 OSD 的空间这是绝大多数 ERR 的根因4) 恢复期间不要执行扩缩容或调整 crush map避免加重数据迁移。此外规则模板中还使用了{{ $labels.ceph_daemon }}、{{ $labels.cluster }}等标签变量如 CephOsdReweighted、MonitorClockSkewTooHigh告警通知会动态填充具体的 OSD/Monitor 与集群名方便定位。源码视角内置集成在夜莺中是如何加载的从“导入即可使用”的表象背后是夜莺服务端对integrations/目录的自动装载机制。核心实现在 center/integration/init.go服务启动时若配置未指定builtinIntegrationsDir则默认读取运行目录下的integrations目录init.go 第 54-57 行对每个组件目录如Ceph注册内置组件记录builtin_component并把markdown/下的 README 作为组件说明保存其中README.lang.md语言副本只进内存、按请求头X-Language返回对应语言init.go 第 83-105 行扫描alerts/*.json解析出告警规则写入内置负载builtin_payloadtypealert供告警规则页面展示与一键导入init.go 第 162-211 行扫描dashboards/*.json解析出仪表盘定义注册为内置仪表盘init.go 第 213 行起组件目录内还有icon/图标通过/api/n9e/integrations/icon/...提供与i18n/多语言词条表两个约定目录。因此Ceph 这个集成的标准目录结构即为integrations/Ceph/ ├── alerts/ceph_by_categraf.json # 15 条告警规则 ├── dashboards/ceph_by_categraf.json # Ceph - Cluster By Categraf 仪表盘 ├── i18n/en_US.json # 英文词条 ├── icon/ceph.png # 组件图标 └── markdown/README.md # 本文所依据的采集与接入说明这套约定意味着新增一个监控对象时只要按同样结构放置 alerts/dashboards/markdown 文件重启后即可在夜莺的“内置”功能中找到并导入是一种可复制、可扩展的集成模式。验证与排障指标是否采到在夜莺的 Prometheus 数据源中执行ceph_health_status若能查到带cluster标签的序列说明采集链路正常。仪表盘是否有数据打开 Ceph - Cluster By Categraf确认右上角cluster变量能下拉出 Ceph 集群标识若为空请检查 Categraf 配置中labels是否打了cluster标签。告警是否生效up{jobceph}这条 CephTargetDown 规则依赖jobceph标签请确认 Categraf prometheus 插件上报时 job 标识与之一致采集实例的 job 名称可通过插件配置指定否则该规则会一直无数据。其余规则均直接基于ceph_*指标无需额外配置。规则持续时间每条规则的prom_for_duration如 CephErrorState 为 300s表示条件需持续满足该时长才触发告警可有效过滤瞬时抖动导入后也可按需调整。至此一条“Ceph 原生暴露指标 → Categraf 抓取打标 → 夜莺存储查询 → 内置仪表盘可视化 → 内置告警规则通知”的完整监控闭环即告完成后续只需在夜莺中为告警规则绑定通知渠道与接收人即可投入生产使用。【免费下载链接】nightingaleNightingale is to monitoring and alerting what Grafana is to visualization.项目地址: https://gitcode.com/GitHub_Trending/ni/nightingale创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考