互联网系统运维实践

1、 互联网系统运维实践前言随着互联网的高速发展，企业经历的数据量越来越大、越来越重，运维也越来越重要。希望通过本文分享B站运维监控系统的发展历程以及我的思考。一、自动发布按过往经验，掐指一算：要寻找破局点、尽早做出第一个改变！当时最耗精力的就是发布，没多久我们看准了从发布着手，先把劳动力解放出来。于是做了简单的发布系统：基于OpenLDAP和谷歌的“身份验证器”作为认证，Gitlab作为代码托管，按需接入Jenkins构建，在堡垒机上包装Ansible（脚本也在Gitlab上），用命令行完成批量部署上线。初见成效后，简单包装了一个页面、加了发布时间的控制就开心的用起来了。二、必须做监控我们服务端

2、典型的应用场景如下图：用户访问到边缘的CDN节点，然后通过二级缓存最后传到核心机房的四层负载均衡LVS集群，再通过七层Tengine的SLB集群按规则分流到各个应用里。典型的应用后端会有缓存、队列，然后再到数据库。开发语言有Go、Java、PHP、Python、C/C+等（排名不分先后）那么问题来了：“监控呢？”B站工程师气氛很浓，热爱开源。连DNS都自研、CDN自建，链路长、监控少，随业务增多定位问题变得非常困难。三、第一个报警：ELK很多人心里都有一套运维自动化系统，而且是闭环的。在有效资源里，从哪里开始呢？原计划本是打算自下而上，从主机监控一步步往上走。而后发现不少用户反馈的问题，后端无

3、感知。鉴于CDN日志都在手上，用户最开始接触的就是CDN。索性把错误日志给收回来，错误多了就报警。于是ELK诞生了：我们仅收错误日志，塞到ElasticSearch里，按域名、CDN节点、用户IP以及错误码进行分类排序。这样当收到报警短信时，基本第一眼都可以锁定一个故障区域了。随后稍加流程，接入微信完美收工。以下是报警短信的代码片段，计划任务第分钟执行（很土很有效）。另外还有个脚本监控错误日志的数量，但数量为零时也会报警（你懂的）。四、可惜还是你：Zabbix做完CDN监控，我们想回头把基础监控做起来。经过开源、自研各种讨论，综合下来还是选择了Zabbix。因为它实施快、报警策略灵活、会用它的

4、人多容易招。五、监控交给你：Statsd好，CDN前端的错误监控，应用底层的系统监控都有了。应用自身的监控怎么做呢？根据当时同事的过往经验看，怎么熟怎么来。那就Statsd吧！Statsd用起来比较简单，只需要开发在他关注的代码前后加上锚点就可以了。默认是UDP协议上报数据（天生自带异步光环），不容易出现由于监控影响到程序本身。下图是在Shell脚本里做Statsd监控的示例代码：搭好一套Statsd收集器，配置一下Graphite就能出图了：前端用Grafana包装一下，一个完整的APM监控闪亮登场。以下图例为某接口的平均响应耗时：六、百花齐放：Grafana网传Grafana有插件可以直接

5、通过API读取Zabbix的监控数据，然而没多久新版本的Grafana就默认自带了此光环。然后我们就开心的给Zabbix装上了Grafana套件，和Statsd的监控数据整合在一起、易用性加一分。此时结合CDN错误监控、应用层APM监控、底层数据监控，联运查问题某些时候感觉很舒适。下图为一次故障过程的追踪：我们并没有因此满足，基础架构的同学参考谷歌的文献实现了内部的Drapper链接追踪系统。请求从CDN入口开始就会携带TrackID，甚至不忘在SQL的查询语句里把TrackID带上。以至于追踪得很细致，哪里什么原因耗时最长一目了然。图示：七、突破壁垒：Misaka做完如上监控，发现仍然有用户

6、反馈问题时我们束手无策。因为我们没有收到任何与此用户相关的错误信息可能网路过程出现了未知原因，比如“被加速”、“功能问题”、“异常退出”等等。于是我们的舆情监测系统Misaka上线，和CDN错误日志思路相同；不同的是客户端是真客户端，突破了服务端的壁垒。由于Misaka上线的受众群体更广，我们简单包装了一下界面（虽然我觉得ELK更漂亮）、添加了历史数据的比较。更利于分析，下图示例：八、报警整合随着人员的加入和系统的逐步完善，定制化的监控和系统也越来越多。比如，支持多种集群模式的Redis集群监控：还有队列的监控，以及把Kafka队列包装成支持Redis协议的Databus中间件的监控。下图示例

7、：随即Docker的监控也来了，下图示例：那么问题又来了，这么多监控，眼不花吗？会不会查问题的时候得开N个窗口，拼经验看谁定位问题更快痛定思痛，我们走访了几家互联网公司。然后默默的做了一次整合，将报警和事件以时间轴的方式展现了出来。用过都说好，下图示例：九、在路上：Prometheus经历约一年时间的洗礼，我们又回到了监控系统的选型。为什么？因为越来越多的花样监控需求，已经无法很快得到满足、而且维护工作日渐繁琐。嗯，可能不同阶段需要不同的解决方案。那为什么是Prometheus？因为可选的开源产品并不多，新潮前卫的现代化监控就OpenFlaon和Prometheus啦。Prometheus不止是监控工具，它是一套完整的监控解决方案。除了前端，其它都好。很快Prometheus就上线了，逐步取代了Zabbix。前端仍然是熟悉的Gr