本文根据高效运维系列群「运维讲坛」的嘉宾分享整理而成。运维讲坛，邀请国内运维领域优秀技术专家作为分享嘉宾，其中线上版固定在每周三晚上举行，采取PPT截图+文字的方式交流，并预留长时间的现场交流互动。另外我们还每月组织「运维讲坛」线下交流活动。关于如何加入本系列群或更多了解运维讲坛活动，请参见文末。
编辑徐文慧21v-北京（内容收集）温国兵-广州（文章整理发布）嘉宾介绍饶琛琳，新浪网技术保障部系统架构师。Perl程序员。《网站运维技术与实践》作者。曾任职云快线，人人网等，专注在CDN、自动化运维领域。最近一年致力于日志处理和监控方面的技术研究和推广。
主题简介处理日志是运维工作必不可少的一环。但是在规模化场景下，grep、awk无法快速发挥作用，Hadoop又更偏向于固定模式的离线统计。我们需要一种高效、灵活的日志分析方式，可以给故障处理，根源定位提供秒级的响应。基于全文搜索引擎Lucene构建的ELKstack平台，是目前开源界最接近该目标的实现。
这次分享首先对ELK三个组件做一下简介，然后示例几种常见日志的场景。然后会分享一下新浪在使用过程中踩过的坑，总结的经验教训。最后大家可以一起发散讨论，在机器数据处理方面，ES、Hive、Spark各自的定位和用途。
ELK使用场景介绍本文介绍ELK套件在日志方面的应用。首先介绍ELK使用场景。
日志其实是运维工程师打交道很多很多的一个东西了。一般来说，日志有三个用途：
找问题，就好像开发讲数据驱动一样，运维也要数据驱动安全审计做监控监控方面，我个人很欣赏Etsy公司传出来的一句话，感觉能算是监控的一种新时代的定义：
Monitoringistheaggregationofhealthandperformancedata,events,andrelationshipsdeliveredviaaninterfacethatprovidesanholisticviewofasystem’sstatetobetterunderstandandaddressfailurescenarios.
所以说，日志数据并不是存下来，能看就OK了的。要能达到促进运维生产力的程度，需要很多后续处理，转变成这个Interface。
说回到日志的应用，第一个，找问题。日志本身，其实就是时间戳+内容。好比一般说各种Metric系统，Graphite等等，就是时间戳+数值。但是找问题的时候，说要「昨晚23:12到23:29那会儿日志有啥异常？」，这种提问，感觉就会很抓瞎了。
一般的监控体系，是定点采样；离线分析，是有固定的规则。而找问题的时候，恰恰是只有一个范畴，等着你找规则，找故障点。所以这是日志分析在运维领域跟其他“相近”的系统差别很大的一点。
这个寻找的过程在分析的时候一般叫做“下钻”。单机的时候，我们通过grep、awk、sort、uniq，一个接一个管道的做日志处理。但是在集群环境下，没法继续这样玩的。几年前一本《大规模Web服务开发技术》，说台是大规模，现在来个稍微有点规模的都上百啦。所以，我们需要一个细粒度的，实时的数据搜索系统。而且这系统基本就是给运维，客服，开发看几眼就能定位问题的。
这个领域其实早就有牛逼公司了，Splunk，上市到现在都已经百亿美元市值了。不过Splunk好贵。ELK就是在这种场景下，用来替代Splunk的开源产品。
应用举例前面这段算是场景方面的介绍。以及一点点我对监控、排障上的理解。下面举例说具体一点的日志。一段应用日志：
这种日志，作为运维大家肯定都很熟悉吧。密密麻麻，要是tail一下，终端能给你卡死。对应Logstash的配置：
这种配置区块的风格我觉得运维工程师应该普遍还是满适应的，因为Ruby写的DSL基本都长这个样子，比如Puppet。
在Kibana3的时候，制作的Dashboard效果：
以及Kibana4的效果：
Kibana4是刚重构的，性能比Kibana3好，但是配色方面目前不是很完美。
一个满屏刷的日志，通过Logstash大概十几行的配置处理，然后就可以在Kibana上做到各种维度的分析。
上面是第一个例子。示例中是ELK最基础的两种面板格式，一个是histogram，也就是时间趋势图，一个是terms，也就是TopN排序。
做时间趋势，有很多选择，那么为什么不直接计算metric，而是走ELK来处理日志呢？比如你一个网站，有0个接口，常见的状态码有6、7个，客户端平台版本也有6、7个，这就要定义多少万个Item才够？一旦有调整，又要变更。而在ELK里，它每次刷新Kibana都是实时计算，你可以任意变更Query。上面截图里，大家可以看到有8个小Query框。其实每个都是写了不同的Query语句，得到不同结果的。只要需要，还可以随时添加修改。这就是灵活性。
下一个例子，PHP的slowlog。
经过Logstash处理后，我给Kibana里定义的Dashboard是这样：
注意：大家可以点开大图看那段黑色框的文字。
这里的千层饼图，每层是对slowlog的函数堆栈的同一层的TopN统计。这样一个千层饼，就不单单能反映说最底层的慢函数在哪，还能一目了然看到说一路调用过来引发慢的整个链条路径。
前一张图里，假如我们看到说Top10里某个host的count比其他的多，或者明显跟别人不一样。比如截图中，Top10host9个是yhg机房的，唯独第一个是xd机房，这显然不对。那么鼠标点击一下这条记录，页面就变成这个样子：
这个host的过滤条件自动就加到Query下面生效了，而且整个页面的分析图表都自动变成有这个host过滤以后的结果。看图里这个堆栈情况的千层饼，跟开始各机房的汇总情况明显不一样。点开大图看细节，就可以知道，这台机器在尝试连接Memcache的时候，gethostbyname()过慢的量暴涨。那好，问题定位直接就完成了。
这是一个单维度的明显变化的示例。还有一个多维度的，下图是Nginx的errorlog：
不同的时间段，在不同维度上结果差距很明显。这几个都是服务器上的日志。当然ELK只要是日志，都能处理能搜索聚合。我们App会上传很多日志到后台。比如Crash的时候，那么开发同学想知道，尤其是新发版的时候，想知道最需要修复的代码在哪。
这个是在Logstash阶段，通过自定义插件，把Crash堆栈中系统函数过滤掉，剩下专门是自己公司的代码了。然后TopN排序，很容易了解。页面做法其实跟一开始的例子一样的，如下图：
新发版的时候，添加一个具体版本号的过滤条件。这个TopN就不一样了，如下图：
当然这个Crashlog只是我们这样玩。相信不同公司发版肯定都会