ASP.NET Core中的日志记录是什么？如何配置？

小老鼠

发布时间：2025-09-21 09:55:01

265人浏览过

来源于php中文网

原创

答案：ASP.NET Core日志通过配置级别和结构化输出实现高效监控与排查，生产环境推荐使用Information及以上级别，结合Serilog等工具实现集中式、结构化、异步日志记录，并避免记录敏感信息以确保安全。

asp.net core中的日志记录是什么？如何配置？

ASP.NET Core中的日志记录，简单来说，就是应用程序在运行过程中，把各种事件（比如请求进入、错误发生、数据处理、甚至调试信息）以结构化的方式记录下来。这就像是给你的应用装了一个“黑匣子”，无论是在开发调试、生产环境监控，还是事后问题排查，它都是不可或缺的眼睛和耳朵。配置它，主要是通过

appsettings.json

文件和代码中的

ILoggerFactory

或

ILogger

接口来控制日志的输出目的地、级别和格式。我个人觉得，一套好的日志系统，是应用可观测性的基石，没有它，你就像在黑暗中驾驶，完全不知道哪里出了问题。

ASP.NET Core提供了一个强大且可扩展的日志框架。要配置它，我们通常会从

appsettings.json

文件入手，因为这是最直观且无需重新编译就能调整日志行为的方式。

首先，在

appsettings.json

中，你可以定义日志的默认级别和特定类别的级别。这是一个典型的配置示例：

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning",
      "System": "Warning"
    },
    "Console": {
      "IncludeScopes": true
    },
    "Debug": {
      "IncludeScopes": false
    }
  },
  "AllowedHosts": "*"
}

这里，

Default

设置为

Information

，意味着所有未明确指定类别的日志，默认都会记录

Information

及以上级别的消息。而

Microsoft.AspNetCore

和

System

命名空间下的日志，我们将其级别提高到

Warning

，这是为了减少框架内部的噪音，只关注那些更重要的信息。这在生产环境中特别有用，可以避免日志文件过大。

在代码层面，ASP.NET Core通过依赖注入来提供日志服务。你只需要在需要记录日志的类中，通过构造函数注入

ILogger

接口即可。这里的

通常是当前类的类型，这样日志输出时就会自动带上这个类的全名，方便追踪。

using Microsoft.Extensions.Logging;

public class MyService
{
    private readonly ILogger _logger;

    public MyService(ILogger logger)
    {
        _logger = logger;
    }

    public void DoSomething(int value)
    {
        _logger.LogInformation("Doing something with value: {Value}", value);

        try
        {
            if (value < 0)
            {
                throw new ArgumentOutOfRangeException(nameof(value), "Value cannot be negative.");
            }
            // ... some logic
        }
        catch (Exception ex)
        {
            _logger.LogError(ex, "An error occurred while doing something with value: {Value}", value);
        }

        _logger.LogDebug("Finished doing something.");
    }
}

在

Program.cs

（对于.NET 6+）或

Startup.cs

（对于旧版本）中，ASP.NET Core默认已经集成了Console、Debug和EventSource日志提供程序。如果你需要自定义或添加其他提供程序（比如文件日志、数据库日志、云服务日志），可以在

Host.CreateDefaultBuilder

之后，通过

ConfigureLogging

方法进行扩展：

// Program.cs for .NET 6+
var builder = WebApplication.CreateBuilder(args);

builder.Logging.ClearProviders(); // 可以选择清除默认提供程序
builder.Logging.AddConsole(); // 添加控制台日志
builder.Logging.AddDebug();   // 添加调试输出日志
// builder.Logging.AddFile("logs/myapp-{Date}.txt"); // 假设你安装了文件日志扩展

// ... 其他服务配置

var app = builder.Build();

通过这种方式，我们能够灵活地控制日志的去向和详细程度，让日志真正成为我们理解和维护应用程序的有力工具。

ASP.NET Core中，日志级别（LogLevel）的选择对应用性能和问题排查有何影响？

日志级别，就像是控制信息流量的阀门。ASP.NET Core定义了几个标准的日志级别：

Trace

、

Debug

、

Information

、

Warning

、

Error

、

Critical

和

None

。选择合适的日志级别，在我看来，是日志配置中最需要权衡的艺术。

Trace (跟踪)：这是最详细的级别，通常用于在开发阶段对代码路径进行细致跟踪。它会记录非常多的信息，包括方法进入/退出、变量值等。在生产环境中启用
```
Trace
```
级别几乎是灾难性的，它会产生巨大的日志量，严重影响应用性能（大量的I/O操作和字符串格式化），并快速耗尽存储空间。调试时，它能提供无与伦比的细节，帮助你精确地定位问题。
Debug (调试)：比
```
Trace
```
稍高一级，仍然包含足够多的细节，用于开发和调试。比如，请求的详细参数、中间件的执行步骤等。在开发环境，我经常将其设置为默认级别，因为它提供了足够的信息而不会像
```
Trace
```
那样过于冗余。在生产环境，通常不会启用，因为它依然会产生大量日志。
Information (信息)：这是默认且推荐的生产环境日志级别。它记录应用程序的正常运行状态和重要事件，例如请求的开始与结束、服务启动、用户登录、关键业务流程的完成等。这个级别的信息量适中，既能让我们了解应用的健康状况，又不会对性能造成过大负担。它对于监控和理解系统行为至关重要。
Warning (警告)：表示应用程序可能存在问题，但通常不会导致应用程序崩溃。例如，配置项缺失、某个操作未能按预期完成但有回退机制、资源即将耗尽等。
```
Warning
```
级别的日志是生产环境中需要重点关注的，它往往是潜在问题的早期预警。
Error (错误)：表示应用程序在执行过程中发生了错误，通常是由于意外情况导致某个操作失败，但应用程序可能仍然可以继续运行。例如，数据库连接失败、外部API调用失败、业务逻辑中的异常。
```
Error
```
日志是排查问题时的核心依据，需要立即关注并处理。
Critical (严重)：最高级别的错误，表示应用程序发生了灾难性的故障，导致整个应用程序或关键功能无法继续运行。例如，内存溢出、服务崩溃、不可恢复的配置错误。这类错误通常需要紧急干预。
None (无)：不记录任何日志。这在某些非常特殊的场景下可能有用，但通常不推荐，因为这意味着你对应用程序的运行状态一无所知。

对性能的影响： 日志级别越低（如

Trace

、

Debug

），产生的日志量越大，对性能的影响也越大。日志记录涉及到字符串格式化、I/O操作（写入文件、发送到网络）、甚至序列化等。这些操作都需要CPU和内存资源。在生产环境中，将不必要的详细日志级别调高（例如，

Default

设置为

Information

，

Microsoft.AspNetCore

设置为

Warning

），可以显著减少日志量，从而降低性能开销。

对问题排查的影响： 详细的日志（如

Debug

、

Trace

）在开发和测试阶段是无价之宝，它们能提供丰富的上下文，帮助开发者迅速定位问题。然而，在生产环境中，过多的日志反而可能淹没真正有用的信息，使得排查变得困难。因此，生产环境的日志策略是：记录足够的信息以诊断问题，但又不能过多导致性能下降或信息泛滥。通常，

Information

、

Warning

、

Error

和

Critical

是生产环境的黄金组合。当出现问题时，可以临时调低某个特定组件的日志级别，以获取更详细的诊断信息。

除了内置日志，如何在ASP.NET Core中集成Serilog等第三方日志框架？

虽然ASP.NET Core内置的日志系统功能完备，但在实际生产环境中，我发现许多团队更倾向于使用Serilog、NLog或Log4net等第三方日志框架。这并非内置系统不好，而是这些第三方框架往往提供了更丰富的日志接收器（Sinks）、更强大的结构化日志能力、更灵活的配置方式，以及更成熟的生态系统。这里，我以Serilog为例，因为它在.NET社区中非常流行，并且与ASP.NET Core的集成也做得很好。

为什么选择Serilog？ 我个人非常推崇Serilog的结构化日志能力。它能将日志事件记录为可查询的JSON或其他格式，而不是简单的文本字符串。这意味着你可以轻松地在Elasticsearch、Splunk等日志分析工具中进行复杂的查询、聚合和可视化，极大地提升了日志的价值。同时，Serilog提供了海量的Sinks（例如，文件、数据库、Kafka、各种云服务），几乎可以满足所有日志输出的需求。

集成步骤：

安装NuGet包： 你需要安装Serilog的核心包以及你需要的Sinks和ASP.NET Core集成包。通常，这些是：
- ```
Serilog.AspNetCore
```
  ：用于将Serilog集成到ASP.NET Core的日志管道中。
- ```
Serilog.Sinks.Console
```
  ：将日志输出到控制台。
- ```
Serilog.Sinks.File
```
  ：将日志输出到文件。
- ```
Serilog.Settings.Configuration
```
  ：允许通过
```
appsettings.json
```
  配置Serilog。
```
dotnet add package Serilog.AspNetCore
dotnet add package Serilog.Sinks.Console
dotnet add package Serilog.Sinks.File
dotnet add package Serilog.Settings.Configuration
```

配置Serilog： 最常见的配置方式是在

Program.cs

中进行初始化，并通过

appsettings.json

来管理其行为。

appsettings.json

配置示例：

多墨智能

多墨智能 - AI 驱动的创意工作流写作工具

下载

{
  "Serilog": {
    "MinimumLevel": {
      "Default": "Information",
      "Override": {
        "Microsoft": "Warning",
        "System": "Warning"
      }
    },
    "Using": [ "Serilog.Sinks.Console", "Serilog.Sinks.File" ], // 声明使用的Sinks
    "WriteTo": [
      {
        "Name": "Console",
        "Args": {
          "outputTemplate": "[{Timestamp:HH:mm:ss} {Level:u3}] {Message:lj}{NewLine}{Exception}"
        }
      },
      {
        "Name": "File",
        "Args": {
          "path": "logs/log-.txt",
          "rollingInterval": "Day",
          "formatter": "Serilog.Formatting.Compact.CompactJsonFormatter, Serilog.Formatting.Compact" // 结构化JSON格式
        }
      }
    ],
    "Enrich": [ "FromLogContext", "WithMachineName", "WithProcessId", "WithThreadId" ], // 添加额外上下文
    "Properties": {
      "Application": "MyAspNetCoreApp"
    }
  }
}

这个配置告诉Serilog：

默认日志级别是
```
Information
```
，但覆盖
```
Microsoft
```
和
```
System
```
命名空间为
```
Warning
```
。
使用
```
Console
```
和
```
File
```
两个Sink。
```
Console
```
Sink使用自定义的文本模板。
```
File
```
Sink每天滚动生成文件，并使用紧凑的JSON格式（这对于日志分析工具非常友好）。
自动丰富日志上下文，添加机器名、进程ID、线程ID，并给所有日志打上
```
Application: MyAspNetCoreApp
```
的标签。

Program.cs

集成： 在.NET 6+的

Program.cs

中，你需要修改

WebApplication.CreateBuilder(args)

的构建过程。

using Serilog;
using Microsoft.Extensions.Hosting;

try
{
    var builder = WebApplication.CreateBuilder(args);

    // 从appsettings.json加载Serilog配置
    builder.Host.UseSerilog((context, services, configuration) => configuration
        .ReadFrom.Configuration(context.Configuration)
        .ReadFrom.Services(services)
        .Enrich.FromLogContext());

    // ... 其他服务配置

    var app = builder.Build();

    // ... 中间件配置

    app.Run();
}
catch (Exception ex)
{
    // 捕获主机启动前的异常，记录到静态Logger（如果已配置）
    Log.Fatal(ex, "Host terminated unexpectedly");
}
finally
{
    Log.CloseAndFlush(); // 确保所有缓冲的日志都被写入
}

通过

builder.Host.UseSerilog(...)

，我们将Serilog作为ASP.NET Core的日志提供程序。

ReadFrom.Configuration

让Serilog从

appsettings.json

读取配置，

ReadFrom.Services

允许Serilog访问DI容器中的服务（例如，用于一些高级Sinks）。

Enrich.FromLogContext()

则允许我们通过

LogContext

在代码中动态添加日志属性。

使用Serilog记录日志： 一旦集成完成，你就可以像使用内置

ILogger

一样使用Serilog了，因为Serilog已经替换了底层的日志实现。

using Microsoft.Extensions.Logging; // 仍然使用这个接口

public class MyController : ControllerBase
{
    private readonly ILogger _logger;

    public MyController(ILogger logger)
    {
        _logger = logger;
    }

    [HttpGet]
    public IActionResult Get()
    {
        _logger.LogInformation("Received a GET request.");
        // Serilog会自动捕获这里的属性，比如UserId，并以结构化方式记录
        _logger.LogInformation("User {UserId} accessed resource {ResourceName}", 123, "Home");
        return Ok();
    }
}

Serilog的强大之处在于，当你使用带参数的日志方法时（如

LogInformation("User {UserId} accessed {ResourceName}", userId, resourceName)

），它会将

UserId

和

ResourceName

作为独立的属性记录下来，而不是简单地格式化成字符串。这对于后续的日志分析和查询非常有用。

在生产环境中，ASP.NET Core日志记录有哪些最佳实践和安全考量？

在生产环境，日志记录不仅仅是“记录下来”那么简单，它是一项严肃的工程，直接关系到应用的可维护性、性能和安全性。我见过太多因为日志策略不当而导致的问题，比如日志文件撑爆硬盘、敏感信息泄露、或者关键时刻找不到有用日志。

最佳实践：

结构化日志 (Structured Logging)： 这是生产环境日志的黄金标准。避免只记录纯文本字符串。使用JSON或其他机器可读的格式来记录日志事件，将事件属性（如时间戳、级别、消息模板、请求ID、用户ID、方法名、参数等）作为独立的字段。Serilog在这方面做得非常出色。结构化日志使得日志更容易被日志分析工具（如ELK Stack、Splunk、Azure Monitor）解析、查询和聚合。
异步日志 (Asynchronous Logging)： 日志写入操作（特别是写入文件或网络）是I/O密集型操作，可能会阻塞应用程序的主线程，从而影响性能。使用异步日志可以把日志写入操作放到后台线程进行，减少对应用程序响应时间的影响。大多数成熟的日志框架（包括Serilog的Sinks）都支持异步写入。
合理的日志级别： 如前所述，生产环境不应开启
```
Trace
```
或
```
Debug
```
级别。通常，
```
Information
```
、
```
Warning
```
、
```
Error
```
和
```
Critical
```
是合适的选择。对于框架自带的日志（如
```
Microsoft.AspNetCore
```
），通常将其级别设置为
```
Warning
```
或
```
Error
```
，以减少噪音。我通常会有一个默认的
```
Information
```
级别，然后针对特别吵闹的命名空间进行
```
Override
```
。
集中式日志系统 (Centralized Logging)： 当你的应用部署在多台服务器上时，本地日志文件会变得难以管理和查询。将所有应用的日志汇集到一个集中式日志系统（如ELK Stack、Grafana Loki、Splunk、Azure Monitor、AWS CloudWatch Logs）是必不可少的。这能让你在一个地方搜索所有服务的日志，进行关联分析，并构建仪表板来监控应用健康状况。
上下文信息 (Contextual Logging)： 仅仅记录“发生了一个错误”是不够的。日志应该包含足够的上下文信息，以便你能够重现问题或理解其发生的原因。例如，在Web应用中，为每个请求生成一个唯一的
```
CorrelationId
```
，并将其添加到所有相关日志事件中。这样，你可以根据这个ID追踪一个请求在整个系统中的生命周期。其他有用的上下文信息包括用户ID、会话ID、操作名称、业务实体ID等。Serilog的
```
LogContext
```
功能对此非常有帮助。
错误处理与异常日志： 确保所有未捕获的异常都能被记录下来，并且捕获的异常也应以适当的级别记录，包含完整的堆栈跟踪信息。使用
```
_logger.LogError(ex, "...")
```
这样的方法，可以确保异常对象本身也被记录下来，而不是仅仅记录异常消息。
日志轮转与保留策略 (Log Rotation & Retention)： 日志文件会不断增长，如果不加管理，很快就会耗尽磁盘空间。配置日志轮转策略（按时间或大小分割文件）和保留策略（定期删除旧日志）至关重要。集中式日志系统通常也提供这些功能。

安全考量：

绝不记录敏感数据： 这是最关键的一点。永远不要在日志中直接记录用户的密码、信用卡号、社会安全号（SSN）、个人身份信息（PII）、API密钥、令牌等敏感数据。即使是在开发环境，也应该避免这种习惯。一旦日志系统被攻破，这些数据就会完全暴露。
数据脱敏/匿名化： 如果确实需要在日志中包含一些与敏感数据相关的信息（例如，用户ID或订单号），请确保这些数据已经过脱敏处理，或者转换为无法反向推导的匿名形式。例如，可以记录用户ID的哈希值，而不是原始ID。
日志访问控制： 确保只有授权人员才能访问日志文件或集中式日志系统。日志中可能包含应用程序内部的运行细节，甚至是业务逻辑的敏感信息，如果落入恶意之手，可能被用于攻击。对日志系统的访问权限应遵循最小权限原则。
审计日志 (Audit Logging)： 对于涉及安全或合规性要求的关键操作（如用户登录失败、权限变更、数据导出等），应记录专门的审计日志。审计日志通常需要更高级别的保护，更长的保留期限，并且内容应清晰、不可篡改，以便事后追溯。
防止日志注入： 小心用户输入直接进入日志消息。恶意用户可能会通过在输入中插入换行符或特殊字符来“注入”伪造的日志条目，从而混淆或掩盖真实的日志信息。使用日志框架提供的参数化日志方法（如
```
_logger.LogInformation("User input: {Input}", userInput)
```
）可以有效防止这类问题，因为框架会正确处理这些参数，而不是简单地拼接字符串。