ceph:HEALTH_ERR 41 pgs are stuck inactive for more than 300 seconds;

在部署Ceph时遇到集群状态异常,主要表现为PGs处于stale、inactive和unclean状态。通过运行`cephhealthdetail`命令识别问题PG,并使用`ceph pg force_create_pg <pgid>`命令强制创建PG来解决stale问题。对于inactive和unclean状态的PG,执行`ceph pg map <pg>`和重启OSD服务进行修复。经过处理,大部分PG问题已解决,但仍有部分PG处于inactive和unclean状态。

1、背景

今天学习ceph部署时,发现集群状态异常

ceph health
HEALTH_ERR 21 pgs are stuck inactive for more than 300 seconds; 21 pgs stale; 21 pgs stuck stale

在这里插入图片描述

猜测:测试添加osd和删除osd时,没有清理干净或者没有使用正确的方法清理

2、处理办法

解決方法就是用 ceph pg force_creat_pg <pgid> 去覆盖那个有问题的 pg

# 查看有问题的PG
ceph health detail
HEALTH_ERR 22 pgs are stuck inactive for more than 300 seconds; 21 pgs stale; 1 pgs stuck inactive; 21 pgs stuck stale; 1 pgs stuck unclean
pg 0.18 is stuck inactive for 385.978354, current state creating, last acting [0]
pg 0.18 is stuck unclean for 385.978358, current state creating, last acting [0]
pg 0.38 is stuck stale for 5228.614958, current state stale+active+clean, last acting [1]
pg 0.2d is stuck stale for 5228.614920, current state stale+active+clean, last acting [1]
pg 0.2c is stuck stale for 5198.568749, current state stale+active+clean, last acting [2]
pg 0.2b is stuck stale for 5228.614940, current state stale+active+clean, last acting [1]
pg 0.2a is stuck stale for 5198.568753, current state stale+active+clean, last acting [2]
pg 0.1a is stuck stale for 5228.614950, current state stale+active+clean, last acting [1]
pg 0.1b is stuck stale for 5228.614951, current state stale+active+clean, last acting [1]
pg 0.d is stuck stale for 5198.568803, current state stale+active+clean, last acting [2]
pg 0.c is stuck stale for 5228.614961, current state stale+active+clean, last acting [1]
pg 0.22 is stuck stale for 5198.568796, current state stale+active+clean, last acting [2]
pg 0.1c is stuck stale for 5228.614956, current state stale+active+clean, last acting [1]
pg 0.5 is stuck stale for 5198.568804, current state stale+active+clean, last acting [2]
pg 0.3c is stuck stale for 5228.614978, current state stale+active+clean, last acting [1]
pg 0.3e is stuck stale for 5198.568821, current state stale+active+clean, last acting [2]
pg 0.34 is stuck stale for 5228.614975, current state stale+active+clean, last acting [1]
pg 0.1d is stuck stale for 5228.614962, current state stale+active+clean, last acting [1]
pg 0.20 is stuck stale for 5228.614962, current state stale+active+clean, last acting [1]
pg 0.36 is stuck stale for 5228.614981, current state stale+active+clean, last acting [1]
pg 0.1f is stuck stale for 5198.568809, current state stale+active+clean, last acting [2]
pg 0.35 is stuck stale for 5228.614983, current state stale+active+clean, last acting [1]
pg 0.1e is stuck stale for 5228.614968, current state stale+active+clean, last acting [1]

覆盖那个有问题的pg

cat pg_id.sh
#!/bin/bash

PG_ID=(
0.18
0.18
0.38
0.2d
0.2c
0.2b
0.2a
0.1a
0.1b
0.d 
0.c 
0.22
0.1c
0.5 
0.3c
0.3e
0.34
0.1d
0.20
0.36
0.1f
0.35
0.1e
)

for id in ${PG_ID[@]};do
  echo $id 
  ceph pg force_create_pg $id
done

# 执行
sh pg_id.sh

问题特别多可以使用一下命令去跑

for pg in `ceph health detail | grep "stale+active+undersized+degraded" | awk '{print $2}' | sort | uniq`;
do
  ceph pg force_create_pg $pg
done

在这里插入图片描述
再次查看健康信息

ceph health detail
HEALTH_ERR 1 pgs are stuck inactive for more than 300 seconds; 1 pgs stuck inactive; 1 pgs stuck unclean
pg 0.18 is stuck inactive for 674.102608, current state creating, last acting [0]
pg 0.18 is stuck unclean for 674.102613, current state creating, last acting [0]

在这里插入图片描述
看来使用覆盖的方式处理的是stale 的问题,还存在一个inactive unclean 的问题
解决creating

for pg in `ceph health detail | grep "creating" | awk '{print $2}' | sort | uniq`;
do
  ceph pg map $pg
done
# 执行完成后重启所有的osd服务
systemctl restart ceph-osd@0

在这里插入图片描述
重启服务
在这里插入图片描述
在这里插入图片描述

<think>好的,我需要帮助用户理解和优化Ceph健康状态监控告警规则,特别是配置和排查ceph_health_status的Prometheus告警规则。首先,我得回忆一下Ceph的健康检查机制。用户提到引用中的HEALTH_WARN和health-code,所以需要先了解Ceph如何生成健康状态,比如通过ceph health命令和相关的健康代码,比如POOL_TOO_FEW_PGS。 接下来,用户想用Prometheus来监控这个指标,所以需要知道如何将Ceph的健康状态导出到Prometheus。通常,这可以通过Ceph的exporter,比如ceph_exporter或者Prometheus的ceph-mgr插件。然后,在Prometheus中配置相应的告警规则,基于ceph_health_status指标。 首先,配置部分可能需要以下步骤:确保Ceph集群已经集成了Prometheus监控,比如通过启用mgr的prometheus模块。检查是否有ceph_health_status指标被正确暴露。然后,在Prometheus的告警规则配置文件中定义规则,当ceph_health_status的状态不为0(即不是HEALTH_OK)时触发告警。但需要更具体的健康状态,比如根据不同的健康代码(如POOL_TOO_FEW_PGS)设置不同的告警级别,可能需要更复杂的处理,比如利用指标中的标签或者额外的查询。 然后是排查部分,如果告警没有正确触发,可能需要检查exporter是否正常收集数据,Prometheus是否能正确抓取到该指标,以及告警规则的条件是否正确。比如,ceph_health_status的值对应不同的健康状态,比如0是OK,1是WARN,2是ERR。所以告警规则可能需要根据这个值来判断。但用户引用中提到的是具体的健康代码,这时候可能需要结合其他指标或者日志信息来细化告警。 另外,用户引用中的ceph health mute命令可以用来临时静音某些健康警告,这可能影响监控结果,需要确保在配置告警时考虑到静音状态,或者排除已被静音的问题。 还可能需要注意,Ceph的健康状态可能包含多个问题,比如同时存在多个HEALTH_WARN,这时候需要告警规则能够处理多个状态的情况,可能需要使用正则表达式或者更复杂的逻辑来判断。 此外,用户提到的k8s中的pod状态,可能与Ceph集群的健康状态相关,比如CSI插件是否正常运行,存储后端是否正常。这可能需要在排查时检查相关pod的日志,确保Ceph集群与k8s的集成没有问题。 总结步骤应该是:配置Exporter暴露指标,确认指标存在,编写Prometheus规则,测试告警触发,处理静音状态,细化告警规则到具体健康代码,结合日志和集群状态进行排查。</think>### 理解与配置Ceph健康状态监控告警规则 #### **1. 配置Ceph健康状态指标暴露** - **启用Ceph MGR Prometheus模块** 确保Ceph MGR的`prometheus`模块已启用,用于暴露集群指标: ```bash ceph mgr module enable prometheus ``` 验证指标是否生成: ```bash curl http://<mgr-host>:9283/metrics | grep ceph_health_status ``` 指标`ceph_health_status`的取值为: - `0`: HEALTH_OK - `1`: HEALTH_WARN - `2`: HEALTH_ERR [^1] - **集成到Prometheus** 在Prometheus配置文件中添加Ceph MGR的抓取目标: ```yaml scrape_configs: - job_name: 'ceph' static_configs: - targets: ['<mgr-host>:9283'] ``` #### **2. 编写Prometheus告警规则** 在`alertmanager.rules`中定义告警规则,区分警告和错误级别: ```yaml groups: - name: Ceph Health rules: - alert: CephClusterWarning expr: ceph_health_status == 1 for: 5m annotations: summary: "Ceph集群处于警告状态 (HEALTH_WARN)" description: "集群健康状态码: {{ $value }},需检查具体健康代码。参考命令: ceph health detail " - alert: CephClusterError expr: ceph_health_status == 2 for: 1m annotations: summary: "Ceph集群处于错误状态 (HEALTH_ERR)" description: "集群健康状态码: {{ $value }},需立即处理!参考命令: ceph health detail " ``` #### **3. 高级优化:基于健康代码细化告警** 若需针对特定健康代码(如`POOL_TOO_FEW_PGS`)配置告警,需结合Ceph日志或自定义指标: - **方法1:通过日志监控** 使用Prometheus的`loki`或`grok_exporter`解析Ceph日志,提取健康代码并生成指标。 - **方法2:自定义脚本** 编写脚本调用`ceph health detail`解析健康代码,并通过`textfile_collector`导出为Prometheus指标。 #### **4. 排查常见问题** - **指标未暴露** 检查MGR模块状态:`ceph mgr services`,确认端口`9283`可访问[^2]。 - **告警未触发** 验证Prometheus是否成功抓取指标:`http://<prometheus-host>:9090/targets`。 - **静音状态干扰** 若使用了`ceph health mute`命令,需在告警规则中排除静音时间段,或通过`ceph health unmute`恢复告警。 #### **5. 关联Kubernetes集群状态** 若Ceph用于Kubernetes存储(如通过`ceph-csi`),需同时监控相关Pod: ```bash kubectl get pod -n kube-system -l app=ceph-csi-rbd # 检查CSI插件状态[^2] ``` 若Pod异常(如非`Running`状态),可能影响Ceph存储功能,需结合Ceph告警综合排查。 --- ###
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值