3. etcd 性能关键指标：延迟、吞吐量与稳定性

在构建多集群 etcd 压测沙盘时，必须精确掌握 etcd 的性能边界与健康状态。etcd 作为 Kubernetes 控制平面的核心数据存储，其性能直接决定了集群的响应速度与稳定性。本章将深入解析 etcd 的六大关键性能指标，并建立对应的告警分层策略。

3.1 延迟指标：P99 与 P999

延迟是衡量 etcd 响应速度的首要指标。在分布式系统中，平均延迟（Avg）容易掩盖长尾问题，因此业界普遍采用百分位延迟（P99、P999）作为核心监控对象。

• P99 延迟：表示 99% 的请求在小于或等于该值的时间内完成。通常用于衡量常规负载下的用户体验。etcd 官方建议 P99 延迟应 低于 10ms。
• P999 延迟：表示 99.9% 的请求在小于或等于该值的时间内完成。用于捕捉极端情况下的性能抖动，如网络闪断、磁盘 IO 毛刺或 Leader 选举。P999 延迟应 低于 50ms。

3.2 吞吐量指标：QPS

吞吐量（Queries Per Second, QPS）反映了 etcd 在单位时间内能处理的请求总数。QPS 与延迟并非线性关系：当 QPS 接近集群瓶颈时，延迟会急剧上升（即“拐点”）。

3.3 存储容量指标：DB 大小

etcd 的数据库文件（db）大小直接反映了集群中存储的键值对总量。过大的 DB 会导致性能下降、快照时间变长、恢复速度变慢。

• 健康范围：建议 DB 大小控制在 1GB ~ 2GB 以内。
• 警告阈值：DB 大小超过 4GB 时应触发 Warning 告警。
• 严重阈值：DB 大小超过 8GB 时应触发 Critical 告警，并立即启动 compaction 或历史数据清理。

# 预估 DB 大小（MB）
DB_SIZE_MB = (NUMBER_OF_KEYS * AVG_KEY_VALUE_SIZE_BYTES) / (1024 * 1024)
# 示例：100 万个 key，平均每个 key-value 1KB
DB_SIZE_MB = (1_000_000 * 1024) / (1024 * 1024) ≈ 976 MB

3.4 写入持久化指标：WAL 写入速率

WAL（Write-Ahead Log）是 etcd 保证数据持久化的核心机制。每次写入操作都会先追加到 WAL 文件，然后才更新内存中的状态机。WAL 写入速率反映了磁盘的写入压力。

3.5 集群稳定性指标：心跳间隔与快照频率

心跳间隔和快照频率是衡量 etcd 集群稳定性的两个关键参数，它们直接影响 Leader 选举的敏感度和数据恢复的速度。

3.5.1 心跳间隔（Heartbeat Interval）

Leader 节点向 Follower 节点发送心跳的间隔时间。默认值为 100ms。过短的心跳间隔会增加网络开销，过长则会导致 Leader 故障检测延迟。

• 监控指标：实际心跳延迟（Heartbeat Latency）应小于心跳间隔的 2 倍。
• 告警规则：如果连续 3 次心跳超时，应触发 Warning 告警；如果发生 Leader 选举，应触发 Critical 告警。

3.5.2 快照频率（Snapshot Frequency）

etcd 定期将内存中的状态机数据持久化到磁盘，生成快照文件。快照频率由 --snapshot-count 参数控制（默认 100,000 次写入触发一次快照）。

• 监控指标：快照生成时间（Snapshot Duration）应小于 30 秒。
• 告警规则：如果快照生成时间超过 60 秒，或快照文件大小超过 DB 大小的 50%，应触发 Warning 告警。

3.6 指标告警分层总览

将上述六大指标整合到统一的告警分层体系中，形成可执行的监控策略。下表总结了每个指标的告警级别与响应动作。