ASP.NET Core 로그인 소개Introduction to 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.

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

로그를 만들려면 가져오기는 ILogger 에서 개체는 종속성 주입 컨테이너:To create logs, get an ILogger 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에서는 비동기로 거 메서드 로깅 async 사용의 비용 보다 중요 없음을 빠른 이어야 하기 때문에 합니다.ASP.NET Core does not provide async logger methods because logging should be so fast that it isn't worth the cost of using async. true가 아니면 하는 상황에 있는 경우에 로그온 하는 방식을 변경 하는 것이 좋습니다.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 is 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 앱 서비스 공급자를 사용 하는 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.

공급자를 사용 하려면 공급자의 Add<ProviderName> 에 확장 메서드 Program.cs: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();
}

기본 프로젝트 템플릿은 위의 코드에서 참조 방식으로 로깅 설정 되지만 ConfigureLogging 호출 하면 됩니다는 CreateDefaultBuilder 메서드.The default project template sets up logging the way you see it in the preceding code, but the ConfigureLogging call is done by the CreateDefaultBuilder method. 다음은 코드 Program.cs 프로젝트 템플릿으로 만들어진:Here's the code in Program.cs that is created by project templates:

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

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

각각에 대 한 정보를 찾을 수 기본 제공 로깅 공급자 에 연결 하 고 제 3 자 로깅 공급자 는 문서의 뒷부분에 나오는 합니다.You'll find information about each built-in logging provider and links to third-party logging providers later in the article.

예제 로깅 출력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". ASP.NET Core에서 "Microsoft" 범주로 시작 하는 로그는 합니다.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 범주 를 만들면 각 로그에 포함 되어 있습니다.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. 범주 문자열을 지정 하려면 호출 CreateLoggerILoggerFactory 인스턴스를 다음과 같이 합니다.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;
    }

이 호출에 해당 하는 CreateLogger 의 정규화 된 형식 이름으로 T합니다.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 메서드가 정상적으로 종료 될 때 로그는 Warning 로그 메서드가 반환 하는 404가 반환 코드를 반환 하는 경우 및는 Error 예기치 않은 예외를 catch 하는 때를 기록 합니다.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. 첫 번째 매개 변수는 이벤트 ID를 로그 (이 문서의 뒷부분에 설명).The first parameter is the Log event ID (explained later in this article). 나머지 매개 변수는 로그 메시지 문자열을 생성 합니다.The remaining parameters construct a log message string.

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. 이러한 메서드 호출 내부적으로 Log 를 받는 메서드에 LogLevel 매개 변수입니다.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 is valuable only to a developer debugging an issue. 이러한 메시지는 중요 한 응용 프로그램 데이터 포함 하 고 있으므로 사용 하지 않아야 프로덕션 환경에서.These messages may contain sensitive application data and so should not 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 would not enable Debug level logs in production unless you are troubleshooting, due to the high volume of logs.

  • 정보 2 =Information = 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 do not 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 framework 씁니다 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를 표시 하지 않지만 콘솔 공급자 찍고 대괄호로 항목 뒤: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 format string

로그에 쓸 때마다 텍스트 메시지를 제공 합니다.Each time you write a log, you provide a text message. 메시지 문자열 인수에 값을 배치 하는 다음 예제 에서처럼 명명 된 자리 표시자를 포함할 수 있습니다.The message string can contain named placeholders into which argument values are placed, as in the following example:

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 for them. 예를 들어 다음과 같은 코드를 가정해 봅니다.For example, if you have the following code:

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

이 결과 로그 메시지는 다음과 같습니다.The resulting log message would look 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 string, logging providers can store the parameter values as fields in addition to the message string. 예를 들어 옮기는 경우 Azure 테이블 저장소에 로그를 출력 하 고로 거 메서드 호출은 다음과 같습니다.For example, if you are 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 테이블 엔터티를 가지기 IDRequestTime 속성으로, 로그 데이터에 대 한 쿼리를 단순화 합니다.Each Azure Table entity could have ID and RequestTime properties, which would simplify queries on log data. 특정 내에서 모든 로그를 찾을 수 RequestTime 문자 메시지의 시간 초과 구문 분석할 필요 없이 범위입니다.You could find all logs within a particular RequestTime range, without having 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 은 6 이며 보다 높은 LogLevel.Critical (5).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": {
    "IncludeScopes": false,
    "Debug": {
      "LogLevel": {
        "Default": "Information"
      }
    },
    "Console": {
      "LogLevel": {
        "Microsoft.AspNetCore.Mvc.Razor.Internal": "Warning",
        "Microsoft.AspNetCore.Mvc.Razor.Razor": "Debug",
        "Microsoft.AspNetCore.Mvc.Razor": "Error",
        "Default": "Information"
      }
    },
    "LogLevel": {
      "Default": "Debug"
    }
  }
}

이 JSON 디버그 공급자에 대해 하나씩, 모든 공급자에 적용 되는 개와 콘솔 공급자에 대 한 4 6 개의 필터 규칙을 만듭니다.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. 처음 여섯 개 구성 예제에서 제공 하 고 마지막 두 코드 예제에서 제공 합니다.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 오류Error
55 콘솔Console 모든 범주All categories 정보Information
66 모든 공급자All providers 모든 범주All categories 디버그Debug
77 모든 공급자All providers 시스템System 디버그Debug
98 디버그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.

예를 들어 앞의 규칙 목록 있고 만들면는 ILogger "Microsoft.AspNetCore.Mvc.Razor.RazorViewEngine" 범주에 대 한 개체: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 is easier to use. 기본 제공 공급자에 대 한 다음과 같은 별칭을 사용 합니다.For the built-in providers, use the following aliases:

  • 콘솔Console
  • 디버그Debug
  • 이벤트 로그EventLog
  • AzureAppServicesAzureAppServices
  • TraceSourceTraceSource
  • EventSourceEventSource

기본 최소 수준Default minimum level

지정 된 공급자 및 범주에 대 한 구성 또는 코드에서 규칙이 적용 하는 경우에 적용 되는 최소 수준 설정이 있습니다.There is 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();

기본값은 최소 수준을 명시적으로 설정 하지 않으면, Information, 즉 TraceDebug 로그는 무시 됩니다.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. Filter 함수는 모든 공급자 및 규칙 할당 하 여 구성 또는 코드를 갖지 않는 범주에 대해 호출 됩니다.A filter function is invoked for all providers and categories that do not 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();

로그 범위Log scopes

내에서 논리적 작업의 집합을 그룹화 수는 범위 해당 집합의 일부로 만들어진 각 로그에 동일한 데이터를 연결 하기 위해 합니다.You can group a set of logical operations within a scope in order to attach the same data to each log that is 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.

범위는는 IDisposable 에서 반환 되는 형식에서 ILogger.BeginScope<TState> 메서드와 삭제 될 때까지 유지 되는 기간.A scope is an IDisposable type that is returned by the ILogger.BeginScope<TState> method and lasts until it is 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:In Program.cs:

.ConfigureLogging((hostingContext, logging) =>
{
    logging.AddConfiguration(hostingContext.Configuration.GetSection("Logging"));
    logging.AddConsole(options => options.IncludeScopes = true);
    logging.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:

콘솔 공급자The console provider

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

logging.AddConsole()

디버그 공급자The 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()

EventSource 공급자The EventSource provider

ASP.NET Core 1.1.0을 대상으로 하는 앱에 대 한 또는 그 이상으로 Microsoft.Extensions.Logging.EventSource 공급자 패키지 이벤트 추적을 구현할 수 있습니다.For apps that target ASP.NET Core 1.1.0 or higher, 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()

수집 하 고 로그를 표시 하는 좋은 방법을 사용 하는 것은 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 추가 공급자

Nano Server에서 이벤트 캡처 몇 가지 추가 설정이 필요 합니다.Capturing events on Nano Server requires some additional setup:

  • PowerShell remoting Nano 서버에 연결 합니다.Connect PowerShell remoting to the Nano Server:

    Enter-PSSession [name]
    
  • ETW 세션을 만듭니다.Create an ETW session:

    New-EtwTraceSession -Name "MyAppTrace" -LocalFilePath C:\trace.etl
    
  • ETW 공급자에 대 한 추가 CLR, ASP.NET Core 및 필요에 따라 다른 사용자입니다.Add ETW providers for CLR, ASP.NET Core, and others as needed. GUID는 ASP.NET Core 공급자 3ac73b97-af73-50e9-0822-5da4367920d0합니다.The ASP.NET Core provider GUID is 3ac73b97-af73-50e9-0822-5da4367920d0.

    Add-EtwTraceProvider -Guid "{e13c0d23-ccbc-4e12-931b-d9cc2eee27e4}" -SessionName MyAppTrace
    Add-EtwTraceProvider -Guid "{3ac73b97-af73-50e9-0822-5da4367920d0}" -SessionName MyAppTrace
    
  • 사이트를 실행 하 고 추적 정보에 대 한 원하는 작업을 수행 합니다.Run the site and do whatever actions you want tracing information for.

  • 마치면 추적 세션을 중지 합니다.Stop the tracing session when you're finished:

    Stop-EtwTraceSession -Name "MyAppTrace"
    

그 결과 C:\trace.etl 다른 Windows 버전에서와 같이 PerfView와 파일을 분석할 수 있습니다.The resulting C:\trace.etl file can be analyzed with PerfView as on other editions of Windows.

Windows 이벤트 로그 공급자The 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()

TraceSource 공급자The 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);

오버 로드 AddTraceSource let 소스 스위치와 추적 수신기에 전달 합니다.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.

다음 예제에서는 구성는 TraceSource 기록 하는 공급자 Warning 및 콘솔 창에 더 높은 메시지입니다.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 앱 서비스 공급자The Azure App Service provider

Microsoft.Extensions.Logging.AzureAppServices 공급자 패키지 로그에는 Azure 앱 서비스 앱의 파일 시스템 및 텍스트 파일에 기록 blob 저장소 는 Azure 저장소 계정에 있습니다.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. 공급자는 ASP.NET Core 1.1.0을 대상으로 하는 앱에 대해서만 사용할 수 있는 이후인 있습니다.The provider is available only for apps that target ASP.NET Core 1.1.0 or higher.

참고

ASP.NET Core 2.0 미리 보기에는입니다.ASP.NET Core 2.0 is in preview. Azure 앱 서비스에 배포 될 때 최신 미리 보기 릴리스를 사용 하 여 만든 앱 실행 되지 않을 수 있습니다.Apps created with the latest preview release may not run when deployed to Azure App Service. Azure 앱 서비스 2.0을 실행은 ASP.NET 코어 2.0 출시 되 면 앱 및 Azure 앱 서비스 공급자는 여기에 설명 된 대로 작동 합니다.When ASP.NET Core 2.0 is released, Azure App Service will run 2.0 apps, and the Azure App Service provider will work as indicated here.

공급자 패키지 또는 호출 설치할 필요가 없습니다는 AddAzureWebAppDiagnostics 확장 메서드.You don't have to install the provider package or call the AddAzureWebAppDiagnostics extension method. 공급자가 Azure 앱 서비스에 앱을 배포할 때 응용 프로그램에 자동으로 사용할 수 있습니다.The provider is automatically available to your app when you deploy the app to Azure App Service.

응용 프로그램의 설정을 인식 앱 서비스 앱에 배포할 때의 진단 로그 의 섹션은 앱 서비스 Azure 포털의 페이지입니다.When you deploy to an App Service app, your application honors the settings in the Diagnostic Logs section of the App Service page of the Azure portal. 이러한 설정을 변경 하면 변경 내용이 즉시 적용 앱을 다시 시작 하거나 코드를 다시 배포 하지 않아도 됩니다.When you change those settings, the changes take effect immediately without requiring that you restart the app or redeploy code to it.

Azure 로깅 설정

로그 파일에 대 한 기본 위치는는 d:\홈\LogFiles\응용 프로그램 폴더가 고 기본 파일 이름은 진단 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 your project runs in the Azure environment. 영향을 주지 않습니다 로컬로 실행할 때 — 로컬 파일 또는 blob에 대 한 로컬 개발 저장소에 기록 하지 않습니다.It has no effect when you run locally — it does not write to local files or local development storage for blobs.

제 3 자 로깅 공급자Third-party logging providers

ASP.NET Core를 사용 하는 몇 가지 타사 로깅 프레임 워크는 다음과 같습니다.Here are some third-party logging frameworks that work with ASP.NET Core:

  • elmah.io -Elmah.Io 서비스 공급자elmah.io - provider for the Elmah.Io service

  • JSNLog -서버 쪽 로그에 JavaScript 예외 및 기타 클라이언트 쪽 이벤트를 기록 합니다.JSNLog - logs JavaScript exceptions and other client-side events in your server-side log.

  • Loggr -Loggr 서비스 공급자Loggr - provider for the Loggr service

  • NLog -NLog 라이브러리에 대 한 공급자NLog - provider for the NLog library

  • Serilog -Serilog 라이브러리에 대 한 공급자Serilog - provider for the Serilog library

일부 타사 프레임 워크에서는 작업을 수행할 수 구조적된 로깅 라고도 하는 의미 체계 로깅합니다.Some third-party frameworks can do semantic logging, also known as structured logging.

타사 프레임 워크를 사용 하는 것은 기본 제공 공급자 중 하나를 사용 하 여 비슷합니다: 프로젝트에 NuGet 패키지를 추가 하 고에 확장 메서드를 호출 ILoggerFactory합니다.Using a third-party framework is similar to using one of the built-in providers: add a NuGet package to your project and call an extension method on ILoggerFactory. 자세한 내용은 각 프레임 워크의 설명서를 참조 합니다.For more information, see each framework's documentation.

다른 로깅 프레임 워크 또는 사용자의 로깅 요구 사항을 지원 하기 위해 사용자 고유의 사용자 지정 공급자도 만들 수 있습니다.You can create your own custom providers as well, to support other logging frameworks or your own logging requirements.