共计 11198 个字符，预计需要花费 28 分钟才能阅读完成。
周成，腾讯云工程师，次要负责腾讯 etcd 监控平台设计、开发、运维工作，具备大规模 Kubernetes 和 etcd 集群运维开发教训。
唐聪，腾讯云资深工程师，极客工夫专栏《etcd 实战课》作者，etcd 沉闷贡献者, 次要负责腾讯云万级 K8s 集群和外部业务的公共 etcd 平台以及 serverless 产品研发设计工作。
背景
随着 Kubernetes 成为容器编排畛域的霸主，越来越多的业务大规模在生产环境应用 Kubernetes 来部署、治理服务。腾讯云 TKE 正是基于原生 Kubernetes，提供以容器为外围的、高度可扩大的高性能容器治理服务，自从 2017 年推出后，随着 Kubernetes 的炽热，咱们的集群规模也增长到万级，在这过程中咱们的各根底组件，尤其是 etcd 面临了以下挑战：
- 如何通过一套监控零碎，采集万级的 TKE 集群的 etcd 等组件 metrics 监控数据?
- 如何高效治理万级集群、被动发现故障及潜在隐患？
- 如何疾速感知异样，实现疾速处理、乃至自愈？
为了解决以上挑战，咱们基于 Kubernetes 的扩大机制，实现了一套含 etcd 集群治理、调度、迁徙、监控、备份、巡检于一体的可视化的 etcd 平台，本篇文章重点和你分享的是咱们 etcd 监控平台是如何解决以上挑战的。
面对大规模监控数据采集问题，咱们的解决方案从 TKE 诞生之初的单 Prometheu 实例、到基于 Promethes-Operator 动静构建多 Prometheus 实例、增加监控 Target, 再到基于 TKE 云原生 Prometheus 产品实现程度可扩大的监控零碎，胜利为万级 Kubernetes 集群提供稳固的 etcd 存储服务和监控能力，etcd 监控平台治理的 Kubernetes 集群数也实现了从个位数、到千级、万级的冲破。目前数据规模上，单位工夫内 Prometheus Target 高达数万个，单地区指标数据量 Series 千万级，面对大规模监控数据，监控数据可用性仍能放弃在 99.99% 以上。
面对简单分布式环境中，各种可能呈现的不可控人为操作失误、硬件、软件故障，咱们基于 Kubernetes 扩大机制、丰盛 的 etcd 常识与教训积攒构建了多维度、可扩大的的巡检零碎，帮忙咱们高效治理万级集群、被动发现潜在隐患。
面对监控数据宏大，告警泛滥，咱们基于高可用的监控数据，联合经营场景，建设标准化的数据经营体系，大幅缩小有效告警，进步告警准确性，并进一步引入多维度的 SLO，收敛告警指标，为业务方提供直观的服务水平指标。通过标准化的数据经营体系、告警分类、告警跟进、回升机制、简略场景的自愈策略等，实现故障疾速处理、乃至自愈。
上面，咱们就和你具体介绍下，咱们是如何解决以上三个挑战，心愿其中的最佳实际能帮忙你疾速构建可扩大的业务监控零碎。
如何构建高可用，可扩大的监控数据采集服务？
首先是第一个问题，如何通过一套监控零碎，采集万级的 TKE 集群的 etcd 组件 metrics 监控数据？
大家都晓得，etcd 是一个开源的分布式 key-value 存储系统，它是 Kubernetes 的元数据存储，etcd 的不稳固会间接导致下层服务不可用，因而 etcd 的监控至关重要。
2017 年，TKE 诞生之初，集群少，因而一个单 Prometheu 实例就能够搞定监控问题了。
2018 年，Kubernetes 越来越被大家认可，咱们的 TKE 集群数也越来越多，因而咱们引入了 Promtheus-Operator 来实现动静治理 Prometheus 实例、通过多 Prometheus 实例，咱们根本扛住了数千的 Kubernetes 集群监控需要，上面是其架构图。
Prometheus-Operator 架构
咱们在每个地区部署了 Prometheus-Operator, 针对不同业务类型创立了不同的 Prometheus 实例，每新增一个 Kubernetes/etcd 集群的时候，咱们会通过 API 创立 ServiceMonitor 资源，告知 Prometheus 采集新集群监控数据。
然而在这套计划中，随着 Kubernetes/etcd 集群越来越多，etcd 监控告警的稳定性受到挑战，监控链路不稳固，监控曲线呈现断点，告警泛滥，虚告警多，难以跟进。
痛点问题
具体有哪些问题呢？
这里咱们从监控不稳固和运维老本两个角度和你剖析下。
监控不稳固
监控组件不稳固：过大的监控数据常常会造成 Prometheus 实例呈现 OOM，同时因为纳管 etcd 过程中会对 Prometheus 实例进行变更，频繁的变更会触发 Prometheus 的卡死。
监控与业务耦合：为防止数据量过大造成 OOM，须要人工拆分 Prometheus 实现数据分片，这样不仅减少保护老本，同时因为存在主动纳管的机制，纳管机制与人工分片强耦合，不利于前期经营和性能拓展。
监控链路不稳固：监控链路次要由 Prometheus-Operator 和 Top-Prometheus 形成，因为与其余业务共享 Top-Prometheus，Top-Prometheus 面临大量数据，时常会呈现 OOM 重启，同时因为本地盘存储数据量大，启动加载慢，重启耗时长，进一步扩充了影响，常常会造成较长时间的数据断点。
运维老本
监控组件须要自保护：监控数据分片须要人工拆分监控实例，监控组件须要自运维保活，确保监控可用性。
告警规定保护难度大：告警规定大量依赖对 etcd 名称的正则匹配，规定保护难度大，对于新增告警规定的场景，须要理解现有的规定配置状况，在增加新规定前需对现有规定减少特定 etcd 集群的反选逻辑，新增操作时常会呈现影响现有告警的状况。
告警难跟进：指标繁多，告警量大，无奈精确反映业务问题，告警指标不具备业务个性，业务难以间接了解，无奈将告警信息间接返回业务方，告警跟进难度大。
另外基于开源的 Prometheus，在增加监控 Target 时，会导致 Prometheus 异样，服务重启，呈现数据断点，同时因为监控数据量大导致常常 OOM，监控服务可用性较低。
问题剖析
如上图所示，监控服务次要由上层 Prometheus Server 和下层 Top-Prometheus 组成。
变更为什么会卡死？
如上图所示，Secret 资源由 etcd 集群产生，Prometheus-Operator 会依据 Secret，Prometheus CRD 和 ServiceMonitor 生成 Prometheus 实例的 static_config 文件，Prometheus 实例最终依赖 config 文件实现数据的拉取。
etcd 减少 => Secret 增多，Prometheus CRD 更新 => static_config 更新频繁 => Prometheus 的拉取配置频繁变动导致 Prometheus 无奈失常工作。
容量问题从何而来？
在 TKE 集群一直增长和产品化 etcd 上线的背景下，etcd 数目一直减少，etcd 本身指标量大，同时为了高效治理集群，提前发现各种隐患，引入巡检策略，指标数据量高达数百万。
Top-Prometheus 除采集 etcd 指标外，还须要采集其余撑持服务，因而，Top-Prometheus 经常出现 OOM 导致监控服务不可用。
可拓展 Prometheus 架构
如何解决以上痛点呢？
TKE 团队推出的云原生 Prometheus 正是为了解决大规模数据场景下的痛点而诞生的，为了解决以上痛点，保证数据标准化经营底座的稳定性，提供高可用的监控服务，咱们决定将 etcd 监控平台全面迁徙到 TKE 云原生 Prometheus 进行监控零碎中。
TKE 云原生 Prometheus 监控引入 file-sync 服务实现配置文件的的热更新，防止变更导致 Prometheus 重启，胜利解决了咱们外围场景过程中的痛点。
同时 TKE 云原生 Prometheus 通过 Kvass 实现对监控数据弹性分片，无效分流大量数据，实现千万级数据的稳固采集。
最重要的是，Kvass 我的项目已开源，上面是其架构图，更多可参考文《如何用 Prometheus 监控十万 container 的 Kubernetes 集群》和 GitHub 源码。
云原生可拓展 Prometheus 架构
上图是咱们基于可扩大的 TKE 云原生 Prometheus 架构图，上面我简略为你介绍下各个组件。
中心化 Thanos 引入
Thanos 次要由两个服务形成：thanos-query 和 thanos-rule。thanos-query 实现对监控数据的查问，thanos-rule 对监控数据进行聚合实现告警。
thanos-query：thanos-query 通过配置 store 字段可实现多个 Prometheus 数据查问工作，利用查问能力实现 TKE 云原生 Prometheus 或原有 Prometheus 的数据聚合，同时也为下层监控大盘和告警提供对立的数据源，起到收敛数据查问入口的作用。
thanos-rule：thanos-rule 依赖 query 采集的数据，对数据进行聚合，并依据配置的告警规定实现告警，告警能力的收敛和中心化的告警配置使得上层 Prometheus 服务无论如何变动，告警链路的稳定性都得以保障。
平滑迁徙
TKE 云原生 Prometheus 齐全兼容开源的 Prometheus-Operator 计划，因而在迁徙过程，原有 Prometheus-Operator 相干配置能够全副保留，仅须要增加对应标签便于 TKE 云原生 Prometheus 辨认即可。然而因为指标裸露由集群内迁徙至内部 TKE 云原生 Prometheus，对集群内外依赖监控指标的服务有所影响。
对外裸露：通过引入中心化 thanos-query，各个地区指标均通过 thanos-query 对外裸露，凭借下层中心化的 query，底层迁徙 TKE 云原生 Prometheus 或者对其进行平行拓展，对于依赖监控指标的内部服务如监控大盘和告警等均无感知。
外部依赖：集群内 custom-metrics 服务依赖监控指标，因为采纳 TKE 云原生 Prometheus，指标无奈再依赖外部 Service 采集，为此，在云原生 Prometheus 所在集群创立对应的内网 LB，使得可被撑持环境外部拜访，通过内网 LB 对 custom-metrics 进行配置，从而实现监控指标的采集。
TKE 云原生 Prometheus 成果
监控可用性：TKE 云原生 Prometheus 基于 Prometheus 对外裸露指标以掂量本身监控服务的可用性，罕用指标有 prometheus_tsdb_head_series 和 up 等，prometheus_tsdb_head_series 用于掂量采集总体监控数据量，up 指标反馈采集工作是否衰弱，通过这两个指标可能对监控服务可用性有整体的感知。
数据采集成功率：作为业务侧，咱们更关怀具体业务指标采集的成功率，为无效掂量可用性，对业务指标进行采样落地数据化。以 15s 为距离别离采集迁徙前后的数据，联合实践数据量判断数据掉点率，以此反映监控服务可用性。通过统计，具体近 30 天数据如下图所示：
引入 TKE 云原生 Prometheus 后，监控数据总量始终高达数千万，监控告警链路稳固，巡检数据覆盖率在 70% 以上，因为对 etcd 服务平台进行过革新造成成功率在短时间内所稳定，除此外，监控指标拉取成功率均在 99.99% 以上，近 7 天数据放弃在 100%，监控服务放弃着高可用性。
如何高效治理 etcd 集群，提前发现隐患？
其次是第二个问题，如何高效治理万级集群、被动发现故障及潜在隐患？
在第一个问题中，咱们曾经解决了大规模 etcd 集群的 metrics 采集问题，通过 metrics 咱们能够发现局部隐患，然而它还不够满足咱们高效治理 etcd 集群的诉求。
为什么这样说呢？
痛点问题
在大规模应用 etcd 过程中，咱们可能会遇到各种各样的隐患和问题，比方常见如下：
- etcd 集群因重启过程、节点等呈现数据不统一
- 业务写入大 key-value 导致 etcd 性能骤降
- 业务异样写入大量 key 数，稳定性存在隐患
- 业务多数 key 呈现写入 QPS 异样，导致 etcd 集群呈现限速等谬误
- 重启、降级 etcd 后，须要人工从多维度查看集群衰弱度
- 变更 etcd 集群过程中，操作失误可能会导致 etcd 集群呈现决裂
- ……
因而为了实现高效治理 etcd 集群，咱们将这些潜在隐患总结成一个个自动化查看项，比方：
- 如何高效监控 etcd 数据不一致性？
- 如何及时发现大 key-value?
- 如何及时通过监控发现 key 数异样增长？
- 如何及时监控异样写入 QPS?
- 如何从多维度的对集群进行自动化的衰弱检测，更安心变更？
- ……
如何将这些 etcd 的最佳实际策略反哺到现网大规模 etcd 集群的治理中去呢？
答案就是巡检。
咱们基于 Kubernetes 扩大机制、丰盛的 etcd 常识与教训积攒构建了多维度、可扩大的的巡检零碎，帮忙咱们高效治理万级集群、被动发现潜在隐患。
为什么咱们基于 Kubernetes 扩大机制构建 etcd 平台呢？
etcd 云原生平台介绍
为了解决咱们业务中一系列痛点，咱们 etcd 云原生平台设计指标如下：
- 可观测性。集群创立、迁徙流程反对可视化，随时可查看以后停顿，反对暂停、回滚、灰度、批量等。
- 高开发效率。充沛复用社区已有基础设施组件和平台，聚焦业务，疾速迭代，高效开发。
- 高可用。各组件无单点，可平行扩容，迁徙模块通过分布式锁抢占工作，可并发迁徙。
- 可扩展性。迁徙对象、迁徙算法、集群治理、调度策略、巡检策略等抽像化、插件化，以反对多种 Kubernetes 集群类型、多种迁徙算法、多种集群类型（CVM/ 容器等）、多种迁徙策略、多种 Kubernetes 版本、多种巡检策略。
回顾咱们设计指标，可观测性、高开发效率跟 Kubernetes 和其申明式编程特地匹配，详情如下。
- 可观测性。基于 Event 做迁徙实时停顿性能，通过 kubectl、可视化的容器控制台都能够查看、启动、暂停各类工作
- 高开发效率。Kubernetes 中 REST API 设计优雅，定义自定义 API 后，SDK 全自动生成，大大减少了开发工作量，可专一业务畛域零碎开发，同时自动化监控、备份模块能够基于 Kubernetes 社区已有的组件，进行定制扩展性开发，来满足咱们的性能，解决痛点。
Kubernetes 是个高度可扩大和配置的分布式系统，各个模块都有丰盛的扩大模式和点。在抉择基于 Kubernetes 编程模式后，咱们须要将 etcd 集群、迁徙工作、监控工作、备份工作、迁徙策略等形象成 Kubernetes 自定义资源，实现对应的控制器即可。
上面是 etcd 云原生平台的架构图。
上面以 etcd 集群的创立和调配为例，为你简略介绍下 etcd 平台的原理：
- 通过 kubectl 或者可视化 Web 零碎创立 etcd 集群，实质上是提交一个 EtcdCluster 自定义资源
- etcd-apiserver 将 CRD 写入到独立的 etcd 存储，etcd-lifecycle operator 监听到新集群后，依据 EtcdCluster 申明的后端 Provider, 抉择基于 CVM Provider 还是容器化创立 etcd 集群。
- 集群创立实现后，etcd-lifecycle operator 还会增加一系列备份策略、监控策略、巡检策略，它们实质上也是一系列 CRD 资源。
- 当业务须要调配 etcd 集群的时候，调度服务通过筛选流程后，失去一系列满足业务条件的候选集群，那如何从中返回最佳的 etcd 集群给用户呢？这里，咱们反对多种评优策略，比方按最小连接数，它会通过 Kubernetes 的 API 从 Prometheus 中获取集群的连接数，优先将最小连接数的集群，返回给业务应用，也就是刚刚创立的集群，马上就会被调配进来。
etcd 巡检案例介绍
如何给巡检零碎增加一个巡检一个规定呢？
一个巡检规定其实对应的就是一个 CRD 资源，如上面 yaml 文件所示，它就示意给集群 gz-qcloud-etcd-03 增加一个数据差异化的巡检策略。
apiVersion: etcd.cloud.tencent.com/v1beta1
kind: EtcdMonitor
metadata:
creationTimestamp: "2020-06-15T12:19:30Z"
generation: 1
labels:
clusterName: gz-qcloud-etcd-03
region: gz
source: etcd-life-cycle-operator
name: gz-qcloud-etcd-03-etcd-node-key-diff
namespace: gz
spec:
clusterId: gz-qcloud-etcd-03
metricName: etcd-node-key-diff
metricProviderName: cruiser
name: gz-qcloud-etcd-03
productName: tke
region: gz
status:
records:
- endTime: "2021-02-25T11:22:26Z"
message: collectEtcdNodeKeyDiff,etcd cluster gz-qcloud-etcd-03,total key num is
122143,nodeKeyDiff is 0
startTime: "2021-02-25T12:39:28Z"
updatedAt: "2021-02-25T12:39:28Z"创立此 yaml 文件后，巡检服务就会执行此巡检策略，并裸露相干 metrics 对外给 Prometheus 服务采集，最终实现成果如下。
如何疾速感知异样，实现疾速处理、乃至自愈？
基于稳固的 TKE 云原生 Prometheus 监控链路以及较欠缺的巡检能力，etcd 平台曾经可能提供 etcd 集群可用性相干的各类监控指标，然而因为集群数较多，指标泛滥，用户应用场景泛滥，部署环境又简单，难以疾速定位异样起因，实现疾速处理，即时复原。
为进步感知异样的能力，实现疾速处理及自愈，次要面临以下几个问题。
- 面对各种规格的 etcd 集群，繁冗的业务利用场景，如何标准化监控以及告警？
etcd 的业务场景与经营场景是有所出入的，基于经营需要，对 etcd 集群的接入进行标准化，提供经营所需标准化监控指标。根据标准化后的业务以及 etcd 规格进一步落地告警标准化，从而实现监控告警的经营标准化。
- 面对海量指标，如何无效收敛，疾速掂量 etcd 集群可用性，感知异样？
etcd 可用性异样，关联的监控往往不同，没有繁多指标可能掂量其可用性，为此引入 SLO，无效反馈 etcd 服务可用性，并围绕 SLO 构建多维度的监控体系实现疾速的异样感知和问题定位，从而进一步疾速复原。
以下将针对上述问题逐个解决，构建高效的数据经营体系，实现异样的疾速感知。
接入标准化
etcd 运维信息接入 CRD：etcd 的继续运维通过 CRD 进行配置，齐全遵循 Kubernetes 标准，Spec 中定义 etcd 根底信息，服务信息以 Annotation 的模式进行拓展，一个 CRD 囊括了 etcd 运维所有须要的信息。
云原生的数据解决方案：开源 Prometheus 通过配置 Static Config 实现采集工作的配置，TKE 云原生 Prometheus 则充分利用开源 Prometheus-Operator 提供的 ServiceMonitor 资源配置采集工作，仅需配置几个筛选标签即可实现组件 Metrics 的自动化接入。etcd 自身作为数据存储个别运行于经营治理集群之外，为实现对 etcd 本身监控指标的采集，利用 Kubernetes 中的 No Selector Service 实现，通过间接配置对应 etcd 节点的 Endpoints 采集 etcd 本身 Metrics。
标准化标准：etcd 监控指标通过 ServiceMonitor 的 Relabel 能力引入产品，场景和规格三类标签实现经营信息的标准化。产品标签反馈 etcd 服务对象所属产品类别，场景标签通过对 etcd 的利用场景进行划分而得，规格依据 etcd 节点规格和用户使用量进行辨别，初步分为 small，default，large 三档。
告警统一标准：通过标准化的施行，告警规定不再依赖大量正则匹配实现，通过场景和规格可能确定对应告警指标的阈值，联合告警指标表达式即可实现告警规定的配置，对于新增告警规定，通过场景和规格的无效宰割，能够在不变动现有告警规定的状况下实现新增。同时带入外部自研告警零碎的场景和规格标签可能反馈告警的应解决人群，实现告警的定向推送，分级告警，进步告警的准确性。
上述标准化流程不仅实用于云原生组件，对于以二进制运行于机器的组件，也能够通过自建 No Selector Service 实现对应指标的采集，组件依据应用场景等经营信息确定好经营类标签后，通过 ServiceMonitor 的 Relabel 能力能疾速联动 TKE 云原生 Prometheus 实现监控告警链路，建设数据标准化的经营体系。
基于上述标准化流程，落地 etcd 产品化现网经营反对，跟随着产品化 etcd 上线，利用 ServiceMonitor 的 Relabel 能力，在不变动监控层的状况下实现了接入即运维的个性：
定义接入标准：引入业务和规格的经营类标签，根据该类标签将 etcd 应用场景反馈到监控指标当中，为平面监控大盘提供了数据根据，同时围绕这类标签实现告警规定的配置和运维。
通用告警规定间接适 配：围绕经营类标签业务和规格，联合监控指标和阈值，间接生成通用告警规定，实现不同维度的告警。
剖析视图：基于业务场景，联合不同的监控指标，间接套用标准化的监控视图生成业务维度的 etcd 监控大盘。
面向 SLO 建设数据经营体系
引入 SLO
如何形象一个 SLO：SLO 即服务水平指标，次要面向外部，用于掂量服务质量。确定 SLO 前，首先要确定 SLI（服务水平指标）。服务是面向用户的，因而一个重要掂量指标是用户方对服务的感知，其中，错误率和延时感知最为显著。同时服务自身和服务依赖的第三方服务也会决定服务质量。因而对于 etcd 服务，SLI 三要素可确定为申请错误率及延时，是否有 Leader 和节点磁盘 IO。节点磁盘 IO 在肯定水平上会体现在读操作的错误率和延时，对 SLI 进一步分层为 etcd 可用性和读写可用性。联合 Prometheus 实时计算能力，etcd SLO 计算公式可初步确定。
SLO 的计算：SLO 用于掂量服务质量，服务质量由用户感知，本身服务状态以及依赖的底层服务决定，因而 SLO 由基于 etcd 外围接口 RPC（Range/Txn/Put 等）的延时，磁盘 IO，是否有 Leader 以及相干巡检指标组成。
SLO 经营计划：通过对 etcd 服务的剖析初步得出 SLO 计算公式并且落地具体 SLO 指标，但只是初步实现。SLO 须要通过比照理论异常情况，一直修改，进步 SLO 的准确率。通过一段时间的察看和修改，SLO 指标日趋精确，逐步形成如下图的经营模式，通过 SLO 联动监控，告警以及现网问题，进步经营效率，欠缺被动服务能力。通过一段时间的经营，SLO 告警在数次异常情况下通过电话告警及时裸露问题，实现了异样的被动发现。
TKE 云原生 Prometheus 落地 SLO
引入 Recording Rules
etcd 可用性和延时等构建 SLO 的要害指标曾经通过 TKE 云原生 Prometheus 进行采集，依靠 Promethues 的计算能力，可能实现 SLO 的计算，然而因为 SLO 计算波及的指标较多，etcd 体量大，SLO 计算提早大，呈现的断点较多。
Recording Rules 是 Prometheus 的记录规定，通过该能力可能提前设置好一个运算表达式，其后果将被保留为一组新的工夫序列数据。通过这种形式，可能将简单的 SLO 计算公式合成为不同单元，扩散计算压力，防止数据断点，并且因为计算结果已被保留，SLO 历史数据查问速度极快。同时，Promethues 通过收到的 SIGNUP 信号量更新记录规定，因而记录规定的重载是实时的，这种个性有利于在 SLO 实际过程一直批改计算公式，继续优化 SLO。
数据价值经营体系建设
通过 SLO 的落地，etcd 平台监控告警依靠 SLO 实现了入口的对立，思考到 etcd 应用场景繁多，日常排障艰难，问题剖析不易进行，围绕 SLO 监控体系建设 SLO 疾速排障和平面 SLO 监控，整体如下图所示。
经营诉求
基本面确认：通过监控可能理解 etcd 的整体详情，如容量信息，组件稳定性，服务可用性等。
不同场景的个性诉求：不同利用场景 etcd 的侧重点不同，所关注的监控维度也不雷同，监控大盘应能反馈不同场景的个性。
运维排障：底层 IAAS 层资源抖动时疾速确定受影响 etcd 集群，故障时疾速确定影响面，并且可能通过告警视图进一步确认故障起因。
平面监控
etcd 平台监控视图如下图所示，总体分为一级，二级，三级以及排障视图。一级为监控大盘，二级划分为三个场景，三级为单集群监控，是具体问题的要害，排障视图联动 etcd 与 Kubernetes 实现双向查问。
一级监控视图：SLO 基于多种监控指标计算而成，能无效掂量 etcd 可用性，起到了收敛监控指标的作用，实现对立入口。根据 SLO 建设多地区的监控大盘，可能整体理解 etcd 状况，疾速确认故障影响面。
二级监控视图：根据 etcd 利用场景，二级监控由业务，大客户等场景组成，实现不同场景的个性需要，业务反馈各个地区的整体可用性，可能事实各业务各地区是否具备足够的 etcd 资源，大客户则在容量上须要反馈出其规模，也须要思考到凋谢给客户应用的状况。
三级监控视图：三级监控为单集群监控视图，通过该视图，可能确认 etcd 具体问题所在，为故障复原提供根据。
SLO 排障监控视图：etcd 是 Kubernetes 的底层存储服务，在排障过程中，etcd 与 Kubernetes 往往须要双向确认，为进步排障效率，SLO 排障监控由 etcd 与 Kubernetes 集群正向查问，反向查问视图组成。
经营功效
SLO 监控体系根本笼罩了所有的经营场景，在理论经营过程中屡次起到了关键作用。
底层 IAAS 抖动：通过一级监控疾速确认影响面，进一步在不同场景下确认受影响 etcd 集群，可疾速确定影响面。
问题定位：接管相应 SLO 告警后，可通过三级监控确定 SLO 告警起因，确认影响指标，实现故障的疾速复原，同时 etcd 与 Kubernetes 的正反查问不仅不便了 etcd 问题确认，也是 Kubernetes 问题确认的利器。
被动服务：通过 SLO 监控大盘屡次提前发现 etcd 异样，并被动反馈给下层服务相干团队，无效将服务故障扼杀在摇篮当中。
自愈能力：etcd 节点故障会影响 etcd 可用性，通过 SLO 监控告警，可能疾速感知异样，同时依靠容器化部署的劣势，产品化 etcd 集群的节点均以 Pod 模式运行，当出现异常节点时，主动会剔除异样 POD，增加新的节点，从而在用户无感知的前提实现故障自愈。
总结
本文围绕着大规模 Kubernetes 和 etcd 集群的三个痛点，具体和你分享了咱们的最佳实践经验。首先通过 TKE 云原生监控 Prometheus 解决了如何稳固采集万级实例的问题，其次通过可扩大的巡检零碎，解决了自动化、高效治理万级集群的问题，最初咱们通过引入 SLO 指标、建设一系列运维监控视图、容器化部署 etcd 集群，实现了故障疾速发现及自愈。
基于 TKE 云原生 Prometheus 的杰出性能，etcd 监控稳定性始终维持在 99.99% 以上，为 SLO 经营零碎提供了稳固的数据起源。依靠欠缺的数据经营体系，etcd 监控平台将来致力于打造面向 etcd 的 AIOPS 智能体系，实现高度自愈能力，为 etcd 乃至更多组件提供智能牢靠的运维解决方案。同时思考到业务场景的个性需要，etcd 平台将会进一步提高拓展能力，提供可插拔的拓展形式，与社区共建，逐渐打造残缺的 etcd 监控运维体系。
【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！
