监控告警系统作为底层基础设施的一环，是保障服务稳定性不可或缺的一部分。线上问题从发现到定位再到解决，通过监控和告警手段可以有效覆盖“发现”和“定位”，甚至可以通过故障自愈等手段实现故障解决。在云原生时代，由于Prometheus监控对容器的高度支持，以及容器编排领域的事实标准Kubernetes的各个组件原生支持Prometheus监控指标，使用Prometheus作为监控告警平台的基石成为了不二之选。
本文将从云原生监控告警的基础组件Prometheus和Alertmanager架构、原理解析开始；再阐述大规模场景下使用Prometheus的痛点以及对应的解决方案：引入Thanos和Kvass打造大型分布式监控系统；最后介绍星斗云基于以上组件自研告警管理平台的架构设计与实现。期望对大家在选择监控告警解决方案时有一定启发。
兴盛优选云原生平台（简称：星斗云)，是在Kubernetes等云原生技术基础上开发的多云多集群容器云平台。
2.1 架构解析
Prometheus是云原生监控告警平台的核心，以下就Prometheus架构图（更准确来说是其生态系统图）做如下分析说明：
Prometheus架构图
◇Prometheus Server：核心服务，用于定时抓取并存储时间序列的指标数据；然后提供Http接口并配合其自定义的指标查询语句（PromQL）查询指标数据。
◇Jobs/exporters：exporter用于暴露指标数据（Metrics）给prometheus server；jobs指的是同一类exporters的集合。
◇Push Gateway：主要用于短期的 jobs，由于这类 jobs 存在时间较短，可能在 prometheus Server来拉取之前就消失了。
◇Alertmanager：prometheus server可以配置告警规则rules，然后定时查询数据计算告警规则，当满足告警规则条件时，会将告警Alert推送到配置的Alertmanager；然后Alertmanager进行告警去重、抑制、静默、分组路由等操作，发出报警。常见的接收方式有：邮件、企业微信、Webhook 等。
◇Grafana/Prometheus web UI：通过PromQL查询或者聚合指标数据并根据需要进行可视化展示。
2.2 监控指标标签
Prometheus监控指标标签（键值对格式）是贯穿整个监控告警体系的核心概念，使用标签可以区分被监控事物的特征。例如，一个提供了名称为http_request_total指标的应用，可能分别部署在不同的环境中，为了区分不同环境http请求总数这个指标，可以增加一个键为env的标签，不同环境取值区分开来即可。当需要查询指定环境下（如dev）该指标的数据时，通过PromQL的标签过滤器便可轻松实现：http_request_total{env=’dev’}。
除了过滤获取指定所需的指标数据外，使用PromQL语句配置告警规则后，当满足告警规则的阈值条件时，Prometheus会将携带了标签信息的告警消息发送到Alertmanager。Alertmanager根据标签信息可以做进一步的分组、降噪、去重、抑制、静默、通知等操作。下一章节将详细分析Alertmanager处理告警消息的流程。
由此可见，指标的标签信息贯穿了整个监控指标采集、查询以及告警消息处理流程。
3.1 架构解析
Alertmanager是Prometheus生态圈重要的可选组件，用作接收Prometheus经过计算后生成的告警信息，经过内部的一系列必要处理后，通过企业微信、邮件等方式发送给用户。
Alertmanager架构图（高可用模式）
以上是Alertmanager组件高可用部署模式下的架构图，其各个子模块的功能分析如下：
◇API：告警消息的接收Http接口，主要提供给Prometheus 推送告警消息。
◇Dispatcher：告警消息的调度器，将API模块接收的告警消息根据标签进行分组，便于对每个组的告警消息进行不同的处理。
◇Cluster：Alertmanager集群模式，集群实例间通过Gossip协议通信，避免重复处理告警消息。
◇Notification Pipeline：告警消息处理流水线，主要包含去重、抑制、静默、重试、发送通知等操作。
各个子模块串联起来的工作流程大致可以描述为：API接收到Prometheus发送过来的告警消息存放到Alert Provider这个内存数据结构中，然后调度器Dispatcher异步消费该告警消息，根据用户配置（在Alertmanager配置文件定义）的分组标签信息进行分组路由。
3.2 分组路由解析
首先需要说明的是，将告警消息进行分组路由处理的原因是为了对不同类型的告警消息进行差异化处理。例如，给服务器故障设置了一条标签为严重级别的告警规则（通过标签severity: critical），而给Mysql、Redis等数据库服务设置了一个标签为dbType: mysql的告警规则。当以上告警规则阈值条件满足后，会分别发出带有标签severity: critical和dbType: mysql的告警消息。在Alertmanager配置中可以提前定义好针对severity和dbType标签key进行告警消息分组路由，如下图所示：
Alertmanager分组路由核心配置示例
当severity等于critical时作为一个分组将该消息路由到Administrator这个接收者，而当dbType等于mysql时作为另一个分组路由到DBA这个接收者。Administrator和DBA对应了不同企业微信用户。如此便实现了不同分组的告警消息差异化处理的目的。
以上举例仅仅是为了说明根据标签给告警消息分组后差异化处理的作用，实际上通过更加个性化的分组路由，可以实现非常丰富的告警消息处理。
此外，针对以上Alertmanager分组路由配置示例，为了更直观更清楚阐述路由分组的原则和原理，以下给出了配置示例对应的分组路由树的示例。需要注意的是：实际的生产配置中，路由树理论上可以多层嵌套，分组也可以更加个性化。
Alertmanager分组路由树示例
在实践过程中得知原生的Prometheus不依赖分布式存储，单个服务节点具备自治能力。但由于只支持单机部署，没有自带支持集群部署，因此不支持高可用和水平扩容。星斗云早期的监控在集群规模不大的情况下，通过Kubernetes的Statefulset工作负载类型部署了两个Prometheus实例实现了高可用，不具备水平扩容能力；随着我司各条业务线逐步接入星斗云，容器实例数不断增长，意味着被采集服务的指标数量的大幅增长，此时出现了单个Prometheus实例的内存超过了单台服务器内存总量的情况，导致Prometheus出现OOM无法继续运行。即便可以通过将Prometheus实例调度到内存总量更高的服务器节点上，但显而易见的是，随着业务发展，监控数据的不断增长，内存再高的单台服务器也无法支撑。在此背景下，经过调研，我们引入了Kvass轻量级Prometheus横向扩容方案解决了Prometheus分布式采集问题；此外，由于星斗云纳管了包含内部我司自建机房的开发测试环境集群、京东云生产环境集群、华为云生产环境集群等多套集群环境，针对不同集群需要一个统一的全局监控数据视图，因此引入了Thanos组件，该组件主要提供了全局视图、监控数据长期存储、高可用的高级特性。
由此，星斗云监控的底层架构进化成了Prometheus+Kvass+Thanos的组合，彻底解决了大规模监控场景下出现的数据存储、水平扩容、高可用等问题。
4.1 分布式解决方案
kvass+thanos简要架构图
以上便是Kvass+Thanos+Prometheus监控体系的架构设计图，其中Thanos Sidecar和kvass sidecar采用了经典的Sidecar模式，实现了thanos/kvass组件与prometheus的松耦合。其整理工作流程大致如下：
1、kvass coordinator作为自动水平扩容prometheus实例的控制器，通过原生Prometheus配置文件进行服务发现，并评估整体指标数量与单个实例最多承载指标数量来觉得扩容多少个prometheus实例，并将不同prometheus实例采集不同指标的监控目标分发给各个实例的kvass sidecar。
2、kvass sidecar接收来自kvass coordinator分配的监控目标，然后以静态配置文件方式生成新的Prometheus配置文件供该实例的Prometheus使用。
3、经过kvass组件的处理后，prometheus形成了分布式部署形态，当需要查询监控数据时，需要使用聚合组件Thanos Query进行聚合多个Thanos Sidecar查出的数据。
4、Grafana等可视化客户端直接对接统一监控数据视图的Thanos Query便可查询所有监控数据。
4.2 星斗云告警管理平台
解决了监控指标的分布式存储、高可用等问题后，另一个常用的核心功能就是针对监控指标配置告警规则，当满足告警规则条件时对触发告警并及时处理告警消息也是非常重要的。原生的Alertmanager可满足大部分无复杂业务场景的告警消息处理。但星斗云作为基础设施提供方，当用户的应用部署到星斗云上时，不同用户的不同重要程度的应用出现异常时（例如OOM导致应用挂掉），需要平台方通过不同渠道（电话、短信、企业微信等）发送给不同的用户。这就对平台方动态识别应用负责人（即告警联系人）联系方式和告警重要程度（对应不同通知渠道）、通过告警消息可快速定位故障（携带星斗云链接信息）、以及用户自定义告警规则等能力提出了要求。在此背景下，星斗云通过自研告警管理平台实现了以上需求。
星斗云告警管理平台纳管多集群监控告警架构如下图所示：
星斗云告警管理平台整体架构图
该告警管理平台提供的核心功能为：告警规则配置按需配置能力和告警消息支持企业微信、语音电话等多渠道通知能力。
告警规则配置流程：用户通过屏蔽了复杂度的星斗云前端页面创建告警规则，前端调用告警规则模块提供的HTTP接口，告警规则模块再创建对应集群环境下的PrometheusRule（K8S CRD资源，由Prometheus Operator转换为实际的Prometheus告警规则），Thanos Rule模块（Thanos组件之一，用于计算告警规则并推送告警消息到Alertmanager）监听到PrometheusRule创建后会立即热更新其真正的告警规则配置文件，然后Thanos Rule周期性评估告警规则，达到阈值后触发告警发送到Alertmanager。
告警消息处理流程：Alertmanager接收到Thanos Rule发送过来的告警消息后，经过内部的去重、分组路由后通过webhook（HTTP POST）发送到告警消息接收模块，该模块对消息进行基本校验通过后根据不同类型的消息写入Kafka消息队列的不同topic中，最后告警消息处理（消费）模块通过订阅告警消息Topic，进行高并发的告警消息通知发送并写入数据库（便于后期统计分析、回溯）。
本文分析了当下云原生监控告警领域使用最广泛的Prometheus和Alertmanager，并重点分析了Alertmanager告警消息分组路由原理。并根据在实际使用中碰到随着业务大规模部署上云，指标数量大幅增长而Prometheus无法水平扩容导致的监控异常，分析了基于kvass和thanos的解决方案。最后重点分析了星斗云告警管理平台的整体架构。希望通过对这一整套大型分布式监控告警系统的整体分析，让读者可以深入解云原生监控告警体系，对解决云原生下大规模监控告警问题有所启发和收获。
| 留言与评论（共有 0 条评论） “” |
