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