Telegram Web
​​Vitess | Шардирование для вашей PostgreSQL

Это слой между приложением и базой данных, созданный выходцами из YouTube для защиты от неэффективных запросов и масштабируемости под экстремальными нагрузками. Он также анализирует SQL-запросы на лету, отсекая потенциально опасные. Vitess — система шардирования, основа для Multigrass — проекта по адаптации для PostgreSQL внутри Supabase. Vitess стал частью их инфраструктуры, чтобы приложения могли расти до миллиардов запросов, оставаясь при этом "просто PostgreSQL".

Сайт проекта
#инструмент
@zen_of_python
Присоединяйся к хакатону года в сфере travel-tech - О!Хакатону от Островка ❤️

Островок приглашает Go и Python разработчиков, а также аналитиков и продакт-менеджеров попробовать свои силы в реальных бизнес-задачах и побороться за денежный приз.

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

Призовой фонд: 1 000 000 ₽
Регистрация открыта до 18 сентября.
Старт 26 сентября! ❤️

Подробности и регистрация

Реклама. ООО "БРОНИРОВАНИЕ ГОСТИНИЦ", ИНН 7703389880, erid: 2W5zFJuGSKr
Please open Telegram to view this post
VIEW IN TELEGRAM
logging | Эволюционируем от дебага с print()

Вместо хаотичного использования print() стоит освоить встроенный модуль logging.

Почему print() — не лучший выбор

На начальном этапе разработки многие прибегают к такому для отладки. Однако в продакшене такой подход не подходит:

print() не имеет уровней важности (debug, info, error…);
— нельзя гибко управлять выводом (в файл, консоль, внешнюю систему)
— невозможно централизованно отключить или настроить поведение.

logging решает все эти задачи и стал стандартом в профессиональной разработке.

База

Минимальный пример:


import logging

logging.basicConfig(level=logging.INFO)
logging.info("Программа запущена")


Этот код выведет в консоль строку «информирующего» уровня. Метод basicConfig задает базовые настройки — например, какой минимальный уровень логов выводить. Уровней несколько:

— DEBUG: подробная отладочная информация;
— INFO: стандартный рабочий поток;
— WARNING: потенциальные проблемы;
— ERROR: ошибки, но программа продолжает работать;
— CRITICAL: фатальные ошибки, возможно аварийное завершение.

Они позволяют фильтровать отладочные данные в зависимости от задачи.

Форматирование вывода

Полезно выводить время, уровень и контекст:


logging.basicConfig(
level=logging.INFO,
format="%(asctime)s [%(levelname)s] %(message)s"
)


Выведется нечто подобное:


2025-07-07 14:00:00,123 [INFO] Программа запущена


Запись логов в файл

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


logging.basicConfig(
level=logging.INFO,
filename='app.log',
filemode='a',
format="%(asctime)s [%(levelname)s] %(message)s"
)


Обособленные логгеры

Функция getLogger(name) позволяет создавать независимые логгеры с именем:


logger = logging.getLogger("myapp")
logger.setLevel(logging.DEBUG)
logger.debug("Отладочная информация")


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

Обработчики (Handlers)

В примере ниже все сообщения уровня DEBUG и выше пишутся в файл, а WARNING+ отображаются в консоли:


handler = logging.FileHandler("debug.log")
handler.setLevel(logging.DEBUG)

console = logging.StreamHandler()
console.setLevel(logging.WARNING)

formatter = logging.Formatter("%(asctime)s [%(levelname)s] %(message)s")
handler.setFormatter(formatter)
console.setFormatter(formatter)

logger = logging.getLogger("myapp")
logger.addHandler(handler)
logger.addHandler(console)
logger.setLevel(logging.DEBUG)


И напоследок: пишите логи в файл или систему мониторинга вроде Sentry или Grafana.
#основы
7🔥1
2025/07/09 02:34:19
Back to Top
HTML Embed Code: