【Ceph RADOS】可观测：如何读懂 ceph status、pg dump 与 OSD perf
内容提要
本文介绍Ceph集群监控的关键指标与语义，强调“集群能写”不等于“集群健康”。文章详细解析ceph status、PG状态、OSD性能、Prometheus指标等字段含义，指出常见误判如active+degraded不等于数据丢失、均值掩盖尾延迟等，并提供容量规划与排障建议，帮助读者准确理解Ceph可观测性。
延伸解读
聚合层均值掩盖尾延迟
ceph osd perf 的 commit/apply latency 是滑动平均，SSD/HDD 混部或冷热 PG 混部时，均值会抹平 P99 尖刺。要定位尾延迟，必须下钻 ceph daemon osd.X perf dump 的 histogram，或使用 ceph-exporter 获取亚秒级数据。mgr Prometheus 默认 15 秒刷新，可能漏掉 RocksDB stall 等短时尖峰。
容量规划看单盘，不看集群均值
ceph df 的 RAW USED% 是集群整体，但 nearfull/full 告警按单 OSD 触发。某个 OSD 使用率超阈值时，即使集群均值 70% 也会告警。因此容量规划应优先看 ceph osd df tree 的每 OSD USE%，而不是只看 ceph df。对 EC 池，USED/STORED 比值反映 EC overhead，副本池则约等于副本数。
状态组合的语义陷阱
active+degraded 不等于数据丢失，只要副本数 ≥ min_size 仍可读写；incomplete 才是数据不可访问。recovery_wait 只是后台排队，前台仍可服务。slow_ops 是累计计数，不代表当前慢，要看 dump_ops_in_flight。ceph health 绿不代表 OSD 内部无问题，mgr 指标来自 MON 聚合，亚秒级问题需用 perf dump。
Q&A
ceph status 中的 HEALTH_ERR 状态是否意味着数据已经丢失？
HEALTH_ERR 状态通常与 MON 失 quorum、大量 PG 不可服务、严重 inconsistent 等问题相关，但并不等于数据已经丢失。它表示集群存在严重问题，应先停止扩容或危险 repair 操作，并进一步排查。
ceph pg dump 中 PG 状态 active+degraded 表示什么？是否影响读写？
active+degraded 表示 PG 的 acting set 完整（可读写），但某些对象的副本数少于期望的 size，但仍大于等于 min_size。此时 PG 可以正常读写，但数据冗余度降低，需要关注恢复进度。
ceph osd perf 中的 commit latency 和 apply latency 有什么区别？
commit latency 是写路径上客户端可感知的提交延迟，即 Primary 收齐副本 ACK 后回客户端的平均时间，包含 BlueStore WAL 和副本网络。apply latency 是数据真正落到设备（含 deferred 刷盘）的平均时间，通常大于等于 commit latency。commit 正常而 apply 飙高可能表示 deferred 队列或磁盘问题；两者同飙则可能磁盘或网络已在前台路径上。
如何通过 Prometheus 指标监控 Ceph 集群的健康状态？
可以通过 mgr Prometheus module 暴露的指标监控，例如 ceph_health_status（0=OK, 1=WARN, 2=ERR）、ceph_pg_degraded、ceph_osd_commit_latency_ms 等。建议设置告警：ceph_health_status > 0 持续 5 分钟、ceph_pg_degraded > 0 超过预期恢复时间、ceph_osd_commit_latency_ms 的 P99 超过阈值（如 SSD 100ms）、ceph_cluster_total_used_bytes / ceph_cluster_total_bytes > 0.75 等。
ceph df 中的 RAW USED % 低是否意味着没有 nearfull 风险？
不是。ceph df 的 RAW USED % 是集群整体均值，而 nearfull/full 阈值是按单个 OSD 触发的。如果某个 OSD 使用率超过 nearfull ratio，即使集群 RAW USED % 较低，也会触发告警。因此容量规划应使用 ceph osd df tree 查看每个 OSD 的 USE%。
如何诊断 PG peering 卡住的问题？
可以使用 ceph pg dump_stuck 快速识别 stuck 的 PG（按 unclean、inactive、stale 过滤），然后使用 ceph pg {pgid} query 查看该 PG 的详细内部状态，包括 peering 历史、每个 peer 的 last_epoch_started（LES）值等。如果某个 OSD 的 LES 太旧，可能是 peering 卡住的原因。
Ceph 中 slow_ops 计数上升是否代表当前集群仍然缓慢？
不一定。slow_ops 是累计计数，当 op 在 OSD 队列中停留超过 osd_op_complaint_time（默认 30 秒）时计数一次。它表示发生过慢操作，但不代表当前仍然慢。要查看当前正在进行的慢操作，应使用 ceph tell osd.{id} dump_ops_in_flight。
CephFS 的 MDS 健康关键信号是什么？
MDS journal 积压是 MDS 健康的关键信号。如果 ceph tell mds.0 get perf dump 中 mds_log.segmented 持续增加而 mds_log.trimmed 不追，说明 journal flush 速度低于写入速度，元数据池 I/O 可能是瓶颈，直接影响 MDS 操作延迟与 failover 时 replay 时间。
