CDN监控系统（三 业务架构）

监控系统（业务监控数据流和架构）

---

需求

本次从业务监控出发，监控系统 配置平台化，假设实现以下简单配置需求：

告警类型	告警条件	告警阈值
流量峰值	>=	t1
5xx 状态码占比	>=	t2

传统的监控系统数据流

不管使用何种软件架构实现，数据流和流程一般包含：

1. 数据源：业务数据存储的中心，一般为大数据平台中心，其中包含了丰富的大量类型的各种业务数据，供各个系统查询使用。
2. 数据metric采集：由于数据源中心提供了大量的业务指标，而使用方仅仅根据自身需要获取部分指标。
3. 数据存储：采集的特定metric交由监控系统存储
4. 数据引用+规则计算：引用监控系统存储中的数据或者直接引用采集的metric（后存储数据库），进行规则引擎计算
5. 告警发送：发送告警

左边是zabbix 玩法：（待后续zabbix 章节补充）

右边是prometheus 的玩法：模块化+PromQL算子使得架构灵活易扩展

1. 正常情况下需要开发exporter，从大数据中心的API 接口获取5xx数据，构建好prometheus的metric 格式并提供服务，以供Prometheus pull，
2. prometheus pull 数据后，存储到时序数据库，
3. 告警模块或者展示模块根据PromQL 算子从数据库引用数据并进行规则计算，告警或者展示

该架构存在以下缺点：

每次新增一个告警时, 需要进行以下重复工作（也许我们可以自动化生成代码或者通过变量配置的方式进行扩展，但是为了抓取数据进行计算 做的中间事情太多了，难道不能直接引用数据中心的数据吗？）

1. 需要大数据中心API 提供数据

2. 需要开发exporter

同时：prometheus 自带的时序数据库不适合历史大数据量存储和查询，

新型监控系统数据流

prometheus 提供远端存储 remote-storage 来支持 存储历史大数据，而我们正好使用clickhouse 作为大数据存储中心，通过 prom2click（prometheus clickhouse adpter）正好可以作为Prometheus 和 clickhouse 中间的代理提供存储和读取。轻而易举的解决了上述两大缺点：

1. 不用开发exporter，采集数据到存储，而是直接引用存储（远端存储）
2. 不需要大数据中心API（prom2click + clickhouse mv，clickhouse mv转换成prometheus 格式的存储，prom2click remote 读代理 ）
   

我们再反思下prometheus为何在servicemesh 容器时代大受青睐，其设计的精华：

1. http API 符合微服务的 模块化组装、方便 扩展接口
2. PromQL 轻而易举的引用数据并计算

实际上，这两种思想都不算新的革命思想，在事物发展过程中，矛盾总会推动向前发展。而程序的世界就是‘偷懒’。之前在做线上运营的时候，曾经想过把日志拉到本地分析，并支持一系列常规分析算子，简化人工zcat *|awk 等操作。提供http 服务，在url中输入算子，和PromQL 是殊途同归，但是后者却结合数据库做的更完善。

我们继续看新型监控系统数据流的架构：

新型监控系统数据流 还有可以完善的地方吗？

新型监控系统数据流解决了存储的问题，但是监控系统主要瓶颈在三点：

1. 存储：监控数据量太大
2. 计算：大量监控类型需要执行PromQL 计算
3. 网络： 从大量客户端拉取数据的瓶颈

对于计算，实际上还是都是在prometheus上做的，如果担心计算做不过来，我们可以做拆分 业务、集群拆分（我们只是利用了remote read，所以业务分多台prometheus 是完全独立等价的）。

部署多套prometheus 不同的业务使用不同的节点。这种是非标准的做法。网上还有thanos、prometheus 联邦集群、hash等策略。一种比较新颖的做法是：

更新型的监控系统数据流

将计算和存储都放在remote storage 而不是 从remote storage 拉取回来再集中计算，参考 victoriametrics.

本节内容量已经足够多了，架构拓展留在后续章节展开，先继续 业务实现。