如何利用Serilog的RequestLogging來精簡ASP.NET Core的日誌輸出

来源:https://www.cnblogs.com/yilezhu/archive/2020/01/20/12215934.html

這是該系列的第一篇文章:在ASP.NET Core 3.0中使用Serilog.AspNetCore。 1. 第1部分 使用 來簡化ASP.NET Core的日誌輸出(本篇文章) 2. 第2部分 使用Serilog記錄所選的端點名稱[敬請期待] 3. 第3部分 使用Serilog.AspNetCor ...


這是該系列的第一篇文章:在ASP.NET Core 3.0中使用Serilog.AspNetCore。

  1. 第1部分-使用Serilog RequestLogging來簡化ASP.NET Core的日誌輸出(本篇文章)
  2. 第2部分-使用Serilog記錄所選的端點名稱[敬請期待]
  3. 第3部分-使用Serilog.AspNetCore記錄MVC屬性[敬請期待]

作者:依樂祝

譯文地址:https://www.cnblogs.com/yilezhu/p/12215934.html

原文地址:https://andrewlock.net/using-serilog-aspnetcore-in-asp-net-core-3-reducing-log-verbosity/

眾所周知,ASP.NET Core的重要改變之一是把日誌記錄內置於框架中。這意味著您可以(如果需要)從自己的標準日誌基礎設施訪問所有深層基礎設施日誌。缺點是有時您會收到太多的日誌。

在這個簡短的系列文章中,我將介紹如何使用Serilog的ASP.NET Core請求日誌記錄功能。在第一篇文章中,我將講述如何將Serilog的RequestLoggingMiddleware添加到您的應用程式,以及它提供的好處。在後續文章中,我將描述如何進一步自定義行為。

我已經將這些帖子草擬了一段時間。從那時起,Serilog的創建者Nicholas Blumhardt就在ASP.NET Core 3.0中使用Serilog撰寫了一篇詳盡的博客文章。這是一篇非常詳細(至少我認為是這樣)的文章,我強烈建議您閱讀。您可以在他的文章中找到我在本系列文章中談論的大部分內容,所以請查看!

原生請求日誌

在本節中,首先讓我們創建一個標準的ASP.NET Core 3.0的Razor pages應用,當然你也可以直接使用dotnet new webapp命令來進行創建。這將創建一個標準Program.cs,如下所示:

 public class Program
    {
        public static void Main(string[] args)
        {
            CreateHostBuilder(args).Build().Run();
        }

        public static IHostBuilder CreateHostBuilder(string[] args) =>
            Host.CreateDefaultBuilder(args)
                .ConfigureWebHostDefaults(webBuilder =>
                {
                    webBuilder.UseStartup<Startup>();
                });
    }

還有一個Startup.cs,用於配置中間件管道,Configure如下所示:

 public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
        {
            if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
            }
            else
            {
                app.UseExceptionHandler("/Error");
                // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
                app.UseHsts();
            }

            app.UseHttpsRedirection();
            app.UseStaticFiles();

            app.UseRouting();

            app.UseAuthorization();

            app.UseEndpoints(endpoints =>
            {
                endpoints.MapRazorPages();
            });
        }

如果您運行該應用程式並導航至主頁,則預設情況下,您會在控制臺中看到每個請求都會產生許多的日誌。以下日誌是針對對主頁的單個請求生成的(此後我還沒有包括對CSS和JS文件的其他請求)(這是是開發環境請求出現的日誌):

info: Microsoft.AspNetCore.Hosting.Diagnostics[1]
      Request starting HTTP/2 GET https://localhost:5001/
info: Microsoft.AspNetCore.Routing.EndpointMiddleware[0]
      Executing endpoint '/Index'
info: Microsoft.AspNetCore.Mvc.RazorPages.Infrastructure.PageActionInvoker[3]
      Route matched with {page = "/Index"}. Executing page /Index
info: Microsoft.AspNetCore.Mvc.RazorPages.Infrastructure.PageActionInvoker[101]
      Executing handler method SerilogRequestLogging.Pages.IndexModel.OnGet - ModelState is Valid
info: Microsoft.AspNetCore.Mvc.RazorPages.Infrastructure.PageActionInvoker[102]
      Executed handler method OnGet, returned result .
info: Microsoft.AspNetCore.Mvc.RazorPages.Infrastructure.PageActionInvoker[103]
      Executing an implicit handler method - ModelState is Valid
info: Microsoft.AspNetCore.Mvc.RazorPages.Infrastructure.PageActionInvoker[104]
      Executed an implicit handler method, returned result Microsoft.AspNetCore.Mvc.RazorPages.PageResult.
info: Microsoft.AspNetCore.Mvc.RazorPages.Infrastructure.PageActionInvoker[4]
      Executed page /Index in 221.07510000000002ms
info: Microsoft.AspNetCore.Routing.EndpointMiddleware[1]
      Executed endpoint '/Index'
info: Microsoft.AspNetCore.Hosting.Diagnostics[2]
      Request finished in 430.9383ms 200 text/html; charset=utf-8

單個請求就是10條日誌。現在,很清楚,它正在Development環境中運行,該環境預設情況下將Microsoft名稱空間中的所有信息記錄在“Information”或更高的級別。如果我們切換到Production環境,則預設模板會將Microsoft命名空間的日誌過濾到“Warning” 。現在導航到預設主頁會生成以下日誌(這裡註意,如果你現在使用ASP.NET Core3.1貌似Microsoft命名空間預設日誌級別已經改為Warning):

是的,根本沒有日誌!上一次運行中生成的所有日誌都位於Microsoft命名空間中,並且屬於“Information”級別,因此將它們全部過濾掉。就個人而言,我覺得這有點麻煩。如果生產版本僅僅只是想記錄一部分內容,而其他相關聯的內容則不進行記錄,這將會更有用的。

一種可能的解決方案是自定義應用於每個命名空間的過濾器。例如,您可以將Microsoft.AspNetCore.Mvc.RazorPages命名空間限製為“Warning”級別,而將更通用的Microsoft命名空間保留為“Information”級別。現在,您將獲得精簡後的日誌集:

info: Microsoft.AspNetCore.Hosting.Diagnostics[1]
      Request starting HTTP/2 GET https://localhost:5001/
info: Microsoft.AspNetCore.Routing.EndpointMiddleware[0]
      Executing endpoint '/Index'
info: Microsoft.AspNetCore.Routing.EndpointMiddleware[1]
      Executed endpoint '/Index'
info: Microsoft.AspNetCore.Hosting.Diagnostics[2]
      Request finished in 184.788ms 200 text/html; charset=utf-8

這些日誌中包含一些有用的信息-URL,HTTP方法,時間信息,端點等-並且沒有太多冗餘。但是,仍然令人討厭的是它們是四個單獨的日誌消息。(還是很多,如果能精簡成一條日誌記錄是不是會好很多)

這是Serilog RequestLoggingMiddleware旨在解決的問題-為請求中的每個步驟創建單獨的日誌相反,它是創建一個包含所有相關信息的“摘要”日誌消息。

將Serilog添加到應用程式

使用Serilog RequestLoggingMiddleware 的一個前提條件就是您正在使用Serilog!在本節中,我將介紹將Serilog添加到ASP.NET Core應用程式中。如果您已經安裝了Serilog,請跳至下一部分。

首先安裝Serilog.AspNetCore NuGet軟體包,再加上控制台和Seq接收器【這是一個漂亮的可視化日誌UI】,以便我們可以查看日誌。您可以通過運行以下命令從命令行執行此操作:

dotnet add package Serilog.AspNetCore
dotnet add package Serilog.Sinks.Seq

現在該用Serilog替換預設日誌了。您可以通過多種方式執行此操作,但是建議的方法是在Program.Main 執行其他任何操作之前先配置記錄器。這與ASP.NET Core通常使用的方法背道而馳,但建議用於Serilog。結當然這會導致您的的Program.cs文件變得更長:

// Additional required namespaces
using Serilog;
using Serilog.Events;

namespace SerilogDemo
{
    public class Program
    {
        public static void Main(string[] args)
        {
            // Create the Serilog logger, and configure the sinks
            Log.Logger = new LoggerConfiguration()
               .MinimumLevel.Debug()
               .MinimumLevel.Override("Microsoft", LogEventLevel.Information)
               .Enrich.FromLogContext()
               .WriteTo.Console()
               .WriteTo.Seq("http://localhost:5341")
               .CreateLogger();
            // Wrap creating and running the host in a try-catch block
            try
            {
                Log.Information("Starting host");
                CreateHostBuilder(args).Build().Run();
            }
            catch (Exception ex)
            {
                Log.Fatal(ex, "Host terminated unexpectedly");
            }
            finally
            {
                Log.CloseAndFlush();
            }
        }

        public static IHostBuilder CreateHostBuilder(string[] args) =>
            Host.CreateDefaultBuilder(args)
                .UseSerilog()
                .ConfigureWebHostDefaults(webBuilder =>
                {
                    webBuilder.UseStartup<Startup>();
                });
    }
}

儘管這樣設置可能顯得更為複雜,但是此設置可確保例如在appsettings.json文件格式錯誤或缺少配置文件的情況下仍會獲取日誌。如果現在運行您的應用程式,您將看到與我們最初相同的10條日誌,只是格式略有不同:

[13:30:27 INF] Request starting HTTP/2 GET https://localhost:5001/  
[13:30:27 INF] Executing endpoint '/Index'
[13:30:27 INF] Route matched with {page = "/Index"}. Executing page /Index
[13:30:27 INF] Executing handler method SerilogRequestLogging.Pages.IndexModel.OnGet - ModelState is Valid
[13:30:27 INF] Executed handler method OnGet, returned result .
[13:30:27 INF] Executing an implicit handler method - ModelState is Valid
[13:30:27 INF] Executed an implicit handler method, returned result Microsoft.AspNetCore.Mvc.RazorPages.PageResult.
[13:30:27 INF] Executed page /Index in 168.28470000000002ms
[13:30:27 INF] Executed endpoint '/Index'
[13:30:27 INF] Request finished in 297.0663ms 200 text/html; charset=utf-8

現在,通過在應用程式生命周期的早期進行配置,我們的日誌記錄配置的更加健壯,但實際上尚未解決我們提出的問題。為此,我們將添加RequestLoggingMiddleware

切換到Serilog的 RequestLoggingMiddleware

RequestLoggingMiddleware被包含在Serilog.AspNetCore中,可以被用於為每個請求添加一個單一的“摘要”日誌消息。如果您已經完成了上一節中的步驟,則添加這個中間件將變得很簡單。在您的Startup類中,在您想要記錄日誌的位置使用UseSerilogRequestLogging()進行調用:

// Additional required namespace
using Serilog;

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    // ... Error handling/HTTPS middleware
    app.UseStaticFiles();

    app.UseSerilogRequestLogging(); // <-- Add this line

    app.UseRouting();
    app.UseAuthorization();
    app.UseEndpoints(endpoints =>
    {
        endpoints.MapRazorPages();
    });
}

與ASP.NET Core的中間件管道一樣,順序很重要。當請求到達RequestLoggingMiddleware中間件時,它將啟動計時器,並將請求傳遞給後續中間件進行處理。當後面的中間件最終生成響應(或拋出異常),則響應通過中間件管道傳遞到請求記錄器,併在其中記錄了結果並寫入概要日誌信息。

Serilog只能記錄到達中間件的請求。在上面的例子中,我已經在StaticFilesMiddleware之後添加了RequestLoggingMiddleware 。因此如果請求被UseStaticFiles處理並使管道短路的話,日誌將不會被記錄。鑒於靜態文件中間件非常嘈雜,而且通常這是人們期望的行為(靜態文件進行短路,不需要進行記錄),但是如果您也希望記錄對靜態文件的請求,則可以在管道中serilog中間件移動到更早的位置。

如果我們再一次運行該應用程式,你還是會看到原來的10個日誌消息,但你會看到一個額外的通過SerilogRequestLoggingMiddleware彙總的日誌消息,倒數第二的消息:

# Standard logging from ASP.NET Core infrastructure
[14:15:44 INF] Request starting HTTP/2 GET https://localhost:5001/  
[14:15:44 INF] Executing endpoint '/Index'
[14:15:45 INF] Route matched with {page = "/Index"}. Executing page /Index
[14:15:45 INF] Executing handler method SerilogRequestLogging.Pages.IndexModel.OnGet - ModelState is Valid
[14:15:45 INF] Executed handler method OnGet, returned result .
[14:15:45 INF] Executing an implicit handler method - ModelState is Valid
[14:15:45 INF] Executed an implicit handler method, returned result Microsoft.AspNetCore.Mvc.RazorPages.PageResult.
[14:15:45 INF] Executed page /Index in 124.7462ms
[14:15:45 INF] Executed endpoint '/Index'

# Additional Log from Serilog
[14:15:45 INF] HTTP GET / responded 200 in 249.6985 ms

# Standard logging from ASP.NET Core infrastructure
[14:15:45 INF] Request finished in 274.283ms 200 text/html; charset=utf-8

關於此日誌,有幾點需要說明下:

  • 它在一條消息中包含您想要的大多數相關信息-HTTP方法,URL路徑,狀態代碼,持續時間。
  • 顯示的持續時間短於Kestrel在後續消息中記錄的值。這是可以預期的,因為Serilog僅在請求到達其中間件時才開始計時,而在返回時停止計時(在生成響應之後)。
  • 在這兩種情況下,使用結構日誌記錄時都會記錄其他值。例如,記錄了RequestId和SpanId(用於跟蹤功能),因為它們是日誌記錄範圍的一部分。您可以在登錄到seq的請求的以下圖像中看到這一點。
  • 預設情況下,我們確實會丟失一些信息。例如,不再記錄終結點名稱和Razor頁面處理程式。在後續文章中,我將展示如何將它們添加到摘要日誌中。
  • 如果想要通過``http://localhost:5341 訪問UI,你可能需要下載seq進行安裝。由於某種不知名的原因,可能下載會很慢。所以當然你也可以關註公眾號“DotNetCore實戰”然後回覆關鍵字“seq”獲取下載地址。

到Seq的RequestLoggingMiddleware日誌顯示結構化日誌包括其他屬性

完成整理工作所剩下的就是過濾掉我們當前正在記錄的信息級日誌消息。在Program.cs中更新Serilog配置以添加額外的過濾器:

Log.Logger = new LoggerConfiguration()
    .MinimumLevel.Debug()
    .MinimumLevel.Override("Microsoft", LogEventLevel.Information)
    // Filter out ASP.NET Core infrastructre logs that are Information and below
    .MinimumLevel.Override("Microsoft.AspNetCore", LogEventLevel.Warning) 
    .Enrich.FromLogContext()
    .WriteTo.Console()
    .WriteTo.Seq("http://localhost:5341")
    .CreateLogger();

通過最後的更改,您現在將獲得一組乾凈的請求日誌,其中包含每個請求的摘要數據:

[14:29:53 INF] HTTP GET / responded 200 in 129.9509 ms
[14:29:56 INF] HTTP GET /Privacy responded 200 in 10.0724 ms
[14:29:57 INF] HTTP GET / responded 200 in 3.3341 ms
[14:30:54 INF] HTTP GET /Missing responded 404 in 16.7119 ms

在下一篇文章中,我將介紹如何通過記錄其他數據來增強此日誌。

摘要

在本文中,我描述瞭如何使用Serilog.AspNetCore的請求日誌記錄中間件來減少為每個ASP.NET Core請求生成的日誌數,同時仍記錄摘要數據。如果您已經在使用Serilog,則非常容易啟用。只需在您的Startup.cs文件中調用UseSerilogRequestLogging()

當請求到達此中間件時,它將啟動計時器。當後續的中間件生成響應(或引發異常)時,響應將通過中間件管道返回到請求記錄器,記錄器記錄結果並編寫摘要日誌消息。

添加請求日誌記錄中間件之後,您可以過濾掉預設情況下在ASP.NET Core 3.0中生成的更多基礎結構日誌,而不會丟失有用的信息。


您的分享是我們最大的動力!

更多相關文章
  • linqtocsv文件有不太好的地方就是:無法設置標題的行數,預設首行就是標題,這不是很尷尬嗎? 並不是所有的csv文件嚴格寫的首行是標題,下麵全是數據,我接受的任務就是讀取很多.csv報表數據,裡面就有很多前幾行是說明性內容,下麵才是標題和數據。為了更好的解決這個問題,自己寫吧... 本博客沒有照 ...
  • 本筆記摘抄自:https://www.cnblogs.com/PatrickLiu/p/7723225.html,記錄一下學習過程以備後續查用。 一、引言 今天我們要講結構型設計模式的第三個模式--裝飾模式。當第一次看到這個名稱時想到的是另外一個詞語“裝修”,個人觀點談談對“裝修”的理解吧,請大家 ...
  • 在上一篇文章:《閃電光速拳? .NetCore 中的Span》中我們提到了在.net core 2.x 所新增的一個類型:Span。但是您會發現它無法用在我們項目的某些地方,它獨特的 ref結構 使它沒有辦法跨線程使用、更沒有辦法使用Lambda表達式。所以,這個時候如果我們又想跨線程操作數據又想獲... ...
  • 前言:想在.net framework環境使用自定義定時器的話,參考我的另一篇文章:https://www.cnblogs.com/lxhbky/p/10242839.html 想在.net core中使用定時器功能,需要藉助一個服務介面:IHostedService, 繼承並實現對應方法,最後再s ...
  • 要點 導出特性 如何導出Excel表頭 如何導出數據、如何進行數據的切割、如何使用篩選器 導出特性 ExporterAttribute + Name : 名稱(當前Sheet 名稱) + HeaderFontSize :頭部字體大小 + FontSize :正文字體大小 + MaxRowNumber ...
  • 你是否在初學 .net core時,被依賴註入所折磨? 你是否在開發過程中,為了註入依賴而不停的在Startup中增加註入代碼,而感到麻煩? 你是否考慮過或尋找過能輕鬆實現自動註入的組件? 如果有,那請歡迎繼續往下看。 或許你是被我這標題給吸引過來的,請不要懷疑自己的眼睛,如果你真的遇到過以上的問題 ...
  • 序言: 在 UWP 中,常見的存儲數據方式基本上就兩種。第一種方案是 UWP 框架提供的 ApplicationData Settings 這一系列的方法,適用於存放比較輕量的數據,例如存個 Boolean 類型的設置項這種是最適合不過的了。另一種方案是用 Sqlite 這種資料庫,適合存放數據量大 ...
  • 一、前言 在進行 Web 項目開發的過程中,可能會存在一些需要經常訪問的靜態數據,針對這種在程式運行過程中可能幾乎不會發生變化的數據,我們可以嘗試在程式運行前寫入到緩存中,這樣在系統後續使用時就可以直接從緩存中進行獲取,從而減緩因為頻繁讀取這些靜態數據造成的應用資料庫伺服器的巨大承載壓力。 既然需要 ...
一周排行
  • 1. 泛型Generic 1.1 引入泛型:延遲聲明 泛型方法聲明時,並未寫死類型,在調用的時候再指定類型。 延遲聲明:推遲一切可以推遲的。 1.2 如何聲明和使用泛型 泛型方法:方法名稱後面加上尖括弧,裡面是類型參數 類型參數實際上就是一個類型T聲明,方法就可以用這個類型T了。 如下所示: pub ...
  • 本筆記摘抄自:https://www.cnblogs.com/PatrickLiu/p/7903617.html,記錄一下學習過程以備後續查用。 一、引言 今天我們要講行為型設計模式的第三個模式--迭代器模式,先從名字上來看。迭代是遍歷的意思,迭代器可以理解為是遍歷某某的工具,遍歷什麼呢?在軟 件設 ...
  • 本筆記摘抄自:https://www.cnblogs.com/PatrickLiu/p/7928521.html,記錄一下學習過程以備後續查用。 一、引言 今天我們要講行為型設計模式的第四個模式--觀察者模式,先從名字上來看。觀察者模式可以理解為既然有“觀察者”,那肯定就有“被觀察者”了。“觀察者” ...
  • 先看核心代碼: public List<DataEntity> SearchShopSalesReport(DateTimeOffset? dateFrom, DateTimeOffset? dateTo,string groupBy) { var query = data.DataEntity / ...
  • 首先新建一個項目,名稱叫Caliburn.Micro.ActionConvertions 然後刪掉MainWindow.xaml 然後去app.xaml刪掉StartupUri這行代碼 其次,安裝Caliburn.Micro,Caliburn.Micro.Core,這兩個Nuget包,如下圖 然後新 ...
  • 一文帶你瞭解 C DLR 的世界 在很久之前,我寫了一片文章 "dynamic結合匿名類型 匿名對象傳參" ,裡面我以為DLR內部是用反射實現的。因為那時候是心中想當然的認為只有反射能夠在運行時解析對象的成員信息並調用成員方法。後來也是因為其他的事一直都沒有回過頭來把這一節知識給補上,正所謂亡羊補牢 ...
  • ​ 在C#8.0中,針對介面引入了一項新特性,就是可以指定預設實現,方便對已有實現進行擴展,也對面向Android和Swift的Api進行互操作提供了可能性。下麵我們來看看該特性的具體規則與實現。 一、主要應用場景: 在不破壞影響已有實現的情況下,可以添加新成員。這解決了在第三方已經大量使用了的介面 ...
  • 前言 通常在應用程式開發到正式上線,在這個過程中我們會分為多個階段,通常會有 開發、測試、以及正式環境等。每個環境的參數配置我們會使用不同的參數,因此呢,在ASP.NET Core中就提供了相關的環境API,方便我們更好的去做這些事情。 環境 ASP.NET Core使用ASPNETCORE_ENV ...
  • 擱置了幾天,工作忙的一塌糊塗,今天終於抽空來繼續看看MVC的知識。先來看看MVC的路由是如何處理的。以下為替代的路由: app.UseEndpoints(endpoints => { endpoints.MapControllerRoute( name: "default", pattern: "{ ...
  • 多用www.bing.com國際版解決代碼報錯 代碼運行的時候,報異常,國內的搜索引擎一搜, 浮誇的廣告太多,解決方案准確性不足, 盜版又很嚴重(導致一錯皆錯),方案未及時更新等詬病。 www.bing.com國際版可以關聯到: (1). 外國官網,可以獲得官方的解決方案。 (2). stackov ...
x