console.log или var_dump — это не инструменты логирования, а помощники для рантайм-отладки. Это диагностическое оборудование, которое вы подключаете к машине в сервисе, чтобы посмотреть показатели здесь и сейчас. Но как только код улетает в продакшн, вам нужен не сканер, а черный ящик самолета. Вам не важно, что происходит в моменте, когда все работает; вам важно восстановить цепочку событий, когда все упало.
Логирование — это проектирование истории системы.
Инженер должен разложить логи так, чтобы в любой момент ответить на вопросы: почему функция выдала именно этот результат, какой путь прошел запрос и почему юзер получил 500-ю ошибку вместо данных.
Главная опасность — логирование без контекста. Пока вы единственный пользователь на локалке, запись «User logged in» выглядит информативно. На продакшене, где тысячи людей одновременно дергают API, такие сообщения превращаются в бессвязную кучу мусора. Вы видите событие, но не видите связи.
Чтобы не гадать на кофейной гуще, в каждый лог в пределах одного пути запроса подмешивается уникальный ID реквеста. Один запрос — один идентификатор. Только так можно отфильтровать гигабайты логов и получить чистую последовательность действий конкретного пользователя. Это превращает хаотичный поток текста в структурированный сценарий, который уже можно анализировать.
При этом логирование — это не слепое записывание всего подряд. Подкапотка приложения не должна хранить чувствительные(Sensitive) данные. Персональная информация, номера карт, пароли — это табу. Эти данные никак не помогают понять логику сбоя, но превращают ваши логи в мину замедленного действия на случай утечки.
Лог должен объяснять механику системы, а не сливать данные клиентов. Если для понимания ошибки вам нужен номер карты пользователя в логах — значит, у вас проблемы с архитектурой, а не с дебагом.
Ставь 🔥, если когда-нибудь пытался найти нужную строку в десятиметровом текстовом логе без фильтрации.
Пиши в коментах если что-то всё ещё звучит запутанно — я обязательно отвечу 😉
10МДК