转载

手机微博运维监控系统实战

现在，各类技术大会层出不穷，技术人员有了更多学习前沿技术和设计思想的渠道。但是学习到的这些思路，是否真的适合公司的业务?要解决业务架构的更种缺点，是否一定要推翻重做?作为技术保障人员，怎样在不重建体系的前提下，降低系统的故障率，让它运行得更好?

作者：于雪来源：51CTO.com | 2016-04-06 10:02

51CTO首届中国APP创新评选大赛正在招募>>

业务是满足公司资本发展向前走的生力军，它的脚步永远都不应该停下来。与直接参与架构的设计和研发人员相比，技术保障人员是一群默默无闻的幕后英雄。完美的架构是不存在的，这就需要技术保障人员不断查找并解决问题、规避架构风险、完善业务以及开发所需要的基础设施，为业务架构的稳定运行提供强大的支撑，为业务线的架构设计和开发人员做好后勤保障。

手机微博运维监控系统实战

王春生秒拍网架构师/前新浪系统架构师、研发技术保障部总监

在由51CTO高招主办的“CTO训练营”活动现场，前手机微博技术保障体系负责人、现秒拍网架构师就上述问题与现场同学进行了分享和探讨。这位有十余年系统设计和技术架构经验的老兵认为，大多数情况下，我们目前线上运行的架构，就是最适合公司业务线状的架构。面对现实存在的一些问题，我们完全没必要推翻现有的体系，而是找到一些方式和方案，能够实时的发现或者监控线上存在的问题;同时通过相应的技术指标，预判并规避可能出现的风险。

手机微博架构浅析

2014年，手机微博的业务翻倍增长，这促使手机微博的架构进行了一次重大改造。主要方式是将PHP的Scribe，包括自己定义的PHP模板引擎换成鸟哥写的Yaff；将很多PHP自身运算变成了PHP模块，等等。

手机微博运维监控系统实战

王春生首先对手机微博架构进行了简单分析。Microservice包括开放平台的核心池和非核心池两部分，来将不同的业务进行隔离。用户可以通过手机客户端直接访问CDN获取图片，以及直接访问“图床”Service 来上传图片；MAPI会请求Microsevice。

手机微博运维监控系统实战

王春生坦言，整个架构无论是从平台体系还是从业务体系来讲，与许多互联网应用的架构非常相似，无非就是接入层、业务层、数据层，当然可能有多个接入层、多个数据层和多个业务层。那么一个这样简单的结构，它的问题到底可能出现在哪儿呢?

手机微博运维监控系统实战

上图是王春生整理出来的手机微博遇到最多的问题，并将这些问题从业务及体验、架构及技术保障这三个层面进行了梳理。

手机微博运维监控系统实战

分析来看，这些架构所遇到的问题基本都差不多。主要所括容量上和容错上的一些问题；一些架构上的不合理；监控、报警不够及时，响应的速度和解决问题的速度不够快；技术债务和技术风险等。

要想把这些技术技术债务、技术风险，包括一些对架构产生影响的外部因素挖掘出来， 首先要解决的问题就是监控 。因为无法对问题进行度量，管理和优化也就无从谈起。

监控体系实战

技术选型：Zabbix

手机微博运维监控系统实战

手机微博监控选择的是Zabbix。王春生谈到，其实任何一款现在主流的开源监控产品，如Nagios、Zabbix、Ganglia、Bosun等等，几乎都可以满足对监控的需求。大家没有必要在监控系统的选型上费太多力气，而真正花费时间和精力的是在监控项的设计上，因为监控项的设计是监控工作中最重要的环节。

说到这里，王春生指出了许多公司运维工程师陷入的一个误区——尽管同时采用了多套不同的监控系统，甚至自己写了一部分shell脚本，但线上一些常见问题并没有得到及时的报警。于是不断有新的监控项堆积出来，然而，往往还是很难定位到问题的具体细节。

监控项设计：最小粒度原则

手机微博运维监控系统实战

因此，手机微博设计监控项是首先考虑的是采用最小粒度原则，任何一个涉及到单机的监控项都会定位到单机上。在成千上万台机器中，只要有一台机器出现问题，可以迅速定位出现问题的那台机器。这台机器在哪一个IDC，影响到的是什么样的用户人群，同样也能够快速知道。

但监控做的细经常遇到的一个问题就是收到到的报警太多。某一个区域，或者说某一个功能特征的系统出现问题时，经常一下子收到几十条、几百条的报警短信。因此在汇总时会考虑一些收敛功能的设计。

另外在设计监控项时，还要考虑到它覆盖的广度和深度，因此手机微博的监控系统做了一个简单的分层：操作系统层、Server层(服务软件层)、业务层。

所有操作系统的日志、业务的日志全部都到Rsyslog里面去，会通过Rsyslog做转发，比如转发到HDFS、Elasticsearch里面去,这基本是目前互联网公司通用的做法。值得一提的是，手机微博的监控整体上都是用的Rsyslog，基于日志进行实时计算。

ELK/ERK:定位复杂问题

监控系统虽然能帮助我们快速发现问题，但只有监控的话，还是没有办法更深入的挖掘到底出在哪儿。通过监控，我们只能得到的是一些计算出来的数值，所以它得到的结果是很概要的。当故障发生时，尤其是在一个复杂行为里，我们很难快速定位问题真正发生的位置。另外，监控项之间的关联关系也是需要提前挖掘的。比如要将Feed接口所依赖的十几个微服务的接口的定义出来，就需要花费很多的时间和精力。而且一旦业务发生变化，监控体系也要随之调整，这是比较麻烦的。

因此，微博采用了ELK和ERK体系，并进行了一些优化，比如用Rsyslog替换Logstash。记录下来的大量日志需要进行一定的格式化分析，让开发工程师和架构师更好的对系统进行优化。通过ELK体系，可以做出这样的饼图出来，直观定位监控系统报警的那些问题，查找出来到底是哪一行代码性能最差，影响了全局。

手机微博运维监控系统实战

整体来看，手机微博技术保障体系的监控系统的功能，主要是快速发现并尽可能快地定位问题。通过ELK和ERK套件，更加精准的定位问题，以及发现一些更为复杂的问题。ELK和ERK套件的优势就是日志是实时的，现场感很强，并且它支持的日是志类型非常丰富。几乎在问题发生同时，我们就可以知道线上系统是哪一个环节都现问题，出现了什么问题。另外，它还提供了很多关联分析。

但它的劣势就是日志的存储是需要一定成本的，另外效率并不高，历史的回溯能力也不强。

手机微博运维监控系统实战

保障业务前进的后勤部队

手机微博运维监控系统实战

当然，技术保障体系不止于监控。总的来说，技术保障就是要给业务架构师和开发工程师这些在前面冲锋的战士，提供相应的支持和更好的素材，来保证整体业务快速向前。我们的业务要往前冲，除了开发工程师，除了架构师，设计方案、写代码之后的所有事情，都需要有一个专门的技术保障团队为大家提供服务和支撑。技术保障一方面对业务线提供支持，帮助架构设计和代码实现快速部署，使产品尽快面世。另外还可以通过一些基础的监控数据分析，和一些基础设施的开发，偿还一些技术债务。