自动立体化运维监控理念

         场景

客户投诉有问题，于是研发测试运维开始投入定位和分析问题。

A 研发去查日志，但是线上机器好多，一台一台的看， 日志文件太大，网速又慢，只能干等......

B 研发同学觉得数据库可能有问题，但是自己又不能直接操作数据库，只能找DBA，但是DBA正好不在......

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

 

解决方案

这种情况就需要一套“立体化、自动化、可视化的监控”，具体实现如下:
1、立体化
将故障分析和定位时涉及的所有的相关信息都要监控起来，共分为5层

（1）业务层

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

（2）应用服务层

以URI为维度的分析，可以看到某个URI的访问量、HTTP响应码分布、HTTP响应时间等指标

应用服务层与业务层并不是一一对应的关系，一个业务可能对应多个应用服务层的URI，一个URI也可能对应多个业务层的业务

（3）接口调用层

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

（4）基础组件层

基础组件层指系统依赖的底层组件，例如容器、数据库、缓存、消息队列

不同的组件收集的信息不一样，例如数据库MySQL的监控指标包括连接数、请求数、查询行数、更新行数等，而缓存包括 使用率、踢出率、命中率等

（5）基础设施层

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

2、自动化

不要再由人工去分析日志或者执行命令了，而是由程序自动完成这些动作

当故障定位的时候需要这些信息时，可以立即看到，节省故障定位时间

为此我们开发了一套数据收集和分析系统，这套系统可以从其它各个系统(包括业务系统、运维系统等)获取并分析数据，例如日志数据、状态数据等

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

Logstash用于采集日志，redis用于缓存日志，elasticsearch用于存储和分析日志

3、可视化

故障定位所需要的信息能够通过图表和数字直观的展示出来

有了自动化的收集和分析作为基础，可视化只需要将数据做成图表展示即可

除此以外，同比、环比这类数据也可以通过系统直观的展示出来，方便快速判断问题所在

 

内容整理自"面向业务的立体化高可用架构设计"
作者李运华 阿里资深工程师