独领风骚的B站，其监控有何过人之处？

《独领风骚的B站，其监控有何过人之处？》要点：
本文介绍了独领风骚的B站，其监控有何过人之处？，希望对您有用。如果有疑问，可以联系我们。

作者简介：胡凯

bilibili,运维负责人

从系统测试到自动化测试到性能测试再到运维,对服务端的兴致带他一步步走近互联网、步入运维行列.丰富的经历,让他对运维有着独特的思考和认知.

前言

随着互联网的高速发展,我们经历的数据量越来越大、越来越重,运维也越来越重要.有幸参加“GOPS2017·全球运维大会.深圳站”,希望通过本文和大家分享过去一年多时间里B站运维监控系统的发展历程以及我的思考.

一、自动发布

回想2015年中入职B站,运维部才正在成立.铺面而来的各种事务,压得我和运维小伙伴们喘不过气来.

想想有好多系统要做,虽然忙得没时间也没人做.

按过往经验,掐指一算：要寻找破局点、尽早做出第一个改变!

当时最耗精力的就是发布,没多久我们看准了从发布着手,先把劳动力解放出来.于是做了简单的发布系统：

基于?OpenLDAP?和谷歌的“身份验证器”作为认证,Gitlab?作为代码托管,按需接入?Jenkins?构建,在堡垒机上包装?Ansible(脚本也在?Gitlab?上),用命令行完成批量部署上线.

初见成效后,简单包装了一个页面、加了发布时间的控制就开心的用起来了.

二、必须做监控

我们服务端典型的应用场景如下图：

用户访问到边缘的?CDN?节点,然后通过二级缓存最后传到核心机房的四层负载均衡LVS集群,再通过七层?Tengine?的?SLB?集群按规则分流到各个应用里.

典型的应用后端会有缓存、队列,然后再到数据库.开发语言有?Go、Java、PHP、Python、C/C++?等(排名不分先后)

那么问题来了：“监控呢?”?B站工程师气氛很浓,热爱开源.连DNS都自研、CDN?自建,链路长、监控少,随业务增多定位问题变得非常困难.

三、第一个报警：ELK

很多人心里都有一套运维自动化系统,而且是闭环的.在有效资源里,从哪里开始呢?

原计划本是打算自下而上,从主机监控一步步往上走.而后发现不少用户反馈的问题,后端无感知.

鉴于?CDN?日志都在手上,用户最开始接触的就是?CDN.索性把错误日志给收回来,错误多了就报警.于是ELK诞生了：

我们仅收错误日志,塞到?ElasticSearch?里,按域名、CDN?节点、用户IP以及错误码进行分类排序.

这样当收到报警短信时,基本第一眼都可以锁定一个故障区域了.随后稍加流程,接入微信完美收工.

以下是报警短信的代码片段,计划任务第分钟执行(很土很有效).另外还有个脚本监控错误日志的数量,但数量为零时也会报警(你懂的).

四、可惜还是你：Zabbix

做完?CDN?监控,我们想回头把基础监控做起来.经过开源、自研?各种讨论,综合下来还是选择了?Zabbix.因为它实施快、报警策略灵活、会用它的人多容易招.

五、监控交给你：Statsd

好,CDN?前端的错误监控,应用底层的系统监控都有了.应用自身的监控怎么做呢?根据当时同事的过往经验看,怎么熟怎么来.那就?Statsd?吧!

Statsd?用起来比较简单,只需要开发在他关注的代码前后加上锚点就可以了.

默认是?UDP?协议上报数据(天生自带异步光环),不容易出现由于监控影响到程序本身.下图是在?Shell?脚本里做?Statsd?监控的示例代码：

搭好一套?Statsd?收集器,配置一下?Graphite?就能出图了：

前端用?Grafana?包装一下,一个完整的?APM?监控闪亮登场.以下图例为某接口的平均响应耗时：

六、百花齐放：Grafana

网传?Grafana?有插件可以直接通过?API?读取?Zabbix?的监控数据,然而没多久新版本的?Grafana?就默认自带了此光环.

然后我们就开心的给?Zabbix?装上了?Grafana?套件,和?Statsd?的监控数据整合在一起、易用性加一分.

此时结合?CDN?错误监控、应用层?APM?监控、底层数据监控,联运查问题某些时候感觉很舒适.下图为一次故障过程的追踪：

我们并没有因此满足,基础架构的同学参考谷歌的文献实现了内部的?Drapper?链接追踪系统.

请求从?CDN?入口开始就会携带?TrackID,甚至不忘在?SQL?的查询语句里把?TrackID?带上.以至于追踪得很细致,哪里什么原因耗时最长一目了然.图示：

（编辑：ASP站长网）