文章大綱
一、日誌系統概念介紹
二、ELK日誌系統介紹
三、互聯網行業日誌處理方案介紹
四、參考文章
一、日誌系統概念介紹
1. 簡介
日誌主要包括系統日誌、應用程序日誌和安全日誌。系統運維和開發人員可以通過日誌瞭解服務器軟硬件信息、檢查配置過程中的錯誤及錯誤發生的原因。經常分析日誌可以瞭解服務器的負荷，性能安全性，從而及時採取措施糾正錯誤。
通常，日誌被分散在儲存不同的設備上。如果你管理數十上百臺服務器，你還在使用依次登錄每臺機器的傳統方法查閱日誌。這樣是不是感覺很繁瑣和效率低下。當務之急我們使用集中化的日誌管理，例如：開源的syslog，將所有服務器上的日誌收集彙總。
集中化管理日誌後，日誌的統計和檢索又成爲一件比較麻煩的事情，一般我們使用grep、awk和wc等Linux命令能實現檢索和統計，但是對於要求更高的查詢、排序和統計等要求和龐大的機器數量依然使用這樣的方法難免有點力不從心。
大數據時代，隨着數據量不斷增長，存儲與計算集羣的規模也逐漸擴大，幾百上千臺的雲計算環境已不鮮見。現在的集羣所需要解決的問題不僅僅是高性能、高可靠性、高可擴展性，還需要面對易維護性以及數據平臺內部的數據共享性等諸多挑戰。優秀的系統運維平臺既能實現數據平臺各組件的集中式管理、方便系統運維人員日常監測、提升運維效率，又能反饋系統運行狀態給系統開發人員。例如採集數據倉庫的日誌可以按照時間序列查看各數據庫實例各種級別的日誌數量與佔比，採集DB2表空間數據分析可得到數據庫集羣健康狀態，分析應用服務器的日誌可以查看出錯最多的模塊、下載最多的文件、使用最多的功能等。大數據時代的業務與運維將緊密的結合在一起。
2. 日誌分類
日誌是帶時間戳的基於時間序列的機器數據，包括IT系統信息（服務器、網絡設備、操作系統、應用軟件）、物聯網各種傳感器信息。日誌可以反映用戶行爲，是真實數據。
日誌處理方案經歷的版本迭代
日誌處理v1.0
日誌沒有集中式處理；只做事後追查，黑客入侵後刪除日誌無法察覺；使用數據庫存儲日誌，無法勝任複雜事務處理。
日誌處理v2.0
使用Hadoop平臺實現日誌離線批處理，缺點是實時性差；使用Storm流處理框架、Spark內存計算框架處理日誌，但Hadoop/Storm/Spark都是編程框架，並不是拿來即用的平臺。
日誌處理v3.0
使用日誌實時搜索引擎分析日誌，特點：第一是快，日誌從產生到搜索分析出結果只有數秒延時；第二是大，每天處理TB日誌量；第三是靈活，可搜索分析任何日誌。作爲代表的解決方案有Splunk、ELK、SILK。
3. 日誌實時性分析
實時
一般適用於我們常說的一級應用，如：直接面向用戶的應用。我們可以自定義各類關鍵字，以方便在出現各種 error 或 exception 時，相關業務人員能夠在第一時間被通知到。
準實時
一般適用於一些項目管理的平臺，如：在需要填寫工時的時候出現了宕機，但這並不影響工資的發放。
平臺在幾分鐘後完成重啓，我們可以再登錄填寫，該情況並不造成原則性的影響。因此，我們可以將其列爲準實時的級別。
除了直接採集錯誤與異常，我們還需要進行分析。例如：僅知道某人的體重是沒什麼意義的，但是如果增加了性別和身高兩個指標，那麼我們就可以判斷出此人的體重是否爲標準體重。
也就是說：如果能給出多個指標，就可以對龐大的數據進行去噪，然後通過迴歸分析，讓採集到的數據更有意義。
此外，我們還要不斷地去還原數字的真實性。特別是對於實時的一級應用，我們要能快速地讓用戶明白他們所碰到現象的真實含義。
例如：商家在上架時錯把商品的價格標籤 100 元標成了 10 元。這會導致商品馬上被搶購一空。
但是這種現象並非是業務的問題，很難被發現，因此我們只能通過日誌數據進行邏輯分析，及時反饋以保證在幾十秒之後將庫存修改爲零，從而有效地解決此問題。可見，在此應用場景中，實時分析就顯得非常有用。
最後是追溯，我們需要在獲取歷史信息的同時，實現跨時間維度的對比與總結，那麼追溯就能夠在各種應用中發揮其關聯性作用了。
4. 完整的日誌系統包含內容
（1）收集－能夠採集多種來源的日誌數據
（2）傳輸－能夠穩定的把日誌數據傳輸到中央系統
（3）存儲－如何存儲日誌數據
（4）分析－可以支持 UI 分析
（5）警告－能夠提供錯誤報告，監控機制
ELK提供了一整套解決方案，並且都是開源軟件，之間互相配合使用，完美銜接，高效的滿足了很多場合的應用。目前主流的一種日誌系統。
5. 完整的日誌系統作用
（1）信息查找。通過檢索日誌信息，定位相應的bug，找出解決方案。
（2）服務診斷。通過對日誌信息進行統計、分析，瞭解服務器的負荷和服務運行狀態，找出耗時請求進行優化等等。
（3）數據分析。如果是格式化的log，可以做進一步的數據分析，統計、聚合出有意義的信息，比如根據請求中的商品id，找出TOP10用戶感興趣商品。
二、ELK日誌系統介紹
1. ELK組成成分
ELK Stack是開源日誌處理平臺解決方案，背後的商業公司是elastic(https://www.elastic.co/)。它由日誌採集解析工具Logstash、基於Lucene的全文搜索引擎Elasticsearch、分析可視化平臺Kibana組成。目前ELK的用戶有Adobe、Microsoft、Mozilla、Facebook、Stackoverflow、Cisco、ebay、Uber等諸多廠商。
2. ELK工作原理展示圖
3. Elasticsearch介紹
Elasticsearch是基於Lucene的近實時搜索平臺，它能在一秒內返回你要查找的且已經在Elasticsearch做了索引的文檔。它默認基於Gossip路由算法的自動發現機制構建配置有相同cluster name的集羣，但是有的時候這種機制並不可靠，會發生腦裂現象。鑑於主動發現機制的不穩定性，用戶可以選擇在每一個節點上配置集羣其他節點的主機名，在啓動集羣時進行被動發現。
Elasticsearch中的Index是一組具有相似特徵的文檔集合，類似於關係數據庫模型中的數據庫實例，Index中可以指定Type區分不同的文檔，類似於數據庫實例中的關係表，Document是存儲的基本單位，都是JSON格式，類似於關係表中行級對象。我們處理後的JSON文檔格式的日誌都要在Elasticsearch中做索引，相應的Logstash有Elasticsearch output插件，對於用戶是透明的。
4. Logstash介紹
Logstash事件處理有三個階段：inputs → filters → outputs。是一個接收，處理，轉發日誌的工具。支持系統日誌，webserver日誌，錯誤日誌，應用日誌，總之包括所有可以拋出來的日誌類型。
Logstash工作原理：
5. Kibana介紹
Kibana是專門設計用來與Elasticsearch協作的，可以自定義多種表格、柱狀圖、餅狀圖、折線圖對存儲在Elasticsearch中的數據進行深入挖掘分析與可視化。下圖定製的儀表盤可以動態監測數據庫集羣中每個數據庫實例產生的各種級別的日誌。
實時監測DB2實例運行狀態的動態儀表盤：
6. ELK整體方案
ELK中的三個系統分別扮演不同的角色，組成了一個整體的解決方案。Logstash是一個ETL工具，負責從每臺機器抓取日誌數據，對數據進行格式轉換和處理後，輸出到Elasticsearch中存儲。Elasticsearch是一個分佈式搜索引擎和分析引擎，用於數據存儲，可提供實時的數據查詢。Kibana是一個數據可視化服務，根據用戶的操作從Elasticsearch中查詢數據，形成相應的分析結果，以圖表的形式展現給用戶。
ELK的安裝很簡單，可以按照"下載->修改配置文件->啓動"方法分別部署三個系統，也可以使用docker來快速部署。具體的安裝方法這裏不詳細介紹，下面來看一個常見的部署方案，如下圖所示，部署思路是：
（1）在每臺生成日誌文件的機器上，部署Logstash，作爲Shipper的角色，負責從日誌文件中提取數據，但是不做任何處理，直接將數據輸出到Redis隊列(list)中；
（2）需要一臺機器部署Logstash，作爲Indexer的角色，負責從Redis中取出數據，對數據進行格式化和相關處理後，輸出到Elasticsearch中存儲；
（3）部署Elasticsearch集羣，當然取決於你的數據量了，數據量小的話可以使用單臺服務，如果做集羣的話，最好是有3個以上節點，同時還需要部署相關的監控插件；
（4）部署Kibana服務，提供Web服務。
在前期部署階段，主要工作是Logstash節點和Elasticsearch集羣的部署，而在後期使用階段，主要工作就是Elasticsearch集羣的監控和使用Kibana來檢索、分析日誌數據了，當然也可以直接編寫程序來消費Elasticsearch中的數據。
在上面的部署方案中，我們將Logstash分爲Shipper和Indexer兩種角色來完成不同的工作，中間通過Redis做數據管道，爲什麼要這樣做？爲什麼不是直接在每臺機器上使用Logstash提取數據、處理、存入Elasticsearch？
首先，採用這樣的架構部署，有三點優勢：第一，降低對日誌所在機器的影響，這些機器上一般都部署着反向代理或應用服務，本身負載就很重了，所以儘可能的在這些機器上少做事；第二，如果有很多臺機器需要做日誌收集，那麼讓每臺機器都向Elasticsearch持續寫入數據，必然會對Elasticsearch造成壓力，因此需要對數據進行緩衝，同時，這樣的緩衝也可以一定程度的保護數據不丟失；第三，將日誌數據的格式化與處理放到Indexer中統一做，可以在一處修改代碼、部署，避免需要到多臺機器上去修改配置。
其次，我們需要做的是將數據放入一個消息隊列中進行緩衝，所以Redis只是其中一個選擇，也可以是RabbitMQ、Kafka等等，在實際生產中，Redis與Kafka用的比較多。由於Redis集羣一般都是通過key來做分片，無法對list類型做集羣，在數據量大的時候必然不合適了，而Kafka天生就是分佈式的消息隊列系統。
三、互聯網行業日誌處理方案介紹
1. 新浪
新浪採用的技術架構是常見的Kafka整合ELK Stack方案。Kafka作爲消息隊列用來緩存用戶日誌；使用Logstash做日誌解析，統一成JSON格式輸出給Elasticsearch；使用Elasticsearch提供實時日誌分析與強大的搜索和統計服務；Kibana用作數據可視化組件。該技術架構目前服務的用戶包括微博、微盤、雲存儲、彈性計算平臺等十多個部門的多個產品的日誌搜索分析業務，每天處理約32億條（2TB）日誌。
新浪的日誌處理平臺團隊對Elasticsearch做了大量優化（比如調整max open files等），並且開發了一個獨立的Elasticsearch Index管理系統，負責索引日常維護任務（比如索引的創建、優化、刪除、與分佈式文件系統的數據交換等）的調度及執行。爲Elasticsearch安裝了國內中文分詞插件elasticsearch-analysis-ik，滿足微盤搜索對中文分詞的需求。
2. 騰訊
騰訊藍鯨數據平臺告警系統的技術架構同樣基於分佈式消息隊列和全文搜索引擎。但騰訊的告警平臺不僅限於此，它的複雜的指標數據統計任務通過使用Storm自定義流式計算任務的方法實現，異常檢測的實現利用了曲線的時間週期性和相關曲線之間的相關性去定義動態的閾值，並且基於機器學習算法實現了複雜的日誌自動分類（比如summo logic）。
告警平臺把撥測（定時curl一下某個url，有問題就告警）、日誌集中檢索、日誌告警（5分鐘Error大於X次告警）、指標告警（cpu使用率大於X告警）整合進同一個數據管線，簡化了整體的架構。
3. 七牛
七牛採用的技術架構爲Flume＋Kafka＋Spark，混部在8臺高配機器。根據七牛技術博客提供的數據，該日誌處理平臺每天處理500億條數據，峯值80萬TPS。
Flume相較於Logstash有更大的吞吐量，而且與HDFS整合的性能比Logstash強很多。七牛技術架構選型顯然考慮了這一點，七牛雲平臺的日誌數據到Kafka後，一路同步到HDFS，用於離線統計，另一路用於使用Spark Streaming進行實時計算，計算結果保存在Mongodb集羣中。
任何解決方案都不是十全十美的，具體採用哪些技術要深入瞭解自己的應用場景。就目前日誌處理領域的開源組件來說，在以下幾個方面還比較欠缺：