前言

日誌，一直以來都是開發人員和運維人員最關心的問題。開發人員可透過日誌記錄來協助問題定位，運維人員可透過日誌發現系統隱患，故障等定位問題。如果你的系統中沒有日誌，就像一個斷了線的風箏，你永遠不知道它會的落腳點（故障點）在什麼地方。當然，你說你不用日誌，非要用除錯樣式來一個一個的排查和驗證問題，那這將是非常瘋狂的。

微服務架構日漸火熱，在享受微服務帶來的種種好處的同事，也要承擔她所帶來的各種困擾。因為系統不再是一個獨立的個體，而是分部到不同地方、不同宿主、不同區段單獨的服務個體（節點），他散落，不統一，那麼，當某個節點出現問題，如何快速定位，將是一個挑戰。你總不可能說我把每個節點的日誌都查一遍吧。那麼，這個問題可以這樣描述：

• 如何及時採集每個節點的日誌？

• 如何將日誌進行及時彙總？

• 如何將彙總的日誌進行有利（快速）的分析（檢索）？

日誌的重要性和複雜性

說道日誌的重要性，我相信沒有任何開發人員和運維人員認為他不重要，正如“前言”所提，這個世界沒有這樣瘋狂的人。

再論日誌的複雜性，日誌儲存了當前系統中各種功能的記錄，正如你去一家醫院的體檢單，上面清晰的記錄了你各項生命特徵資訊、以及不同的指標。日誌檔案在應用系統中的作用就如同體檢單，它反應了系統的健康狀態、系統的操作事件、系統的變更狀況。

日誌種類繁雜，一個健壯的系統可能會有著各種各樣的日誌資訊。

單單上面一張圖片，可以顯示出六種日誌型別，那還有我們開發的日誌呢，比如除錯，執行，錯誤，一般資訊等等等。如此多種多樣的日誌，哪些是我們所需要的，都是在架構中需要考慮的問題。

微服務的日誌中心架設流程

我們先瞭解一下微服務中的體系（結構）：

• 域：一個域是一套註冊中心、配置中心、監控中心、閘道器等等組成的結構體系，一個域中可以有多個系統。

• 系統：一個系統相當於一個容器叢集，這個容器系統內可以部署多個應用節點。

• 節點：實現了微服務的輕耦合節點（應用）。

當然，理解這些是不夠的架構設計的，我們還需要瞭解整個日誌收集中的每個流程：

• 日誌選擇：確定哪些日誌型別需要進行收集分析，比如除錯，網路等等型別。

• 日誌採集：使用哪種日誌元件來作為採集，.NET上常用有Nlog和Log4net。

• 日誌緩衝：使用Kafka或RabbitMQ來緩衝日誌收集的大量請求。

• 日誌篩選：篩選（過濾）哪些日誌型別將要被儲存，提前埋點。

• 日誌儲存：日誌的統一儲存，例如ES（Elasticsearch）。

• 日誌檢索：日誌的快速檢索功能，例如ES（Elasticsearch）。

• 日誌展現：日誌的UI展現，例如KI（Kibana），或自定義WEB站點。

日誌中心

在日誌中心的方案上，由於日誌收集沒有語言依賴性，我們可以透過混合使用不同語言的元件來收集日誌。

ELK

（Elasticsearch + Logstash + Kibana），java開源日誌收集平臺，名聲赫赫，我們只需要配置採集元件的遠端對接即可進行儲存。如你更傾向於日後微服務的其他所有元件都是Java（比如Spring Boot）的，可使用

steeltoe

來完成你的夢想。（筆者並未深入研究ELK，只是實現了日誌的提交和展現）

特點：開源，免費

Splunk：使用 Splunk 可收集、索引和利用所有應用程式、伺服器和裝置生成的快速移動型計算機資料。使用Splunking處理計算機資料，可讓您在幾分鐘內解決問題和調查安全事件–| 這解釋太官方，公司目前用的就是Splunk

特點：企業版收費，上手困難。

Exceptionless：原生.Net平臺上開發的一套開源日誌收集中心，支援託管或自行部署，並且新版裡面還有一些非常簡單的APM，比如死鏈、耗時。

特點：託管收費，介面清晰易懂，最重要的是.Net且開源

總結

本篇簡單的介紹了日誌收集的重要性，和設計流程，並簡單的展示了三個常見平臺的主介面，下一篇我們重點介紹Exceptionless。

原文地址：https://www.cnblogs.com/SteveLee/p/MicroService_Logs.html