要达到这个目标，监控对象必须具备可观测性，即通过数据描述是否出现异常，这些数据包括指标监控 Metric、日志 log 和 Trace 数据。
为了实现缩短 MTTR 的目标，监控系统应该具有这些能力：
- 数据采集能力，获取可观测的数据
- 数据能够方便加工，比如把相关的数据汇聚起来，得到我们需要关注的数据
- 对这些关注的数据，做异常检测，及时产生告警
- 收到告警后，通过 Dashbord 查图定位，最好有专家推荐，加速定位
- 定位问题后，通过预案平台进行快速止损
- 整个监控系统需要做到高可用，监控就是为了发现异常，如果由于异常导致自身不可用，肯定是减分的
从下往上来看，首先是抽象层，包含 CMDB（配置管理数据库），抽象了我们对监控对象的定义，比如定义了应用、机器、域名、网络等，比如确定监控系统里面机器到底是用 IP 还是 Hostname。采集层包含众多采集手段，包括机器、容器、进程、日志、端口等，可以通过 Agent 数据传输，或者外部探测点定期拉取，也可以用户直接通过 API 推送进行数据采集。
数据采集后，分为三条数据流处理：计算、存储、告警，计算即进行数据加工，如聚合计算把 10 台 Nginx 的 PV 累加起来；数据存储便于 Dashbord 能够查看；报警通路进行异常检测，快速发出报警。上层计算平台基于智能算法对异常或者故障的根因进行分析，进行根因推荐，输出专家辅助定位。最终到达用户层，提供用户常见的监控功能点：监控配置维护、告警处理、预案管理等。
从数据的视角来分解监控系统，同样分为四层，上图尝试用不同颜色、形状的图形去说明采集、计算、存储、告警等模块在数据视角的功能。打比方说：数据抽象层，即把监控数据被抽象成是各种形状、各种颜色的模块，数据采集就是标准化过程，把各种形状颜色的数据用统一的方式表示，比如上图用一个云的形状把各种图形框起来；聚合计算就是对同一标签的数据做聚合处理，比如上图按照颜色来聚合，存储流把相同的形状颜色顺序摆好，告警则是挑选出有红色框的数据（上图表示异常数据点）。所以，无论是采集、聚合、存储、告警还是查看 Dashbord，本质上都是对数据的一些处理、变换操作。
举个例子，用户 Dashbord 筛选耗时 >2s 的曲线、和告警模块筛选出 >2s 告警，对应数据视角是一致的，都是做一些数据计算过滤等。所以，如果我们把数据的通用处理，过滤转换、运算表示为统一通用能力，用 F(x) 表示，那么在设计监控的时候，把这些通用能力封装成 .lib 可以应用到各个模块中，不但能够实现很强的能力复用，还能简化系统设计。站在数据的视角上，将监控系统理解为一个数据处理系统，会有助于更好的理解监控系统。
那么从数据视角分析监控系统，还需要优先考虑以下这几个部分：
1、数据模型先行，不同模型代表着不同的数据描述及处理能力，进而会对监控产品的形态产生影响
以一个 Http 的 2xx 的请求 PV 为例，用单值模型描述，即通过“监控项名字 + 取值”来描述，这种体验就跟如下左图一样：去地摊买东西，不同数据平铺开来，关联比较弱；用多维度单值模型，引入了标签的概念，比如这里面的 code:200，通过“名字 + 标签”组合去描述，如中间图：去超市货架买东西，同种商品公用一个饮料标签，如上层是可乐标签，通过标签可以快速找到相关性的众多商品；而多维度多值模型，如右图：一次性就能够把你想吃的东西都拿到，同样还能得到一些有趣的数据，如商家可以知道喜欢吃番茄口味薯片的人对铜锣烧的需求爱好是什么。类比到监控领域，PV 和耗时放到一块，然后一块进行存储，这样我们可以方便获取到耗时大于两秒的那些 PV 是多少，因为他们是存储在一起的。所以先清楚监控系统的数据模型，对于理解监控系统很重要。
如果是用 Agent 数据传输的方式，首先要考虑就是 Agent 稳定性，也就是资源消耗的问题。从 CPU、内存、磁盘等都需要做一些限制，保证 Agent 有确定性最大资源消耗。
3、监控数据存储具有读写正交、meta 的灵活查询需求，基本上会采用列式存储 + 倒排 +Gorilla 的方案选型
为了满足读写正交要求，业界一般采用列式存储作为主存，如 Hbase、Cassandra，满足监控查询按照标签做灵活检索，一般采用倒排存储 meta 数据，这样可以实现类似百度通过标签筛选指标，监控数据有最新值查询的需求，所以采用基于 Gorilla 的缓存。所以京东云的 TSDB 选型方案为 Es+Cassandra+Gorilla。
4、聚合计算就是对数据进行范围圈定，进行算子处理
数据另外一条流加工常见的是聚合计算，比如有 3 台 Nginx 程序，部署在 H1、H2、H3 机器上，需要把这三台机器的 PV 加起来，这个就是聚合计算，而需要把 PV 在 httpCode=2xx、3xx 进行展开，则称为多维度聚合计算。
要实现这个目标，从数据视角看，首先需要做范围圈定，也就是 H1、H2、H3 为什么是在一起计算？这就需要通过标签进行关联。范围圈定后进行数据的算子处理，比如常见的 sum、min、max、avg 运算，数据量级不大的情况下，可以让存储模块完成，但当数据量级较大，一般会发送给流式计算平台。京东云选择是用 Spark Streaming 来计算，为了保证稳定性，京东云设计了对流式计算的调度能力，分机房部署了 Spark 计算集群，通过一个 map，指定调度，比如把 Nginx 应用放到 SparkA 进行计算，MySQL 应用放到 SparkB 进行计算，这样，当某个 Spark 出现问题，也能快速做调度止损，定位恢复另一个集群。对于重型开源系统，设计实现的时候，可以考虑在前面加一层 Proxy，将开源细节封装起来，这样当出现异常时，会有较强的掌控能力。
5、报警通路做好“质检员”工作，同时完成通知用户这件事情
告警通路的作用其实是质检，通过抓取数据做检查，发现问题就及时报警。从数据视角来看，报警通路作用归纳到两类，一是时序数据处理，可以依据基于经验的算法，比如简单阈值、同环比等，如果这些方法解决不了，就尝试基于统计的机器学习算法。二是为了让通知更加有效，京东云目前的思路是事件的标签化，支持对告警事件进行合并，比如：用户通过标定告警级别，选择不同的告警方式和时效性，按照环境合并告警。
那么如何按照监控标准去指导监控产品的落地呢？看京东云如何从发现问题、定位问题和解决问题三个方面来减少 MTTR：
在发现问题阶段，分别面向管理者和运维人员设置监控系统的打分机制及推荐系统，给予管理者一个直观的总分和每个维度的细分得分，使得管理人员对整体监控有个量化的指标，另一方面，对于运维人员，则提供配置推荐、一键启用，可以快速地根据标准去完善监控，达到监控变‘全’。
在定位问题阶段京东云推进了变更可视化项目，将上线、配置更改、第三方的变更事件，都接入到变更事件中，用户可以根据时间去查询时间段的变更，跟报警做关联，京东云也会根据一些相关性的算法推荐，将变更推荐给用户，加速问题定位过程。
处理问题阶段京东云可提供预案平台，对预案进行标准化分类，指导用户管理预案。
这就需要首先数据量化，先统计各个渠道的告警总数，然后分两步走，对于产品线负责人，需要让产品线的负责人知道自己部门的情况，另一路出分析数据，拆解产品线发送多的原因，给运维同学提供数据指导，分析各种有可能导致发送告警多的原因，如：一条短信平均接收人、哪些告警规则发送较多等。
基于这些统计数据，监控团队去成立告警收敛项目：在面对接收人过多的情况（一个短信原来需要 10 几个人接收），京东云推出值班表计划，在产品设计上保证告警规则设置的合理性，对于一些大规模触发情况，比如网络故障，京东云默认会按照规则、应用进行合并，同时为了在合并之后让用户能看的更清楚，京东云也推出了移动端程序。
面向未来，颜志杰老师说：“数据处理原来基于规则和经验解决了不少问题，后续疑难杂症会慢慢尝试基于统计和大数据的机器学习，因为效果更明显。在数据收集方面，由于云原生的兴起，常见的可观测数据将会变得更加标准化，而对于一些非结构化的，比如日志，会有机器学习的算法去帮助语义理解标准化。在数据处理层面，对于单数据的处理，我们去判断比如一条曲线的动态阈值是什么样子，很多公司已有不少实践，未来多数据之间的联动处理，会更加有意义，比如一个域名告警了，如果同一时刻其他部门域名大规模告警，那么平台或者网络的可能性较大，否则应该是自身的原因较大，越来越多用大数据的思想分析多指标数据将会更加普遍。同时数据处理方面，Trace、log、Metric 之间的关联将会越来越智能，准确，最后数据驱动整体闭环，未来，监控将会在数据的大道上，通向 AI 化，智能化。”
点击“阅读”了解京东云监控系统产品
欢迎点击“京东云”了解更多精彩内容
Q&A 课程问答
Q
报警系统，优先级怎么处理？
A
告警分级是常见的处理方式，不同的告警级别（比如0级1级2级）代表不同的处理时效性，一般对于0级的告警的话，需要有对应预案，并定期演练，收到告警之后，应该直接快速进行预案处理，5-10分钟要进行预案执行完成并check，同时第一时间需要进行上级的通告；1级告警，可能处理的时间要求更宽松一点，但比如在30分钟没有处理完成，也需要进行上级的通告；2级告警，可能进行定期巡检，在更宽松的时间处理完成即可。所以，不同的级别，可以对应不同的通知方式、处理时效性、通告时效性、预案管理等；衡量标准就是异常MTTR对公司造成的金钱或者品牌的损失。
Q
请问监控有专门的团队吗？监控团队 大概是怎么分工的？
A
其实这边是在刚开始按照监控模块分解监控系统的时候，已经给了说明，对于我理解来说，监控的团队一般分为采集计算存储，然后告警，还有算法，加业务端这些模块，相应的团队也是这么去分的，今天想要强调的是，如果站在数据视角，那么团队之间的分工就相对比较清晰，大家都是围绕数据的流转来协作，采集的数据可以进行聚合加工，最终进行存储；告警对加工后关联的数据做运算，发现异常；业务端则是站在用户的角度思考怎么对数据做呈现；所以，如果把数据的处理统一抽象成为公共模块或者lib，对于监控系统设计是能极大简化，同时，不同团队之间也更加紧密。
Q
请问一下监控系统自身的监控是怎么做的？
A
这是一个好问题，比如说大家业界开源的比如说普罗米修斯，他可能是两个普罗米修斯之间互相去做监控，然后所以说监控系统你肯定不能依赖于自身去做监控，一般来说，就是你得有另外一个系统去做这个监控。所以比如前面说的prometheus互相监控，达到A挂了B可以报，B挂A可以报；另外就是设置一些必然会有的告警，比如每条早上9点有短信、电话告警；如果缺失了，那就表明监控系统有问题。
