普元雲計算-基於微服務的日誌中心設計、實現與關鍵配置

時間 2019-11-17

標籤計算基於微服日誌中心設計實現關鍵配置简体版

原文原文鏈接

轉載本文需註明出處：微信公衆號EAWorld，違者必究。java

引言：緩存

日誌向來都是運維以及開發人員最關心的問題。運維人員能夠及時的經過相關日誌信息發現系統隱患、系統故障並及時安排人員處理解決問題。開發人員解決問題離不開日誌信息的協助定位。沒有日誌就至關於沒有了眼睛，失去了方向。安全

微服務日漸火熱，享受微服務架構帶來的種種好處的同時也要承擔起由微服務帶來的種種困擾。日誌管理就是其中一個。微服務有一個很大的特點：分佈式。分佈式部署的結果就致使日誌信息散落在各地，這樣就給日誌的採集存儲帶來了必定的挑戰：微信

如何及時採集日誌信息？網絡
如何將日誌信息進行彙總？架構
彙總以後如何對日誌信息進行檢索分析？app

這篇文章將探討一下日誌管理的相關問題。運維

目錄：elasticsearch

1、日誌的重要性和複雜性分佈式

2、基於微服務的日誌中心架構設計

3、日誌中心的流程與實現

4、日誌中心的關鍵配置

5、總結

1、日誌的重要性和複雜性

要說管日誌，在管日誌以前有一個先決條件，咱們須要知道日誌是什麼，能作什麼，有什麼用。援引百度百科的話，它是記錄系統操做事件的記錄信息。

在日誌文件內部記錄了當前系統的各項生命體徵，就像咱們在醫院體檢事後拿到的體檢單，上面反應了咱們的肝功能、腎功能、血常規等的具體指標。日誌文件在應用系統中的做用就如同體檢單，它反應了系統的健康狀態、系統的操做事件、系統的變動情況。

日誌在系統中扮演着監護人的身份，它是保障高可靠服務的基礎，記錄了系統的一舉一動。運維層面、業務層面、安全層面都有日誌的身影，系統監控、異常處理、安全、審計等都離不開日誌的協助。

日誌種類繁雜，一個健壯的系統可能會有着各類各樣的日誌信息。

如此複雜多樣的日誌，是否要一網打盡？哪些又是咱們所須要的？這都是咱們在設計日誌中心架構時須要考慮的問題。

2、基於微服務的日誌中心架構設計

日誌中心是微服務生態中不可或缺的一環，是監控的二當家。在此分享一下咱們的產品級設計實踐，瞭解一下，在基於微服務的架構，日誌中心在技術架構中所處的位置是怎樣的，以及如何部署。

在這一設計中，微服務結構由如下幾部分組成：

域：一個域是一套註冊中心、配置中心、業務監控中心、網關等組成的生態圈。一個域內有能夠有多個系統。
系統：一個系統內部能夠部署多個應用。
應用：輕耦合的微服務應用。

圖片中並無日誌中心這四個關鍵字，由於他是由多個獨立組件共同協同構成的。

這些組件分別是Filebeat、Kafka、Logstash、Elastic search，他們共同構成了日誌中心。

咱們通過考量研究肯定了一套適用於當下微服務架構日誌管理流程。

1. 日誌選取 ---- 肯定選擇哪些日誌記錄分析

2. 日誌採集 ---- filebeat輕巧作收集

3. 日誌緩衝 ---- kafka緩存本地作緩衝

4. 日誌篩選 ---- logstash篩選過濾

5. 日誌存儲 ---- elasticsearch建索引入庫

6. 日誌檢索 ---- 利用elasticsearch自己的檢索功能

7. 日誌展示 ---- 參考kibana風格實現日誌數據可視化

在傳統的ELK上替換了Logstash作日誌採集的部分採起Filebeat，在日誌存儲前多了kafka緩衝和logstash篩選。這一套流程在保障功能完備同時提升性能、儘量作到輕量部署。

3、日誌中心的流程與實現

選擇：以業務場景爲原則

日誌內容複雜多樣，如何去收集有價值的日誌是咱們重點關注的。日誌的價值實際上是取決於業務操做的，不一樣的業務場景下相同類型的日誌的價值會大相徑庭。

根據以往的業務實踐，結合企業級的一些業務需求，咱們選定關注如下幾類日誌。

• 跟蹤日誌【trace.log】 Server引擎的調試日誌，用於系統維護人員定位系統運行問題使用。

• 系統日誌【system.log】大粒度的引擎運行的入口、出口的日誌，用於調用棧分析，能夠進行性能分析使用。

• 部署日誌【deploy.log】記錄系統啓動、中止、構件包部署、集羣通知等信息的日誌。

• 引擎日誌【engine.log】細粒度的引擎運行日誌，能夠打印上下文數據，用於定位業務問題。

• 構件包日誌【contribution.log】構件包記錄的業務日誌（使用基礎構件庫的日誌輸出API寫日誌）

經過以上幾種日誌，咱們能夠在分析問題時明確咱們要查找的位置，經過分類縮小查找範圍提升效率。

採集（Filebeat）：側重考慮輕量級

微服務應用會分佈在各個域內的各個系統。應用的日誌也就相對應的產生在各個域內的各個系統。進行日誌管理首先要作好日誌的採集工做。日誌採集工做咱們選擇Elastic Stack中的Filebeat。

Filebeat是一個開源的文件採集器，基於go語言開發，不須要java環境，它是對logstash的重構產物。Filebeat對環境依賴很低比較親民。
Filebeat是一個輕量的採集器，最新版的Filebeat體積大約是20M左右，而logstash有近百兆。Filebeat更利於部署實施，減輕宿主壓力。
以前曾有對filebeat和logstash的測試對比，在採集日誌方面，filebeat比logstash花費更少CPU和內存。Filebeat在日誌採集方面有更好的性能表現。

Filebeat和應用是掛鉤的，由於咱們須要知道針對每一個落點去收集日誌信息，因此輕量實際上是咱們考量的主要因素。

Filebeat會有一個或者多個的叫作Prospector的探測器，能夠實時監聽指定的文件或者制定的文件目錄的變動情況，將變動情況及時的傳遞到下一層---Spooler處理。

Filebeat還有一個特性咱們放到日誌篩選那裏進行介紹，它是定位來源的關鍵。

這兩點恰好知足咱們實現日誌的實時採集的需求。經過Filebeat動態的將新增的日誌進行及時存儲取樣。至此如何採集日誌信息的問題已經能夠完美解決。

緩衝（Kafka）：吞吐量大、易擴展、上限高

在日誌存儲以前，咱們引入了一個組件--- Kafka，做爲日誌緩衝層。 Kafka起一個緩衝的做用，避免高峯期應用對ES的衝擊。形成因爲ES瓶頸問題而引起數據丟失問題。同時它也起到了數據彙總的功能。

選用kafka來作日誌緩衝有幾個優勢：

吞吐量大，一個topic能夠拆分爲多個partition。建議這幾個partition在不一樣的磁盤中。
分佈式系統易拓展。
Kafka的性能主要取決於它對磁盤的連續讀寫，它的性能很大程度上是取決於磁盤處理的能力。能夠說只要磁盤性能容許，它就能夠無限制的接收來自Filebeat的日誌信息，從而實現一個緩衝的做用。

篩選（Logstash）：提早埋點、方便定位

日誌信息通過filebeat、kafka等工具的收集傳遞，給日誌事件加了不少附加信息。利用Logstash實現二次處理，可在filter裏進行過濾或處理。

咱們在Filebeat收集信息的時候經過將同一個Server上的日誌信息發送到同一個Kafka的topic中來實現日誌的彙總，這個topic名稱就是server的關鍵信息。在更細粒度的層面上你也能夠將每個App的信息都看成一個topic來進行彙總。Kafka中經過Filebeat接受到的日誌信息中包含了一個標識---日誌是從哪裏來的。Logstash的做用就是在日誌匯入ES以前，經過標識將對應的日誌信息進行二次篩選彙總處理，輸送給ES，爲以後的搜索提供依據。方便咱們清楚的定位問題。

存儲(ES)：方便擴展、上手簡單

Elastic 是 Lucene 的封裝，提供了 REST API 的操做接口，開箱即用。

選用ElasticSearch的緣由主要爲：可分佈式的部署，方便拓展；處理海量數據能夠應對多種需求；強大的搜索功能，基於Lucene能夠實現快速搜索；活躍的開發社區，資料多、上手簡單。

檢索（ES）：分門別類

Elasticsearch自己就是一個強大的搜索引擎，支持經過系統、應用、應用實例分組、應用實例IP、關鍵字、日誌級別、時間區間來檢索所須要的日誌信息。

展示（Kibana）：簡單配置、清晰明瞭

查看密密麻麻的日誌信息的時候，經常會有一種暈眩感。須要經過精簡提煉日誌信息，對日誌信息進行整合分析，以圖表的形式將日誌信息進行展現。在展現的過程當中咱們能夠借鑑和吸取Kibana在日誌可視化方面的努力，實現日誌的可視化處理，只需經過簡單的配置就能夠看到對某一個服務或者某一個應用的清晰的可視化的日誌分析結果。

（注：圖片摘自互聯網https://blog.csdn.net/my_bai/article/details/68062701 服務調用折線圖）

4、日誌中心的關鍵配置

在此就再也不贅述關於各個組件的安裝方法了，你們能夠很輕鬆的從網絡上找到相關教程。咱們在這裏介紹一些關鍵的配置，確保你們在安裝過程當中關鍵環節少走一些彎路。

Filebeat的關鍵配置