526互联

Ceph巡检

发布时间 2023-04-24 10:48:33作者: XU-NING

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

组件状态

宿主机