Есть веб аппликейшн. Принимает запросы, ходит в базу, отдаёт ответы. Иногда запросы 500. Иногда отправляет письма. Иногда письма не приходят. Иногда выполняет задачи по расписанию, раз в день например. Задачи иногда не стартуют. Иногда стартуют, но падают. Некоторые запросы обрабатываются асинхронно. Иногда падают. С вопросами всегда приходят к вам. Что, как, и в каком объёме вы стали бы логировать? Поделитесь стратегией
Примеры:
1. Ничего не стану специально логировать, а стектрейсы при падениях сами пишутся в логи.
2. Применю аспектно-ориентированную магию, буду прям трассировку в логи писать.
3. Сделаю по крайней мере некие correlation ID, чтобы идентифицировать каждую логическую транзакцию (HTTP запрос, попытку выполнить задачу). В самом начале логической транзакции буду логировать весь известный контекст: всякие userId, taskId, и т.д.
4. На каждую строчку полезного кода буду добавлять запись в лог руками.
Здравствуйте, rosencrantz, Вы писали:
R>Есть веб аппликейшн. Принимает запросы, ходит в базу, отдаёт ответы. Иногда запросы 500. Иногда отправляет письма. Иногда письма не приходят. Иногда выполняет задачи по расписанию, раз в день например. Задачи иногда не стартуют. Иногда стартуют, но падают. Некоторые запросы обрабатываются асинхронно. Иногда падают. С вопросами всегда приходят к вам. Что, как, и в каком объёме вы стали бы логировать? Поделитесь стратегией
Есть же промышленные решения для таких проблем. Вагон и маленькая тележка.
Azure AppInsights например. Или App Dynamics.
Да, AppInsights обзавелось неким подобием ИИ, так что если твои сервисы работаю на Azure, оно само вызовы друг с другом свяжет,
чтобы можно было отследить от клика кнопки на фронтенде до запроса в базу. То есть, тебе для этого ничего особо делать не надо.
Пользуюсь log4j, логгирую в файлы. По умолчанию в продакшне включены debug+ логи. В коде пишу trace не слишком часто, для тех мест, которые с одной стороны будут спамить очень много, т.е. по умолчанию их включать не будет никто, но с другой стороны если вдруг понадобится разобраться, чтобы можно было в конкретном месте включить быстро. В debug пишу потенциально полезные для отладки, но не особо спамящие логи, debug-логи обычно в районе недели хранятся. info+ логи уже предназначены для вечного хранения (ну условно вечного), поэтому там точно ничего спамящего не должно быть, обычно просто по факту выполнения операции записываю что-нибудь или какую-то статистику. Условно 1-5 строк info-лога на запрос должно быть. warning+ это уже ошибки, в идеале их в логе не должно быть. warning это обычно нестандартная ситуация, которую система обработала без проблем, например кривой запрос пришёл. Если это закрытая система, то это повод связаться с теми, кто прислал этот запрос и попросить их исправить свой софт. Ну если открытая система, там понятно, что может любой полтергейст в сокет стучаться, тут уже ничего не поделаешь, но если их много, значит какая-то фигня точно происходит. error это скорей всего баг, сразу надо разбираться и чинить. fatal это баг например с падением приложения, в целом редкость.
Каждый уровень лога пишется в отдельный файл (с вышестоящими уровнями, конечно). Т.е. сразу видно, если в error-логе есть новые записи.
Все корреляции по thread id видно, я всякой реактивной ерундой не пользуюсь, поэтому тут всё просто как два рубля — вытаскиваешь предыдущие записи в логе по этому thread id до первой, в которой логгируется сам запрос на входе и всё.
Чисто теоретически я бы хотел видеть логгирование с инцидентной системой. Как я это вижу: для запроса создаётся этот самый корреляционный id, который привязывается к треду (даже в реактивных системах обычно есть коллбеки на привязывание/отвязывание). Все логи от начала до конца пишутся помимо своих назначений ещё в какой-то буфер в памяти (вне зависимости от включенных уровней логгирования). Когда запрос завершает своё выполнение, то производится анализ записанных логов. Если была запись уровня error+, то создаётся отдельный файл, в который все собранные логи всех уровней во время выполнения этого запроса дополнительно записываются. Таким образом каждой ошибке будет соответствовать файл с подробным логгированием всего происходящего во время этого запроса. Но готовой реализации такой системы я не видел, а самому писать не захотелось, не настолько оно мне надо. Но в целом это бы точно решило все мои хотелки.
А вообще говорят, что умные люди сейчас всякие хитрые системы по сбору логов применяют. Мне это не применимо, но в целом, наверное, все эти файлы и уровни это прошлый век, с этой бигдатой всё проще должно быть. Логгируй всё от начала до конца, включай там все эти аспектные логгирования, а оно пусть само разбирается, что куда сохранять, процессора много, диски толстые.
Здравствуйте, rosencrantz, Вы писали:
r> С вопросами всегда приходят к вам. Что, как, и в каком объёме вы стали бы логировать? Поделитесь стратегией
Цель — не писать логи, цель чтобы к тебе пореже приходили, а если пришли с вопросами — ты должен уметь на них ответить за вменяемое время. Вот эту проблему и решай.
Если писать слишком много логов — будет проблема найти в них что-то полезное. И та же проблема если логов слишком мало.
Так же надо и другими способами решать проблемы — обрабатывай ошибочные ситуации правильно. Посылай уведомления если что-то не получилось с объяснением причин и как пофиксить, повторяй действия, если сеть отвалилась и т.п.
Здравствуйте, bnk, Вы писали:
bnk>Есть же промышленные решения для таких проблем. Вагон и маленькая тележка. bnk>Azure AppInsights например. Или App Dynamics.
bnk>Да, AppInsights обзавелось неким подобием ИИ, так что если твои сервисы работаю на Azure, оно само вызовы друг с другом свяжет, bnk>чтобы можно было отследить от клика кнопки на фронтенде до запроса в базу. То есть, тебе для этого ничего особо делать не надо.
Да, это всё здорово, только оно ведь исключительно механику мониторит — с проблемами в логике или в данных оно никак не поможет.
bnk>Еще логи вот тут обсуждали bnk>http://rsdn.org/forum/design/7253326.flat
Здравствуйте, ·, Вы писали:
·>Здравствуйте, rosencrantz, Вы писали:
r>> С вопросами всегда приходят к вам. Что, как, и в каком объёме вы стали бы логировать? Поделитесь стратегией ·>Цель — не писать логи, цель чтобы к тебе пореже приходили, а если пришли с вопросами — ты должен уметь на них ответить за вменяемое время. Вот эту проблему и решай. ·>Если писать слишком много логов — будет проблема найти в них что-то полезное. И та же проблема если логов слишком мало.
·>Так же надо и другими способами решать проблемы — обрабатывай ошибочные ситуации правильно. Посылай уведомления если что-то не получилось с объяснением причин и как пофиксить, повторяй действия, если сеть отвалилась и т.п.
Дада, стратегическое планирование я и сам умею, ты мне расскажи что в логи писать
Здравствуйте, rosencrantz, Вы писали:
bnk>>Да, AppInsights обзавелось неким подобием ИИ, так что если твои сервисы работаю на Azure, оно само вызовы друг с другом свяжет, bnk>>чтобы можно было отследить от клика кнопки на фронтенде до запроса в базу. То есть, тебе для этого ничего особо делать не надо.
R>Да, это всё здорово, только оно ведь исключительно механику мониторит — с проблемами в логике или в данных оно никак не поможет.
Для ошибок стека вызовов и исключения часто бывает достаточно. (в смысле, стека во всех приложениях, объеденных одной "операцией", типа "Вася кликнул кнопку купить и все сломалось")
Можно настроить, чтобы оно по клику на исключение прямо исходник показывало, где исключение произошло (source maps)
Если тебя не только ошибки волнуют, тогда да, придется что-то еще писать.
Здравствуйте, rosencrantz, Вы писали:
R>·>Цель — не писать логи, цель чтобы к тебе пореже приходили, а если пришли с вопросами — ты должен уметь на них ответить за вменяемое время. Вот эту проблему и решай. R>·>Если писать слишком много логов — будет проблема найти в них что-то полезное. И та же проблема если логов слишком мало. R>·>Так же надо и другими способами решать проблемы — обрабатывай ошибочные ситуации правильно. Посылай уведомления если что-то не получилось с объяснением причин и как пофиксить, повторяй действия, если сеть отвалилась и т.п. R>Дада, стратегическое планирование я и сам умею, ты мне расскажи что в логи писать
Ты вначале расскажи — кто будет читать логи и с какой целью?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Здравствуйте, rosencrantz, Вы писали:
R>>·>Цель — не писать логи, цель чтобы к тебе пореже приходили, а если пришли с вопросами — ты должен уметь на них ответить за вменяемое время. Вот эту проблему и решай. R>>·>Если писать слишком много логов — будет проблема найти в них что-то полезное. И та же проблема если логов слишком мало. R>>·>Так же надо и другими способами решать проблемы — обрабатывай ошибочные ситуации правильно. Посылай уведомления если что-то не получилось с объяснением причин и как пофиксить, повторяй действия, если сеть отвалилась и т.п. R>>Дада, стратегическое планирование я и сам умею, ты мне расскажи что в логи писать ·>Ты вначале расскажи — кто будет читать логи и с какой целью?
Ну перечитай первое сообщение, там ведь хорошо написано.
С вопросами всегда приходят к вам. Что, как, и в каком объёме вы стали бы логировать? Поделитесь стратегией
"Если бы с вопросами всегда приходили ко мне, то я бы логировал <тут идут твои сакральные знания, добытые потом и кровью за десятилетия опыта>".
Здравствуйте, rosencrantz, Вы писали:
R>·>Ты вначале расскажи — кто будет читать логи и с какой целью? R>Ну перечитай первое сообщение, там ведь хорошо написано. R>
R>С вопросами всегда приходят к вам. Что, как, и в каком объёме вы стали бы логировать? Поделитесь стратегией
R>"Если бы с вопросами всегда приходили ко мне, то я бы логировал <тут идут твои сакральные знания, добытые потом и кровью за десятилетия опыта>".
Ты просто плохо задал вопрос, как будто ты ожидаешь универсальный рецепт. Ведь всё очень зависит от ситуации. Вот я и пытаюсь выудить из тебя подробности.
С какими вопросами к тебе приходят? Какие проблемы с логами у тебя возникают сейчас?
Общие тезисы.
Надо логгировать всё что приложение получает извне и отправляет наружу.
Если объёмы данных огромны — надо думать как сократить.
не логгировать sensitive информацию (пароли/ключи/етс).
Идеально, если по логам ты можешь воспроизвести проблему локально.
Не имеет смысл логгировать то, что и так ясно из кода. Например, логгировать посылаемые в субд sql-запросы смысла нет — они и так есть в коде.
Логгировать стектрейсы исключений. Имя треда. Положение в коде (т.е. по каждому сообщению в логе должна быть возможность однозначно идентифицировать строчку в коде).
Из лога должна быть возможность однозначно определить версию кода (git commit id какой-нибудь) и текущую конфигурацию (используемые ENV, конфиги, етс).
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Здравствуйте, rosencrantz, Вы писали:
R>>·>Ты вначале расскажи — кто будет читать логи и с какой целью? R>>Ну перечитай первое сообщение, там ведь хорошо написано. R>>
R>>С вопросами всегда приходят к вам. Что, как, и в каком объёме вы стали бы логировать? Поделитесь стратегией
R>>"Если бы с вопросами всегда приходили ко мне, то я бы логировал <тут идут твои сакральные знания, добытые потом и кровью за десятилетия опыта>". ·>Ты просто плохо задал вопрос, как будто ты ожидаешь универсальный рецепт. Ведь всё очень зависит от ситуации. Вот я и пытаюсь выудить из тебя подробности.
Иногда неспособность читателя прочитать может выглядеть как неспособность автора написать. Мне не нужен универсальный рецепт — мне нужны ценности, которых придерживаешься конкретно ТЫ, когда принимаешь решение что логировать, что не логировать, как логировать, как не логировать. Перестань пожалуйста мне планировать IT стратегию масштаба предприятия на следующие 5 лет. Вопрос про логи. Не усложняй. Как потом интерпретировать твой ответ, я разберусь.
·>С какими вопросами к тебе приходят?
Юзер купил подписку на продукт, должен был получить письмо, не получил. Вопросы: почему? что теперь делать?
Юзер купил подписку на продукт, выслали ему временный пароль. Юзер пытается зайти, пароль не подходит. Вопросы: почему? что теперь делать?
Юзер тыкнул кнопку в приложении, ничего не произошло. Вопросы: почему? что теперь делать?
·>Какие проблемы с логами у тебя возникают сейчас?
Да в принципе никаких. Но это не из-за того, что логи хорошие, а из-за того, что почти любой фейл совершенно не критичен, и в большинстве случаев я могу сказать "хз, флуктуация какая-то" и на этом всё закончится. Это не должно быть релевантной частью контекста в этом обсуждении.
·>Общие тезисы.
А вот за это спасибо!
·>Надо логгировать всё что приложение получает извне и отправляет наружу. ·>Если объёмы данных огромны — надо думать как сократить. ·>не логгировать sensitive информацию (пароли/ключи/етс). ·>Идеально, если по логам ты можешь воспроизвести проблему локально.
Это отличный критерий, не очень понятно только, как в практику это перевести. В голову приходит например: для каждого ветвления говорить почему получилось true/false, и по какой ветке в итоге пошли.
·>Не имеет смысл логгировать то, что и так ясно из кода. Например, логгировать посылаемые в субд sql-запросы смысла нет — они и так есть в коде.
По-моему не так очевидно. В случае ORM, когда запросы строятся динамически по параметрам снаружи, интересно же, что именно там получилось. Вполне может получиться страшный запрос со страшным планом, который не уложится в таймаут потока, обрабатывающего HTTP запрос, клиент получит 500, к нам придут с вопросом. Или это относится к "приложение получает извне"?
·>Логгировать стектрейсы исключений. Имя треда. Положение в коде (т.е. по каждому сообщению в логе должна быть возможность однозначно идентифицировать строчку в коде). ·>Из лога должна быть возможность однозначно определить версию кода (git commit id какой-нибудь) и текущую конфигурацию (используемые ENV, конфиги, етс).
Здравствуйте, ·, Вы писали:
·>Из лога должна быть возможность однозначно определить версию кода (git commit id какой-нибудь) и текущую конфигурацию (используемые ENV, конфиги, етс).
А где почитать про как сделать git commit Id? Это в ресурсах сборки защивается или как?
Здравствуйте, rosencrantz, Вы писали:
R>По-моему не так очевидно. В случае ORM, когда запросы строятся динамически по параметрам снаружи, интересно же, что именно там получилось. Вполне может получиться страшный запрос со страшным планом, который не уложится в таймаут потока, обрабатывающего HTTP запрос, клиент получит 500, к нам придут с вопросом. Или это относится к "приложение получает извне"?
Извне. Значит надо логгировать в таком формате, чтобы можно было параметры куда-нибудь скопировать, отправить какую-нибудь утилиту, которая и построит, а может и выполнит, запрос.
Здравствуйте, rosencrantz, Вы писали:
R>·>С какими вопросами к тебе приходят?
R>Юзер купил подписку на продукт, должен был получить письмо, не получил. Вопросы: почему? что теперь делать? R>Юзер купил подписку на продукт, выслали ему временный пароль. Юзер пытается зайти, пароль не подходит. Вопросы: почему? что теперь делать? R>Юзер тыкнул кнопку в приложении, ничего не произошло. Вопросы: почему? что теперь делать?
Ну вот ровно эти проблемы сервисы телеметрии типа appinsights и решают.
Посмотри видео обучающее какое что ли, не изобретай велостпед.
Разберись как работает и прикрути к своему приложению
Такие сервисы могут выглядеть страшно для тебя, как "it стратегия уровня предприятия", как ты говоришь,
просто потому что ты с этим не работал. Там, как правило, все просто на самом деле,
и от разработчика требуется минимум телодвижений.
Тут нечего проектировать, индустрия уже давно превратилось в сборку из кубиков,
Все придумано и сделано до нас.
Здравствуйте, rosencrantz, Вы писали:
r> ·>Ты просто плохо задал вопрос, как будто ты ожидаешь универсальный рецепт. Ведь всё очень зависит от ситуации. Вот я и пытаюсь выудить из тебя подробности. r> Иногда неспособность читателя прочитать может выглядеть как неспособность автора написать. Мне не нужен универсальный рецепт — мне нужны ценности, которых придерживаешься конкретно ТЫ, когда принимаешь решение что логировать, что не логировать, как логировать, как не логировать. Перестань пожалуйста мне планировать IT стратегию масштаба предприятия на следующие 5 лет. Вопрос про логи. Не усложняй. Как потом интерпретировать твой ответ, я разберусь.
Ну ещё можно вспомнить про аудит-логи, перформанс-логи. Много можно наговорить, лениво же столько кнопок жать...
r> ·>С какими вопросами к тебе приходят? r> Юзер купил подписку на продукт, должен был получить письмо, не получил. Вопросы: почему? что теперь делать?
Действия пользователя должны логироваться. Отправка письма это "отправляет наружу" — т.е. логгируем когда какому юзеру, на какой емейл отправили какой тип письма. И лог "получает извне" — ответ smtp-сервера.
r> Юзер купил подписку на продукт, выслали ему временный пароль. Юзер пытается зайти, пароль не подходит. Вопросы: почему? что теперь делать?
Пароли логировать нельзя, но можно логировать солёный хеш отправленного юзеру пароля и тот который он пытается ввести. Т.е. можно будет хотя бы проверить — вводил ли он тот же пароль или ошибался.
r> Юзер тыкнул кнопку в приложении, ничего не произошло. Вопросы: почему? что теперь делать?
В веб-приложении? С этим плохо — это же событие в браузере? js сломался? Вроде можно ловить все ошибки происходящие в браузере и слать репорты в бэкенд...
r> ·>Надо логгировать всё что приложение получает извне и отправляет наружу. r> ·>Если объёмы данных огромны — надо думать как сократить. r> ·>не логгировать sensitive информацию (пароли/ключи/етс). r> ·>Идеально, если по логам ты можешь воспроизвести проблему локально. r> Это отличный критерий, не очень понятно только, как в практику это перевести. В голову приходит например: для каждого ветвления говорить почему получилось true/false, и по какой ветке в итоге пошли.
Нет, конечно. Пришел запрос, залогировали. И теперь если в юнит-тест вписать этот же запрос, выцепленный из лога, то код пойдёт по тем же ветвлениям — под дебагом локально посмотришь. Для этого и нужно знать точную версию кода/конфигов/етс.
Детерминизм и повторяемость — это цель, это счастье.
r> ·>Не имеет смысл логгировать то, что и так ясно из кода. Например, логгировать посылаемые в субд sql-запросы смысла нет — они и так есть в коде. r> По-моему не так очевидно. В случае ORM, когда запросы строятся динамически по параметрам снаружи, интересно же, что именно там получилось. Вполне может получиться страшный запрос со страшным планом, который не уложится в таймаут потока, обрабатывающего HTTP запрос, клиент получит 500, к нам придут с вопросом. Или это относится к "приложение получает извне"?
Параметры снаружи зависят от того, что приложение "получает извне" — значит это ты сможешь воспроизвести локально и увидеть что там нагенерилось.
Здравствуйте, Sharov, Вы писали:
S> ·>Из лога должна быть возможность однозначно определить версию кода (git commit id какой-нибудь) и текущую конфигурацию (используемые ENV, конфиги, етс). S> А где почитать про как сделать git commit Id? Это в ресурсах сборки защивается или как?
Это обычно зависит от языка и системы сборки. Не знаю про шарп, в мавене — плагин, генерит данные в MANIFEST.MF или .properties, и система логгирования подхватывает.
Здравствуйте, vsb, Вы писали:
vsb>А вообще говорят, что умные люди сейчас всякие хитрые системы по сбору логов применяют. Мне это не применимо, но в целом, наверное, все эти файлы и уровни это прошлый век, с этой бигдатой всё проще должно быть. Логгируй всё от начала до конца, включай там все эти аспектные логгирования, а оно пусть само разбирается, что куда сохранять, процессора много, диски толстые.
Сижу сейчас и пишу спеку о том, как от этой биг даты избавится. Файлы рулят, потому что дешево, надежно и сердито. А с биг датой логи в проекте жрут чуть ли не 40% стоимости всех ресурсов. То есть сотни тысяч долларов в год тратятся чтобы их хранить и запрашивать, в среднем, 3 раза в минуту. Все эти свистоперделки стоят очень дорого, тяжелы в поддержке и глючат, особенно когда в инвертированный индекс (Elastic) запихивают time series данные (логи) в количестве много теребайт в год. Кто до этого додумался и почему ELK популярен я ума не приложу.
Здравствуйте, gusilebedi, Вы писали:
g> Сижу сейчас и пишу спеку о том, как от этой биг даты избавится. Файлы рулят, потому что дешево, надежно и сердито.
Зависит от. Крутится у тебя несколько сот серверов разбрасывается по кластеру как попало... И что с тысячами файлов делать, раскиданных по сотне хостов?
Терабайты логов — да, фигня. Всё равно в них ничего не найти.
Здравствуйте, gusilebedi, Вы писали:
G>Здравствуйте, vsb, Вы писали:
vsb>>А вообще говорят, что умные люди сейчас всякие хитрые системы по сбору логов применяют. Мне это не применимо, но в целом, наверное, все эти файлы и уровни это прошлый век, с этой бигдатой всё проще должно быть. Логгируй всё от начала до конца, включай там все эти аспектные логгирования, а оно пусть само разбирается, что куда сохранять, процессора много, диски толстые.
G>Сижу сейчас и пишу спеку о том, как от этой биг даты избавится. Файлы рулят, потому что дешево, надежно и сердито. А с биг датой логи в проекте жрут чуть ли не 40% стоимости всех ресурсов. То есть сотни тысяч долларов в год тратятся чтобы их хранить и запрашивать, в среднем, 3 раза в минуту. Все эти свистоперделки стоят очень дорого, тяжелы в поддержке и глючат, особенно когда в инвертированный индекс (Elastic) запихивают time series данные (логи) в количестве много теребайт в год. Кто до этого додумался и почему ELK популярен я ума не приложу.
Делали хипстерский серверлес проект — цепочка из десятка AWS Lambda обрабатывает сообщения. Ключевое слово "цепочка из десятка". Разрабатывать это локально довольно неудобно, потому что локально целую систему не поднимешь. Поэтому построили механизм деплоймента, который позволяют любому девелоперу по желанию за 15 минут поднять в AWS свой энвайронмент из своего бранча и делать там всё что хочешь. Вот в ELK у нас были все логи со всех энвайронментов, и это позволяло написать что-то типа: "environment=bobby5 and eventId=12312312323" и посмотреть как ивент шёл через весь этот десяток лямбд на конкретном энвайронменте. Как это делать без ELK (или его аналогов) я не представляю.
Здравствуйте, rosencrantz, Вы писали:
R> Что, как, и в каком объёме вы стали бы логировать? Поделитесь стратегией
Следует использовать некоторое решение, например, NLog (для .NET). У него есть уровни логгирования, которые задаются в конфигах. Пришли к тебе с вопросом, посмотрел лог — не понял, понизил уровень, еще посмотрел, ну и так далее. Когда разобрался, вернул прежний уровень.
спасибо.
