运维运维运维

王先生，下面我按"需要更正/容易误导的点"和"建议补充的关键内容"两部分来审阅。整体上，你这份手册的结构清晰、面向 cephadm 容器化部署场景也比较贴近一线运维；主要问题集中在：部分参数默认值/类型不准确、cephadm 与 Ceph 原生默认行为混在一起、少量笔误与版本信息不一致、以及缺少 Day-2 运维闭环（巡检---告警---处置---恢复---变更）。

一、需要更正或容易误导的点（建议优先修）

1) 容器运行时写死为 Docker，建议改为"Docker/Podman"

你文中多处以 /usr/bin/docker run ... 为例，这在你的环境成立，但在很多 cephadm 默认环境是 podman。建议表述为：

"cephadm 以容器方式运行守护进程，容器运行时可能为 docker 或 podman；以本集群输出为准（cephadm info / ps -ef | grep ceph-）。"

这样可避免读者在非 Docker 环境照抄排障时走偏。

2) MON 日志：你写"集群默认不将 mon 日志写入文件"，但后面参数默认值又写成 true

你在 1.2.2 说"默认不写文件，需要把 log_to_file 改为 true"，而在 1.2.3 又写：

mon_cluster_log_to_file 默认 true
同时你在进程参数里也能看到 cephadm 注入了：
--default-log-to-file=false
--default-mon-cluster-log-to-file=false

建议统一口径：

Ceph 守护进程的"编译/配置默认值" 与 cephadm 容器启动时的默认注入参数 是两回事。
你这份手册明显是 cephadm 场景 ，因此应以 unit.run/容器启动参数为准，明确写成：
- "在 cephadm 部署下，通常通过 --default-*-to-file=false 关闭文件日志，默认走 stderr/journald；需要落盘时使用 ceph config set ... log_to_file true 或调整对应 daemon 的启动默认参数。"

3) RocksDB / LevelDB 表述自相矛盾

在 MON 日志解读里你写"RocksDB 数据库操作（LevelDB 后端）"，这会让读者误以为两者并存或等价。建议改成：

"MON 存储后端为 RocksDB（历史上曾支持 LevelDB，现以 RocksDB 为主）。日志中 Compaction/Flush 等属于 RocksDB 行为。"

同类问题还有你对 store.db 的描述里同时提 RocksDB/LevelDB，建议在"现网版本"下给出唯一结论，把 LevelDB 放到"历史兼容说明"即可。

4) 路径描述建议从"hostname"改为"monid/mgrid/osdid"，更准确

你写：

MON 默认存储在 /var/lib/ceph/<cluster-fsid>/mon.<hostname>
更准确的说法应是"monid"（通常与主机名相关但不是概念等价），建议改为：
/var/lib/ceph/<fsid>/mon.<monid>
/var/lib/ceph/<fsid>/mgr.<hostname>.<id>
/var/lib/ceph/<fsid>/osd.<id>

这类修正能显著减少跨集群/跨主机场景的歧义。

5) `ceph device ls` 用来证明 MON 在系统盘上：结论可能不稳

你用 ceph device ls 看到 mon.node1 关联 vda，并据此推导 "mon 数据在系统盘 vda"。这在你环境可能成立，但在很多集群里：

ceph device ls 更常用于展示由 ceph-volume 管理、与 OSD 关联的设备信息；
MON 使用普通文件系统目录，未必会以"device---daemon"方式出现在该命令输出中。

建议把"mon 在系统盘"的证据链改成更稳的两步：

mount | grep /var/lib/ceph/<fsid>/mon.* 确认该目录落在哪个文件系统
lsblk -f/df -hT 对应挂载点确认实际盘符/卷

6) OSD 日志小笔误：写成了 mon

在 1.4.2 你写："集群默认将 mon 日志写入文件"，这里应为 osd（或"守护进程日志"）。建议直接修正避免读者误解。

7) logrotate 定时任务不是"每 30 分钟"

你写的 crontab：

30 * * * * ...
这是一小时一次（每小时第 30 分钟），不是每 30 分钟。
若你想"每 30 分钟"，应为：
*/30 * * * * ...

另外你前文提到 cephadm 生成 ceph-<fsid> 的 logrotate 文件，但后文改 /etc/logrotate.d/ceph，建议统一为你实际环境中的文件名（通常是 ceph-<fsid>）。

8) 版本信息前后不一致（v16 与 18.2.7）

MON/MGR 进程示例里镜像 quay.io/ceph/ceph:v16，OSD 日志示例却写 ceph version 18.2.7 reef。

建议在文档开头增加"适用版本/测试版本"：

Ceph 主版本、cephadm 版本、容器镜像来源与标签策略（v16/reef 等），避免读者在不同版本下对参数/日志产生偏差。

9) 参数类型标注有明显不一致（str/bool）

例如你写：

mon_cluster_log_to_syslog 类型：str（通常应为 bool）
mon_cluster_log_to_journald 类型：str（通常应为 bool）

建议你把"参数名---类型---默认值"这一块做一次统一校验（最稳的方法是从实际集群 ceph config dump/ceph config get mon.<id> <key> 抽样核对），避免读者按错误类型配置导致参数不生效。

二、强烈建议补充的内容（让手册从"说明文"变成"可落地运维手册"）

你目前的优势在"模块结构与日志/进程解释"，但缺少运维最常用的 流程化 Runbook。建议按下面优先级补齐。

A. Day-2 运维闭环（巡检---告警---处置---恢复）

每日巡检清单（10 分钟版）

ceph -s、ceph health detail
ceph osd tree、ceph osd df、ceph df
ceph pg stat、ceph pg dump pgs_brief（抽样）
ceph orch ps --daemon_type mon/mgr/osd（cephadm 场景）
时间同步检查（chrony/ntp），因为你日志里也提到 clock skew

告警分级与处置模板

P0：MON 不成 quorum、集群 IO 不可用
P1：大量 PG peering/backfill、恢复风暴
P2：单 OSD down、单宿主机异常、慢盘
每一类给出：
现象 → 关键命令 → 判断标准 → 回滚/升级路径 → 风险提示

常见故障 Runbook

OSD down/out 的处理（区分宕机/磁盘坏/网络隔离）
MON quorum 不稳（选举抖动、时钟漂移、磁盘满）
慢请求（slow ops）、PG stuck、undersized/degraded
nearfull/backfillfull/full 的处理策略
节点系统盘写满（与日志、crash、core dump 关联）

B. 监控体系：从"指标解释"升级为"指标阈值 + 联动定位"

你在客户端 perf 指标解释很好，但建议再补：

服务端关键 perf 与健康指标（OSD 侧：op queue、commit/apply 延迟、bluestore/rocksdb、heartbeat；MON 侧：paxos、db 变更、quorum；MGR 侧：模块状态）
阈值建议（例如：op_laggy、op_resend、slow ops 的数量/持续时间触发告警）
定位路径：客户端延迟高 → objecter → OSD latency → 网络/磁盘 → PG 状态 → 恢复/回填影响

C. 变更与维护：升级、扩容、缩容、替盘

建议增加一章"变更操作规范"，至少包含：

cephadm 方式的升级步骤与检查点（升级前后 health、版本一致性）
新增 OSD、替换 OSD（ceph-volume LVM/裸盘、擦盘、reweight、in/out、destroy 的边界）
pool/pg 调整、CRUSH 变更的风险提示
scrubbing 策略（deep-scrub 的窗口、对性能影响）

D. 安全与权限（生产环境经常被忽略）

keyring 生命周期：备份、最小权限、泄露应对
cephx 开关与常见权限模型（client.admin 不建议长期用于业务）
Dashboard/Prometheus 暴露面、TLS/证书与访问控制

E. 你目录里"其他客户端日志(待补充)"建议优先补齐

你已经留了占位，建议落到可直接用的内容：

librados 日志怎么开、落在哪里（容器/宿主机/journald）
KRBD ：dmesg 关键字、常见错误（超时、重连、map 更新）、与用户态 rbd 的差异

三、建议你做的"最小改动清单"（性价比最高）

统一说明：cephadm 默认注入的日志行为 vs Ceph 参数默认值
修复：RocksDB/LevelDB、OSD 日志笔误、crontab */30、logrotate 文件名一致
增加：文档开头的"适用版本/部署形态/容器运行时（docker/podman）"
增加：一章"常见告警 Runbook（至少 6 个场景）"，把手册变成可执行工具

1) 挂载与路径：哪些目录是"容器化运维的生命线"

必须关注的挂载点（cephadm 常见）

这些目录不在容器的临时层里，而是绑定到宿主机上；一旦挂载错/权限错，daemon 会直接起不来或行为异常。

MON：/var/lib/ceph/<fsid>/mon.<id> → 容器内 /var/lib/ceph/mon/ceph-<monid>
MGR：/var/lib/ceph/<fsid>/mgr.<id> → 容器内 /var/lib/ceph/mgr/ceph-<mgrid>
OSD：/var/lib/ceph/<fsid>/osd.<id> → 容器内 /var/lib/ceph/osd/ceph-<id>

关注点：

宿主机文件系统类型/容量/IO 性能（尤其 MON 的系统盘写满会导致 quorum 波动）
SELinux/AppArmor 标签（你日志里有 :z，说明用了 SELinux relabel；如果环境启用 SELinux，这是"起不来"的常见根因）
目录 owner/perms（通常 ceph:ceph，错了就会认证/写盘失败）

运行时 socket 与 asok

宿主机：/var/run/ceph/<fsid>/（或 /var/run/ceph 映射到 /var/run/ceph/<fsid>）
容器内：/var/run/ceph/

关注点：

这里放的是 .asok、admin socket、临时运行文件；排障时常用：
- ceph daemon /var/run/ceph/<...>.asok ...
目录不可写会导致很多"看似随机"的运行异常

配置与 keyring（配置一致性关键）

宿主机：/etc/ceph/ceph.conf、各类 keyring
容器内：通常挂载到 /etc/ceph/ceph.conf 和对应 keyring 路径

关注点：

cephadm 会生成/管理部分配置，手工改 ceph.conf 可能被覆盖（更推荐 ceph config set）
keyring 路径挂载错误是 daemon 启动失败的高频原因（认证失败）

OSD 额外挂载（设备、LVM、udev、rootfs）
OSD 容器通常还会挂：

/dev、/sys
/run/udev
/run/lvm、/run/lock/lvm
有时还有 -v /:/rootfs（用于访问宿主机根文件系统视图）

关注点：

这意味着 OSD 容器具有很高权限（常见 --privileged --group-add=disk），宿主机层面的设备问题会直接体现在容器里
任何 udev/lvm 相关异常都会导致 OSD 起不来或 block 设备找不到

运维检查命令（建议写进手册）

看某个 daemon 实际挂载/参数（最可信） ：直接查看 unit.run
bash 复制代码
```
cat /var/lib/ceph/<fsid>/osd.<id>/unit.run
```

确认宿主机挂载与容量

bash 复制代码

df -hT /var/lib/ceph /var/log/ceph
mount | egrep "var/lib/ceph|var/log/ceph|run/ceph"

2) 日志位置：容器化下日志不止"/var/log/ceph"

你在文档里已经写了 /var/log/ceph/<fsid>，但容器化运维要把日志分成三层看：

A) Ceph 传统文件日志（可选，可能默认关闭）

宿主机：/var/log/ceph/<fsid>/
是否存在取决于：
- 你是否开启 log_to_file
- cephadm 是否注入了 --default-log-to-file=false

关注点

生产环境不建议长期高 debug 落盘（系统盘写爆风险）
如果必须落盘，必须同时配置 logrotate 与保留策略

B) journald / systemd 日志（容器化最常用）

因为 cephadm 经常默认把日志打到 stderr，由 systemd/journald 接管，所以很多时候"文件里没有，但 journal 里有"。

典型查看方式（按实际 unit 名称调整）：

bash 复制代码

journalctl -u ceph-<fsid>@mon.<id> -n 200 --no-pager
journalctl -u ceph-<fsid>@mgr.<id> -n 200 --no-pager
journalctl -u ceph-<fsid>@osd.<id> -n 200 --no-pager

关注点

journald 自身会占盘：要看 journalctl --disk-usage，并设置合理上限
"找不到文件日志"时，第一跳应查 journal，而不是认为"没日志"

C) 容器运行时日志（docker/podman）

当 systemd 只是拉起容器，容器 stdout/stderr 会被容器运行时记录：

bash 复制代码

podman logs <container_id> --tail 200
# 或 docker logs <container_id> --tail 200

关注点

在不同发行版上，容器日志驱动/存储目录不同；运维上更建议统一走 journald 或集中采集

D) Crash/核心转储（常被忽略但最值钱）

crash 归档：/var/lib/ceph/<fsid>/crash/
core dump（若启用）：通常由 systemd-coredump 接管（coredumpctl）

关注点：

crash 文件不清理会吃盘
core dump 体积巨大，必须配额与策略

3) 网络模型：容器化多数是 host network，但仍要关注两条网络

cephadm 常见用 --net=host，这减少了容器网络复杂度，但运维上必须明确：

public network（客户端/对外）
cluster network（OSD 复制/恢复/backfill）

关注点（容器化与非容器化都一样，但容器化更容易忽略宿主机层）：

MTU 一致性（尤其跨交换机/VXLAN 场景）
丢包/重传（会直接表现为 op_resend、心跳异常、peering 卡住）
防火墙规则（host 网络意味着端口就是宿主机端口）

建议加一段固定检查：

bash 复制代码

ip -s link
ss -lntp | egrep "ceph|6789|3300|6800|8443|9283"

（端口要以你集群实际为准：MON v2 通常 3300，v1 6789，OSD 常见 6800-7300 范围；dashboard/prometheus 取决于是否启用。）

4) 编排状态与"漂移"：容器化运维最容易踩坑的点

容器化最大风险不是"某个进程挂了"，而是编排状态与实际状态不一致，或手工改动导致 cephadm 重建时丢失。

关注点：

所有 daemon 是否由 cephadm 管理
bash 复制代码
```
ceph orch ps
ceph orch ls
```
是否存在反复重建/漂移（配置被重写）
- 你手工改了 ceph.conf、手工改了 unit 文件、手工改了容器启动参数
- cephadm 重新 deploy/upgrade 时可能覆盖

运维原则（建议写进规范）：

配置优先用 ceph config set（由 MON 配置库管理），避免手工改容器内部文件
守护进程生命周期操作优先用 ceph orch ...，避免直接 docker stop/podman rm（除非应急且记录）

5) 宿主机资源与安全边界：容器化并不等于隔离

尤其是 OSD 容器通常 --privileged，实际隔离很弱，所以宿主机是"第一责任边界"。

必须关注：

系统盘容量 ：/var/lib/ceph、/var/log/ceph、journald、容器镜像层
文件句柄/ulimit ：你示例里是 nofile=1048576，要确保系统级也匹配
CPU/内存：mgr 常占内存；恢复风暴时 OSD 会吃 CPU/IO
SELinux ：有 :z 的场景下，标签不对会导致"权限拒绝但看起来像 Ceph 错误"
时间同步：容器共享宿主机时间，clock skew 必须从宿主机解决

建议固定检查（每周一次）：

bash 复制代码

df -hT
journalctl --disk-usage
podman system df    # 或 docker system df
ulimit -n
timedatectl status
chronyc tracking

6) 一句话总结成"容器化运维 Checklist"

挂载：/var/lib/ceph、/var/log/ceph、/var/run/ceph、/etc/ceph、/dev 与 LVM/udev 相关挂载是否正确、容量是否充足、权限/SELinux 是否正常
日志链路：文件日志是否启用？journald 是否在用？容器日志去哪？crash/core dump 是否受控？
编排一致性 ：以 ceph orch 为准，避免手工改导致漂移；升级/重建时配置不会丢
宿主机底座：磁盘、网络、时间同步、ulimit、journal、容器存储空间

1) "Ceph 参数默认值"是什么意思

这是指：Ceph 守护进程（ceph-mon/ceph-mgr/ceph-osd 等）在没有任何额外配置时，内部会有一套默认行为，例如：

日志是否写文件（log_to_file）
是否输出到 stderr（log_to_stderr）
集群日志（cluster log / audit log）是否写文件（如 mon_cluster_log_to_file）
日志文件路径（log_file）

这套"默认值"可以通过：

ceph config show <daemon>（看运行时实际值）
ceph config dump（看集群层的配置项）
来观察。

但注意：这些"默认值"并不等于"最终生效值"。

2) "cephadm 默认注入的日志行为"是什么意思

在 cephadm 模式下，守护进程不是你手工 ceph-mon ... 启动的，而是 cephadm 生成 unit.run → systemd 拉起容器 → 容器里执行 ceph-mon/ceph-mgr/ceph-osd。

在这个链路里，cephadm 会把一串参数加到 daemon 启动命令上，典型就是您文档里已经出现过的：

--default-log-to-file=false
--default-log-to-stderr=true
--default-log-stderr-prefix=debug
（MON 还会有）--default-mon-cluster-log-to-file=false
（MON 还会有）--default-mon-cluster-log-to-stderr=true

这些 --default-xxx 的含义是：
"如果 Ceph 配置里没有明确设置某项，则用我这个 default 值。"

也就是说：cephadm 把"默认行为"改成了"默认走 stderr/journald，不默认落盘到 /var/log/ceph/*.log"。

这就是我之前说的：Ceph 内置默认值 vs cephadm 启动时注入的 default 值，两者可能不一致，最终以运行时生效为准。

3) 谁的优先级更高？（覆盖关系）

在 cephadm 场景里，通常可以按这个优先级理解（从高到低）：

你显式配置的 Ceph 配置项 （例如 ceph config set ... log_to_file true 或 ceph.conf 的对应项）
守护进程启动参数里注入的 --default-xxx（cephadm 常用）
Ceph 程序自身编译/代码里的默认值

所以：

如果您没有显式设置 log_to_file，那就会吃到 cephadm 注入的 --default-log-to-file=false。
一旦您显式 ceph config set ... log_to_file true，一般就会覆盖掉 cephadm 的 default 行为（以 daemon 实际值为准）。

4) cephadm "里面到底有啥"？（它做了哪些事）

从运维角度看，cephadm 主要提供四类能力（也是它"注入"的来源）：

A. 编排与生命周期

生成并维护 systemd 单元（unit.run/unit.stop/unit.meta 等）
负责容器创建、启动、停止、重建
用 ceph orch ... 接受集群层编排指令（添加 OSD、部署 MON/MGR、升级等）

B. 运行环境"注入"

启动容器时统一注入：

网络模式（常见 --net=host）
挂载（/var/lib/ceph、/var/log/ceph、/var/run/ceph、/dev、/run/lvm 等）
资源限制（ulimit、pids-limit）
daemon 的启动参数（尤其 --default-* 这类）

日志这块就是典型的"运行时注入"。

C. 配置分发与密钥管理

把 ceph.conf、keyring 放到正确位置并挂载给容器
为每个 daemon 维护对应的目录与元数据（unit.meta 等）

D. 观测与运维入口

ceph orch ps 看到守护进程状态
cephadm shell 提供带配置/认证的运维 shell
管理 dashboard/prometheus/alertmanager 等（取决于启用的 mgr 模块与服务）

5) 在您集群里怎么"眼见为实"确认 cephadm 注入了什么

您已经在文档里贴出过进程命令行，这其实就是最直接证据。建议您在手册里补一段"标准核对方法"。

方法 1：看 unit.run（最准确）

宿主机上：

bash 复制代码

cat /var/lib/ceph/<fsid>/mon.<id>/unit.run
cat /var/lib/ceph/<fsid>/mgr.<id>/unit.run
cat /var/lib/ceph/<fsid>/osd.<id>/unit.run

里面会包含容器启动命令，以及 ceph-mon/ceph-mgr/ceph-osd 的参数（含 --default-*）。

方法 2：看运行中进程命令行（快）

bash 复制代码

ps -ef | egrep "ceph-mon|ceph-mgr|ceph-osd" | head
# 或者查看某个 pid 的完整 cmdline
tr '\0' ' ' < /proc/<pid>/cmdline

方法 3：看"最终生效的配置"（判断是否被覆盖）

例如看 mon 的日志相关配置：

bash 复制代码

ceph config show mon.<id> | egrep "log_to_file|log_to_stderr|log_file|mon_cluster_log"

这里看到的才是"最终有效值"。

如果这里 log_to_file = false，那就说明您没有显式改、并且吃到了 cephadm default；

如果这里 log_to_file = true，说明您显式覆盖成功了。

6) 为什么 cephadm 要这么做（工程上的真实原因）

主要原因通常是三个：

容器化更倾向把日志打到 stdout/stderr，再由 journald / 日志采集系统统一收集（比每个容器写本地文件更可控）。
避免 /var/log/ceph 写爆系统盘。调试级别一开，日志可能每小时 GB 级，落盘风险大。
统一运维体验 ：通过 journalctl 或集中日志平台追踪，避免"每台机器找文件"。

因此 cephadm 常见策略是：默认不落盘、优先 stderr/journald；需要落盘时由运维显式开启。

7) 写进您文档的推荐表述（可直接粘贴）

在 cephadm 容器化部署中，守护进程启动由 cephadm 生成的 systemd 单元（unit.run）负责。cephadm 会通过 ceph-mon/ceph-mgr/ceph-osd 的启动参数注入一组 --default-* 选项（如 --default-log-to-file=false、--default-log-to-stderr=true 等），用于覆盖 Ceph 程序自身的默认日志行为。若集群配置中未显式设置相应参数，则以 --default-* 的值作为运行时默认；一旦通过 ceph config set 或 ceph.conf 显式配置，则显式配置优先于 --default-*。最终生效值以 ceph config show <daemon> 为准。

如果您把您环境里任意一个 unit.run（mon 或 mgr 的都行）再贴一小段（包含 ceph-mon/ceph-mgr 的参数部分即可），我可以帮您把"日志输出链路（stderr → journald → 文件/采集）"在您这套集群里写成一段完全对齐现网的说明，包括：默认去哪、如何开启落盘、如何保证 logrotate 生效、以及如何避免系统盘满。

A. Day-2 运维闭环（巡检---告警---处置---恢复）

A1. 每日巡检清单（10 分钟版）

建议固定每天两次（早/晚），并将输出保存到工单或巡检记录（便于基线对比）。以下每一项都给出：命令、关注点、判定标准、异常时下一跳。

1) 集群总览：`ceph -s` 与 `ceph health detail`

命令

bash 复制代码

ceph -s
ceph health detail

关注点

HEALTH_OK / HEALTH_WARN / HEALTH_ERR
mon: X daemons, quorum ...
osd: N osds: N up, N in
pgs: ... active+clean 占比
IO：客户端读写是否明显异常（部分版本会显示）
health detail 中的具体告警项（例如：OSD_DOWN、PG_DEGRADED、MON_CLOCK_SKEW、NEARFULL 等）

判定标准（可执行）

正常：HEALTH_OK；或 HEALTH_WARN 但告警为已知且有工单跟踪（例如计划内 scrub 影响、单个非关键告警）。
需要立刻处理：出现 HEALTH_ERR；或 HEALTH_WARN 但包含以下任意项：
- MON_DOWN / MON_QUORUM 异常
- OSD_DOWN、OSD_OUT 非计划
- PG_AVAILABILITY、PG_DEGRADED 持续增长
- NEARFULL / BACKFILLFULL / FULL
- SLOW_OPS 持续出现（例如超过 5 分钟仍在增加）

异常下一跳

进入 A3 "常见故障 Runbook"对应条目（MON/OSD/PG/满盘/慢请求）。

2) 容量与分布：`ceph df`、`ceph osd df`、`ceph osd tree`

命令

bash 复制代码

ceph df
ceph osd df
ceph osd tree
# 可选：更直观的分层视图
ceph osd df tree

关注点

ceph df：
- RAW 与各 pool 的 MAX AVAIL、USED、%USED
ceph osd df：
- 单 OSD utilization/%use 是否失衡
- VAR（有的版本提供）是否明显偏离 1.0
ceph osd tree：
- 主机/机架/故障域分布是否符合预期
- 是否有 OSD down 或 out

判定标准（经验阈值，便于落地）

容量健康线（建议写入告警规则）：
- NEARFULL：通常在集群或 OSD 达到阈值时触发（阈值由 mon_osd_nearfull_ratio 等参数控制），实际以 ceph health detail 为准。
- 实操建议：当 RAW 使用率接近 70% 就开始扩容评估；接近 80% 进入变更窗口；触发 NEARFULL 必须立即控写/扩容。
失衡判断：
- 同一故障域内若存在 OSD %use 差异持续大于 10--15 个百分点，且 ceph -s 显示长期 backfill/remap，建议检查 crush/weight、balancer、以及是否存在慢盘。

异常下一跳

容量逼近：看 A3-4（nearfull/backfillfull/full）
分布失衡：看 B3（定位路径）与 C3（CRUSH/PG 调整风险提示）

3) PG 状态：`ceph pg stat` 与 `ceph pg dump pgs_brief`（抽样）

命令

bash 复制代码

ceph pg stat
# 抽样：只看异常 PG（建议）
ceph pg dump pgs_brief | egrep -v "active\+clean" | head -n 50
# 或者只看 stuck（若有）
ceph pg dump_stuck inactive
ceph pg dump_stuck unclean
ceph pg dump_stuck undersized
ceph pg dump_stuck degraded

关注点

active+clean 是否为绝对主导
是否出现 peering、activating、undersized、degraded、remapped、backfilling、recovery_wait 等
异常 PG 是否集中在某几个 OSD/主机（常见于单机故障或慢盘）

判定标准（可执行）

若存在以下情况，进入 P1/P2 流程：
- peering/activating 的 PG 数量持续上升或长时间不收敛
- undersized/degraded 持续 > 10 分钟且无下降趋势
- stuck inactive/unclean 任意出现（通常属于高优先级）

异常下一跳

进入 A2 告警分级：P1（大面积）或 P2（局部）
进入 A3-3（PG stuck/undersized/degraded）

4) cephadm 编排态：`ceph orch ps --daemon_type mon/mgr/osd`

命令

bash 复制代码

ceph orch ps --daemon_type mon
ceph orch ps --daemon_type mgr
ceph orch ps --daemon_type osd
# 可选：查看失败原因更详细
ceph orch ps --daemon_type osd --format json-pretty | head

关注点

STATUS 是否为 running
是否出现 error、unknown、stopped
失败守护进程是否集中在某一台宿主机（提示宿主机层面问题：磁盘、网络、容器运行时、系统资源）

判定标准

任一 mon/活跃 mgr/多个 osd 处于非 running 且非计划停机：进入告警流程（P0/P2）。
若 orch ps 显示守护进程反复重启，通常需要结合宿主机 journalctl 与容器日志排查（见 A3 条目中的日志段落）。

5) 时间同步（chrony/ntp），针对 clock skew

时钟漂移会直接导致 MON 选举、paxos、心跳判断异常，是必须每日抽查的"硬指标"。

命令（chrony 常见）

bash 复制代码

timedatectl status
chronyc tracking
chronyc sources -v

判定标准（可执行）

timedatectl：System clock synchronized: yes
chronyc tracking：
- Leap status : Normal
- Last offset、RMS offset 不应长期处于毫秒级以上（不同网络环境略有差异；持续 > 10ms 建议关注，持续 > 50ms 建议处置）
chronyc sources -v：
- 至少 2--3 个可用源
- 当前选中源状态正常（带 * 的源可用）

异常下一跳

若 ceph health detail 报 MON_CLOCK_SKEW：直接走 A3-2（MON quorum 不稳：时钟漂移分支）。

A2. 告警分级与处置模板（P0/P1/P2）

下面每一类都按：现象 → 关键命令 → 判断标准 → 回滚/升级路径 → 风险提示。

P0：MON 不成 quorum、集群 IO 不可用（最高优先级）

现象

ceph -s 卡住或报错（无法从 MON 获取 map）
health 显示 HEALTH_ERR，包含 MON_DOWN / no quorum
客户端普遍 IO 超时、挂载/映射失败（RBD/CEPHFS/RGW 皆可能受影响）

关键命令

bash 复制代码

ceph -s
ceph health detail
ceph quorum_status
ceph mon stat
ceph orch ps --daemon_type mon
# 宿主机侧（在异常 mon 所在节点）
journalctl -u ceph-<fsid>@mon.<id> -n 200 --no-pager
# 若是容器运行时
podman ps | grep mon.   # 或 docker ps | grep mon.

判断标准

ceph quorum_status 无法返回或 quorum 成员不足（例如 3 MON 集群只剩 1 个可用）
ceph orch ps --daemon_type mon 显示 mon 非 running/反复重启
日志出现：
- 时钟漂移（clock skew）
- 磁盘空间不足（low space）
- RocksDB 损坏/无法打开（store.db 错误、LOCK 异常等）
- 网络不可达（互相无法通信）

回滚/升级路径（处置路线）

先恢复 quorum（优先级最高）
- 若是单节点 mon 进程挂掉：先恢复该 mon 守护进程运行（服务/容器）
- 若是网络问题：先恢复 MON 间网络连通（防火墙、路由、MTU、丢包）
- 若是时钟漂移：先修 chrony/ntp，再观察 mon 选举是否恢复稳定
若 MON 数据目录/DB 损坏
- 不直接在生产上"修 RocksDB"；正确路线是：让故障 mon 重新从 quorum 同步（需要谨慎，通常走 cephadm/ceph 官方恢复流程）
恢复后验证
- ceph -s 正常、ceph health 收敛、quorum_status 正常

风险提示

不要在 quorum 未恢复前做大规模 OSD 操作、CRUSH 变更、升级操作。
不要随意删除 mon 数据目录或强制重建，可能导致集群 map 回退/一致性问题。
MON 故障经常与"系统盘满/时钟漂移/网络抖动"绑定，处置要从底层先行。

P1：大量 PG peering/backfill、恢复风暴（影响性能，可能扩散）

现象

ceph -s 中 pgs 大量处于 peering/backfill/recovery/remapped，客户端延迟明显升高
HEALTH_WARN/ERR 含 PG_DEGRADED、PG_AVAILABILITY、RECOVERY 相关
集群网络与磁盘 IO 飙升，业务抖动

关键命令

bash 复制代码

ceph -s
ceph health detail
ceph pg stat
ceph osd stat
ceph osd df tree
ceph osd perf               # 观察 OSD 提交/应用延迟（如支持）
ceph tell 'osd.*' dump_recovery_stats | head   # 部分版本可用
# 查"谁在拖后腿"
ceph health detail | egrep -i "slow|stuck|degraded|undersized|backfill|recovery" -n

判断标准

异常 PG 数量占比高（例如显著多于 active+clean）
backfill/recovery 长时间不收敛，或 misplaced 比例不下降
osd perf 显示部分 OSD 延迟显著偏高（典型慢盘/坏盘/宿主机资源不足）

回滚/升级路径（处置路线）

先止血：控制恢复对业务的冲击
- 适度限制恢复并发（具体参数因版本不同，但核心策略是"降低 backfill/recovery 并发"）
- 如果是计划内维护导致，可在维护窗口结束后逐步恢复默认值
再定位：为什么触发大规模恢复
- 是否有 OSD/主机掉线恢复
- 是否做过 CRUSH/权重/PG 数调整
- 是否出现慢盘导致恢复速度极慢
最后收敛：确保恢复完成
- ceph -s 中 misplaced/degraded 逐步下降直至清零

风险提示

盲目提高恢复并发可能导致业务雪崩（前台 IO 与后台恢复抢资源）。
在 nearfull/backfillfull 状态下恢复可能"越恢复越满"，必须与容量策略联动（见 A3-4）。

P2：单 OSD down、单宿主机异常、慢盘（局部影响，可升级）

现象

ceph -s 显示 osd: N up, N in 不一致（例如 1 个 down）
ceph osd tree 某个 OSD down 或整机下线
ceph osd perf 某个 OSD 延迟显著高，伴随 slow ops

关键命令

bash 复制代码

ceph -s
ceph health detail
ceph osd tree
ceph osd df
ceph osd perf               # 若可用
ceph orch ps --daemon_type osd | egrep "osd\.<id>|<hostname>"
# 宿主机侧（OSD 所在节点）
journalctl -u ceph-<fsid>@osd.<id> -n 200 --no-pager
dmesg -T | egrep -i "blk|scsi|nvme|timeout|reset|I/O error|ext4|xfs" | tail -n 50
lsblk -f

判断标准

若 OSD down 与宿主机磁盘 I/O error/timeout 同时出现：高度怀疑硬件或链路问题（磁盘、HBA、线缆、背板）。
若 OSD down 且宿主机网络异常：检查与 MON、同集群节点连通性。
若仅 OSD 进程反复重启：看容器日志、权限、挂载、设备映射。

回滚/升级路径

单 OSD 故障：优先恢复该 OSD（重启服务/修复宿主机问题）；若确认坏盘则走替盘流程（见 C2）。
单宿主机异常：先隔离该主机（避免反复 flap），再处理硬件/系统层问题。
慢盘：若影响明显且可定位到单盘/单 OSD，建议尽快更换或迁移该盘上的负载。

风险提示

不要在原因未明时频繁 in/out 抖动，会导致 PG 反复迁移，引发 P1 恢复风暴。
计划内重启/维护前要按策略设置标志位（见 C 章维护规范）。

A3. 常见故障 Runbook（可直接复制进手册）

A3-1) OSD down/out 的处理（区分宕机 / 磁盘坏 / 网络隔离）

目标

快速判断故障类型 → 恢复 OSD 或隔离并替换 → 避免引发恢复风暴与数据风险。

步骤 1：确认 down/out 现状

bash 复制代码

ceph -s
ceph health detail
ceph osd tree | egrep "osd\.<id>|host"
ceph osd dump | egrep "osd\.<id>"

down：进程/节点不可用
out：被标记移出数据承载（会触发数据迁移）
常见情况：down 但仍 in（危险：会 degraded）；out 多为人工或自动策略导致

步骤 2：定位是"进程问题"还是"宿主机问题"

看编排态：

bash 复制代码

ceph orch ps --daemon_type osd | egrep "osd\.<id>|<hostname>"

到宿主机看服务与日志（cephadm 常见为 systemd 单元 + 容器）：

bash 复制代码

journalctl -u ceph-<fsid>@osd.<id> -n 300 --no-pager
# 容器日志（按实际运行时）
podman logs --tail 200 <container_id>

步骤 3：区分三大类根因

宿主机宕机/不可达（最常见）
- ping/ssh 不通，或整机重启中
- 处理：先恢复主机（电源/网络/内核崩溃），再观察 OSD 是否自动回归
磁盘/链路故障（高风险）
- dmesg 出现 I/O error、timeout、reset、blk_update_request 等
- 处理：优先保护数据与避免 flap
  - 若磁盘明显坏：走替盘流程（C2），不要反复重启 OSD
网络隔离/局部丢包
- 主机在线但与部分节点/MON 不通
- 处理：检查交换机端口、bond、MTU、一致性；确认 ceph public/cluster 网络健康

步骤 4：恢复策略（in/out 的边界）

短时故障（例如重启、临时抖动） ：不建议立刻 out，先恢复 OSD 运行
确认磁盘坏且恢复时间不可控 ：需要将 OSD out（触发数据迁移保证副本数），并执行替换
若是计划内维护：应先设置维护标志位（见 C 章），避免不必要的数据迁移

验证

bash 复制代码

ceph -s
ceph health detail
ceph pg stat

目标是：PG 恢复收敛，告警消失或可控。

A3-2) MON quorum 不稳（选举抖动、时钟漂移、磁盘满）

症状

ceph -s 中 quorum 成员反复变化
health detail 提示 MON_CLOCK_SKEW、MON_DISK_LOW、mon 掉线/重启
客户端间歇性超时（map 获取失败）

定位命令

bash 复制代码

ceph mon stat
ceph quorum_status
ceph health detail
ceph orch ps --daemon_type mon
# 宿主机
chronyc tracking
df -h /var/lib/ceph /var/log/ceph
journalctl -u ceph-<fsid>@mon.<id> -n 300 --no-pager

分支处置

时钟漂移
- 修 chrony/ntp：恢复同步、稳定源
- 复核：chronyc tracking 正常，ceph health 中 clock skew 消失
磁盘满（系统盘/mon 数据盘）
- 立即释放空间（日志轮转、清理 crash、清理无用镜像层等）
- 强烈建议：对 /var/lib/ceph、/var/log/ceph 做容量预警
网络抖动
- 检查 MON 节点之间连通性与丢包（尤其是 public 网络）
- 修复交换机/防火墙/MTU/路由异常

风险提示

quorum 不稳时避免进行任何变更（升级、CRUSH、PG 调整、批量 OSD 操作）。
clock skew 往往是"时间源异常/虚拟化宿主机时间漂移/chrony 失效"的信号，必须作为基础设施问题闭环。

A3-3) 慢请求（slow ops）、PG stuck、undersized/degraded

症状与入口

ceph health detail 出现 SLOW_OPS
PG 状态长期 peering/inactive/unclean/undersized/degraded
业务：延迟升高、超时

关键命令

bash 复制代码

ceph health detail
ceph pg stat
ceph osd perf                 # 若支持：查看提交/应用延迟
ceph osd tree
# 看慢请求细节（不同版本输出略有差异）
ceph daemon osd.<id> dump_historic_ops | head
ceph daemon osd.<id> dump_ops_in_flight | head

判断标准（可执行）

SLOW_OPS 若持续 > 5 分钟且数量上升：视为需要处置
pg stuck inactive/unclean：优先级接近 P0（数据不可用风险）
undersized/degraded：若副本不足且持续不收敛，需要定位 down/out OSD 或网络隔离

处置路径（由近及远）

先找"拖后腿的 OSD/主机"
- osd perf 高延迟者优先
- 同时检查宿主机 dmesg I/O error、磁盘满、CPU/内存打满
再看网络
- 若 op_resend/丢包相关指标异常（见 B2），优先修网络
最后再动集群策略
- 不建议在根因不明时直接改 CRUSH/PG，避免扩大影响面

A3-4) nearfull/backfillfull/full 的处理策略

核心原则

nearfull/backfillfull/full 是"容量与恢复策略"的耦合问题：越满越难恢复，越恢复越可能更满。
处置优先级：先止血（控写/扩容）→ 再恢复（回填/再均衡）→ 最后优化（清理/规划）。

定位命令

bash 复制代码

ceph health detail
ceph df
ceph osd df
ceph osd df tree

处置步骤（可执行）

确认是哪一层触发
- 是某些 OSD 近满？还是整体 RAW 近满？
短期止血
- 控制写入来源（业务侧限流/停写非关键任务）
- 清理可回收对象（例如 RGW/镜像垃圾、快照策略不当导致膨胀）
中期恢复
- 扩容 OSD 或增加容量（见 C2 新增 OSD）
- 恢复后观察 misplaced/degraded 是否可持续下降
长期治理
- 规划 pool 配额、生命周期、快照保留策略、压缩/纠删码策略等

风险提示

在 backfillfull/full 状态下，恢复可能卡死甚至导致更多 OSD 被逼近满线，必须以扩容/控写为优先。

A3-5) 节点系统盘写满（日志、crash、core dump 关联）

典型现象

mon/mgr 无法写日志或 DB，守护进程反复重启
health detail 报 low on available space（尤其 mon）
宿主机 df -h 显示 /var 或根分区 100%

定位命令

bash 复制代码

df -hT
du -sh /var/log/ceph/* | sort -h | tail
du -sh /var/lib/ceph/* | sort -h | tail
# crash 文件
find /var/lib/ceph/*/crash -type f | wc -l
# journald 占用
journalctl --disk-usage

处置（按风险从低到高）

立即释放空间（低风险优先）
- 压缩/清理历史日志（结合 logrotate）
- 清理过多 crash 归档（确认已上报/已保存后清理）
- 控制调试日志级别（避免 debug 爆量）
治理
- 设定 logrotate 的大小阈值与保留策略
- 对 /var/log/ceph、/var/lib/ceph 做独立分区或至少做容量告警
- 限制 core dump（生产环境通常应收敛到可控目录与配额）

风险提示

不要在未确认内容用途前直接删除 mon 的 store.db 或关键 keyring/config。
清理应优先日志与 crash，再考虑容器镜像层与系统临时文件。

B. 监控体系：指标阈值 + 联动定位

B1. 服务端关键 perf 与健康指标（按 MON/MGR/OSD）

1) OSD 侧（性能与稳定性最关键）

健康类（强制纳入告警）

ceph -s / ceph health detail 中：
- OSD_DOWN、OSD_OUT
- SLOW_OPS
- PG_DEGRADED / PG_AVAILABILITY
- NEARFULL/BACKFILLFULL/FULL

性能类（建议监控）

OSD 延迟（提交/应用）
- 命令面：ceph osd perf（若版本支持）
- 解释：某个 OSD 的 commit/apply 延迟长期显著高，通常是慢盘或宿主机资源瓶颈
OSD 心跳与网络
- ceph health detail 中 heartbeat 相关告警
- 宿主机层：网卡丢包、重传、bond 抖动

OSD 侧 perf dump（按需排障）

bash 复制代码

ceph daemon osd.<id> perf dump | head -n 80
# 或批量抽样
ceph tell osd.<id> perf dump | head -n 80

关注：

队列与延迟相关字段（不同版本字段名略有差异，但"队列长度/处理耗时/磁盘提交耗时"是共性）

2) MON 侧（quorum、paxos、DB、磁盘）

必须监控

quorum 成员数量与稳定性：
- ceph mon stat
- ceph quorum_status
MON_CLOCK_SKEW、low disk space（系统盘/mon 数据目录）

排障辅助

paxos 相关：mon 日志里会体现 map 更新、选举、paxos 提交节奏
DB 相关：RocksDB compaction/flush 过于频繁可能与磁盘性能、写入压力相关

3) MGR 侧（模块状态与监控出口）

必须监控

是否存在 active/standby：
- ceph mgr stat
关键模块状态（如 dashboard、prometheus、balancer）：
- ceph mgr module ls

排障辅助

ceph orch ps --daemon_type mgr
mgr 日志中常见：balancer、pg_autoscaler、prometheus exporter 状态

B2. 阈值建议（告警触发条件示例）

阈值需要结合您集群规模与业务类型做基线校准。下面给的是"通用可落地起点"，并带持续时间条件，避免抖动误报。

1) 健康告警（强制）

ceph health：
- HEALTH_ERR：立即告警（P0/P1 视内容）
- MON_DOWN / quorum 异常：P0
- PG_AVAILABILITY（如 inactive/unclean）：P0/P1
- OSD_DOWN（非计划）：P2（若影响副本或集中则升 P1）
- NEARFULL/BACKFILLFULL/FULL：至少 P1（FULL 直接 P0/P1，视是否影响写入）

2) 慢请求与重试（结合客户端与服务端）

SLOW_OPS：
- 触发条件：连续 5 分钟存在且数量不下降，或数量持续增长
客户端侧（您文档已有 perf 指标）：
- objecter.op_laggy > 0 持续 1--3 分钟：预警
- objecter.op_resend > 0 持续出现：告警（多为网络丢包/OSD flap）

3) OSD 延迟（慢盘/宿主机瓶颈）

ceph osd perf（若可采集）：
- 单 OSD commit/apply 延迟持续显著高于同集群均值（例如高出 5--10 倍且持续 10 分钟）
宿主机 dmesg 出现 I/O error/timeout：立即告警（硬件风险）

B3. 联动定位路径（从"客户端慢"到"根因"）

下面给一条标准化"从现象到根因"的联动路径，适合写成运维 SOP：

客户端延迟高

入口：业务监控/RBD 指标 rd_latency.avgtime、wr_latency.avgtime 升高
同时看：objecter.op_laggy、op_resend 是否上升

判断是"客户端自身瓶颈"还是"存储端瓶颈"

若 finisher queue_len 堆积且客户端 CPU 高：先处理客户端（线程数/CPU/内核）
若 op_laggy 上升：更可能是网络或 OSD 响应慢

下钻到 OSD latency

ceph osd perf 找出高延迟 OSD
ceph osd df/tree 看是否集中在某主机/某批盘

区分网络 vs 磁盘

若 op_resend/丢包明显：优先网络（交换机、MTU、bond、拥塞）
若宿主机 dmesg 报错或磁盘 util 高：优先磁盘/宿主机资源

回到 PG 状态确认影响面

ceph pg stat 是否出现 peering/backfill/recovery
若处于恢复风暴：按 P1 止血策略限制恢复并发，避免业务雪崩

C. 变更与维护：升级、扩容、缩容、替盘（变更操作规范）

C1. cephadm 升级步骤与检查点（生产可执行版）

升级前检查（必须）

bash 复制代码

ceph -s
ceph health detail
ceph versions
ceph orch ps
ceph mgr stat
ceph mon stat

判定：

集群应处于可控状态（最好 HEALTH_OK；至少不能有 quorum/PG availability 类严重告警）
确保有 mgr standby、mon quorum 稳定
确认当前版本与目标版本的跨度符合升级策略（避免跨大版本跳跃）

升级执行（cephadm 常用）

bash 复制代码

# 以镜像升级（示例；镜像地址以实际仓库为准）
ceph orch upgrade start --image <your_image>
ceph orch upgrade status

升级中检查点

每一步后看：

bash 复制代码

ceph -s
ceph health detail
ceph orch upgrade status
ceph orch ps | egrep -i "error|failed|unknown"

暂停/恢复（用于风险控制）

bash 复制代码

ceph orch upgrade pause
ceph orch upgrade resume

升级后验证

ceph versions 确认各 daemon 版本一致性
ceph -s 收敛到稳定状态
若启用 dashboard/prometheus：确认模块可用、监控链路正常

风险提示

升级过程中若出现 MON quorum 不稳或大规模 PG 异常，优先 pause 并回到 A3 的故障处置。
升级前应确认宿主机磁盘空间（/var/lib/ceph、/var/log/ceph、容器镜像存储目录）充足。

C2. 新增 OSD、替换 OSD（ceph-volume/LVM、擦盘、reweight、in/out、destroy 边界）

1) 新增 OSD（cephadm 编排方式，推荐）

前置

确认新盘在宿主机可见：lsblk -f
确认盘上无残留（必要时做擦除/清签名，见下）

新增命令（常见形态）

bash 复制代码

# 将指定主机的指定设备加入为 OSD（示例）
ceph orch daemon add osd <host>:<device>
# 例如：ceph orch daemon add osd node1:/dev/sdb

检查

bash 复制代码

ceph orch ps --daemon_type osd | egrep "<host>|osd\."
ceph osd tree
ceph -s

2) 替换 OSD（坏盘/退役盘）

原则

替换 OSD 本质上是：让数据在其他 OSD 上补齐副本 → 安全移除旧 OSD → 清理旧盘 → 加入新盘。

典型步骤（安全路径）

标识故障 OSD：

bash 复制代码

ceph osd tree
ceph health detail

让该 OSD 退出承载（触发迁移）：

bash 复制代码

ceph osd out osd.<id>

等待数据补齐收敛：

bash 复制代码

ceph -s
ceph pg stat

确认可以销毁（destroy）边界：

仅当该 OSD 上的数据已经在集群内通过副本/纠删码安全重建完成，且 ceph -s 显示 degraded/misplaced 明显下降并收敛，才进入销毁。

从编排移除并清理（以 cephadm/ceph-volume 实际流程为准）：

常见需要 "停止守护进程→移除→擦盘→再加入" 的链路
擦盘（高风险操作，务必核对盘符）：

bash 复制代码

# 常见擦除方式之一（示例，命令需非常谨慎）
wipefs -a /dev/<device>
sgdisk --zap-all /dev/<device>
# 若使用 ceph-volume LVM 管理（示例）
cephadm shell -- ceph-volume lvm zap --destroy /dev/<device>

reweight/in/out 边界

out：触发数据迁移，适用于坏盘/长期不可恢复
in：恢复承载，适用于短时故障恢复后回归
reweight：用于逐步降低某 OSD 承载以平滑迁移（避免一次性 out 引发风暴）；适合"慢盘退役"场景

风险提示

zap --destroy、wipefs 属于不可逆数据破坏操作，只能对确认退役的盘执行。
频繁 in/out 会导致 PG 反复迁移，极易升级为 P1 恢复风暴。

C3. pool/pg 调整、CRUSH 变更的风险提示

pool/PG 调整

不建议大幅一次性修改 PG 数（会触发大量 remap/backfill）。
推荐策略：
- 小步调整、观察收敛，再继续；
- 优先使用 pg_autoscaler（如已启用）并在变更窗口执行；
- 变更前确认容量与恢复能力，否则易触发 nearfull/backfillfull。

CRUSH 变更

CRUSH 变更（故障域、权重、规则）会改变数据放置，通常触发数据迁移。
风险控制：
- 变更前：ceph -s 必须稳定；容量留有余量；避免与升级同窗
- 变更后：重点盯 misplaced/degraded、网络与磁盘负载，必要时限制恢复并发

C4. scrubbing 策略（deep-scrub 窗口与性能影响）

目标

通过 scrub/deep-scrub 提前发现 silent data corruption，但控制对业务的影响。

常见可控手段（按需写入配置基线）

设定 scrub 时间窗口（例如夜间）：
- 通过相关 scrub 时间参数限制执行窗口（具体键名以版本为准，可用 ceph config dump | grep scrub 在集群内核对）
限制 scrub 并发与优先级：
- 避免 scrub 与恢复/backfill/高峰业务竞争资源

运维建议

业务高峰尽量避免 deep-scrub
若集群正在恢复风暴（P1），优先保证恢复与业务，必要时暂时降低 scrub 压力（但要在事后恢复）

D. 安全与权限（生产必须补齐）

D1. keyring 生命周期：备份、最小权限、泄露应对

1) 备份策略（真实可执行）

备份对象（至少）：
- /etc/ceph/ceph.conf
- /etc/ceph/ceph.client.admin.keyring（或你实际使用的管理 keyring）
- 各 daemon 目录下的 keyring（如 /var/lib/ceph/<fsid>/mon.* /mgr.* /osd.* 中的 keyring）
备份要求：
- 加密存储（如企业密钥库/堡垒机加密区）
- 访问审计（谁取用、何时取用）
- 定期演练恢复（至少季度）

2) 最小权限（不要让业务用 admin）

生产建议：为不同业务/组件创建独立 client，并赋予最小 caps。
查看现有权限：

bash 复制代码

ceph auth ls
ceph auth get client.<name>

创建/更新权限（示例：按需调整 pool/namespace）：

bash 复制代码

# 示例：给某业务 client 仅开放 rbd 所需能力（实际 caps 需结合你的使用场景与安全要求制定）
ceph auth get-or-create client.app1 \
  mon 'allow r' \
  osd 'allow rw pool=<poolname>'

3) 泄露应对（必须写入手册）

一旦怀疑 key 泄露：

立刻识别泄露主体：是哪一个 client keyring
立即收敛权限或禁用该 client：

bash 复制代码

ceph auth del client.<leaked>

或先降权再替换（业务不中断场景更常见）：

新建 client（新 key）→ 业务切换 → 删除旧 client

排查来源（配置仓库、CI、镜像、日志、工单附件）
审计与复盘：将"禁止把 keyring 放入镜像/代码仓库"写成强制规范

D2. cephx 开关与常见权限模型

核对 cephx 是否开启

bash 复制代码

ceph config get mon auth_cluster_required
ceph config get mon auth_service_required
ceph config get mon auth_client_required

常见期望：

cephx 认证启用（通常这些项应为 cephx 或相应安全配置）

权限模型建议

管理：保留 client.admin 但限制使用范围（仅运维堡垒机/受控主机）
业务：每个业务系统独立 client.<biz>，只给必要的 mon 读权限与 osd 的 pool 级权限
自动化：为监控/备份/脚本单独建 client，并限制只读或最小写权限

D3. Dashboard/Prometheus 暴露面、TLS/证书与访问控制

1) 暴露面治理（网络层优先）

强制要求：
- Dashboard 与 Prometheus exporter 不直接暴露公网/非受控网段
- 通过防火墙/安全组仅允许运维网段访问
- 可选：统一走反向代理（nginx/haproxy）并做额外认证与审计

2) Dashboard（MGR 模块）安全配置要点

核对模块：

bash 复制代码

ceph mgr module ls

建议：
- 启用 HTTPS（TLS）
- 禁用弱口令，开启访问审计
- 最小化开放端口与绑定地址（仅管理网）

证书方式可以使用自签或企业 CA。具体命令在不同版本略有差异，但原则是：提供证书+私钥 → 配置到 dashboard → 强制 https → 限制监听地址。

3) Prometheus 指标出口（mgr/prometheus 或 exporter）

关注：
- 指标端口仅对 Prometheus Server 网段开放
- 若使用反代，统一做 mTLS 或 basic auth（看企业规范）
- 对外暴露会泄漏集群拓扑与容量信息，属于安全风险

运维运维运维

一、需要更正或容易误导的点（建议优先修）

1) 容器运行时写死为 Docker，建议改为"Docker/Podman"

2) MON 日志：你写"集群默认不将 mon 日志写入文件"，但后面参数默认值又写成 true

3) RocksDB / LevelDB 表述自相矛盾

4) 路径描述建议从"hostname"改为"monid/mgrid/osdid"，更准确

5) ceph device ls 用来证明 MON 在系统盘上：结论可能不稳

6) OSD 日志小笔误：写成了 mon

7) logrotate 定时任务不是"每 30 分钟"

8) 版本信息前后不一致（v16 与 18.2.7）

9) 参数类型标注有明显不一致（str/bool）

二、强烈建议补充的内容（让手册从"说明文"变成"可落地运维手册"）

A. Day-2 运维闭环（巡检---告警---处置---恢复）

B. 监控体系：从"指标解释"升级为"指标阈值 + 联动定位"

C. 变更与维护：升级、扩容、缩容、替盘

D. 安全与权限（生产环境经常被忽略）

E. 你目录里"其他客户端日志(待补充)"建议优先补齐

三、建议你做的"最小改动清单"（性价比最高）

1) 挂载与路径：哪些目录是"容器化运维的生命线"

必须关注的挂载点（cephadm 常见）

运维检查命令（建议写进手册）

2) 日志位置：容器化下日志不止"/var/log/ceph"

A) Ceph 传统文件日志（可选，可能默认关闭）

B) journald / systemd 日志（容器化最常用）

C) 容器运行时日志（docker/podman）

D) Crash/核心转储（常被忽略但最值钱）

3) 网络模型：容器化多数是 host network，但仍要关注两条网络

4) 编排状态与"漂移"：容器化运维最容易踩坑的点

5) 宿主机资源与安全边界：容器化并不等于隔离

6) 一句话总结成"容器化运维 Checklist"

1) "Ceph 参数默认值"是什么意思

2) "cephadm 默认注入的日志行为"是什么意思

3) 谁的优先级更高？（覆盖关系）

4) cephadm "里面到底有啥"？（它做了哪些事）

A. 编排与生命周期

B. 运行环境"注入"

C. 配置分发与密钥管理

D. 观测与运维入口

5) 在您集群里怎么"眼见为实"确认 cephadm 注入了什么

方法 1：看 unit.run（最准确）

方法 2：看运行中进程命令行（快）

方法 3：看"最终生效的配置"（判断是否被覆盖）

6) 为什么 cephadm 要这么做（工程上的真实原因）

7) 写进您文档的推荐表述（可直接粘贴）

A. Day-2 运维闭环（巡检---告警---处置---恢复）

A1. 每日巡检清单（10 分钟版）

1) 集群总览：ceph -s 与 ceph health detail

2) 容量与分布：ceph df、ceph osd df、ceph osd tree

3) PG 状态：ceph pg stat 与 ceph pg dump pgs_brief（抽样）

4) cephadm 编排态：ceph orch ps --daemon_type mon/mgr/osd

5) 时间同步（chrony/ntp），针对 clock skew

A2. 告警分级与处置模板（P0/P1/P2）

P0：MON 不成 quorum、集群 IO 不可用（最高优先级）

P1：大量 PG peering/backfill、恢复风暴（影响性能，可能扩散）

P2：单 OSD down、单宿主机异常、慢盘（局部影响，可升级）

A3. 常见故障 Runbook（可直接复制进手册）

A3-1) OSD down/out 的处理（区分宕机 / 磁盘坏 / 网络隔离）

A3-2) MON quorum 不稳（选举抖动、时钟漂移、磁盘满）

A3-3) 慢请求（slow ops）、PG stuck、undersized/degraded

A3-4) nearfull/backfillfull/full 的处理策略

A3-5) 节点系统盘写满（日志、crash、core dump 关联）

B. 监控体系：指标阈值 + 联动定位

B1. 服务端关键 perf 与健康指标（按 MON/MGR/OSD）

1) OSD 侧（性能与稳定性最关键）

2) MON 侧（quorum、paxos、DB、磁盘）

3) MGR 侧（模块状态与监控出口）

B2. 阈值建议（告警触发条件示例）

1) 健康告警（强制）

2) 慢请求与重试（结合客户端与服务端）

3) OSD 延迟（慢盘/宿主机瓶颈）

B3. 联动定位路径（从"客户端慢"到"根因"）

C. 变更与维护：升级、扩容、缩容、替盘（变更操作规范）

C1. cephadm 升级步骤与检查点（生产可执行版）

C2. 新增 OSD、替换 OSD（ceph-volume/LVM、擦盘、reweight、in/out、destroy 边界）

1) 新增 OSD（cephadm 编排方式，推荐）

2) 替换 OSD（坏盘/退役盘）

C3. pool/pg 调整、CRUSH 变更的风险提示

pool/PG 调整

CRUSH 变更

C4. scrubbing 策略（deep-scrub 窗口与性能影响）

5) `ceph device ls` 用来证明 MON 在系统盘上：结论可能不稳

1) 集群总览：`ceph -s` 与 `ceph health detail`

2) 容量与分布：`ceph df`、`ceph osd df`、`ceph osd tree`

3) PG 状态：`ceph pg stat` 与 `ceph pg dump pgs_brief`（抽样）

4) cephadm 编排态：`ceph orch ps --daemon_type mon/mgr/osd`