监控体系建设-演化历程及标准化
目标
本文，结合工作的实践以及他人的分享，整理了监控系统建设中的若干问题以及对应的解决方案。
本文逻辑
监控系统进化一般路径
监控系统如何标准化
小结
监控系统进化的一般路径
如同人类的进化史，大部分公司都会经历 工具时代，平台化，标准化，智能化的过程。
工具化时代
聚焦的问题： 解决有没有的问题。
代表： 基于开源的监控系统如，Nagios+Cacti / zabbix 等。
存在的问题：
1. 无法定制。投入人力和资源都比较少，无法对这些组件和系统深入的二次开发或定制。和
公司的运维体系不能融为一体。
2. 不能规模化. 随着公司业务体量的增加，监控的规模上来后，性能，稳定性，产品易用性
等问题表现突出，无法系统的解决。
平台化时代
聚焦的问题：解决性能，稳定性，以及和运维体系整合联动。
代表：： 如小米开源的open-falcon, 阿里的 alimonitor，鹰眼 等
存在的问题：
1. 监控的全面覆盖，必然带来监控指标的爆炸性增长，带来了监控告警的泛滥。
2. 监控自定义的东西就很多，标准化的程度低，监控的运维管控就很困难，进一步的数据分析挖掘就更难做了
3. 产品的专业性比较强，用户的要求比苛刻，复杂程度高
标准化时代
聚焦的问题：解决监控指标爆炸，监控指标的标准化，业务全链路，以及服务质量评估体系建立。
代表： 阿里的Sunfire监控平台，prometheus+thanos ， 更多的是结合公司的业务层场景， 平台+标准+人工标注。
智能化
聚焦的问题：
发现问题： 异常捕获（时间序列的异常，操作日志异常等）
定位问题： RCA，根因溯源，推荐，事件关联分析等
代表：阿里的智能诊断平台，skyline, Prophet, 腾讯Metis, 以及裴丹老师的相关理论研究
存在的问题：
这部分还处于探索阶段，大部分公司都处于弱智能时代。
监控系统如何标准化
监控系统的标准化的最终目的，是为业务全链路监控打好基础。全链路监控的目的是为了快速发现问题，定位问题。
标准化的目标及意义
我理解的标准化，主要来自三个维度：数据模型层和指标规范层，业务规范层
数据模型层：
指的是建立一种通用的数据模型，能完全覆盖各个监控层级的业务需求，同时能提供一种标准的监控查询语法，满足
各个业务的定制化分析，聚合等需求。
典型的解决方案： 如prometheus 的PROMQL, 和 阿里基于HiTsdb
指标规范： 四个黄金指标，资源类型的通用指标 USE，业务类型的：RED 等
指的是对 监控指标的归一化处理。比如，google SRE 解密中提出的四大黄金指标，
流量 ：业务在单位时间内的调用量，如：服务的QPS、每秒订单笔数等。
耗时 ：业务的具体处理时长，需区分成功耗时和失败耗时。
错误 ：调用出错数量、成功率、错误码。
饱和度 ：应用已使用资源的占比。
Weave Cloud在基于Google的“4个黄金指标”的原则下结合Prometheus以及Kubernetes容器实践，细
化和总结 得出的：RED方法
(请求)速率：服务每秒接收的请求数。
(请求)错误：每秒失败的请求数。
(请求)耗时：每个请求的耗时。
USE方法全称”Utilization Saturation and Errors Method”，主要用于分析系统性能问题，可以指导用户快速识别资源瓶颈以及错误的方法。
使用率：关注系统资源的使用情况。 这里的资源主要包括但不限于：CPU，内存，网络，磁盘等等。100%
的使用率通常是系统性能瓶颈的标志。
饱和度：例如CPU的平均运行排队长度，这里主要是针对资源的饱和度(注意，不同于4大黄金信号)。任何
资源在某种程度上的饱和都可能导致系统性能的下降。
错误：错误计数。例如：“网卡在数据包传输过程中检测到的以太网网络冲突了14次”。
业务规范
为解决业务全链路分析而建立业务监控模型
业务域：一个完整的业务或产品称为“业务域”，如电商的“交易域”、“营销域”、“支付域”等。
业务活动：业务域中的的核心业务用例叫做“业务活动”，如交易域的“下单确认”、“创建订单”等，业务活
动是整个监控模型的核心，每个业务活动都会有标准的【黄金指标】来反应自身的健康状况，业务活动之
间建立上下游关系就形成了业务链路。
系统服务：业务活动中的依赖的关键方法称作“系统服务”，如“下单确认”包含：查询会员、查询商品、查询
优惠等关键方法，每个系统服务也通过【黄金指标】来表示其健康状况。
小结
本文梳理了监控体系建设的进化历程，以及如何实现标准化。后续会介绍如何给予标准化，实现全链路业务监控。