Однако необычно видеть видео по logging и не слышать ничего про конфигурацию через словарь или файл, ничего про хендлеры и взаимоотношения внутри, даже ничего про ротации, а ведь кажется, что именно это все так раздражает людей в библиотеке, поэтому и пользуют разные loguru. Я так понимаю, причина в подходе, что из потока необходимое будет хватать уже другая программа, но словно стоило немного про это поговорить. Тем не менее, спасибо, было интересно и ты очень круто доносишь информацию.
Пожалуйста! В этом видео самая основа. Прям основы основ. Говорить про более сложные вещи, которые вы перечисляете, просто рано и неуместно. И так ролик большой получился. Логуру фуфло, не нужно его использовать. Кроме симпатичного вывода и более широкого трейсбека ничего интересного там нет. Пожалуйста!
Привет, спасибо за качественный материал :3 Будет ли продолжение? Хотелось бы узнать как можно логировать или перехватывать логи из других фреймворков, библиотек и, например, отсылать их в брокер или куда-то еще, либо инструменты которые позволяют это делать. Так же, было бы круто узнать о других инструментах для логгирования, по типу structlog
Привет, пожалуйста! Продолжение может быть и будет, но не в ближайшее время. Перехватывать логи чтобы что? Они же обычно точно также пишутся. Или у вас какая-то другая задача? Продвинуть тему видео вперед можно через бусти 🙂
@@popcorn_833 привет! Пожалуйста! Ротацию логов нужно делать не на уровне приложения, логи необходимо писать в stdout / stderr А дальше супервизор собирает и ротирует логи, будь то Docker, systemd, или что-то ещё. Это не ответственность приложения, хоть и действительно в питоне можно сделать ротацию логов. Но мы этим не занимаемся
@@SurenKhorenyan уточнение про ротацию логов супервизором кажется для меня даже более ценным чем всё видео). как же я намучался в свое время с ротированием внутри приложения и не догадался просто выводить в stdout и читать journalctl
Спасибо, логирование это нелюбимая тема, но знать и использовать все равно нужно, можно видео по работе с датами? И по работе с файлами pathlib к пррмеру.
Как понять философию вывода error и warning, это надо заранее знать что это ошибка получается? Но ее надо исправлять, а не выводить info и debug понятно вроде, info временно выключаем, debug используем, зачем остальные не могу понять
Зависит от ситуации. Эти уровни тоже применимы и довольно часто. Иногда нельзя точно предсказать ситуацию более узко, чем "что-то пошло не так, вот детали:"
подскажите, когда я пытаюсь повторить пример с %s и передавать параметры в аргументы, то у меня записывает в лог %s, а не полученное значение из аргументов
Было бы круто увидеть, как применяется логирование в fastapi проекте. Не совсем понятно, что и как нужно правильно логировать (каждую ли апи или только те, которые важны).
в реальных проектах реализация логов такая же? я думал, что логи реализуются через декораторы (wrapperы) и сохраняются в специальные файлы, а не выводятся в консоль
@@forceloop1789 логи надо писать в stdout (как показано, в консоль), чтобы не тормозить программу работой с диском. А уже оттуда будет другая программа читать всё написанное и сохранять куда надо. Декораторы тут вообще не играют роли
@@efibutov если у вас есть реальные примеры, то давайте обсуждать, можете показать в чате в телеграм. Если делать логи как я показал в ролике, замедления не будет точно. Все логи надо выводить в stdout / stderr
@@SurenKhorenyan Согласен, если в СТД, проблем быть не должно (конечно,м предполагаем, что речь идёт не о CPU-bound аппликации). Однако если есть логгер, который пробрасывает логи, скажем, в эластик, то послать данные по сетке может занимать время, если это синхронные запросы
@@SurenKhorenyan Ну сейчас реально могут на собесе даже на джуна спросить немного про C. Конечно если не знаешь тебя врядтли сбросят, но плюсик будет не плохой. Да и в целом полезные знания, для понимания программирования в целом.
@@SurenKhorenyan info - это не дебаг уровень. Допустим на проде нам нужно знать, когда залогинился или разлогинился пользователь (думаю, что с этим Вы согласны). Так это ну никак не Варнинг и не Дебаг. Вполне себе обычный Инфо.
Если нас волнует событие входа / выхода пользователя, мы это пишем в базу данных, можно в тот же кликхаус. Никак не в логи. Логи нужны для отладки, когда мы уже поняли, что нам надо разобраться в последовательности событий
@@SurenKhorenyan логи нужны и для разбора ситуаций на продакшене. Или у Вас идеальный код и не может возникнуть ошибки в проде? Конечно, ситуации бывают разные, но когда в проде сразу по логу понятно что произошло - это жирный плюс. Поэтому крайне не согласен с Вами на счёт типа Info
Как будто бы не работает оптимизация % форматирования... Ниже выводим только уровень INFO, но общее время всё-равно 4 секунды (вместо ожидаемых 3 секунд). Почему - не понятно. start_time = time.time() logging.debug("Result: %d", complex_function()) logging.info("Result: %d", complex_function()) logging.debug("Result: {}".format(complex_function())) logging.debug(f"Result: {complex_function()}") end_time = time.time() total_time = end_time - start_time print(f"Total execution time: {total_time:.2f} seconds") ======== # python src/time_tester.py 2024-08-30 15:15:28,872 - Result: 42 Total execution time: 4.01 seconds
@@sergeipopov привет Я в ролике показывал проверку isEnabledFor. Для подобных ситуаций нужно делать под флагом обязательно, если какую-то долгую функцию только для лога дёргаете
Это просто кладезь знаний! Спасибо огромное тебе, Сурен!
Пожалуйста! Очень приятно 🥰
Только начал читать статью на Хабре за логи, так тут видос от Сурена. Кайф!
@@podjigalgoroda6523 крутяк!
Как всегда изложено чётко и грамотно.
Спасибо ☺️
Однако необычно видеть видео по logging и не слышать ничего про конфигурацию через словарь или файл, ничего про хендлеры и взаимоотношения внутри, даже ничего про ротации, а ведь кажется, что именно это все так раздражает людей в библиотеке, поэтому и пользуют разные loguru. Я так понимаю, причина в подходе, что из потока необходимое будет хватать уже другая программа, но словно стоило немного про это поговорить. Тем не менее, спасибо, было интересно и ты очень круто доносишь информацию.
Пожалуйста!
В этом видео самая основа. Прям основы основ. Говорить про более сложные вещи, которые вы перечисляете, просто рано и неуместно. И так ролик большой получился. Логуру фуфло, не нужно его использовать. Кроме симпатичного вывода и более широкого трейсбека ничего интересного там нет.
Пожалуйста!
Спасибо за видео!
Пожалуйста!
Привет! Спасибо за видос 🔥
@@ivanalexandrovsky1909 привет! Пожалуйста ☺️
Спасибо, очень интересно. Было бы еще интересно услышать сравнение со страктлог и логуру
Пожалуйста! Не использую ни то ни другое, так как и без них всё ок. Максимум это JSON formatter для вывода в JSON
Привет, спасибо за качественный материал :3 Будет ли продолжение? Хотелось бы узнать как можно логировать или перехватывать логи из других фреймворков, библиотек и, например, отсылать их в брокер или куда-то еще, либо инструменты которые позволяют это делать. Так же, было бы круто узнать о других инструментах для логгирования, по типу structlog
Привет, пожалуйста!
Продолжение может быть и будет, но не в ближайшее время.
Перехватывать логи чтобы что? Они же обычно точно также пишутся. Или у вас какая-то другая задача?
Продвинуть тему видео вперед можно через бусти 🙂
Подскажите, как называется эта тема для кода. Не могу понять по расцветке, но очень нравится..
@@itsrealshafardenis это One Dark
@@SurenKhorenyan большое спасибо
@@itsrealshafardenis пожалуйста! 🥰
Привет! Спасибо за материал! Нужно было добавить как записывать их в файлы, по времени, размеру и т.д.
@@popcorn_833 привет! Пожалуйста!
Ротацию логов нужно делать не на уровне приложения, логи необходимо писать в stdout / stderr
А дальше супервизор собирает и ротирует логи, будь то Docker, systemd, или что-то ещё.
Это не ответственность приложения, хоть и действительно в питоне можно сделать ротацию логов. Но мы этим не занимаемся
@@SurenKhorenyan а не расскажешь про ELK, ротацию логов и вот это всё? Думаю многим будет полезно
@@SurenKhorenyan уточнение про ротацию логов супервизором кажется для меня даже более ценным чем всё видео). как же я намучался в свое время с ротированием внутри приложения и не догадался просто выводить в stdout и читать journalctl
@@zion4d ого. Ну, видимо, надо будет про это тоже рассказать 😅
@@bocik2854 когда-нибудь расскажу, но, наверное, не скоро. Ускорить можно через бусти 🙂
Спасибо, логирование это нелюбимая тема, но знать и использовать все равно нужно, можно видео по работе с датами? И по работе с файлами pathlib к пррмеру.
Пожалуйста!
А с датами что?
Вообще, заказ темы проходит через бусти
Как понять философию вывода error и warning, это надо заранее знать что это ошибка получается? Но ее надо исправлять, а не выводить
info и debug понятно вроде, info временно выключаем, debug используем, зачем остальные не могу понять
Зависит от ситуации. Эти уровни тоже применимы и довольно часто.
Иногда нельзя точно предсказать ситуацию более узко, чем "что-то пошло не так, вот детали:"
подскажите, когда я пытаюсь повторить пример с %s и передавать параметры в аргументы, то у меня записывает в лог %s, а не полученное значение из аргументов
А аргументы вы точно передали? Показывайте код. В чате в телеграм быстрее подскажем
@@SurenKhorenyan кинул скрин в чат
Спасибо за видос! Как называется твоя тема в pycharm?
@@bocik2854 пожалуйста!
Это One Dark
@@SurenKhorenyan спс🙂
@@bocik2854 🤝
Было бы круто увидеть, как применяется логирование в fastapi проекте. Не совсем понятно, что и как нужно правильно логировать (каждую ли апи или только те, которые важны).
@@никитакорж-ю7э логирование там применяется точно также. Логировать нужно только то, что вам важно увидеть при чтении логов
в реальных проектах реализация логов такая же? я думал, что логи реализуются через декораторы (wrapperы) и сохраняются в специальные файлы, а не выводятся в консоль
@@forceloop1789 логи надо писать в stdout (как показано, в консоль), чтобы не тормозить программу работой с диском. А уже оттуда будет другая программа читать всё написанное и сохранять куда надо.
Декораторы тут вообще не играют роли
@@SurenKhorenyan понял, спасибо за быстрый ответ, ты профи
@@forceloop1789 пожалуйста 🥰
@@SurenKhorenyan было бы ешё интересно и полезно услышать от тебя, как реализуются метрики в fastapi. Через Grafana или Prometheus, или как вообще ?
Всё зависит от того, кто принимает решения. Можно прометеус, можно складывать в кликхаус, а отображать в графане
спасибо ❤
@@vasopython1547 пожалуйста 🥰
Не успел досмотреть до конца, поэтому, возможно, вопрос лишний: насколько логгирование замедляет работу приложения, и как устранить подобную проблему?
@@efibutov ни насколько. Вообще, преждевременная оптимизация это вредное занятие, не тратьте на него время
@@SurenKhorenyan я о том, что если логгер типа кибаны, то это медленный IO, и, возможно, это будет тормозить ...
@@efibutov если у вас есть реальные примеры, то давайте обсуждать, можете показать в чате в телеграм.
Если делать логи как я показал в ролике, замедления не будет точно. Все логи надо выводить в stdout / stderr
@@SurenKhorenyan Согласен, если в СТД, проблем быть не должно (конечно,м предполагаем, что речь идёт не о CPU-bound аппликации). Однако если есть логгер, который пробрасывает логи, скажем, в эластик, то послать данные по сетке может занимать время, если это синхронные запросы
@@SurenKhorenyan Просто я подумал, что если на каждый чих будет что-то слаться по сетке в логгер, то аппликация может замедлиться
Форматирование из C. В целом думаю это многие и так знают.
@@dmitry-lz1ny немногие знают, из чего сделан питон 🙂
@@SurenKhorenyan Ну сейчас реально могут на собесе даже на джуна спросить немного про C.
Конечно если не знаешь тебя врядтли сбросят, но плюсик будет не плохой.
Да и в целом полезные знания, для понимания программирования в целом.
@@dmitry-lz1ny могут.. да, вы правы, знания точно будут не лишними
Уровень info для отладки? Что то какой то неправильный мед.
@@Kampogolik всё так. На debug уровне слишком много всего сыпет в логи.
На проде всё равно должно быть от WARNING и выше
@@SurenKhorenyan info - это не дебаг уровень. Допустим на проде нам нужно знать, когда залогинился или разлогинился пользователь (думаю, что с этим Вы согласны). Так это ну никак не Варнинг и не Дебаг. Вполне себе обычный Инфо.
Если нас волнует событие входа / выхода пользователя, мы это пишем в базу данных, можно в тот же кликхаус. Никак не в логи. Логи нужны для отладки, когда мы уже поняли, что нам надо разобраться в последовательности событий
@@SurenKhorenyan логи нужны и для разбора ситуаций на продакшене. Или у Вас идеальный код и не может возникнуть ошибки в проде? Конечно, ситуации бывают разные, но когда в проде сразу по логу понятно что произошло - это жирный плюс. Поэтому крайне не согласен с Вами на счёт типа Info
@@Kampogolik на продакшн логи от уровня Warning и выше. Инфо вы всё равно не увидите.
Как будто бы не работает оптимизация % форматирования... Ниже выводим только уровень INFO, но общее время всё-равно 4 секунды (вместо ожидаемых 3 секунд). Почему - не понятно.
start_time = time.time()
logging.debug("Result: %d", complex_function())
logging.info("Result: %d", complex_function())
logging.debug("Result: {}".format(complex_function()))
logging.debug(f"Result: {complex_function()}")
end_time = time.time()
total_time = end_time - start_time
print(f"Total execution time: {total_time:.2f} seconds")
========
# python src/time_tester.py
2024-08-30 15:15:28,872 - Result: 42
Total execution time: 4.01 seconds
@@sergeipopov привет
Я в ролике показывал проверку isEnabledFor. Для подобных ситуаций нужно делать под флагом обязательно, если какую-то долгую функцию только для лога дёргаете