Логи

[metaclass]

Я пришел к выводу, что осмысленно выбрать уровни логов (log4j, log4net) в вызовах внутри программы при разработке невозможно.
Всегда возникнет ситуация, в которой конкретно вот сейчас, без перезагрузки сервиса надо сменить уровень лога в данном конкретном методе.
Делать отдельные логгеры на каждый чих и конфигурировать их - это адский комбинаторный взрыв, конфиги становятся нечитабельными, когда там в xml пытаются засунуть то, что должно быть матрицей M(логгеров)*N(аппендеров), а еще лучше такой же матрицей, только с иерархией (общий, группа логгеров, логгер) по одной оси и аналогично для аппендеров по другой.

Кажется, надо просто логи складывать в очереди и фильтровать их по уровням не на этапе создания, а на этапе чтения. Возможно, разве что уберотладочные на каждую букву в каком-нибудь парсере с конечным автоматом отсеивать, и то не факт.

Comments

[bydlorus.livejournal.com]

В каждый msg - облако тэгов!

[henu3detb.livejournal.com]

смена log level в log4j не требует перезагрузки сервера.

[develop7]

ещё добавить вагон метаинформации к каждой записи и получится почти journald

[kiryl.livejournal.com]

Может тебе нужен осмысленый трейсинг вместо логирования? Думаю, в ваших jvm'ах с д дотнетами это не дожно быть проблемой. Особенно если производительноить не сильно поджимает.

[jakobz.livejournal.com]

Мне еще иерархичности самих логов не хватает. Скажем обрабатываем веб-запрос. Ну там trace("начал"), trace("пошол в бд"), trace("кончел").

Вот эти все trace - нахер не нужны в 99% случаев, но если оно где-то упало в конце - неплохо бы поиметь их все, с самого начала, на всю обработку запроса.

Если бы лог был бы древовидный, это все можно было бы неплохо завернуть. Включая, вероятно, и твою задачу - включить логирование всего для такого-то метода на время, вместе с трейсами.

[nivanych.livejournal.com]

> не на этапе создания, а на этапе чтения

В таком случае, придётся отказаться от чего-то типа "paranoid"-уровня логов —
будет просто чрезмерно для обычных случаев засирать.
Впрочем, я очень не уверен, нужно ли такое.

[vit-r.livejournal.com]

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

[ilya-portnov.livejournal.com]

Есть ещё вариант каждому сообщению, которому может быть захочется поменять уровень, присваивать какой-нибудь guid. И в БД/конфиге иметь табличку переопределений guid -> severity. Генерацию гуидов и удобное редактирование конфига повесить на платформу/среду разработки.

[victorgr.livejournal.com]

Как не допускать попадания в логи приватных данных?

[zaharchenko]

А не легче ли в таком случае дебагером подключиться к работающему процессу?

[inconceivable2.livejournal.com]

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