监控与告警系统

一 背景

很多时候习以为常的东西，到了一个新环境会发现完全不一样，比如监控。新环境中监控体系的缺失，萌生了写这篇文章的想法。当一个系统从0到1的时候，到底什么东西应该作为监控的指标，如何收集这些数据， 如何设置报警规则。以上从前觉得习以为常的东西，突然发现还是有必要思考，记录整理一下。

ps：以下是自己从工作，学习中总结出来的一些经验，个人观点。如有问题欢迎指出和交流。

二 监控的定义

监控是观察并检查系统及其组件随着时间的推移而产生的行为和输出 - Greg Poirier 在2016年的Monitorama讨论会上

这段定义揭示了监控的核心目标，对系统的行为和输出的观测。监控是系统可观测性的一部分。我们今天主要讨论监控，可观测性是一个更大的主题，后面单独写一篇。

三 为什么要有监控系统

稳定性，复杂性，自动化

3.1 稳定性

线上的系统，我们需要保证稳定性。对于系统的异常情况，能够立刻进行感知。比如服务进程因为某些原因被kill了，如果没有监控，可能只有用户反馈了，我们才知道出现了问题。

3.2 复杂性

现在互联网公司的程序都非常复杂，大部分都是微服务分布式容器部署的架构。涉及到众多的中间件和服务。在这一过程中，我们需要监控收集的指标和数据众多。容器层的数据，硬件层的数据，服务内部业务指标，相关中间件的业务和基础指标等等。将这些数据收集，关联，存储，分析，可视化的展示是一个系统级别的工程。

3.3  自动化

考虑到上面复杂性问题，不能让前台业务开发的同学去手动配置基础监控，当相关的容器，中间件被创建出来的时候，对应的监控就应该自动创建好了。 同时我们还需要能让业务开发快速接入业务数据监控的方式，提高开发的效率。进一步提高效率，通过自动化的监控和告警系统，可以在触发报警规则后，第一时间人工或者自动化处理。

四 监控的设计

一个监控系统应该有什么

1. 数据采集
2. 数据存储
3. 可视化
4. 分析
5. 告警

上面是一个监控系统的基本功能。如何实现他们呢？对于现代监控系统来说，既有开源的解决方案，也有云服务商提供的一整套解决方案。有大而广的一体化解决方案，也有自由搭配的组件化组合方案可以选择。下面我们一一介绍。

4.1 数据收集

数据收集有两大范式

1. 推送
2. 拉取（采集）

监控数据的特征是大数据量，时间排列的。整个采集会将经过以下流程

[数据产生源] → [采集 Agent] → [传输管道] → [存储]

在传输管道中一般采用大数据流式架构。agent采集的数据使用kafka或者rocketmq中转，减少突然增长的数据对系统的影响，也起到持久化数据的目的。通过flink或者spark等大数据计算框架，根据规则进行计算后，可以根据其中的报警规则识别异常的数据，进行报警。

4.2 数据存储

根据数据的不同类型，选择合适的数据库。

1. metrics：使用时序数据库（TSDB）如 Prometheus、VictoriaMetrics、Thanos、Mimir。
2. logs：Elasticsearch、Loki、ClickHouse。
3. traces：Jaeger、Tempo、Zipkin。

4.3 可视化

但是Grafana已经成为了事实上的监控可视化标准。所有的中间件都能够接入Grafana中。另外一套常用方案ELK，这套体系和其他兼容性不太好。

4.4 分析

Prometheus是单机设计的方案。大数据量的存储和分析会有性能瓶颈。可以尝试分布式的Prometheus方案，或者ElasticSearch。

简单的方式是近期的数据存储在Prometheus中，全量数据存储在专门的OLAP数据库。比如ClickHouse，Druid，Doris（StarRocks）。

4.5  告警

监控数据有了，让人去24小时值守也不现实。所以要给每一个数据指标配置对应的报警规则。

需要告警的维度可以有三大类

1. 基础服务（硬件，中间件，基础组件等）
2. 基础指标（qps，磁盘占用，网络io，cpu等）
3. 业务指标（业务自定义指标）

其中基础服务和基础指标，可以有默认的配置模版，用户也可以根据自己业务修改默认模版参数。

业务指标就是业务方自己将监控数据收集后，在监控系统上根据规则配置的报警监控。常见的比如总qps波动，某个场景的qps波动率，某个错误日志的打印，接口有果率等等。

触发报警后可以通过IM，电话，短信的形式通知到业务方接收人。

五 监控的一些思想

1. end to end
2. 可组合性和灵活

5.1 end to end

服务面向的人是用户。如果我们加了一堆监控，但没有在最终用户的使用界面上添加监控，那么就没有任何意义。如果出现了问题只能指望用户来提醒我们了。

1. 监控首先要加在最重要的，会影响用户的服务和代码上。
2. 监控要加到最终用户的界面上。从用户发起到用户结束。贯穿整个流程。

5.2  可组合型和灵活

世界上没有银弹，也没有说哪个系统能解决所有问题。一个看起来大而完善的系统，往往只适用于当前。随着业务的发展，这种系统的扩展性都会有问题，最终只能彻底放弃。

监控系统来说，将功能拆分成为不同的模块，每个模块使用不同的中间件实现。将他们组合起来成为一个完整的系统。当其中某个模块不符合业务的需求（性能，扩展性，功能等）我们可以方便的替换掉。

整体架构

                +--------------------+
                |     被监控对象      |
                | (应用 / 主机 / 容器) |
                +----------+---------+
                           |
                     [Agent / SDK / Sidecar]
                           |
        +------------------+-------------------+
        |                                      |
   [Metrics 收集器]                    [Logs/Traces 收集器]
 (如 Prometheus NodeExporter)     (如 FluentBit / OpenTelemetry)
        |                                      |
        +------------[传输通道]----------------+
                           ↓
                   [集中式 Collector / MQ]
                           ↓
                   [统一存储（TSDB / ES / S3）]
                           ↓
                +----------+-----------+
                | 可视化（Grafana 等）  |
                | 告警系统（AlertMgr） |
                +----------------------+

六 总结

监控和告警系统作为互联网服务软件风险控制的基石。需要我们对其有一定的了解和有意识的搭建起来。如果是一个新服务，那么上线前，需要把基础的业务和系统监控指标配置完成。如果是一个新功能和需求不仅仅是完成这个需求，在上线前要考虑好本次新添加业务是否需要建立新的监控等等。

后面打算写一下，监控指标的配置，如何配置有效的监控告警指标，减少误报。

还有可观测性，如何建立系统的可观测性，出现问题分析和排查问题。