Логирование в Symfony с помощью пакета Monolog.

Сразу после установки фремворка Symfony 5 , в нем уже поставляется возможность минималистского логирования PSR-3: Logger. В соответствии с методологией приложения из двенадцати факторов приложение отправляет сообщения, начиная с уровня WARNING, в stderr.

Минимальный уровень журнала можно изменить, установив переменную среды SHELL_VERBOSITY:

Минимальный уровень журнала, вывод по умолчанию и формат журнала также можно изменить, передав соответствующие аргументы конструктору Logger.

Логирование сообщений в Symfony.

Чтобы записать сообщение в лог, передайте логгер как зависимость в ваш контроллер:

use Psr\Log\LoggerInterface;

public function index(LoggerInterface $logger)
{
    $logger->info('I just got the logger');
    $logger->error('An error occurred');

    $logger->critical('I left the oven on!', [
        // include extra "context" info in your logs
        'cause' => 'in_hurry',
    ]);

    // ...
}

Сервис Logger имеет разные методы для разных уровней / приоритетов логирования сообщений. Посмотрите LoggerInterface для списка всех методов в регистраторе.

Установка Monolog в Symfony 5.

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

Например, используя Monolog, вы можете настроить логирование на разные действия в зависимости от уровня сообщения (например, отправка электронного письма при возникновении ошибки).

Выполните эту команду, чтобы установить логирование на основе пакета Monolog перед его использованием:

 composer require symfony/monolog-bundle

Где храняться логи в Symfony?

По умолчанию записи журнала записываются в файл var/log/dev.log, когда вы находитесь в среде разработчика dev.

В среде prod журналы записываются в var/log/prod.log, но только во время запроса, в котором была сделана ошибка или запись в журнале с высоким приоритетом (error() , critical(), alert() или emergency()).

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

Обработчики: запись логов сообщений в разные места.

Логгер имеет стек обработчиков, и каждый из них может быть использован для записи записей журнала в разные места (например, файлы, база данных, Slack и т.д.).

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

Symfony предварительно настраивает некоторые базовые обработчики в стандартных файлах конфигурации monolog.yaml. Проверьте это для некоторых реальных примеров.

В этом примере используются два обработчика: stream (для записи в файл) и syslog для записи журналов с использованием функции syslog:

# config/packages/prod/monolog.yaml
monolog:
    handlers:
        # this "file_log" key could be anything
        file_log:
            type: stream
            # log to var/log/(environment).log
            path: "%kernel.logs_dir%/%kernel.environment%.log"
            # log *all* messages (debug is lowest level)
            level: debug

        syslog_handler:
            type: syslog
            # log error-level messages and higher
            level: error

Это определяет стек обработчиков, и каждый обработчик вызывается в порядке, который он определил.

Обработчики, которые изменяют записи в журнале.

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

По умолчанию в среде prod используется один мощный встроенный обработчик finger_crossed. Он сохраняет все сообщения журнала во время запроса, но передает их только второму обработчику, если одно из сообщений достигает уровня action_level. Например как в этом примере:

# config/packages/prod/monolog.yaml
monolog:
    handlers:
        filter_for_errors:
            type: fingers_crossed
            # if *one* log is error or higher, pass *all* to file_log
            action_level: error
            handler: file_log

        # now passed *all* logs, but only if one log is error or higher
        file_log:
            type: stream
            path: "%kernel.logs_dir%/%kernel.environment%.log"

        # still passed *all* logs, and still only logs error or higher
        syslog_handler:
            type: syslog
            level: error

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

Обработчик с именем «file_log» не будет включен в сам стек, поскольку он используется как вложенный обработчик обработчика finger_crossed.

Если вы хотите переопределить конфигурацию monolog через другой файл конфигурации, вам нужно будет переопределить весь стек обработчиков. Конфигурация из двух файлов не может быть объединена, потому что порядок имеет значение, и объединение не позволяет контролировать заказ.

Еще больше встроенных обработчиков handlers.

Monolog поставляется со многими встроенными обработчиками для отправки журналов по электронной почте, отправки их в Loggly или уведомления в Slack. Они задокументированы внутри самого MonologBundle. Полный список см. В разделе «Конфигурация Monolog».

Как чередовать файлы логов.

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

Другой вариант — заставить Monolog чередовать файлы за вас с помощью обработчика rotating_file. Этот обработчик создает новый файл журнала каждый день, а также может автоматически удалять старые файлы. Чтобы использовать его, установите опцию type вашего обработчика равным rotating_file:

# config/packages/prod/monolog.yaml
monolog:
    handlers:
        main:
            type:  rotating_file
            path:  '%kernel.logs_dir%/%kernel.environment%.log'
            level: debug
            # max number of log files to keep
            # defaults to zero, which means infinite files
            max_files: 10