NET Core微服務之路：簡單談談對ELK，Splunk，Exceptionless統一日誌收集中心的心得體會
前言
日誌，一直以來都是開發人員和運維人員最關心的問題。開發人員可通過日誌記錄來協助問題定位，運維人員可通過日誌發現系統隱患，故障等定位問題。如果你的系統中沒有日誌，就像一個斷了線的風箏，你永遠不知道它會的落腳點（故障點）在什麼地方。當然，你說你不用日誌，非要用除錯模式來一個一個的排查和驗證問題，那這將是非常瘋狂的。
微服務架構日漸火熱，在享受微服務帶來的種種好處的同事，也要承擔她所帶來的各種困擾。因為系統不再是一個獨立的個體，而是分部到不同地方、不同宿主、不同區段單獨的服務個體（節點），他散落，不統一，那麼，當某個節點出現問題，如何快速定位，將是一個挑戰。你總不可能說我把每個節點的日誌都查一遍吧。那麼，這個問題可以這樣描述：
-
如何及時採集每個節點的日誌？
-
如何將日誌進行及時彙總？
-
如何將彙總的日誌進行有利（快速）的分析（檢索）？
日誌的重要性和複雜性
說道日誌的重要性，我相信沒有任何開發人員和運維人員認為他不重要，正如“前言”所提，這個世界沒有這樣瘋狂的人。
再論日誌的複雜性，日誌儲存了當前系統中各種功能的記錄，正如你去一家醫院的體檢單，上面清晰的記錄了你各項生命特徵資訊、以及不同的指標。日誌檔案在應用系統中的作用就如同體檢單，它反應了系統的健康狀態、系統的操作事件、系統的變更狀況。
日誌種類繁雜，一個健壯的系統可能會有著各種各樣的日誌資訊。
（圖片來源於谷歌，侵權立刪）
單單上面一張圖片，可以顯示出六種日誌型別，那還有我們開發的日誌呢，比如除錯，執行，錯誤，一般資訊等等等。如此多種多樣的日誌，哪些是我們所需要的，都是在架構中需要考慮的問題。
微服務的日誌中心架設流程
我們先了解一下微服務中的體系（結構）：
-
域：一個域是一套註冊中心、配置中心、監控中心、閘道器等等組成的結構體系，一個域中可以有多個系統。
-
系統：一個系統相當於一個容器叢集，這個容器系統內可以部署多個應用節點。
-
節點：實現了微服務的輕耦合節點（應用）。
當然，理解這些是不夠的架構設計的，我們還需要了解整個日誌收集中的每個流程：
-
日誌選擇：確定哪些日誌型別需要進行收集分析，比如除錯，網路等等型別。
-
日誌採集：使用哪種日誌元件來作為採集，.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且開源
