如何构建万级Kubernetes集群场景下的etcd监控平台

本篇文章给大家分享的是有关如何构建万级Kubernetes集群场景下的etcd监控平台，小编觉得挺实用的，因此分享给大家学习，希望大家阅读完这篇文章后可以有所收获，话不多说，跟着小编一起来看看吧。

创新互联专业为企业提供西湖网站建设、西湖做网站、西湖网站设计、西湖网站制作等企业网站建设、网页设计与制作、西湖企业网站模板建站服务，十载西湖做网站经验，不只是建网站，更提供有价值的思路和整体网络服务。

背景

随着 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监控平台，小编相信有部分知识点可能是我们日常工作会见到或用到的。希望你能通过这篇文章学到更多知识。更多详情敬请关注创新互联行业资讯频道。