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

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

一. 背景介紹

許多公司的平臺每天會產生大量的日志（一般為流式數據，如，搜索引擎的pv，查詢等），處理這些日志需要特定的日志系統，一般而言，這些系統需要具有以下特征：
（1）構建應用系統和分析系統的橋梁，并將它們之間的關聯解耦；
（2）支持近實時的在線分析系統和類似于Hadoop之類的離線分析系統；
（3）具有高可擴展性。即：當數據量增加時，可以通過增加節點進行水平擴展。

二．日志系統比較

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

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

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

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

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

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

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

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

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

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

此外，使用autoE2EChain，當某個collector 出現故障時，Flume會自動探測一個可用collector，并將數據定向到這個新的可用collector上。
(3) storage
storage是存儲系統，可以是一個普通file，也可以是HDFS，HIVE，HBase等。

E. 總結
根據這四個系統的架構設計，可以總結出典型的日志系統需具備三個基本組件，分別為agent（封裝數據源，將數據源中的數據發送給collector），collector（接收多個agent的數據，并進行匯總后導入后端的store中），store（中央存儲系統，應該具有可擴展性和可靠性，應該支持當前非常流行的HDFS）。
下面表格對比了這四個系統：

三．較為成熟的日志監控分析工具

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

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

這三個工具（框架）各司其職，最終形成一整套的監控架構。

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

業務數據分析

通過客戶端的數據采集系統，可以將一些業務流程的關鍵步驟、信息采集到后端，進行業務流程的分析。

錯誤日志分析

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

數據預警

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

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