Ведение журнала в .NET и ASP.NET Core

В этой статье описывается ведение журнала в приложениях ASP.NET Core. Общие рекомендации по ведению журнала в .NET см. в разделе "Ведение журнала" в C# и .NET. Для Blazor руководства по ведению журнала, которое добавляет или заменяет настоящее руководство, см. ASP.NET Core ведение журналаBlazor.

Поставщики ведения журнала

ASP.NET Core поддерживает высокую производительность, структурированное ведение журнала через ILogger API, чтобы помочь отслеживать поведение приложения и диагностировать проблемы. Журналы записываются в разные назначения путем настройки поставщиков ведения журнала. Набор поставщиков ведения журнала встроен в платформу, и есть множество сторонних поставщиков. В приложении можно включить несколько поставщиков.

Большинство поставщиков ведения журнала записывают сообщения журнала в систему хранения данных. Например, поставщик ведения журналов Azure Application Insights хранит журналы в Azure Application Insights. Один из поставщиков, Console, отображает только сообщения журнала. Поставщик Console полезен при локальном запуске приложения для мониторинга и отладки в режиме реального времени.

var builder = WebApplication.CreateBuilder(args);

var builder = WebApplication.CreateBuilder(args);

builder.Logging.ClearProviders();
builder.Logging.AddConsole();

var builder = WebApplication.CreateBuilder(args);

builder.Host.ConfigureLogging(logging =>
{
    logging.ClearProviders();
    logging.AddConsole();
});

Host.CreateDefaultBuilder(args)

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

Дополнительные поставщики рассматриваются в разделах встроенных поставщиков ведения журнала и сторонних поставщиков ведения журнала .

Выходные данные ведения журнала

Отображаются журналы, созданные поставщиками ведения журналов по умолчанию :

• В Visual Studio
  • В окне вывода отладки при отладке.
  • В окне веб-сервера ASP.NET Core .
• В командной оболочке при запуске приложения с использованием команды dotnet run.

.NET в целом и ASP.NET Core используют один и тот же API для ведения журналов и те же поставщики. Дополнительные сведения см. в разделе "Ведение журнала в C# и .NET", в котором рассматриваются общие сценарии ведения журнала для C# и .NET. В этой статье рассматривается ведение журнала приложений ASP.NET Core.

Создайте сообщения журнала

Чтобы создать сообщения журнала, используйте ILogger<TCategoryName> объект из внедрения зависимостей (DI).

В следующих примерах:

• Создайте ILogger, который указывает категорию журнала на основе полного имени типа. Категория журнала — это строка, связанная с каждым журналом, которая полезна для идентификации, сортировки и фильтрации сообщений журнала. Дополнительные сведения о категориях журналов приведены далее в этой статье.
• Вызывает метод LogInformation для ведения журналов на уровне Information. Уровень журнала указывает уровень серьезности зарегистрированного события. Дополнительные сведения об уровнях логов приведены далее в этой статье.

На следующей странице счетчика (CounterRazor компонент) в приложении BlazorILogger<Counter> внедряется с помощью директивы @inject. Экземпляр средства ведения журнала (Logger) используется для регистрации сведений при вызове IncrementCount метода.

Pages/Counter.razor:

@page "/counter"
@inject ILogger<Counter> Logger

<h1>Counter</h1>

<p>Current count: @currentCount</p>

<button class="btn btn-primary" @onclick="IncrementCount">Click me</button>

@code {
    private int currentCount = 0;

    private void IncrementCount()
    {
        Logger.LogInformation("Someone incremented the counter!");

        currentCount++;
    }
}

Лог-сообщение:

BlazorSample.Components.Pages.Counter: Information: Someone incremented the counter!

Категория журнала — BlazorSample.Components.Pages.Counter, а уровень журнала (уровень серьезности) — Information. Сообщение равно Someone incremented the counter!.

В следующем Razor файле класса страницы конфиденциальности Pages в конструктор класса внедряется ILogger<PrivacyModel>, чтобы регистрировать посещение страницы. Обратите внимание, что в этом примере сообщение является шаблоном , который принимает текущую дату и время в формате UTC (DateTime.UtcNow) и записывает его в сообщение журнала. Шаблоны сообщений журнала рассматриваются в разделе Log message template далее в этой статье.

Pages/Privacy.cshtml.cs:

public class PrivacyModel(ILogger<PrivacyModel> logger) : PageModel
{
    public void OnGet() => logger.LogInformation("Privacy page visited at {DT}", 
        DateTime.UtcNow);
}

Шаблон сообщения журнала

Шаблон сообщения журнала может содержать заполнители для предоставленных аргументов. Используйте для заполнителей имена, а не числа.

В следующих примерах {Id} является заполнителем для ID элемента, а id — параметром идентификатора.

Logger.LogInformation(LogEvent.GetItem, "Getting item {Id}", id);

Logger.LogWarning(LogEvent.GetItemNotFound, "Get({Id}) NOT FOUND", id);

Порядок параметров, а не их имен заполнителей, определяет параметры, используемые для предоставления значений заполнителей в сообщениях журнала. В приведенном ниже коде имена параметров идут не по порядку в заполнителях шаблоне сообщения:

var apples = 1;
var pears = 2;
var bananas = 3;

Logger.LogInformation("{Pears}, {Bananas}, {Apples}", apples, pears, bananas);

Однако параметры присваиваются заполнителям в порядке: apples, pears, bananas. Сообщение журнала отражает порядок параметров:

1, 2, 3

Такой подход позволяет поставщикам ведения журнала реализовывать семантическое или структурированное ведение журналов. Сами аргументы передаются в систему ведения журналов, а не только в отформатированный шаблон сообщения. Это позволяет поставщикам ведения журнала хранить значения параметров как поля. Например, рассмотрим следующий метод средства ведения журнала:

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

При ведении журнала в хранилище таблиц Azure:

• каждая сущность таблицы Azure может иметь свойства ID и RequestTime;
• использование таблиц со свойствами позволяет упростить выполнение запросов к данным журнала. Например, с помощью запроса можно находить все журналы в пределах определенного диапазона RequestTime, не анализируя время ожидания текстового сообщения.

Вход при запуске приложения

var builder = WebApplication.CreateBuilder(args);

var app = builder.Build();

app.Logger.LogInformation("Adding Routes");

app.MapGet("/", () => "Hello World!");

app.Logger.LogInformation("Starting the app");

app.Run();

var builder = WebApplication.CreateBuilder(args);

builder.Logging.AddConsole();

var app = builder.Build();

app.MapGet("/", () => "Hello World!");

app.MapGet("/Test", async (ILogger<Program> logger, HttpResponse response) =>
{
    logger.LogInformation("'Test' logging in the Program file");
    await response.WriteAsync("Testing");
});

app.Run();

using Microsoft.Extensions.Logging.Console;

var builder = WebApplication.CreateBuilder(args);

builder.Logging.AddSimpleConsole(
    option => option.ColorBehavior = LoggerColorBehavior.Disabled);

var app = builder.Build();

app.MapGet("/", () => "Hello World!");

app.MapGet("/Test", async (ILogger<Program> logger, HttpResponse response) =>
{
    logger.LogInformation("'Test' logging in the Program file");
    await response.WriteAsync("Testing");
});

app.Run();

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

    var logger = host.Services.GetRequiredService<ILogger<Program>>();
    logger.LogInformation("Host created.");

    host.Run();
}

public void Configure(IApplicationBuilder app, IWebHostEnvironment env, ILogger<Startup> logger)
{
    logger.LogInformation("'Startup'.Configure' logging");

    ...
}

Настройка логирования

При создании объекта ILogger указывается категория. Эта категория включается в каждое сообщение журнала, создаваемое этим экземпляром логгера.

Уровень журнала определяет уровень детализации сообщений журнала на уровне по умолчанию для приложения в целом и для определенных сборок приложений. Уровень журнала можно задать любым из поставщиков конфигурации.

Параметры приложения

Конфигурация ведения журнала обычно предоставляется в разделе Logging файлов appsettings.{ENVIRONMENT}.json, где заполнитель {ENVIRONMENT} является средой. Шаблоны веб-приложений ASP.NET Core создают следующий файл appsettings.Development.json:

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning"
    }
  }
}

В приведенном выше документе JSON:

• Указаны категории "Default" и "Microsoft.AspNetCore".
• Категория "Microsoft.AspNetCore" применяется ко всем категориям, начинающимся с "Microsoft.AspNetCore". Например, этот параметр применяется к категории "Microsoft.AspNetCore.Routing.EndpointMiddleware".
• Категория "Microsoft.AspNetCore" ведет журналы на уровне журнала Warning и выше (более серьезные).
• Конкретный поставщик журналов не указан, поэтому LogLevel применяется ко всем включенным поставщикам ведения журналов, кроме Windows EventLog.

Свойство Logging может иметь свойство LogLevel и свойства поставщика журналов. Свойство LogLevel указывает минимальный уровень журнала для выбранных категорий. В приведенном выше коде JSON заданы уровни ведения журнала Information и Warning. LogLevelзначение указывает на серьезность журнала, которая отображается в следующей таблице с соответствующими enum значениями.

LogLevel При указании параметра ведения журнала, оно включается для сообщений на указанном уровне и выше (более критичном). В приведенном выше коде JSON задается ведение журналов для категории Default для сообщений с уровнем Information и более высоким. Например, в журнал записываются сообщения с уровнями Information, Warning, Error и Critical. Если LogLevel не задан, по умолчанию устанавливается уровень ведения журналов Information. Дополнительные сведения см. в статье Уровни ведения журналов.

Свойство поставщика может задавать свойство LogLevel. Свойство LogLevel поставщика определяет уровень ведения журналов для этого поставщика и переопределяет любые другие не относящиеся к поставщику параметры ведения журналов. Рассмотрим следующий файл appsettings.json:

{
  "Logging": {
    "LogLevel": { // All providers, LogLevel applies to all the enabled providers.
      "Default": "Error", // Default logging, Error and higher.
      "Microsoft": "Warning" // All Microsoft* categories, Warning and higher.
    },
    "Debug": { // Debug provider.
      "LogLevel": {
        "Default": "Information", // Overrides preceding LogLevel:Default setting.
        "Microsoft.Hosting": "Trace" // Debug:Microsoft.Hosting category.
      }
    },
    "EventSource": { // EventSource provider
      "LogLevel": {
        "Default": "Warning" // All categories of EventSource provider.
      }
    }
  }
}

Параметры переопределения Logging.{PROVIDER NAME}.LogLevel в Logging.LogLevel, где заполнитель {PROVIDER NAME} является именем поставщика. В приведенном выше коде JSON для поставщика Debug задается уровень ведения журнала по умолчанию Information:

Logging:Debug:LogLevel:Default:Information

Приведенный выше параметр задает уровень ведения журнала Information для всех категорий Logging:Debug:, за исключением Microsoft.Hosting. Если задана конкретная категория, она переопределяет категорию по умолчанию. В приведенном выше коде JSON категории Logging:Debug:LogLevel"Microsoft.Hosting" и "Default" переопределяют параметры в Logging:LogLevel.

Минимальный уровень ведения журнала можно указать для:

• Пример конкретных поставщиков: Logging:EventSource:LogLevel:Default:Information
• Пример конкретных категорий: Logging:LogLevel:Microsoft:Warning
• всех поставщиков и всех категорий: Logging:LogLevel:Default:Warning

Любые журналы с уровнем ниже минимального:

• не передаются поставщику;
• не записываются в журнал и не отображаются.

Чтобы отключить все журналы, укажите LogLevel.None. LogLevel.None имеет значение 6, то есть выше LogLevel.Critical (5).

Если поставщик поддерживает области журналов, IncludeScopes определяет, включены ли они. Дополнительные сведения см. в статье Области журналов.

Следующий файл appsettings.json содержит все поставщики, включенные по умолчанию:

{
  "Logging": {
    "LogLevel": { // No provider, LogLevel applies to all the enabled providers.
      "Default": "Error",
      "Microsoft": "Warning",
      "Microsoft.Hosting.Lifetime": "Warning"
    },
    "Debug": { // Debug provider.
      "LogLevel": {
        "Default": "Information" // Overrides preceding LogLevel:Default setting.
      }
    },
    "Console": {
      "IncludeScopes": true,
      "LogLevel": {
        "Microsoft.AspNetCore.Mvc.Razor.Internal": "Warning",
        "Microsoft.AspNetCore.Mvc.Razor.Razor": "Debug",
        "Microsoft.AspNetCore.Mvc.Razor": "Error",
        "Default": "Information"
      }
    },
    "EventSource": {
      "LogLevel": {
        "Microsoft": "Information"
      }
    },
    "EventLog": {
      "LogLevel": {
        "Microsoft": "Information"
      }
    },
    "AzureAppServicesFile": {
      "IncludeScopes": true,
      "LogLevel": {
        "Default": "Warning"
      }
    },
    "AzureAppServicesBlob": {
      "IncludeScopes": true,
      "LogLevel": {
        "Microsoft": "Information"
      }
    },
    "ApplicationInsights": {
      "LogLevel": {
        "Default": "Information"
      }
    }
  }
}

В предыдущем примере:

• Категории и уровни не являются предлагаемыми значениями. Пример предоставляется для отображения всех поставщиков по умолчанию.
• Параметры переопределения Logging.{PROVIDER NAME}.LogLevel в Logging.LogLevel, где заполнитель {PROVIDER NAME} является именем поставщика. Например, уровень в Debug.LogLevel.Default переопределяет уровень в LogLevel.Default.
• Каждый поставщик по умолчанию использует псевдоним. Каждый поставщик определяет псевдоним, используемый в конфигурации вместо полного имени типа. Встроенные псевдонимы поставщиков:
  • Console
  • Debug
  • EventSource
  • EventLog
  • AzureAppServicesFile
  • AzureAppServicesBlob
  • ApplicationInsights

Командная оболочка

Переменные среды для настройки ведения журнала можно задать с помощью командной оболочки.

Разделитель : не работает с иерархическими ключами переменных среды на всех платформах. Например, : разделитель не поддерживается Bash. Двойные подчеркивания, __ поддерживаются всеми платформами и автоматически заменяются двоеточием :.

Установите переменную среды командой set в Windows для текущего сеанса командной оболочки. В следующем примере ключ Logging:LogLevel:Microsoft среды имеет значение Information. Вы можете протестировать параметр с любым приложением, созданным на основе шаблона проекта веб-приложения ASP.NET Core.

set Logging__LogLevel__Microsoft=Information

dotnet run Выполните команду в каталоге проекта после выполнения предыдущей set команды:

dotnet run

Предыдущая переменная среды:

• Устанавливается только для приложений, запущенных из текущей командной оболочки.
• Не считывается браузерами, запускаемыми Visual Studio или Visual Studio Code.

Используйте setx для сохранения переменной среды в экземплярах командной оболочки. Параметр /M задает переменную в системной среде. Если параметр /M не используется, задается переменная среды пользователя.

setx Logging__LogLevel__Microsoft Information /M

Настройка службы приложений Azure

В Службе приложений Azure следуйте инструкциям в статье "Настройка приложения службы приложений" , чтобы задать переменные среды ведения журнала.

Дополнительные сведения см. в приложение Azure: переопределение конфигурации приложения с помощью портал Azure.

Категория журнала

При создании объекта ILogger указывается категория. Категория включается в каждое сообщение журнала, создаваемое этим экземпляром логгера. Строка категории является произвольной, но соглашение заключается в том, чтобы использовать полное имя класса. Веб-приложения ASP.NET Core используют ILogger<T> для создания экземпляра средства ведения журнала, который использует полное имя типа T в качестве категории.

Сообщения журнала с именем категории, начинающимся с "Microsoft", относятся к .NET. Как правило, сообщения журнала, начинающиеся с имени сборки приложения, относятся к приложению. Пакеты за пределами .NET обычно имеют категорию на основе имени сборки из пакета. Список распространенных категорий журналов см. в разделе "Общие категории журналов ".

В компоненте Razor приложения Blazor, где тип T задан как Counter для страницы счётчика, отображаемой с помощью компонента Counter (Pages/Counter.razor):

@inject ILogger<Counter> Logger

Razor В модели класса страниц Pages, где тип T предназначен PrivacyModel для страницы конфиденциальности (Pages/Privacy.cshtml.cs):

public class PrivacyModel(ILogger<PrivacyModel> logger) : PageModel

Если требуется дальнейшая классификация, соглашение заключается в том, чтобы использовать иерархическое имя, добавив подкатегорию к полному имени класса с помощью ILoggerFactory.CreateLogger. Этот подход полезен для определения области действия сообщений журнала для методов компонента или класса.

Следующие журналы компонентов из метода Counter с категорией IncrementByOne, а также из метода BlazorSample.Components.Pages.Counter.IncrementByOne с категорией IncrementByTen.

Pages/Counter.razor:

@page "/counter"
@inject ILogger<Counter> Logger

<h1>Counter</h1>

<p>Current count: @currentCount</p>

<button class="btn btn-primary" @onclick="IncrementByOne">Click me (+1)</button>
<button class="btn btn-primary" @onclick="IncrementByTen">Click me (+10)</button>

@code {
    private int currentCount = 0;

    private void IncrementByOne()
    {
        var logger = Logger.CreateLogger($"{typeof(Counter)}.IncrementByOne");
        Logger.LogInformation("Someone incremented the counter!");
        currentCount++;
    }

    private void IncrementByTen()
    {
        var logger = Logger.CreateLogger($"{typeof(Counter)}.IncrementByTen");
        Logger.LogInformation("Someone incremented the counter!");
        currentCount += 10;
    }
}

Сообщения журнала:

BlazorSample.Components.Pages.Counter.IncrementByOne: Information: Someone incremented the counter!
BlazorSample.Components.Pages.Counter.IncrementByTen: Information: Someone incremented the counter!

Razor В модели класса страниц Pages, которая использует пользовательскую категорию ("CustomCategory") для всей модели страницы:

public class PrivacyModel(ILoggerFactory logger) : PageModel
{
    private readonly ILogger _logger = 
        logger.CreateLogger($"{typeof(PrivacyModel)}.CustomCategory");

    public void OnGet() =>
        _logger.LogInformation("Privacy page visited");
}

Идентификатор события журнала

Каждое сообщение журнала может указать идентификатор события. В следующем примере создается набор пользовательских идентификаторов событий для использования приложением. Обратите внимание, что идентификаторы находятся в диапазоне 1000 для операций создания, чтения, обновления и удаления (CRUD), 3000 для ведения журнала тестов и в диапазоне 4000 для не найденных сценариев:

public class LogEvent
{
    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 TestItem           = 3000;

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

Используется в коде компонента Razor, где экземпляр ILogger<T> внедряется (Logger):

• LogEvent.GetItem Идентификатор (1002) используется с информационным сообщением журнала для получения элемента по его идентификатору (id).
• LogEvent.GetItemNotFound Идентификатор (4000) используется с сообщением журнала предупреждений, если элемент не найден.

Logger.LogInformation(LogEvent.GetItem, "Getting item {Id}", id);

var todoItem = await TodoItemService.FindAsync(id);

if (todoItem == null)
{
    Logger.LogWarning(LogEvent.GetItemNotFound, "Get({Id}) NOT FOUND", id);

    return NotFound();
}

Поставщик ведения журнала может хранить идентификатор события в идентификаторе (разрешает фильтрацию по идентификатору), в сообщении журнала или вообще нет. ПоставщикDebug не отображает идентификаторы событий. Поставщик Console отображает идентификаторы событий в квадратных скобках после категории:

info: BlazorSample.Components.Pages.Items[1002]
      Getting item 1
warn: BlazorSample.Components.Pages.Items[4000]
      Get(1) NOT FOUND

Уровень журнала

В следующей таблице описываются уровни ведения журнала с наименьшей до самой высокой серьезности, соответствующие enum значения и их удобные методы расширения.

Первый параметр метода Log, LogLevel, указывает на степень серьезности журнала. Вместо вызова Log(LogLevel, ...), большинство разработчиков вызывают LoggerExtensions методы. Например, следующие два вызова ведения журнала функционально эквивалентны и создают тот же результат на основе внедрения экземпляра ILogger<T> (Logger) в компонент Razor.

Logger.Log(LogLevel.Information, LogEvent.TestItem, routeInfo);

Logger.LogInformation(LogEvent.TestItem, routeInfo);

Ведение журнала на соответствующем уровне для контроля объема выводимых данных журнала, чтобы определять, сколько вывода журнала записывается на конкретный носитель хранения.

• В рабочей среде:
  • Ведение журнала на Traceуровне или DebugInformation на уровне создает большое количество подробных сообщений журнала. Чтобы управлять затратами и не превышать пределы хранения данных, ведите журнал на этих уровнях в хранилище данных с высокой пропускной способностью и низкой стоимостью. Рекомендуется ограничить эти уровни определенными категориями.
  • Ведение журнала на уровнях Warning и Critical обычно приводит к небольшому количеству сообщений журнала.
    • При этом стоимость и ограничения хранения, как правило, не важны.
    • Меньший объем журналов позволяет выбирать среди большего количества вариантов хранения данных.
• В разработке:
  • Мы рекомендуем Information уровень ("Default": "Information") для ведения журнала по умолчанию и Warning уровня для сборок Microsoft ASP.NET Core ("Microsoft.AspNetCore": "Warning").
  • Добавьте Trace и Debug сообщения или Information сообщения при устранении неполадок. Чтобы ограничить выходные данные, задайте только эти уровни ведения журнала для категорий, которые в процессе исследования.

Изменение уровней ведения журнала в работающем приложении

API ведения журнала не поддерживает изменение уровней журнала во время работы приложения. Однако некоторые поставщики конфигурации могут перезагружать конфигурацию, что немедленно влияет на конфигурацию ведения журнала. Например, поставщик конфигурации файлов по умолчанию перезагружает конфигурацию ведения журнала. Если конфигурация изменяется в коде во время выполнения приложения, приложение может вызвать IConfigurationRoot.Reload, чтобы обновить конфигурацию ведения журнала приложения.

Применение правил фильтрации

При создании объекта ILogger<TCategoryName> объект ILoggerFactory выбирает одно правило для каждого поставщика, которое будет применено к этому средству ведения журналов. Все сообщения, записываемые с помощью экземпляра ILogger, фильтруются на основе выбранных правил. Самое подробное правило для каждой пары поставщика и категории выбирается из списка доступных правил.

При создании ILogger для данной категории для каждого поставщика используется приведенный далее алгоритм:

• Выберите все правила, которые соответствуют поставщику или его псевдониму. Если ничего не найдено, выберите все правила с пустым поставщиком.
• В результатах предыдущего шага выберите правила с самым длинным соответствующим префиксом категории. Если ничего не найдено, выберите все правила, которые не указывают категорию.
• Если выбрано несколько правил, примите последнее.
• Если правила не выбраны, используйте MinimumLevel.

ILogger и ILoggerFactory.

Интерфейсы ILogger<TCategoryName> и реализации ILoggerFactory включены в .NET SDK. Кроме того, они доступны в следующих пакетах NuGet:

• Интерфейсы находятся в пакетеMicrosoft.Extensions.Logging.Abstractions NuGet.
• Реализации по умолчанию находятся в пакетеMicrosoft.Extensions.Logging NuGet.

Исключения журналов

Методы средства ведения журнала имеют перегрузки, которые принимают параметр исключения:

try
{
   ...

   throw new Exception("Test exception");
}
catch (Exception ex)
{
    Logger.LogWarning(LogEvent.GetItemNotFound, ex, "Test exception at {DT}", 
        DateTime.UtcNow);
}

Принципы записи исключений в журнал зависят от конкретного поставщика.

Уровень ведения журнала по умолчанию

Если уровень журнала по умолчанию не задан явным образом, используется Informationуровень журнала по умолчанию.

Если уровень журнала по умолчанию не задан в конфигурации, его можно задать с помощью LoggingBuilderExtensions.SetMinimumLevel. Следующий пример задает Warning уровень как уровень ведения журнала по умолчанию.

var builder = WebApplication.CreateBuilder();

builder.Logging.SetMinimumLevel(LogLevel.Warning);

Рекомендуется задать минимальный уровень журнала по умолчанию в конфигурации, а не в коде C#.

Функция фильтра

Функция фильтра вызывается для всех поставщиков и категорий, которым не назначены правила по конфигурации или коду. В следующем примере отображаются журналы консоли, когда категория содержит Page или Microsoft, а уровень журнала Information или выше.

var builder = WebApplication.CreateBuilder();

builder.Logging.AddFilter((provider, category, logLevel) =>
{
    if (provider is not null && category is not null)
    {
        return provider.Contains("ConsoleLoggerProvider")
            && (category.Contains("Page") || category.Contains("Microsoft"))
            && logLevel >= LogLevel.Information;
    }

    return false;
});

Рекомендуется указывать уровни журналов в конфигурации, а не в коде с функциями фильтра.

основные категории ASP.NET

В следующей таблице содержатся некоторые категории ведения журнала, используемые ASP.NET Core.

Чтобы изучить дополнительные категории с помощью Console средства ведения журнала, задайте appsettings.Development.json в тестовом приложении:

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Trace",
      "Microsoft.Hosting.Lifetime": "Information"
    }
  }
}

Список категорий Entity Framework см. в статье "Простое ведение журнала: категории сообщений(EF Core документация)".

Области журнала

Область может группировать набор логических операций. Эту возможность можно использовать для присоединения одних и тех же данных к каждому журналу, созданному как часть набора. Например, каждый журнал, созданный в ходе обработки транзакции, может включать идентификатор транзакции.

Область:

• имеет тип IDisposable, который возвращается методом BeginScope;
• действует вплоть до удаления.

Области поддерживаются следующими поставщиками:

• Console
• AzureAppServicesFile и AzureAppServicesBlob.

Используйте область, заключив вызовы средства ведения журналов в блок using:

public async Task<TodoItem> GetTodoItem(long id)
{
    TodoItem todoItem;
    var transactionId = Guid.NewGuid().ToString();

    using (Logger.BeginScope(new List<KeyValuePair<string, object>>
    {
        new("TransactionId", transactionId),
    }))
    {
        Logger.LogInformation(LogEvent.GetItem, "Getting item {Id}", id);

        todoItem = await TodoItemsService.FindAsync(id);

        if (todoItem == null)
        {
            Logger.LogWarning(LogEvent.GetItemNotFound, "Get({Id}) NOT FOUND", id);

            return NotFound();
        }
    }

    return todoItem;
}

Встроенные поставщики ведения журнала.

ASP.NET Core включает следующие поставщики ведения журнала:

• Console
• Debug
• EventSource
• Windows EventLog

Следующие поставщики ведения журнала предоставляются корпорацией Майкрософт, но не в рамках общей платформы .NET. Они должны быть установлены в качестве дополнительного пакета NuGet, добавленного в приложение.

• AzureAppServicesFile и AzureAppServicesBlob.
• ApplicationInsights

ASP.NET Core не содержит поставщика ведения журналов для записи журналов в файлы. Чтобы записать журналы в файлы из приложения ASP.NET Core, рассмотрите возможность использования стороннего поставщика ведения журналов.

Сведения о stdout и ведении журналов отладки с помощью модуля ASP.NET Core см. в статье Устранение неполадок ASP.NET Core в Службе приложений Azure и IIS и Модуль ASP.NET Core (ANCM) для IIS.

Console

Поставщик Console выводит выходные данные в консоль. Дополнительные сведения о просмотре Console журналов в процессе разработки см. в разделе "Вывод журнала".

Debug

Поставщик Debug записывает выходные данные журнала с помощью класса System.Diagnostics.Debug. При вызове методов System.Diagnostics.Debug.WriteLine выполняется запись в поставщик Debug.

В Linux расположение журнала поставщика Debug зависит от дистрибутива и может быть одним из следующих:

• /var/log/message
• /var/log/syslog

EventSource

Поставщик EventSource выполняет запись в кроссплатформенный источник событий с именем Microsoft-Extensions-Logging. В Windows поставщик использует ETW.

инструменты dotnet-trace

Это dotnet-trace кроссплатформенное глобальное средство командной строки, которое позволяет собирать трассировки .NET для выполняемого процесса. Средство собирает данные поставщика Microsoft.Extensions.Logging.EventSource с помощью LoggingEventSource.

Инструкции по установке см. в разделе dotnet-trace.

Используйте средства dotnet-trace, чтобы получить трассировку из приложения:

1. Запустите приложение с помощью команды dotnet run.

2. Определите идентификатор процесса (PID) приложения .NET:

   dotnet-trace ps
   

   Найдите идентификатор процесса, имя которого совпадает с именем сборки приложения.

3. Выполните команду dotnet-trace.

   Общий синтаксис команды:

   • {PID}: идентификатор процесса
   • {KEYWORD}:Ключевое слово
   • {PROVIDER LEVEL}: уровень поставщика
   • {LOGGER CATEGORY ...}: категория логгера
   • {CATEGORY LEVEL ...}: уровень категории

   dotnet-trace collect -p {PID} 
       --providers Microsoft-Extensions-Logging:{KEYWORD}:{PROVIDER LEVEL}
           :FilterSpecs=\"
               {LOGGER CATEGORY 1}:{CATEGORY LEVEL 1};
               {LOGGER CATEGORY 2}:{CATEGORY LEVEL 2};
               ...
               {LOGGER CATEGORY N}:{CATEGORY LEVEL N}\"
   

   При использовании командной оболочки PowerShell заключите значение --providers в одинарные кавычки ('):

   dotnet-trace collect -p {PID} 
       --providers 'Microsoft-Extensions-Logging:{KEYWORD}:{PROVIDER LEVEL}
           :FilterSpecs=\"
               {LOGGER CATEGORY 1}:{CATEGORY LEVEL 1};
               {LOGGER CATEGORY 2}:{CATEGORY LEVEL 2};
               ...
               {LOGGER CATEGORY N}:{CATEGORY LEVEL N}\"'
   

   На платформах, отличных от Windows, добавьте параметр -f speedscope, чтобы изменить формат выходного файла трассировки на speedscope.

   В следующей таблице дано определение ключевого слова ({KEYWORD} плейсхолдер).

   Keyword	Description
   1	Занесите в журнал метасобытия о LoggingEventSource. Не заносит в журнал события из ILogger.
   2	Включает событие Message при вызове ILogger.Log(). Предоставляет сведения в исходном виде (без форматирования).
   4	Включает событие FormatMessage при вызове ILogger.Log(). Предоставляет сведения в виде отформатированной строки.
   8	Включает событие MessageJson при вызове ILogger.Log(). Предоставляет представление аргументов в формате JSON.

   В следующей таблице определяются уровни поставщика.

   Уровень поставщика	Description
   0	LogAlways
   1	Critical
   2	Error
   3	Warning
   4	Informational
   5	Verbose

   Разбор уровня категории может быть представлен в виде строки или числа, как показано в следующей таблице.

   Значение с именем категории	Числовое значение
   Trace	0
   Debug	1
   Information	2
   Warning	3
   Error	4
   Critical	5

   Уровень поставщика и уровень категории:

   • В обратном порядке.
   • Не все строковые константы не идентичны.

   Если FilterSpecs не указано, EventSourceLogger реализация пытается преобразовать уровень поставщика в уровень категории и применяет его ко всем категориям.

   Уровень поставщика	Уровень категории
   Verbose(5)	Debug(1)
   Informational(4)	Information(2)
   Warning(3)	Warning(3)
   Error(2)	Error(4)
   Critical(1)	Critical(5)

   Если FilterSpecs задано, любая категория, включенная в список, использует закодированный там уровень категории, все остальные категории отфильтровываются.

   В следующих примерах предполагается:

   • Приложение работает и вызывает Logger.LogDebug("12345").
   • Идентификатор процесса (PID) задается через set PID=12345, где 12345 — это фактический PID.

   Рассмотрим следующую команду:

   dotnet-trace collect -p %PID% --providers Microsoft-Extensions-Logging:4:5
   

   Предыдущая команда:

   • Фиксирует сообщения отладки.
   • Не применяет FilterSpecs.
   • Указывает на уровень 5, который сопоставляется с категорией Debug.

   Рассмотрим следующую команду:

   dotnet-trace collect -p %PID%  --providers Microsoft-Extensions-Logging:4:5:\"FilterSpecs=*:5\"
   

   Предыдущая команда:

   • Не фиксирует сообщения отладки, так как уровень категории 5 — Critical.
   • Предоставляет FilterSpecs.

   Следующая команда записывает отладочные сообщения, так как уровень категории 1 определяет Debug:

   dotnet-trace collect -p %PID%  --providers Microsoft-Extensions-Logging:4:5:\"FilterSpecs=*:1\"
   

   Следующая команда записывает сообщения отладки, так как категория указывает Debug:

   dotnet-trace collect -p %PID%  --providers Microsoft-Extensions-Logging:4:5:\"FilterSpecs=*:Debug\"
   

   FilterSpecs записи категории регистратора и уровня категории представляют дополнительные условия фильтрации журналов. Разделяйте записи FilterSpecs символом точки с запятой ;.

   Пример с использованием командной оболочки Windows:

   dotnet-trace collect -p %PID% --providers Microsoft-Extensions-Logging:4:2:FilterSpecs=\"Microsoft.AspNetCore.Hosting*:4\"
   

   Предыдущая команда активирует:

   • ПоставщикEventSource для создания форматированных строк (4) для ошибок (2).
   • Ведение журнала Microsoft.AspNetCore.Hosting на уровне ведения журнала Information (4).

4. Остановите инструмент, dotnet-trace нажав клавишу ВВОД или CTRL+C.

   Трассировка сохраняется с именем trace.nettrace в папке, в которой выполняется команда dotnet-trace.

5. Откройте трассировку с помощью Perfview. Откройте файл trace.nettrace и изучите события трассировки.

Если приложение не строит хост WebApplication.CreateBuilder, добавьте EventSource поставщика в конфигурацию ведения журнала приложения.

Дополнительные сведения см. в разделе:

• Трассировка для служебной программы анализа производительности () (dotnet-traceдокументация по .NET)
• Трассировка для служебной программы анализа производительности (dotnet-trace) (dotnet/diagnostics документация по репозиторию GitHub)
• LoggingEventSource
• EventLevel
• Perfview для просмотра EventSource трассировок

Perfview

Для сбора и просмотра данных журналов рекомендуется использовать программу PerfView. Существуют и другие средства для просмотра журналов трассировки событий Windows, но PerfView обеспечивает максимальное удобство работы с событиями трассировки событий Windows, создаваемыми ASP.NET Core.

Чтобы настроить PerfView для сбора событий, регистрируемых этим поставщиком, добавьте строку *Microsoft-Extensions-Logging в список Дополнительные поставщики. Не пропустите символ * в начале строки.

Журнал событий Windows

Поставщик Windows EventLog отправляет выходные данные журнала в журнал событий Windows. В отличие от других поставщиков, поставщик EventLog не наследует параметры по умолчанию, не относящиеся к поставщику. Если параметры журнала EventLog не указаны, то принимается значение по умолчанию LogLevel.Warning.

Чтобы регистрировать события с уровнем ниже LogLevel.Warning, следует явно задать уровень ведения журнала. В следующем примере для журнала событий по умолчанию задается уровень LogLevel.Information:

"Logging": {
  "EventLog": {
    "LogLevel": {
      "Default": "Information"
    }
  }
}

Перегрузки AddEventLog позволяют передавать EventLogSettings. Если null или не указан, используются следующие параметры по умолчанию:

• LogName: "Application"
• SourceName: ".NET Runtime"
• MachineName: используется имя локального компьютера.

Следующий код изменяет значение SourceName с установленного по умолчанию ".NET Runtime" на "CustomLogs".

var builder = WebApplication.CreateBuilder();

builder.Logging.AddEventLog(eventLogSettings =>
{
    eventLogSettings.SourceName = "CustomLogs";
});

Когда приложение вызывает перегрузку AddEventLogEventLogSettings, создается новый экземпляр EventLogLoggerProvider с указанными параметрами. Если экземпляр EventLogLoggerProvider уже зарегистрирован, то есть если приложение не вызывает ClearProviders, чтобы удалить все экземпляры ILoggerProvider, то новые параметры не заменяют существующие. Если вы хотите убедиться, что EventLogSettings используются, вызовите ClearProviders перед вызовом AddEventLog.

Служба приложений Azure

ПакетMicrosoft.Extensions.Logging.AzureAppServices NuGet поставщика записывает журналы в текстовые файлы в файловую систему приложения Службы приложений Azure и в хранилище BLOB-объектов в учетной записи хранения Azure. Поставщик ведет журнал только во время выполнения проекта в среде Azure.

Пакет поставщика не включен в общую платформу. Чтобы использовать поставщик, добавьте пакет поставщика в проект.

Для настройки параметров поставщика используйте AzureFileLoggerOptions и AzureBlobLoggerOptions, как показано в следующем примере:

using Microsoft.Extensions.Logging.AzureAppServices;

var builder = WebApplication.CreateBuilder();

builder.Logging.AddAzureWebAppDiagnostics();

builder.Services.Configure<AzureFileLoggerOptions>(options =>
{
    options.FileName = "azure-diagnostics-";
    options.FileSizeLimit = 50 * 1024;
    options.RetainedFileCountLimit = 5;
});

builder.Services.Configure<AzureBlobLoggerOptions>(options =>
{
    options.BlobName = "log.txt";
});

public class Scopes
{
    public class Program
    {
        public static void Main(string[] args)
        {
            CreateHostBuilder(args).Build().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>();
                });
    }
}

При развертывании в службе приложений Azure ваше приложение использует параметры в разделе Журналы службы приложений на странице Служба приложений на портале Azure. При обновлении следующих параметров изменения вступают в силу немедленно без перезапуска или повторного развертывания приложения:

• Ведение журнала приложения (файловая система);
• Ведение журнала приложения (BLOB-объект).

Расположение по умолчанию для файлов журналов находится в D:\home\LogFiles\Application. Ограничение размера файла по умолчанию составляет 10 МБ, а максимальное количество файлов, сохраненных по умолчанию, составляет два файла.

Потоковая передача журналов Azure

Потоковая передача журналов Azure позволяет просматривать активность журнала в реальном времени из следующих источников:

• сервер приложений;
• веб-сервер;
• Трассировка неудачно завершенных запросов

Настройка потоковой передачи журналов Azure

• Со страницы портала приложения перейдите на страницу Журналы службы приложений.
• Установите для параметра Вход в приложения (файловая система) значение Вкл.
• Выберите уровень ведения журнала. Этот параметр применяется только к потоковой передаче журналов Azure.

Перейдите на страницу Поток журналов, чтобы просмотреть журналы. Сообщения записываются в журнал с помощью интерфейса ILogger.

Azure Application Insights

Служба Application Insights отслеживает веб-приложения и предоставляет средства для создания запросов и анализа данных телеметрии. Используя этого поставщика, вы сможете выполнять запросы к журналам и их анализ с помощью средств Application Insights.

Пакет NuGet поставщикаMicrosoft.Extensions.Logging.ApplicationInsights записывает логи в Azure Application Insights. Поставщик ведения журнала включается в качестве зависимости Microsoft.ApplicationInsights.AspNetCore пакета NuGet, который предоставляет все доступные данные телеметрии для ASP.NET Core. Если вы используете пакет Microsoft.ApplicationInsights.AspNetCore NuGet, нет необходимости устанавливать пакет Microsoft.Extensions.Logging.ApplicationInsights поставщика.

Дополнительные сведения см. на следующих ресурсах:

• Общие сведения об Application Insights
• Application Insights для приложений ASP.NET Core — начните изучение с этой статьи, если вы хотите полностью реализовать возможности Application Insights для телеметрии и ведения журналов.
• ApplicationInsightsLoggerProvider для журналов ILogger .NET: Начните отсюда, если вы хотите настроить провайдер журналирования, не подключая остальную телеметрию Application Insights.
• Адаптеры ведения журналов в Application Insights
• Установка, настройка и инициализация пакета SDK Application Insights — интерактивное руководство.

Сторонние поставщики ведения журналов

Некоторые сторонние платформы ведения журналов, которые работают с ASP.NET Core:

• elmah.io (репозиторий GitHub)
• Gelf (репозиторий GitHub)
• JSNLog (репозиторий GitHub)
• KissLog.net (репозиторий GitHub)
• Log4Net (репозиторий GitHub)
• NLog (репозиторий GitHub)
• PLogger (репозиторий GitHub)
• Sentry (репозиторий GitHub)
• Serilog (репозиторий GitHub)
• Stackdriver (репозиторий GitHub)

Некоторые сторонние платформы выполняют семантическое ведение журналов, также известное как структурированное ведение журналов.

Использование сторонней платформы аналогично использованию одного из встроенных поставщиков:

1. Добавьте пакет NuGet поставщика в проект.
2. Вызовите метод расширения ILoggerFactory, предоставляемый платформой ведения журналов.

Дополнительные сведения см. в документации поставщика. Сторонние поставщики ведения журналов не принадлежат, не поддерживаются корпорацией Майкрософт.

Ведение журнала консольного приложения, не работающего в хосте

Чтобы выполнять ведение журнала в консольном приложении без общего хоста, см. "Ведение журнала в C# и .NET". Дополнительные примеры см. в примере приложения фоновых задач, которое рассматривается фоновыми задачами с размещенными службами в ASP.NET Core.

Асинхронные методы ведения журналов не выполняются

Скорость ведения журналов не должна влиять на производительность выполнения асинхронного кода. Если хранилище данных, предназначенное для регистрации сообщений журнала, работает медленно, сначала записывайте эти сообщения в быстродействующее хранилище, Сначала попробуйте записать сообщения журнала в быстрое хранилище, а затем переместить журналы в более медленное хранилище данных позже. Например, не записывайте сообщения журнала непосредственно в хранилище данных SQL Server в Log методе, поскольку Log методы являются синхронными. Вместо этого синхронно добавляйте сообщения журнала в очередь в памяти, а фоновый процесс извлекает сообщения из очереди, чтобы отправлять данные в SQL Server асинхронно. Дополнительные сведения см. руководстве по записи журнала в очередь сообщений для медленных хранилищ данных (dotnet/AspNetCore.Docs #11801).

Применение правил фильтрации журналов в коде

Предпочтительный подход к настройке правил фильтрации журналов определяется конфигурацией приложения.

В следующем примере показано, как зарегистрировать правила фильтрации в коде путем вызова AddFilterWebApplicationBuilder.Logging:

using Microsoft.Extensions.Logging.Console;
using Microsoft.Extensions.Logging.Debug;

var builder = WebApplication.CreateBuilder();

builder.Logging.AddFilter("System", LogLevel.Debug);
builder.Logging.AddFilter<DebugLoggerProvider>("Microsoft", LogLevel.Information);
builder.Logging.AddFilter<ConsoleLoggerProvider>("Microsoft", LogLevel.Trace);

В предыдущем примере:

• Первый фильтр указывает:

  • Правила фильтрации журналов применяются для всех поставщиков, поскольку конкретный поставщик не сконфигурирован.
  • Все категории, начиная с "System".
  • уровень ведения журнала Debug и выше;

• Поставщик Debug (DebugLoggerProvider) указывает:

  • Все категории, начиная с "Microsoft".
  • уровень ведения журнала Information и выше;

• Поставщик Console (ConsoleLoggerProvider) указывает:

  • Все категории, начиная с "Microsoft".
  • уровень ведения журнала Trace и выше;

var builder = WebApplication.CreateBuilder(args);

builder.Logging.AddSimpleConsole(options =>
{
    options.IncludeScopes = true;
});

builder.Logging.Configure(options =>
{
    options.ActivityTrackingOptions = 
        ActivityTrackingOptions.SpanId | ActivityTrackingOptions.TraceId;
});

var app = builder.Build();

app.MapGet("/", () => "Hello World!");

app.Run();

var loggerFactory = LoggerFactory.Create(logging =>
{
    logging.Configure(options =>
    {
        options.ActivityTrackingOptions = 
            ActivityTrackingOptions.SpanId | ActivityTrackingOptions.TraceId;
    }).AddSimpleConsole(options =>
    {
        options.IncludeScopes = true;
    });
});

Создание пользовательского средства ведения журнала

Сведения о создании пользовательского средства ведения журнала см. в статье Реализация пользовательского поставщика ведения журнала в .NET.

var builtConfig = new ConfigurationBuilder()
    .AddJsonFile("appsettings.json")
    .AddCommandLine(args)
    .Build();

Log.Logger = new LoggerConfiguration()
    .WriteTo.Console()
    .WriteTo.File(builtConfig["Logging:FilePath"])
    .CreateLogger();

try
{
    return Host.CreateDefaultBuilder(args)
        .ConfigureServices((context, services) =>
        {
            services.AddRazorPages();
        })
        .ConfigureAppConfiguration((hostingContext, config) =>
        {
            config.AddConfiguration(builtConfig);
        })
        .ConfigureLogging(logging =>
        {   
            logging.AddSerilog();
        })
        .ConfigureWebHostDefaults(webBuilder =>
        {
            webBuilder.UseStartup<Startup>();
        });
}
catch (Exception ex)
{
    Log.Fatal(ex, "Host builder error");

    throw;
}
finally
{
    Log.CloseAndFlush();
}

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

Отчеты об ошибках при ведении логов

Отправьте отчет об ошибке ведения журнала в разделе проблем репозитория GitHub.

Общие категории журналов

В этом разделе описываются общие категории журналов, которые отображаются в журналах приложений ASP.NET Core. Ниже приведен не полный список.

Microsoft.AspNetCore: журналы компонентов платформы ASP.NET Core, таких как хостинг, маршрутизация и посредник.

Authentication

• Microsoft.AspNetCore.Authentication: журналы аутентификационного ПО и служб, включая обработку схем проверки подлинности.
• Microsoft.AspNetCore.Authentication.Cookies: журналы логов, относящиеся к проверке подлинности на основе cookie.
• Microsoft.AspNetCore.Authentication.JwtBearer: журналы, связанные с проверкой подлинности маркера носителя JWT.
• Microsoft.AspNetCore.Authentication.OpenIdConnect: журналы, касающиеся процессов проверки подлинности OpenID Connect.
• Microsoft.AspNetCore.Authentication.OAuth: журналы, связанные с потоками проверки подлинности и авторизации OAuth.

Authorization

• Microsoft.AspNetCore.Authorization: журналы, связанные с операциями авторизации, включая оценку политики и принятие решений.
• Microsoft.AspNetCore.Authorization.DefaultAuthorizationService: журналы по умолчанию.

Конфигурация

• Microsoft.Extensions.Configuration.Json: журналы из классов, получающих данные конфигурации из JSON-файлов.
• Microsoft.Extensions.Configuration.UserSecrets: журналы, связанные с загрузкой конфигурации пользовательских секретов.

CORS (Совместное использование ресурсов разных источников)

• Microsoft.AspNetCore.Cors: журналы, связанные с предоставлением ресурсов между источниками (CORS) и оценкой политики.
• Microsoft.AspNetCore.Cors.Infrastructure: журналы, касающиеся настройки и соблюдения политики CORS.

Защита данных:

• Microsoft.AspNetCore.DataProtection: журналы из системы защиты данных, включая управление ключами, операции шифрования и какие ключи были рассмотрены, найдены и использованы.
• Microsoft.AspNetCore.DataProtection.KeyManagement.XmlKeyManager: журналы, специфичные для диспетчера ключей XML, включая хранение и извлечение ключей.

Diagnostics

• Microsoft.AspNetCore.Diagnostics: Логи о диагностике и обработке ошибок промежуточного программного обеспечения, включая обработку исключений и страницы с кодами состояния.
• Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware: журналы, связанные с обработкой middleware на странице исключений разработчика.
• Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware: журналы, связанные с обработкой исключений и созданием ответов об ошибках.
• Microsoft.AspNetCore.Diagnostics.StatusCodePageMiddleware: журналы, связанные с промежуточным программным обеспечением для страниц с кодами состояния и обработкой ответов.

Фильтрация хостов

• Microsoft.AspNetCore.HostFiltering: разрешенные и запрещенные узлы промежуточным слоем фильтрации.
• Microsoft.AspNetCore.HostFiltering.HostFilteringMiddleware: журналы, связанные с промежуточным слоем фильтрации хостов, включая разрешенные и запрещенные хосты.
• Microsoft.AspNetCore.HostFiltering.HostFilteringOptions: журналы, касающиеся параметров посредствующего слоя системы HostFiltering.

Хостинг

• Microsoft.AspNetCore.Hosting.Lifetime: журналы, связанные с жизненным циклом веб-узла, включая запуск и остановку событий.
• Microsoft.AspNetCore.Hosting.Diagnostics: регистрирует сведения о диагностике, такие как запуск приложения и завершение работы.
• Microsoft.AspNetCore.Hosting.RequestDelegate: журналы, связанные с обработкой HTTP-запросов конвейером приложения.
• Microsoft.AspNetCore.Hosting.Internal.WebHost: внутренние журналы из веб-узла, полезные для отладки проблем, связанных с узлом.
• Microsoft.AspNetCore.Hosting.Internal.HostedServiceExecutor: журналы, касающиеся выполнения размещенных служб веб-узла.

HTTP

• Microsoft.AspNetCore.Http.ConnectionLogging: связано с HTTP-подключениями, включая создание и завершение подключения.
• Microsoft.AspNetCore.Http.DefaultHttpContext: журналы, связанные с созданием и использованием экземпляров HttpContext.
• Microsoft.AspNetCore.Http.Endpoints.EndpointMiddleware: журналы о маршрутизации конечных точек и исполнении промежуточного ПО.
• Microsoft.AspNetCore.Http.Response: журналы, связанные с обработкой ответа HTTP.

HTTPS

• Microsoft.AspNetCore.HttpsPolicy: журналы промежуточного ПО для перенаправления HTTPS, применения политик и HTTP Strict-Transport-Security (HSTS).
• Microsoft.AspNetCore.HttpsPolicy.HstsMiddleware: журналы, относящиеся к обработке промежуточного ПО HTTP Strict-Transport-Security (HSTS).
• Microsoft.AspNetCore.HttpsPolicy.HttpsRedirectionMiddleware: журналы, относящиеся к выполнению посреднического ПО перенаправления HTTPS.
• Microsoft.AspNetCore.HttpsPolicy.HstsOptions: журналы, касающиеся конфигурации и применения политики HSTS.

Identity

• Microsoft.AspNetCore.Identity: журналы фреймворка ASP.NET Core Identity, включая операции управления пользователями и идентификации.
• Microsoft.AspNetCore.Identity.RoleManager: журналы, связанные с операциями управления ролями.
• Microsoft.AspNetCore.Identity.UserManager: журналы, касающиеся действий управления пользователями и событий жизненного цикла.

Kestrel

• Microsoft.AspNetCore.Server.Kestrel: журналы с веб-сервера, охватывающие обработку подключений Kestrel и обработку запросов.
• Microsoft.AspNetCore.Server.Kestrel.Core: журналы, связанные с основными Kestrel операциями, такими как настройка и управление ресурсами.
• Microsoft.AspNetCore.Server.Kestrel.Transport: журналы, относящиеся к уровням сетевого транспорта, используемым Kestrel.

Logging

• Microsoft.Extensions.Logging: журналы из API расширений журналирования.
• Microsoft.Extensions.Logging.Console: журналы, относящиеся к консольному логгеру.

MVC

• Microsoft.AspNetCore.Mvc: общие журналы из компонентов платформы MVC, включая выполнение контроллера и действия.
• Microsoft.AspNetCore.Mvc.Infrastructure: журналы, связанные с инфраструктурой и службами поддержки для MVC, такими как привязка модели и фильтры действий.
• Microsoft.AspNetCore.Mvc.ModelBinding: журналы, касающиеся операций привязки модели и проверки данных.
• Microsoft.AspNetCore.Mvc.Filters: регистрирует выполнение фильтров действий и конвейеров фильтров.
• Microsoft.AspNetCore.Mvc.Razor: журналы, относящиеся к отрисовке и компиляции представления Razor.
• Microsoft.AspNetCore.Mvc.ViewFeatures: журналы, касающиеся отрисовки представлений и связанных функций, таких как компоненты представления и вспомогательные функции тегов.

Маршрутизация

• Microsoft.AspNetCore.Routing.EndpointMiddleware: журналы, связанные с маршрутизацией HTTP-запросов к конечным точкам.
• Microsoft.AspNetCore.Routing.EndpointRoutingMiddleware: Промежуточное программное обеспечение маршрутизации конечных точек обрабатывает запросы.
• Microsoft.AspNetCore.Routing.Matching.DataSourceDependentMatcher: журналы, касающиеся сопоставления маршрутов и выбора конечных точек.
• Microsoft.AspNetCore.Routing.Matching.DfaMatcher: логи, специфичные для маршрутизатора сопоставлений DFA (детерминированный конечный автомат).

SignalR

• Microsoft.AspNetCore.SignalR: логи из SignalR фреймворка, включая подключения хабов и обработку сообщений.
• Microsoft.AspNetCore.SignalR.Hub: журналы, относящиеся к вызову концентратора и отправке сообщений.
• Microsoft.AspNetCore.SignalR.Transports: журналы, связанные с механизмами транспортировки, используемыми SignalR.

статические файлы;

• Microsoft.AspNetCore.StaticFiles: журналы из промежуточного слоя статических файлов, включая операции подачи файлов и работы с кэшем.
• Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware: журналы, связанные с выполнением промежуточного слоя статических файлов и обработкой ответов на файлы.

Дополнительные ресурсы

• Ведение журналов BlazorASP.NET Core
• Повышение производительности ведения журнала с помощью генераторов источников
• [LogProperties] За и новым генератором источника ведения журнала телеметрии
• Microsoft.Extensions.Logging репозиторий GitHub для исходного кода (dotnet/runtime)
• Ведение журнала высокой производительности
• Просмотр или скачивание примера кода (как скачать)