正文
一、监控系统分层
由于早期B站高速发展，巨石架构基于CMS系统搭建，导致代码紊乱。
从研发角度切入，来分析监控系统。
1. 业务层：
监控系统需要关注业务指标，如携程网的酒店下单量，大众点评、唯品会的商品购买指标、实时业务，B站的注册成功率等。
2. 应用层：
（1）端监控，如：河北地区APP无法打开，需要通过端采集数据上报，查找原因；
（2）链路层监控（APM监控），如：唯品会跟踪订单的完整交易流程，或是完整调用链路，查找异常；
（3）日志监控，通过回溯旧日志，浏览TLF等，发现异常。
3. 系统层：
关注网络、AOC、CDN的质量，关注中间件、数据库的问题等。
早期B站仅有Zabbix系统，监控思路是从下往上，效率低下。基于上述监控分层，对B站进行监控系统改进。
二、B站监控系统的演进
（一）B站监控系统改进步骤
1.编写ELK日志分析系统，让研发人员有日志可看，不用重复登录系统查看；
2.将巨石架构逐步转变为微服务化架构；架构转变之后，我们发现系统发生问题时，很难定位Root cause。
3.基于谷歌的Dapper编写监控系统，用于快速查找问题；
4.编写负责PC端、移动端链路上报的Misaka系统，监控运营商信息；
5.编写Traceon系统，关注业务指标和异常监控，将业务指标报表输出给内容、产品同事，把敏感的变更告知监控系统报警。同时将监控报警短信、邮件，发送给 运维、开发，甚至运营、客服和产品同事。
（二）如何通过监控入口，研发找到系统问题
B站的内部指标：在登录运维系统后，核心业务与非核心业务发现故障的时间分别为5分钟之内和20分钟之内。
监控入口类别：
1. 大盘
-
变更：大部分故障是由于变更（发布、修改配置、版本更新）引起的，大盘是看到整个变更的试件，做出变更防御进行动作收集。
-
当前报警：异常治疗
-
失败率
-
全链路
2. 前段：通过提供端，进行服务的服务质量监控；
3. 异常：对失败率、异常汇总统计入口；
4. 业务：投稿成功率等这类指标；
5. 链路：方便查询特定业务链路情况；
6. 系统： 核心网络、CDN、IDC等；
通过以上六个监控入口不同职责的人员，找准自己所属入口，进行监控，发现问题解决问题。
（三）将监控系统化整为零，分而治之
把监控系统全部打通到一个系统里是非常困难的，所以需要把监控系统化整为零。
那么如何串联如此多的监控系统？
借鉴谷歌的traceid，使用traceid把包括日志、链路、HDB接口，前端等在内的全业务系统串联起来，通过Skyeye发现问题，address定位问题。比如：某次B站首页发生故障，前端上报traceid到Misaka，Misaka标红后，研发人员发现故障原因在于ELK。
从研发的角度来说，当监控系统发现故障时，需要及时做出正确报警和报警规划。
1.正确报警：避免误报，做到好的收点。
2.报警规划：比如当核心机房出现问题时，大量接口全部报警，这会影响运维人员判断。需要通过智能报警，自动汇聚一个完整的ELK。
最后总结一下：做好一套监控体系，需要将它拆分成数个小系统，化整为零。通过traceid、address等关联起来，分而治之。
（四）Dapper系统
早期B站包含多种语言，机房分布在多个地方，系统非常复杂。
举个例子，用户浏览移动端首页，一次请求到达服务端，查看编辑推荐、运营推荐、大数据推荐以及分区推荐数据等，涉及多个服务，用户耗时过多，如果发生故障也难以发现原因，效率低下。
后来B站参考谷歌Dapper，发现完整请求是一个树型调用，会记录在系统中完成一次特定的请求后所有的工作信息。只需要在公共组件中植入代码就可以做到。
![]()
![]()
Dapper采样率为抽样采样。
多数系统是全量采量，但是谷歌内部更倾向抽样采量。B站Dapper也采用抽样采样，如果系统发生故障，一旦出现，之后必然会再次出现，抽样采样命中率很高。B站内部也采用多种采样方式（固定采样1/1024、可变采样、可控采样），这种做法，对于网络、存储的压力也较小。
![]()
举一个代码实例：HTP请求，发生拦截。服务器请求中加入这种注入后，可以非常方便的采集到埋点。
