互联网系统运维实践.docx

互联网系统运维实践前言随着互联网的高速发展，企业经历的数据量越来越大、越来越重，运维也越来越重要。希望通过本文分享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?带上。以至于追踪得很细致，哪里什么原因耗时最长一目了然。图示：七、突破壁垒：Misaka做完如上监控，发现仍然有用户反馈问题时我们束手无策。因为我们没有收到任何与此用户相关的错误信息……可能网路过程出现了未知原因，比如“被加速”、“功能问题”、“异常退出”等等。??????????????????????????????????????于是我们的舆情监测系统?Misaka?上线，和CDN错误日志思路相同；不同的是客户端是真客户端，突破了服务端的壁垒。由于?Misaka?上线的受众群体更广，我们简单包装了一下界面（虽然我觉得?ELK?更漂亮）、添加了历史数据的比较。更利于分析，下图示例：八、报警整合随着人员的加入和系统的逐步完善，定制化的监控和系统也越来越多。比如，支持多种集群模式的?Redis?集群监控：还有队列的监控，以及把?Kafka?队列包装成支持?Redis?协议的?Databus?中间件的监控。下图示例：随即?Docker?的监控也来了，下图示例：那么问题又来了，这么多监控，眼不花吗？会不会查问题的时候得开N个窗口，拼经验看谁定位问题更快……痛定