Логи

[metaclass]

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

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

Comments

[bydlorus.livejournal.com]

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

[metaclass.livejournal.com]

Было бы весьма удобно.
Только не облако, а словарь типа "поле: значение" и потом по ним фильтровать.

[nealar.livejournal.com]

MDC?

[henu3detb.livejournal.com]

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

[metaclass.livejournal.com]

Я про уровень в вызове логгеров, в коде особо не поменяешь на ходу.
И таки делать имитацию этого средствами log4х - неудобненько.

[henu3detb.livejournal.com]

Поставил дебаг для всего, погрепал, вернул в ворн.
Чота я не вижу проблемы.

[metaclass.livejournal.com]

дебаг для всего + лимиты на размер логов - информация за час уходит в никуда.

[berezovsky.livejournal.com]

можно периодически паковать и складывать на удалённый сервер

[henu3detb.livejournal.com]

или агрегаторы логов

[leotsarev]

Тем же лог4нет делаем так: еррорные логи лежат за годы, инфошные за недели, дебажные за дни.

[metaclass.livejournal.com]

Я просто по размеру ограничиваю все кроме error.
На клиентах до 10 мег, на сервере до 100 мег.

[leotsarev]

Они по размеру ограничены, я результат говорю

[develop7]

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

[metaclass.livejournal.com]

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

[n16bs.livejournal.com]

Давайте просто снимать и складывать инкрементные дампы процесса вместо писания логов.

[develop7]

логика из разряда «поскольку преступления по-прежнему происходят, полицию следует распустить». пробуйте тяжелее.

[n16bs.livejournal.com]

В моём посте нет тега иронии.

[develop7]

без иронии, значит. надо понимать, вы и сами так делаете (иначе с чего бы вы другим людям советовали), да?

[nivanych.livejournal.com]

Не делает, но собирается!
И собирает единомышленников!

[metaclass.livejournal.com]

Да, диффы состояний процесса было бы неплохо.

[ynot.livejournal.com]

в хекс-едиторе, буахаха.

(Метаязык описания состояния процесса ннада? убер-стек-трейс. Как свойство языка, понятное дело, чтоб без лишних телодвижений. может получиться забавно.)

[blackyblack.livejournal.com]

Ну я так и делаю: [дата время] [уровень лога] [поток] [модуль] [функция:строка] текст
При желании можно пофильтровать как душе угодно.

[gineer.livejournal.com]

и по идее большую часть из этого можно кешировать/препроцесить... или вообще, хранить вместе с дебажной информацией?

[metaclass.livejournal.com]

Внятных способов не знаю.
А вообще очень сильно не помешало бы - ссылаться из лога прямо на место в *.pdb, да еще и с областями памяти локальных переменных.

[gineer.livejournal.com]

и по идее большую часть из этого можно кешировать/препроцесить... или вообще, хранить вместе с дебажной информацией?

[kiryl.livejournal.com]

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

[metaclass.livejournal.com]

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

[kiryl.livejournal.com]

дык не показывай. складывай бинарные стекфреймы в сторонку куда-нить и разгребай в offline. ftrace в ядре как-то так и работает: во время трассировки складыват в бинарный ring buffer и только когда кто-то попросил делает из этого что-то читаемое. получается терпимо.

[jakobz.livejournal.com]

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

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

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

[metaclass.livejournal.com]

Да, не хватает и этого тоже.

[jakobz.livejournal.com]

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

[nivanych.livejournal.com]

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

[voidex.livejournal.com]

Я эксперимента ради делал так:

scope "foo" $ do
  log Trace "lala"
  ...
  log Trace "done"

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

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

[jakobz.livejournal.com]

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

[tonsky.livejournal.com]

Это тоже теги. RequestId=1124343, все сообщения, связанные с реквестом, им протегированы

[nivanych.livejournal.com]

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

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

[vit-r.livejournal.com]

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

[ilya-portnov.livejournal.com]

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

[victorgr.livejournal.com]

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

[metaclass.livejournal.com]

Методом "дать 100 гб логов безопасникам заказчика и пусть фильтруют от приватных данных". А на вопросы юзеров - посылать к ним же. "Они еще логи не очистили".

На практике - ну не писать эти данные в логи, делов то.

[jakobz.livejournal.com]

Ха, я помню у нас приложение одно срало в логи XML-ем столько, что одно это жрало половину ресурсов. А еще 2/3 от этого - тратилось на сериализацию/десериализацию, и на GC этого всего говна.

Так вот даже в такой ситуации умные люди не постеснялись туда регекс впаять, который >10 последовательных цифр крестиками заменяет - номера кредиток отфильтровывать. Чтобы еще больше тормозило.

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

[zaharchenko]

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

[metaclass.livejournal.com]

Надо считать, что в среднем на продакшен у программистов нет доступа.
А если есть - то там нет админских прав.

[zaharchenko]

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

Да и по большому счету, вот логи, право читать их программисту как-то кто-то дал же, почему не дать право на подебагать?

[inconceivable2.livejournal.com]

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

[metaclass.livejournal.com]

Так можно, за исключением одной тонкости с log4net - ему можно передавать какие угодно объекты, но он от них будет вызывать ToString() (который может быть сколь угодно тяжелым) только если этот объект пролез через фильтры уровня логов.