@kotelok

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

Сейчас реализация самая простая - при запуске потока, который обрабатывает подключение, кодом создаётся 'FileTarget' с уникальным именем и правило для него, после чего выполняется 'ReconfigExistingLoggers' (все подчинённые потоки, если требуется, запрашивают логгер по тому же уникальному имени). При завершении подключения, правило и 'FileTarget' удаляются из конфига. Речь не про файл конфига, а про ту конфигурацию, что уже загружена - 'NLog.LogManager.Configuration'.

В целом работает, но только выглядит сей подход как-то ну очень костыльно. И ещё не понятно, как это скажется на производительности и вообще на работоспособности всех активных логгеров, если будет постоянно вызываться 'ReconfigExistingLoggers'.

Может, есть какие-нибудь другие способы реализовать то же самое?

0

@nicolas2008

Как при таком подходе решается проблема логирования из нескольких одновременных подключений?
LogManager он же общий для всех полключений.

0

@kotelok

nicolas2008
Так это ведь штатный режим работы для него.
Он на вход получает все данные из всех потоков, а потом, согласно правилам, раскладывает их в файлы в соответствии с фильтрами, указанными в 'Rules'.

Сейчас он все записи пишет в один общий лог и параллельно дублирует каждую в свой файл.

Ну и даже при обычной реализации API на netcore режим работы логгера аналогичный - один общий конфиг и несколько фильтров для раскладывания по тематическим файлам (весь лог, только linqtodb, только пользовательские события).

0

@nicolas2008

А ну если применены Rules тогда понятно.

Не обязательно. Есть еще LogFactory, которым можно создавать отдельные логгеры у каждого из которых своя конфигурация.

1