B站的运维成长之路(监控篇)

社区广播:运维派(Yunweipai.com)是国内最早成立的IT运维社区,欢迎大家投稿,让运维人不再孤寂的成长!

作者简介:

胡凯

bilibili, 运维负责人

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

前言

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

一、自动发布

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

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

B站

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

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

Gitlab

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

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

二、必须做监控

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

监控

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

CDN

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

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

三、第一个报警:ELK

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

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

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

ELK

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

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

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

代码

四、可惜还是你:Zabbix

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

Zabbix

五、监控交给你:Statsd

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

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

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

Statsd

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

 Graphite

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

APM

六、百花齐放:Grafana

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

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

Grafana

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

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

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

Drapper

七、突破壁垒:Misaka

做完如上监控,发现仍然有用户反馈问题时我们束手无策。因为我们没有收到任何与此用户相关的错误信息……

可能网路过程出现了未知原因,比如“被加速”、“功能问题”、“异常退出”等等。

于是我们的舆情监测系统 Misaka 上线,和CDN错误日志思路相同;不同的是客户端是真客户端,突破了服务端的壁垒。

Misaka

由于 Misaka 上线的受众群体更广,我们简单包装了一下界面(虽然我觉得 ELK 更漂亮)、添加了历史数据的比较。更利于分析,下图示例:

Misaka

八、报警整合

随着人员的加入和系统的逐步完善,定制化的监控和系统也越来越多。比如,支持多种集群模式的 Redis 集群监控:

还有队列的监控,以及把 Kafka 队列包装成支持 Redis 协议的 Databus 中间件的监控。下图示例:

监控

随即 Docker 的监控也来了,下图示例:

那么问题又来了,这么多监控,眼不花吗?会不会查问题的时候得开N个窗口,拼经验看谁定位问题更快……

痛定思痛,我们走访了几家互联网公司。然后默默的做了一次整合,将报警和事件以时间轴的方式展现了出来。

用过都说好,下图示例:

九、在路上:Prometheus

经历约一年时间的洗礼,我们又回到了监控系统的选型。

为什么?因为越来越多的花样监控需求,已经无法很快得到满足、而且维护工作日渐繁琐。嗯,可能不同阶段需要不同的解决方案。

那为什么是 Prometheus?因为可选的开源产品并不多,新潮前卫的现代化监控就 OpenFlaon 和 Prometheus 啦。

Prometheus

Prometheus 不止是监控工具,它是一套完整的监控解决方案。除了前端,其它都好。

很快 Prometheus 就上线了,逐步取代了 Zabbix。前端仍然是熟悉的Grafana:

不得不说 Prometheus 真的很强大,过去都用 Ganglia 监控 Hadoop 监控。如今 Prometheus 轻松搞定,颜值还不差:

MySQL 的监控数据也非常详尽,以下截图看懂的是专业 DBA:

我们在路上,期待与你共享。

文章来自微信公众号:高效运维

网友评论comments

发表评论

电子邮件地址不会被公开。 必填项已用*标注

暂无评论

Copyright © 2012-2017 YUNWEIPAI.COM - 运维派 - 粤ICP备14090526号-3
扫二维码
扫二维码
返回顶部