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

周成，腾讯云工程师，主要负责腾讯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，监控服务可用性较低。

问题分析