etcd 磁盘延迟飙高：从 fsync 到盘队列的定位顺序

Kubernetes 控制面、部分服务发现把 etcd 当强一致存储，磁盘一抖就会出现选举抖动、API Server 超时、租约大批过期。本帖按「先看延迟指标 → 再分 fsync/队列/邻居 → 最后做容量与隔离」整理排查顺序，命令以你们发行版为准。

一、先看哪些信号
1. etcd 指标：wal_fsync_duration_seconds、backend_commit_duration_seconds 的 P99；经验上 P99 长期 >10–25ms 就要警惕（SSD 健康时应远低于此）。
2. 对端：leader 变更频率、apply 滞后、慢请求日志。
3. 节点级：iostat 的 await/%util、磁盘队列深度、是否与其他写密集负载共盘。

二、定位顺序
1. 确认是 WAL fsync 慢还是 bbolt commit 慢：两者都高多半是盘或 IO 争用；只有 commit 高可能是后端库膨胀、碎片或大 value。
2. 看是否共盘：容器日志、镜像层、其他数据库若与 etcd 数据目录同块盘，尖峰会互相放大。
3. 网络与心跳：跨 AZ 高 RTT 会放大「感觉像磁盘慢」；先把 peer RTT 与丢包排除。
4. 空间与配额：盘将满、inode 耗尽、文件系统 remount 只读都会让 fsync 失败或排队。
5. 云盘突发积分：部分云盘基线 IOPS 很低，积分耗尽后延迟台阶式上升——对齐监控里的 burst balance。

三、缓解与架构
1. etcd 数据目录独占低延迟 SSD；关掉同盘的重写负载；必要时上本地 NVMe 而非网络盘。
2. 控制 value 大小与历史版本；定期 defrag（在维护窗、按官方流程），避免后端文件虚高。
3. 限流客户端：控制器与运算符别疯狂 watch/list；API Priority and Fairness 与 etcd 侧都能减负。
4. 监控告警：对 fsync P99、leader 变更、db 大小、盘利用率分别设阈，避免只盯 CPU。

四、验收与演练
1. 压测写入时同步看 fsync 直方图，而不是只看 QPS。
2. 演练「打满同盘写」与「云盘降速」两种故障，确认告警与切主行为可接受。
3. 变更记录：盘型、IOPS、是否本地盘、defrag 时间，方便回溯。

五、常见误区
- 一见超时就加副本，不先修盘；慢盘上的多数派只会一起抖。
- 把 defrag 当日常自动任务乱跑，可能在高峰触发长暂停。
- 忽略客户端重试风暴：盘一慢、客户端一重试，延迟更容易雪崩。

欢迎分享你们在托管 K8s 与自建 etcd 上遇到的盘型选型与 fsync 告警阈值经验。

etcd fsync P99 告警这条对车队调度库同样有启发——我们把任务状态写强一致存储时，也曾把日志盘和数据盘混在一起，高峰一到选举抖动。补充：除了看 wal_fsync，还建议把「客户端重试 QPS」和 fsync 延迟画在同一张图，避免盘一慢、重试一堆、延迟二次放大。独占低延迟盘比盲目加副本更管用。