前言
上一節對日誌的部分核心型別進行簡單的剖析，相信現在再使用日誌的時候，應該大概知道怎麼一回事了，比如記錄器是怎麼來的，是如何將日誌內容寫入到不同目的地的等；當然還有很多細節沒深入講解，抽時間小夥伴們可以去研究研究；廢話不多說，接下來主要舉例演示日誌作用域及第三方日誌框架的擴充套件；
正文
說到日誌作用域，相信很多小夥伴聽著不是那麼熟悉吧，之前進行日誌記錄時候，是不是把內容記錄下來就完事了，最多就是再稍微格式化一下；如果是這樣，那在排查問題的時候肯定差不多是這樣：一點一點的扒日誌，然後根據關鍵詞找大概地方，再根據時間和內容定位排錯，更讓人頭大的是哪些日誌是在同一個業務中產生的，哪些日誌是在同一個請求中記錄的等等一系列煩惱；對於複雜的流程日誌關聯時扒日誌就更需要靠眼力了；
而日誌作用域可以輔助排查和定位，所謂日誌作用域，我是這麼理解的，就是將日誌記錄畫一個範圍，對應的業務邏輯記錄在指定的範圍內，這樣在排查業務邏輯的時候就減少對業務日誌的歸屬分辨，從而快速定位對應請求或業務的相關日誌內容；別那麼多廢話，上例子......
來吧，一個WebAPI專案走起...
執行，然後嗖嗖嗖嗖按F5重新整理幾次，如下：
懵了吧，很難辨別出哪些日誌內容是同一個請求記錄的吧，那排錯分析就更加模糊了，就算日誌加一些特殊的關鍵字區分，那排查效率也不高，對吧；其實對於請求而言，框架內部已經實現了，只需要配置開啟即可:
其他不動，執行專案，然後嗖嗖嗖嗖按F5重新整理幾次，如下：
咋多了那麼東西，每一次記錄，都把對應的請求ID等資訊帶上了，可以清楚的看到日誌是哪個請求的，其他資訊而對於日誌分析框架來說是很有用的；以上只是舉例控制檯輸出案例，其他目的地也可以進行配置；
到這裡肯定會有小夥伴問，那我一次請求裡面有多個業務，咋區分呢？那先來稍微改一下程式碼，增加了一個Action方法：
執行，再重新整理
通過BeginScope可以開啟一個新的記錄作用域，根據對應業務進行記錄即可；這裡的原始碼實現就不具體說了，上一節簡單提了一下，如果需要詳細研究，可以私下繼續看看原始碼；
由於框架本身內建的日誌記錄，有時候滿足不了專案需求，比如需要將日誌內容寫入到其他目的地，日誌內容格式需自定義等，當然這些通過自己也可以實現，只要實現核心型別即可；但是成熟的第三方框架已經很多了，如NLog，Log4Net,Serilog等，別人已經把輪子造好了，我們們直接拿來用豈不美哉；
由於之前在部落格裡寫過一篇整合Log4Net的文章(去部落格園吧https://www.cnblogs.com/zoe-zyq/p/12900636.html)，這裡就舉例演示一下整合Serilog吧，三步走：
-
安裝依賴包；
-
配置檔案；
其實可以單獨做一個檔案配置，但這裡和appsettings寫在一塊了；
-
程式碼編寫；
其他邏輯不用變，原來記錄日誌的方式已經委託給Serilog框架進行日誌記錄了；
以上只是對Serilog簡單的配置和使用，如需詳細瞭解，請進入官網https://github.com/serilog/serilog/wiki/Configuration-Basics，文件很全，說的也很詳細；
總結
對於日誌的使用就簡單說到這吧，這節說的內容不多，也比較簡單，但有以下幾個建議：
-
日誌最好結構化儲存，便於檢索和分析；
-
日誌針對負責複雜即又關鍵的業務，最好加上作用域標識；
-
日誌記錄時避免記錄敏感資訊；
-
日誌記錄時推薦以模板的形式進行記錄；
// 模板形式，推薦 _logger.LogInformation("TestLogger {content}", DateTime.Now); // 不推薦 _logger.LogInformation($"TestLogger {DateTime.Now}", DateTime.Now)
下一節說說中介軟體~~~
------------------------------------------------
一個被程式搞醜的帥小夥，關注"Code綜藝圈"，識別關注跟我一起學~~~
