🐘 Совет #2: Логируй то, что надо! — 19 марта 2026 г. в 16:04:51.610
🐘 Совет #2: Логируй то, что надо! Привет! На связи Бурый. Заходил когда-нибудь в логи и тонул? Листаешь мегабайты текста, а в итоге — ничего не понял. Знакомо? Логов много не бывает. Бывает много бесполезных логов. Если ты логируешь всё подряд - ты не логируешь ничего. В критический момент ты просто утонешь в простыне текста, пока прод горит. ✋ Что реально нужно логировать? Одна запись на один клиентский запрос. Одна запись на выполнение cli скрипта. Которая отвечает на главный вопрос: Как прошел процесс? Успех или ошибка? 🎯 Вот мой идеальный лог: { "datetime": "2025-03-19 10:23:15.123" "status": "error", "reason": "Database connection timeout", "script": "cron/parse-orders.php", } { "datetime": "2025-03-19 10:24:11.123" "status": "success", "reason": "", "script": "cron/parse-orders.php", "final_time": 0.123, "rows": 1002, } Почему это работает: ✅ status - сразу видно, всё ок или нет. Можно мониторить и дёргать команду только на "error". ✅ reason - ёмко объясняет, что пошло не так. Не нужно парсить stack trace, чтобы понять, что упала база. ✅ контекст - можно дополнить параметрами вызова, pid процесса и др, все то что поможет идентифицировать запрос или итерацию вызова скрипта. Что не надо логировать: ❌ Каждую итерацию цикла ❌ "Начал делать то-то" - если без этого можно понять результат ❌ Дампы огромных массивов ❌ Стек-трейсы на каждое предупреждение 🎯 Мой подход: + На каждый запрос/скрипт - одна итоговая запись. + Если ошибка - пишу reason так, чтобы сразу было понятно, куда смотреть. + Для отладки включаю подробные логи локально, на проде - только суть. Помни: логи ты пишешь не для процесса, а для ответа на вопрос "Что случилось?" в 3 часа ночи, когда прод лёг. — 👇 А у вас в проекте можно по логам быстро понять проблему? 👉 Подписывайтесь на PHP: Бурый - дальше будет еще больше живых советов из практики!