Как вы можете запретить NLog обрабатывать операторы журнала в ссылочных библиотеках? - PullRequest
Новая
       96

Как вы можете запретить NLog обрабатывать операторы журнала в ссылочных библиотеках?

2 голосов
/ 04 марта 2020

Всякий раз, когда в нашем API возникает ошибка, мы получаем несколько писем за одну ошибку. На основании журнала сообщений; мы можем видеть, что эти другие электронные письма, кажется, генерируются, потому что различные библиотеки Microsoft вызывают что-то вроде _logger.LogError, а также нашу собственную _ logger.LogError, что происходит, когда мы обрабатываем ошибку.

Например, при наличии тайм-аута базы данных мы видим 4 электронных письма из этих разных классов:

  • Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware
  • Microsoft.EntityFrameworkCore .Database.Command
  • Microsoft.EntityFrameworkCore.Query
  • Web.Controllers.ErrorController (наш собственный обработчик исключений; это единственный, который мы хотим видеть)

Последний является единственным, в котором есть собственное форматирование ошибок с полезной информацией, такой как текущий пользователь и т. Д. c. Другие просто содержат трассировку стека, которая уже находится в нашей собственной отформатированной электронной почте.

Мы не можем точно определить, откуда поступают эти другие сообщения журнала; но наиболее вероятная вещь, о которой я могу подумать, это то, что в библиотеках Microsoft они вызывают _logger.LogError(), а наша собственная конфигурация NLog обрабатывает все экземпляры LogError; вместо того, чтобы просто обрабатывать наши собственные.

Как мы можем предотвратить запись этих других операторов журнала и, в частности, по электронной почте нам?

Это наша установка в Program.cs: 

public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
                    WebHost.CreateDefaultBuilder(args)
                        .UseStartup<Startup>()
                         .ConfigureLogging(logging =>
                         {
                             logging.ClearProviders();
                             logging.SetMinimumLevel(Microsoft.Extensions.Logging.LogLevel.Trace);
                         })
                    .UseNLog();

1 Ответ

2 голосов
/ 04 марта 2020

Вы можете отфильтровать это. NET Ядро - потому что вы используете интеграцию Microsoft.Extensions.Logging и Microsoft отправляет сообщения на это - и в NLog.

Настройка в. NET Ядро

Изменение настроек, например, настроек приложения. json. Например, по крайней мере, ошибка для всех Microsoft. * И Предупреждение для Microsoft.EntityFrameworkCore. *

{
  "Logging": {
    "IncludeScopes": false,
    "LogLevel": {
      "Default": "Trace",
      "Microsoft": "Error",
      "Microsoft.EntityFrameworkCore": "Warning"
    }
  }
}

Обратите внимание, что это не NLog, указанный c, поэтому вы не можете использовать имена уровней NLog. возможные имена уровней

Подробнее об этом подходе здесь .

Настроить NLog

Или вы можете настроить его в конфигурации NLog .

В файле NLog.config отредактируйте <rules>. Эти правила обрабатываются сверху вниз.

  • Вы можете фильтровать пространство имен с атрибутом name (* разрешено)
  • Без атрибута writeTo журналы отбрасываются
  • Если правило имеет final="true" и соответствует событиям, следующее правило не будет обработано.

Например: 

<rules>
    <!--All logs, including from Microsoft-->
    <logger name="*" minlevel="Trace" writeTo="allfile" />

    <!--Skip non-critical Microsoft logs and so log only own logs-->
    <logger name="Microsoft.*" maxlevel="Info" final="true" /> <!-- BlackHole without writeTo -->
    <logger name="*" minlevel="Trace" writeTo="ownFile-web" />
  </rules>

Вы можете прочитать о nlog.config правила здесь .

Это также возможно с тем же подходом из кода, см. здесь .

...