我们先来看监控系统的典型架构图，从左往右看，采集器是负责采集监控数据的，采集到数据之后传输给服务端，通常是直接写入时序库。然后就是对时序库的数据进行分析和可视化，分析部分最典型的就是告警规则判断（复杂一些的会引入统计算法和机器学习的能力做预判），即图上的告警引擎，告警引擎产生告警事件之后交给告警发送模块做不同媒介的通知。可视化比较简单，就是图上的数据展示，通过各种图表来合理地渲染各类监控数据，便于用户查看比较、日常巡检。
采集器
采集器负责采集监控数据，有两种典型的部署方式，一种是跟随监控对象部署，比如所有的机器上都部署一个采集器，采集机器的 CPU、内存、硬盘、IO、网络相关的指标；另一种是远程探针式，比如选取一个中心机器做探针，同时探测很多个机器的 PING 连通性，或者连到很多 MySQL 实例上去，执行命令采集数据。
时序库
监控系统的架构中，最核心的就是时序库。老一些的监控系统直接复用关系型数据库，比如 Zabbix 直接使用 MySQL 存储时序数据，MySQL 擅长处理事务场景，没有针对时序场景做优化，容量上有明显的瓶颈。Open-Falcon 是用 RRDtool 攒了一个分布式存储组件 Falcon-Graph，但是 RRDTool 本身的设计就有问题，散文件很多，对硬盘的 IO 要求太高，性能较差。Falcon-Graph 是分布式的，可以通过堆机器来解决大规模的问题，但显然不是最优解。
告警引擎
告警引擎的核心职责就是处理告警规则，生成告警事件。通常来讲，用户会配置数百甚至数千条告警规则，一些超大型的公司可能要配置数万条告警规则。每个规则里含有数据过滤条件、阈值、执行频率等，有一些配置丰富的监控系统，还支持配置规则生效时段、持续时长、留观时长等。
数据展示
监控数据的可视化也是一个非常通用且重要的需求，业界做得最成功的当数 Grafana。Grafana 采用插件式架构，可以支持不同类型的数据源，图表非常丰富，基本可以看做是开源领域的事实标准。
此文章为10月Day08学习笔记，内容来源于极客时间《运维监控系统实战笔记》，强烈推荐该课程
