一、引言
.Net技術棧目前還沒有像spring cloud相對完整一整微服務架構棧，隨着業務發展系統架構演進，自行構建.Net技術體系的微服務架構，配套相關核心組件。因平臺基於微服務架構方式研發，每個領域服務遵循平臺統一標準，各自研發，獨立部署運行，服務運行日誌均通過記錄本地文件方式進行記錄。程序日誌無法及時查閱，需登錄服務器查看，同時不利於日誌統一管理，因研發運行日誌分析系統，進行日誌統一分析管理，便於快速定位程序運行問題及時處理，保障平臺運行穩定。雖然行業上也有一些日誌架構，如較爲有名的LEK（logstash, elasticsearch, kibana），因考慮到後續一些個性化的需求，還是自行研發運行日誌分析系統。
二、設計原則
系統在總體微服務架構設計思想下，遵守平臺標準，並結合實際解決問題的需要，進行設計和研發，系統嚴格按照如下設計原則設計：
1、模塊化：根據職責和歸屬明確，進行拆分模塊，模塊功能高度內聚。
2、服務化：各模塊通信，通過服務方式進行調用，服務之間通信，遵守平臺的標準。
3、鬆耦合：系統模塊之間通信，基於行業通用標準，按照“約定優於配置”思想，充分體現系統模塊之間鬆耦合的關係。
4、高性能：採用異步的方式進行記錄日誌和分析，不影響平臺總體性能。
5、易擴展：日誌採用統一的接入方式，支持靈活擴展。
6、跨平臺：支持不同技術語言、平臺進行採集日誌。
三、總體架構
圖- 運行日誌分析系統總體架構示意圖
如圖所示，系統基於上述設計原則，主要由五部分組成：日誌記錄、日誌採集、日誌接入、日誌分析及存儲、日誌管理服務。每部分職責定位明確，相互支持、相互協作，共同構成運行日誌分析系統。日誌記錄到本地文件，通過日誌採集器將本地日誌文件抽取後，發送至Kafka，同時由日誌分析服務進行消費、分析及存儲於elasticsearch，日誌管理服務提供於用戶查閱&分析日誌信息。在平臺統一通信協議下，擴展運行日誌的內容，沿用Json報文格式，記錄內容包括：IP、端口、服務ID、記錄時間、日誌內容。
1、日誌報文
2、日誌記錄
日子記錄，支持多種日誌記錄組件：Log4.net（本系統選用）、.Net core 自帶的Nlog、微軟企業庫等，針對JAVA技術語言開發的服務，則選用log4j組件，只要按照約定規範進行打印日誌即可。將日誌信息記錄到本地文件。
3、日誌採集
日誌採集，選用filebeat組件，filebeat是一個輕量級的日誌傳輸組件，其可以通過提供一種輕量級的方式來轉發和集中日誌和文件，幫助你把簡單採集和發送的事情簡單化。本質上filebeat是一個日誌信息搬運工，不進行日誌過濾和分析工作。同時支持跨平臺。
4、日誌接入
日誌接入，考慮日誌量在某一故障情況，可能存在較大併發接入，所以選用Kafka組件作爲日誌信息接入分析的統一入口，kafka組件是一個高性能的MQ組件，具有高併發、高可用的特性。統一接入方案，爲系統提供更爲靈活的採集日誌，不受限於某一平臺、技術或者日誌採集組件，均可將運行日誌進行接入分析和存儲。
5、日誌分析及儲存
日誌分析，採用.Net Core研發，以後臺服務的方式進行運行，訂閱kafka的日誌消息進行批量消費，分析程序支持橫向擴展部署於多個程序，提升日誌的消費能力，保障日誌接收能力和分析能力相當。對日誌分析後存儲於Elasticsearch（以下簡稱：ES），ES是一個高可擴展的開源全文搜索和分析引擎，它允許存儲、搜索和分析大量的數據。非常適合存儲半結構化的日誌數據，便於全文搜索日誌信息。
6、日誌管理服務
日誌管理服務，實現查詢ES中的運行日誌數據，通過WebAPI方式提供界面功能調用。本系統採用“前後分離”應用開發技術，前端界面功能採用H5+JS，後端服務以restful方式提供API接口。
四、總結
根據不同應用場景和需求，選用不同的日誌分析架構或者自行研發，最終目的就是爲了快速、方便捕捉系統日誌，有助於分析系統運行情況。尤其對於微服務架構大型平臺，運行日誌更爲重要。本文主要是將系統設計原則、思想進行記錄，同時對有需要的同學提供參考，可能再實際應用中，還有很多地方需要完善或者優化。