Логи
Я пришел к выводу, что осмысленно выбрать уровни логов (log4j, log4net) в вызовах внутри программы при разработке невозможно.
Всегда возникнет ситуация, в которой конкретно вот сейчас, без перезагрузки сервиса надо сменить уровень лога в данном конкретном методе.
Делать отдельные логгеры на каждый чих и конфигурировать их - это адский комбинаторный взрыв, конфиги становятся нечитабельными, когда там в xml пытаются засунуть то, что должно быть матрицей M(логгеров)*N(аппендеров), а еще лучше такой же матрицей, только с иерархией (общий, группа логгеров, логгер) по одной оси и аналогично для аппендеров по другой.
Кажется, надо просто логи складывать в очереди и фильтровать их по уровням не на этапе создания, а на этапе чтения. Возможно, разве что уберотладочные на каждую букву в каком-нибудь парсере с конечным автоматом отсеивать, и то не факт.
Всегда возникнет ситуация, в которой конкретно вот сейчас, без перезагрузки сервиса надо сменить уровень лога в данном конкретном методе.
Делать отдельные логгеры на каждый чих и конфигурировать их - это адский комбинаторный взрыв, конфиги становятся нечитабельными, когда там в xml пытаются засунуть то, что должно быть матрицей M(логгеров)*N(аппендеров), а еще лучше такой же матрицей, только с иерархией (общий, группа логгеров, логгер) по одной оси и аналогично для аппендеров по другой.
Кажется, надо просто логи складывать в очереди и фильтровать их по уровням не на этапе создания, а на этапе чтения. Возможно, разве что уберотладочные на каждую букву в каком-нибудь парсере с конечным автоматом отсеивать, и то не факт.
no subject
Вот эти все trace - нахер не нужны в 99% случаев, но если оно где-то упало в конце - неплохо бы поиметь их все, с самого начала, на всю обработку запроса.
Если бы лог был бы древовидный, это все можно было бы неплохо завернуть. Включая, вероятно, и твою задачу - включить логирование всего для такого-то метода на время, вместе с трейсами.
no subject
no subject
no subject
что после какого-то времени, её можно было "законсервировать" без конфликтов,
то получилось бы вполне годная штука.
С другой стороны, для логов в базе данных, их деревянность почти ничего не усложнит и не сильно замедлит.
Кроме того, что для каких-то случаев обработки, они принципиально сложнее.
no subject
Если всё вышло ок, ниже какого-то уровня ничего не выводится, а если фейл - выводятся
+ путь из scope-ов
Ну и соот-но можно временно для конкретного scope или пути включить логирование всего подряд
no subject
Пишешь
var result = ctx.Run("Querying API", () => api.Query("http://a.com"));
И в лог срется типа
Starting Querying API
... тут всякое вложенное с отступом
Done Querying API in 13 sec.
no subject