日志系統架構介紹（非原創）

文章大綱

一、日志系統概念介紹
二、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./)。它由日志采集解析工具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集群中。
任何解決方案都不是十全十美的，具體采用哪些技術要深入了解自己的應用場景。就目前日志處理領域的開源組件來說，在以下幾個方面還比較欠缺：

四、參考文章

1. https://blog.csdn.net/yunzhaji3762/article/details/82962291
2. https://blog.csdn.net/bigstar863/article/details/49099531
3. https://www.cnblogs.com/kevingrace/p/5919021.html