Логирование ошибок в PHP — это реально одна из тех вещей, которые либо правильно настраиваешь с самого начала, либо потом мучаешься, пытаясь понять, где что сломалось, особенно если проект уже запущен и на боевом сервере. Хочу поделиться, как я обычно выстраиваю эту систему, чтобы всегда знать, что происходит с кодом, и не натыкаться на пустые экраны или непонятные сбои.

Что такое логирование ошибок и зачем оно нужно
Логирование ошибок — это когда PHP записывает все возникающие проблемы (ошибки, предупреждения, сообщения об уведомлениях) в отдельный файл или выводит на экран. Без логов проще всего заблудиться, если вдруг что-то не работает, особенно если в продакшне ошибки отключены от вывода и ничего не отображается пользователю. То есть по сути, логи — это дневник работы твоего скрипта, куда записываются все сбои. Это не просто "ненужные строчки" — это ключ к быстрому решению проблем.

Где уместно использовать логирование
На продакшене, конечно, лучше ошибки не показывать пользователям — мало ли, что злые дяди могут выцепить. Вместо этого логируется всё в файл. В среде разработки и тестирования удобно видеть ошибки сразу, поэтому display_errors обычно включают, но даже тут иногда полезно выделять логи для более детального мониторинга — особенно когда работаешь с AJAX запросами, API, или взаимодействием с базой. Если ошибка где-то в ответе API, то сразу в браузере её не увидишь, но сможешь изучить по логам.

Практическая настройка через php.ini
Если есть доступ к конфигу PHP, то настройка самая базовая и стабильная:

error_reporting = E_ALL
display_errors = Off
log_errors = On
error_log = /var/log/php/php-error.log

Здесь:
- error_reporting = E_ALL — ловим все ошибки, предупреждения и уведомления
- display_errors = Off — чтобы ошибки не показывались пользователю на продакшне
- log_errors = On — включаем запись в лог
- error_log — указываем путь к файлу, где будут храниться ошибки

Если доступа к php.ini нет (что часто бывает на shared-хостингах), то можно подправить настройки в самом коде:

ini_set('display_errors', 0);
ini_set('log_errors', 1);
ini_set('error_log', __DIR__ . '/logs/php-error.log');
error_reporting(E_ALL);

Такой вариант удобен в проектах с ограничениями на уровне сервера и позволяет быстро протестировать логирование.

Дополнительно: если проект большой и ошибок много, лучше подключить какие-то более продвинутые логгеры. Часто используется Monolog — он умеет писать в разные источники, фильтровать ошибки по уровню, форматировать вывод, отправлять уведомления и даже интегрироваться с сервисами типа Slack или Sentry. Но для простых задач достаточно и стандартного PHP-логирования.

Примеры расширенного логирования с использованием set_error_handler
Если хочется кастомизировать обработку ошибок — например, добавить в лог больше данных (время, URL, текущий пользователь), можно написать собственный обработчик:

function myErrorHandler($errno, $errstr, $errfile, $errline) {
$logEntry = "[" . date('Y-m-d H:i:s') . "] Error: $errstr in $errfile on line $errline\n";
error_log($logEntry, 3, __DIR__ . '/logs/custom-errors.log');
/* Можно добавить ещё действия: отправлять письма, уведомления и т.д. */
return true; // чтобы не вызывать стандартный обработчик
}
set_error_handler("myErrorHandler");

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

Чек-лист правильного логирования ошибок в PHP

- Убедиться, что error_reporting выставлен на E_ALL — ловим все ошибки.
- Выключить display_errors на продакшене — не светить внутренности пользователю.
- Включить log_errors, чтобы ошибки писались в файл.
- Убедиться, что error_log указывает на корректный путь и что у PHP есть права на запись туда.
- Настроить ротацию логов (logrotate или аналог) — чтобы файл не разросся до гигабайтов.
- Не хранить логи в публичных директориях сайта — лучше за пределами корня или в закрытых папках.
- При необходимости использовать более продвинутые средства (Monolog и т.п.).
- Проверить, что на локальной машине можно видеть ошибки на экране (display_errors=On), чтобы быстро отлавливать баги.

Типичные ошибки, из-за которых логирование не работает или оказывается бесполезным

- Не задан корректный путь в error_log — логи либо не пишутся, либо смещаются в системные логи, которые могут быть недоступны.
- display_errors оставлен включенным на продакшне — рискуешь "светить" внутренние данные сайта.
- error_reporting настроен неоптимально или вовсе не задан — некоторые ошибки игнорируются.
- Права на файл или директорию лога не позволяют PHP писать (часто возникает при переносах сервера).
- Логи создаются в той же папке, что и сайт, и доступны в интернете — потенциальный риск безопасности.
- Логи растут бесконтрольно, занимая весь диск — без ротации и очистки это большая проблема.
- Отсутствие орфметики по уровню логирования — пишутся все ошибки без сортировки, что затрудняет анализ.

Полезные инструменты для работы с логами PHP

- Monolog — мощный лайбрери для логирования, который облегчит управление большими проектами.
- Xdebug — отлично помогает в локальной отладке, показывает стэктрейсы, точки останова, переменные.
- tail, tail -f, multitail — классические утилиты для "живого" просмотра логов в терминале.
- PHP Debug Bar — визуальный тул для отладки прямо в браузере (полезно, если хочешь видеть логи на разработке).
- Logrotate (на Linux/Unix) — для автоматической ротации логов и архивации старых файлов.

FAQ по логированию ошибок в PHP

1. Нужно ли логировать абсолютно все ошибки?
Да, лучше ловить E_ALL, чтоб случайно не пропустить важные предупреждения или заметки, которые могут накапливаться и вызывать проблемы.

2. Можно ли хранить логи в базе данных?
Теоретически — да, но практичнее и удобнее хранить в файлах. В базе сложнее быстро просмотреть и обработать много данных. Для специфических задач можно внутри базы хранить только критические ошибки.

3. Логи пустые, хотя ошибки есть, что делать?
Проверьте, что включены log_errors и error_reporting, что правильно указан файл лога и что PHP-скрипту хватает прав на запись.

4. Как защитить логи от посторонних?
Логи должны находиться вне публичной директории сайта, максимально закрыты для доступа по HTTP. Можно использовать настройки веб-сервера (.htaccess, nginx-конфиги) для ограничения доступа.

5. Лог файлы быстро растут — как с этим справляться?
Настраивайте системные средства для ротации (напр., logrotate), либо в самом коде ограничивайте запись по уровню важности. Иногда полезно писать в разные файлы по датам.

6. Нужно ли отключать display_errors на локальной машине?
На локалке обычно включают, чтобы видеть ошибки сразу. Главное — не забывать отключать на продакшене.

7. Можно ли логировать ошибки из фреймворков и CMS?
Да, обычно они используют свои системы логирования, но можно подключить или расширить существующие механизмы, чтобы все ошибки попали в единый лог.

8. Как учитывать разницу между предупреждениями и фатальными ошибками?
Можно фильтровать уровни в error_reporting и настраивать Monolog или свои обработчики для записи ошибок разных уровней в разные места.

Выводы по опыту — лучше раз и хорошо настроить логирование с самого начала. Это сэкономит кучу нервов и времени, особенно если сайт или сервис живёт долго и постоянно развивается. Можно отдельно настраивать логи для разных сред (разработка, тест, продакшен) — там разные задачи и подходы. Важно помнить, что "невидимые" ошибки — самая частая причина непонятных сбоев.

Сам обычно делаю так: на локалке показываю все ошибки на экране, но одновременно пишу логи в файл. На продакшне оставляю только логирование с правильным error_reporting. Иногда делаю кастомный обработчик, который пишет в логи чуть больше контекста — скажем, какой URL вызвал ошибку или какой пользователь был залогинен. Вот такие мелочи здорово помогают потом разобраться, где и почему сайт упал.

А как вы настраиваете логирование в своих проектах? Есть свои фишки или проблемы, с которыми пришлось бороться?