error_log()

Логирование ошибок PHP с помощью функции Error Log

Вывод ошибок на экран через echo или var_dump() вполне подходит при разработке функциональности, но в продакшне это неверный подход: вывод виден посетителям, теряется при AJAX-запросах и исчезает сразу после завершения запроса. Встроенная функция error_log() решает эту проблему, отправляя сообщение в надёжное хранилище — файл журнала, электронную почту или системный логгер операционной системы — чтобы вы могли просмотреть его позже.

Это руководство объясняет, что делает error_log(), разбирает каждый параметр с рабочими примерами и рассматривает подводные камни (отсутствие символа новой строки, директива error_log в ini, что не следует записывать в журнал), которые возникают в реальных проектах.

Что делает функция error_log()

error_log() записывает одно сообщение в выбранное вами место. Она не запускает механизм обработки ошибок PHP, не изменяет код завершения и не останавливает скрипт — она только записывает текст. Возвращаемое значение — bool: true при успехе, false если сообщение не удалось записать (например, файл журнала недоступен для записи).

Поскольку это просто «добавить эту строку куда-то», error_log() — простейший способ оставлять следы в коде, который выполняется без наблюдения разработчика: задачи cron, обработчики очередей, вебхуки и любые продакшн-запросы.

Сигнатура функции

error_log(
    string $message,
    int $message_type = 0,
    ?string $destination = null,
    ?string $additional_headers = null
): bool

По умолчанию: запись в настроенное PHP место назначения

Наиболее распространённый вызов передаёт только сообщение и позволяет PHP направить его туда, где сервер настроен принимать ошибки (директива error_log в ini, или логгер SAPI/системы, если она не задана):

<?php

error_log("Payment gateway returned an unexpected status code");

Именно туда уже попадают неперехваченные предупреждения и уведомления, поэтому ваши сообщения окажутся рядом с собственными сообщениями PHP. Чтобы узнать текущее место назначения во время выполнения, прочитайте значение ini:

<?php

echo ini_get('error_log') ?: '(SAPI / system default)';

Запись в конкретный файл (тип 3)

Тип 3 добавляет сообщение в файл, указанный в $destination. Это основной способ ведения журналов для конкретных приложений:

<?php

$message = "Error: Unable to connect to the database";
error_log($message, 3, "/var/log/php-errors.log");

В отличие от типа 0, тип 3 записывает сообщение дословно — без временной метки, без уровня серьёзности, и что важно без символа новой строки. Если забыть о символе новой строки, все вызовы окажутся на одной строке:

<?php

$log = sys_get_temp_dir() . "/app.log";
error_log("first", 3, $log);
error_log("second", 3, $log);
echo file_get_contents($log); // firstsecond

Добавляйте PHP_EOL самостоятельно (и обычно временну́ю метку), чтобы каждая запись была читаемой строкой:

<?php

$log = sys_get_temp_dir() . "/app.log";
$line = date('[Y-m-d H:i:s] ') . "Cache miss for user 42" . PHP_EOL;
error_log($line, 3, $log);

echo file_get_contents($log);
// [2026-06-21 10:00:00] Cache miss for user 42

Все типы сообщений

Тип 2 (отправка через TCP-сокет) существовал в старых версиях PHP и был удалён в PHP 8; не следует на него полагаться.

Отправка критических ошибок по электронной почте (тип 1)

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

<?php

error_log(
    "FATAL: order processor crashed",
    1,
    "[email protected]",
    "From: [email protected]\r\n"
);

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

Реалистичный паттерн перехвата и записи в журнал

В коде приложения обычно ведут журнал внутри блока catch, записывают достаточно контекста для воспроизведения проблемы, а затем показывают пользователю обобщённое сообщение:

<?php

function chargeCustomer(int $cents): bool
{
    if ($cents <= 0) {
        throw new InvalidArgumentException("Amount must be positive, got $cents");
    }
    // ... real charge logic ...
    return true;
}

try {
    chargeCustomer(-5);
} catch (Throwable $e) {
    error_log(sprintf(
        "[%s] %s in %s:%d",
        date('Y-m-d H:i:s'),
        $e->getMessage(),
        $e->getFile(),
        $e->getLine()
    ));
    echo "Sorry, we couldn't process your payment.";
}

Подробное сообщение попадает в журнал; посетитель видит только понятную строку. В этом и состоит весь смысл error_log().

Распространённые подводные камни

• Нет символа новой строки при типе 3. Добавляйте PHP_EOL самостоятельно, иначе записи будут склеиваться.
• Директива error_log в ini задаёт место назначения по умолчанию. Если не указывать $message_type/$destination, сообщение отправится туда, куда указывает ini_get('error_log'). На свежей CLI-установке это может быть stderr; на веб-сервере — конкретный файл.
• Файл должен быть доступен для записи процессу PHP. Возврат false часто означает проблему с правами доступа к директории или файлу.
• display_errors и error_log независимы. Отключение вывода ошибок на экран не останавливает журналирование, и наоборот — управляйте ими по отдельности.
• Никогда не записывайте секреты в журнал. Пароли, ключи API, полные номера кредитных карт и токены сессий никогда не должны попадать в файл журнала. Скрывайте их перед вызовом error_log().

Связанные функции

• set_error_handler() — перенаправляйте собственные предупреждения и уведомления PHP через ваш код, чтобы последовательно вызывать error_log().
• set_exception_handler() — перехватывайте и записывайте неперехваченные исключения в одном месте.
• trigger_error() — генерируйте пользовательскую ошибку, которую подхватит обработчик ошибок (и, соответственно, журналирование).
• error_reporting() — выбирайте, какие уровни ошибок будут вообще сообщаться.
• syslog() — отправляйте сообщения напрямую в системный логгер с указанием уровня серьёзности.

Заключение

error_log() — простейший надёжный способ записывать информацию о сбоях в коде, за которым не наблюдает разработчик. Используйте тип 3 с временно́й меткой и PHP_EOL для файлов журналов приложения, тип по умолчанию — чтобы сообщения оказывались рядом с собственными ошибками PHP, а электронную почту (тип 1) резервируйте для действительно критических событий. Сочетайте error_log() с set_error_handler() и set_exception_handler(), чтобы перехватывать всё в одном месте — и никогда не записывайте секреты в журнал.

Практика