1. Slow OSD heartbeats
# ceph -s
health: HEALTH_WARN
Slow OSD heartbeats on back (longest 6181.010ms)
Slow OSD heartbeats on front (longest 5953.232ms)OSDs之间会相互测试（ping）访问速度，若两个OSDs之间的连接延迟高于1s，则表示OSDs之间的延迟太高，不利于CEPH集群的数据存储和访问。两个OSDs之间可以通过内网（存储服务器之间 / back）检测其延迟，也可以通过外网（存储服务器到使用服务器 / front）检测其延迟。若延迟过高，会将相应的OSDs down掉，进而可能导致CEPH数据丢失。
一般情况下OSDs之间延迟高的原因是因为网络原因导致的。可能是某台存储服务器重启网络导致，或网线出问题导致。前者的时间会逐渐变小，最后恢复正常，后者则问题一直存在。通过查看详细的OSDs延迟信息查找延迟较高的主机，再进行解决。
# ceph health detail
[WRN] OSD_SLOW_PING_TIME_BACK: Slow OSD heartbeats on back (longest 11846.602ms)
Slow OSD heartbeats on back from osd.12 [] to osd.25 [] 11846.602 msec
Slow OSD heartbeats on back from osd.8 [] to osd.17 [] 3617.281 msec
Slow OSD heartbeats on back from osd.16 [] to osd.27 [] 2784.517 msec
Slow OSD heartbeats on back from osd.21 [] to osd.17 [] 1678.064 msec
Slow OSD heartbeats on back from osd.11 [] to osd.15 [] 1675.884 msec
Slow OSD heartbeats on back from osd.20 [] to osd.13 [] 1073.790 msec
[WRN] OSD_SLOW_PING_TIME_FRONT: Slow OSD heartbeats on front (longest 11427.677ms)
Slow OSD heartbeats on front from osd.12 [] to osd.25 [] 11427.677 msec
Slow OSD heartbeats on front from osd.8 [] to osd.17 [] 3787.868 msec
Slow OSD heartbeats on front from osd.16 [] to osd.27 [] 3465.298 msec
Slow OSD heartbeats on front from osd.11 [] to osd.15 [] 1469.591 msec
Slow OSD heartbeats on front from osd.21 [] to osd.17 [] 1341.135 msec
Slow OSD heartbeats on front from osd.20 [] to osd.13 [] 1224.235 msec
Slow OSD heartbeats on front from osd.5 [] to osd.16 [] 1101.175 msec
通过以上信息查看，可以发现有一台主机和其它主机的OSDs延迟都比较高，将该主机的光纤网线拔下擦拭干净并重新插上得以解决。2. slow ops
# ceph -s
21 slow ops, oldest one blocked for 29972 sec, mon.ceph1 has slow ops先保证所有存储服务器上的时间同步一致，再重启相应主机上的moniter服务解决。
3. pgs not deep-scrubbed in time
# ceph -s
47 pgs not deep-scrubbed in timeCEPH系统每1~1.5天对所有的PGs进行一致性检验（scrub，通过文件的元数据信息检验PG在各OSDs上对应的对份数据是否完整一致，速度很快）。对每个PG进行一致性检验时，有一定概率转换为深度一致性检验（deep-scrub，通过文件内容来 检验PG在各OSDs上对应的对份数据是否完整一致，速度很慢，非常消耗磁盘读取性能 ）。若设置概率为5%，则需要20~30天才能对所有的PGs进行深度一致性检验。而默认的osd_deep_scrub_interval阈值为1周，当有PGs超过2周未能进行deep-scrub时，则其会进行警报。修改该参数阈值为一个月时间(60*60*24*30)，从而消除警告。
ceph config set global osd_deep_scrub_interval 2592000 4. MDS cache is too large
ceph config set mds mds_cache_memory_limit 10GB ceph config dump
当MDS使用的缓存过高，比设定的阈值高很多时，则有此警告信息。使用如上命令设置更高的MDS缓存阈值，即可消除次警告信息，但会消耗更多的内存。使用config dump命令可以查看各项参数阈值信息。
此外，可能增大了mds_cache_memory_limit参数后，过了一段时间后仍然提示该警告，检测发现MDS缓存使用又超过新设定值的1.5倍大小了。此时，可以考虑设置多个活动状态的MDS服务。
# 先开启3台服务器的MDS服务，确保这3台服务器的内存是够用的，最好这3台服务器的内存更大。 ceph orch apply mds cephfs ceph106,ceph107,ceph109 ceph fs set cephfs max_mds 3 # 由于激活了3台服务器的MDS，缺少备用的MDS服务。再增加一个备用的MDS服务主机。 ceph orch apply mds cephfs ceph106,ceph107,ceph109,ceph110
5. Client node18 failing to respond to cache pressure
表示node18主机和MDS服务之前的响应较慢，若过一会儿就显示health_ok，则不用管它。若是长期显示该警告，则在对应的node18主机上卸载ceph文件系统后重新挂载即可。
客户端在使用相应数据时，MDS服务端则将其数据缓存到服务器的内存中。当MDS服务端需要减少缓存消耗时，则会给客户端发送相应的请求。此时，客户端响应过慢，则提示此警告信息。若一直如此，会导致MDS服务器缓存无法释放，内存消耗持续增加甚至导致宕机。
ceph集群提供元数据服务，则客户端可以提挂载ceph文件系统。客户端访问数据时，则在客户端和元数据服务器中都缓存相应的数据。元数据服务器会和客户端inode占用情况来消减缓存。当客户端响应太慢，则会报错“failing to respond to cache pressure” or MDS_HEALTH_CLIENT_RECALL。若确实是客户端负荷较大，是正常读写操作，可以考虑增大mds_recall_warning_decay_rate参数的值（默认为60s），从而消除警告。
可以查询ceph客户端的ID号及其使用inode数（num_caps的值）。
ceph tell mds.0 session ls谨慎使用如下命令踢出目标客户端或全部客户端。
ceph tell mds.0 session evict id=11134635
ceph tell mds.0 session evict踢出客户端是将客户端加入了黑名单，可以使用如下命令查看黑名单信息或移出黑名单。虽然移出黑名单，可能还不能让客户端正常挂载ceph文件系统，因此需要谨慎处理。
ceph osd blacklist ls
ceph osd blacklist rm 192.168.20.1:0/1498586492
ceph osd blacklist clear6. Reduced data availability: 4 pgs inactive, 4 pgs incomplete
当有pgs出现incomplete时，表明pgs对应的OSDs存活数量少于最小副本数。因此，其对应的数据无法读写，处于reduced状态，会导致MDS服务出问题，提示如下报错信息，示例：
3 MDSs report slow metadata IOs 2 MDSs report slow requests 2 MDSs behind on trimming Reduced data availability: 4 pgs inactive, 4 pgs incomplete pg 5.6de is incomplete, acting [254,356,222,352,111,247,100,133,351,206] (reducing pool cephfs_data min_size from 8 may help; search ceph.com/docs for 'incomplete') pg 5.6e9 is incomplete, acting [276,244,357,358,221,321,311,229,314,351] (reducing pool cephfs_data min_size from 8 may help; search ceph.com/docs for 'incomplete') pg 5.73b is incomplete, acting [186,279,351,247,293,354,359,220,181,283] (reducing pool cephfs_data min_size from 8 may help; search ceph.com/docs for 'incomplete') pg 5.eda is incomplete, acting [164,157,120,227,353,351,295,269,95,354] (reducing pool cephfs_data min_size from 8 may help; search ceph.com/docs for 'incomplete')
此时，需要修复pgs。
# 查询pg信息（pg id 为 5.6de）
ceph pg 5.6de query
# 强行重建pg
ceph osd force-create-pg 5.6de --yes-i-really-mean-it
7. failed to probe daemons or devices stderr:Non-zero exit code 125 from /bin/podman
由于Ceph存储集群中个别服务器的podman容器出问题，导致相应服务启动失败。报告警告如下：
[WRN] CEPHADM_REFRESH_FAILED: failed to probe daemons or devices
host ceph105 ceph-volume inventory failed: cephadm exited with an error code: 1, stderr:Non-zero exit code 125 from /bin/podman run --rm --ipc=host --net=host --entrypoint stat -e CONTAINER_IMAGE=docker.io/ceph/ceph:v15 -e NODE_NAME=ceph105 docker.io/ceph/ceph:v15 -c %u %g /var/lib/ceph
stat:stderr Error: readlink /var/lib/containers/storage/overlay/l/HMGABIBEWBRXOSBT4JLOKQIKDA: no such file or directory
Traceback (most recent call last):
File "", line 6112, in
File "", line 1299, in _infer_fsid
File "", line 1382, in _infer_image
File "", line 3581, in command_ceph_volume
File "", line 1477, in make_log_dir
File "", line 2084, in extract_uid_gid
RuntimeError: uid/gid not found
执行以下命令时，会有如上报错。而正常的存储节点则不会报错。
cephadm shell该类报错表示podman的docker容器出错。查找出错的存储节点：
ceph orch ps | grep error在各存储节点重新pull相应的docker镜像：
cephadm pull
podman pull ceph/ceph:v15
# 以上两个命令都可以达到目的，后者能看到下载的速度，以免等待较长时间下载几百M的文件而不清楚进度。
# 重新pull镜像后，会提升ceph版本。不会影响使用检查podman的docker镜像
podman images
podman ps最后重启服务器或重启CEPH服务。
8. mds.cephfs.ceph109.avzzqn(mds.1): Behind on trimming (594/128) max_segments: 128, num_segments: 594
有MDS服务器报警：
[WRN] MDS_TRIM: 2 MDSs behind on trimming
mds.cephfs.ceph109.avzzqn(mds.1): Behind on trimming (594/128) max_segments: 128, num_segments: 594
mds.cephfs.ceph106.hggsge(mds.0): Behind on trimming (259/128) max_segments: 128, num_segments: 259
MDS服务器将元数据以segments(object)方式存放，当MDS中的segments数量超出mds_log_max_segments的设置值（默认为128）时，MDS服务开始启动Trimming，即将segments数据进行回写。当MDS中的segments数超过设定值两倍时，开始报警Behind on trimming信息。当MDS服务器内存足够时，推荐增大mds_log_max_segments参数值。
ceph config set mds mds_log_max_segments 10249. mds N slow requests are blocked > 30 secs
MDS服务报警：
[WRN] MDS_SLOW_REQUEST: 3 MDSs report slow requests mds.cephfs.ceph109.avzzqn(mds.1): 29 slow requests are blocked > 30 secs mds.cephfs.ceph110.sfagxf(mds.2): 1 slow requests are blocked > 30 secs mds.cephfs.ceph106.hggsge(mds.0): 3 slow requests are blocked > 30 secs
以上报警表示MDS响应慢，原因可能是：mds服务运行太慢、底层pg或OSD出问题导致写入日志未确认、或BUG。通过设置mds_op_complaint_time值为3000，问题依旧。
出现此警告时，OSD未报错。而mds服务运行应该正常，内存也足够用。通过阵列卡检测硬盘，发现有两台服务器分别有一块硬盘没有检测到。推测是相应的硬盘出问题，而OSD还未反应过来，带后续观察。
10. insufficient standby MDS daemons available
当有mds服务crash的时候，候选的mds则补上。此时，已经连接上的计算服务器还是可以正常访问ceph存储。但是，新的计算服务器无法挂载ceph文件系统。
解决方法是，ssh登陆到mds服务有crash的服务器，然后重启其mds服务。再登陆备用的mds服务器，重启其mds服务。
ssh ceph107
systemctl restart ceph-8f1c1f24-59b1-11eb-aeb6-f4b78d05bf17@mds.cephfs.ceph106.hggsge.service
ssh ceph102
systemctl restart ceph-8f1c1f24-59b1-11eb-aeb6-f4b78d05bf17@mds.cephfs.ceph102.imxzno.service
11. OSD_TOO_MANY_REPAIRS: Too many repaired reads on 1 OSDs
当某个OSD对应的磁盘有坏道时，CEPH系统对PGs进行deep srub的一致性检测时，会检测到某个OSD上同时又多个PGs出问题，于是可能出现以该警告。即使对所有的PGs进行修复后，该警报也不会消失。
[root@ceph101 ~]# ceph health detail
HEALTH_WARN Too many repaired reads on 1 OSDs
[WRN] OSD_TOO_MANY_REPAIRS: Too many repaired reads on 1 OSDs
osd.174 had 21 reads repaired
若想要解决该警报，进入对应的CEPH主机，重启对应的OSD服务即可。
ssh ceph105
systemctl restart ceph-osd@174.service
12. RECENT_CRASH: 2 daemons have recently crashed
当CEPH有daemons奔溃情况时，虽然解决问题后，但相关crashed警告信息不会消失。比如当有磁盘出现坏道导致OSD服务奔溃自动重启，虽然CEPH系统没有问题，但留下了警告信息。
[root@ceph101 ~]# ceph health detail
HEALTH_WARN 2 daemons have recently crashed
[WRN] RECENT_CRASH: 2 daemons have recently crashed
osd.174 crashed on host ceph105 at 2022-09-02T22:09:29.443817Z
osd.174 crashed on host ceph105 at 2022-09-02T23:55:25.357799Z
使用如下命令清除并归档警告信息：
ceph crash archive-all
13. 1 clients failing to advance oldest client/flush tid
正常情况下客户端读写任务完成后，则通知MDS服务器释放资源，并更新tid。若客户端和MDS不能正常沟通了，可能导致tid一直不更新，从而会导致MDS中的内存不能释放，继而出现segment不能trim的情况，同时导致 MDSs behind on trimming 报警。此时，将MDS服务器重启即可解决。