B 站监控体系——OpenTalk技术干货系列

一、监控系统分层

由于早期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机制。

更多详情请点击（内附ppt及演讲视频）：