2017年3月12日，又拍云在上海外滩SOHO举行了Open Talk No.29《云上开发与运维体验》技术分享会，B站技术总监毛剑带来了《B站监控体系》的分享，讲解了B站在快速发展业务面前，面对基础设施以及微服务业务架构的双重复杂度，如何通过高效的手段定位和解决系统问题。
毛剑目前就职于bilibili(B站)，主站技术部研发负责人，技术总监，专注服务端高性能，喜欢Golang语言。
以下为毛剑讲师分享稿，由编者整理
文章框架：
一、监控系统分层
二、 B站监控系统演进
理论
B站监控系统改进步骤
如何通过监控入口，研发找到系统问题
将监控系统化整为零，分而治之
应用
Dapper系统
Lancer系统
Misaka系统
Traceon系统
三、监控系统展望
监控系统分层
由于早期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请求，发生拦截。服务器请求中加入这种注入后，可以非常方便的采集到埋点。
加入之后，在编写完整的链路后，推动其他业务部门使用，可以绘制出一个完整的依赖关系。
天猫双十一时，需要花大量的时间进行整体架构梳理。但是如果依靠上文的依赖图，思考在全链路上架构存在的问题、热点、瓶颈，可以避免架构出现重大错误。
通过推动依赖方、业务方，接入事业部之后，十分容易便可以将公司大部分的链路绘制出来。比如说：B站的业务重点依赖瓶颈热点，我们只需要按区域、用户数量这个概念来完成多机房、机房内的单元化部署。通过APM系统，推测出问题。
如何使用Dapper系统定位问题？
如果一个接口耗时久，那它就是需要推进业务方改进的地方。从客户端开始到服务端接受，是一个网络开销，到服务器处理完成之后回包给客户端，Dapper系统可以借此计算出网络耗时。
通过Dapper系统搜索某个项目、接口、时间段，进行抽样采样，得出这个部件每分钟的数据量、耗时。
Lancer系统（以FATE系列枪兵库·丘林命名）
早期B站具体部署到Docker、虚拟机、物理机的业务服务都需要日志打包。但是收集日志的过程不可控，小包数量大，容易丢失。
后来B站进行优化，部署了Log Docker通过进程类通讯上报，并将小包集合成大包后发送，再使用Lancer系统分发。
打开web界面，选定service，点击按钮，Lancer系统会自动发现这个行为，确定采集地点。然后，将采集日志放到ES上和Lancer的商业存储。
通过syslog、log-agent、sys-agent，Kafak进行数据缓冲。B站默认会支持Kafak、ES等比较通用的节点。
上图是Kafak的后端缓冲，由agent完成日志分解工作。Dapper系统的工作流程也类似于此，通过业务服务进程埋点。通过定制搜索需求，将数据镜像一份至ES，暴露Dapper的API，通过APM平台查阅其完整请求。
Misaka系统（以超电磁炮御坂美琴命名）
Misaka作为端监控。需要移动端或PC端在前端埋点，将埋点数据上报，以此检测故障。
就像上图，南京某节点可能出现了DNS劫持或流量劫持。
我们无法解析出详细信息，但是现阶段解析出的内容是HTML，以此判定是流量劫持。通过此类事情，才能真正了解客户端的情况和服务质量，推进HTTPS协议的使用，架构的演进。
Traceon系统（以卫宫士郎投影魔术命名）
Traceon系统通过埋点，进行业务指标和异常收集。它可以通过代码提前定义部门性质，比如：A部门的某个指标上报完成后，Traceon系统会通过原数据查询“它是否被注册过？”如果没有被注册，系统就会完成创建。订单量的大量增加是在Redis中做递增，不断将其累加，再定期回刷至mysql。
上图是B站某商城中的Traceon系统界面。它可以发现某些地方出现的峰值、问题。通过报警规则，把信息发给报警系统，通知具体人员来处理它。
监控系统展望
1.监控系统的各个子系统更加独立完善，各司其责；
2.更完美的Dashboard。Dashboard、报警机制都更加准确；
3.更加完善的监控流程和Oncall机制。
