当然,这篇文章谈的是运维都有哪些数据,哪些指标,以及数据呈现。并没有谈及如何和大数据相关的架构做整合,从而能让这些数据真的变得活起来。

　　比较凑巧的是,原先百度的桑文峰的分享也讲到日志的多维度分析,吃完饭的时候,一位优酷的朋友也和我探讨了关于业务监控的的问题。而我之前发表在肉饼铺子里的一篇文章《大数据给公司带来了什么》也特地提到了大数据对于整个运维的帮助,当时因为这篇内容的主旨是罗列大数据的用处,自然没法细讲运维和大数据的整合这一块。

　　上面的文字算引子,在步入正式的探讨前,有一点我觉得值得强调:

　　虽然这里讲的是如何将大数据思维/架构应用于运维,平台化运维工作,但是和大数据本质上没有关系,我们只是将大数据处理的方式和思想应用在运维工作上。所以,即使你现在所在的公司没有数据团队支撑,也是完全可以通过现有团队完成这件事情的。

　　1、运维监控现状

　　很多公司的运维的监控具有如下特质:

　　只能监控基础运维层次,通过zabbit等工具提供服务器,CPU,内存等相关的监控。这部分重要,但确实不是运维的核心。

　　对业务的监控是最复杂的,而现在很多公司的要么还处于Shell脚本的刀耕火种阶段,要么开发能力较强,但是还是东一榔头西一棒子,不同的业务需要不同的监控系统,人人都可以根据的自己的想法开发一个监控的工具也好,系统也好,平台也好。总之是比较凌乱的。

　　使用第三方的监控平台。这个似乎在Rails/NodeJS/Pythone相关语系开发的产品中比较常见。我不做过多评价,使用后冷暖自知。

　　当然也有抽象得很好的,比如点评网的运维监控据说就做得相当好,运维很闲,天天没事就根据自己的监控找开发的茬,让开发持续改进。不过他们的指导思想主要有两个:

　　运维自动化。怎么能够实现这个目标就怎么搞,这严重依赖于搞的人的规划能力和经验。

　　抽象化,根据实际面临的问题做出抽象,得到对应的系统,比如需要发布,于是又发布系统,需要管理配置文件,所以有配管系统,需要日志分析所以有了有日志分析系统。然而这样是比较零散的。

　　有点扯远,我们还是focus在监控上。

　　如果以大数据的思维去思考,我们应该如何做好监控这件事情?

　　2、罗列出你的数据源

　　《大数据对于运维的意义》这篇文章也讲了,主要有工程数据,业务数据。所有的数据源都有一个共性,就是日志。无论文本的也好,二进制的也好。所以日志是整个信息的源头。日志包含的信息足以让我们追查到下面几件事情:

　　系统健康状况监控

　　查找故障根源

　　系统瓶颈诊断和调优

　　追踪安全相关问题

　　从日志我们可以挖掘出什么?

　　我觉得抽象起来就一个:指标。

　　指标可以再进行分类:

　　业务层面,如团购业务每秒访问数,团购券每秒验券数,每分钟支付、创建订单等

　　应用层面,每个应用的错误数,调用过程,访问的平均耗时,最大耗时,95线等

　　系统资源层面:如cpu、内存、swap、磁盘、load、主进程存活等

　　网络层面:如丢包、ping存活、流量、tcp连接数等

　　每个分类里的每个小点其实都是一个指标。

　　3、大数据思维

　　对于运维的监控,利用大数据思维,需要分三步走:

　　找到数据

　　分析定义从数据里中我能得到什么

　　从大数据平台中挑选你要的组件完成搭积木式开发

　　所有系统最可靠的就是日志输出,系统是不是正常,发生了什么情况,我们以前是出了问题去查日志,或者自己写个脚本定时去分析。现在这些事情都可以整合到一个已有的平台上,我们唯一要做的就是定义处理日志的的逻辑。

　　这里有几点注意的:

　　如果你拥有复杂的产品线,那么日志格式会是一个很痛苦的事情。以为这中间Storm(或者SparkStreaming)的处理环节你需要做大量的兼容适配。我个人的意见是,第一,没有其他更好的办理,去兼容适配吧,第二,推动大家统一日志格式。两件事情一起做。我一个月做不完,那我用两年时间行么?总有一天大家都会有统一的日志格式的。

　　如果你的研发能力有富余,或者有大数据团队支撑,那么可以将进入到SparkStreaming中的数据存储起来,然后通过SparkSQL等做即席查询。这样,有的时候原先没有考虑的指标,你可以直接基于日志做多维度分析。分析完了,你觉得好了,需要固化下来,那再去更新你的SparkStreaming程序。