答案：ASP.NET Core日志通过配置级别和结构化输出实现高效监控与排查，生产环境推荐使用Information及以上级别，结合Serilog等工具实现集中式、结构化、异步日志记录，并避免记录敏感信息以确保安全。
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
接口即可。这里的
T
通常是当前类的类型，这样日志输出时就会自动带上这个类的全名，方便追踪。
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.AspNetCoredotnet add package Serilog.Sinks.Consoledotnet add package Serilog.Sinks.Filedotnet add package Serilog.Settings.Configuration
配置Serilog：最常见的配置方式是在
Program.cs
中进行初始化，并通过
appsettings.json
来管理其行为。
a.
appsettings.json
配置示例：
{ "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
的标签。
b.
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)
）可以有效防止这类问题，因为框架会正确处理这些参数，而不是简单地拼接字符串。
日志记录是应用程序健康和安全的重要组成部分。投入时间和精力来设计和实现一个健壮的日志策略，绝对是一笔划算的投资。
以上就是ASP.NET Core中的日志记录是什么？如何配置？的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1439805.html
微信扫一扫 
支付宝扫一扫 
