Когда всё падает в 3 часа ночи, именно логи определяют, проведете Вы остаток ночи в дебаге или исправите баг за пять минут.
❗️Главный принцип: Логи — это поток (Streams)
Приложение не должно заботиться о хранении своих логов. Оно не должно писать в файлы или управлять их ротацией.
Правило простое: Ваше приложение пишет поток событий в
stdout
Всё остальное (сбор, агрегация, хранение в ELK или Grafana Loki) — задача инфраструктуры.
✅ Что ОБЯЗАТЕЛЬНО стоит писать в логи:
Контекст запроса (Trace ID / Request ID): Без сквозного ID Вы никогда не соберёте цепочку событий от входа в API до запроса в базу данных.
Таймстампы в ISO 8601: Всегда с указанием часового пояса (лучше всего — UTC).
Уровни логирования (Levels):
ERROR — когда что-то реально сломалось и требует внимания.
WARN — подозрительное поведение, которое не привело к падению.
INFO — ключевые бизнес-события (заказ оплачен, пользователь создан).
Структурированные данные (JSON): Забудьте про обычный текст. Логи в формате JSON позволяют мгновенно фильтровать события по полям user_id, status_code или latency.
❌Чего НЕ ДОЛЖНО быть в Ваших логах:
Персональные данные (PII): Пароли, токены, номера карт или личные телефоны. Это не только вопрос безопасности, но и прямой путь к нарушению GDPR и других законов.
Бесполезный шум: Логировать каждый «чих» цикла или вход в каждый метод на уровне INFO — значит превратить поиск ошибки в попытку найти иголку в стоге сена.
Объекты целиком: Никогда не кидайте в лог весь объект из БД. Логируйте только необходимые ID и изменившиеся поля.
📝Минимальный чек-лист для команды:
🔸Приложение пишет в stdout в формате JSON.
🔸В каждом логе есть trace_id.
🔸Ошибки пишутся с коротким stack trace, а не просто фразой «что-то пошло не так».
🔸Логи не содержат секретов и чувствительных данных.
Помните: Хорошее логирование — это когда Вы можете восстановить картину инцидента, не заглядывая в код.