闯关预计 45 分钟

闯关：HEALTH_WARN 从哪儿看起

在模拟终端里接手一套告警集群，一步步定位到根因。

学完这节你能做到

周二上午 10:14，监控群里弹出告警：

[P2] ceph-prod 集群 health 状态变更：HEALTH_OK → HEALTH_WARN

你是这套集群的值班人。业务侧暂时没有报障，但告警必须在 30 分钟内给出初步结论。这套集群的情况你只知道个大概：36 个 OSD，3 台存储节点，同时提供 RBD 和 CephFS。

现在开始排查。下面是一个模拟终端，你已经登录到 ceph-node1（MON 节点之一）。

✓排查纪律：从全局到局部

新人最容易犯的错是直接 ssh 到某台机器上翻日志。正确顺序永远是： 先看集群全局状态 → 再看告警明细 → 再定位到具体 OSD/主机 → 最后才登机器看硬件层证据。 反过来做，你会在错误的机器上浪费半小时。

root@ceph-node1

目标 0/6

模拟终端：这是一次预置的排障演练，输出固定。
输入 goals 查看目标，hint 获取提示。开始吧。

[root@ceph-node1 ~]#

排查完成后，值班记录应该长这样——结论、依据、动作、风险四段齐全：

结论：ceph-node3 上的 osd.14 对应的物理盘 /dev/sdd（SN: S6CVNE0T412938）介质损坏，已被固件置为只读，OSD 进程因 BlueStore 读取失败而反复崩溃退出。

依据：

ceph health detail → osd.14 (host=ceph-node3) is down
systemctl status ceph-osd@14 → BlueStore 读盘返回 (5) Input/output error，进程 assert 后被 ABRT
dmesg → critical medium error, dev sdd，扇区级不可恢复读错误
smartctl → SMART overall-health: FAILED，Available Spare 0%，Percentage Used 97%，介质错误 2847 次

动作：

风险与次生问题（这部分最容易漏，也最能体现水平）：

osd.29 已达 86%，进入 nearfull。osd.14 的数据迁移会进一步推高其它 OSD 的水位，有触发 backfillfull 甚至 full（拒绝写入）的风险。迁移前应先确认容量余量，必要时限速回填。
集群 OSD 平均 Percentage Used 需要普查——这批盘同批次采购、同期上线，一块到寿命意味着其它盘也接近。这是典型的批次性故障风险。
当前 61 个 PG 处于 undersized+degraded，副本数不足。在恢复完成前，集群容错额度是降低的。

!别急着敲 ceph osd out

看到盘坏了就立刻 out，是新人最常见的操作事故。out 会立即触发大规模数据迁移，如果此时集群水位已高（就像本例的 osd.29 到了 86%），迁移可能把某个 OSD 顶到 full，导致整个池拒绝写入——一次小故障被你亲手升级成了业务中断。正确做法是先算容量、再限速、再操作。

检查点单选

本次故障中，判断「盘确实坏了」最有力的证据是哪一条？

检查点多选

在执行换盘流程之前，必须先确认哪些事情？（多选）

检查点单选

ceph -s 里 osd 那一行显示「36 osds: 35 up, 36 in」。这里的 in 是什么意思？