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

本文轉載自查看原文 2018-07-02 16:09 806

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

引言：

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

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

如何及時采集日志信息？
如何將日志信息進行匯總？
匯總之后如何對日志信息進行檢索分析？

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

目錄：

一、日志的重要性和復雜性

二、基於微服務的日志中心架構設計

三、日志中心的流程與實現

四、日志中心的關鍵配置

五、總結

一、日志的重要性和復雜性

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

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

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

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

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

二、基於微服務的日志中心架構設計

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

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

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

圖片中並沒有日志中心這四個關鍵字，因為他是由多個獨立組件共同協同構成的。

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

我們經過考量研究確定了一套適用於當下微服務架構日志管理流程。

1. 日志選取 ---- 確定選擇哪些日志記錄分析

2. 日志采集 ---- filebeat輕巧做收集

3. 日志緩沖 ---- kafka緩存本地做緩沖

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

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

6. 日志檢索 ---- 利用elasticsearch本身的檢索功能

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

在傳統的ELK上替換了Logstash做日志采集的部分采取Filebeat，在日志存儲前多了kafka緩沖和logstash篩選。這一套流程在保障功能完備同時提高性能、盡可能做到輕量部署。

三、日志中心的流程與實現

選擇：以業務場景為原則

日志內容復雜多樣，如何去收集有價值的日志是我們重點關注的。日志的價值其實是取決於業務操作的，不同的業務場景下相同類型的日志的價值會截然不同。

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

• 跟蹤日志【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在日志可視化方面的努力，實現日志的可視化處理，只需通過簡單的配置就可以看到對某一個服務或者某一個應用的清晰的可視化的日志分析結果。