Etcd是Kubernetes中的组件，其角色非常重要，因为整个集群的状态信息都保存在其中，比如客户端提交的Deployment、DaemonSet、ConfigMap等信息。

Kubernetes中只有Api Server与Etcd通信，其他组件都是直接与Api Server进行通信，这里可以认为Etcd是Api Server组件的一部分，Api Server在Kubernetes集群中像一个仓库的库管员，将客户端提交过来的“货物”都存储在Etcd这个仓库中，其他组件通过询问库管员即Api Server来获取“货物”的信息，然后执行各自分内的操作。如果Etcd运行不正常，那么提交给Kubernetes集群新的Deployment等会得不到执行，集群的自愈能力也将丧失。

从上可见Etcd在整个Kubernetes集群中非常重要，对于它的监控就很有必要。在生产环境，为了保证数据的高可用性，一般部署3到5个Etcd实例组成集群，实例间通过Raft算法保持数据的一致性。

本文对Etcd监控的重要Metrics做介绍，对于如何搭建Prometheus和Grafana监控栈不做过多介绍，这些内容在网络上介绍的文章有很多。

在正式开始之前，对Etcd相关知识做简明陈述，

基本知识点

Etcd集群节点分三种角色，Follower、Candidate和Leader如果Follower不能发现Leader，它将变成Candidate写操作只能通过Leader来完成，即使写请求发到Follower角色的节点，这些请求也会转交给Leader来处理在Leader失联后，集群的选举系统在Candidate中选出新的Leader写操作时，只要Leader收到集群大部分Follower的ack回复，便认为写操作成功，不用等全部Follower节点的ack回复

核心Metrics

Etcd会将自己的Metrics通过4001端口暴露，Metrics比较多，重要的有下面这些。

up

这个是最基本的，如果Etcd集群有5个节点，你的集群"sum(up{job="etcd"})"这个值一定不要小于3。

etcd_server_has_leader

每个instance，该值应该都为1，否则这个节点可能已经离开集群，最好在发生过半这样的情况前介入。

etcd_server_leader_changes_seen_total

这个metrics类型为counter，即它是单调递增的，可以监控该值的变化率，如果发现变化率太高，说明集群的负载过高或者网络连接可能不稳定。

etcd_server_proposals_failed_total

该值的类型也是counter。proposal字面意思是“提案”，客户端的一个写操作可以认为是一个提案，提案需要集群内的Etcd实例来“表决”，如果表达式“rate(etcd_server_proposals_failed_total{job=~"etcd"}[15m])”的值不为零，说明有proposal没有提交成功，如果经常这样，说明集群leader选举失败或者集群有过半节点离线。

etcd_disk_backend_commit_duration_seconds_bucket

Etcd的持久化保证依赖WAL和快照机制，这些全靠硬盘的IO表现。如果硬盘的性能不佳，在高负载情况下，将严重拖慢Etcd的处理速度，因此在生产环境中建议使用SSD来替代传统机械硬盘。可以通过监控"etcd_disk_backend_commit_duration_seconds_bucket"的0.99分位数来衡量硬盘的表现情况，

histogram_quantile(0.99, rate(etcd_disk_backend_commit_duration_seconds_bucket{job=~"etcd"}[5m]))

提交耗时

如果该值仅几个毫秒，说明你的Etcd比较健康。

以上便是对Etcd监控的关键Metrics介绍，希望能帮助到你，欢迎评论和分享！