etcd/metrics.md at v3.2.17 · etcd-io/etcd · GitHub
etcd 监控可以帮助您更好地利用 etcd，特别用于是定位性能问题。etcd 服务提供了原生的指标接口。KubeSphere 监控系统提供了高度图形化和响应性强的仪表板，用于显示原生数据。
| 指标 | 描述 |
|---|---|
| 服务状态 | - 是否有 Leader 表示成员是否有 Leader。如果成员没有 Leader，则成员完全不可用。如果集群中的所有成员都没有任何 Leader，则整个集群完全不可用。 - 1 小时内 Leader 变更次数 表示集群成员观察到的 1 小时内 Leader 变更总次数。频繁变更 Leader 将显著影响 etcd 性能，同时这还表明 Leader 可能由于网络连接问题或 etcd 集群负载过高而不稳定。 |
| 库大小 | etcd 的底层数据库大小，单位为 MiB。图表中显示的是 etcd 的每个成员数据库的平均大小。 |
| 客户端流量 | 包括发送到 gRPC 客户端的总流量和从 gRPC 客户端接收的总流量。有关该指标的更多信息，请参阅 etcd Network。 |
| gRPC 流式消息 | 服务器端的 gRPC 流消息接收速率和发送速率，反映集群内是否正在进行大规模的数据读写操作。有关该指标的更多信息，请参阅 go-grpc-prometheus。 |
| WAL 日志同步时间 | WAL 调用 fsync 的延迟。在应用日志条目之前，etcd 会在持久化日志条目到磁盘时调用 wal_fsync。有关该指标的更多信息，请参阅 etcd Disk。 |
| 库同步时间 | 后端调用提交延迟的分布。当 etcd 将其最新的增量快照提交到磁盘时，会调用 backend_commit。需要注意的是，磁盘操作延迟较大（WAL 日志同步时间或库同步时间较长）通常表示磁盘存在问题，这可能会导致请求延迟过高或集群不稳定。有关该指标的详细信息，请参阅 etcd Disk。 |
| Raft 提议 | - 提议提交速率记录提交的协商一致提议的速率。如果集群运行状况良好，则该指标应随着时间的推移而增加。etcd 集群的几个健康成员可以同时具有不同的一般提议。单个成员与其 Leader 之间的持续较大滞后表示该成员缓慢或不健康。 - 提议应用速率记录协商一致提议的总应用率。etcd 服务器异步地应用每个提交的提议。提议提交速率和提议应用速率的差异应该很小（即使在高负载下也只有几千）。如果它们之间的差异持续增大，则表明 etcd 服务器过载。当使用大范围查询或大量 txn 操作等大规模查询时，可能会出现这种情况。 - 提议失败速率记录提议失败的总速率。这通常与两个问题有关：与 Leader 选举相关的临时失败或由于集群成员数目达不到规定数目而导致的长时间停机。 - 排队提议数记录当前待处理提议的数量。待处理提议的增加表明客户端负载较高或成员无法提交提议。 目前，仪表板上显示的数据是 etcd 成员的平均数值。有关这些指标的详细信息，请参阅 etcd Server。 |
