3分钟找到系统问题：立体化&自动化&可视化的监控

面向业务的立体化高可用架构设计
http://www.csdn.net/article/2015-10-27/2826042


立体化&自动化&可视化的监控

处理过线上问题的朋友可能都有这样的经历：客户投诉现在业务有问题，于是研发测试运维开始投入定位和分析问题，一场忙碌但又混乱的活动开始了。

A研发去查日志，但是线上机器好多，一台一台的看，1小时过去了；如果想把日志下载下来，一下几个G的文件，网速又慢，只能干等……

B研发同学觉得数据库可能有问题，但是自己又不能直接操作数据库，只能找DBA，但是DBA不在线啊，赶紧打电话，DBA说我正好休假呢……

C运维同学更头大，一边要应付研发和测试的各种问题，一边还要自己查机器CPU、内存、io、网络、程序状态，而且还那么多机器。

这样的做法肯定达不到“3分钟定位问题”的要求，怎么办呢？我们的运维大神给出了“立体化、自动化、可视化监控”的方向：在故障发生的时候，定位问题的所需要的各种信息都已经准备好了，不需要再到各种各样的系统中去执行各种各样的命令了；而且这些信息都必须是可视化的，能够一目了然的看出问题所在。具体实现如下：


1. 立体化

立体化就是将故障分析和定位时涉及的所有的相关信息都要监控起来，共分为5层，具体各层和含义如下：

业务层
收集和分析业务层的访问量、成功率等指标。例如当系统被刷的时候，业务层能够一目了然的看出访问量会增加很多

应用服务层
应用服务层指的是以URI为维度的分析，可以看到某个URI的访问量、HTTP响应码分布、HTTP响应时间等指标。应用服务层与业务层并不是一 一对应的关系，一个业务可能对应多个应用服务层的URI，一个URI也可能对应多个业务层的业务。

接口调用层
接口调用层指的是系统依赖的外部系统接口，收集的信息包括访问情况，包括时延、错误码、次数等，当外部系统故障导致我们的业务故障时，通过接口调用层就能够快速的定位具体问题。

基础组件层
基础组件层指系统依赖的底层组件，例如容器、数据库、缓存、消息队列。不同的组件收集的信息不一样，例如数据库MySQL的监控指标包括连接数、请求数、查询行数、更新行数等，而缓存memcached包括使用率、踢出率、命中率等。

基础设施层
基础设施层指操作系统状态、网络状态，收集的信息包括cpu使用率、内存使用率、网卡流量、连接数等。
2. 自动化

自动化的含义就是不要再由人工去分析日志或者执行命令了，而是由程序自动完成这些动作。当故障定位的时候需要这些信息时，可以立即看到，节省故障定位时间。为此我们开发了一套数据收集和分析系统，这套系统可以从其它各个系统（包括业务系统、运维系统等）获取并分析数据，例如日志数据、状态数据等。

数据自动化收集和分析系统的结构如下：



其中Logstash用于采集日志，redis用于缓存日志，elasticsearch用于存储和分析日志。
3. 可视化

可视化的含义就是故障定位所需要的信息能够通过图表和数字直观的展示出来。有了自动化的收集和分析作为基础，可视化只需要将数据做成图表展示即可。除此以外，同比、环比这类数据也可以通过系统直观的展示出来，方便快速判断问题所在。


七、总结

我们来回顾一下整个这套架构方案是如何实现我们最初的目标的：

3分钟定位问题
通过运维已有的拨测脚本，加上立体化&自动化&可视化的监控，绝大部分故障能够在3分钟内发现并定位初步的原因。例如是因为访问量暴涨，还是数据库变慢了，还是网络被SYN FLOOD攻击了。

5分钟恢复业务
如果是某台机器或者某几台机器故障，我们可以将故障机器下线；

某个接口或者某些业务故障，如果不是核心业务，我们可以采用功能降级快速处理；

如果是大面积的业务故障，甚至是核心功能也故障了，我们可以通过将故障机房的业务切换到其它机房；

如果是所有的机房核心业务都出故障了，那就只能具体问题具体处理了，例如如果是新版本引起的，首先立刻回滚版本；如果是被攻击了，需要采用防攻击手段等。

平均最多2个月发生一次故障
通过核心功能和非核心功能分离，能够尽最大可能的保护核心功能的可靠性。当然除了这个措施外，我们还有其它更多常规的保证措施，例如项目流程上的部署评审，自动化测试，灰度发布，tcpcopy环境预发布、MySQL高可用、Memcached高可用等措施。