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

Что такое логирование ошибок и зачем оно нужно

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

Правильное логирование ошибок не только помогает быстро находить и фиксить баги, но и служит мониторингом здоровья приложения — по логам можно заметить нарастающие ошибки, что-то странное с производительностью, попытки неправильных вызовов и многое другое. В больших или сложных приложениях без продуманного логирования попасть на причину проблем — это часто долгое и мучительное дело. Даже в небольших проектах лог может резко сэкономить время, если что-то ломается «в бою».

Основные настройки логирования ошибок в PHP

Всё начинается с php.ini — именно там задаются главные параметры для ошибок. Вот базовые моменты, которые стоит учесть:

- display_errors — показывает ли PHP ошибки на экран. Для разработки удобно ставить On, но на продакшене точка должна быть в Off.

- log_errors — включает логирование ошибок, без этого ошибки не попадут в файл вообще.

- error_log — путь к файлу, куда будут записываться сообщения об ошибках. Обычно это /var/log/php_errors.log на Linux или отдельный файл в папке логов вашего проекта. Важно убедиться, что PHP имеет права на запись туда.

- error_reporting — уровень ошибок, которые будут регистрироваться. Лучше ставить максимально полный (E_ALL), чтобы ничего не пропускать.

Пример базовой настройки в php.ini для продакшена:

display_errors = Off
log_errors = On
error_log = /var/log/php_errors.log
error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT

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

Что делать в коде, чтобы дополнительно контролировать ошибки?

Иногда нужно на лету менять настройки — например, для локальной отладки или чтобы ловить более подробные данные. Для этого есть функции ini_set и error_reporting прямо в скрипте:

ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL);

Это удобно для тестов или небольших проектов, но не забывайте выключать потом! Для больших проектов лучше настраивать через конфиги и использовать системы логирования.

Кастомные обработчики ошибок и исключений

PHP позволяет определять свои функции - обработчики ошибок и исключений с помощью set_error_handler и set_exception_handler. На практике это круто, потому что так можно объединить разнородные ошибки в единый формат и отправлять их в более удобные места: JSON-файлы, базы данных, syslog или в инструменты типа Sentry.

Пример обработчика ошибок, который логирует их в JSON-файл:

function myErrorHandler($errno, $errstr, $errfile, $errline) {
$errorData = [
'type' => $errno,
'message' => $errstr,
'file' => $errfile,
'line' => $errline,
'time' => date('Y-m-d H:i:s')
];
file_put_contents('/path/to/error_log.json', json_encode($errorData) . PHP_EOL, FILE_APPEND);
return false; // чтобы стандартная обработка тоже сработала
}

set_error_handler('myErrorHandler');

Такой подход даёт больше контроля, но требует аккуратности и продуманности.

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

- [ ] display_errors = Off на продакшене
- [ ] log_errors = On
- [ ] error_log прописан и доступен для записи
- [ ] error_reporting включает все нужны уровни ошибок (обычно E_ALL)
- [ ] Проверить права на директорию и файл лога
- [ ] Регулярно проверять размер логов и ротацию (logrotate или аналог)
- [ ] Настроить кастомный обработчик ошибок при необходимости
- [ ] Для локалки можно временно включить display_errors = On и error_reporting = E_ALL
- [ ] Использовать сторонние библиотеки (Monolog) или сервисы мониторинга для сложных проектов

Типичные ошибки при настройке логов в PHP

1. Оставлять display_errors включённым на продакшене — клиенты видят внутренние ошибки, а это может привести к утечке информации или испортить UX.

2. Error_log указывает на путь, куда PHP не имеет доступа на запись — ошибки просто не появляются ни в браузере, ни в логе, и понять, что не так, сложно.

3. Недостаточный уровень error_reporting — например, ловить только фатальные ошибки (E_ERROR), а предупреждения (E_WARNING, E_NOTICE) игнорировать. А зачастую именно предупреждения показывают на потенциальные проблемы.

4. Игнорирование логов — когда логи есть, но никто их не смотрит: файлы накапливаются, занимают место, а проблемы остаются незамеченными.

5. Логи растут без ограничения — важно настроить ротацию лог-файлов, чтобы они не переполнили диск.

6. Отсутствие контроля формата и структуры логов — полезно иметь удобно читаемый или парсируемый формат, чтобы быстро искать и анализировать ошибки.

Практические примеры

1. Включаем вывод ошибок и логируем их в файл (например, для локальной разработки):

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

2. Настройка Monolog с записью в файл и в syslog (пример упрощённый):

use Monolog\Logger;
use Monolog\Handler\StreamHandler;
use Monolog\Handler\SyslogHandler;

$log = new Logger('my_app');
$log->pushHandler(new StreamHandler(__DIR__.'/app.log', Logger::ERROR));
$log->pushHandler(new SyslogHandler('php_app'));

// Логируем ошибку
$log->error('Произошла ошибка', ['code' => 123]);

3. Отлавливаем непойманные исключения:

set_exception_handler(function($e) {
error_log("Uncaught exception: " . $e->getMessage());
// Можно добавить сюда уведомления или запись в БД
});

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

— Почему ошибки не пишутся в лог, хотя я всё вроде настроил?
Проверьте права на файл error_log и его директорию. Убедитесь, что PHP-процесс имеет права на запись. Посмотрите, нет ли конфликтных настроек error_reporting, может вы исключаете нужные уровни ошибок? Также иногда влияет настройка SAPI и окружения.

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

— Как отключить показ ошибок пользователю, но при этом видеть их в логе?
display_errors нужно ставить в Off, log_errors включать, а error_reporting выставлять на максимальный уровень. Тогда ошибки не будут лезть в браузер, но будут сохраняться в логи.

— Что лучше — использовать штатный error_log или Monolog (или другую библиотеку)?
Для простых проектов часто хватает стандартного логирования error_log. Если нужен мультиканальный сбор логов, разные форматы, ротация, фильтрация и интеграция с внешними сервисами — тогда лучше Monolog или аналоги.

— Как правильно проверять, что логирование работает?
Простейший тест — вызвать в скрипте намеренно ошибку, например, вызов несуществующей функции: no_such_function(). Если после этого ничего не появилось в логе, значит либо ошибка не логируется, либо неправильно настроен путь, либо проблемы с правами.

— Нужно ли логировать предупреждения (E_WARNING) и уведомления (E_NOTICE)?
Да, лучше включать их, особенно на этапе разработки и тестирования. Предупреждения часто становятся причиной более серьёзных проблем в будущем. На продакшене можно фильтровать некоторые типы ошибок, но не стоит полностью их игнорировать.

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

- tail -f — для просмотра логов в реальном времени в терминале (Linux/Mac). Живой мониторинг очень удобен.

- logrotate — системный инструмент для ротации логов, чтобы не накапливались вечно и не загораживали место на диске.

- Xdebug — расширение для дебага PHP, даёт подробные стеки вызовов, переменные и другое, отлично сочетается с логированием ошибок.

- Monolog — библиотека для комплексного логирования в PHP, умеет писать во множество каналов, поддерживает фильтры, форматирование.

- Сервисы вроде Sentry, Bugsnag — для сбора и анализа ошибок из боевых проектов с удобной аналитикой.

Заключение

Логирование ошибок — это простой, но важный инструмент в арсенале любого PHP-разработчика. С его помощью можно быстро находить баги, контролировать состояние приложений и не терять время на поиск непойманных ошибок. Главное — понять, что это не просто кнопка в php.ini, а часть общей стратегии поддержки и мониторинга проекта. А вы как настраиваете логирование? Какие ещё инструменты используете? Где ловите самые странные баги? Пишите, делитесь опытом.