ELK-日誌分析系統

二十-帥帥發表於2020-09-23

為什麼要建立日誌分析系統:

當我們需要進行日誌分析場景:直接在日誌檔案中 grep、awk 就可以獲得自己想要的資訊。但在規模較大的場景中,此方法效率低下,面臨問題包括日誌量太大如何歸檔、文字搜尋太慢怎麼辦、如何多維度查詢。需要集中化的日誌管理,所有伺服器上的日誌收集彙總。

解決辦法是建立集中式日誌收集系統,將所有節點上的日誌統一收集,管理,訪問。

一般大型系統是一個分散式部署的架構,不同的服務模組部署在不同的伺服器上,問題出現時,大部分情況需要根據問題暴露的關鍵資訊,定位到具體的伺服器和服務模組,構建一套集中式日誌系統,可以提高定位問題的效率。

一個完整的集中式日誌系統,需要包含以下幾個主要特點:

  • 收集-能夠採集多種來源的日誌資料
  • 傳輸-能夠穩定的把日誌資料傳輸到中央系統
  • 儲存-如何儲存日誌資料
  • 分析-可以支援 UI 分析
  • 警告-能夠提供錯誤報告,監控機制

ELK提供了一整套解決方案,並且都是開源軟體,之間互相配合使用,完美銜接,高效的滿足了很多場合的應用。目前主流的一種日誌系統。

ELK簡介:

ELK是三個開源軟體的縮寫,分別表示:Elasticsearch , Logstash, Kibana , 它們都是開源軟體。新增了一個FileBeat,它是一個輕量級的日誌收集處理工具(Agent),Filebeat佔用資源少,適合於在各個伺服器上搜集日誌後傳輸給Logstash,官方也推薦此工具。

Elasticsearch是個開源分散式搜尋引擎,提供蒐集、分析、儲存資料三大功能。它的特點有:分散式,零配置,自動發現,索引自動分片,索引副本機制,restful風格介面,多資料來源,自動搜尋負載等。

Logstash 主要是用來日誌的蒐集、分析、過濾日誌的工具,支援大量的資料獲取方式。一般工作方式為c/s架構,client端安裝在需要收集日誌的主機上,server端負責將收到的各節點日誌進行過濾、修改等操作在一併發往elasticsearch上去。

Kibana 也是一個開源和免費的工具,Kibana可以為 Logstash 和 ElasticSearch 提供的日誌分析友好的 Web 介面,可以幫助彙總、分析和搜尋重要資料日誌。

Kibana示例圖

Filebeat隸屬於Beats。目前Beats包含四種工具:

  1. Packetbeat(蒐集網路流量資料)
  2. Topbeat(蒐集系統、程式和檔案系統級別的 CPU 和記憶體使用情況等資料)
  3. Filebeat(蒐集檔案資料)
  4. Winlogbeat(蒐集 Windows 事件日誌資料)

ELK用途:

傳統意義上,ELK是作為替代Splunk的一個開源解決方案。Splunk 是日誌分析領域的領導者。日誌分析並不僅僅包括系統產生的錯誤日誌,異常,也包括業務邏輯,或者任何文字類的分析。而基於日誌的分析,能夠在其上產生非常多的解決方案,譬如:

1.問題排查。我們常說,運維和開發這一輩子無非就是和問題在戰鬥,所以這個說起來很樸實的四個字,其實是沉甸甸的。很多公司其實不缺錢,就要穩定,而要穩定,就要運維和開發能夠快速的定位問題,甚至防微杜漸,把問題殺死在搖籃裡。日誌分析技術顯然問題排查的基石。基於日誌做問題排查,還有一個很帥的技術,叫全鏈路追蹤,比如阿里的eagleeye 或者Google的dapper,也算是日誌分析技術裡的一種。
2.監控和預警。 日誌,監控,預警是相輔相成的。基於日誌的監控,預警使得運維有自己的機械戰隊,大大節省人力以及延長運維的壽命。
3.關聯事件。多個資料來源產生的日誌進行聯動分析,通過某種分析演算法,就能夠解決生活中各個問題。比如金融裡的風險欺詐等。這個可以可以應用到無數領域了,取決於你的想象力。
4.資料分析。 這個對於資料分析師,還有演算法工程師都是有所裨益的。

官方文件:

Filebeat:

https://www.elastic.co/cn/products/beats/filebeat
https://www.elastic.co/guide/en/beats/filebeat/5.6/index.html

Logstash:
https://www.elastic.co/cn/products/logstash
https://www.elastic.co/guide/en/logstash/5.6/index.html

Kibana:

https://www.elastic.co/cn/products/kibana

https://www.elastic.co/guide/en/kibana/5.5/index.html

Elasticsearch:
https://www.elastic.co/cn/products/elasticsearch
https://www.elastic.co/guide/en/elasticsearch/reference/5.6/index.html

elasticsearch中文社群:
https://elasticsearch.cn/

ELK架構圖:

架構圖一:

這是最簡單的一種ELK架構方式。優點是搭建簡單,易於上手。缺點是Logstash耗資源較大,執行佔用CPU和記憶體高。另外沒有訊息佇列快取,存在資料丟失隱患。

此架構由Logstash分佈於各個節點上搜集相關日誌、資料,並經過分析、過濾後傳送給遠端伺服器上的Elasticsearch進行儲存。Elasticsearch將資料以分片的形式壓縮儲存並提供多種API供使用者查詢,操作。使用者亦可以更直觀的通過配置Kibana Web方便的對日誌查詢,並根據資料生成報表。

架構圖二:

此種架構引入了訊息佇列機制,位於各個節點上的Logstash Agent先將資料/日誌傳遞給Kafka(或者Redis),並將佇列中訊息或資料間接傳遞給Logstash,Logstash過濾、分析後將資料傳遞給Elasticsearch儲存。最後由Kibana將日誌和資料呈現給使用者。因為引入了Kafka(或者Redis),所以即使遠端Logstash server因故障停止執行,資料將會先被儲存下來,從而避免資料丟失。

架構圖三:

此種架構將收集端logstash替換為beats,更靈活,消耗資源更少,擴充套件性更強。同時可配置Logstash 和Elasticsearch 叢集用於支援大叢集系統的運維日誌資料監控和查詢。

Filebeat工作原理:

Filebeat由兩個主要元件組成:prospectors 和 harvesters。這兩個元件協同工作將檔案變動傳送到指定的輸出中。

Harvester(收割機):負責讀取單個檔案內容。每個檔案會啟動一個Harvester,每個Harvester會逐行讀取各個檔案,並將檔案內容傳送到制定輸出中。Harvester負責開啟和關閉檔案,意味在Harvester執行的時候,檔案描述符處於開啟狀態,如果檔案在收集中被重新命名或者被刪除,Filebeat會繼續讀取此檔案。所以在Harvester關閉之前,磁碟不會被釋放。預設情況filebeat會保持檔案開啟的狀態,直到達到close_inactive(如果此選項開啟,filebeat會在指定時間內將不再更新的檔案控制程式碼關閉,時間從harvester讀取最後一行的時間開始計時。若檔案控制程式碼被關閉後,檔案發生變化,則會啟動一個新的harvester。關閉檔案控制程式碼的時間不取決於檔案的修改時間,若此引數配置不當,則可能發生日誌不實時的情況,由scan_frequency引數決定,預設10s。Harvester使用內部時間戳來記錄檔案最後被收集的時間。例如:設定5m,則在Harvester讀取檔案的最後一行之後,開始倒數計時5分鐘,若5分鐘內檔案無變化,則關閉檔案控制程式碼。預設5m)。

Prospector(勘測者):負責管理Harvester並找到所有讀取源。

filebeat.prospectors:

- input_type: log

  paths:

    - /apps/logs/*/info.log

Prospector會找到/apps/logs/*目錄下的所有info.log檔案,併為每個檔案啟動一個Harvester。Prospector會檢查每個檔案,看Harvester是否已經啟動,是否需要啟動,或者檔案是否可以忽略。若Harvester關閉,只有在檔案大小發生變化的時候Prospector才會執行檢查。只能檢測本地的檔案。

Filebeat如何記錄檔案狀態:

將檔案狀態記錄在檔案中(預設在/var/lib/filebeat/registry)。此狀態可以記住Harvester收集檔案的偏移量。若連線不上輸出裝置,如ES等,filebeat會記錄傳送前的最後一行,並再可以連線的時候繼續傳送。Filebeat在執行的時候,Prospector狀態會被記錄在記憶體中。Filebeat重啟的時候,利用registry記錄的狀態來進行重建,用來還原到重啟之前的狀態。每個Prospector會為每個找到的檔案記錄一個狀態,對於每個檔案,Filebeat儲存唯一識別符號以檢測檔案是否先前被收集。

Filebeat如何保證事件至少被輸出一次:

Filebeat之所以能保證事件至少被傳遞到配置的輸出一次,沒有資料丟失,是因為filebeat將每個事件的傳遞狀態儲存在檔案中。在未得到輸出方確認時,filebeat會嘗試一直髮送,直到得到回應。若filebeat在傳輸過程中被關閉,則不會再關閉之前確認所有時事件。任何在filebeat關閉之前為確認的時間,都會在filebeat重啟之後重新傳送。這可確保至少傳送一次,但有可能會重複。可通過設定shutdown_timeout引數來設定關閉之前的等待事件回應的時間(預設禁用)。

 

Logstash工作原理:

Logstash事件處理有三個階段:inputs → filters → outputs。是一個接收,處理,轉發日誌的工具。支援系統日誌,webserver日誌,錯誤日誌,應用日誌,總之包括所有可以丟擲來的日誌型別。

 

Input:輸入資料到logstash。

一些常用的輸入為:

file:從檔案系統的檔案中讀取,類似於tail -f命令

syslog:在514埠上監聽系統日誌訊息,並根據RFC3164標準進行解析

redis:從redis service中讀取

beats:從filebeat中讀取

Filters:資料中間處理,對資料進行操作。

一些常用的過濾器為:

grok:解析任意文字資料,Grok 是 Logstash 最重要的外掛。它的主要作用就是將文字格式的字串,轉換成為具體的結構化的資料,配合正規表示式使用。內建120多個解析語法。

官方提供的grok表示式:https://github.com/logstash-plugins/logstash-patterns-core/tree/master/patterns
grok線上除錯:https://grokdebug.herokuapp.com/

mutate:對欄位進行轉換。例如對欄位進行刪除、替換、修改、重新命名等。

drop:丟棄一部分events不進行處理。

clone:拷貝 event,這個過程中也可以新增或移除欄位。

geoip:新增地理資訊(為前臺kibana圖形化展示使用)

Outputs:outputs是logstash處理管道的最末端元件。一個event可以在處理過程中經過多重輸出,但是一旦所有的outputs都執行結束,這個event也就完成生命週期。

一些常見的outputs為:

elasticsearch:可以高效的儲存資料,並且能夠方便和簡單的進行查詢。

file:將event資料儲存到檔案中。

graphite:將event資料傳送到圖形化元件中,一個很流行的開源儲存圖形化展示的元件。

Codecs:codecs 是基於資料流的過濾器,它可以作為input,output的一部分配置。Codecs可以幫助你輕鬆的分割傳送過來已經被序列化的資料。

一些常見的codecs:

json:使用json格式對資料進行編碼/解碼。

multiline:將匯多個事件中資料彙總為一個單一的行。比如:java異常資訊和堆疊資訊。

相關文章