日誌分析（一）框架選擇

• 概要

    日誌分析，有兩個主要模塊日誌收集以及分析統計。日誌收集主要實現日誌數據源的獲取。分析統計是對數據源的聚合和統計分析。

    日誌收集又分爲離線收集和熱數據收集：離線收集的日誌收集服務器與日誌分析系統徹底隔離，服務器日誌以文本的格式輸出到指定文件，而後經過logstash或者flume等文本收集系統進行傳輸，從而造成對應的日誌數據源。

    分析統計主要根據日誌的數據源新進聚合和處理，聚合的過程主要是分佈式日誌的數據聚攏，由於聚攏的策略通常是遵循fifo準則和fcfs算法，保證時間優先進行日誌聚合。由於目前日誌分析在必定程度上要求實時性，對日誌數據源的處理，又多了些預處理、流計算等模式進行數據的實時處理運算，以實現日誌數據最終存儲或者內存的格式即查詢或者圖形化展現須要的內容。

1. 熱門應用的介紹

        一、logstash

        elk 是logstash,elasticsearch,kibana 的縮寫，這個架構組合很是適合作日誌分析，其就是離線式日誌實時分析的表明，並且有目前已知的最強大的社區支持。logstash shipper利用file input讀取日誌文件，filter組件進行正則日誌篩選，而後經過 broker 進行聚合，日誌經過es out已有的組件輸出到 elasticsearch。kibana根據elasticsearch的索引進行實時查詢。成功案例參照 新浪 、芒果TV等，github上有4000+ stars，它好在有一套完整的日誌收集（logstash）、日誌存儲（elasticsearch）、日誌展現分析（kibana），搭建起來很是方便。

        詳細介紹：http://kibana.logstash.es/content/index.html

        

        logstash能夠多線程共享 SizedQueue、java協議寫ES等等優勢就不羅列了，其缺點大概有如下：logstash 的一系列問題，好比Input/syslog性能極差，Filter/geoip性能較差，Filter/grok費CPU，Output/elasticsearch的retry邏輯跟stud的SizedQueue重複等等。針對版本能夠作相應代碼優化以實現版本問題。

        ps www.elastic.co的一句 ：If a newbie has a bad time, it's a bug.

        二、flume

        flume是一個分佈式、可靠、和高可用的海量日誌聚合的系統，支持在系統中定製各種數據發送方，用於收集數據；同時，Flume提供對數據進行簡單處理，並寫到各類數據接受方（可定製）的能力。相似的有。

        官網：http://flume.apache.org/

        簡介：http://my.oschina.net/u/2284716/blog/542991

        三、kafka

        kafka數據處理管道。

        原文：http://kafka.apache.org/design.html

        翻譯的：http://www.oschina.net/translate/kafka-design?lang=chs&page=1

        四、druid

        druid 是實時試探性查詢的分析數據存儲工具，能夠理解成一種數據緩存化的聚合存儲，爲olap而生。

如下是針對druid和目前較多 數據存儲工具的對比：

如下 是druid 的架構模型：

        只說兩個缺點：硬件要求，以及 自己便是數據的聚合結果存儲須要對源數據進行額外存儲。

        原文 ：http://druid.io/docs/0.8.2/design/index.html

        五、es

        elasticsearch搜索引擎,基於lucene,分佈式，RESTful搜索引擎, 比solr在實時數據方面有優點。kibana 提供了數據前端展現。

        缺點:沒有事務概念，針對單個document最好採用單一實例操做。

        官網：http://www.elastic.co

olap的暫時瞭解了以上開源框架，elk、flume+管道（redis或kafka）+es+kibana 、flume / logstash /rsync+ kafka+Hadoop+druid 等組合。

but，however，以上全部的olap的日誌分析都要很大的主機(以上組合最少也要3個實例進程，或者須要大量內存空間)成本...我如今告訴你們一種省錢的架構組合，成本更低，效率有必定的優點。

jvm agent+kafka+es +kibana ~~

    官網：http://my.oschina.net/u/2284716/blog/544201