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预测剖析潜在故障；
  • 故障自愈；
  • 通过数据分析设定适合的告警阈值；
  • 优化告警管控策略。

没有一种架构设计是一劳永逸的，必须要随着生产环境和需要的变动，以及技术的倒退来继续演进。咱们在云原生监控这条路上，须要持续不忘初心，砥砺前行。