共计 2628 个字符，预计需要花费 7 分钟才能阅读完成。
重点监控指标
指标分类
- 衰弱状态
-
USE 办法（零碎）
- 使用率
- 饱和度
- 谬误
-
RED 办法（利用）
- 申请速率
- 错误率
- 提早
| 指标分类 | 指标 | 释义 |
|---|---|---|
| 衰弱状态 | 实例衰弱状态 | etcd 是一个分布式系统，由多个成员节点组成。监控 etcd 成员节点的状态能够帮忙你理解集群中节点的健康状况，发现掉线或者异样节点。 |
| 衰弱状态 | 主从状态 | |
| 衰弱状态 | etcd leader 切换统计 | 频繁的领导者变更会重大影响 etcd 的性能。这也意味着领导者不稳固，可能是因为网络连接问题或对 etcd 集群施加的过载负荷导致的。 |
| 衰弱状态 | 心跳 | etcd 集群中的节点通过发送心跳来放弃彼此之间的连贯。监控失落的心跳能够帮忙你发现 etcd 节点之间的通信问题或者网络提早。 |
| RED 办法 | QPS | |
| RED 办法 | 申请错误率 | 监控 etcd 的错误率能够帮忙你发现 etcd 操作中的潜在问题。高错误率可能表明集群遇到了故障或其余异常情况。 |
| RED 办法 | 申请提早 | 监控 etcd 的申请提早能够帮忙你理解 API 申请的解决工夫。较高的提早可能表明 etcd 正面临负载压力或性能问题。 |
| RED 办法 | 磁盘同步（WAL/DB fsync）耗时 | 高磁盘操作提早（wal_fsync_duration_seconds 或 backend_commit_duration_seconds）通常示意磁盘问题。它可能会导致高申请提早或使群集不稳固。 |
| RED 办法 | 同步提早 | 如果集群失常运行，已提交的提案应该随着工夫的推移而减少。重要的是要在集群的所有成员中监控这个指标；如果单个成员与其领导节点之间存在继续较大的滞后，这表明该成员运行迟缓或存在异样。 |
| RED 办法 | 提案失败次数 | 失败的提案通常与两个问题相干：与领导选举相干的暂时性故障或因为集群丢失法定人数而导致的较长时间的停机。 |
| RED 办法 | 快照解决工夫 | etcd 定期创立快照以备份数据。监控快照解决工夫能够帮忙你理解 etcd 备份的性能，确保备份工作可能及时实现。 |
| RED 办法 | watcher 数量 | 监控 etcd 集群以后连贯到 etcd 的客户端数量。如果连接数过高，可能须要调整 etcd 的配置或者减少集群的容量。 |
| USE 办法 | CPU 使用率 | |
| USE 办法 | 内存使用量 | |
| USE 办法 | 关上文件数 | |
| USE 办法 | 存储空间使用率 | 监控 etcd 存储空间的使用率能够帮忙你确保 etcd 有足够的空间存储配置数据。如果使用率靠近或达到下限，可能须要思考扩大存储容量或者清理无用的数据。 |
应用 kube-prometheus 收集 etcd 指标
http 模式（举荐）
批改 --listen-metrics-urls
#- --listen-metrics-urls=http://127.0.0.1:2381
- --listen-metrics-urls=http://127.0.0.1:2381,http://ip:2381部署
helm install monitoring -n cattle-prometheus --set kubeEtcd.service.port=2381 --set kubeEtcd.service.targetPort=2381 --set prometheusOperator.admissionWebhooks.patch.image.sha=null ./https 模式
新增 etcd secret
kubectl create secret generic etcd-certs -n cattle-prometheus --from-file=/etc/kubernetes/pki/etcd/ca.crt --from-file=/etc/kubernetes/pki/etcd/healthcheck-client.crt --from-file=/etc/kubernetes/pki/etcd/healthcheck-client.key部署
helm install monitoring -n cattle-prometheus --set kubeEtcd.serviceMonitor.scheme=https --set kubeEtcd.serviceMonitor.caFile=/etc/prometheus/secrets/etcd-certs/ca.crt --set kubeEtcd.serviceMonitor.certFile=/etc/prometheus/secrets/etcd-certs/healthcheck-client.crt --set kubeEtcd.serviceMonitor.keyFile=/etc/prometheus/secrets/etcd-certs/healthcheck-client.key --set prometheus.prometheusSpec.secrets={etcd-certs} --set prometheusOperator.admissionWebhooks.patch.image.sha=null ./大盘展现
Grafana 大盘：https://github.com/clay-wangzhi/grafana-dashboard/blob/master/etcd/etcd-dash.json
导入即可
<img src=”https://clay-blog.oss-cn-shanghai.aliyuncs.com/img/image-20230616180204033.png” alt=”image-20230616180204033″ style=”zoom:67%;” />
<img src=”https://clay-blog.oss-cn-shanghai.aliyuncs.com/img/image-20230616180334752.png” alt=”image-20230616180334752″ >
巡检
实现集群部署、理解成员治理、构建好监控及告警体系并增加好定时备份策略后，这时终于能够释怀给业务应用了。然而在后续业务应用过程中，你可能会遇到各类问题，而这些问题很可能是 metrics 监控无奈发现的，比方如下：
- etcd 集群因重启过程、节点等呈现数据不统一；
- 业务写入大 key-value 导致 etcd 性能骤降；
- 业务异样写入大量 key 数，稳定性存在隐患；
这时就须要巡检。
参考 ServiceMonitor 和 EtcdBackup 机制，同样能够通过 CRD 的形式形容此巡检工作，而后通过相应的 Operator 实现此巡检工作。
参考链接：
datadog etcd 指标
etcd 实战课 | 极客工夫 唐聪