ETCD 磁盘延迟指标验证分析报告

ETCD 磁盘延迟指标验证分析报告

生成时间: 2026-03-11
验证环境: -148 (QFusion 集群)
ETCD 版本: 3.5.6
分析目标: 验证etcd_disk_wal_fsync_duration_seconds与底层磁盘延迟的关系

一、执行摘要

二、ETCD 指标采集验证

2.1 ETCD Metrics 端点配置

通过kubectl get pod验证，ETCD Pod 配置如下：

# ETCD 启动参数中的 metrics 配置--listen-metrics-urls=http://127.0.0.1:2381

2.2 磁盘延���相关指标验证

Prometheus 中确认存在的 ETCD 磁盘延迟指标：

2.3 PromQL 查询示例

# WAL fsync P99 延迟 (毫秒) histogram_quantile(0.99, rate(etcd_disk_wal_fsync_duration_seconds_bucket[5m]) ) * 1000 # DB commit P99 延迟 (毫秒) histogram_quantile(0.99, rate(etcd_disk_backend_commit_duration_seconds_bucket[5m]) ) * 1000 # WAL fsync 平均延迟 (秒) rate(etcd_disk_wal_fsync_duration_seconds_sum[5m]) / rate(etcd_disk_wal_fsync_duration_seconds_count[5m])

三、底层磁盘延迟验证 (iostat)

3.1 磁盘布局信息

设备 大小 挂载点 用途 ───────────────────────────────────────────── /dev/vda 200G / 系统盘 /dev/vdb 200G /opt/qfusion ETCD 数据目录 /dev/vdc 200G /opt/qfusion1 其他数据

3.2 当前磁盘 I/O 状态

采集时间: 2026-03-11 (最近3次采样)

ETCD 数据磁盘 (/dev/vdb)

关键指标说明

3.3 空间使用情况

Filesystem Size Used Avail Use% Mounted on /dev/vdb 200G 68G 133G 34% /opt/qfusion /dev/vdc 200G 11G 190G 6% /opt/qfusion1

四、ETCD 指标 vs 底层磁盘延迟关系分析

4.1 I/O 延迟链路图

┌───────────────────────────────────────────────────────────────────���─┐ │ I/O 延迟链路 │ ├─────────────────────────────────────────────────────────────────────┤ │ │ │ 应用层 ETCD 内核层 磁盘物理层 │ │ │ │ │ │ │ │ ├─ 写操作 ──>│ │ │ │ │ │ ├─ write() ──>│ │ │ │ │ │ ├─ page cache ──>│ │ │ │ │ │ │ │ │ │ ├─ fsync() ──>├─ I/O 调度 ───>│ 磁盘写入 │ │ │ │ │ │ │ │ │<───────────┤ 返回 │ │ │ │ │ │ │ │ │ └─────┴────────────┴─────────────┴────────────────┴─────────────────┘ etcd_disk_wal_fsync_duration_seconds = ①②③ 整体耗时 底层磁盘延迟 = ③ 磁盘设备耗时

4.2 指标对应关系

4.3 判决树分析

ETCD WAL fsync 延迟高 │ ┌──────┴──────┐ │ │ oswbb w_await oswbb w_await 高 正常/低 │ │ │ ┌─────┴─────┐ │ 可能原因： │ 1. 文件系统延迟 │ 2. 内核参数 │ 3. 锁竞争 │ 4. ETCD 配置 │ ┌─────────┴─────────┐ │ │ oswbb %util 高 oswbb %util 低 │ │ 磁盘设备饱和 可能是： 1. 升级硬件 1. 磁盘性能问题 2. 分离负载 2. 阵列配置问题 3. 调整参数 3. 控制器瓶颈

五、OSWBB 工具匹配建议

5.1 OSWBB 相关指标

5.2 OSWBB 与 ETCD 指标匹配方法

方法一：时间戳关联分析

# 1. 同步采集时间# ETCD 指标采集kubectlexec-nkube-system etcd-xxx --sh-c\"wget -qO- http://127.0.0.1:2381/metrics">\etcd_metrics_$(date+%s).txt# oswbb 采集cd/root/oswbb&&./startOSWBB.sh6010# 2. 问题发生后，导出数据# 从 oswbb 归档中提取问题时间段的 iostat 数据# 3. 关联分析# 找到 ETCD 延迟峰值的时间点，查看同一时间 oswbb 的 w_await、svctm、%util

方法二：Prometheus + OSWBB 对比

importpandasaspddefanalyze_correlation(oswbb_file,etcd_metrics):""" 分析 oswbb 磁盘数据与 ETCD WAL fsync 的相关性 """# 读取 oswbb 数据oswbb=pd.read_csv(oswbb_file)# 关键指标etcd_wal_fsync=etcd_metrics['etcd_disk_wal_fsync_duration_seconds']oswbb_w_await=oswbb['w_await']# 写等待oswbb_svctm=oswbb['svctm']# 服务时间# 相关性分析correlation={'etcd_wal vs w_await':etcd_wal_fsync.corr(oswbb_w_await),'etcd_wal vs svctm':etcd_wal_fsync.corr(oswbb_svctm),}returncorrelation

5.3 场景判断指南

六、诊断建议

6.1 当前环境评估

结论: 当前环境磁盘 I/O 性能良好，无明显瓶颈。

6.2 当 ETCD 延迟告警触发时的排查步骤

# 1. 确认 ETCD 延迟指标kubectl port-forward-nqfusion svc/prometheus9090:9090--address127.0.0.1&curl-s"http://127.0.0.1:9090/api/v1/query?query=histogram_quantile(0.99,rate(etcd_disk_wal_fsync_duration_seconds_bucket[5m]))"# 2. 检查底层磁盘延迟iostat-x110|grepvdb# 3. 检查 ETCD 数据目录ls-lh/opt/qfusion/etcd/member/# 4. 检查文件系统类型df-T/opt/qfusion# 5. 检查磁盘调度器cat/sys/block/vdb/queue/scheduler# 6. 检查磁盘队列深度cat/sys/block/vdb/queue/nr_requests

6.3 优化建议

七、总结

7.1 核心结论

1. etcd_disk_wal_fsync_duration_seconds 不是底层磁盘延迟

   • 它是应用层视角的 fsync 总耗时
   • 包含文件系统、内核调度、设备 I/O 等多个环节

2. OSWBB 可以与 ETCD 指标匹配使用

   • 通过时间戳关联分析
   • 关键指标：w_await（写等待）、svctm（服务时间）、%util（利用率）

3. 当前环境 I/O 状态正常

   • 磁盘延迟低（w_await < 20ms）
   • 设备利用率正常（%util < 20%）

7.2 验证方法

# 快速验证脚本cat>check_etcd_disk_latency.sh<<'EOF' #!/bin/bash echo "=== ETCD WAL fsync P99 ===" kubectl exec -n kube-system $(kubectl get po -n kube-system | grep etcd | head -1 | awk '{print $1}') \ -- sh -c "wget -qO- http://127.0.0.1:2381/metrics" | \ grep etcd_disk_wal_fsync_duration_seconds_bucket echo "" echo "=== 磁盘 I/O 状态 ===" iostat -x 1 1 | grep -v "Linux\|avg-cpu\|Device" EOFchmod+x check_etcd_disk_latency.sh ./check_etcd_disk_latency.sh

八、参考资源