.net core 微服務之日誌落盤設計

時間 2019-12-01

標籤 core 微服日誌設計简体版

原文原文鏈接

原文: .net core 微服務之日誌落盤設計

一、設計目標

對各個微服務的訪問進行請求追蹤，注重排查開發、線上問題
消息隊列發送、多服務落盤，過後分析
日誌分析
性能優化

二、日誌流程

三、串聯請求事務

3.1 請求ID

請求id：惟一標識一個Api請求鏈路。css

爲了分析前端的一條Api請求，須要在Api網關請求時產生一個guid，標識api的請求，並按照調用次序傳遞給微服務，微服務間能夠互相調用，所以請求id按照調用次序依次傳遞。前端

3.2 處理服務器、服務

請求鏈路會穿越不一樣的服務器以及不一樣的服務，所以，須要記錄服務器的IP或名稱，服務的名稱，這樣在分析問題時能夠快速找到故障點。git

3.3 處理接口名

api的入口是惟一接口，但穿越不一樣節點後，實際執行接口會隨着調用而改變，所以接口名須要被記錄下來。github

3.4 日誌的發生時間

可提供時間索引，可按照時間進行分區分表等web

3.5 接口返回狀態碼

狀態碼簡單判斷接口是否工做正常，有無錯誤，錯誤描述等api

四、記錄結構

五、RabbitMq隊列

六、落盤

日誌落盤採用RabbitMq的拉模式，考慮到日誌的規模，若是採用推模式，極可能致使落盤阻塞，所以這裏採用拉取模式，以落盤介質的流速爲限制。
落盤能夠採用多個微服務進行拉取，這樣能夠保證某個落盤服務故障後，仍然能夠繼續落盤。
落盤採用一個線程拉取隊列，並存儲在內存隊列中，三個不一樣的落庫線程，從內存隊列中拉取並落庫。性能優化

public static void Init()
        {
            _event = new AutoResetEvent(false);
            _queue = new ConcurrentQueue<LogBase>();

            new Thread(SaveLogInfo){IsBackground = true}.Start();
            new Thread(SaveLogStat) { IsBackground = true }.Start();
            new Thread(SaveLogBussiness) { IsBackground = true }.Start();
            new Thread(SaveLogToDb) { IsBackground = true }.Start();
        }