3. etcd 性能基准与关键指标解读

在构建云原生日志平台时，etcd 作为 Kubernetes 和 Loki 的元数据存储核心，其性能直接决定了整个集群的稳定性与响应速度。本章将深入解读 etcd 的五大核心性能指标：延迟、吞吐量、DB 大小、WAL 写入速率以及Leader 选举次数。理解这些指标是后续进行压测、配置告警规则和定位故障的基础。

3.1 核心指标全景图

etcd 的性能基准可以从“速度”、“容量”和“稳定性”三个维度进行衡量。下表总结了五大核心指标及其对集群健康的影响：

3.2 延迟与吞吐量：速度的双刃剑

延迟衡量的是单个请求从发出到收到响应所花费的时间，通常关注 P99 分位值。吞吐量则衡量系统在单位时间内能处理的请求总数。两者相互制约：当请求量（吞吐量）超过系统处理能力时，请求会在队列中堆积，导致延迟急剧上升。

在 etcd 中，影响延迟和吞吐量的主要因素包括：

• 磁盘性能：etcd 对写入延迟极其敏感，建议使用 SSD 并确保 fsync 操作高效。
• 网络延迟：集群节点间的 RTT 会影响 Raft 共识协议的提交速度。
• 请求大小：单个 key-value 过大（超过 1MB）会显著增加序列化和网络传输开销。

下面的 SVG 图展示了在压测过程中，随着并发请求数（吞吐量）增加，请求延迟的变化趋势：

3.3 DB 大小与 WAL 写入速率：容量的晴雨表

DB 大小反映了 etcd 当前存储的数据量。etcd 使用 B+ 树存储所有历史版本，即使 key 被更新或删除，旧版本数据仍会保留，直到触发压缩（Compaction）和碎片整理（Defragmentation）。如果 DB 大小持续增长且不进行压缩，会导致：

• 内存占用过高（etcd 将 DB 文件映射到内存）。
• 查询性能下降（遍历更多版本数据）。
• 备份和恢复时间变长。

WAL（Write-Ahead Log）写入速率则直接反映了集群的写入压力。每一次 etcd 的写入操作，都会先追加到 WAL 文件，然后才更新内存中的状态机。WAL 写入速率过高可能意味着：

• 集群正在经历大量写入操作（如频繁创建/删除 Pod）。
• 磁盘 I/O 成为瓶颈，导致写入延迟增加。

3.4 Leader 选举次数：稳定性的基石

etcd 通过 Raft 共识算法保证数据一致性。在一个稳定的集群中，Leader 选举只发生在集群初始化或 Leader 节点故障时。频繁的 Leader 变更（etcd_server_leader_changes_seen_total 指标持续增加）是集群不稳定的直接信号。

导致 Leader 频繁选举的常见原因包括：

1. 网络分区：Follower 节点无法与 Leader 心跳通信，触发选举超时。
2. 磁盘 I/O 抖动：Leader 节点因磁盘写入延迟过高，无法及时发送心跳。
3. 资源争抢：CPU 或内存被其他进程抢占，导致 etcd 进程被操作系统调度延迟。

下面的 SVG 图展示了 Raft 集群中一次正常的 Leader 选举流程：

3.5 指标关联分析与压测实践

在压测沙盘中，这些指标并非孤立存在。例如，当压测工具模拟大量日志写入时，我们会观察到：

1. WAL 写入速率首先飙升，伴随磁盘 I/O 利用率上升。
2. 如果磁盘性能不足，请求延迟开始增加。
3. 延迟增加可能导致 etcd 节点间心跳超时，触发 Leader 选举。
4. Leader 选举期间，集群短暂不可用，导致 吞吐量骤降。
5. 长期运行后，DB 大小持续增长，若不压缩，会进一步恶化性能。