.NET Core および ASP.NET Core でのログ記録Logging in .NET Core and ASP.NET Core

作成者: Tom DykstraSteve SmithBy Tom Dykstra and Steve Smith

.NET Core では、組み込みやサード パーティ製のさまざまなログ プロバイダーと連携するログ API がサポートされています。.NET Core supports a logging API that works with a variety of built-in and third-party logging providers. この記事では、組み込みプロバイダーと共にログ API を使用する方法について説明します。This article shows how to use the logging API with built-in providers.

この記事に記載されているほとんどのコード例は、ASP.NET Core アプリのものです。Most of the code examples shown in this article are from ASP.NET Core apps. これらのコード スニペットのログ記録固有の部分は、汎用ホストを使用するすべての .NET Core アプリに適用されます。The logging-specific parts of these code snippets apply to any .NET Core app that uses the Generic host. Web コンソール以外のアプリで汎用ホストを使用する方法については、ホステッド サービスに関する記事を参照してください。For information about how to use the Generic Host in non-web console apps, see Hosted services.

汎用ホストを使用しないアプリのログ記録コードは、プロバイダーの追加方法とロガーの作成方法によって異なります。Logging code for apps without Generic Host differs in the way providers are added and loggers are created. ホスト以外のコードの例については、記事のこれらのセクションを参照してください。Non-host code examples are shown in those sections of the article.

サンプル コードを表示またはダウンロードします (ダウンロード方法)。View or download sample code (how to download)

プロバイダーを追加するAdd providers

ログ プロバイダーによってログが表示または格納されます。A logging provider displays or stores logs. たとえば、Console プロバイダーによってコンソール上にログが表示され、Azure Application Insights プロバイダーによってそれらが Azure Application Insights に格納されます。For example, the Console provider displays logs on the console, and the Azure Application Insights provider stores them in Azure Application Insights. 複数のプロバイダーを追加することで、複数の宛先にログを送信することができます。Logs can be sent to multiple destinations by adding multiple providers.

汎用ホストを使用するアプリにプロバイダーを追加するには、Program.cs でプロバイダーの Add{provider name} 拡張メソッドを呼び出します。To add a provider in an app that uses Generic Host, call the provider's Add{provider name} extension method in Program.cs:

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

ホスト コンソール以外のアプリでは、LoggerFactory を作成するときにプロバイダーの Add{provider name} 拡張メソッドを呼び出します。In a non-host console app, call the provider's Add{provider name} extension method while creating a LoggerFactory:

var loggerFactory = LoggerFactory.Create(builder =>
{
    builder
        .AddFilter("Microsoft", LogLevel.Warning)
        .AddFilter("System", LogLevel.Warning)
        .AddFilter("LoggingConsoleApp.Program", LogLevel.Debug)
        .AddConsole()
        .AddEventLog();
});
ILogger logger = loggerFactory.CreateLogger<Program>();
logger.LogInformation("Example log message");

LoggerFactory および AddConsole には、Microsoft.Extensions.Logging 用に using ステートメントが必要です。LoggerFactory and AddConsole require a using statement for Microsoft.Extensions.Logging.

既定の ASP.NET Core プロジェクト テンプレートからは CreateDefaultBuilder が呼び出されます。これにより、次のログ プロバイダーが追加されます。The default ASP.NET Core project templates call CreateDefaultBuilder, which adds the following logging providers:

  • コンソールConsole
  • デバッグDebug
  • EventSourceEventSource
  • イベント ログ (Windows で実行されている場合のみ)EventLog (only when running on Windows)

既定のプロバイダーを自分で選択したものと置き換えることができます。You can replace the default providers with your own choices. ClearProviders を呼び出し、目的のプロバイダーを追加します。Call ClearProviders, and add the providers you want.

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

プロバイダーを追加するには、Program.cs でプロバイダーの Add{provider name} 拡張メソッドを呼び出します。To add a provider, call the provider's Add{provider name} 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) =>
        {
            // Requires `using Microsoft.Extensions.Logging;`
            logging.AddConfiguration(hostingContext.Configuration.GetSection("Logging"));
            logging.AddConsole();
            logging.AddDebug();
            logging.AddEventSourceLogger();
        })
        .UseStartup<Startup>()
        .Build();

    webHost.Run();
}

上記のコードには、Microsoft.Extensions.LoggingMicrosoft.Extensions.Configuration への参照が必要です。The preceding code requires references to Microsoft.Extensions.Logging and Microsoft.Extensions.Configuration.

既定のプロジェクト テンプレートでは、次のログ プロバイダーを追加する CreateDefaultBuilder が呼び出されます。The default project template calls CreateDefaultBuilder, which adds the following logging providers:

  • コンソールConsole
  • デバッグDebug
  • EventSource (ASP.NET Core 2.2 以降)EventSource (starting in ASP.NET Core 2.2)
public static void Main(string[] args)
{
    CreateWebHostBuilder(args).Build().Run();
}

public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
    WebHost.CreateDefaultBuilder(args)
        .UseStartup<Startup>();

CreateDefaultBuilder を使用する場合は、既定のプロバイダーを自分で選択したものと置き換えることができます。If you use CreateDefaultBuilder, you can replace the default providers with your own choices. ClearProviders を呼び出し、目的のプロバイダーを追加します。Call ClearProviders, and add the providers you want.

public static void Main(string[] args)
{
    var host = CreateWebHostBuilder(args).Build();

    var todoRepository = host.Services.GetRequiredService<ITodoRepository>();
    todoRepository.Add(new Core.Model.TodoItem() { Name = "Feed the dog" });
    todoRepository.Add(new Core.Model.TodoItem() { Name = "Walk the dog" });

    var logger = host.Services.GetRequiredService<ILogger<Program>>();
    logger.LogInformation("Seeded the database.");

    host.Run();
}

public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
    WebHost.CreateDefaultBuilder(args)
        .UseStartup<Startup>()
        .ConfigureLogging(logging =>
        {
            logging.ClearProviders();
            logging.AddConsole();
        });

この記事の後半では、組み込みログ プロバイダーサードパーティ製ログ プロバイダーについて説明します。Learn more about built-in logging providers and third-party logging providers later in the article.

ログを作成するCreate logs

ログを作成するには、ILogger<TCategoryName> オブジェクトを使用します。To create logs, use an ILogger<TCategoryName> object. Web アプリまたはホステッド サービスで、依存関係の挿入 (DI) から ILogger を取得します。In a web app or hosted service, get an ILogger from dependency injection (DI). ホスト コンソール以外のアプリでは、LoggerFactory を使用して ILogger を作成します。In non-host console apps, use the LoggerFactory to create an ILogger.

次の ASP.NET Core の例では、カテゴリが TodoApiSample.Pages.AboutModel のロガーを作成します。The following ASP.NET Core example creates a logger with TodoApiSample.Pages.AboutModel as the category. ログの "カテゴリ" は、各ログに関連付けられている文字列です。The log category is a string that is associated with each log. DI で提供される ILogger<T> インスタンスでは、カテゴリとして型 T の完全修飾名を持つログが作成されます。The ILogger<T> instance provided by DI creates logs that have the fully qualified name of type T as the category.

public class AboutModel : PageModel
{
    private readonly ILogger _logger;

    public AboutModel(ILogger<AboutModel> logger)
    {
        _logger = logger;
    }

次のホスト コンソール以外のアプリの例では、カテゴリが LoggingConsoleApp.Program のロガーを作成します。The following non-host console app example creates a logger with LoggingConsoleApp.Program as the category.

var loggerFactory = LoggerFactory.Create(builder =>
{
    builder
        .AddFilter("Microsoft", LogLevel.Warning)
        .AddFilter("System", LogLevel.Warning)
        .AddFilter("LoggingConsoleApp.Program", LogLevel.Debug)
        .AddConsole()
        .AddEventLog();
});
ILogger logger = loggerFactory.CreateLogger<Program>();
logger.LogInformation("Example log message");
public class AboutModel : PageModel
{
    private readonly ILogger _logger;

    public AboutModel(ILogger<AboutModel> logger)
    {
        _logger = logger;
    }

次の ASP.NET Core とコンソール アプリの例では、ロガーを使用して、レベルが Information のログを作成します。In the following ASP.NET Core and console app examples, the logger is used to create logs with Information as the level. ログの "レベル" は、ログに記録されるイベントの重大度を示します。The Log level indicates the severity of the logged event.

public void OnGet()
{
    Message = $"About page visited at {DateTime.UtcNow.ToLongTimeString()}";
    _logger.LogInformation("Message displayed: {Message}", Message);
}
var loggerFactory = LoggerFactory.Create(builder =>
{
    builder
        .AddFilter("Microsoft", LogLevel.Warning)
        .AddFilter("System", LogLevel.Warning)
        .AddFilter("LoggingConsoleApp.Program", LogLevel.Debug)
        .AddConsole()
        .AddEventLog();
});
ILogger logger = loggerFactory.CreateLogger<Program>();
logger.LogInformation("Example log message");
public void OnGet()
{
    Message = $"About page visited at {DateTime.UtcNow.ToLongTimeString()}";
    _logger.LogInformation("Message displayed: {Message}", Message);
}

レベルカテゴリの詳細については、この記事で後ほど説明します。Levels and categories are explained in more detail later in this article.

Program クラスでログを作成するCreate logs in the Program class

ASP.NET Core アプリの Program クラスでログを書き込むには、ホストをビルドした後に DI から ILogger インスタンスを取得します。To write logs in the Program class of an ASP.NET Core app, get an ILogger instance from DI after building the host:

public static void Main(string[] args)
{
    var host = CreateHostBuilder(args).Build();

    var todoRepository = host.Services.GetRequiredService<ITodoRepository>();
    todoRepository.Add(new Core.Model.TodoItem() { Name = "Feed the dog" });
    todoRepository.Add(new Core.Model.TodoItem() { Name = "Walk the dog" });

    var logger = host.Services.GetRequiredService<ILogger<Program>>();
    logger.LogInformation("Seeded the database.");

    IMyService myService = host.Services.GetRequiredService<IMyService>();
    myService.WriteLog("Logged from MyService.");

    host.Run();
}

Startup クラスでログを作成するCreate logs in the Startup class

ASP.NET Core アプリの Startup.Configure メソッドでログを書き込むには、メソッド シグネチャに ILogger パラメーターを含めます。To write logs in the Startup.Configure method of an ASP.NET Core app, include an ILogger parameter in the method signature:

public void Configure(IApplicationBuilder app, IHostEnvironment env, ILogger<Startup> logger)
{
    if (env.IsDevelopment())
    {
        logger.LogInformation("In Development environment");
        app.UseDeveloperExceptionPage();
    }
    else
    {
        app.UseExceptionHandler("/Error");
        app.UseHsts();
    }

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

    app.UseRouting();

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

Startup.ConfigureServices メソッドでの DI コンテナーの設定が完了する前にログを書き込むことはサポートされていません。Writing logs before completion of the DI container setup in the Startup.ConfigureServices method is not supported:

  • Startup コンストラクターへのロガーの挿入はサポートされていません。Logger injection into the Startup constructor is not supported.
  • Startup.ConfigureServices メソッド シグネチャへのロガーの挿入はサポートされていませんLogger injection into the Startup.ConfigureServices method signature is not supported

この制限の理由は、ログ記録は DI と構成に依存しており、さらに構成は DI に依存しているためです。The reason for this restriction is that logging depends on DI and on configuration, which in turns depends on DI. DI コンテナーは、ConfigureServices が完了するまで設定されません。The DI container isn't set up until ConfigureServices finishes.

ASP.NET Core の以前のバージョンでは Web ホスト用に別の DI コンテナーが作成されるため、ロガーの Startup へのコンストラクター挿入が機能します。Constructor injection of a logger into Startup works in earlier versions of ASP.NET Core because a separate DI container is created for the Web Host. 汎用ホストに対して 1 つのコンテナーのみが作成される理由については、破壊的変更に関するお知らせに関する記事を参照してください。For information about why only one container is created for the Generic Host, see the breaking change announcement.

ILogger<T> に依存するサービスを構成する必要がある場合でも、コンストラクターの挿入を使用するか、ファクトリ メソッドを用意して行うことができます。If you need to configure a service that depends on ILogger<T>, you can still do that by using constructor injection or by providing a factory method. ファクトリ メソッドの方法は、他の選択肢がない場合にのみお勧めします。The factory method approach is recommended only if there is no other option. たとえば、DI のサービスを使用してプロパティを設定する必要があるとします。For example, suppose you need to fill a property with a service from DI:

public void ConfigureServices(IServiceCollection services)
{
    services.AddControllers();
    services.AddRazorPages();

    services.AddSingleton<IMyService>((container) =>
    {
        var logger = container.GetRequiredService<ILogger<MyService>>();
        return new MyService() { Logger = logger };
    });

    services.AddSingleton<ITodoRepository, TodoRepository>();
}

前の強調表示されているコードは、DI コンテナーで MyService のインスタンスが初めて作成されるときに実行される Func です。The preceding highlighted code is a Func that runs the first time the DI container needs to construct an instance of MyService. この方法では、任意の登録済みサービスにアクセスできます。You can access any of the registered services in this way.

Startup でログを作成するCreate logs in Startup

Startup クラスでログを作成するには、コンストラクター シグネチャに ILogger パラメーターを追加します。To write logs in the Startup class, include an ILogger parameter in the constructor signature:

public class Startup
{
    private readonly ILogger _logger;

    public Startup(IConfiguration configuration, ILogger<Startup> logger)
    {
        Configuration = configuration;
        _logger = logger;
    }

    public IConfiguration Configuration { get; }

    public void ConfigureServices(IServiceCollection services)
    {
        services.AddMvc()
            .SetCompatibilityVersion(CompatibilityVersion.Version_2_2);

        // Add our repository type
        services.AddSingleton<ITodoRepository, TodoRepository>();
        _logger.LogInformation("Added TodoRepository to services");
    }

    public void Configure(IApplicationBuilder app, IHostingEnvironment env)
    {
        if (env.IsDevelopment())
        {
            _logger.LogInformation("In Development environment");
            app.UseDeveloperExceptionPage();
        }
        else
        {
            app.UseExceptionHandler("/Error");
            app.UseHsts();
        }

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

        app.UseMvc();
    }
}

Program クラスでログを作成するCreate logs in the Program class

Program クラスでログを作成するには、DI から ILogger インスタンスを取得します。To write logs in the Program class, get an ILogger instance from DI:

public static void Main(string[] args)
{
    var host = CreateWebHostBuilder(args).Build();

    var todoRepository = host.Services.GetRequiredService<ITodoRepository>();
    todoRepository.Add(new Core.Model.TodoItem() { Name = "Feed the dog" });
    todoRepository.Add(new Core.Model.TodoItem() { Name = "Walk the dog" });

    var logger = host.Services.GetRequiredService<ILogger<Program>>();
    logger.LogInformation("Seeded the database.");

    host.Run();
}

public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
    WebHost.CreateDefaultBuilder(args)
        .UseStartup<Startup>()
        .ConfigureLogging(logging =>
        {
            logging.ClearProviders();
            logging.AddConsole();
        });

非同期でないロガー メソッドNo asynchronous logger methods

ログ記録は高速に実行され、非同期コードのパフォーマンス コストを下回る必要があります。Logging should be so fast that it isn't worth the performance cost of asynchronous code. ログ記録のデータ ストアが低速の場合は、そこへ直接書き込むべきではありません。If your logging data store is slow, don't write to it directly. まずログ メッセージを高速なストアに書き込んでから、後で低速なストアに移動する方法を検討してください。Consider writing the log messages to a fast store initially, then move them to the slow store later. たとえば、SQL Server にログインしている場合、それを Log メソッドで直接実行したくはないでしょう。Log が同期メソッドであるためです。For example, if you're logging to SQL Server, you don't want to do that directly in a Log method, since the Log methods are synchronous. 代わりに、ログ メッセージをインメモリ キューに同期的に追加し、バックグラウンド ワーカーにキューからメッセージをプルさせて、SQL Server にデータをプッシュする非同期処理を実行させます。Instead, synchronously add log messages to an in-memory queue and have a background worker pull the messages out of the queue to do the asynchronous work of pushing data to SQL Server.

構成Configuration

ログ プロバイダーの構成は、1 つまたは複数の構成プロバイダーによって提供されます。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
    }
  }
}

Logging プロパティには LogLevel およびログ プロバイダーのプロパティ (Console が示されています) を含めることができます。The Logging property can have LogLevel and log provider properties (Console is shown).

Logging の下の LogLevel プロパティでは、選択したカテゴリに対するログの最小のレベルが指定されます。The LogLevel property under Logging specifies the minimum level to log for selected categories. この例では、SystemMicrosoft カテゴリが Information レベルで、その他はすべて Debug レベルでログに記録します。In the example, System and Microsoft categories log at Information level, and all others log at Debug level.

Logging の下のその他のプロパティではログ プロバイダーが指定されます。Other properties under Logging specify logging providers. この例では、Console プロバイダーです。The example is for the Console provider. プロバイダーでログのスコープがサポートされている場合、IncludeScopes によってそれを有効にするかどうかが指定されます。If a provider supports log scopes, IncludeScopes indicates whether they're enabled. プロバイダーのプロパティ (例の Console など) では、LogLevel プロパティが指定される場合があります。A provider property (such as Console in the example) may also specify a LogLevel property. プロバイダーの下の LogLevel では、そのプロバイダーのログのレベルが指定されます。LogLevel under a provider specifies levels to log for that provider.

Logging.{providername}.LogLevel でレベルが指定される場合、それによって Logging.LogLevel で設定されたものはすべてオーバーライドされます。If levels are specified in Logging.{providername}.LogLevel, they override anything set in Logging.LogLevel.

構成プロバイダーの実装について詳しくは、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, logs appear in the console when the app is run from the command line. コンソールの出力例は次のとおりです。Here's an example of console output:

info: Microsoft.AspNetCore.Hosting.Diagnostics[1]
      Request starting HTTP/1.1 GET http://localhost:5000/api/todo/0
info: Microsoft.AspNetCore.Hosting.Diagnostics[2]
      Request finished in 84.26180000000001ms 307
info: Microsoft.AspNetCore.Hosting.Diagnostics[1]
      Request starting HTTP/2 GET https://localhost:5001/api/todo/0
info: Microsoft.AspNetCore.Routing.EndpointMiddleware[0]
      Executing endpoint 'TodoApiSample.Controllers.TodoController.GetById (TodoApiSample)'
info: Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker[3]
      Route matched with {action = "GetById", controller = "Todo", page = ""}. Executing controller action with signature Microsoft.AspNetCore.Mvc.IActionResult GetById(System.String) on controller TodoApiSample.Controllers.TodoController (TodoApiSample).
info: TodoApiSample.Controllers.TodoController[1002]
      Getting item 0
warn: TodoApiSample.Controllers.TodoController[4000]
      GetById(0) NOT FOUND
info: Microsoft.AspNetCore.Mvc.StatusCodeResult[1]
      Executing HttpStatusCodeResult, setting HTTP status code 404
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 のサンプル アプリに向けて HTTP Get 要求を作成することで生成されました。The preceding logs were generated by making an HTTP Get request to the sample app at http://localhost:5000/api/todo/0.

Visual Studio でサンプル アプリを実行したときに [デバッグ] ウィンドウに表示されるログと同じログの例を、次に示します。Here's an example of the same logs as they appear in the Debug window when you run the sample app in Visual Studio:

Microsoft.AspNetCore.Hosting.Diagnostics: Information: Request starting HTTP/2.0 GET https://localhost:44328/api/todo/0  
Microsoft.AspNetCore.Routing.EndpointMiddleware: Information: Executing endpoint 'TodoApiSample.Controllers.TodoController.GetById (TodoApiSample)'
Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker: Information: Route matched with {action = "GetById", controller = "Todo", page = ""}. Executing controller action with signature Microsoft.AspNetCore.Mvc.IActionResult GetById(System.String) on controller TodoApiSample.Controllers.TodoController (TodoApiSample).
TodoApiSample.Controllers.TodoController: Information: Getting item 0
TodoApiSample.Controllers.TodoController: Warning: GetById(0) NOT FOUND
Microsoft.AspNetCore.Mvc.StatusCodeResult: Information: Executing HttpStatusCodeResult, setting HTTP status code 404
Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker: Information: Executed action TodoApiSample.Controllers.TodoController.GetById (TodoApiSample) in 34.167ms
Microsoft.AspNetCore.Routing.EndpointMiddleware: Information: Executed endpoint 'TodoApiSample.Controllers.TodoController.GetById (TodoApiSample)'
Microsoft.AspNetCore.Hosting.Diagnostics: Information: Request finished in 98.41300000000001ms 404

前のセクションで紹介した ILogger の呼び出しで作成されるログは、"TodoApiSample" から始まります。The logs that are created by the ILogger calls shown in the preceding section begin with "TodoApiSample". "Microsoft" カテゴリから始まるログは、ASP.NET Core のフレームワークのコードからのログです。The logs that begin with "Microsoft" categories are from ASP.NET Core framework code. ASP.NET Core とアプリケーション コードでは、同じログ API とログ プロバイダーが使用されています。ASP.NET Core and application code are using the same logging API and providers.

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" から始まります。The logs that are created by the ILogger calls shown in the preceding section begin with "TodoApi". "Microsoft" カテゴリから始まるログは、ASP.NET Core のフレームワークのコードからのログです。The logs that begin with "Microsoft" categories are from ASP.NET Core framework code. ASP.NET Core とアプリケーション コードでは、同じログ API とログ プロバイダーが使用されています。ASP.NET Core and application code are using the same logging API and providers.

以降、この記事では、ログ記録の詳細とオプションについて説明します。The remainder of this article explains some details and options for logging.

NuGet パッケージNuGet packages

ILogger および ILoggerFactory インターフェイスは、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

ILogger オブジェクトが作成されるときに、その "カテゴリ" が指定されます。When an ILogger object is created, a category is specified for it. このカテゴリは、その ILogger のインスタンスによって作成される各ログ メッセージと共に含められます。That category is included with each log message created by that instance of ILogger. カテゴリには任意の文字列を指定できますが、"TodoApi.Controllers.TodoController" などのクラス名を使用するが慣例です。The category may be any string, but the convention is to use the class name, such as "TodoApi.Controllers.TodoController".

ILogger<T> を使用して、カテゴリとして T の完全修飾型名が使用される ILogger インスタンスを取得します。Use ILogger<T> to get an ILogger instance that uses the fully qualified type name of T as the category:

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

    public TodoController(ITodoRepository todoRepository,
        ILogger<TodoController> logger)
    {
        _todoRepository = todoRepository;
        _logger = logger;
    }
public class TodoController : Controller
{
    private readonly ITodoRepository _todoRepository;
    private readonly ILogger _logger;

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

カテゴリを明示的に指定するには、ILoggerFactory.CreateLogger を呼び出します。To explicitly specify the category, call ILoggerFactory.CreateLogger:

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

    public TodoController(ITodoRepository todoRepository,
        ILoggerFactory logger)
    {
        _todoRepository = todoRepository;
        _logger = logger.CreateLogger("TodoApiSample.Controllers.TodoController");
    }
public class TodoController : Controller
{
    private readonly ITodoRepository _todoRepository;
    private readonly ILogger _logger;

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

ILogger<T> は、T の完全修飾型名を使用した CreateLogger の呼び出しと同じです。ILogger<T> is equivalent to calling CreateLogger with the fully qualified type name of T.

ログ レベルLog level

すべてのログで LogLevel 値が指定されます。Every log specifies a LogLevel value. ログ レベルは、重大度または重要度を示します。The log level indicates the severity or importance. たとえば、メソッドが正常に終了した場合は Information ログを、メソッドが 404 Not Found 状態コードを返した場合は Warning ログを書き込む場合があります。For example, you might write an Information log when a method ends normally and a Warning log when a method returns a 404 Not Found status code.

Information および Warning ログを作成するコードを次に示します。The following code creates Information and Warning logs:

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 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);
}

前のコードでは、最初のパラメーターはログ イベント ID です。In the preceding code, the first parameter is the Log event ID. 2 つ目のパラメーターは、他のメソッド パラメーターによって提供される引数値のプレースホルダーを含むメッセージ テンプレートです。The second parameter is a message template with placeholders for argument values provided by the remaining method parameters. メソッド パラメーターについては、この記事の後半のメッセージ テンプレートのセクションで説明します。The method parameters are explained in the message template section later in this article.

メソッド名にレベルを含むログ メソッド (たとえば LogInformationLogWarning) は、ILogger の拡張メソッドです。Log methods that include the level in the method name (for example, LogInformation and LogWarning) are extension methods for ILogger. これらのメソッドでは、LogLevel パラメーターを受け取る Log メソッドが呼び出されます。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 ILogger and the logger extensions source code.

ASP.NET Core には、次のログ レベルが定義されています (重大度の低いものから高い順)。ASP.NET Core defines the following log levels, ordered here from lowest to highest severity.

  • Trace = 0Trace = 0

    通常はデバッグでのみ役立つ情報の場合。For information that's typically valuable only for debugging. これらのメッセージには機密性の高いアプリケーション データが含まれる可能性があるため、運用環境は有効にしないことをお勧めします。These messages may contain sensitive application data and so shouldn't be enabled in a production environment. 既定で無効です。Disabled by default.

  • Debug = 1Debug = 1

    開発とデバッグで役立つ可能性がある情報の場合。For information that may be useful in development and debugging. 例:Entering method Configure with flag set to true. Debug レベルのログは、ログのサイズが大きくなるため、トラブルシューティングの場合を除き運用環境では有効にしません。Example: Entering method Configure with flag set to true. Enable Debug level logs in production only when troubleshooting, due to the high volume of logs.

  • Information = 2Information = 2

    アプリの一般的なフローを追跡する場合。For tracking the general flow of the app. 通常、これらのログには、長期的な値があります。These logs typically have some long-term value. 例 : Request received for path /api/todoExample: Request received for path /api/todo

  • Warning = 3Warning = 3

    アプリのフローで異常なイベントや予期しないイベントが発生した場合。For abnormal or unexpected events in the app flow. アプリの停止の原因にはならないが、調査する必要があるエラーやその他の状態がここに含まれる場合があります。These may include errors or other conditions that don't cause the app to stop but might 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.

  • Error = 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 app-wide failure. ログ メッセージの例: Cannot insert record due to duplicate key violation.Example log message: Cannot insert record due to duplicate key violation.

  • Critical = 5Critical = 5

    即時の注意が必要なエラーの場合。For failures that require immediate attention. 例: データ損失のシナリオ、ディスク領域不足。Examples: data loss scenarios, out of disk space.

ログ レベルを使用して、特定のストレージ メディアまたは表示ウィンドウに書き込むログの出力量を制御します。Use the log level to control how much log output is written to a particular storage medium or display window. 次に例を示します。For example:

  • 運用環境では、Information レベルを使用してボリューム データ ストアに Trace を送信します。In production, send Trace through Information level to a volume data store. Critical を使用して値のデータ ストアに Warning を送信します。Send Warning through Critical to a value data store.
  • 開発中は Critical を使用してコンソールに Warning を送信し、トラブルシューティングの際は Information を使用して Trace を追加します。During development, send Warning through Critical to the console, and add Trace through Information when troubleshooting.

この記事で後述する「ログのフィルター処理」セクションでは、プロバイダーで処理するログ レベルの制御方法について説明します。The Log filtering section later in this article explains how to control which log levels a provider handles.

ASP.NET Core では、フレームワーク イベントのログが書き込まれます。ASP.NET Core writes logs for framework events. この記事の前のログの例では、Information レベル以下のログを除外したため、Debug または Trace レベルのログは作成されませんでした。The log examples earlier in this article excluded logs below Information level, so no Debug or Trace level logs were created. Debug ログを示すために構成したサンプル アプリを実行することで生成されるコンソールのログの例を、次に示します。Here's an example of console logs produced by running the sample app configured to show Debug logs:

info: Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker[3]
      Route matched with {action = "GetById", controller = "Todo", page = ""}. Executing controller action with signature Microsoft.AspNetCore.Mvc.IActionResult GetById(System.String) on controller TodoApiSample.Controllers.TodoController (TodoApiSample).
dbug: Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker[1]
      Execution plan of authorization filters (in the following order): None
dbug: Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker[1]
      Execution plan of resource filters (in the following order): Microsoft.AspNetCore.Mvc.ViewFeatures.Filters.SaveTempDataFilter
dbug: Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker[1]
      Execution plan of action filters (in the following order): Microsoft.AspNetCore.Mvc.Filters.ControllerActionFilter (Order: -2147483648), Microsoft.AspNetCore.Mvc.ModelBinding.UnsupportedContentTypeFilter (Order: -3000)
dbug: Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker[1]
      Execution plan of exception filters (in the following order): None
dbug: Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker[1]
      Execution plan of result filters (in the following order): Microsoft.AspNetCore.Mvc.ViewFeatures.Filters.SaveTempDataFilter
dbug: Microsoft.AspNetCore.Mvc.ModelBinding.ParameterBinder[22]
      Attempting to bind parameter 'id' of type 'System.String' ...
dbug: Microsoft.AspNetCore.Mvc.ModelBinding.Binders.SimpleTypeModelBinder[44]
      Attempting to bind parameter 'id' of type 'System.String' using the name 'id' in request data ...
dbug: Microsoft.AspNetCore.Mvc.ModelBinding.Binders.SimpleTypeModelBinder[45]
      Done attempting to bind parameter 'id' of type 'System.String'.
dbug: Microsoft.AspNetCore.Mvc.ModelBinding.ParameterBinder[23]
      Done attempting to bind parameter 'id' of type 'System.String'.
dbug: Microsoft.AspNetCore.Mvc.ModelBinding.ParameterBinder[26]
      Attempting to validate the bound parameter 'id' of type 'System.String' ...
dbug: Microsoft.AspNetCore.Mvc.ModelBinding.ParameterBinder[27]
      Done attempting to validate the bound parameter 'id' of type 'System.String'.
info: TodoApiSample.Controllers.TodoController[1002]
      Getting item 0
warn: TodoApiSample.Controllers.TodoController[4000]
      GetById(0) NOT FOUND
info: Microsoft.AspNetCore.Mvc.StatusCodeResult[1]
      Executing HttpStatusCodeResult, setting HTTP status code 404
info: Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker[2]
      Executed action TodoApiSample.Controllers.TodoController.GetById (TodoApiSample) in 32.690400000000004ms
info: Microsoft.AspNetCore.Routing.EndpointMiddleware[1]
      Executed endpoint 'TodoApiSample.Controllers.TodoController.GetById (TodoApiSample)'
info: Microsoft.AspNetCore.Hosting.Diagnostics[2]
      Request finished in 176.9103ms 404
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 log 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;
}
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 associates a set of events. たとえば、ページ上に項目の一覧を表示する機能に関連するすべてのログを 1001 に設定します。For example, all logs related to displaying a list of items on a page might be 1001.

ログ プロバイダーでは、ID フィールドやログ メッセージにイベント ID が格納されたり、またはまったく格納されなかったりする場合があります。The logging provider may store the event ID in an ID field, in the logging message, or not at all. Debug プロバイダーでイベント ID が表示されることはありません。The Debug provider doesn't show event IDs. Console プロバイダーでは、カテゴリの後のブラケット内にイベント ID が表示されます。The console provider shows event IDs 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 log specifies a message template. メッセージ テンプレートには、指定される引数のためのプレースホルダーを含めることができます。The message template can contain placeholders for which arguments are provided. プレースホルダーには、数値ではなく名前を使用します。Use names for the placeholders, not numbers.

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 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. 次のコードでは、パラメーター名がメッセージ テンプレート内のシーケンスの外にあることに注意してください。In the following code, notice that the parameter names are out of sequence in the message template:

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

このコードでは、シーケンス内のパラメーター値を含むログ メッセージが作成されます。This code creates a log message with the parameter values in sequence:

Parameter values: parm1, parm2

ログ プロバイダーがセマンティック ログ記録 (または構造化ログ記録)を実装できるようにするために、ログ フレームワークはこのように動作します。The logging framework works this way so that logging providers can implement semantic logging, also known as structured logging. 書式設定されたメッセージ テンプレートだけでなく、引数自体がログ システムに渡されます。The arguments themselves are passed to the logging system, not just the formatted message template. この情報により、ログ プロバイダーはフィールドとしてパラメーター値を格納することができます。This information enables logging providers to store the parameter values as fields. たとえば、つぎのようなロガー メソッドの呼び出しがあるとします。For example, suppose logger method calls look like this:

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

Azure Table Storage にログを送信する場合、各 Azure Table エンティティに ID および RequestTime プロパティを指定し、ログ データのクエリを簡略化することができます。If you're sending the logs to Azure Table Storage, each Azure Table entity can have ID and RequestTime properties, which simplifies queries on log data. クエリによって指定した RequestTime の範囲内のすべてのログを検索できます。テキスト メッセージから時間を解析する必要はありません。A query can find all logs within a particular RequestTime range without parsing 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);
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. 前述のコードの Debug プロバイダーの出力の例を次に示します。Here's an example of Debug provider output from the code shown above.

TodoApiSample.Controllers.TodoController: Warning: GetById(55) NOT FOUND

System.Exception: Item not found exception.
   at TodoApiSample.Controllers.TodoController.GetById(String id) in C:\TodoApiSample\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 を指定します。To suppress all logs, 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 が呼び出され、Console プロバイダーと Debug プロバイダーのログ記録が設定されます。The project template code calls CreateDefaultBuilder to set up logging for the Console and Debug providers. Loggingこの記事で既に説明したように、CreateDefaultBuilder メソッドでは、 セクションで構成を検索するようにログが設定されます。The CreateDefaultBuilder method sets up logging to look for configuration in a Logging section, as explained earlier in this article.

次の例のように、構成データでは、プロバイダーとカテゴリごとに最小ログ レベルを指定します。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"
    }
  }
}
{
  "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 個のフィルター規則を作成します。1 つは Debug プロバイダー用、4 つは Console プロバイダー用、1 つはすべてのプロバイダー用です。This JSON creates six filter rules: one for the Debug provider, four for the Console provider, and one for all providers. ILogger オブジェクトが作成されると、各プロバイダーに対して 1 つの規則が選択されます。A single rule is chosen for each provider when an ILogger object is created.

コードのフィルター規則Filter rules in code

コードにフィルター規則を登録する方法を次の例に示します。The following example shows how to register filter rules in code:

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

2 つ目の AddFilter では、プロバイダーの種類名を使用して Debug プロバイダーを指定します。The second AddFilter specifies the Debug provider by using its type name. 1 つ目の 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 オブジェクトによって、そのロガーに適用するプロバイダーごとに 1 つの規則が選択されます。When an ILogger object is created, the ILoggerFactory object selects a single rule per provider to apply to that logger. ILogger インスタンスによって書き込まれるすべてのメッセージは、選択した規則に基づいてフィルター処理されます。All messages written by an ILogger instance 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 no match is found, select all rules with an empty provider.
  • 前の手順の結果、最も長いカテゴリのプレフィックスが一致する規則が選択されます。From the result of the preceding step, select rules with longest matching category prefix. 一致が見つからない場合は、カテゴリを指定しないすべての規則が選択されます。If no match is found, select all rules that don't specify a category.
  • 複数の規則が選択されている場合は、最後の 1 つが使用されます。If multiple rules are selected, take the last one.
  • 規則が選択されていない場合は、MinimumLevel が使用されます。If no rules are selected, use MinimumLevel.

前の規則一覧を使用して、カテゴリ "Microsoft.AspNetCore.Mvc.Razor.RazorViewEngine" に ILogger オブジェクトを作成するとします。With the preceding list of rules, suppose you create an ILogger object for category "Microsoft.AspNetCore.Mvc.Razor.RazorViewEngine":

  • Debug プロバイダーの場合、規則 1、6、8 が適用されます。For the Debug provider, rules 1, 6, and 8 apply. 規則 8 が最も限定的なので、規則 8 が選択されます。Rule 8 is most specific, so that's the one selected.
  • Console プロバイダーの場合、規則 3、4、5、6 が適用されます。For the Console provider, rules 3, 4, 5, and 6 apply. 規則 3 が最も限定的です。Rule 3 is most specific.

作成される ILogger インスタンスでは、Debug プロバイダーに Trace レベル以上のログが送信されます。The resulting ILogger instance sends logs of Trace level and above to the Debug provider. Debug レベル以上のログが Console プロバイダーに送信されます。Logs of Debug level and above are sent to the Console provider.

プロバイダーのエイリアスProvider aliases

各プロバイダーでは "エイリアス" が定義されます。これは構成で完全修飾型名の代わりに使用できます。Each provider defines an alias that can be used in configuration in place of the fully qualified type name. 組み込みのプロバイダーの場合は、次のエイリアスを使用してください。For the built-in providers, use the following aliases:

  • コンソールConsole
  • デバッグDebug
  • EventSourceEventSource
  • EventLogEventLog
  • TraceSourceTraceSource
  • AzureAppServicesFileAzureAppServicesFile
  • AzureAppServicesBlobAzureAppServicesBlob
  • ApplicationInsightsApplicationInsights

既定の最小レベル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:

public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
        .ConfigureLogging(logging => logging.SetMinimumLevel(LogLevel.Warning))
WebHost.CreateDefaultBuilder(args)
    .UseStartup<Startup>()
    .ConfigureLogging(logging => logging.SetMinimumLevel(LogLevel.Warning));

最小レベルを明示的に設定しない場合、既定値は Information です。これは、Trace および Debug ログが無視されることを意味します。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

フィルター関数は、構成またはコードによって規則が割り当てられていないすべてのプロバイダーとカテゴリについて呼び出されます。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. 次に例を示します。For example:

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

システムのカテゴリとレベルSystem categories and levels

ASP.NET Core と Entity Framework Core によって使用されるいくつかのカテゴリと、それらから想定されるログの種類に関するメモを、次に示します。Here are some categories used by ASP.NET Core and Entity Framework Core, with notes about what logs to expect from them:

カテゴリCategory メモNotes
Microsoft.AspNetCoreMicrosoft.AspNetCore ASP.NET Core の一般的な診断。General ASP.NET Core diagnostics.
Microsoft.AspNetCore.DataProtectionMicrosoft.AspNetCore.DataProtection どのキーが検討、検索、および使用されたか。Which keys were considered, found, and used.
Microsoft.AspNetCore.HostFilteringMicrosoft.AspNetCore.HostFiltering 許可されるホスト。Hosts allowed.
Microsoft.AspNetCore.HostingMicrosoft.AspNetCore.Hosting HTTP 要求が完了するまでにかかった時間と、それらの開始時刻。How long HTTP requests took to complete and what time they started. どのホスティング スタートアップ アセンブリが読み込まれたか。Which hosting startup assemblies were loaded.
Microsoft.AspNetCore.MvcMicrosoft.AspNetCore.Mvc MVC と Razor の診断。MVC and Razor diagnostics. モデルの構築、フィルター処理の実行、ビューのコンパイル、アクションの選択。Model binding, filter execution, view compilation, action selection.
Microsoft.AspNetCore.RoutingMicrosoft.AspNetCore.Routing 一致する情報をルーティングします。Route matching information.
Microsoft.AspNetCore.ServerMicrosoft.AspNetCore.Server 接続の開始、停止、キープ アライブ応答。Connection start, stop, and keep alive responses. HTTPS 証明書情報。HTTPS certificate information.
Microsoft.AspNetCore.StaticFilesMicrosoft.AspNetCore.StaticFiles 提供されるファイル。Files served.
Microsoft.EntityFrameworkCoreMicrosoft.EntityFrameworkCore Entity Framework Core の一般的な診断。General Entity Framework Core diagnostics. データベースのアクティビティと構成、変更の検出、移行。Database activity and configuration, change detection, migrations.

ログのスコープLog scopes

"スコープ" では、論理操作のセットをグループ化できます。A scope can group a set of logical operations. このグループ化を使用して、セットの一部として作成される各ログに同じデータをアタッチすることができます。This grouping can be used to attach the same data to each log that's created as part of a set. たとえば、トランザクション処理の一部として作成されるすべてのログに、トランザクション ID を含めることができます。For example, every log created as part of processing a transaction can include the transaction ID.

スコープは BeginScope メソッドから返される IDisposable の種類であり、破棄されるまで継続します。A scope is an IDisposable type that's returned by the BeginScope method and lasts until it's disposed. ロガーの呼び出しを using ブロックでラップすることによって、スコープを使用します。Use a scope by wrapping logger calls in a using block:

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);
}
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);
}

次のコードでは、Console プロバイダーのスコープを有効にしています。The following code enables scopes for the console provider:

Program.cs:Program.cs:

public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
        .ConfigureLogging((hostingContext, logging) =>
        {
            logging.ClearProviders();
            logging.AddConsole(options => options.IncludeScopes = true);
            logging.AddDebug();
        })
        .ConfigureWebHostDefaults(webBuilder =>
        {
            webBuilder.UseStartup<Startup>();
        });
.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.

各ログ メッセージには、スコープ内の情報が含まれます。Each log message includes the scoped information:

info: TodoApiSample.Controllers.TodoController[1002]
      => RequestId:0HKV9C49II9CK RequestPath:/api/todo/0 => TodoApiSample.Controllers.TodoController.GetById (TodoApi) => Message attached to logs created in the using block
      Getting item 0
warn: TodoApiSample.Controllers.TodoController[4000]
      => RequestId:0HKV9C49II9CK RequestPath:/api/todo/0 => TodoApiSample.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:

ASP.NET Core モジュールを使用した stdout およびデバッグ ログの詳細については、「Azure App Service および IIS での ASP.NET Core のトラブルシューティング」および「ASP.NET Core モジュール」を参照してください。For information on stdout and debug logging with the ASP.NET Core Module, see Azure App Service および IIS での ASP.NET Core のトラブルシューティング and ASP.NET Core モジュール.

Console プロバイダーConsole provider

Microsoft.Extensions.Logging.Console プロバイダー パッケージは、ログ出力をコンソールに送信します。The Microsoft.Extensions.Logging.Console provider package sends log output to the console.

logging.AddConsole();

コンソールのログ出力を確認するには、プロジェクト フォルダーでコマンド プロンプトを開き、次のコマンドを実行します。To see console logging output, open a command prompt in the project folder and run the following command:

dotnet run

Debug プロバイダー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 プロバイダー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();

ログの収集と表示には、PerfView utility を使用することをお勧めします。A good way to collect and view logs is to use the PerfView utility. ETW ログを表示できる他のツールはありますが、ASP.NET Core から出力される ETW イベントを操作する場合、PerfView は最適なエクスペリエンスを提供します。There are other tools for viewing ETW logs, but PerfView provides the best experience for working with the ETW events emitted by ASP.NET Core.

このプロバイダーでログに記録されるイベントを収集するように 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();

AddEventLog のオーバーロードを使用すると、EventLogSettings を渡すことができます。AddEventLog overloads let you pass in EventLogSettings.

TraceSource プロバイダーTraceSource provider

Microsoft.Extensions.Logging.TraceSource プロバイダー パッケージでは、TraceSource ライブラリとプロバイダーが使用されます。The Microsoft.Extensions.Logging.TraceSource provider package uses the TraceSource libraries and providers.

logging.AddTraceSource(sourceSwitchName);

AddTraceSource オーバーロードを使用すると、ソース スイッチとトレース リスナーを渡すことができます。AddTraceSource overloads let you pass in a source switch and a trace listener.

このプロバイダーを使用するには、アプリを (.NET Core ではなく) .NET Framework 上で実行する必要があります。To use this provider, an app has to run on the .NET Framework (rather than .NET Core). このプロバイダーでは、サンプル アプリで使用されている TextWriterTraceListener など、さまざまなリスナーにメッセージをルーティングさせることができます。The provider can route messages to a variety of listeners, such as the TextWriterTraceListener used in the sample app.

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.

logging.AddAzureWebAppDiagnostics();

プロバイダー パッケージは、共有フレームワークに含まれていません。The provider package isn't included in the shared framework. プロバイダーを使用するには、プロバイダー パッケージをプロジェクトに追加します。To use the provider, add the provider package to the project.

プロバイダー パッケージは、Microsoft.AspNetCore.App メタパッケージには含まれません。The provider package isn't included in the Microsoft.AspNetCore.App metapackage. .NET Framework をターゲットとする場合、または Microsoft.AspNetCore.App を参照している場合は、プロバイダー パッケージをプロジェクトに追加します。When targeting .NET Framework or referencing the Microsoft.AspNetCore.App metapackage, add the provider package to the project.

プロバイダーの設定を構成するには、次の例のように AzureFileLoggerOptionsAzureBlobLoggerOptions を使用します。To configure provider settings, use AzureFileLoggerOptions and AzureBlobLoggerOptions, as shown in the following example:

public static void Main(string[] args)
{
    var host = CreateHostBuilder(args).Build();

    var todoRepository = host.Services.GetRequiredService<ITodoRepository>();
    todoRepository.Add(new Core.Model.TodoItem() { Name = "Feed the dog" });
    todoRepository.Add(new Core.Model.TodoItem() { Name = "Walk the dog" });

    var logger = host.Services.GetRequiredService<ILogger<Program>>();
    logger.LogInformation("Seeded the database.");

    host.Run();
}

public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
        .ConfigureLogging(logging => logging.AddAzureWebAppDiagnostics())
            .ConfigureServices(serviceCollection => serviceCollection
                .Configure<AzureFileLoggerOptions>(options =>
                {
                    options.FileName = "azure-diagnostics-";
                    options.FileSizeLimit = 50 * 1024;
                    options.RetainedFileCountLimit = 5;
                }).Configure<AzureBlobLoggerOptions>(options =>
                {
                    options.BlobName = "log.txt";
                })
            )
        .ConfigureWebHostDefaults(webBuilder =>
        {
            webBuilder.UseStartup<Startup>();
        });

プロバイダーの設定を構成するには、次の例のように AzureFileLoggerOptionsAzureBlobLoggerOptions を使用します。To configure provider settings, use AzureFileLoggerOptions and AzureBlobLoggerOptions, as shown in the following example:

public static void Main(string[] args)
{
    var host = CreateWebHostBuilder(args).Build();

    var todoRepository = host.Services.GetRequiredService<ITodoRepository>();
    todoRepository.Add(new Core.Model.TodoItem() { Name = "Feed the dog" });
    todoRepository.Add(new Core.Model.TodoItem() { Name = "Walk the dog" });

    var logger = host.Services.GetRequiredService<ILogger<Program>>();
    logger.LogInformation("Seeded the database.");

    host.Run();
}

public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
    WebHost.CreateDefaultBuilder(args)
        .ConfigureLogging(logging => logging.AddAzureWebAppDiagnostics())
        .ConfigureServices(serviceCollection => serviceCollection
                .Configure<AzureFileLoggerOptions>(options =>
                {
                    options.FileName = "azure-diagnostics-";
                    options.FileSizeLimit = 50 * 1024;
                    options.RetainedFileCountLimit = 5;
                }).Configure<AzureBlobLoggerOptions>(options =>
                {
                    options.BlobName = "log.txt";
                }))
        .UseStartup<Startup>();

AddAzureWebAppDiagnostics のオーバーロードによって AzureAppServicesDiagnosticsSettings を渡すことができます。An AddAzureWebAppDiagnostics overload lets you pass in AzureAppServicesDiagnosticsSettings. 設定オブジェクトで既定の設定をオーバーライドできます。たとえば、ログの出力テンプレート、BLOB 名、ファイル サイズの制限などです。The settings object 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 in addition to what's provided with an ILogger method call.)

アプリケーションを App Service アプリにデプロイすると、Azure portal の [App Service] ページの [App Service ログ] セクションで指定された設定が適用されます。When you deploy to an App Service app, the application honors the settings in the App Service logs section of the App Service page of the Azure portal. 次の設定が更新されると、アプリの再起動や再デプロイを必要とせずに、変更がすぐに有効になります。When the following settings are updated, the changes take effect immediately without requiring a restart or redeployment of the app.

  • [アプリケーション ログ (ファイル システム)]Application Logging (Filesystem)
  • [アプリケーション ログ (BLOB)]Application Logging (Blob)

ログ ファイルの既定の場所は、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. 既定のファイル サイズ制限は 10 MB です。保持されるファイルの既定の最大数は 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.

このプロバイダーは、プロジェクトが 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.

Azure ログのストリーミングAzure log streaming

Azure ログのストリーミングを使用すると、以下からリアル タイムでログ アクティビティを確認できます。Azure log streaming lets you view log activity in real time from:

  • アプリ サーバーThe app server
  • Web サーバーThe web server
  • 失敗した要求のトレースFailed request tracing

Azure ログのストリーミングを構成するにはTo configure Azure log streaming:

  • アプリのポータル ページから [App Service ログ] ページに移動します。Navigate to the App Service logs page from your app's portal page.
  • [アプリケーション ログ (ファイル システム)][オン] に設定します。Set Application Logging (Filesystem) to On.
  • ログ [レベル] を選択します。Choose the log Level.

[ログ ストリーム] ページに移動して、アプリのメッセージを確認します。Navigate to the Log Stream page to view app messages. これらはアプリによって、ILogger インターフェイスを介してログに記録されます。They're logged by the app through the ILogger interface.

Azure Application Insights のトレース ログAzure Application Insights trace logging

Microsoft.Extensions.Logging.ApplicationInsights プロバイダー パッケージでは、Azure Application Insights にログを書き込みます。The Microsoft.Extensions.Logging.ApplicationInsights provider package writes logs to Azure Application Insights. Application Insights は、Web アプリを監視するサービスであり、クエリを実行してテレメトリ データを分析するためのツールを提供します。Application Insights is a service that monitors a web app and provides tools for querying and analyzing the telemetry data. このプロバイダーを使用する場合は、Application Insights ツールを使ってクエリを実行し、ログを分析できます。If you use this provider, you can query and analyze your logs by using the Application Insights tools.

ログ プロバイダーは、Microsoft.ApplicationInsights.AspNetCore の依存関係として組み込まれており、ASP.NET Core で利用可能なすべてのテレメトリを提供するパッケージです。The logging provider is included as a dependency of Microsoft.ApplicationInsights.AspNetCore, which is the package that provides all available telemetry for ASP.NET Core. このパッケージを使用する場合は、プロバイダー パッケージをインストールする必要はありません。If you use this package, you don't have to install the provider package.

ASP.NET 4.x. に対応している Microsoft.ApplicationInsights.Web パッケージを使用しないでください。Don't use the Microsoft.ApplicationInsights.Web package—that's for ASP.NET 4.x.

詳細については、次のリソースを参照してください。For more information, see the following resources:

サードパーティ製のログ プロバイダー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 ILoggerFactory.

詳細については、各プロバイダーのドキュメントをご覧ください。For more information, see each provider's documentation. サード パーティ製のログ プロバイダーは、Microsoft ではサポートされていません。Third-party logging providers aren't supported by Microsoft.

その他の技術情報Additional resources