問題導(dǎo)讀：
1、怎樣收集系統(tǒng)日志并進(jìn)行分析？
2、常見的開源日志系統(tǒng)有哪些？
3、如何選擇常用成熟的日志監(jiān)控分析工具？
4、Logstash 與FluentD(Fluentd)有哪些不同？

一. 背景介紹
二．日志系統(tǒng)比較
1．怎樣收集系統(tǒng)日志并進(jìn)行分析
A.實(shí)時模式：
B.準(zhǔn)實(shí)時模式
2.常見的開源日志系統(tǒng)的比較
A. FaceBook的Scribe
B. Apache的Chukwa
C. LinkedIn的Kafka
E. 總結(jié)
三．較為成熟的日志監(jiān)控分析工具
1.ELK
A.ELK 簡介
B.ELK使用場景
C.ELK的優(yōu)勢
D.ELK的缺點(diǎn)：
2.EFK
3. Logstash 與FluentD(Fluentd)對比

一. 背景介紹

許多公司的平臺每天會產(chǎn)生大量的日志（一般為流式數(shù)據(jù)，如，搜索引擎的pv，查詢等），處理這些日志需要特定的日志系統(tǒng)，一般而言，這些系統(tǒng)需要具有以下特征：
（1）構(gòu)建應(yīng)用系統(tǒng)和分析系統(tǒng)的橋梁，并將它們之間的關(guān)聯(lián)解耦；
（2）支持近實(shí)時的在線分析系統(tǒng)和類似于Hadoop之類的離線分析系統(tǒng)；
（3）具有高可擴(kuò)展性。即：當(dāng)數(shù)據(jù)量增加時，可以通過增加節(jié)點(diǎn)進(jìn)行水平擴(kuò)展。

二．日志系統(tǒng)比較

1．怎樣收集系統(tǒng)日志并進(jìn)行分析
A.實(shí)時模式：
1 在打印日志的服務(wù)器上部署agent
2 agent使用低耗方式將日志增量上傳到計算集群
3 計算集群解析日志并計算出結(jié)果，盡量分布式、負(fù)載均衡，有必要的話（比如需要關(guān)聯(lián)匯聚）則采用多層架構(gòu)
4 計算結(jié)果寫入最適合的存儲（比如按時間周期分析的結(jié)果比較適合寫入Time Series模式的存儲）
5 搭建一套針對存儲結(jié)構(gòu)的查詢系統(tǒng)、報表系統(tǒng)
補(bǔ)充：常用的計算技術(shù)是storm
B.準(zhǔn)實(shí)時模式
1 在打印日志的服務(wù)器上部署agent
2 agent使用低耗方式將日志增量上傳到緩沖集群
3 緩沖集群將原始日志文件寫入hdfs類型的存儲
4 用hadoop任務(wù)驅(qū)動的解析日志和計算
5 計算結(jié)果寫入hbase
6 用hadoop系列衍生的建模和查詢工具來產(chǎn)出報表
補(bǔ)充：可以用hive來幫助簡化

2.常見的開源日志系統(tǒng)的比較
A. FaceBook的Scribe
Scribe是facebook開源的日志收集系統(tǒng)，在facebook內(nèi)部已經(jīng)得到大量的應(yīng)用。它能夠從各種日志源上收集日志，存儲到一個中央存儲系統(tǒng) （可以是NFS，分布式文件系統(tǒng)等）上，以便于進(jìn)行集中統(tǒng)計分析處理。它為日志的“分布式收集，統(tǒng)一處理”提供了一個可擴(kuò)展的，高容錯的方案。
特點(diǎn):容錯性好。當(dāng)后端的存儲系統(tǒng)crash時，scribe會將數(shù)據(jù)寫到本地磁盤上，當(dāng)存儲系統(tǒng)恢復(fù)正常后，scribe將日志重新加載到存儲系統(tǒng)中。

架構(gòu)：
scribe的架構(gòu)比較簡單，主要包括三部分，分別為scribe agent， scribe和存儲系統(tǒng)。
(1) scribe agent
scribe agent實(shí)際上是一個thrift client。向scribe發(fā)送數(shù)據(jù)的唯一方法是使用thrift client， scribe內(nèi)部定義了一個thrift接口，用戶使用該接口將數(shù)據(jù)發(fā)送給server。
(2) scribe
scribe接收到thrift client發(fā)送過來的數(shù)據(jù)，根據(jù)配置文件，將不同topic的數(shù)據(jù)發(fā)送給不同的對象。scribe提供了各種各樣的store，如 file， HDFS等，scribe可將數(shù)據(jù)加載到這些store中。
(3) 存儲系統(tǒng)
存儲系統(tǒng)實(shí)際上就是scribe中的store，當(dāng)前scribe支持非常多的store，包括file（文件），buffer（雙層存儲，一個主儲存，一個副存儲），network（另一個scribe服務(wù)器），bucket（包含多個 store，通過hash的將數(shù)據(jù)存到不同store中），null(忽略數(shù)據(jù))，thriftfile（寫到一個Thrift TFileTransport文件中）和multi（把數(shù)據(jù)同時存放到不同store中）。

B. Apache的Chukwa
chukwa是一個非常新的開源項目，由于其屬于hadoop系列產(chǎn)品，因而使用了很多hadoop的組件（用HDFS存儲，用mapreduce處理數(shù)據(jù)），它提供了很多模塊以支持hadoop集群日志分析。
需求：
(1) 靈活的，動態(tài)可控的數(shù)據(jù)源
(2) 高性能，高可擴(kuò)展的存儲系統(tǒng)
(3) 合適的框架，用于對收集到的大規(guī)模數(shù)據(jù)進(jìn)行分析

架構(gòu)：
Chukwa中主要有3種角色，分別為：adaptor，agent，collector。
(1) Adaptor 數(shù)據(jù)源
可封裝其他數(shù)據(jù)源，如file，unix命令行工具等
目前可用的數(shù)據(jù)源有：hadoop logs，應(yīng)用程序度量數(shù)據(jù)，系統(tǒng)參數(shù)數(shù)據(jù)（如linux cpu使用流率）。
(2) HDFS 存儲系統(tǒng)
Chukwa采用了HDFS作為存儲系統(tǒng)。HDFS的設(shè)計初衷是支持大文件存儲和小并發(fā)高速寫的應(yīng)用場景，而日志系統(tǒng)的特點(diǎn)恰好相反，它需支持高并發(fā)低速率的寫和大量小文件的存儲。需要注意的是，直接寫到HDFS上的小文件是不可見的，直到關(guān)閉文件，另外，HDFS不支持文件重新打開。
(3) Collector和Agent
為了克服(2)中的問題，增加了agent和collector階段。
Agent的作用：給adaptor提供各種服務(wù)，包括：啟動和關(guān)閉adaptor，將數(shù)據(jù)通過HTTP傳遞給Collector；定期記錄adaptor狀態(tài)，以便crash后恢復(fù)。
Collector的作用：對多個數(shù)據(jù)源發(fā)過來的數(shù)據(jù)進(jìn)行合并，然后加載到HDFS中；隱藏HDFS實(shí)現(xiàn)的細(xì)節(jié)，如，HDFS版本更換后，只需修改collector即可。
(4) Demux和achieving
直接支持利用MapReduce處理數(shù)據(jù)。它內(nèi)置了兩個mapreduce作業(yè)，分別用于獲取data和將data轉(zhuǎn)化為結(jié)構(gòu)化的log。存儲到data store（可以是數(shù)據(jù)庫或者HDFS等）中。

C. LinkedIn的Kafka
Kafka是2010年12月份開源的項目，采用scala語言編寫，使用了多種效率優(yōu)化機(jī)制，整體架構(gòu)比較新穎（push/pull），更適合異構(gòu)集群。
設(shè)計目標(biāo)：
(1) 數(shù)據(jù)在磁盤上的存取代價為O(1)
(2) 高吞吐率，在普通的服務(wù)器上每秒也能處理幾十萬條消息
(3) 分布式架構(gòu)，能夠?qū)ο⒎謪^(qū)
(4) 支持將數(shù)據(jù)并行的加載到hadoop

架構(gòu)：
Kafka實(shí)際上是一個消息發(fā)布訂閱系統(tǒng)。producer向某個topic發(fā)布消息，而consumer訂閱某個topic的消息，進(jìn)而一旦有新的關(guān)于某個topic的消息，broker會傳遞給訂閱它的所有consumer。在kafka中，消息是按topic組織的，而每個topic又會分為多個partition，這樣便于管理數(shù)據(jù)和進(jìn)行負(fù)載均衡。同時，它也使用了zookeeper進(jìn)行負(fù)載均衡。
Kafka中主要有三種角色，分別為producer，broker和consumer。
(1) Producer
Producer的任務(wù)是向broker發(fā)送數(shù)據(jù)。Kafka提供了兩種producer接口，一種是low_level接口，使用該接口會向特定的broker的某個topic下的某個partition發(fā)送數(shù)據(jù)；另一種那個是high level接口，該接口支持同步/異步發(fā)送數(shù)據(jù)，基于zookeeper的broker自動識別和負(fù)載均衡（基于Partitioner）。
其中，基于zookeeper的broker自動識別值得一說。producer可以通過zookeeper獲取可用的broker列表，也可以在zookeeper中注冊listener，該listener在以下情況下會被喚醒：
a．添加一個broker
b．刪除一個broker
c．注冊新的topic
d．broker注冊已存在的topic
當(dāng)producer得知以上時間時，可根據(jù)需要采取一定的行動。
(2) Broker
Broker采取了多種策略提高數(shù)據(jù)處理效率，包括sendfile和zero copy等技術(shù)。
(3) Consumer
consumer的作用是將日志信息加載到中央存儲系統(tǒng)上。kafka提供了兩種consumer接口，一種是low level的，它維護(hù)到某一個broker的連接，并且這個連接是無狀態(tài)的，即，每次從broker上pull數(shù)據(jù)時，都要告訴broker數(shù)據(jù)的偏移量。另一種是high-level 接口，它隱藏了broker的細(xì)節(jié)，允許consumer從broker上push數(shù)據(jù)而不必關(guān)心網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)。更重要的是，對于大部分日志系統(tǒng)而言，consumer已經(jīng)獲取的數(shù)據(jù)信息都由broker保存，而在kafka中，由consumer自己維護(hù)所取數(shù)據(jù)信息。

D. Cloudera的Flume
Flume是cloudera于2009年7月開源的日志系統(tǒng)。它內(nèi)置的各種組件非常齊全，用戶幾乎不必進(jìn)行任何額外開發(fā)即可使用。
設(shè)計目標(biāo)：
(1) 可靠性
當(dāng)節(jié)點(diǎn)出現(xiàn)故障時，日志能夠被傳送到其他節(jié)點(diǎn)上而不會丟失。Flume提供了三種級別的可靠性保障，從強(qiáng)到弱依次分別為：end-to-end（收到數(shù)據(jù)agent首先將event寫到磁盤上，當(dāng)數(shù)據(jù)傳送成功后，再刪除；如果數(shù)據(jù)發(fā)送失敗，可以重新發(fā)送。），Store on failure（這也是scribe采用的策略，當(dāng)數(shù)據(jù)接收方crash時，將數(shù)據(jù)寫到本地，待恢復(fù)后，繼續(xù)發(fā)送），Best effort（數(shù)據(jù)發(fā)送到接收方后，不會進(jìn)行確認(rèn)）。
(2) 可擴(kuò)展性
Flume采用了三層架構(gòu)，分別問agent，collector和storage，每一層均可以水平擴(kuò)展。其中，所有agent和collector由master統(tǒng)一管理，這使得系統(tǒng)容易監(jiān)控和維護(hù)，且master允許有多個（使用ZooKeeper進(jìn)行管理和負(fù)載均衡），這就避免了單點(diǎn)故障問題。
(3) 可管理性
所有agent和colletor由master統(tǒng)一管理，這使得系統(tǒng)便于維護(hù)。用戶可以在master上查看各個數(shù)據(jù)源或者數(shù)據(jù)流執(zhí)行情況，且可以對各個數(shù)據(jù)源配置和動態(tài)加載。Flume提供了web 和shell script command兩種形式對數(shù)據(jù)流進(jìn)行管理。
(4) 功能可擴(kuò)展性
用戶可以根據(jù)需要添加自己的agent，colletor或者storage。此外，F(xiàn)lume自帶了很多組件，包括各種agent（file， syslog等），collector和storage（file，HDFS等）。

架構(gòu)：
正如前面提到的，F(xiàn)lume采用了分層架構(gòu)，由三層組成，分別為agent，collector和storage。其中，agent和collector均由兩部分組成：source和sink，source是數(shù)據(jù)來源，sink是數(shù)據(jù)去向。
(1) agent
agent的作用是將數(shù)據(jù)源的數(shù)據(jù)發(fā)送給collector，F(xiàn)lume自帶了很多直接可用的數(shù)據(jù)源（source）
(2) collector
collector的作用是將多個agent的數(shù)據(jù)匯總后，加載到storage中。它的source和sink與agent類似。
下面例子中，agent監(jiān)聽TCP的5140端口接收到的數(shù)據(jù)，并發(fā)送給collector，由collector將數(shù)據(jù)加載到HDFS上。

一個更復(fù)雜的例子如下：
有6個agent，3個collector，所有collector均將數(shù)據(jù)導(dǎo)入HDFS中。agent A，B將數(shù)據(jù)發(fā)送給collector A，agent C，D將數(shù)據(jù)發(fā)送給collectorB，agent C，D將數(shù)據(jù)發(fā)送給collectorB。同時，為每個agent添加end-to-end可靠性保障（Flume的三種可靠性保障分別由agentE2EChain, agentDFOChain, and agentBEChain實(shí)現(xiàn)），如，當(dāng)collector A出現(xiàn)故障時，agent A和agent B會將數(shù)據(jù)分別發(fā)給collector B和collector C。

此外，使用autoE2EChain，當(dāng)某個collector 出現(xiàn)故障時，F(xiàn)lume會自動探測一個可用collector，并將數(shù)據(jù)定向到這個新的可用collector上。
(3) storage
storage是存儲系統(tǒng)，可以是一個普通file，也可以是HDFS，HIVE，HBase等。

E. 總結(jié)
根據(jù)這四個系統(tǒng)的架構(gòu)設(shè)計，可以總結(jié)出典型的日志系統(tǒng)需具備三個基本組件，分別為agent（封裝數(shù)據(jù)源，將數(shù)據(jù)源中的數(shù)據(jù)發(fā)送給collector），collector（接收多個agent的數(shù)據(jù)，并進(jìn)行匯總后導(dǎo)入后端的store中），store（中央存儲系統(tǒng)，應(yīng)該具有可擴(kuò)展性和可靠性，應(yīng)該支持當(dāng)前非常流行的HDFS）。
下面表格對比了這四個系統(tǒng)：

三．較為成熟的日志監(jiān)控分析工具

1.ELK
A.ELK 簡介
ELK在服務(wù)器運(yùn)維界應(yīng)該是運(yùn)用的非常成熟了，很多成熟的大型項目都使用ELK來作為前端日志監(jiān)控、分析的工具。
前端日志與后端日志不同，具有很強(qiáng)的自定義特性，不像后端的接口日志、服務(wù)器日志格式比較固定，大部分成熟的后端框架都有非常完善的日志系統(tǒng)，借助一些分析框架，就可以實(shí)現(xiàn)日志的監(jiān)控與分析，這也是運(yùn)維工作的一部分。
ELK實(shí)際上是三個工具的集合：

E：Elasticsearch (彈性搜索)
L：Logstash
K：Kibana

這三個工具（框架）各司其職，最終形成一整套的監(jiān)控架構(gòu)。

Elasticsearch
ElasticSearch是一個基于Lucene的搜索服務(wù)器。它提供了一個分布式多用戶能力的全文搜索引擎，基于RESTful web接口。Elasticsearch是用JAVA開發(fā)的，并作為Apache許可條款下的開放源碼發(fā)布，是當(dāng)前流行的企業(yè)級搜索引擎。設(shè)計用于云計算中，能夠達(dá)到實(shí)時搜索，穩(wěn)定，可靠，快速，安裝使用方便。
我們使用Elasticsearch來完成日志的檢索、分析工作。
Logstash
Logstash是一個用于管理日志和事件的工具，可以用它去收集日志、轉(zhuǎn)換日志、解析日志并將它們作為數(shù)據(jù)提供給其它模塊調(diào)用，例如搜索、存儲等。
我們使用Logstash來完成日志的解析、存儲工作。
Kibana
Kibana是一個優(yōu)秀的前端日志展示框架，它可以非常詳細(xì)的將日志轉(zhuǎn)化為各種圖表，為用戶提供強(qiáng)大的數(shù)據(jù)可視化支持。
我們使用Kibana來進(jìn)行日志數(shù)據(jù)的展示工作。
B.ELK使用場景
現(xiàn)在已經(jīng)有非常多的公司在使用這套架構(gòu)了，例如Sina、餓了么、攜程，這些公司都是這方面的先驅(qū)。同時，這套東西雖然是后端的，但是『他山之石，可以攻玉』，我們將這套架構(gòu)借用到前端，可以使用前端日志的分析工作，同樣是非常方便的。這里我舉一些常用的使用場景。

業(yè)務(wù)數(shù)據(jù)分析

通過客戶端的數(shù)據(jù)采集系統(tǒng)，可以將一些業(yè)務(wù)流程的關(guān)鍵步驟、信息采集到后端，進(jìn)行業(yè)務(wù)流程的分析。

錯誤日志分析

類似Bugly，將錯誤日志上報后，可以在后端進(jìn)行錯誤匯總、分類展示，進(jìn)行錯誤日志的分析。

數(shù)據(jù)預(yù)警

利用ELK，可以很方便的對監(jiān)控字段建立起預(yù)警機(jī)制，在錯誤大規(guī)模爆發(fā)前進(jìn)行預(yù)警。
C.ELK的優(yōu)勢
a. 強(qiáng)大的搜索
這是elasticsearch的最強(qiáng)大的功能，它可以以分布式搜索的方式快速檢索，而且支持DSL的語法來進(jìn)行搜索，簡單的說，就是通過類似配置的語言，快速篩選數(shù)據(jù)。
b. 強(qiáng)大的展示
這是Kibana的最強(qiáng)大的功能，它可以展示非常詳細(xì)的圖表信息，而且可以定制展示內(nèi)容，將數(shù)據(jù)可視化發(fā)揮的淋漓盡致。
所以，借助ELK的這兩大優(yōu)勢，我們可以讓前端日志的分析與監(jiān)控展現(xiàn)出強(qiáng)大的優(yōu)勢。
D.ELK的缺點(diǎn)：
1、三個獨(dú)立的系統(tǒng)，沒有統(tǒng)一的部署、管理工具，用戶需要分別部署及管理這三套系統(tǒng)
2、復(fù)雜業(yè)務(wù)下權(quán)限的分組管理，企業(yè)肯定希望每個業(yè)務(wù)部分看自身的，但又存在矛盾點(diǎn)，企業(yè)想看匯總情況。
3、安全漏洞，之前烏云網(wǎng)站曾爆出Elasticsearch存在嚴(yán)重的安全漏洞。
4、不進(jìn)行深度開發(fā)的話，數(shù)據(jù)挖掘能力弱
2.EFK
市場上另外一個非常好的數(shù)據(jù)收集解決方案即是Fluentd，它也支持Elasticsearch作為數(shù)據(jù)收集的目的地。所以運(yùn)用相同的數(shù)據(jù)存儲和前端解決方案，便形成了EFK.許多人選擇用Fluentd 代替logtash。

3. Logstash 與FluentD(Fluentd)對比
二者都有許多可用插件，被積極的維護(hù)著。
技術(shù)上：
Lostash：有良好的并行性支持，jvm有很好的Grok支持
FlentD：缺少支持windows 平臺
傳輸上：兩者同時提供向一個非常必要的的選項，即向一個完全成熟的實(shí)例讀送日志信息的部署輕量級組件。
安裝