ASP.NET Core에 로그인Logging in ASP.NET Core

작성자: Steve SmithTom DykstraBy Steve Smith and Tom Dykstra

ASP.NET Core는 다양한 로깅 공급자를 사용하는 로깅 API를 지원합니다.ASP.NET Core supports a logging API that works with a variety of logging providers. 기본 공급자를 통해 하나 이상의 대상에 로그를 보낼 수 있으며, 타사 로깅 프레임워크를 연결할 수 있습니다.Built-in providers let you send logs to one or more destinations, and you can plug in a third-party logging framework. 이 문서에서는 코드에 기본 제공 로깅 API 및 공급자를 사용하는 방법을 보여 줍니다.This article shows how to use the built-in logging API and providers in your code.

IIS를 사용하여 호스트하는 경우의 stdout 로깅에 대한 내용은 IIS에서 ASP.NET Core 문제 해결를 참조하세요.For information on stdout logging when hosting with IIS, see IIS에서 ASP.NET Core 문제 해결. Azure App Service를 사용한 stdout 로깅에 대한 내용은 Azure App Service에서 ASP.NET Core 문제 해결를 참조하세요.For information on stdout logging with Azure App Service, see Azure App Service에서 ASP.NET Core 문제 해결.

로그를 만드는 방법How to create logs

로그를 만들려면 종속성 주입 컨테이너에서 ILogger<TCategoryName> 개체를 구현합니다.To create logs, implement an ILogger<TCategoryName> object from the dependency injection container:

public class TodoController : Controller
{
    private readonly ITodoRepository _todoRepository;
    private readonly ILogger _logger;

    public TodoController(ITodoRepository todoRepository,
        ILogger<TodoController> logger)
    {
        _todoRepository = todoRepository;
        _logger = logger;
    }

그런 다음 해당 로거 개체에 대해 로깅 메서드를 호출합니다.Then call logging methods on that logger object:

public IActionResult GetById(string id)
{
    _logger.LogInformation(LoggingEvents.GetItem, "Getting item {ID}", id);
    var item = _todoRepository.Find(id);
    if (item == null)
    {
        _logger.LogWarning(LoggingEvents.GetItemNotFound, "GetById({ID}) NOT FOUND", id);
        return NotFound();
    }
    return new ObjectResult(item);
}

이 예에서는 범주TodoController 클래스를 사용하여 로그를 만듭니다.This example creates logs with the TodoController class as the category. 범주는 이 문서의 뒷부분에 설명되어 있습니다.Categories are explained later in this article.

ASP.NET Core는 비동기 로거 메서드를 제공하지 않습니다. 비동기를 사용할 필요가 없도록 로깅 속도가 아주 빠르기 때문입니다.ASP.NET Core doesn't provide async logger methods because logging should be so fast that it isn't worth the cost of using async. 로깅 속도가 빠르지 않은 경우 로깅 방식을 변경하는 방안을 고려해 보세요.If you're in a situation where that's not true, consider changing the way you log. 데이터 저장소가 느리면 로그 메시지를 빠른 저장소에 먼저 쓴 후 나중에 느린 저장소로 이동합니다.If your data store is slow, write the log messages to a fast store first, then move them to a slow store later. 예를 들어 다른 프로세스에서 읽고 지속하는 느린 저장소인 메시지 큐에 기록합니다.For example, log to a message queue that's read and persisted to slow storage by another process.

공급자를 추가하는 방법How to add providers

로깅 공급자는 개발자가 ILogger 개체를 사용하여 만든 메시지를 가져와서 표시하거나 저장합니다.A logging provider takes the messages that you create with an ILogger object and displays or stores them. 예를 들어 콘솔 공급자는 콘솔에 메시지를 표시하고, Azure App Service 공급자는 메시지를 Azure BLOB 저장소에 저장할 수 있습니다.For example, the Console provider displays messages on the console, and the Azure App Service provider can store them in Azure blob storage.

공급자를 사용하려면 Program.cs에서 공급자의 Add<ProviderName> 확장 메서드를 호출합니다.To use a provider, call the provider's Add<ProviderName> extension method in Program.cs:

public static void Main(string[] args)
{
    var webHost = new WebHostBuilder()
        .UseKestrel()
        .UseContentRoot(Directory.GetCurrentDirectory())
        .ConfigureAppConfiguration((hostingContext, config) =>
        {
            var env = hostingContext.HostingEnvironment;
            config.AddJsonFile("appsettings.json", optional: true, reloadOnChange: true)
                  .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true, reloadOnChange: true);
            config.AddEnvironmentVariables();
        })
        .ConfigureLogging((hostingContext, logging) =>
        {
            logging.AddConfiguration(hostingContext.Configuration.GetSection("Logging"));
            logging.AddConsole();
            logging.AddDebug();
        })
        .UseStartup<Startup>()
        .Build();

    webHost.Run();
}

기본 프로젝트 템플릿은 Program.csCreateDefaultBuilder 확장 메서드 호출을 통해 콘솔 및 디버그 로깅 공급자를 지원합니다.The default project template enables the Console and Debug logging providers with a call to the CreateDefaultBuilder extension method in Program.cs:

public static void Main(string[] args)
{
    BuildWebHost(args).Run();
}

public static IWebHost BuildWebHost(string[] args) =>
    WebHost.CreateDefaultBuilder(args)
        .UseStartup<Startup>()
        .Build();

로깅 공급자는 개발자가 ILogger 개체를 사용하여 만든 메시지를 가져와서 표시하거나 저장합니다.A logging provider takes the messages that you create with an ILogger object and displays or stores them. 예를 들어 콘솔 공급자는 콘솔에 메시지를 표시하고, Azure App Service 공급자는 메시지를 Azure BLOB 저장소에 저장할 수 있습니다.For example, the Console provider displays messages on the console, and the Azure App Service provider can store them in Azure blob storage.

공급자를 사용하려면 다음 예제처럼 NuGet 패키지를 설치하고 ILoggerFactory 인스턴스에서 공급자의 확장 메서드를 호출합니다.To use a provider, install its NuGet package and call the provider's extension method on an instance of ILoggerFactory, as shown in the following example:

public void Configure(IApplicationBuilder app,
    IHostingEnvironment env,
    ILoggerFactory loggerFactory)
{
    loggerFactory
        .AddConsole()
        .AddDebug();

ASP.NET Core DI(종속성 주입)는 ILoggerFactory 인스턴스를 제공합니다.ASP.NET Core dependency injection (DI) provides the ILoggerFactory instance. AddConsoleAddDebug 확장 메서드는 Microsoft.Extensions.Logging.ConsoleMicrosoft.Extensions.Logging.Debug 패키지에 정의됩니다.The AddConsole and AddDebug extension methods are defined in the Microsoft.Extensions.Logging.Console and Microsoft.Extensions.Logging.Debug packages. 각 확장 메서드는 ILoggerFactory.AddProvider 메서드를 호출하고, 공급자 인스턴스를 전달합니다.Each extension method calls the ILoggerFactory.AddProvider method, passing in an instance of the provider.

참고

샘플 앱Startup.Configure 메서드에서 로그 공급자를 추가합니다.The sample app adds logging providers in the Startup.Configure method. 먼저 실행되는 코드의 로그 출력을 가져오려면 Startup 클래스 생성자에서 로그 공급자를 추가합니다.If you want to obtain log output from code that executes earlier, add logging providers in the Startup class constructor.

기본 제공 로깅 공급자에 대해 자세히 알아보고 문서의 뒷부분에 나오는 타사 로깅 공급자에 대한 링크를 확인해 보세요.Learn more about the built-in logging providers and find links to third-party logging providers later in the article.

구성Configuration

로깅 공급자 구성은 하나 이상의 구성 공급자에서 제공합니다.Logging provider configuration is provided by one or more configuration providers:

  • 파일 형식(INI, JSON 및 XML).File formats (INI, JSON, and XML).
  • 명령줄 인수.Command-line arguments.
  • 환경 변수.Environment variables.
  • 메모리 내 .NET 개체.In-memory .NET objects.
  • 암호화되지 않은 암호 관리자 저장소.The unencrypted Secret Manager storage.
  • 암호화된 사용자 저장소(예:Azure Key Vault).An encrypted user store, such as Azure Key Vault.
  • 사용자 지정 공급자(설치 또는 생성된).Custom providers (installed or created).

예를 들어 로깅 구성은 일반적으로 앱 설정 파일의 Logging 섹션에서 제공됩니다.For example, logging configuration is commonly provided by the Logging section of app settings files. 다음 예제에서는 일반적인 appsettings.Development.json 파일의 콘텐츠를 보여줍니다.The following example shows the contents of a typical appsettings.Development.json file:

{
"Logging": {
"LogLevel": {
"Default": "Debug",
"System": "Information",
"Microsoft": "Information"
},
"Console":
{
"IncludeScopes": "true"
}
}
}

LogLevel 키는 로그 이름을 나타냅니다.LogLevel keys represent log names. Default 키는 명시적으로 나열되지 않은 로그에 적용됩니다.The Default key applies to logs not explicitly listed. 값은 지정된 로그에 적용된 로그 수준을 나타냅니다.The value represents the log level applied to the given log. IncludeScopes(예제의 Console)를 설정하는 로그 키는 로그 범위를 표시된 로그에 사용하는지 여부를 지정합니다.Log keys that set IncludeScopes (Console in the example), specify if log scopes are enabled for the indicated log.

{
"Logging": {
"LogLevel": {
"Default": "Debug",
"System": "Information",
"Microsoft": "Information"
}
}
}

LogLevel 키는 로그 이름을 나타냅니다.LogLevel keys represent log names. Default 키는 명시적으로 나열되지 않은 로그에 적용됩니다.The Default key applies to logs not explicitly listed. 값은 지정된 로그에 적용된 로그 수준을 나타냅니다.The value represents the log level applied to the given log.

구성 공급자 구현에 대한 자세한 내용은 ASP.NET Core의 구성를 참조하세요.For information on implementing configuration providers, see ASP.NET Core의 구성.

샘플 로깅 출력Sample logging output

이전 섹션에 나와 있는 샘플 코드를 사용하는 경우 명령줄에서 실행하면 콘솔에 로그가 표시됩니다.With the sample code shown in the preceding section, you'll see logs in the console when you run from the command line. 다음은 콘솔 출력의 예입니다.Here's an example of console output:

info: Microsoft.AspNetCore.Hosting.Internal.WebHost[1]
      Request starting HTTP/1.1 GET http://localhost:5000/api/todo/0
info: Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker[1]
      Executing action method TodoApi.Controllers.TodoController.GetById (TodoApi) with arguments (0) - ModelState is Valid
info: TodoApi.Controllers.TodoController[1002]
      Getting item 0
warn: TodoApi.Controllers.TodoController[4000]
      GetById(0) NOT FOUND
info: Microsoft.AspNetCore.Mvc.StatusCodeResult[1]
      Executing HttpStatusCodeResult, setting HTTP status code 404
info: Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker[2]
      Executed action TodoApi.Controllers.TodoController.GetById (TodoApi) in 42.9286ms
info: Microsoft.AspNetCore.Hosting.Internal.WebHost[2]
      Request finished in 148.889ms 404

이러한 로그는 http://localhost:5000/api/todo/0으로 이동하여 생성되었으며, 이는 이전 섹션에서 나온 두 ILogger 호출의 실행을 트리거합니다.These logs were created by going to http://localhost:5000/api/todo/0, which triggers execution of both ILogger calls shown in the preceding section.

다음은 Visual Studio에서 응용 프로그램 예제를 실행하면 디버그 창에 표시되는 동일한 로그의 예입니다.Here's an example of the same logs as they appear in the Debug window when you run the sample application in Visual Studio:

Microsoft.AspNetCore.Hosting.Internal.WebHost:Information: Request starting HTTP/1.1 GET http://localhost:53104/api/todo/0  
Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker:Information: Executing action method TodoApi.Controllers.TodoController.GetById (TodoApi) with arguments (0) - ModelState is Valid
TodoApi.Controllers.TodoController:Information: Getting item 0
TodoApi.Controllers.TodoController:Warning: GetById(0) NOT FOUND
Microsoft.AspNetCore.Mvc.StatusCodeResult:Information: Executing HttpStatusCodeResult, setting HTTP status code 404
Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker:Information: Executed action TodoApi.Controllers.TodoController.GetById (TodoApi) in 152.5657ms
Microsoft.AspNetCore.Hosting.Internal.WebHost:Information: Request finished in 316.3195ms 404

이전 섹션에서 ILogger 호출을 통해 생성된 로그는 "TodoApi.Controllers.TodoController"로 시작합니다.The logs that were created by the ILogger calls shown in the preceding section begin with "TodoApi.Controllers.TodoController". "Microsoft" 범주로 시작하는 로그는 ASP.NET Core에서 온 것입니다.The logs that begin with "Microsoft" categories are from ASP.NET Core. ASP.NET Core 자체와 응용 프로그램 코드는 동일한 로깅 API와 동일한 로깅 공급자 사용합니다.ASP.NET Core itself and your application code are using the same logging API and the same logging providers.

이 문서의 나머지 부분에서는 로깅에 대한 일부 세부 정보 및 옵션을 설명합니다.The remainder of this article explains some details and options for logging.

NuGet 패키지NuGet packages

ILoggerILoggerFactory 인터페이스는 Microsoft.Extensions.Logging.Abstractions에 있으며, 두 인터페이스의 기본 구현은 Microsoft.Extensions.Logging에 있습니다.The ILogger and ILoggerFactory interfaces are in Microsoft.Extensions.Logging.Abstractions, and default implementations for them are in Microsoft.Extensions.Logging.

로그 범주Log category

범주는 개발자가 만드는 각 로그와 함께 포함됩니다.A category is included with each log that you create. 개발자는 ILogger 개체를 만들 때 범주를 지정합니다.You specify the category when you create an ILogger object. 모든 문자열을 범주로 사용할 수 있지만, 로그가 작성되는 클래스의 정규화된 이름을 사용해야 하는 규칙이 적용됩니다.The category may be any string, but a convention is to use the fully qualified name of the class from which the logs are written. "TodoApi.Controllers.TodoController"를 예로 들 수 있습니다.For example: "TodoApi.Controllers.TodoController".

범주를 문자열로 지정하거나 형식에서 범주가 파생되는 확장 메서드를 사용할 수 있습니다.You can specify the category as a string or use an extension method that derives the category from the type. 범주를 문자열로 지정하려면 아래와 같이 ILoggerFactory 인스턴스에 대해 CreateLogger를 호출합니다.To specify the category as a string, call CreateLogger on an ILoggerFactory instance, as shown below.

public class TodoController : Controller
{
    private readonly ITodoRepository _todoRepository;
    private readonly ILogger _logger;

    public TodoController(ITodoRepository todoRepository,
        ILoggerFactory logger)
    {
        _todoRepository = todoRepository;
        _logger = logger.CreateLogger("TodoApi.Controllers.TodoController");
    }

대부분의 경우 다음 예제와 같이 ILogger<T>를 사용하는 편이 더 쉽습니다.Most of the time, it will be easier to use ILogger<T>, as in the following example.

public class TodoController : Controller
{
    private readonly ITodoRepository _todoRepository;
    private readonly ILogger _logger;

    public TodoController(ITodoRepository todoRepository,
        ILogger<TodoController> logger)
    {
        _todoRepository = todoRepository;
        _logger = logger;
    }

이것은 정규화된 형식 이름 T를 사용하여 CreateLogger를 호출하는 것과 동일합니다.This is equivalent to calling CreateLogger with the fully qualified type name of T.

로그 수준Log level

로그를 쓸 때마다 LogLevel을 지정합니다.Each time you write a log, you specify its LogLevel. 로그 수준은 심각도 또는 중요도 수준을 나타냅니다.The log level indicates the degree of severity or importance. 예를 들어 메서드가 정상적으로 종료되면 Information 로그를 쓰고, 메서드가 404 반환 코드를 반환하면 Warning 로그를 쓰고, 예기치 않은 예외를 catch하면 Error 로그를 씁니다.For example, you might write an Information log when a method ends normally, a Warning log when a method returns a 404 return code, and an Error log when you catch an unexpected exception.

다음 코드 예제에서 메서드 이름(예: LogWarning)은 로그 수준을 지정합니다.In the following code example, the names of the methods (for example, LogWarning) specify the log level. 첫 번째 매개 변수는 Log event ID입니다.The first parameter is the Log event ID. 두 번째 매개 변수는 message template으로, 나머지 메서드 매개 변수에서 인수 값에 대한 자리 표시자를 제공합니다.The second parameter is a message template with placeholders for argument values provided by the remaining method parameters. 메서드 매개 변수는 이 문서의 뒷부분에 자세히 설명되어 있습니다.The method parameters are explained in more detail later in this article.

public IActionResult GetById(string id)
{
    _logger.LogInformation(LoggingEvents.GetItem, "Getting item {ID}", id);
    var item = _todoRepository.Find(id);
    if (item == null)
    {
        _logger.LogWarning(LoggingEvents.GetItemNotFound, "GetById({ID}) NOT FOUND", id);
        return NotFound();
    }
    return new ObjectResult(item);
}

메서드 이름에 수준을 포함하는 로그 메서드는 ILogger에 대한 확장 메서드입니다.Log methods that include the level in the method name are extension methods for ILogger. 백그라운드에서 이러한 메서드는 LogLevel 매개 변수를 사용하는 Log 메서드를 호출합니다.Behind the scenes, these methods call a Log method that takes a LogLevel parameter. 이러한 확장 메서드 중 하나를 호출하는 대신 Log 메서드를 직접 호출할 수 있지만, 구문이 비교적 복잡합니다.You can call the Log method directly rather than one of these extension methods, but the syntax is relatively complicated. 자세한 내용은 ILogger 인터페이스로거 확장 소스 코드를 참조하세요.For more information, see the ILogger interface and the logger extensions source code.

ASP.NET Core는 다음 로그 수준을 정의하며, 여기에 가장 낮은 심각도에서 가장 높은 심각도 순으로 정렬됩니다.ASP.NET Core defines the following log levels, ordered here from least to highest severity.

  • 추적 = 0Trace = 0

    문제를 디버깅하는 개발자에게만 중요한 정보입니다.For information that's valuable only to a developer debugging an issue. 이러한 메시지는 중요한 응용 프로그램 데이터를 포함할 수 있으므로 프로덕션 환경에서 사용하면 안 됩니다.These messages may contain sensitive application data and so shouldn't be enabled in a production environment. 기본적으로 사용하지 않도록 설정됩니다.Disabled by default. 예: Credentials: {"User":"someuser", "Password":"P@ssword"}Example: Credentials: {"User":"someuser", "Password":"P@ssword"}

  • 디버그 = 1Debug = 1

    개발 및 디버깅하는 동안 단기적으로 유용한 정보입니다.For information that has short-term usefulness during development and debugging. 예: 로그 볼륨이 크기 때문에 문제를 해결하려는 경우 외에는 프로덕션 환경에서 Entering method Configure with flag set to true.일반적으로 수준 로그를 사용하지 않습니다Debug.Example: Entering method Configure with flag set to true. You typically wouldn't enable Debug level logs in production unless you are troubleshooting, due to the high volume of logs.

  • 정보 = 2Information = 2

    응용 프로그램의 일반적인 흐름을 추적합니다.For tracking the general flow of the application. 이러한 로그는 일반적으로 장기적인 가치가 있습니다.These logs typically have some long-term value. 예: Request received for path /api/todoExample: Request received for path /api/todo

  • 경고 = 3Warning = 3

    응용 프로그램 흐름에 비정상적인 또는 예기치 않은 이벤트가 있습니다.For abnormal or unexpected events in the application flow. 응용 프로그램을 중지하지는 않지만 조사할 필요가 있는 오류 또는 기타 조건도 여기에 포함될 수 있습니다.These may include errors or other conditions that don't cause the application to stop, but which may need to be investigated. 처리된 예외는 Warning 로그 수준을 사용하는 일반적인 장소입니다.Handled exceptions are a common place to use the Warning log level. 예: FileNotFoundException for file quotes.txt.Example: FileNotFoundException for file quotes.txt.

  • 오류 = 4Error = 4

    처리할 수 없는 오류 및 예외입니다.For errors and exceptions that cannot be handled. 이러한 메시지는 전체 응용 프로그램 오류가 아닌 현재 동작 또는 작업(예: 현재 HTTP 요청)의 오류를 의미합니다.These messages indicate a failure in the current activity or operation (such as the current HTTP request), not an application-wide failure. 예제 로그 메시지: Cannot insert record due to duplicate key violation.Example log message: Cannot insert record due to duplicate key violation.

  • 중요 = 5Critical = 5

    즉각적인 대응이 필요한 오류입니다.For failures that require immediate attention. 예: 데이터 손실 시나리오, 디스크 공간 부족.Examples: data loss scenarios, out of disk space.

로그 수준을 사용하여 특정 저장 매체 또는 디스플레이 창에 기록되는 로그 출력의 양을 제어할 수 있습니다.You can use the log level to control how much log output is written to a particular storage medium or display window. 예를 들어 프로덕션 환경에서 Information 수준 이하의 모든 로그는 볼륨 데이터 저장소로 이동하고, Warning 수준 이상의 모든 로그는 가치 데이터 저장소로 이동할 수 있습니다.For example, in production you might want all logs of Information level and lower to go to a volume data store, and all logs of Warning level and higher to go to a value data store. 개발하는 동안 심각도가 Warning 이상인 로그는 일반적으로 콘솔로 보냅니다.During development, you might normally send logs of Warning or higher severity to the console. 문제를 해결해야 하는 상황이 오면 Debug 수준을 추가할 수 있습니다.Then when you need to troubleshoot, you can add Debug level. 이 문서의 뒷부분에 나오는 로그 필터링 섹션에서는 공급자가 처리하는 로그 수준을 제어하는 방법을 설명합니다.The Log filtering section later in this article explains how to control which log levels a provider handles.

ASP.NET Core 프레임워크는 프레임워크 이벤트에 대한 Debug 수준 로그를 씁니다.The ASP.NET Core framework writes Debug level logs for framework events. 이 문서 앞부분에 나온 로그 예제는 Information 수준 미만 로그를 제외했기 때문에 Debug 수준 로그가 하나도 표시되지 않았습니다.The log examples earlier in this article excluded logs below Information level, so no Debug level logs were shown. 다음은 콘솔 공급자에 대해 Debug 이상 로그를 표시하도록 구성된 응용 프로그램 예제를 실행할 경우의 콘솔 로그 예제입니다.Here's an example of console logs if you run the sample application configured to show Debug and higher logs for the console provider.

info: Microsoft.AspNetCore.Hosting.Internal.WebHost[1]
      Request starting HTTP/1.1 GET http://localhost:62555/api/todo/0
dbug: Microsoft.AspNetCore.Routing.Tree.TreeRouter[1]
      Request successfully matched the route with name 'GetTodo' and template 'api/Todo/{id}'.
dbug: Microsoft.AspNetCore.Mvc.Internal.ActionSelector[2]
      Action 'TodoApi.Controllers.TodoController.Update (TodoApi)' with id '089d59b6-92ec-472d-b552-cc613dfd625d' did not match the constraint 'Microsoft.AspNetCore.Mvc.Internal.HttpMethodActionConstraint'
dbug: Microsoft.AspNetCore.Mvc.Internal.ActionSelector[2]
      Action 'TodoApi.Controllers.TodoController.Delete (TodoApi)' with id 'f3476abe-4bd9-4ad3-9261-3ead09607366' did not match the constraint 'Microsoft.AspNetCore.Mvc.Internal.HttpMethodActionConstraint'
dbug: Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker[1]
      Executing action TodoApi.Controllers.TodoController.GetById (TodoApi)
info: Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker[1]
      Executing action method TodoApi.Controllers.TodoController.GetById (TodoApi) with arguments (0) - ModelState is Valid
info: TodoApi.Controllers.TodoController[1002]
      Getting item 0
warn: TodoApi.Controllers.TodoController[4000]
      GetById(0) NOT FOUND
dbug: Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker[2]
      Executed action method TodoApi.Controllers.TodoController.GetById (TodoApi), returned result Microsoft.AspNetCore.Mvc.NotFoundResult.
info: Microsoft.AspNetCore.Mvc.StatusCodeResult[1]
      Executing HttpStatusCodeResult, setting HTTP status code 404
info: Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker[2]
      Executed action TodoApi.Controllers.TodoController.GetById (TodoApi) in 0.8788ms
dbug: Microsoft.AspNetCore.Server.Kestrel[9]
      Connection id "0HL6L7NEFF2QD" completed keep alive response.
info: Microsoft.AspNetCore.Hosting.Internal.WebHost[2]
      Request finished in 2.7286ms 404

로그 이벤트 IDLog event ID

로그를 쓸 때마다 이벤트 ID를 지정합니다.Each time you write a log, you can specify an event ID. 샘플 앱은 로컬로 정의된 LoggingEvents 클래스를 사용하여 이 작업을 수행합니다.The sample app does this by using a locally-defined LoggingEvents class:

public IActionResult GetById(string id)
{
    _logger.LogInformation(LoggingEvents.GetItem, "Getting item {ID}", id);
    var item = _todoRepository.Find(id);
    if (item == null)
    {
        _logger.LogWarning(LoggingEvents.GetItemNotFound, "GetById({ID}) NOT FOUND", id);
        return NotFound();
    }
    return new ObjectResult(item);
}
public class LoggingEvents
{
    public const int GenerateItems = 1000;
    public const int ListItems = 1001;
    public const int GetItem = 1002;
    public const int InsertItem = 1003;
    public const int UpdateItem = 1004;
    public const int DeleteItem = 1005;

    public const int GetItemNotFound = 4000;
    public const int UpdateItemNotFound = 4001;
}

이벤트 ID는 로깅된 이벤트 집합을 서로 연결하는 데 사용할 수 있는 정수 값입니다.An event ID is an integer value that you can use to associate a set of logged events with one another. 예를 들어 장바구니에 항목 추가에 대한 로그는 이벤트 ID 1000이고 구매 완료에 대한 로그는 이벤트 ID 1001입니다.For instance, a log for adding an item to a shopping cart could be event ID 1000 and a log for completing a purchase could be event ID 1001.

로깅 출력에서 이벤트 ID는 공급자에 따라 필드에 저장되거나 텍스트 메시지에 포함될 수 있습니다.In logging output, the event ID may be stored in a field or included in the text message, depending on the provider. 디버그 공급자는 이벤트 ID를 표시하지 않지만, 콘솔 공급자는 범주 뒤에서 대괄호 안에 이벤트 ID를 표시합니다.The Debug provider doesn't show event IDs, but the console provider shows them in brackets after the category:

info: TodoApi.Controllers.TodoController[1002]
      Getting item invalidid
warn: TodoApi.Controllers.TodoController[4000]
      GetById(invalidid) NOT FOUND

로그 메시지 템플릿Log message template

로그 메시지를 쓸 때마다 메시지 템플릿을 제공합니다.Each time you write a log message, you provide a message template. 메시지 템플릿은 문자열일 수도 있고, 인수 값이 배치되는 명명된 자리 표시자를 포함할 수도 있습니다.The message template can be a string or it can contain named placeholders into which argument values are placed. 템플릿은 형식 문자열이 아니고, 자리 표시자는 번호가 아닌 이름이 지정되어야 합니다.The template isn't a format string, and placeholders should be named, not numbered.

public IActionResult GetById(string id)
{
    _logger.LogInformation(LoggingEvents.GetItem, "Getting item {ID}", id);
    var item = _todoRepository.Find(id);
    if (item == null)
    {
        _logger.LogWarning(LoggingEvents.GetItemNotFound, "GetById({ID}) NOT FOUND", id);
        return NotFound();
    }
    return new ObjectResult(item);
}

값을 제공하는 데 사용되는 매개 변수를 결정하는 것은 자리 표시자의 번호가 아닌 이름입니다.The order of placeholders, not their names, determines which parameters are used to provide their values. 다음과 같은 코드를 가정해 봅니다.If you have the following code:

string p1 = "parm1";
string p2 = "parm2";
_logger.LogInformation("Parameter values: {p2}, {p1}", p1, p2);

결과로 만들어진 로그 메시지는 다음과 같습니다.The resulting log message looks like this:

Parameter values: parm1, parm2

로깅 프레임워크는 이 방식으로 메시지를 포맷하여 로깅 공급자가 구조적 로깅이라고도 하는 의미 체계 로깅을 구현할 수 있게 해줍니다.The logging framework does message formatting in this way to make it possible for logging providers to implement semantic logging, also known as structured logging. 인수 자체는 포맷된 메시지 템플릿이 아닌 로깅 시스템으로 전달되기 때문에 로깅 공급자가 메시지 템플릿 외에도 매개 변수 값을 필드로 저장할 수 있습니다.Because the arguments themselves are passed to the logging system, not just the formatted message template, logging providers can store the parameter values as fields in addition to the message template. 로그 출력을 Azure Table Storage로 전달하는 경우 로거 메서드 호출은 다음과 같습니다.If you're directing your log output to Azure Table Storage and your logger method call looks like this:

_logger.LogInformation("Getting item {ID} at {RequestTime}", id, DateTime.Now);

각 Azure Table 엔터티는 로그 데이터에 대한 쿼리를 간소화하는 IDRequestTime 속성을 가질 수 있습니다.Each Azure Table entity can have ID and RequestTime properties, which simplifies queries on log data. 문자 메시지의 시간 초과를 구문 분석할 필요 없이 특정 RequestTime 범위 내에서 모든 로그를 찾을 수 있습니다.You can find all logs within a particular RequestTime range without the need to parse the time out of the text message.

로깅 처리Logging exceptions

로거 메서드는 다음 예제와 같이 예외를 전달할 수 있는 오버로드를 갖고 있습니다.The logger methods have overloads that let you pass in an exception, as in the following example:

catch (Exception ex)
{
    _logger.LogWarning(LoggingEvents.GetItemNotFound, ex, "GetById({ID}) NOT FOUND", id);
    return NotFound();
}
return new ObjectResult(item);

공급자들은 다양한 방식으로 예외 정보를 처리합니다.Different providers handle the exception information in different ways. 다음은 위에서 보여드린 코드의 디버그 공급자 출력의 예제입니다.Here's an example of Debug provider output from the code shown above.

TodoApi.Controllers.TodoController:Warning: GetById(036dd898-fb01-47e8-9a65-f92eb73cf924) NOT FOUND

System.Exception: Item not found exception.
 at TodoApi.Controllers.TodoController.GetById(String id) in C:\logging\sample\src\TodoApi\Controllers\TodoController.cs:line 226

로깅 필터링Log filtering

특정 공급자 및 범주 또는 모든 공급자나 모든 범주의 최소 로그 수준을 지정할 수 있습니다.You can specify a minimum log level for a specific provider and category or for all providers or all categories. 최소 수준 미만인 로그는 해당 공급자에게 전달되지 않으므로 표시되거나 저장되지 않습니다.Any logs below the minimum level aren't passed to that provider, so they don't get displayed or stored.

모든 로그를 표시하지 않으려면 최소 로그 수준으로 LogLevel.None을 지정하면 됩니다.If you want to suppress all logs, you can specify LogLevel.None as the minimum log level. LogLevel.None의 정수 값은 LogLevel.Critical(5)보다 높은 6입니다.The integer value of LogLevel.None is 6, which is higher than LogLevel.Critical (5).

구성에서 필터 규칙 만들기Create filter rules in configuration

프로젝트 템플릿은 콘솔 및 디버그 공급자에 대한 로깅을 설정하는 CreateDefaultBuilder를 호출하는 코드를 만듭니다.The project templates create code that calls CreateDefaultBuilder to set up logging for the Console and Debug providers. 또한 CreateDefaultBuilder 메서드는 다음과 같은 코드를 사용하여 Logging 섹션에서 구성을 조회하는 로깅을 설정합니다.The CreateDefaultBuilder method also sets up logging to look for configuration in a Logging section, using code like the following:

public static void Main(string[] args)
{
    var webHost = new WebHostBuilder()
        .UseKestrel()
        .UseContentRoot(Directory.GetCurrentDirectory())
        .ConfigureAppConfiguration((hostingContext, config) =>
        {
            var env = hostingContext.HostingEnvironment;
            config.AddJsonFile("appsettings.json", optional: true, reloadOnChange: true)
                  .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true, reloadOnChange: true);
            config.AddEnvironmentVariables();
        })
        .ConfigureLogging((hostingContext, logging) =>
        {
            logging.AddConfiguration(hostingContext.Configuration.GetSection("Logging"));
            logging.AddConsole();
            logging.AddDebug();
        })
        .UseStartup<Startup>()
        .Build();

    webHost.Run();
}

구성 데이터는 다음 예제와 같이 공급자 및 범주별로 최소 로그 수준을 지정합니다.The configuration data specifies minimum log levels by provider and category, as in the following example:

{
  "Logging": {
    "Debug": {
      "LogLevel": {
        "Default": "Information"
      }
    },
    "Console": {
      "IncludeScopes": false,
      "LogLevel": {
        "Microsoft.AspNetCore.Mvc.Razor.Internal": "Warning",
        "Microsoft.AspNetCore.Mvc.Razor.Razor": "Debug",
        "Microsoft.AspNetCore.Mvc.Razor": "Error",
        "Default": "Information"
      }
    },
    "LogLevel": {
      "Default": "Debug"
    }
  }
}

이 JSON은 6개의 필터 규칙을 만드는데, 하나는 디버그 공급자용이고, 4개는 콘솔 공급자용이고, 나머지 하나는 모든 공급자에 적용됩니다.This JSON creates six filter rules, one for the Debug provider, four for the Console provider, and one that applies to all providers. ILogger 개체가 생성될 때 각 공급자에 대해 이러한 규칙 중 하나를 선택하는 방법은 나중에 살펴보겠습니다.You'll see later how just one of these rules is chosen for each provider when an ILogger object is created.

코드의 필터 규칙Filter rules in code

다음 예제와 같이 코드에서 필터 규칙을 등록할 수 있습니다.You can register filter rules in code, as shown in the following example:

WebHost.CreateDefaultBuilder(args)
    .UseStartup<Startup>()
    .ConfigureLogging(logging =>
        logging.AddFilter("System", LogLevel.Debug)
               .AddFilter<DebugLoggerProvider>("Microsoft", LogLevel.Trace))
    .Build();

두 번째 AddFilter는 형식 이름을 사용하여 디버그 공급자를 지정합니다.The second AddFilter specifies the Debug provider by using its type name. 첫 번째 AddFilter는 공급자 형식을 지정하지 않으며, 따라서 모든 공급자에 적용됩니다.The first AddFilter applies to all providers because it doesn't specify a provider type.

필터링 규칙 적용 방식How filtering rules are applied

이전 예제의 구성 데이터 및 AddFilter 코드는 다음 표에 표시된 규칙을 만듭니다.The configuration data and the AddFilter code shown in the preceding examples create the rules shown in the following table. 처음 6개는 구성 예제에서 가져온 것이고 마지막 2개는 코드 예제에서 가져온 것입니다.The first six come from the configuration example and the last two come from the code example.

Number 공급자Provider 다음으로 시작하는 범주...Categories that begin with ... 최소 로그 수준Minimum log level
11 디버그Debug 모든 범주All categories 정보Information
22 콘솔Console Microsoft.AspNetCore.Mvc.Razor.InternalMicrosoft.AspNetCore.Mvc.Razor.Internal 경고Warning
33 콘솔Console Microsoft.AspNetCore.Mvc.Razor.RazorMicrosoft.AspNetCore.Mvc.Razor.Razor 디버그Debug
44 콘솔Console Microsoft.AspNetCore.Mvc.RazorMicrosoft.AspNetCore.Mvc.Razor ErrorError
55 콘솔Console 모든 범주All categories 정보Information
66 모든 공급자All providers 모든 범주All categories 디버그Debug
77 모든 공급자All providers 시스템System 디버그Debug
88 디버그Debug MicrosoftMicrosoft 추적Trace

로그를 쓰는 ILogger 개체를 만들 때 ILoggerFactory 개체는 공급자마다 해당 로거에 적용할 단일 규칙을 선택합니다.When you create an ILogger object to write logs with, the ILoggerFactory object selects a single rule per provider to apply to that logger. ILogger 개체를 통해 작성된 모든 메시지는 선택한 규칙을 기반으로 필터링됩니다.All messages written by that ILogger object are filtered based on the selected rules. 사용 가능한 규칙 중에서 각 공급자 및 범주 쌍에 적용 가능한 가장 구체적인 규칙이 선택됩니다.The most specific rule possible for each provider and category pair is selected from the available rules.

지정된 범주에 대한 ILogger가 생성되면 다음 알고리즘이 각 공급자에 사용됩니다.The following algorithm is used for each provider when an ILogger is created for a given category:

  • 공급자 또는 공급자의 별칭과 일치하는 모든 규칙을 선택합니다.Select all rules that match the provider or its alias. 일치 항목이 없는 경우 빈 공급자와 함께 모든 규칙을 선택합니다.If none are found, select all rules with an empty provider.
  • 앞 단계의 결과에서 일치하는 범주 접두사가 가장 긴 규칙을 선택합니다.From the result of the preceding step, select rules with longest matching category prefix. 일치 항목이 없는 경우 범주를 지정하지 않는 규칙을 모두 선택합니다.If none are found, select all rules that don't specify a category.
  • 여러 규칙을 선택하는 경우 마지막 규칙을 사용합니다.If multiple rules are selected take the last one.
  • 규칙을 선택하지 않는 경우 MinimumLevel을 사용합니다.If no rules are selected, use MinimumLevel.

예를 들어 이전 단계의 규칙 목록을 갖고 있고 "Microsoft.AspNetCore.Mvc.Razor.RazorViewEngine" 범주에 대한 ILogger 개체를 만든다고 가정해 봅시다.For example, suppose you have the preceding list of rules and you create an ILogger object for category "Microsoft.AspNetCore.Mvc.Razor.RazorViewEngine":

  • 디버그 공급자에게는 규칙 1, 6, 8이 적용됩니다.For the Debug provider, rules 1, 6, and 8 apply. 규칙 8이 가장 구체적이므로 선택됩니다.Rule 8 is most specific, so that's the one selected.
  • 콘솔 공급자에게는 규칙 3, 4, 5, 6이 적용됩니다.For the Console provider, rules 3, 4, 5, and 6 apply. 규칙 3이 가장 구체적입니다.Rule 3 is most specific.

ILogger를 사용하여 "Microsoft.AspNetCore.Mvc.Razor.RazorViewEngine" 범주에 대한 로그를 만들 때 수준 Trace 이상의 로그는 디버그 공급자로 이동하고 수준 Debug 이상의 로그는 콘솔 공급자로 이동합니다.When you create logs with an ILogger for category "Microsoft.AspNetCore.Mvc.Razor.RazorViewEngine", logs of Trace level and above will go to the Debug provider, and logs of Debug level and above will go to the Console provider.

공급자 별칭Provider aliases

형식 이름을 사용하여 구성에서 공급자를 지정할 수 있지만, 각 공급자는 길이가 짧아 사용하기 간편한 별칭을 정의합니다.You can use the type name to specify a provider in configuration, but each provider defines a shorter alias that's easier to use. 기본 공급자의 경우 다음 별칭을 사용합니다.For the built-in providers, use the following aliases:

  • 콘솔Console
  • 디버그Debug
  • EventLogEventLog
  • AzureAppServicesAzureAppServices
  • TraceSourceTraceSource
  • EventSourceEventSource

기본 최소 수준Default minimum level

특정 공급자 및 범주에 대한 구성 또는 코드의 규칙이 적용되지 않는 경우에만 효력이 있는 최소 수준 설정이 있습니다.There's a minimum level setting that takes effect only if no rules from configuration or code apply for a given provider and category. 다음 예제는 최소 수준을 설정하는 방법을 보여 줍니다.The following example shows how to set the minimum level:

WebHost.CreateDefaultBuilder(args)
    .UseStartup<Startup>()
    .ConfigureLogging(logging => logging.SetMinimumLevel(LogLevel.Warning))
    .Build();

최소 수준을 명시적으로 설정하지 않으면 TraceDebug 로그를 무시하는 Information이 기본값으로 설정됩니다.If you don't explicitly set the minimum level, the default value is Information, which means that Trace and Debug logs are ignored.

필터 함수Filter functions

필터 함수에서 필터링 규칙을 적용할 코드를 작성할 수 있습니다.You can write code in a filter function to apply filtering rules. 필터 함수는 구성 또는 코드를 통해 규칙이 할당되지 않은 모든 공급자와 범주에 대해 호출됩니다.A filter function is invoked for all providers and categories that don't have rules assigned to them by configuration or code. 함수의 코드는 공급자 형식, 범주 및 로그 수준에 액세스하여 메시지를 기록할 것인지 여부를 결정할 수 있습니다.Code in the function has access to the provider type, category, and log level to decide whether or not a message should be logged. 예:For example:

WebHost.CreateDefaultBuilder(args)
    .UseStartup<Startup>()
    .ConfigureLogging(logBuilder =>
    {
        logBuilder.AddFilter((provider, category, logLevel) =>
        {
            if (provider == "Microsoft.Extensions.Logging.Console.ConsoleLoggerProvider" && 
                category == "TodoApi.Controllers.TodoController")
            {
                return false;
            }
            return true;
        });
    })
    .Build();

일부 로깅 공급자는 로그 수준 및 범주에 따라 로그를 저장 매체에 기록할 것인지 아니면 무시할 것인지를 개발자가 지정할 수 있게 해줍니다.Some logging providers let you specify when logs should be written to a storage medium or ignored based on log level and category.

AddConsoleAddDebug 확장 메서드는 필터링 조건을 전달할 수 있는 오버로드를 제공합니다.The AddConsole and AddDebug extension methods provide overloads that let you pass in filtering criteria. 다음 샘플 코드는 콘솔 공급자가 Warning 수준 미만의 로그를 무시하게 만들고, 디버그 공급자는 프레임워크에서 만드는 로그를 무시합니다.The following sample code causes the console provider to ignore logs below Warning level, while the Debug provider ignores logs that the framework creates.

public void Configure(IApplicationBuilder app,
    IHostingEnvironment env,
    ILoggerFactory loggerFactory)
{
    loggerFactory
        .AddConsole(LogLevel.Warning)
        .AddDebug((category, logLevel) => (category.Contains("TodoApi") && logLevel >= LogLevel.Trace));

AddEventLog 메서드는 EventLogSettings 인스턴스를 사용하는 오버로드를 갖고 있으며, 이 인스턴스의 Filter 속성에는 필터링 함수가 포함될 수 있습니다.The AddEventLog method has an overload that takes an EventLogSettings instance, which may contain a filtering function in its Filter property. TraceSource 공급자는 오버로드를 제공하지 않습니다. 로깅 수준 및 기타 매개 변수가 사용하는 SourceSwitchTraceListener를 기반으로 하기 때문입니다.The TraceSource provider doesn't provide any of those overloads, since its logging level and other parameters are based on the SourceSwitch and TraceListener it uses.

WithFilter 확장 메서드를 사용하여 ILoggerFactory 인스턴스에 등록된 모든 공급자에 대한 필터링 규칙을 설정할 수 있습니다.You can set filtering rules for all providers that are registered with an ILoggerFactory instance by using the WithFilter extension method. 아래 예제는 프레임워크 로그(범주가 "Microsoft" 또는 "시스템"으로 시작)를 경고로 제한하고 디버그 수준에서 앱 로그를 허용합니다.The example below limits framework logs (category begins with "Microsoft" or "System") to warnings while letting the app log at debug level.

public void Configure(IApplicationBuilder app,
    IHostingEnvironment env,
    ILoggerFactory loggerFactory)
{
    loggerFactory
        .WithFilter(new FilterLoggerSettings
        {
            { "Microsoft", LogLevel.Warning },
            { "System", LogLevel.Warning },
            { "ToDoApi", LogLevel.Debug }
        })
        .AddConsole()
        .AddDebug();

필터링을 사용하여 특정 범주에 대한 로그를 기록하지 못하게 하려면 해당 범주의 최소 로그 수준으로 LogLevel.None을 지정하면 됩니다.If you want to use filtering to prevent all logs from being written for a particular category, you can specify LogLevel.None as the minimum log level for that category. LogLevel.None의 정수 값은 LogLevel.Critical(5)보다 높은 6입니다.The integer value of LogLevel.None is 6, which is higher than LogLevel.Critical (5).

WithFilter 확장 메서드는 Microsoft.Extensions.Logging.Filter NuGet 패키지에서 제공합니다.The WithFilter extension method is provided by the Microsoft.Extensions.Logging.Filter NuGet package. 이 메서드는 등록된 모든 로거 공급자로 전달되는 메시지를 필터링하는 새로운 ILoggerFactory 인스턴스를 반환합니다.The method returns a new ILoggerFactory instance that will filter the log messages passed to all logger providers registered with it. 원래 ILoggerFactory 인스턴스를 포함하여 어떤 ILoggerFactory 인스턴스에도 영향을 주지 않습니다.It doesn't affect any other ILoggerFactory instances, including the original ILoggerFactory instance.

로그 점수Log scopes

범위 내의 논리적 작업 집합을 그룹화하여 동일한 데이터를 해당 집합의 일부로 생성된 각 로그에 연결할 수 있습니다.You can group a set of logical operations within a scope in order to attach the same data to each log that's created as part of that set. 예를 들어 트랜잭션 처리의 일부로 생성되는 모든 로그가 트랜잭션 ID를 포함하게 만들 수 있습니다.For example, you might want every log created as part of processing a transaction to include the transaction ID.

범위는 ILogger.BeginScope<TState> 메서드에서 반환하는 IDisposable 형식이며 삭제될 때까지 유지됩니다.A scope is an IDisposable type that's returned by the ILogger.BeginScope<TState> method and lasts until it's disposed. 다음과 같이 로거 호출을 using 블록에 래핑하여 범위를 사용합니다.You use a scope by wrapping your logger calls in a using block, as shown here:

public IActionResult GetById(string id)
{
    TodoItem item;
    using (_logger.BeginScope("Message attached to logs created in the using block"))
    {
        _logger.LogInformation(LoggingEvents.GetItem, "Getting item {ID}", id);
        item = _todoRepository.Find(id);
        if (item == null)
        {
            _logger.LogWarning(LoggingEvents.GetItemNotFound, "GetById({ID}) NOT FOUND", id);
            return NotFound();
        }
    }
    return new ObjectResult(item);
}

다음은 콘솔 공급자에 대한 범위를 사용하도록 설정하는 코드입니다.The following code enables scopes for the console provider:

Program.cs:Program.cs:

.ConfigureLogging((hostingContext, logging) =>
{
    logging.AddConfiguration(hostingContext.Configuration.GetSection("Logging"));
    logging.AddConsole(options => options.IncludeScopes = true);
    logging.AddDebug();
})

참고

범위 기반 로깅을 사용하려면 IncludeScopes 콘솔 로거 옵션을 구성해야 합니다.Configuring the IncludeScopes console logger option is required to enable scope-based logging.

구성에 대한 자세한 내용은 구성 섹션을 참조하세요.For information on configuration, see the Configuration section.

Program.cs:Program.cs:

.ConfigureLogging((hostingContext, logging) =>
{
    logging.AddConfiguration(hostingContext.Configuration.GetSection("Logging"));
    logging.AddConsole(options => options.IncludeScopes = true);
    logging.AddDebug();
})

참고

범위 기반 로깅을 사용하려면 IncludeScopes 콘솔 로거 옵션을 구성해야 합니다.Configuring the IncludeScopes console logger option is required to enable scope-based logging.

Startup.cs:Startup.cs:

public void Configure(IApplicationBuilder app,
    IHostingEnvironment env,
    ILoggerFactory loggerFactory)
{
    loggerFactory
        .AddConsole(includeScopes: true)
        .AddDebug();

각 로그 메시지는 범위 정보를 포함하고 있습니다.Each log message includes the scoped information:

info: TodoApi.Controllers.TodoController[1002]
      => RequestId:0HKV9C49II9CK RequestPath:/api/todo/0 => TodoApi.Controllers.TodoController.GetById (TodoApi) => Message attached to logs created in the using block
      Getting item 0
warn: TodoApi.Controllers.TodoController[4000]
      => RequestId:0HKV9C49II9CK RequestPath:/api/todo/0 => TodoApi.Controllers.TodoController.GetById (TodoApi) => Message attached to logs created in the using block
      GetById(0) NOT FOUND

기본 로깅 공급자Built-in logging providers

ASP.NET Core는 다음 공급자를 제공합니다.ASP.NET Core ships the following providers:

콘솔 공급자Console provider

Microsoft.Extensions.Logging.Console 공급자 패키지는 콘솔에 로그 출력을 보냅니다.The Microsoft.Extensions.Logging.Console provider package sends log output to the console.

logging.AddConsole();
loggerFactory.AddConsole();

AddConsole 오버로드를 사용하여 최소 로그 수준, 필터 함수 및 범위 지원 여부를 나타내는 부울을 전달할 수 있습니다.AddConsole overloads let you pass in an a minimum log level, a filter function, and a boolean that indicates whether scopes are supported. 다른 옵션으로는 IConfiguration 개체를 전달할 수 있으며, 이 개체는 범위 지원 및 로깅 수준을 지정할 수 있습니다.Another option is to pass in an IConfiguration object, which can specify scopes support and logging levels.

프로덕션 환경에서 콘솔 공급자를 사용하려고 생각 중인 경우 성능에 상당한 영향이 있다는 점에 주의해야 합니다.If you are considering the console provider for use in production, be aware that it has a significant impact on performance.

Visual Studio에서 새 프로젝트를 만들면 AddConsole 메서드는 다음과 같습니다.When you create a new project in Visual Studio, the AddConsole method looks like this:

loggerFactory.AddConsole(Configuration.GetSection("Logging"));

이 코드는 appSettings.json 파일의 Logging 섹션을 참조합니다.This code refers to the Logging section of the appSettings.json file:

{
  "Logging": {
    "Console": {
      "IncludeScopes": false
    },
    "LogLevel": {
      "Default": "Debug",
      "System": "Information",
      "Microsoft": "Information"
    }
  }
}

로그 필터링 섹션에서 설명했듯이, 제한 프레임워크를 표시한 설정은 경고에 기록되는 한편 앱이 디버그 수준에서 기록하는 것을 허용합니다.The settings shown limit framework logs to warnings while allowing the app to log at debug level, as explained in the Log filtering section. 자세한 내용은 구성을 참고하시기 바랍니다.For more information, see Configuration.

디버그 공급자Debug provider

Microsoft.Extensions.Logging.Debug 공급자 패키지는 System.Diagnostics.Debug 클래스(Debug.WriteLine 메서드 호출)를 사용하여 로그 출력을 씁니다.The Microsoft.Extensions.Logging.Debug provider package writes log output by using the System.Diagnostics.Debug class (Debug.WriteLine method calls).

Linux에서 이 공급자는 /var/log/message에 로그를 씁니다.On Linux, this provider writes logs to /var/log/message.

logging.AddDebug();
loggerFactory.AddDebug();

AddDebug 오버로드를 사용하여 최소 수준 로그 또는 필터 함수를 전달할 수 있습니다.AddDebug overloads let you pass in a minimum log level or a filter function.

EventSource 공급자EventSource provider

ASP.NET Core 1.1.0 이상을 대상으로 하는 앱의 경우 Microsoft.Extensions.Logging.EventSource 공급자 패키지가 이벤트 추적을 구현할 수 있습니다.For apps that target ASP.NET Core 1.1.0 or later, the Microsoft.Extensions.Logging.EventSource provider package can implement event tracing. Windows에서는 ETW를 사용합니다.On Windows, it uses ETW. 플랫폼 간 공급자이지만 이벤트를 수집하지 않으며 Linux 또는 macOS용 도구를 표시합니다.The provider is cross-platform, but there are no event collection and display tools yet for Linux or macOS.

logging.AddEventSourceLogger();
loggerFactory.AddEventSourceLogger();

로그를 수집하고 보는 좋은 방법은 PerfView 유틸리티를 사용하는 것입니다.A good way to collect and view logs is to use the PerfView utility. ETW 로그를 보는 다른 도구가 있지만, PerfView는 ASP.NET에서 내보내는 ETW 이벤트를 처리하기에 가장 좋은 환경을 제공합니다.There are other tools for viewing ETW logs, but PerfView provides the best experience for working with the ETW events emitted by ASP.NET.

이 공급자가 기록한 이벤트를 수집하도록 PerfView를 구성하려면 추가 공급자 목록에 *Microsoft-Extensions-Logging 문자열을 추가합니다.To configure PerfView for collecting events logged by this provider, add the string *Microsoft-Extensions-Logging to the Additional Providers list. (문자열의 시작 부분에 별표를 누락하지 마세요.)(Don't miss the asterisk at the start of the string.)

Perfview 추가 공급자

Windows EventLog 공급자Windows EventLog provider

Microsoft.Extensions.Logging.EventLog 공급자 패키지는 Windows 이벤트 로그에 로그 출력을 보냅니다.The Microsoft.Extensions.Logging.EventLog provider package sends log output to the Windows Event Log.

logging.AddEventLog();
loggerFactory.AddEventLog();

AddEventLog 오버로드를 사용하여 EventLogSettings 또는 최소 로그 수준을 전달할 수 있습니다.AddEventLog overloads let you pass in EventLogSettings or a minimum log level.

TraceSource 공급자TraceSource provider

Microsoft.Extensions.Logging.TraceSource 공급자 패키지는 System.Diagnostics.TraceSource 라이브러리 및 공급자를 사용합니다.The Microsoft.Extensions.Logging.TraceSource provider package uses the System.Diagnostics.TraceSource libraries and providers.

logging.AddTraceSource(sourceSwitchName);
loggerFactory.AddTraceSource(sourceSwitchName);

AddTraceSource 오버로드를 사용하여 원본 스위치 및 추적 수신기를 전달할 수 있습니다.AddTraceSource overloads let you pass in a source switch and a trace listener.

이 공급자를 사용하려면 응용 프로그램이 .NET Framework(.NET Core가 아닌)에서 실행되어야 합니다.To use this provider, an application has to run on the .NET Framework (rather than .NET Core). 공급자를 통해 응용 프로그램 예제에 사용된 TextWriterTraceListener처럼 다양한 수신기로 메시지를 라우팅할 수 있습니다.The provider lets you route messages to a variety of listeners, such as the TextWriterTraceListener used in the sample application.

다음은 Warning 이상 메시지를 콘솔 창에 기록하는 TraceSource 공급자를 구성하는 예제입니다.The following example configures a TraceSource provider that logs Warning and higher messages to the console window.

public void Configure(IApplicationBuilder app,
    IHostingEnvironment env,
    ILoggerFactory loggerFactory)
{
    loggerFactory
        .AddDebug();

    // add Trace Source logging
    var testSwitch = new SourceSwitch("sourceSwitch", "Logging Sample");
    testSwitch.Level = SourceLevels.Warning;
    loggerFactory.AddTraceSource(testSwitch,
        new TextWriterTraceListener(writer: Console.Out));

Azure App Service 공급자Azure App Service provider

Microsoft.Extensions.Logging.AzureAppServices 공급자 패키지는 Azure App Service 앱의 파일 시스템과 Azure Storage 계정의 BLOB 저장소에 텍스트 파일을 기록합니다.The Microsoft.Extensions.Logging.AzureAppServices provider package writes logs to text files in an Azure App Service app's file system and to blob storage in an Azure Storage account. 공급자 패키지는 .NET Core 1.1 이상을 대상으로 하는 앱에 사용할 수 있습니다.The provider package is available for apps targeting .NET Core 1.1 or later.

.NET Core를 대상으로 하는 경우 다음 사항에 유의합니다.If targeting .NET Core, note the following points:

.NET Framework를 대상으로 지정하거나 Microsoft.AspNetCore.App 메타패키지를 참조하는 경우 패키지 공급자를 프로젝트에 추가합니다.If targeting .NET Framework or referencing the Microsoft.AspNetCore.App metapackage, add the provider package to the project. ILoggerFactory 인스턴스에서 AddAzureWebAppDiagnostics를 호출합니다.Invoke AddAzureWebAppDiagnostics on an ILoggerFactory instance:

logging.AddAzureWebAppDiagnostics();
loggerFactory.AddAzureWebAppDiagnostics();

AddAzureWebAppDiagnostics 오버로드를 사용하여 로깅 출력 템플릿, Blob 이름, 파일 크기 제한 등의 기본 설정을 재정의하는 데 사용할 수 있는 AzureAppServicesDiagnosticsSettings를 전달할 수 있습니다.An AddAzureWebAppDiagnostics overload lets you pass in AzureAppServicesDiagnosticsSettings with which you can override default settings, such as the logging output template, blob name, and file size limit. (출력 템플릿ILogger 메서드를 호출할 때 제공하는 로그를 기반으로 모든 로그에 적용되는 메시지 템플릿입니다.)(Output template is a message template that's applied to all logs on top of the one that you provide when you call an ILogger method.)

App Service 앱에 배포할 때 앱은 Azure Portal에 있는 App Service 페이지의 진단 로그 섹션에 있는 설정을 따릅니다.When you deploy to an App Service app, the app honors the settings in the Diagnostic Logs section of the App Service page of the Azure portal. 이러한 설정을 업데이트하는 경우 앱을 다시 시작하거나 재배포하지 않아도 변경 내용은 즉시 적용됩니다.When these settings are updated, the changes take effect immediately without requiring a restart or redeployment of the app.

Azure 로깅 설정

로그 파일의 기본 위치는 D:\home\LogFiles\Application 폴더이며, 기본 파일 이름은 diagnostics-yyyymmdd.txt입니다.The default location for log files is in the D:\home\LogFiles\Application folder, and the default file name is diagnostics-yyyymmdd.txt. 기본 파일 크기 제한은 10MB이고, 보존되는 기본 최대 파일 수는 2입니다.The default file size limit is 10 MB, and the default maximum number of files retained is 2. 기본 BLOB 이름은 {app-name}{timestamp}/yyyy/mm/dd/hh/{guid}-applicationLog.txt입니다.The default blob name is {app-name}{timestamp}/yyyy/mm/dd/hh/{guid}-applicationLog.txt. 기본 동작에 대한 자세한 내용은 AzureAppServicesDiagnosticsSettings를 참조하세요.For more information about default behavior, see AzureAppServicesDiagnosticsSettings.

공급자는 프로젝트가 Azure 환경에서 실행되는 경우에만 작동합니다.The provider only works when the project runs in the Azure environment. 프로젝트를 로컬로 실행하는 경우에는 아무 영향도 없습니다—Blob에 대한 로컬 파일 또는 로컬 개발 저장소에 기록하지 않습니다.It has no effect when the project is run locally—it doesn't write to local files or local development storage for blobs.

타사 로깅 공급자Third-party logging providers

ASP.NET Core와 호환되는 타사 로깅 프레임워크는 다음과 같습니다.Third-party logging frameworks that work with ASP.NET Core:

일부 타사 프레임워크는 구조적 로깅이라고 하는 의미 체계 로깅을 수행할 수 있습니다.Some third-party frameworks can perform semantic logging, also known as structured logging.

타사 프레임워크를 사용하는 방법은 다음과 같이 기본 공급자 중 하나를 사용하는 방법과 비슷합니다.Using a third-party framework is similar to using one of the built-in providers:

  1. 프로젝트에 NuGet 패키지를 추가합니다.Add a NuGet package to your project.
  2. ILoggerFactory에 대한 확장 메서드를 호출합니다.Call an extension method on ILoggerFactory.

자세한 내용은 각 프레임워크의 설명서를 참조하십시오.For more information, see each framework's documentation.

Azure 로그 스트리밍Azure log streaming

Azure 로그 스트리밍을 통해 로그 작업을 실시간으로 볼 수 있습니다.Azure log streaming enables you to view log activity in real time from:

  • 응용 프로그램 서버The application server
  • 웹 서버The web server
  • 실패한 요청 추적Failed request tracing

Azure 로그 스트리밍을 구성하려면:To configure Azure log streaming:

  • 응용 프로그램의 포털 페이지에서 진단 로그 페이지로 이동합니다.Navigate to the Diagnostics Logs page from your application's portal page
  • 응용 프로그램 로깅(파일 시스템) 을 켭니다.Set Application Logging (Filesystem) to on.

Azure Portal 진단 로그 페이지

로그 스트리밍 페이지로 이동하여 응용 프로그램 메시지를 봅니다.Navigate to the Log Streaming page to view application messages. 응용 프로그램이 ILogger 인터페이스를 통해 기록한 것입니다.They're logged by application through the ILogger interface.

Azure Portal 응용 프로그램 로그 스트리밍

Azure Application Insights 추적 로깅Azure Application Insights trace logging

Application Insights SDK는 ASP.NET Core 로깅 인프라를 통해 생성된 로그에서 추적 원격 분석을 수집할 수 있습니다.The Application Insights SDK is capable of collecting trace telemetry from logs generated via the ASP.NET Core logging infrastructure. 자세한 내용은 ASP.NET Core용 Application InsightsMicrosoft/ApplicationInsights-aspnetcore Wiki: 로깅을 참조합니다.For more information, see Application Insights for ASP.NET Core and Microsoft/ApplicationInsights-aspnetcore Wiki: Logging.

추가 자료Additional resources