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

文章大綱

1、日誌系統概念介紹
2、ELK日誌系統介紹
3、互聯網行業日誌處理方案介紹
4、參考文章

 

1、日誌系統概念介紹

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用戶感興趣商品。

2、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天生就是分佈式的消息隊列系統。

 

3、互聯網行業日誌處理方案介紹

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集羣中。
任何解決方案都不是十全十美的，具體採用哪些技術要深刻了解本身的應用場景。就目前日誌處理領域的開源組件來講，在如下幾個方面還比較欠缺：

4、參考文章

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