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及演讲视频):

B站监控体系opentalk.upyun.com

编辑于 2018-03-20