一个集群的系统日志都一样的报错，怎么排查

报错图片

CAS/CVK 集群全部节点 message 日志大量 print_req_error: I/O error
现象：集群所有 CVK 节点/var/log/messages都刷大量print_req_error: I/O error，日志膨胀到 26G；网卡 ethtool、ovs‑appctl ovs 状态显示正常。
关键点：全部节点同时报，不是单台本地磁盘硬件故障；单节点磁盘故障只会本节点报错，不会集群全部节点同步输出 I/O error。
print_req_error是 Linux 块层输出，含义：块设备 IO 请求提交返回 I/O 错误；不一定是本地硬盘，大概率是Ceph 分布式存储 rbd 块设备 IO 报错（CAS 底层虚拟机磁盘是 Ceph RBD）。
第一步区分：错误来自本地磁盘，还是 Ceph RBD 块设备
bash
# 查看messages报错上下文，看报错对应的设备名
grep print_req_error /var/log/messages | head -20
如果设备是sda/sdb等本地 sdX → 本地硬盘问题。
如果设备是rbd0/rbd125这类 rbd 设备 → Ceph 存储返回 IO 错误，这是集群所有节点同时报的最常见根因。
你集群全部节点同时打日志，90% 场景是 Ceph 后端返回 IO 错误，各个 CVK 主机上的 rbd 客户端（libvirt/qemu）收到错误，内核打印 print_req_error，不是物理网卡、OVS 虚拟交换机故障。
ethtool、ovs‑appctl 看的是网络二层状态，网络通，不代表 Ceph OSD 读写无报错。网络链路通 ≠ 存储业务 IO 正常。
典型触发原因（集群全部节点同时报）
Ceph 集群不健康：OSD 宕机、PG 状态异常、backfill/rebalance 回填风暴
Ceph 集群处于 degraded 降级状态，大量 RBD 卷 IO 返回 error，所有 CVK 节点（RBD 客户端）同步打印print_req_error:I/O error，打满 messages 日志。
存储网络问题：存储网卡 / 交换机存在丢包、错包、MTU 不匹配。ovs 状态 up，但是有丢包，Ceph 客户端与 OSD 之间报文丢包，RBD IO 超时返回 I/O error。
ethtool 看没有 errors，不一定真实，要看ethtool -S ethX精细统计，看 rx_errors、rx_dropped、rx_miss。
Ceph OSD 磁盘慢盘，磁盘响应超时，IO 请求超时返回 I/O error。
CAS/CVK 内核 bug，老版本 CAS 存在 rbd 客户端 print_req_error 日志疯狂打印的 bug，日志文件暴涨。
排查步骤，按顺序执行
1、登录 CVM（CAS 管理节点）检查 Ceph 整体健康状态
bash
ceph health detail
ceph -s
ceph osd tree
ceph pg stat
重点看：
HEALTH_ERR / HEALTH_WARN；是否 OSD down；PG 是否 degraded、stuck、unclean。
只要 Ceph 不是 HEALTH_OK，就会出现 RBD IO 报错，所有 CVK 节点内核输出 print_req_error。
2、定位是 RBD 设备 IO 错误（最可能）
bash
#抓取报错上下文，确认设备
grep -A5 -B5 print_req_error /var/log/messages | head -100
看到rbd设备名，确认是 Ceph RBD 返回 IO 错误。
该报错是CVK 客户端内核打印，真实故障点在后端 Ceph 集群，不是 CVK 本地硬件。
3、检查存储网络（CVK <-> OSD）
ovs‑appctl 只看虚拟交换机状态，要看物理网卡精细统计：
bash
#存储网物理网卡，替换成实际存储网卡名称
ethtool -S eth-storage | grep -E "drop|error"
看是否有丢包、错包。
检查存储网 MTU，Ceph 存储网建议 MTU=9000 巨帧，所有节点、交换机端口统一 MTU。
MTU 不一致，小包通大包丢，ovs 状态 up，但是 Ceph 大 IO 报文分片异常，产生 IO error。
4、检查 OSD 磁盘状态（CVM 执行）
bash
ceph osd perf
看 OSD 延迟，是否存在大量 OSD 延迟过高（慢盘）。
bash
ceph osd dump | grep slow
慢盘会直接导致客户端 IO 超时，报 I/O error。
5、日志暴涨临时应急处理
/var/log/messages已经 26G，占用磁盘空间风险。
不要直接 rm 删除 messages，rsyslog 还持有句柄，磁盘空间不会释放。
bash
#清空日志正确操作
> /var/log/messages
#重启rsyslog
systemctl restart rsyslog
同时配置 rsyslog 日志轮转，防止再次无限膨胀。
治标不治本，必须解决底层 Ceph IO 问题，否则还会快速打满。
区分容易踩坑误区
ethtool看网卡 error 计数为 0 ≠ 存储网无丢包。要用 ethtool -S 看细粒度统计。
ovs‑appctl show显示端口 up，只代表 OVS 虚拟链路状态，无法检测 Ceph 业务层面的报文丢包。
全部 CVK 节点同时报，排除单节点本地磁盘故障，根因指向 Ceph 集群层面（OSD、PG、存储网络、慢盘）。
版本提示
老版本 CAS（如 CAS‑E0513P03 及更早）存在已知问题：Ceph 轻微降级场景，CVK 内核疯狂刷屏 print_req_error，日志爆炸。确认 CAS 版本，建议升级到稳定补丁版本。
业务影响说明
print_req_error:I/O error代表虚拟机磁盘 IO 报错：虚拟机内部会出现磁盘卡顿、iohang、虚拟机卡死，严重会虚拟机磁盘只读。
快速判断总结
全部节点同时报 → 优先查 Ceph 集群健康状态 ceph‑s；
确认报错设备是 rbd 设备；
检查存储网络 MTU、精细丢包统计；
检查 OSD 性能、慢盘；
临时处理日志，跟进 CAS 版本是否存在已知 bug。