Я пока к такому варианту пришел.

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

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

info это все действия-изменения, произошедшие с системой. Чтобы видеть что там вообще происходит. Обычно в консоль пускается именно это. Залогинился, создал запись, удалил запись и тд. Эдакий примитивный аудит, чтобы если что, можно было быстро понять что там происходило с логической точки зрения.

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

trace — самая подробная отладка, которая не включается в обычном режиме. Можно включить для конкретного модуля если вдруг не хватает остальной информации. Тот же debug но без ограничений.

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

Контекст — user ID и user IP. Ну и имя потока, конечно. Этого хватает, чтобы вычленить действия именно этого юзера. Честно говоря и имени потока хватает, я этой новомодной асинхронностью не пользуюсь, но если вдруг понадобится, можно изобрести какой-нибудь request ID.

Здравствуйте, Kernan, Вы писали:

Б>>Что пишут умные люди:
Б>>1. Писать в лог чем больше, тем лучше.
K>На одном проекте писались все входы и выходы из функция + дополнительные логи. В какой-то момент придумали сделать циклический буфер и во время проблемы дампить только его чтобы не нагружать систему. Этим продумктом был софтсвитч .

Вот кстати мне этого не хватает в библиотеках для логгирования. Я в логах указываю начало запроса, конец запроса. Они всю информацию по запросу держат в памяти, в случае ошибки создаётся файл инцидента, в который все логи всех уровней, относящиеся к запросу, запишутся. Самому такое велосипедить долго и скучно, а вот готовым функционалом я бы пользовался с удовольствием.

Здравствуйте, vsb, Вы писали:

vsb>error/fatal это то, чего происходить не должно. Логгируется в отдельный файл, любая запись в этом файле это баг, который надо исправлять.

Вот как бы такую разбивку сделать на log4net?

Здравствуйте, VladiCh, Вы писали:

VC>Использовать простой формат для логов (никакого json). json увеличивает в разы стоимость их обработки.

Почему увеличивает стоимость обработки? Вроде разница небольшая для обработки — что строка текста, что строка json. Искать по подстроке можно в обоих вариантах. Но в json можно быстро искать по сложным условиям, а в обычном текст — нет. В json легко собрать статистику, а в обычном тексте придется писать парсеры.

Здравствуйте, vsb, Вы писали:

vsb>Здравствуйте, Kernan, Вы писали:

Б>>>Что пишут умные люди:
Б>>>1. Писать в лог чем больше, тем лучше.
K>>На одном проекте писались все входы и выходы из функция + дополнительные логи. В какой-то момент придумали сделать циклический буфер и во время проблемы дампить только его чтобы не нагружать систему. Этим продумктом был софтсвитч .

vsb>Вот кстати мне этого не хватает в библиотеках для логгирования. Я в логах указываю начало запроса, конец запроса. Они всю информацию по запросу держат в памяти, в случае ошибки создаётся файл инцидента, в который все логи всех уровней, относящиеся к запросу, запишутся. Самому такое велосипедить долго и скучно, а вот готовым функционалом я бы пользовался с удовольствием.

Да, мне тоже такое интересно, писал об этом здесь

Автор: Буравчик
Дата: 26.10.18

. Чтобы, в лог сыпались info и warning, а в случае errors добавились все debug и trace.

На питоне таких логгеров нет (не знаю). А у тебя какой язык?

Здравствуйте, Буравчик, Вы писали:

Б>>>>Что пишут умные люди:
Б>>>>1. Писать в лог чем больше, тем лучше.
K>>>На одном проекте писались все входы и выходы из функция + дополнительные логи. В какой-то момент придумали сделать циклический буфер и во время проблемы дампить только его чтобы не нагружать систему. Этим продумктом был софтсвитч .

vsb>>Вот кстати мне этого не хватает в библиотеках для логгирования. Я в логах указываю начало запроса, конец запроса. Они всю информацию по запросу держат в памяти, в случае ошибки создаётся файл инцидента, в который все логи всех уровней, относящиеся к запросу, запишутся. Самому такое велосипедить долго и скучно, а вот готовым функционалом я бы пользовался с удовольствием.

Б>Да, мне тоже такое интересно, писал об этом здесь

Автор: Буравчик
Дата: 26.10.18

. Чтобы, в лог сыпались info и warning, а в случае errors добавились все debug и trace.

Б>На питоне таких логгеров нет (не знаю). А у тебя какой язык?

Java. Думаю можно с logback или log4j реализовать такое, но это нетривиально, в общем не настолько мне этого хочется.

Здравствуйте, Буравчик, Вы писали:

Б>Здравствуйте, VladiCh, Вы писали:

VC>>Использовать простой формат для логов (никакого json). json увеличивает в разы стоимость их обработки.

Б>Почему увеличивает стоимость обработки? Вроде разница небольшая для обработки — что строка текста, что строка json. Искать по подстроке можно в обоих вариантах. Но в json можно быстро искать по сложным условиям, а в обычном текст — нет. В json легко собрать статистику, а в обычном тексте придется писать парсеры.

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

Здравствуйте, Sharov, Вы писали:

S>Вот как бы такую разбивку сделать на log4net?

Как-то так:

<log4net>
    <appender name="ErrorAppender" type="log4net.Appender.FileAppender">
        <filter type="log4net.Filter.LevelRangeFilter">
            <levelMin value="ERROR" />
            <levelMax value="FATAL" />
        </filter>
        <file value="errors.log" />
        <appendToFile value="true" />
        <layout type="log4net.Layout.PatternLayout">
            <conversionPattern value="%date [%thread] %-5level %logger - %message%newline" />
        </layout>
    </appender>
    <appender name="CommonAppender" type="log4net.Appender.FileAppender">
        <file value="common.log" />
        <appendToFile value="true" />
        <layout type="log4net.Layout.PatternLayout">
            <conversionPattern value="%date [%thread] %-5level %logger - %message%newline" />
        </layout>
    </appender>
    <root>
        <level value="DEBUG" />
        <appender-ref ref="ErrorAppender" />
        <appender-ref ref="CommonAppender" />
    </root>
</log4net>

Здравствуйте, Буравчик, Вы писали:

Б>Возможно удобно иметь конструкцию, которая бы позволяла добавлять в каждое сообщение некоторую информацию (например, request_id)

Б>

Б>with log.context(request_id='...') as inner_log:
Б>    # здесь во все JSON-лог сообщения будет добавляться предопределенный ключ request_id
Б>    inner_log.info()
Б>    inner_log.debug()
Б>

Спустя некоторое время добавлю. Такая возможность есть в structlog для питон. Умеет создавать логи на json, привязывать контекст и др.

Здравствуйте, bnk, Вы писали:

bnk>json вообще не уперся, если обычный текст фильтруется (каждая строчка содержит таймстемп и юзера)

У JSON есть такое преимущество, что разным частям системы проще иметь одинаковое понимание, где есть одна запись, а где две.

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

Можно регулярными выражениями в Sumo настроить, чтобы оно их обратно склеило или доработать логгирование в приложении, чтоб оно каждую строку отдельно форматировало (но это дополнительный мусор в логах), но с JSON таких проблем нет.

Здравствуйте, vsb, Вы писали:

vsb>Здравствуйте, Kernan, Вы писали:

Б>>>Что пишут умные люди:
Б>>>1. Писать в лог чем больше, тем лучше.
K>>На одном проекте писались все входы и выходы из функция + дополнительные логи. В какой-то момент придумали сделать циклический буфер и во время проблемы дампить только его чтобы не нагружать систему. Этим продумктом был софтсвитч .

vsb>Вот кстати мне этого не хватает в библиотеках для логгирования. Я в логах указываю начало запроса, конец запроса. Они всю информацию по запросу держат в памяти, в случае ошибки создаётся файл инцидента, в который все логи всех уровней, относящиеся к запросу, запишутся. Самому такое велосипедить долго и скучно, а вот готовым функционалом я бы пользовался с удовольствием.

в одном из C# проектов я использовал такой подход:

void SomeFunction()
{
using (xxx)
{
// Function body
}
}



xxx -- вначале писал название ф-ции, которая запускается, а после выполнения Function body, что ф-ция успешно завершена

Здравствуйте, Буравчик, Вы писали:

Б>Как ЭТО происходит у вас? Поделитесь своими практиками/правилами?

У меня есть софтина для управления технологическим процессом, там ведение журнала — требование заказчика.
Чтобы если попрёт брак, можно было посмотреть, во сколько минут-секунд на каком участке сколько было вольт, ампер и градусов.
Кроме этого пишу все моменты принятия решений, типа "произошло событие такое-то, реагируем действием таким-то".
Также пишу действия оператора, его лазания в конфигурации, выдачу и сброс сообщений об ошибках и т.п.
Короче говоря — всё, что может помочь в разбирательствах, когда что-то пошло не так.
Основной журнал с цифирью вольты-амперы-входа-выхода-регистры пишется в CSV, чтобы в экселе было удобно смотреть/фильтровать.
Доп. информация о том, что при этом происходило в программе, копится в буферную строку и дописывается в последнее поле.
Вот как-то так.

Здравствуйте, Буравчик, Вы писали:


Б>2. Использовать машиночитаемый формат сообщений (json)

Логи надо держать в текстовом формате, что бы можно было посмотреть данные в любом тектовом редакторе
или стандартными утилитами для просмотра логов: cat, grep на любом компьютере будь-то домашний пк
или сервер с минимальным набором программ.
json сам по себе г-формат для данных(нельзя писать комментарии и т.д), не говоря о том что бы исспользовать его для логов.

Здравствуйте, #John, Вы писали:

Б>>2. Использовать машиночитаемый формат сообщений (json)

J>Логи надо держать в текстовом формате, что бы можно было посмотреть данные в любом тектовом редакторе

json нормально читается текстовым редактором и понимается человеком

J>или стандартными утилитами для просмотра логов: cat, grep на любом компьютере будь-то домашний пк
J>или сервер с минимальным набором программ.

Логи пишутся обычно в jsonlines. С этим форматом прекрасно работает cat и grep

J>json сам по себе г-формат для данных(нельзя писать комментарии и т.д), не говоря о том что бы исспользовать его для логов.

Комментарии в логах не нужны.
А вот анализировать логи становится удобно. Например с помощью утилиты jq

Здравствуйте, Буравчик, Вы писали:

У нас логи только в отладочных версиях. В релизных нельзя.

Уровни логирования настраиваются. Максимальный 5-ый уровень срёт в лог по гигу за 5 мин.

Здравствуйте, Мёртвый Даун, Вы писали:

МД>У нас логи только в отладочных версиях. В релизных нельзя.

Админзапрет? А почему?

МД>У нас логи только в отладочных версиях. В релизных нельзя.

МД>Уровни логирования настраиваются. Максимальный 5-ый уровень срёт в лог по гигу за 5 мин.

А как происходит отключение логирования в релизах?

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

Здравствуйте, #John, Вы писали:

Б>>2. Использовать машиночитаемый формат сообщений (json)
J>Логи надо держать в текстовом формате, что бы можно было посмотреть данные в любом тектовом редакторе

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

Здравствуйте, Буравчик, Вы писали:

Б>Поделитесь полезными советами про логи.

Логи — это отдельная и очень важная задача встречающаеся от микроконтролёров до глобальных сервисов. В некоторых случаях записи в логах могут иметь денежные и юридические последствия. В больших конторах есть специальные отделы занимающиеся исключительно анализом логов. В некоторых програмных продуктах время потраченное на разработку софта связанного с логами может занимать до 50% разработки. А в специальных случаях (см. черные ящики) все 100%. Нельзя говорить о лучших практиках логирования вообще. Это как спросить о лучших практиках программирования не уточняя ни язык, ни область задач.

Здравствуйте, B0FEE664, Вы писали:

BFE>В больших конторах есть специальные отделы занимающиеся исключительно анализом логов. В некоторых програмных продуктах время потраченное на разработку софта связанного с логами может занимать до 50% разработки.

Различаешь ли ты в этом сбор собственно логов, аналитики, метрики, телеметрии?