Laravel log работа с ошибками и регистрация логов в приложении


Содержание материала:

Laravel: регистрация ошибок и хороший вид

Я пытаюсь регистрировать ошибки в Laravel, но он выдает страницу ошибок Chrome 500 по умолчанию еще до того, как достигает функции рендеринга. Как я могу ловить ошибки?

Я хочу записать все ошибки в базу данных и показать хороший дружественный пользовательский вид CUSTOM, но как мне это сделать, если он не доходит до метода рендеринга?

Laravel не может это сделать:

Итак, как вы собираетесь регистрировать ошибки? Это кажется неправильным во многих отношениях.

Также мой файл .EVN:

Решение

Вот как я решаю ту же проблему. В приложении / Exceptions / Handler.php:

Я добавил функцию logError, которая записывает ошибку в базу данных, и у меня есть шаблон в resources / views / errors — 500.blade.php — с пользовательской страницей ошибок.

Я также использую APP_DEBUG в .env, чтобы определить, следует ли регистрировать ошибку в базе данных и отображать страницу ошибки или отображать подробности ошибки на экране.

Другие решения

Вы можете попробовать сторонние пакеты для журнала & показать ошибки.

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

// File App \ Exceptions \ Handler.php;
В Handler.php добавьте или измените этот метод.

Чтобы увидеть хороший вид, измените .env и измените APP_DEBUG с true на false, например, APP_DEBUG = false

Вы также можете регистрировать ошибки только тогда, когда приложение работает.

Ваша ошибка 500 в

Laravel будет автоматически обслуживать эту страницу

Улучшенные логи в Laravel

Настройка пакета производится путем добавления LogEnhancer к параметру tap в config/logging.php :

‘production_stack’ => [
‘driver’ => ‘stack’,
‘tap’ => [Freshbitsweb\LaravelLogEnhancer\LogEnhancer::class],
‘channels’ => [‘daily’, ‘slack’],
],

После настройки канала, в логах появятся дополнительные данные, например:

Вот варианты (также показывающие дополнительные данные, которые включены по-умолчанию), которые вы можете настроить для расширенного ведения журнала:

true,
‘log_input_data’ => true,
‘log_request_headers’ => false,
‘log_session_data’ => true,
‘log_memory_usage’ => false,
‘log_git_data’ => false,
// You can specify the inputs from the user that should not be logged
‘ignore_input_fields’ => [‘password’, ‘confirm_password’]
];

Обратите внимание на ignore_input_fields , чтобы избежать случайного регистрации конфиденциальных пользовательских данных, таких как пароли или кредитные карты. Будьте особенно внимательны, чтобы личные данные не попали в ваши журналы!

Чтобы настроить LogEnhancer , запустите artisan vendor:publish чтобы скопировать config файлы для этого пакета:

php artisan vendor:publish —tag=laravel-log-enhancer-config

Вы можете установить этот пакет вместе с composer , выполнив следующую команду в проекте Laravel 5.6:

composer require freshbitsweb/laravel-log-enhancer

Ошибки и Логирование

Введение

При первом запуске OctoberCMS обработка ошибок и исключений уже настроена. Вы можете посмотреть логи двумя способами:

  1. В файле: storage/logs/system.log .
  2. В административной части сайта: System > Logs > Event Log.

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

Настройка

Детализация ошибок

Подробная детализация ошибок вашего приложения, отображаемая в браузере, контролируется параметром debug в файле config/app.php . По умолчанию подробные отчеты об ошибках включены. Это полезно для отладки и устранения различных проблем, которые могут возникнуть при разработке нового приложения. Иначе на странице отобразится только общее сообщение об ошибке.

Для локальной разработки Вы должны установить для параметра debug значение true . В вашей рабочей среде это значение всегда должно быть false .

Режимы логгирования

Октябрь поддерживает следующие режимы логгирования: single , daily , syslog и errorlog . Например, если Вы хотите использовать режим daily вместо single , Вы должны изменить параметр log в файле с настройками приложения config/app.php :

Типы исключений

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

Application exception

Класс October\Rain\Exception\ApplicationException (или просто ApplicationException ) — наиболее распространенный тип исключения. Оно используется, когда простое условие не сработало.

Сообщение об ошибке будет упрощено и не будет содержать конфиденциальную информацию, такую как файл php и номер строки.

System exception

Класс October\Rain\Exception\SystemException (или просто SystemException ) используется для критических ошибок, которые добавляются в логи.

При вызове этого исключения, отображается подробное сообщение об ошибке с номером файла и строки, в которой она произошла.

Validation exception

Класс October\Rain\Exception\ValidationException (или просто ValidationException ) используется для ошибок, которые связаны непосредственно с отправкой формы. Сообщение должно содержать массив с полями и сообщениями об ошибках.

Вы также можете передать экземпляр службы проверки.

При вызове этого исключения AJAX framework предоставит информацию в удобном для использования формате, и курсор сфокусируется на первом поле, где возникла ошибка.

AJAX exception

Класс October\Rain\Exception\AjaxException (или просто AjaxException ) можно рассматривать в качестве «интеллектуальной ошибки». Он вернет 406 ошибку, что позволит передать ему произвольный контент.

Обработка исключений

Все исключения обрабатываются классом October\Rain\Foundation\Exception\Handler , который имеет два метода: report и render . Метод report используется для логгирования исключений, а render — для преобразования исключения в ответ, который можно отправить в браузер.

Вы также можете создавать произвольные обработчики, если это необходимо, при помощи метода App::error . Например, Вы можете создать обработчик, который обрабатывает только экземпляры RuntimeException :

Если обработчик исключений возвращает ответ, этот ответ будет отправлен в браузер, и никакие другие обработчики ошибок не будут вызваны:

Используйте метод App::fatal , чтобы прослушивать фатальные ошибки PHP:

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

Где разместить обработчики ошибок?

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


HTTP exceptions

Такие ошибки могут возникнуть во время обработки запроса от клиента. Это может быть ошибка «Страница не найдена» (http-код 404), «Требуется авторизация» (401) или даже «Ошибка сервера» (500). Для того, чтобы отправить такой ответ, используйте следующее:

Опционально, Вы можете установить свой ответ для возврата в браузер:

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

Произвольная страница ошибки

По умолчанию страница с ошибкой содержит секцию с кодом, номер строки и трассировку стека, где она возникла. Вы можете изменить эту страницу, установив значение параметра debug на false в файле с настройками config/app.php и создав страницу со следующим URL: /error .

Логгирование

По умолчанию October настроен так, чтобы создать один лог-файл в каталоге storage/logs . Вы можете записывать в логи информацию следующим образом:

Существует восемь уровней логгирования, которые определены в RFC 5424: emergency, alert, critical, error, warning, notice, info и debug.

Контекстная информация

Массив с контекстными данными может быть также передан методами журнала. Эти контекстные данные будут отформатированы и отображены в сообщении:

Хелперы

Существует несколько глобальных методов, которые упрощают работу с логгированием. Функция trace_log — псевдоним Log::info с поддержкой массивов и исключениями.

Исключения Laravel: ловим, обрабатываем и создаем собственные

Обычно веб-разработчики не следят за ошибками. Если что-то идет не так, то мы частенько видим дефолтный текст ошибки Laravel: «Whoops, something went wrong» или, что еще хуже, код исключения, который посетителю совсем ни к чему. Поэтому я решил написать пошаговую статью о том, как элегантно обрабатывать ошибки и показывать посетителю правильную информацию о произошедшем.

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

Подготовка: Задача поиска пользователя

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

У нас есть два маршрута:

И контроллер с двумя методами:

В файле resources/views/users/index.blade.php находится сама форма:

Если мы ищем существующего пользователя и он найден, мы видим такой результат:

Всё это находится в resources/views/users/search.blade.php:

Но это в идеальном случае, а что, если пользователь не найден?

Обработка исключений

Давайте вернемся в реальный мир. Мы не проверяем существование пользователя, в контроллере мы только делаем:

И, если пользователь не найден, то получим это:

Или, понятное дело, мы можем задать APP_DEBUG=false в файле .env, и тогда браузер просто покажет пустую страницу с «Whoops, looks like something went wrong». Но для нашего посетителя все это совершенно бесполезно.

Еще одно быстрое исправление, которое мы можем сделать, это использовать User::findOrFail() вместо просто find() — тогда, если пользователь не найден, Laravel покажет страницу 404 с текстом «Sorry, the page you are looking for could not be found». Но это дефолтная страница ошибки для всего сайта. Для посетителя она, опять таки, бесполезна.

Поэтому нам нужно отлавливать ошибки, обрабатывать их и перенаправлять обратно в форму с действительно понятным сообщением об ошибке.

Нам нужно знать тип исключения и имя класса, которое оно будет возвращать. В случае с findOrFail() будет выдано Eloquent исключение ModelNotFoundException, поэтому нам нужно сделать так:

Теперь давайте покажем ошибку в Blade:

Отлично, мы отобразили ошибку! Но это еще не идеал, верно? Вместо $exception->getMessage() нам нужно показать наше собственное сообщение:

Топ-пост этого месяца:  Урок 7. NodeJS. Получение API ключа

Перемещаем обработку ошибок в Сервис

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

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

Давайте переместим нашу логику в app/Services/UserService.php:

А в контроллере нам нужно вызвать этот сервис. Для начала мы внедрим его в метод __construct():

Если вы не знакомы с внедрением зависимостей и как работает контейнер Laravel IOC, то вот официальная документация.

А вот так теперь выглядит наш метод search():

Обратите внимание, мы снова можем использовать $exception->getMessage(), вся проверка ошибок и логика сообщений происходит внутри службы. Мы удалили это из контроллера, он не должен заниматься этим.

Следующий Шаг: Создание собственного класса исключений

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

Итак, как мы можем создать наш собственный класс исключений? Очень просто — с помощью команды Artisan:

Сгенерируется app/Exceptions/UserNotFoundException.php:

Здесь же ничего нет, верно? Давайте заполним наше исключение логикой.
В этом классе может быть два метода:

  • report() — используется, если вы хотите сделать дополнительную запись в журнал — отправить сообщение об ошибке в BugSnag, на почту, в Slack и т. д.
  • render() — используется, если вы хотите сделать редирект с ошибкой или вернуть HTTP-ответ (например, свой собственный файл Blade ) непосредственно из класса Exception

Итак, для этого примера мы cделаем метод report():

А вот так мы вызываем это исключение из контроллера:

Итак, это всё, что я хотел рассказать вам об обработке исключений и использовании Сервисов.

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

Подробнее об исключениях и обработке ошибок: официальная документация Laravel.

Laravel — Logging

Вступление

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

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

Конфигурация

Вся конфигурация для системы регистрации вашего приложения находится в файле конфигурации. Этот файл позволяет настроить каналы журналов вашего приложения, поэтому обязательно просмотрите каждый из доступных каналов и их параметры. Мы рассмотрим несколько распространенных вариантов ниже. config/logging.php

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

Настройка имени канала

По умолчанию Monolog создается с «именем канала», которое соответствует текущей среде, например, production или local . Чтобы изменить это значение, добавьте name параметр в конфигурацию вашего канала:

Доступные драйверы канала


название Описание
stack Обертка для облегчения создания «многоканальных» каналов
single Канал логгера на основе одного файла или пути ( StreamHandler )
daily RotatingFileHandler Драйвер на основе Монолог , который вращается ежедневно
slack SlackWebhookHandler Драйвер Монолог на основе
papertrail SyslogUdpHandler Драйвер Монолог на основе
syslog SyslogHandler Драйвер Монолог на основе
errorlog ErrorLogHandler Драйвер Монолог на основе
monolog Заводской драйвер Monolog, который может использовать любой поддерживаемый обработчик Monolog
custom Драйвер, который вызывает указанную фабрику для создания канала

Проверьте документацию по расширенному каналу настройки , чтобы узнать больше о monolog и custom водителях.

Настройка одиночного и дневного каналов

single И daily каналы имеют три дополнительных опций конфигурации: bubble , permission и locking .

название Описание По умолчанию
bubble Указывает, должны ли сообщения пузыриться к другим каналам после обработки true
permission Разрешения файла журнала 0644
locking Попытайтесь заблокировать файл журнала перед записью в него false

Настройка канала Papertrail

Для papertrail канала требуются параметры конфигурации url и port . Вы можете получить эти значения из Papertrail .

Настройка слабого канала

slack Канала требует url параметр конфигурации. Этот URL-адрес должен соответствовать URL-адресу входящего веб-крюка, который вы настроили для своей команды Slack.

Строительство бревен

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

Давайте рассмотрим эту конфигурацию. Во-первых, обратите внимание, что наш stack канал объединяет два других канала с помощью своей channels опции: syslog и slack . Таким образом, при регистрации сообщений оба канала будут иметь возможность регистрировать сообщения.

Уровни журнала

Обратите внимание на level опцию конфигурации, присутствующую в конфигурациях каналов syslog и и slack в приведенном выше примере. Эта опция определяет минимальный «уровень» сообщения, который должен быть зарегистрирован для канала. Monolog, который поддерживает службы журналов Laravel, предлагает все уровни журналов, определенные в спецификации RFC 5424 : аварийный , аварийный , критический , ошибка , предупреждение , уведомление , информация и отладка .

Итак, представьте, что мы записываем сообщение, используя debug метод:

Учитывая нашу конфигурацию, syslog канал запишет сообщение в системный журнал; однако, так как сообщение об ошибке не critical указано или выше, оно не будет отправлено в Slack. Однако, если мы зарегистрируем emergency сообщение, оно будет отправлено как в системный журнал, так и в Slack, поскольку emergency уровень выше нашего минимального порогового уровня для обоих каналов:

Написание сообщений журнала

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

Таким образом, вы можете вызвать любой из этих методов, чтобы записать сообщение для соответствующего уровня. По умолчанию сообщение будет записано в канал журнала по умолчанию, настроенный вашим файлом конфигурации: config/logging.php

Контекстная информация

Массив контекстных данных также может быть передан в методы журнала. Эти контекстные данные будут отформатированы и отображены в сообщении журнала:

Запись на определенные каналы

Иногда вам может потребоваться записать сообщение на канал, отличный от канала вашего приложения по умолчанию. Вы можете использовать channel метод на Log фасаде, чтобы получить и войти в любой канал, определенный в вашем файле конфигурации:

Если вы хотите создать стек регистрации по требованию, состоящий из нескольких каналов, вы можете использовать stack метод:

Расширенная настройка канала Monolog

Настройка Monolog для каналов

Иногда вам может понадобиться полный контроль над настройкой Monolog для существующего канала. Например, вы можете настроить пользовательскую FormatterInterface реализацию Monolog для обработчиков данного канала.

Для начала определите tap массив в конфигурации канала. tap Массив должен содержать список классов , которые должны иметь возможность настроить (или «кран» в) экземпляр Монолог после ее создания:

Как только вы настроили tap опцию на своем канале, вы готовы определить класс, который будет настраивать ваш экземпляр Monolog. Этому классу нужен только один метод:, __invoke который получает экземпляр. В экземпляра прокси все вызовы методов базового Monolog например: Illuminate\Log\Logger Illuminate\Log\Logger

Все ваши классы «tap» разрешаются контейнером службы , поэтому любые зависимости от конструкторов, которые им требуются, будут автоматически вставлены.

Создание каналов обработчика Monolog

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

При использовании monolog драйвера handler опция конфигурации используется, чтобы указать, какой обработчик будет создан. Необязательно, любые параметры конструктора, которые нужны обработчику, могут быть указаны с with помощью параметра конфигурации:

Монолог Форматеры

При использовании monolog драйвера Monolog LineFormatter будет использоваться в качестве форматера по умолчанию. Однако вы можете настроить тип форматера, передаваемого обработчику, используя параметры конфигурации formatter и formatter_with :

Если вы используете обработчик Monolog, который может предоставить свой собственный модуль форматирования, вы можете установить значение параметра formatter конфигурации в default :

Создание каналов через фабрики

Если вы хотите определить полностью собственный канал, в котором вы имеете полный контроль над созданием и настройкой Monolog, вы можете указать custom тип драйвера в вашем файле конфигурации. Ваша конфигурация должна включать опцию, указывающую на класс фабрики, который будет вызываться для создания экземпляра Monolog: config/logging.php via

После того как вы настроили custom канал, вы готовы определить класс, который будет создавать ваш экземпляр Monolog. Этому классу нужен только один метод:, __invoke который должен возвращать экземпляр Monolog:

Logging

Introduction

To help you learn more about what’s happening within your application, Laravel provides robust logging services that allow you to log messages to files, the system error log, and even to Slack to notify your entire team.

Under the hood, Laravel utilizes the Monolog library, which provides support for a variety of powerful log handlers. Laravel makes it a cinch to configure these handlers, allowing you to mix and match them to customize your application’s log handling.

Configuration

All of the configuration for your application’s logging system is housed in the config/logging.php configuration file. This file allows you to configure your application’s log channels, so be sure to review each of the available channels and their options. We’ll review a few common options below.

By default, Laravel will use the stack channel when logging messages. The stack channel is used to aggregate multiple log channels into a single channel. For more information on building stacks, check out the documentation below.

Configuring The Channel Name

By default, Monolog is instantiated with a «channel name» that matches the current environment, such as production or local . To change this value, add a name option to your channel’s configuration:

Available Channel Drivers

Name Description
stack A wrapper to facilitate creating «multi-channel» channels
single A single file or path based logger channel ( StreamHandler )
daily A RotatingFileHandler based Monolog driver which rotates daily
slack A SlackWebhookHandler based Monolog driver
syslog A SyslogHandler based Monolog driver
errorlog A ErrorLogHandler based Monolog driver
monolog A Monolog factory driver that may use any supported Monolog handler
custom A driver that calls a specified factory to create a channel

Check out the documentation on advanced channel customization to learn more about the monolog and custom drivers.

Configuring The Single and Daily Channels

The single and daily channels have three optional configuration options: bubble , permission , and locking .

Name Description Default
bubble Indicates if messages should bubble up to other channels after being handled true
permission The log file’s permissions 0644
locking Attempt to lock the log file before writing to it false

Configuring The Slack Channel

The slack channel requires a url configuration option. This URL should match a URL for an incoming webhook that you have configured for your Slack team.

Building Log Stacks

As previously mentioned, the stack driver allows you to combine multiple channels into a single log channel. To illustrate how to use log stacks, let’s take a look at an example configuration that you might see in a production application:

Let’s dissect this configuration. First, notice our stack channel aggregates two other channels via its channels option: syslog and slack . So, when logging messages, both of these channels will have the opportunity to log the message.

Log Levels

Take note of the level configuration option present on the syslog and slack channel configurations in the example above. This option determines the minimum «level» a message must be in order to be logged by the channel. Monolog, which powers Laravel’s logging services, offers all of the log levels defined in the RFC 5424 specification: emergency, alert, critical, error, warning, notice, info, and debug.

So, imagine we log a message using the debug method:

Given our configuration, the syslog channel will write the message to the system log; however, since the error message is not critical or above, it will not be sent to Slack. However, if we log an emergency message, it will be sent to both the system log and Slack since the emergency level is above our minimum level threshold for both channels:


Writing Log Messages

You may write information to the logs using the Log facade. As previously mentioned, the logger provides the eight logging levels defined in the RFC 5424 specification: emergency, alert, critical, error, warning, notice, info and debug:

So, you may call any of these methods to log a message for the corresponding level. By default, the message will be written to the default log channel as configured by your config/logging.php configuration file:

Contextual Information

An array of contextual data may also be passed to the log methods. This contextual data will be formatted and displayed with the log message:

Writing To Specific Channels

Sometimes you may wish to log a message to a channel other than your application’s default channel. You may use the channel method on the Log facade to retrieve and log to any channel defined in your configuration file:

If you would like to create an on-demand logging stack consisting of multiple channels, you may use the stack method:

Advanced Monolog Channel Customization

Customizing Monolog For Channels

Sometimes you may need complete control over how Monolog is configured for an existing channel. For example, you may want to configure a custom Monolog FormatterInterface implementation for a given channel’s handlers.

To get started, define a tap array on the channel’s configuration. The tap array should contain a list of classes that should have an opportunity to customize (or «tap» into) the Monolog instance after it is created:

Once you have configured the tap option on your channel, you’re ready to define the class that will customize your Monolog instance. This class only needs a single method: __invoke , which receives an Illuminate\Log\Logger instance. The Illuminate\Log\Logger instance proxies all method calls to the underlying Monolog instance:

All of your «tap» classes are resolved by the service container, so any constructor dependencies they require will automatically be injected.

Creating Monolog Handler Channels

Monolog has a variety of available handlers. In some cases, the type of logger you wish to create is merely a Monolog driver with an instance of a specific handler. These channels can be created using the monolog driver.

When using the monolog driver, the handler configuration option is used to specify which handler will be instantiated. Optionally, any constructor parameters the handler needs may be specified using the handler_with configuration option:

Monolog Formatters

When using the monolog driver, the Monolog LineFormatter will be used as the default formatter. However, you may customize the type of formatter passed to the handler using the formatter and formatter_with configuration options:

If you are using a Monolog handler that is capable of providing its own formatter, you may set the value of the formatter configuration option to default :

Creating Channels Via Factories

If you would like to define an entirely custom channel in which you have full control over Monolog’s instantiation and configuration, you may specify a custom driver type in your config/logging.php configuration file. Your configuration should include a via option to point to the factory class which will be invoked to create the Monolog instance:

Once you have configured the custom channel, you’re ready to define the class that will create your Monolog instance. This class only needs a single method: __invoke , which should return the Monolog instance:

Become a Laravel Partner

Laravel Partners are elite shops providing top-notch Laravel development and consulting. Each of our partners can help you craft a beautiful, well-architected project.

Логирование. NLog Platform. Зачем нужны логи в приложении

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

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

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

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

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

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

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

Trace – максимально детальная информация о том, что происходит с целевым участком кода, по шагам. Например: Попытка открыть подключение к БД, успешно\неуспешно. Сколько времени заняла эта операция. Сколько времени выполнялась выборка из БД, успешно\неуспешно. Сколько записей извлечено. Какая была нагрузка на систему, сколько использовано памяти. Сколько записей прошло нужную фильтрацию. Сколько записей оказалось в результирующей выборке, куда эти записи отправились дальше. Проверка нужных значений в каждой записи.

Debug – это информация для отладки. Логирование крупных операций, менее детально, чем в Trace. Здесь мы не так подробно описываем весь процесс операции, но, тем не менее, заносим в журнал основные операции. Например: Совершено обращение к БД. Из базы выбрано N записей. Записи успешно обработаны и отправлены клиенту.

Info – это более общие информационные сообщения о текущей работе приложения, что происходит с системой в процессе ее использования. Например: Была выгрузка студентов в Excel-файл. На сайте зарегистрирован новый студент. Студент добавил новый отчет. Студент перемещен в другую группу.

Warn – сообщения о странной или подозрительной работе приложения. Это еще не серьезная ошибка, но следует обратить внимание на такое поведение системы. Например: Добавлен студент с возрастом 2 года. Студент получил отрицательный балл. Преподаватель завершил курс, в котором училось 0 студентов. В группе находится больше студентов, чем максимально возможно.

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

Fatal – сообщения об очень серьезных ошибках в системе. Чаще всего это связано с работоспособностью всего приложения или его окружения на сервере. На такие сообщения следует реагировать МАКСИМАЛЬНО оперативно. Например: Приложение постоянно перезагружается из-за нехватки памяти или места на жестком диске. Приложение завершило работу по неизвестной причине. Нет доступа к базе данных. Нет доступа к сети. Заблокирован какой-то порт.

То есть, прежде чем отправить какое-то сообщение в лог, нам нужно отнести его к той или иной группе.

Например, мы написали новый функционал и хотим его протестировать, как правильно и быстро он работает. Для этого мы будем использовать тип сообщений Trace, то есть все наши сообщения в логе будут помечены как Trace.

Подобным образом мы можем описать, как работает наше приложение в целом, сообщения будут с пометкой Info.

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

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

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

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

Для того, чтобы начать логирование, мы подключим в наш проект платформу NLog. Это можно легко сделать посредством менеджера NuGet (прямо из Visual Studio).

Обратите внимание на конфигурационный файл NLog.config. В этом файле находятся настройки логгера (куда будут выводиться логи, формат записи логов и т.д.). Давайте настроим файл следующим образом:

Здесь мы описали два правила и цели, к которым они применяются. Мы хотим чтобы отладочная информация была записана в один файл, а информация об ошибках — в другой (в поддиректории errors). Оба лога будут писаться в текстовый файл. Также мы используем специальные теги (директивы), которые понимает NLog. На их место будут подставлены соответствующие значения в процессе выполнения. Опишем теги, которые используются у нас в конфигурации (описание всех тегов и любую другую информацию можно найти на официальном сайте проекта NLog):

  • $ — корневой каталог нашего приложения
  • $ — текущая дата в формате yyyy-MM-dd
  • $ — текущая дата в формате yyyy-MM-dd HH:mm:ss.ffff
  • $ — место вызова лога (название класса, название метода)
  • $ — уровень логирования
  • $ — непосредственно сообщение, которое будет записано в лог
  • $ — символ новой строки

Далее уже в коде объявим новый логгер (здесь код проекта приводится в сокращенном виде, исходный код всего проекта можно скачать в конце статьи):

Чаще всего следует объявлять один статичный логгер в пределах всего класса. Здесь мы посредством класса-менеджера LogManager объявили новый логгер, с которым будем работать.

Начнем логирование с уровня Trace. В методе, где мы выбираем студента по его идентификатору, давайте максимально подробно опишем как это происходит:

Обратите внимание, что мы на объекте logger вызываем метод Trace(). Он имеет соответствующее значение — запись в лог сообщения типа Trace. Если обратиться к определению класса Logger, то можно обнаружить, там также присутствуют и другие методы для всех уровней лога, которые мы будем использовать далее.

Теперь давайте добавим несколько сообщений уровня Debug. Как мы помним, это тоже отладочная информация, но менее детальная. Данный подход мы используем в другом методе, для наглядности:

Идем далее. На уровне Info мы описываем регулярные операции в нашем приложении, то есть поднимаемся еще на уровень выше. Предположим, что мы работаем над ASP.NET MVC приложением, и у нас есть действие в контроллере, которое обращается к ранее описанному методу GetStudentById():

Теперь добавим в логи сообщения уровня Warn. Как мы помним, на этом уровне логирования мы описываем все потенциально опасные ситуации, странное и нелогичное поведение компонентов. Будем заносить в лог запись, если студенту меньше 15 лет:

Далее обработаем ошибку в нашем коде и запишем в лог сообщение уровня Error:

Теперь определим, что же нам записать на уровне Fatal. В нашем простейшем примере просто смоделируем подобную ситуацию:

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

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

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


На этом здесь все, давайте подведем небольшой итог. Мы изучили тему логирования в приложении. Посмотрели как правильно логировать те или иные участки кода, а также познакомились с одной из самых популярных платформ логирования – это NLog Platform, также рассмотрели ее возможности и как можно настроить генерацию логов на этой платформе.

Все о WEB программировании

WEB программирование от А до Я

Заказать сайт:

Социальные сети:

Партнеры:

Как сохранить время последнего входа пользователя и IP-адрес

Доброго времени суток. В одном из проектов мне необходимо было вести лог активности пользователя. Логирование практически любого действия (время, ip адрес и само действие). В этом нет ничего сложного. Давайте я расскажу, как это сделать и немного упростим задачу. Будем ввести лог только для аутентификации (записывать дату и ip адрес). И все это дело будем писать в стандартный лог файл.

Как устанавливать Laravel я не буду рассказывать, это можно прочитать в официальной документации или кто не очень дружит с английским языком можно прочитать в переведенной документации. Теперь давайте сделаем первоначальные настройки.

Настройка проекта на Laravel

Мы настроим подключение к базе данных и логирование. Для этого откроем файл .env, который расположен в корне нашего проекта и изменим настройки. (База данных у меня называется lara, логин – homestead, пароль – secret)

Теперь настроим логирование так, чтобы логи писались по дням: laravel- .log

Отлично. На этом настройка завершена. Теперь переходим к созданию аутентификации в нашем приложении.

Аутентификация в Laravel

Тут вообще проще простого. Laravel из коробки поддерживает аутентификацию. Нам необходимо ввести две команды:

И вторая команда:

Первая команда создает контроллеры аутентификации, регистрации, сброса пароля и напоминание пароля, виды и роуты. А вторая выполняет миграцию, при выполнении которой буду созданы две таблицы (в одной хранятся email, пароли и др. данные о пользователя, а вторая необходима для хранения данных при восстановлении пароля).

Теперь если мы перейдем на наш сайт, то увидим ссылки: на страницу авторизации и на страницу регистрации.

Давайте пройдем регистрацию, а потом авторизацию.

Регистрация и авторизация в Laravel

Проходим по ссылке Register и вводим все необходимые данные. И при успешной регистрации нас сразу перенаправит на защищенную страницу

Отлично. Теперь давайте разлогинемся и снова залогинемся. Все работает.

Вот мы и подошли к самому интересному.

Запись даты и ip адрес в лог при авторизации.

В AuthenticatesUsers есть метод authenticated(Request $request, $user), который выполняется, когда пользователь проходит аутентификацию. Поэтому в своем контроллере Auth\LoginController мы можем переопределить его, добавив код в конец нашего контроллера

И не забываем прописать:

Тут мы использовали фасад Log для записи данных в файл логов. Для работы с датой мы использовали Carbon. Как работать с датой и временем с помощью carbon вы можете прочитать в статье «Работа с датой и временем в Laravel и PHP с помощью Carbon».

Давайте проверим, что у нас получилось. Залогинимся в нашем приложении и посмотрим лог, который находится в storage\logs

И в самом логе будет следующее:

Как видите все работает.

Заключение.

Мы с вами сделали логирование при авторизации пользователя. Правда записываем дату и ip адрес в файл, что не очень правильно (хотя… смотря для чего).

Laravel 5.6. Monolog хранения логов в базе данных.

Данная статья не является полноценным переводом, для меня она является руководством по размещению логов в базу данных. Надеюсь кому-то она еще поможет, решить данную проблему. Если будут вопросы, пишите в комментариях, будем вместе разбираться.

Итак проблема: запись логов в базу данных.

В Laravel в коробочном решении есть логгер «Monolog». Фреймворк и библиотека позволяет нам написать собственный обработчик логов, но информации, как всегда, в русскоязычной сети недостаточно. Поиск привел меня на статью, с помощью которой мне удалось решить данную проблему, и я решил поделиться с Вами.

В первую очередь создаем миграцию и модель

Далее настраиваем канал логов.

Переходим в настройки \config\logging.php

custom — указываем на то, что мы пишем свой обработчик
database — название канала
via — обработчик

Настройка обработчика Monolog

Создаем файл Log.php. Я сделал такой путь до файла \app\Logging\Database\Log.php. Вы можете сделать любой другой.

Находясь в том же пространстве имен, создаем обработчик LogHandler

При выводе $record будет массив, здесь есть два массива context и extra. Нам нужно еще level, description, result и др, чтобы собрать в кучу и отформатировать их, пишем LogFormatter.

Сохранение в БД

Теперь при добавлении данного кода

появиться ошибка Unknown column ‘foo’, произошло она из-за того что мы слили массив и этого поля нет в БД.

Сделаем исключение лишних данных(перед методом fill)ю

в обработчике раскомментируем строку event()

как записывать информацию, ошибки, предупреждения, аварийные ошибки в разные файлы вместо laravel.log

В основном, у меня есть это прямо сейчас в logging.php

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

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

Я искал слишком много. Я нашел так много решений, но с тех пор laravel так сильно изменился, что ни одно решение не сработало для меня. Я использую 5.7 laravel.

Explaination

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

Пример из документов Laravel:

Учитывая нашу конфигурацию, канал системного журнала запишет сообщение в системный журнал; однако, поскольку сообщение об ошибке не является критическим или выше, оно не будет отправлено в Slack. Однако, если мы регистрируем экстренное сообщение, оно будет отправлено как в системный журнал, так и в Slack, поскольку уровень аварийной ситуации выше нашего минимального порогового уровня для обоих каналов.

Решение 1

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

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

Решение 2

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

Добавить комментарий