典型架构

采集器是负责采集监控数据的，采集到数据之后传输给服务端，通常是直接写入时序库。然后就是对时序库的数据进行分析和可视化，分析部分最典型的就是告警规则判断（复杂一些的会引入统计算法和机器学习的能力做预判），即图上的告警引擎，告警引擎产生告警事件之后交给告警发送模块做不同媒介的通知。可视化比较简单，就是图上的数据展示，通过各种图表来合理地渲染各类监控数据，便于用户查看比较、日常巡检。

采集器

采集器负责采集监控数据，有两种典型的部署方式

• push模式：跟随监控对象部署，比如所有的机器上都部署一个采集器，采集机器的 CPU、内存、硬盘、IO、网络相关的指标；
• pull模式：远程探针式，比如选取一个中心机器做探针，同时探测很多个机器的 PING 连通性，或者连到很多 MySQL 实例上去，执行命令采集数据。

时序库

老一些的监控系统直接复用关系型数据库，比如

• Zabbix 直接使用 MySQL 存储时序数据，MySQL 擅长处理事务场景，没有针对时序场景做优化，容量上有明显的瓶颈。
• Open-Falcon 是用 RRDtool 攒了一个分布式存储组件 Falcon-Graph，但是 RRDTool 本身的设计就有问题，散文件很多，对硬盘的 IO 要求太高，性能较差。Falcon-Graph 是分布式的，可以通过堆机器来解决大规模的问题，但显然不是最优解。

后来出现的时序数据库有

• OpenTSDB：底层存储是基于HBase的，国内受众较少
• InfluxDB：生态完备，但开源版本是单机的，没有开源集群版本
• TDEngine：偏设备监控，集群版是开源的，不支持 Prometheus 的 Query 类接口
• M3DB：全开源，架构原理比较复杂，CPU 和内存占用较高
• VictoriaMetrics：架构非常简单清晰，采用 merge read 方式
• TimescaleDB：基于 PostgreSQL

告警引擎

告警引擎的核心职责就是处理告警规则，生成告警事件。通常来讲，用户会配置数百甚至数千条告警规则，一些超大型的公司可能要配置数万条告警规则。每个规则里含有数据过滤条件、阈值、执行频率等，有一些配置丰富的监控系统，还支持配置规则生效时段、持续时长、留观时长等。 告警引擎通常有两种架构

• 数据触发式：指服务端接收到监控数据之后，除了存储到时序库，还会转发一份数据给告警引擎，告警引擎每收到一条监控数据，就要判断是否关联了告警规则，做告警判断。因为监控数据量比较大，告警规则的量也可能比较大，所以告警引擎是会做分片部署的，即部署多个实例。这样的架构，即时性很好，但是想要做指标关联计算就很麻烦，因为不同的指标哈希后可能会落到不同的告警引擎实例。
• 周期轮询式：架构简单，通常是一个规则一个协程，按照用户配置的执行频率，周期性查询判断即可，因为是主动查询的，做指标关联计算就会很容易。像 Prometheus、Nightingale、Grafana 等，都是这样的架构。

数据展示

Grafana 采用插件式架构，可以支持不同类型的数据源，图表非常丰富，基本可以看做是开源领域的事实标准。 监控数据可视化，通常有两类需求

• 即时查询
• 监控大盘

此文章为3月Day04学习笔记，内容来源于极客时间《运维监控实战笔记》，强烈推荐该课程！