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

[kotbaun]

фильтр логов?

[imanushin]

Возможно, вам было бы проще с NLog. В нем есть опция асинхронных контекстов — см. тут.

Алгоритм действий:

1. В начале обработки запроса необходимо инициализировать контекст.
2. В конце — вызвать Dispose (то есть по сути — обычный using).
3. В конфигурации — пропускать только те logging event, которые содержат свойство из контекста (у вас такое и сделано).

Плюс моего подхода в том, что он позволяет фильтровать события даже из 3rd party библиотек.

[iakimov]

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

[ZerGer]

Вы не правильно понимаете, что такое уровни логирования. Так Logger.Trace() и Logger.Debug() пишут информацию для разработчиков; Logger.Info() — разовые операции, которые влияют на поведение системы (например: обновление конфига или загрузка плагина); Logger. Warning() – сигнализирует о потенциальных проблемах; Logger. Error () и Logger. Fatal() – детали ошибки.

Обычно, в DEV-конфигурации для записи логов используется минимальный уровень события Trace, а для PROD – минимальным уровнем выставляется Info.

Я бы переформулировал вашу задачу с «Должен существовать способ установить отдельный уровень логирования для каждого запроса.» на «Требуется логировать событий по переделённым критериям (в том числе, параметрам запроса)».

Я не работал с log4net, но, например, в NLog или Serilog эти критерии и таргеты вывода можно декларативно прописать в конфигурационном файле.

Для .Net Core, если логгер используется под оберткой ILogger из Microsoft.Extensions.Logging, то контекст логгера для можно создать методом Logger.BeginScope(…). В частности, реализовав middleware, в котором вызывается Logger.BeginScope(…) можно добавить нестандартные параметры во все события запроса и потом делать по ним фильтрацию.

[iakimov]

Если на production установить причину проблемы можно только по записям с уровнем Info и серьезнее, то никакой надобности в изменении конфигурации логгеров нет. Но если этого не достаточно, и мы считаем, что записи уровней Trace и Debug могут нам помочь, то здесь нужно что-то делать.

Да, вы правы, можно для этой цели использовать фильтрацию NLog, как предложили выше.

[ZerGer]

А что мешает в production написать что-то вроде такого:

<nlog>
 <rules>
  <!-- Логируем события любого уровня от ValuesController -->
  <logger name="ValuesController" writeTo="traceFile" minlevel="Trace" />
  <!-- Детальные логи по ошибкам -->
  <logger name="*" writeTo="email,errorFile" minlevel="Warn" />
  <!-- Общие логи по работе системы -->
  <logger name="*" writeTo="commonFile" minlevel="Info" />
 </rules>
</nlog>

Для более сложных критериев можно воспользоваться фильтрами.

Отмечу, что nlog не поддерживает декларативную конфигурацию в appsettings.json, только XML. Если все же хочется работать с конфигами в json, то рекомендую Serilog. Но суть будет примерно та же…

[iakimov]

Ничего не мешает, если вы хотите видеть в логах записи и от «хороших», и от «плохих» запросов. Если же вам нужны только записи из «плохих» запросов, то их нужно как-то пометить. Тогда эти «метки» можно будет использовать в фильтрах логов.