當前，生產環境應用服務多是部署在多臺AP上，日誌一般通過log4j寫入到日誌文件並做定期歸檔和清理。日誌存儲於文件系統不利於查找問題，更不用說做一些統計分析。日常運維多是熟悉代碼的開發人員利用linux命令行通過特定的字符串模式去匹配查找日誌。對於大數據分佈式應用，日誌的統一收集、檢索、分析的需求更加迫切。下面針對日誌統一收集和分析的方案做一些討論。
一、日誌收集與分析的主要流程
日誌一般通過兩種方式進行收集，一是通過日誌文件，一是通過消息中間件在服務過程中將日誌以消息的方式發送到消息中間件。日誌收集與分析的主要流程如下圖所示：
依據流程中的主要功能差異將日誌收集分析劃分為是個主要的部分：
· 採集端：包括離線採集和聯機在線消息發送。
· 數據管道：多以Kafka為數據管道。其實如Flume，Logstash等框架本身也有管道的概念。
· 日誌處理：主要包括解析、抽取、過濾、轉換等過程。將不太結構化的日誌記錄轉化為結構化的易於存儲和檢索的日誌信息。
· 存儲與檢索：日誌收集後需要落地存儲並提供檢索與分析功能。目前長見的存儲和檢索框架如Hbase、Solr、Elasticsearch等。後面我會分析不同框架的優缺點。
二、基於Flume+Kafka+Sparkstream+Hbase+Solr的日誌收集與分析
如圖所示採集端使用的是Flume、數據管道採用Kafka、數據加工處理使用的是SparkStream、存儲和檢索端使用的是Hbase、Hdfs、Solr。各個組件在許多推薦項目中都有應用。首先分析一下各個組件的作用：
· Flume：官網的定義如為“Apache Flume is a distributed, reliable, and available system for efficiently collecting, aggregating and moving large amounts of log data from many different sources to a centralized data store.”Flume是一款分佈式的、高可用、考可靠的日誌收集系統，具有十多種Source和十多種Sink配置。這裡的Source和Sink就是Flume接入的數據源和輸出目標。本文只是對日誌收集方案的探討，Flume深入的知識點，比如Flume Interceptors、各類Channel的配置，多重路由（Multiplexer）與Replicating的區別等等可以後續在留言區討論。
· Kafka：數據管道，Flume採集完數據後將日誌信息發送到Kafka對應的Topic，在該方案中Kafka實際上為Flume的Sink端。
· Sparkstream：日誌處理端。訂閱Kafka中對應Topic的消息，進行加工處理。
· Hbase、Hdfs、Solr：對日誌進行存儲和提供檢索功能。Solr作為一個分佈式搜索引擎，能夠提供功能強大的檢索服務和一定的統計分析功能。
該方案的優缺點：
優點：
· 所有組件在華為的Fusioninsight平臺都有提供
· 組件使用熟悉程度高
· 對已有交易沒有侵入性
缺點：
· Hbase由於其Rowkey設計的特點，查詢比較受限，僅使用Hbase作為存儲無法滿足一個日誌收集分析平臺的主要需求
· Hdfs只能是作為數據備份
· Solr能夠提供檢索功能但需要開發相應的聯機功能才能對外提供服務
· Sparkstream的日誌加工處理邏輯必須自主實現，有一定的開發量以及面對不同的日誌
格式通用性不高
三、基於Filebeat+Kafka+Logstash+Elasticsearch+Kibana的日式收集與分析
如圖所示，採集端使用的是Filebeat，數據管道採用的是Kafka，數據處理使用的是Logstash，數據存儲與檢索採用的是Elasticsearch+Kibana。
· Filebeat：Filebeat是一個輕量級的日誌採集組件，其主要邏輯是為每個監控的文件創建一個Harvester，在整個日誌採集過程中Havester都會保留文件的句柄，將文件的增量記錄發送給目標端，並在內存的registry file中更新文件的讀取狀態，如讀取到的最新位置等，保證對文件數據的at-least-once語義。對於循環寫入的日誌文件（如當前我們很多系統的日誌寫入方式，日誌文件達到一定大小後會重命名並重新創建最新的日誌文件的方式）Filebeat會有問題可能會丟失數據，對於該問題的處理可以後續深入討論。
· Logstash：日誌處理，轉換，過濾。通過grok配置解析和過濾將非結構化的日誌記錄轉化為結構話的記錄。Logstash也可以作為數據採集端直接使用，但相比於Filebeat其過於重量級，會給服務器帶來比較大的壓力。
· Kafka：數據管道，由Filebeat作為生產者，Logstash作為消費者。
· Elasticsearch：作為存儲組件並提供分佈式的檢索和統計分析功能。Elasticsearch在官網上的介紹為“Elasticsearch is an open source distributed, RESTful search and analytics engine capable of solving a growing number of use cases.”其安裝和部署很簡單，如Solr一樣是基於luncence的開箱即用的分佈式搜索引擎，同時具有功能強大的統計分析功能。
· Kibana：針對Elasticsearch的一款開源的可視化組件，通過Kibana可以完成對Elasticsearch的可視化檢索與分析、還可以自定義統計圖表以及做一些實時指標監控。這也是吸引我選擇ELK的關鍵所在。
該方案的優缺點分析如下：
優點：
· 所有框架均為開源，且社區活躍
· 實現了日誌收集分析的全流程，尤其是具有良好體驗的檢索統計分析功能
· Kafka後可以接其它消費者，比如可以和第一個方案進行適當整合，將日誌數據存入別的存儲組件
缺點：
· 開源產品，環境搭建有一定的學習成本
· 日誌採集的一些問題，比如Filebeat對循環寫入的文件採集可能存在丟失數據的問題，而Flume不會。
三、其它思考
在上面的內容中主要介紹的是利用不同的組件如何搭建一套完整的日誌分析處理平臺。實際上，日誌收集分析首當其衝的問題在於如何設計一套規範的、通用的、靈活的日誌規範。或者說不僅僅侷限於系統產生的日誌數據，其概念還可以包含如消息，事件等等，比如前端和後端的日誌如何進行統一檢索，匹配與分析。其應用場景是很廣泛的，追蹤錯誤原因，基本指標的統計分析，KPI監控等都是最基本的需求。還可以基於對前端組件收集點擊、瀏覽等等事件來分析UI設計是否合理等。
此外，在文章最開始將日誌收集分析歸為是個主要的部分，每個部分的可選產品都是很多的，而且是很靈活的。比如針對方案二，我們可以把採集的組件換成Flume，針對方案一我們也可以接入Elasticsearch和Kibana。具體的方案應該根據實際應用的需求和條件來考慮。
最後，對於在應用中將日誌以消息的方式寫入Kafka也是一種選擇，Kafka作為數據管道本身就具有存儲，以及平衡生產者和消費者兩端處理速度的作用。利用Log4jAppdener可以配置將日誌直接寫入Kafka。對於這些方案中的一些組件後續，感興趣的讀者可以做在留言區深入的討論。
閱讀更多 銀行小馬農的日常 的文章
