用大数据思维做运维监控的一种体验（2）

千万不要针对具体问题进行解决，大数据架构上的一个思维就是：我能够提供一个平台让大家方便解决这些问题么? 而不是，这个问题我能解决么?先来看看架构图：

图2

因为目前我负责应用层的研发，业务还比较少，主要就需要监控三个系统：

• 推荐
• 搜索
• 统一查询引擎

所以监控的架构设计略简单些。如果你希望进行日志存储以及事后批量分析，则可以采用淘宝的这套架构方式：

图3

稍微说明下，日志收集Agent可以使用Flume,鹰眼Storm集群，其实就是Storm集群，当然有可能是淘宝内部Java版的，Storm(或图2的SparkStreaming)做两件事情。

将日志过滤，格式化，或存储起来。

进行实时计算，将指标数据存储到HBase里去。

到目前为止，我们没有做任何的开发，全部使用大数据里通用的一些组件。至于这些组件需要多少服务器，就看对应的日志量规模了，三五台到几百台都是可以的。

需要开发的地方只有两个点，有一个是一次性的，有一个则是长期。

先说说一次性的，其实就是大盘展示系统。这个就是从HBase里取出数据做展示。这个貌似也有开源的一套，ELK。不过底层不是用的HBase存储，而是ES。这里就不详细讨论。

长期的则是SparkStreaming(淘宝是使用Storm，我建议用SparkStreaming,因为SparkStreaming可以按时间窗口，也可以按量统一做计算)，这里你需要定义日志的处理逻辑，生成我上面提到的各项指标。

这里有一个什么好处呢，就是平台化了，对新的监控需求响应更快了，开发到上线可能只要几个小时的功夫。如果某个系统某天需要一个新的监控指标，我们只要开发个SparkStreaming程序，丢到平台里去，这事就算完了。

第一幅图的平台我是已经实现了的。我目前在SparkStreaming上只做了三个方面比较基础的监控，不过应该够用了。

状态码大盘。 HTTP响应码的URL(去掉query参数)排行榜。比如你打开页面就可以看到发生500错误的top100的URL，以及该URL所归属的系统。

响应耗时大盘。 URL请求耗时排行榜。比如你打开页面就可以看到5分钟内平均响应耗时top100的URL(去掉query参数)。

还有就是Trace系统。类似Google的Dapper,淘宝的EagleEye。给出一个唯一的UUID,可以追踪到特定一个Request的请求链路。每个依赖服务的响应情况，比如响应时间。对于一个由几个甚至几百个服务组成的大系统，意义非常大，可以方便的定位出到底是那个系统的哪个API的问题。这个最大的难点是需要统一底层的RPC/HTTP调用框架，进行埋点。因为我使用的是自研的ServiceFramework框架，通讯埋点就比较简单。如果是在一个业务线复杂，各个系统使用不同技术开发，想要做这块就要做好心理准备了。

现在，如果你想要监控一个系统是不是存活，你不在需要取写脚本去找他的pid看进程是不是存在，系统发现在一定的周期内没有日志，就可以认为它死了。而系统如果有异常，比如有大量的慢查询，大盘一定能展示出来。

描述到这，我们可以看到，这套架构的优势在哪：

基本上没有需要自己开发的系统。从日志收集，到日志存储，到结果存储等，统统都是现成的组件。

可扩展性好。每个组件都是集群模式的，没有单点故障。每个组件都是可水平扩展的，日志量大了，加机器就好。

开发更集中了。你只要关注日志实际的分析处理，提炼指标即可。

（待续）

（摘编自 公众微信号：36大数据 作者：祝威廉 / 编辑 严进军）