![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Логи
Я пришел к выводу, что осмысленно выбрать уровни логов (log4j, log4net) в вызовах внутри программы при разработке невозможно.
Всегда возникнет ситуация, в которой конкретно вот сейчас, без перезагрузки сервиса надо сменить уровень лога в данном конкретном методе.
Делать отдельные логгеры на каждый чих и конфигурировать их - это адский комбинаторный взрыв, конфиги становятся нечитабельными, когда там в xml пытаются засунуть то, что должно быть матрицей M(логгеров)*N(аппендеров), а еще лучше такой же матрицей, только с иерархией (общий, группа логгеров, логгер) по одной оси и аналогично для аппендеров по другой.
Кажется, надо просто логи складывать в очереди и фильтровать их по уровням не на этапе создания, а на этапе чтения. Возможно, разве что уберотладочные на каждую букву в каком-нибудь парсере с конечным автоматом отсеивать, и то не факт.
Всегда возникнет ситуация, в которой конкретно вот сейчас, без перезагрузки сервиса надо сменить уровень лога в данном конкретном методе.
Делать отдельные логгеры на каждый чих и конфигурировать их - это адский комбинаторный взрыв, конфиги становятся нечитабельными, когда там в xml пытаются засунуть то, что должно быть матрицей M(логгеров)*N(аппендеров), а еще лучше такой же матрицей, только с иерархией (общий, группа логгеров, логгер) по одной оси и аналогично для аппендеров по другой.
Кажется, надо просто логи складывать в очереди и фильтровать их по уровням не на этапе создания, а на этапе чтения. Возможно, разве что уберотладочные на каждую букву в каком-нибудь парсере с конечным автоматом отсеивать, и то не факт.
no subject
Только не облако, а словарь типа "поле: значение" и потом по ним фильтровать.
no subject