vivo 互联网服务器团队 -YuanPeng
一、概述
从容器技术的推广以及 Kubernetes 成为容器调度治理畛域的事实标准开始，云原生的理念和技术架构体系逐步在生产环境中失去了越来越宽泛的利用实际。在云原生的体系下，面对高度的弹性、动静的利用生命周期治理以及微服务化等特点，传统的监控体系曾经难以应答和撑持，因而新一代云原生监控体系应运而生。
以后，以 Prometheus 为外围的监控零碎已成为云原生监控畛域的事实标准。Prometheus 作为新一代云原生监控零碎，领有弱小的查问能力、便捷的操作、高效的存储以及便捷的配置操作等特点，但任何一个零碎都不是万能的，面对简单多样的生产环境，繁多的 Prometheus 零碎也无奈满足生产环境的各种监控需要，都须要依据环境的特点来构建适宜的监控办法和体系。
本文以 vivo 容器集群监控实践经验为根底，探讨了云原生监控体系架构如何构建、遇到的挑战以及相应的对策。
二、云原生监控体系
2.1 云原生监控的特色和价值
云原生监控相比于传统监控，有其特色和价值，可演绎为下表：
2.2 云原生监控生态简介
CNCF 生态全景图中监控相干的我的项目如下图（参考 https://landscape.cncf.io/），上面重点介绍几个我的项目：
- Prometheus（已毕业）
Prometheus 是一个弱小的监控零碎，同时也是一个高效的时序数据库，并且具备残缺的围绕它为外围的监控体系解决方案。单台 Prometheus 就可能高效的解决大量监控数据，并且具备十分敌对且弱小的 PromQL 语法，能够用来灵便查问各种监控数据以及告警规定配置。
Prometheus 是继 Kubernetes 之后的第二个 CNCF“毕业”我的项目（也是目前监控方向惟一“毕业”的我的项目），开源社区沉闷，在 Github 上领有近 4 万 Stars。
Prometheus 的 Pull 指标采集形式被宽泛采纳，很多利用都间接实现了基于 Prometheus 采集规范的 metric 接口来裸露本身监控指标。即便是没有实现 metric 接口的利用，大部分在社区里都能找到相应的 exporter 来间接裸露监控指标。
但 Prometheus 依然存在一些有余，比方只反对单机部署，Prometheus 自带时序库应用的是本地存储，因而存储空间受限于单机磁盘容量，在大数据量存储的状况下，prometheus 的历史数据查问性能会有重大瓶颈。因而在大规模生产场景下，繁多 prometheus 难以存储长期历史数据且不具备高可用能力。
- Cortex（孵化中）
Cortex 对 Prometheus 进行了扩大，提供多租户形式，并为 Prometheus 提供了对接长久化存储的能力，反对 Prometheus 实例程度扩大，以及提供多个 Prometheus 数据的对立查问入口。
- Thanos（孵化中）
Thanos 通过将 Prometheus 监控数据存储到对象存储，提供了一种长期历史监控数据存储的低成本解决方案。Thanos 通过 Querier 组件给 Prometheus 集群提供了全局视图（全局查问），并能将 Prometheus 的样本数据压缩机制利用到对象存储的历史数据中，还能通过降采样性能晋升大范畴历史数据的查问速度，且不会引起显著的精度损失。
- Grafana
Grafana 是一个开源的度量剖析与可视化套件，次要在监控畛域用于时序数据的图标自定义和展现，UI 非常灵活，有丰盛的插件和弱小的扩大能力，反对多种不同的数据源（Graphite, InfluxDB, OpenTSDB, Prometheus, Elasticsearch, Druid 等等）。Grafana 还提供可视化的告警定制能力，可能继续的评估告警指标，发送告警告诉。
此外，Grafana 社区提供了大量罕用零碎 / 组件的监控告警面板配置，能够一键在线下载配置，简略便捷。
- VictoriaMetrics
VictoriaMetrics 是一个高性能、经济且可扩大的监控解决方案和时序数据库，能够作为 Prometheus 的长期近程存储计划，反对 PromQL 查问，并与 Grafana 兼容，可用于替换 Prometheus 作为 Grafana 的数据源。具备装置配置简略、低内存占用、高压缩比、高性能以及反对程度扩大等个性。
- AlertManager
AlertManager 是一个告警组件，接管 Prometheus 发来的告警，通过分组、缄默、克制等策略解决后，通过路由发送给指定的告警接收端。告警能够依照不同的规定发送给不同的接管方，反对多种常见的告警接收端，比方 Email，Slack，或通过 webhook 形式接入企业微信、钉钉等国内 IM 工具。
2.3 如何搭建一套简略的云原生监控零碎
上文理解了云原生监控畛域的常用工具后，该如何搭建一套简略的云原生监控零碎？下图给出了 Prometheus 社区官网提供的计划：
（出处：Prometheus 社区）
上述零碎开展论述如下：
- 所有监控组件都是以云原生的形式部署，即容器化部署、用 Kubernetes 来对立治理。
- Prometheus 负责指标采集和监控数据存储，并能够通过文件配置或 Kubernetes 服务发现形式来主动发现采集指标。
- 利用能够通过本身的 Metric 接口或相应的 exporter 来让 Prometheus 拉取监控数据。
- 一些短暂的自定义采集指标，能够通过脚本程序采集并推送给 Pushgateway 组件，来让 Prometheus 拉取。
- Prometheus 配置好告警规定，将告警数据发送给 Alertmanager，由 Alertmanager 依照肯定规定策略解决后路由给告警接管方。
- Grafana 配置 Prometheus 作为数据源，通过 PromQL 查问监控数据后，做告警面板展现。
2.4 如何构建能力凋谢、稳固高效的云原生监控体系
上文展现了社区官网给出的监控零碎搭建计划，但该计划在生产环境利用时存在的次要问题：
- Prometheus 单机无奈存储大量长期历史数据；
- 不具备高可用能力；
- 不具备横向扩大能力；
- 短少多维度的监控统计分析能力。
那么对于大规模简单生产环境，如何构建能力凋谢、稳固高效的云原生监控体系？
综合 vivo 本身容器集群监控实践经验、各类云原生监控相干文档以及技术大会上各家厂商的技术架构分享，能够总结出适宜大规模生产场景的云原生监控体系架构，下图展现了体系架构的分层模型。
- 通过云原生形式部署，底层应用 Kubernetes 作为对立的管制治理立体。
- 监控层采纳 Prometheus 集群作为采集计划，Prometheus 集群通过开源 / 自研高可用计划来保障无单点故障以及提供负载平衡能力，监控指标则通过利用 / 组件的本身 Metric API 或 exporter 来裸露。
- 告警数据发给告警组件依照指定规定进行解决，再由 webhook 转发给公司的告警核心或其余告诉渠道。
- 数据存储层，采纳高可用可扩大的时序数据库计划来存储长期监控数据，同时也用适合的数仓零碎存储一份来做更多维度的监控数据统计分析，为下层做数据分析提供根底。
- 数据分析解决层，能够对监控数据做进一步的剖析解决，提供更多维度的报表，开掘更多有价值的信息，甚至能够利用机器学习等技术实现故障预测、故障自愈等自动化运维目标。
三、vivo 容器集群监控架构
任何零碎的架构设计肯定是针对生产环境和业务需要的特点，以满足业务需要和高可用为前提，在综合思考技术难度、研发投入和运维老本等综合因素后，设计出最合乎以后场景的架构计划。因而，在详解 vivo 容器集群监控架构设计之前，须要先介绍下背景：
- 生产环境
vivo 目前有多个容器化生产集群，散布在若干机房，目前单集群最大规模在 1000~2000 节点。
- 监控需要
须要满足生产高可用，监控范畴次要包含容器集群指标、物理机运行指标和容器（业务）指标，其中业务监控告警还须要通过公司的根底监控平台来展现和配置。
- 告警需要
告警须要可视化的配置形式，须要发送给公司的告警核心，并有分级分组等策略规定需要。
- 数据分析需要
有各类丰盛的周、月度、季度统计报表需要。
3.1 监控高可用架构设计
联合上文阐明的环境和需要特点，vivo 以后监控架构的设计思路：
- 每个生产集群都有独立的监控节点用于部署监控组件，Prometheus 依照采集指标服务划分为多组，每组 Prometheus 都是双正本部署保障高可用。
- 数据存储采纳 VictoriaMetrics，每个机房部署一套 VictoriaMetrics 集群，同一机房内集群的 Prometheus 均将监控数据 remote-write 到 VM 中，VM 配置为多正本存储，保障存储高可用。
- Grafana 对接 Mysql 集群，Grafana 本身做到无状态，实现 Grafana 多正本部署。Grafana 应用 VictoriaMetrics 作为数据源。
- 通过拨测监控实现 Prometheus 本身的监控告警，在 Prometheus 异样时能及时收到告警信息。
- 集群层面的告警应用 Grafana 的可视化告警配置，通过自研 webhook 将告警转发给公司告警核心，自研 webhook 还实现了分级分组等告警解决策略。
- 容器层面（业务）的监控数据则通过自研 Adapter 转发给 Kafka，进而存储到公司根底监控做业务监控展现和告警配置，同时也存储一份到 Druid 做更多维度的统计报表。
前文介绍了社区的 Cortex 和 Thanos 高可用监控计划，这两个计划在业界均有生产级的实践经验，但为什么咱们抉择用 Prometheus 双正本 +VictoriaMetrics 的计划？
次要起因有以下几点：
- Cortex 在网上能找到的相干实际文档较少。
- Thanos 须要应用对象存储，理论部署时发现 Thanos 的配置比较复杂，参数调优可能比拟艰难，另外 Thanos 须要在 Prometheus Pod 里部署其 SideCar 组件，而咱们 Prometheus 部署采纳的是 Operator 主动部署形式，嵌入 SideCar 比拟麻烦。另外，在实测中对 Thanos 组件进行监控时发现，Thanos 因为 Compact 和传输 Prometheus 数据存储文件等起因，时常呈现 CPU 和网络的尖峰。综合思考后认为 Thanos 的前期保护老本较高，因而没有采纳。
- VictoriaMetrics 部署配置比较简单，有很高的存储、查问和压缩性能，反对数据去重，不依赖内部零碎，只须要通过 Prometheus 配置 remote-write 写入监控数据即可，并且与 Grafana 齐全兼容。既满足咱们长期历史数据存储和高可用需要，同时保护老本很低。从咱们对 VictoriaMetrics 本身组件的监控察看来看，运行数据安稳，并且自生产应用以来，始终稳固运行无故障。
3.2 监控数据转发层组件高可用设计
因为 Prometheus 采纳双正本部署高可用计划，数据存储如何去重是须要设计时就思考的。VictoriaMetrics 自身反对存储时去重，因而 VictoriaMetrics 这一侧的数据去重失去人造解决。但监控数据通过 Kafka 转发给根底监控平台和 OLAP 这一侧的去重该如何实现？
咱们设计的计划，如下图，是通过自研 Adapter“分组选举”形式实现去重。即每个 Prometheus 正本对应一组 Adapter，两组 Adapter 之间会进行选主，只有选举为 Leader 的那组 Adapter 才会转发数据。通过这种形式既实现了去重，也借用 K8s service 来反对 Adapter 的负载平衡。
此外，Adapter 具备感知 Prometheus 故障的能力，当 Leader Prometheus 产生故障时，Leader Adapter 会感知到并主动放弃 Leader 身份，从而切换到另一组 Adapter 持续传输数据，确保了“双正本高可用 + 去重”计划的有效性。
四、容器监控实际的挑战和对策
咱们在容器集群监控实际的过程中，遇到的一些艰难和挑战，总结如下：
五、将来瞻望
监控的指标是为了更高效牢靠的运维，精确及时的发现问题。更高的指标是基于监控实现自动化的运维，甚至是智能运维（AIOPS）。
基于目前对容器集群监控的经验总结，将来在监控架构上能够做的晋升点包含：
- Prometheus 自动化分片及采集 Target 主动负载平衡；
- AI 预测剖析潜在故障；
- 故障自愈；
- 通过数据分析设定适合的告警阈值；
- 优化告警管控策略。
没有一种架构设计是一劳永逸的，必须要随着生产环境和需要的变动，以及技术的倒退来继续演进。咱们在云原生监控这条路上，须要持续不忘初心，砥砺前行。