Ceph巡检
Ceph巡检
前置检查
指标解释：
获取指令：
判断条件：
告警级别：
Err：
Warn :
Info：
备注信息：
Ceph 集群
集群状态
-
集群整体 Health 状态
指标解释：
Ceph 集群的健康状态，分为三种情况：
HEALTH_OK
HEALTH_WARN
HEALTH_ERR获取指令：
ceph -s -f json |jq .health.status "HEALTH_WARN"判断条件：
根据输出判断告警级别：
Err："HEALTH_ERR"
Warn : "HEALTH_WARN" -
集群是否有慢请求
-
集群当前慢请求
指标解释：
集群当前存在的慢请求，可以通过ceph -s即时查询到，适用于卡顿时间较长的场景。获取指令：
ceph -s -f json | jq .health.checks.REQUEST_SLOW { "severity": "HEALTH_WARN", "summary": { "message": "39 slow requests are blocked > 32 sec. Implicated osds 5,6,7,9,11,13,14,17,19,33,34" } }判断条件：
当该字段存在时，即报警，根据慢请求的个数和持续时间来上调告警级别。
告警级别：
Err：慢请求个数 > 100个
Err：慢请求持续时间 > 60s
Warn: 剩余场景，即上面的39个慢请求大于32秒等。 -
集群历史慢请求总数
指标解释：
根据MON节点的 ceph.log，来查询集群是否存在历史慢请求，通常/var/log/ceph/ceph.log每小时输出一行，文件内容不会太大，当集群存在慢请求时，后记录之。并且需要处理最近一周的 ceph.log。由于日志会压缩，可以根据ceph.log-20201126.gz的大小预先判断集群是否发生过慢请求，如果大于 16KB，则认为发生过慢请求，再进行解压/过滤处理。获取指令：
MON 节点执行：
grep REQUEST_SLOW /var/log/ceph/ceph.log解压日志：
gunzip /var/log/ceph/ceph.log-*.gz判断条件：
存在即告警
告警级别：
Err：慢请求个数 > 100个
Err：慢请求持续时间 > 60s
Warn: 剩余场景。备注信息：
在过滤日志时，可以通过过滤
grep "Health check failed" |grep "REQUEST_SLOW"两个关键字来确定慢请求起始时间，通过过滤grep "Health check cleared" | grep "REQUEST_SLOW"来确定慢请求结束时间。
在时间区间内，可以通过先过滤REQUEST_SLOW来找到慢请求的个数和时间：Health check update: 138 slow requests are blocked > 32 sec.
最好统计出慢请求的数量的峰值和影响时长。 -
各个OSD历史慢请求数
指标解释：
有时候，集群会存在个别慢盘，慢请求会汇聚在这些个别OSD上，而ceph.log 不能明确指出哪些OSD汇聚了慢请求，因此需要再次分析OSD的日志来找出可能存在的慢盘。获取指令：
gunzip /var/log/ceph/ceph-osd.0.log-*.gz grep "slow requests" xxxx.log判断条件：
存在即告警，需要找出最长时间的慢请求数，和慢请求的峰值。
告警级别：
Err：慢请求个数 > 10个
Err：慢请求持续时间 > 60s
Warn: 剩余场景。备注信息：
可以通过以下指令查询到，当前OSD上卡住的慢请求详情，包括所影响到的客户端和影响时间，以此可以定位到影响到的虚拟机。需要在OSD所在物理机上执行，并且只能查到当前的慢请求。没有慢请求时输出为空
ceph daemon osd.0 ops可以通过下面的指令查询到，某个OSD最近的20条/最近600秒内的接受到的请求：
ceph daemon osd.0 dump_historic_ops可以通过两个参数来控制记录的条数和时间：
osd_op_history_duration = 600 osd_op_history_size = 20
-
-
PG长时间未scrub
指标解释：
有些运行比较久的Ceph集群，会关闭scrub，L版本中，关闭后，不会告警有多少PG多久未scrub/deep-scrub，需要打开以下配置才可以告警出来：mon_warn_not_deep_scrubbed = 1 mon_warn_not_scrubbed = 1获取指令：
查询集群是否有PG未deep-scrub
ceph -s -f json |jq .health.checks.PG_NOT_DEEP_SCRUBBED { "severity": "HEALTH_WARN", "summary": { "message": "32 pgs not deep-scrubbed in time" } }查询集群的未deep-scrub的PG的具体ID和时间：
ceph health detail -f json |jq .checks.PG_NOT_DEEP_SCRUBBED.detail [ { "message": "pg 4.2 not deep-scrubbed since 2020-12-02 07:17:39.066715" }, { "message": "pg 1.7 not deep-scrubbed since 2020-11-28 23:19:40.051078" } ]判断条件：
存在即告警
告警级别：
Err : 未deep-scrub的PG时间 > 1年
Warn ：0.5～1年
Info ：1-6个月备注信息：
scrub不需要告警，deep-scrub会触发scrub
-
PG inconsistent
指标解释：
在PG做scrub时，如果底层磁盘有坏道等场景，会触发PG三副本数据不一致，报HEALTH_ERR，PG状态为inconsistent，并且损坏的PG可能会卡慢请求，一旦请求发向了丢失的文件，慢请求会一直存在。
获取指令：
检测集群是否有PG inconsistent
ceph -s -f json |jq .health.checks.PG_DAMAGED { "severity": "HEALTH_ERR", "summary": { "message": "Possible data damage: 1 pg inconsistent" } }查询具体inconsistent的PG，以及它们所在的OSD：
ceph health detail -f json |jq .checks.PG_DAMAGED.detail [ { "message": "pg 1.1 is active+clean+inconsistent, acting [0]" }, { "message": "pg 1.2 is active+clean+inconsistent, acting [0]" } ]判断条件：
存在即告警
告警级别：
Err：存在即告警
备注信息：
在 ceph.log 中，可以查询到如下信息，可以计算得到丢失的对象数：
log [ERR] : 1.1 scrub : stat mismatch, got 181/373 objects, 0/0 clones, 181/373 dirty, 0/0 omap, 0/0 pinned, 0/0 hit_set_archive, 0/0 whiteouts, 741376/1527808 bytes, 0/0 hit_set_archive bytes.告警时，需要对查询到的信息进行归并处理，并提供以下告警结果：
哪些 PG 有inconsistent
这些 PG 汇聚在哪些OSD上
每个 PG丢失了多少对象 -
PG 状态是否异常
指标解释：
有些PG状态为 stale/down/incomplete/peering时，这部分PG不能提供IO服务，属于比较严重的异常，需要告警出来。
获取指令：
获取总揽：
ceph -s -f json |jq .health.checks.PG_AVAILABILITY { "severity": "HEALTH_WARN", "summary": { "message": "Reduced data availability: 32 pgs stale" } }获取详细信息：
ceph health detail -f json |jq .checks.PG_AVAILABILITY.detail [ { "message": "pg 1.0 is stuck stale for 9598.744882, current state stale+active+clean, last acting [0]" }, { "message": "pg 1.1 is stuck stale for 9598.744885, current state stale+active+clean+inconsistent, last acting [0]" } ]判断条件：
存在即告警
告警级别：
Err：存在即告警
备注信息：
告警时，需要对查询到的信息进行归并处理，并提供以下告警结果：
哪些 PG 状态有异常
这些 PG 异常的时间有多久，以小时为时间区间进行汇聚
汇聚这些PG所在的OSD，以异常PG的数量的OSD进行排序。 -
对象丢失 unfound
指标解释：
集群在日常运行中，可能因为一些异常，导致了对象的副本不一致或者版本落后，此时集群会报 object unfound，发送给unfound的object的IO 均会被阻塞，造成慢请求，此时需要告警出来。
获取指令：
ceph -s -f json |jq .health.checks.OBJECT_UNFOUND ceph health detail -f json |jq .checks.OBJECT_UNFOUND.detail判断条件：
存在即告警
告警级别：
Err：属于严重异常，存在即告警
备注信息：
需要汇聚PG所在的OSD，查看是否有OSD集中报错
需要列出所有的unfound的对象，以备后续确定影响范围
PG query 可能查询到造成丢失的原因，过滤blocked_by，使用如下指令，注意有即输出：ceph tell 1.0 query |jq .info.stats.blocked_by
