ceph平台-未及时移除故障osd导致根目录100%问题的故障记录

项目场景：

一个甲方的ceph集群，osd日志拉满导致根目录100%

问题描述

甲方联系说有点问题，远程处理。
首先登陆到控制节点发现根目录满了，检查定位到日志目录，所有osd日志大小几乎一致。
然后检查所有存储节点都有类似问题。
打开日志文件分析原因，下面放三个osd日志的截图



全部在16:57 指向到secret_id:44281

原因分析：

千问的回答

1. auth: could not find secret_id=44281
   含义：Ceph Monitor（或 OSD）在验证某个客户端身份时，找不到 ID 为 44281 的密钥。
   ✅ 这个 secret_id 是 Ceph 内部生成的唯一标识，用于关联一个实体（如 osd.5）的认证密钥。
2. cephx: verify_authorizer could not get service secret for service osd secret_id=44281
   含义：使用 cephx 协议验证时，无法获取对应 osd 服务的密钥。
   ❌ 表明：该 OSD 的 keyring 已被删除、损坏，或未正确同步到 MON 数据库。
3. .accept: got bad authorizer
   含义：连接被拒绝，因为客户端提供的认证票据无效。
   ⚠️ 通常出现在：
   OSD 使用旧密钥尝试连接 MON
   OSD 被删除后仍在运行
   keyring 文件被手动修改或丢失

操作

感觉是坏掉的osd没有及时删除的问题。

第一步： 先处理根目录100%
所有ceph节点的所有osd日志追空

第二步：执行ceph osd命令
ceph命令没有返回，检查mon服务，全死。挨个mon节点重启mon服务

第三步：通过osd相关命令找到坏掉的osd，然后完全删除掉
执行删除命令后，集群进入恢复模式

第四步：观察集群恢复，同时不定期检查osd日志大小，看是否还有异常

forXin{1..14};dosshXX.XXX.X.$X'hostname ; rm -rf /var/log/ceph/*.gz ;ls -ln -h /var/log/ceph/ ';done

第五步：等待集群恢复完毕后，重启所有osd服务

第六步：持续多天检查osd日志大小和集群状态

解决方案：

osd坏了及时换盘，没有的话要及时完全删除掉