metaclass: (Default)
metaclass ([personal profile] metaclass) wrote2015-12-18 01:20 pm

Логи

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

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

[identity profile] jakobz.livejournal.com 2015-12-18 11:24 am (UTC)(link)
Мне еще иерархичности самих логов не хватает. Скажем обрабатываем веб-запрос. Ну там trace("начал"), trace("пошол в бд"), trace("кончел").

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

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

[identity profile] metaclass.livejournal.com 2015-12-18 11:27 am (UTC)(link)
Да, не хватает и этого тоже.

[identity profile] jakobz.livejournal.com 2015-12-18 11:33 am (UTC)(link)
Кстати вот в teamcity когда лог смотришь - он как раз так показывает, причем на лету обновляет и показывает текущую ветку. Вот такое бы что-нибудь.

[identity profile] nivanych.livejournal.com 2015-12-18 11:46 am (UTC)(link)
Если придумать способ как-то адекватно ограничить запись в подветку,
что после какого-то времени, её можно было "законсервировать" без конфликтов,
то получилось бы вполне годная штука.
С другой стороны, для логов в базе данных, их деревянность почти ничего не усложнит и не сильно замедлит.
Кроме того, что для каких-то случаев обработки, они принципиально сложнее.

[identity profile] voidex.livejournal.com 2015-12-18 12:50 pm (UTC)(link)
Я эксперимента ради делал так:
scope "foo" $ do
  log Trace "lala"
  ...
  log Trace "done"


Если всё вышло ок, ниже какого-то уровня ничего не выводится, а если фейл - выводятся
+ путь из scope-ов

Ну и соот-но можно временно для конкретного scope или пути включить логирование всего подряд

[identity profile] jakobz.livejournal.com 2015-12-18 12:56 pm (UTC)(link)
У меня такая же приспособа для всяких тормозных background-job-ов.
Пишешь
var result = ctx.Run("Querying API", () => api.Query("http://a.com"));
И в лог срется типа
Starting Querying API
... тут всякое вложенное с отступом
Done Querying API in 13 sec.

[identity profile] tonsky.livejournal.com 2015-12-18 06:55 pm (UTC)(link)
Это тоже теги. RequestId=1124343, все сообщения, связанные с реквестом, им протегированы