监控系统（业务监控数据流和架构）
需求
本次从业务监控出发，监控系统 配置平台化，假设实现以下简单配置需求：
告警类型 | 告警条件 | 告警阈值 |
流量峰值 | >= | t1 |
5xx 状态码占比 | >= | t2 |
传统的监控系统数据流
不管使用何种软件架构实现，数据流和流程一般包含：
- 数据源：业务数据存储的中心，一般为大数据平台中心，其中包含了丰富的大量类型的各种业务数据，供各个系统查询使用。
- 数据metric采集：由于数据源中心提供了大量的业务指标，而使用方仅仅根据自身需要获取部分指标。
- 数据存储：采集的特定metric交由监控系统存储
- 数据引用+规则计算：引用监控系统存储中的数据或者直接引用采集的metric（后存储数据库），进行规则引擎计算
- 告警发送：发送告警
左边是zabbix 玩法：（待后续zabbix 章节补充）
右边是prometheus 的玩法：模块化+PromQL算子使得架构灵活易扩展
- 正常情况下需要开发exporter，从大数据中心的API 接口获取5xx数据，构建好prometheus的metric 格式并提供服务，以供Prometheus pull，
- prometheus pull 数据后，存储到时序数据库，
- 告警模块或者展示模块根据PromQL 算子从数据库引用数据并进行规则计算，告警或者展示
该架构存在以下缺点：
每次新增一个告警时, 需要进行以下重复工作（也许我们可以自动化生成代码或者通过变量配置的方式进行扩展，但是为了抓取数据进行计算 做的中间事情太多了，难道不能直接引用数据中心的数据吗？）
- 需要大数据中心API 提供数据
- 需要开发exporter
同时：prometheus 自带的时序数据库不适合历史大数据量存储和查询，
新型监控系统数据流
prometheus 提供远端存储 remote-storage 来支持 存储历史大数据，而我们正好使用clickhouse 作为大数据存储中心，通过 prom2click（prometheus clickhouse adpter）正好可以作为Prometheus 和 clickhouse 中间的代理提供存储和读取。轻而易举的解决了上述两大缺点：
- 不用开发exporter，采集数据到存储，而是直接引用存储（远端存储）
- 不需要大数据中心API（prom2click + clickhouse mv，clickhouse mv转换成prometheus 格式的存储，prom2click remote 读代理 ）
我们再反思下prometheus为何在servicemesh 容器时代大受青睐，其设计的精华：
- http API 符合微服务的 模块化组装、方便 扩展接口
- PromQL 轻而易举的引用数据并计算
实际上，这两种思想都不算新的革命思想，在事物发展过程中，矛盾总会推动向前发展。而程序的世界就是‘偷懒’。之前在做线上运营的时候，曾经想过把日志拉到本地分析，并支持一系列常规分析算子，简化人工zcat *|awk 等操作。提供http 服务，在url中输入算子，和PromQL 是殊途同归，但是后者却结合数据库做的更完善。
我们继续看新型监控系统数据流的架构：
新型监控系统数据流 还有可以完善的地方吗？
新型监控系统数据流解决了存储的问题，但是监控系统主要瓶颈在三点：
- 存储：监控数据量太大
- 计算：大量监控类型需要执行PromQL 计算
- 网络： 从大量客户端拉取数据的瓶颈
对于计算，实际上还是都是在prometheus上做的，如果担心计算做不过来，我们可以做拆分 业务、集群拆分（我们只是利用了remote read，所以业务分多台prometheus 是完全独立等价的）。
部署多套prometheus 不同的业务使用不同的节点。这种是非标准的做法。网上还有thanos、prometheus 联邦集群、hash等策略。一种比较新颖的做法是：
更新型的监控系统数据流
将计算和存储都放在remote storage 而不是 从remote storage 拉取回来再集中计算，参考 victoriametrics.
本节内容量已经足够多了，架构拓展留在后续章节展开，先继续 业务实现。
