Comments 7
фильтр логов?
Возможно, вам было бы проще с NLog. В нем есть опция асинхронных контекстов — см. тут.
Алгоритм действий:
- В начале обработки запроса необходимо инициализировать контекст.
- В конце — вызвать Dispose (то есть по сути — обычный using).
- В конфигурации — пропускать только те logging event, которые содержат свойство из контекста (у вас такое и сделано).
Плюс моего подхода в том, что он позволяет фильтровать события даже из 3rd party библиотек.
Да, согласен. Вместо изменения уровня логирования всего лога, можно прописывать специальные значения для некоторого свойства в асинхроном контексте, а в конфигурационном файле прописать несколько вариантов logger с разными фильтрами для разных значений этого свойства. Вы правы, это решит ряд проблем.
Вы не правильно понимаете, что такое уровни логирования. Так 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(…) можно добавить нестандартные параметры во все события запроса и потом делать по ним фильтрацию.
Обычно, в DEV-конфигурации для записи логов используется минимальный уровень события Trace, а для PROD – минимальным уровнем выставляется Info.
Я бы переформулировал вашу задачу с «Должен существовать способ установить отдельный уровень логирования для каждого запроса.» на «Требуется логировать событий по переделённым критериям (в том числе, параметрам запроса)».
Я не работал с log4net, но, например, в NLog или Serilog эти критерии и таргеты вывода можно декларативно прописать в конфигурационном файле.
Для .Net Core, если логгер используется под оберткой ILogger из Microsoft.Extensions.Logging, то контекст логгера для можно создать методом Logger.BeginScope(…). В частности, реализовав middleware, в котором вызывается Logger.BeginScope(…) можно добавить нестандартные параметры во все события запроса и потом делать по ним фильтрацию.
Если на production установить причину проблемы можно только по записям с уровнем Info и серьезнее, то никакой надобности в изменении конфигурации логгеров нет. Но если этого не достаточно, и мы считаем, что записи уровней Trace и Debug могут нам помочь, то здесь нужно что-то делать.
Да, вы правы, можно для этой цели использовать фильтрацию NLog, как предложили выше.
Да, вы правы, можно для этой цели использовать фильтрацию NLog, как предложили выше.
А что мешает в production написать что-то вроде такого:
Для более сложных критериев можно воспользоваться фильтрами.
Отмечу, что nlog не поддерживает декларативную конфигурацию в appsettings.json, только XML. Если все же хочется работать с конфигами в json, то рекомендую Serilog. Но суть будет примерно та же…
<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. Но суть будет примерно та же…
Sign up to leave a comment.
Отдельный уровень логирования для каждого запроса