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

标签: 找到 系统 问题 | 发表时间:2015-10-27 15:52 | 作者:coolsunchen
出处:http://www.iteye.com
面向业务的立体化高可用架构设计
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高可用等措施。

已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [找到 系统 问题] 推荐:

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

- - 行业应用 - ITeye博客
面向业务的立体化高可用架构设计. 立体化&自动化&可视化的监控. 处理过线上问题的朋友可能都有这样的经历:客户投诉现在业务有问题,于是研发测试运维开始投入定位和分析问题,一场忙碌但又混乱的活动开始了. A研发去查日志,但是线上机器好多,一台一台的看,1小时过去了;如果想把日志下载下来,一下几个G的文件,网速又慢,只能干等…….

思考系统API设计的问题

- edware_love - C++博客-首页原创精华区
最近正好在思考系统API设计中考量的一些问题,. 我现在的理解是这样的,假设有巨大的真实内存. windows首先将高2G的内存自己占了,用作各种内核对象. 这2G内存共享给每个进程,但进程不能直接访问,只能通过windows给定的函数访问. : 然后每个进程都给他2G内存,进程如果创建自己的对象就放到自己那2G内存里面,如果要建立内核对象就放到共享的那高2G里面去.

搜索系统中的纠错问题

- -
纠错是搜索引擎中一个非常有特色的模块,对用户输入的内容进行改写从而让用户得到正确的结果,有的时候也会带有一些惊喜度,所以纠错技术是一个搜索体验的加分项,近期突然对这块有兴趣,所以就了解了一下. (学习周报本周停,学习内容都在这了). 人非圣贤,孰能无过,别说是搜索的时候,哪怕是我们打字、写作文的时候,都会出现错字,一般的错别字不会对最终目标带来很大影响,且出现频率很低,不拘小节的我们常常会忽略这样的小问题,但是,在搜索场景下,错别字意味着可能就搜不到内容了,对于用户而言,就是需求无法满足,造成了很差的体验,因此在搜索场景中,就很有必要去纠错.

导致Linux Kernel电源问题原因可能找到

- Hitsmaxft - Solidot
自Linux 2.6.38 kernel开始,移动Linux用户发现电力消耗迅速飚升,电池续航时间迅速减少,这迫使部分用户放弃使用Linux发行版如Ubuntu 11.04,电源退化(regression)问题受到了许多人的关注,在Launchpad上有数百人报告这一bug. phoronix.com执行了一次自动耗电量测试,寻找出问题的根源.

开发者寄望Android 4.0缓解系统分化问题

- 中雨 - cnBeta.COM
美国IT网站PCWorld今天撰文称,开发者希望最新的“冰淇淋三明治”系统能够从一定程度上缓解Android目前的平台分化问题,并修复一些漏洞.

tag推荐系统的关键问题以及解决方案

- - CSDN博客推荐文章
最近在做推荐产品,读了一些论文,客观的说,扯淡的居多,基本的思路也差不多,结合工作的情况,谈一下tag推荐的产品形态、主要问题以及如何推荐. tag 的推荐系统,顾名思义,利用用户或者item的 tag信息进行推荐,涉及到两个产品形态:. 1.tag-based recommend,基于tag信息推荐item给用户.

从问题域出发认识Hadoop生态系统

- - 董的博客
Dong | 新浪微博: 西成懂 | 可以转载, 但必须以超链接形式标明文章原始出处和作者信息及 版权声明. 网址: http://dongxicheng.org/mapreduce-nextgen/rethinking-hadoop-from-problems-solved/. 本博客的文章集合: http://dongxicheng.org/recommend/.

分布式系统中的事务一致性问题

- - CSDN博客架构设计推荐文章
在分布式系统中,我们经常遇到多数据副本保持一致的问题,在我们所能找到的资料中该问题讲的很笼统,模模糊糊的,把多个问题或分类糅合在一起,难以理解. 在思考和翻阅资料后,通俗地把一致性的问题可分解为2个问题:. 1、任何一次修改保证数据一致性. 在弱一致性的算法,不要求每次修改的内容在修改后多副本的内容是一致的,对问题1的解决比较宽松,更多解决问题2,该类算法追求每次修改的高度并发性,减少多副本之间修改的关联性,以获得更好的并发性能.

关于分布式系统的数据一致性问题

- - 互联网 - ITeye博客
现在先抛出问题,假设有一个主数据中心在北京M,然后有成都A,上海B两个地方数据中心,现在的问题是,假设成都上海各自的数据中心有记录变更,需要先同步到主数据中心,主数据中心更新完成之后,在把最新的数据分发到上海,成都的地方数据中心A,地方数据中心更新数据,保持和主数据中心一致性(数据库结构完全一致).

留心那些潜在的系统设计问题

- - ITeye博客
在系统设计阶段考虑全面很难,有许多人倾向于把整个设计分成若干阶段,在迭代中完成整个设计,这本身是非常好的,但是,就如同“先做出来,以后再优化”这样的经典谎言一样,本身并无错,只是许多程序员都不习惯于真正的迭代设计和迭代优化. 举例来说,有一个日益复杂的类,每个人都修改一点点,一直到最后都没有人愿意去做重构,大家的心态都是一样的:“我只修改了一点点,为什么要我去动那么大的刀,于我没有任何好处”.