Logging

[metaclass]

Не хватает одной вещи в log4net, да и вообще в логах - явного отображения иерархии вызовов.

У меня один метод пишет в лог в процессе работы три раза, в промежутках вызывает методы, которые тоже пишут в лог свои данные. Даже с более менее понятными строками для вывода в лог, понять, кто кого вызывает, очень сложно, не наглядно как-то получается. Да еще эта падла работает в двух потоках, одновременно с GUI и звукозаписью, т.е. события приходят и от фонового потока воспроизведения и от виндовских событий, вроде отрисовки или там перемещения курсора.

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

Comments

[perplexed-bear.livejournal.com]

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

[volodymir-k.livejournal.com]

В лог4ж есть thread-local переменная, т.н.контекст, именно для много поточности -- там можно userid / сессионИд / что угодно покласть.

Насчёт стеков вызовов, это плохая идея. Для похожего есть две методы: или в самом сообщении писать, что за класс-метод, или имя логгера подобрать осмысленное. А если например процедура будет рекурсивная, то стек вызовов будет конский и неинформативный. Потом Вам захочется рисовать аргументы. Потом окажется, что аргументы сцуко большие, список списков в мильён строк и пр.шиза.

[metaclass.livejournal.com]

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

[volodymir-k.livejournal.com]

> когда вообще непонятно откуда вызовы приходят

Неряшливо задизайнены зависимости компонентов, подозреваю. Если пользователи пакета не определены заранее, то да, вопросы есть. Лечится рефакторингом, то есть редко и тяжело.

> вычислять разницу, хранить еще один стек для откатов состояний при возвратах и прочий долгоиграющий мрак

Похоже на отладчик Пролога )))
А вообще да, хорошо бы в ЯП ввести понятие intent, и чтобы его можно было закодировать и потом поглядеть на рантайме. Имя функции ОБЯЗАНО его отражать, но сам вызов функции ("зачем звал, братишка?") никак не документируется.

[lemantar.livejournal.com]

Стек трейс тебе в помощь.

[vp.livejournal.com]

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

[lemantar.livejournal.com]

у аффтара иная проблема "Не хватает одной вещи в log4net, да и вообще в логах - явного отображения иерархии вызовов."

[blackyblack.livejournal.com]

Согласен. Но для каждой записи в лог не применить.
Лично я в особо запущенных случаях использовал логирование входа в метод и выход. Тогда иерархию вызовов видно.
От рекурсии можно и нужно избавляться.

[http://users.livejournal.com/_windwalker_/]

В log4j есть такое понятие, как MDC. Который и позволяет реализовывать ету самую иерархию (вроде как). Вполне возможно что и в log4net есть.

[metaclass.livejournal.com]

Есть, да. Только заполнять его вроде надо ручками, контекст этот.

[http://users.livejournal.com/_windwalker_/]

AOP ?