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

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

R>>·>Ты вначале расскажи — кто будет читать логи и с какой целью?
R>>Ну перечитай первое сообщение, там ведь хорошо написано.
R>>

R>>С вопросами всегда приходят к вам. Что, как, и в каком объёме вы стали бы логировать? Поделитесь стратегией

R>>"Если бы с вопросами всегда приходили ко мне, то я бы логировал <тут идут твои сакральные знания, добытые потом и кровью за десятилетия опыта>".
·>Ты просто плохо задал вопрос, как будто ты ожидаешь универсальный рецепт. Ведь всё очень зависит от ситуации. Вот я и пытаюсь выудить из тебя подробности.

Иногда неспособность читателя прочитать может выглядеть как неспособность автора написать. Мне не нужен универсальный рецепт — мне нужны ценности, которых придерживаешься конкретно ТЫ, когда принимаешь решение что логировать, что не логировать, как логировать, как не логировать. Перестань пожалуйста мне планировать IT стратегию масштаба предприятия на следующие 5 лет. Вопрос про логи. Не усложняй. Как потом интерпретировать твой ответ, я разберусь.

·>С какими вопросами к тебе приходят?

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

·>Какие проблемы с логами у тебя возникают сейчас?

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

·>Общие тезисы.

А вот за это спасибо!

·>Надо логгировать всё что приложение получает извне и отправляет наружу.
·>Если объёмы данных огромны — надо думать как сократить.
·>не логгировать sensitive информацию (пароли/ключи/етс).
·>Идеально, если по логам ты можешь воспроизвести проблему локально.

Это отличный критерий, не очень понятно только, как в практику это перевести. В голову приходит например: для каждого ветвления говорить почему получилось true/false, и по какой ветке в итоге пошли.

·>Не имеет смысл логгировать то, что и так ясно из кода. Например, логгировать посылаемые в субд sql-запросы смысла нет — они и так есть в коде.

По-моему не так очевидно. В случае ORM, когда запросы строятся динамически по параметрам снаружи, интересно же, что именно там получилось. Вполне может получиться страшный запрос со страшным планом, который не уложится в таймаут потока, обрабатывающего HTTP запрос, клиент получит 500, к нам придут с вопросом. Или это относится к "приложение получает извне"?

·>Логгировать стектрейсы исключений. Имя треда. Положение в коде (т.е. по каждому сообщению в логе должна быть возможность однозначно идентифицировать строчку в коде).
·>Из лога должна быть возможность однозначно определить версию кода (git commit id какой-нибудь) и текущую конфигурацию (используемые ENV, конфиги, етс).

спасибо.