Логирование – это то, как разработчики понимают почему приложение терпит неудачу, во время улучшения и отладки.
В любом приложении разработчик должен иметь возможность видеть, что происходит во время использования приложения, чтобы отлавливать проблемы по мере их возникновения и определять возможности для улучшения.
При внедрении любого решения для ведения логирования важно иметь достаточно логов, чтобы иметь возможность собирать нужную информацию и метрики, но не перегружать журнал, чтобы любая важная информация была потеряна в море данных.
В этой записи вы узнаете, как реализовать ведение логов в популярном PHP-фреймворке Laravel. Laravel — это PHP-фреймворк основанный на паттерне Model-View-Controller, который позволяет разработчикам быстро и легко создавать что угодно, от небольших веб-сайтов до приложений корпоративного уровня.
Начало работы с логами в Laravel
Когда вы начнете реализовывать ведение логов в своем приложении Laravel, первая проблема — с которой вы столкнетесь это решить, что именно нужно регистрировать. Подобно комментированию кода, комментарии в определенных местах кодовой базы могут быть полезны, в то время как комментирование каждой строки может загромождать кодовую базу, затрудняя работу с ней.
Общие приоритеты ведения логов в приложениях включают ответы API на вызовы внешних служб, любые запросы или поведение приложения, которое происходит медленнее, чем ожидалось. И, как минимум, уведомления и ошибки, создаваемые либо Laravel, либо PHP. У логов двоякая цель: регистрировать ошибки, чтобы их можно было отладить, даже если они не могут быть воспроизведены в режиме реального времени. И определять области для улучшения в приложении, и именно здесь пригодятся уведомления и предупреждения на уровне PHP.
События, которые необходимо регистрировать, имеют разную серьезность, и большинство регистраторов, включая Laravel, определяют так называемые уровни логирования.
Эти уровни определены в документе, известном как RFC 5424, и доступны в фасаде лога Laravel.
Они включают в себя emergency, alert, critical, error, warning, notice, info и debug. Они определены в Laravel, как показано ниже:
use Illuminate\Support\Facades\Log;
Log::emergency($message);
Log::alert($message);
Log::critical($message);
Log::error($message);
Log::warning($message);
Log::notice($message);
Log::info($message);
Log::debug($message);Вы можете вызвать любой из этих методов, чтобы зарегистрировать сообщение для нужного уровня. По умолчанию сообщение будет записано в канал лога по умолчанию, настроенного в файле конфигурации ведения логирования.
Когда вы используете встроенный фасад логирования Laravel, он использует каналы лога как способ записи того, куда вы отправляете свою информацию. Каналы логирования могут делать множество вещей, включая отправку сообщений лога в стандартный системный журнал логирования или отправку лога в Papertrail или даже отправку записей лога в виде сообщений Slack.
Лучшие практики ведения Лога в Laravel
При использовании фасада логирования Laravel заданного по умолчанию относительно просто начать вставлять операторы журнала в критические точки вашего приложения; однако, если заранее не учесть несколько ключевых моментов, эти журналы могут быстро стать непригодными для использования и представлять угрозу безопасности.
Структурирование, хранение и вывод логов
В зависимости от того, как часто вы записываете файлы логов, они могут быстро увеличиваться в размерах до такой степени, что любое приложение, используемое для их чтения или фильтрации, может начать с трудом анализировать объем хранимой информации. В большинстве логов используется концепция ротации, при которой файлы логов автоматически сжимаются, архивируются, переименовываются или удаляются либо по достижении определенного размера, либо по календарному расписанию. Это гарантирует, что ни один файл логов не станет слишком большим. Если файлы логов заархивированы или хранятся где-то еще, это означает, что к ним можно получить доступ, если исторические данные действительно необходимы, но только самая актуальная (и, следовательно, наиболее полезная) информация сохраняется там, где она может быть использована.
Под капотом многие фреймворки PHP используют библиотеку Monolog, и она стала в значительной степени стандартом в экосистеме PHP. Вместо того, чтобы писать логи вручную, Monolog позволяет разработчикам легко записывать файлы логов и управлять ими, предоставляя стандартный интерфейс для ведения. Это позволяет разработчикам создавать средства ведения логов, которые записывают данные в различные каналы. Сосредотачиваются на логике своего приложения, вместо того чтобы тратить ненужное время на написание пользовательского кода ведения логов.
Если у вас есть хранилище под вашим управлением, то необходим способ чтения логов. Хотя большинство логов хранятся в виде обычного текста и могут быть открыты в любом текстовом редакторе, специальная программа для чтения журналов имеет функции, которых нет в стандартном текстовом редакторе. Для примера, существует специфичный для Laravel пакет под названием Laravel Log Viewer, который можно установить через Composer, который может отображать ваши журналы через маршрут или настраиваемое представление, и с ним можно работать более эффективно.
Файлы Laravel config/logging.php
Именно в этом файле config/logging.php настраивается большая часть ведения журнала для вашего приложения Laravel. Если вы создадите новое приложение Laravel, то вы увидите там есть значения по умолчанию для многих параметров логов, которые поддерживает Laravel, с каналом логов по умолчанию, а также примеры конфигураций для некоторых других настроек. Например, в верхней части файла конфигураций вы увидите что-то вроде следующего:
/*
|--------------------------------------------------------------------------
| Default Log Channel
|--------------------------------------------------------------------------
|
| This option defines the default log channel that gets used when writing
| messages to the logs. The name specified in this option should match
| one of the channels defined in the "channels" configuration array.
|
*/
'default' => env('LOG_CHANNEL', 'stack'),Этот код устанавливает канал логов по умолчанию для Laravel. Если у вас есть значение для LOG_CHANNEL в файле .env, оно будет использоваться; иначе он вернется к каналу логов стека. Под этим значением по умолчанию находится массив всех различных каналов логов, которые можно настроить.
Хотя изменение того, что регистрирует ваше приложение, должно происходить вокруг кода, который вы хотите регистрировать, любые изменения в том, как ваше приложение ведет логи, должны быть внесены и централизованы в файле config/logging.php. Таким образом, другие разработчики знают, где искать нужные настройки, если их нужно будет изменить в будущем.
Вопросы безопасности
Обычный путь, которым все компании (включая профильные) неосознанно сливают информацию – это ведение логов. Если вы как разработчик не будете осторожны, конфиденциальная личная информация, включая пароли, может быть записана в файл логов, который обычно хранится в условиях менее интенсивной защиты, чем пароли, хранящиеся в базе данных или какой-либо другой системе. Например, если вы пытаетесь отладить информацию, связанную с пользователем, и вывести из системы весь объект пользователя, то информация об этом пользователе может занестись в журнал логов. Если в будущем произойдет утечка этих журналов или доступ к ним будет осуществлен несанкционированным образом, вся информация о зарегистрированных пользователях также будет утеряна. В зависимости от того, какую информацию вы храните о пользователе, это может иметь серьезные личные последствия, а также потенциально создать юридическую и финансовую ответственность для владельца приложения. К счастью, существуют пакеты PHP, которые вы можете включить в свое приложение для маскировки этих данных. Тем не менее, все же стоит время от времени проверять свои журналы логов, чтобы убедиться, что там не хранится конфиденциальная информация.
Общие инструменты для логирования
С базовой настройкой ведения журнала Laravel по умолчанию легко начать работу. По мере того, как приложения становятся более сложными и распределенными, этого базового ведения логирования иногда недостаточно, чтобы предоставить разработчикам информацию, необходимую для обеспечения бесперебойной работы их приложений.
Разработчики часто используют такие инструменты, как Papertrail, чтобы отслеживать свои логи, или New Relic, чтобы дать им возможность наблюдать за тем, что происходит с их приложением. Однако когда вы приступаете к сложным развертываниям инфраструктуры с участием Kubernetes, все становится немного сложнее. Вот где ContainIQ может помочь.
Использование ContainIQ для приложения Laravel
В качестве решения для ведения журналов ContainIQ позволяет вам еще глубже изучить ваш код и инфраструктуру, отслеживая ваше приложение непосредственно из ядра, предоставляя разработчикам более конкретные логи на уровне кластера и на уровне приложения. С другими инструментами ведения журнала логов, которые не являются родными для Kubernetes, вы можете получить определенные части ошибок регистрации вашего приложения, когда на самом деле ошибка находится на уровне инфраструктуры. Это может отправить вас в кроличью нору расследования, которое в конечном итоге не даст результатов.
ContainIQ не только позволяет разработчикам быстрее выявлять проблемы, но и помогает решить, на что следует обратить внимание, а что можно безопасно игнорировать. Используя исторические данные, команды могут устанавливать более интеллектуальные уведомления, чтобы избежать усталости от оповещений и гарантировать, что только та информация, которая должна быть рассмотрена, попадает к разработчикам, которые могут внести необходимые изменения.
После срабатывания предупреждения и необходимости внесения изменений ContainIQ собирает всю необходимую информацию в одном месте. Современные приложения Laravel сложны, и отслеживание решения зарегистрированной проблемы часто включает сравнение нескольких наборов логов для вашего приложения, инфраструктуры и иногда даже внешних поставщиков. Однако ContainIQ может хранить данные из нескольких источников на одной платформе, что позволяет пользователям сопоставлять события из нескольких наборов журналов без необходимости вручную сравнивать метки времени.
Это особенно важно при попытке выяснить, почему возникают определенные ошибки в контексте вашей инфраструктуры Kubernetes. Поскольку ContainIQ может помочь вам визуализировать всю настройку Kubernetes и определить конкретные узлы, в которых вы видите ошибки, вы можете быстро узнать, что происходит, и решить проблемы.
Если ваше приложение стало более сложным, чем его можно эффективно отладить с помощью логов Laravel по умолчанию, или если отладка и решение проблем занимают слишком много времени и создают слишком много неопределенности, ContainIQ может стать шагом вперед, который вам нужен, чтобы довести ведение журнала Laravel до уровня следующий уровень.
Resume
Логи являются важной функцией любого стека приложений. Приложения, созданные с помощью Laravel, не являются исключением. В то время как Laravel предоставляет надежный фасад логирования из коробки, который может обрабатывать ведение журнала базового уровня и может передавать эти данные журнала в различные источники, когда ваше приложение становится более сложным и развертывается в инфраструктуре, такой как Kubernetes, вам нужны более конкретные решения.
ContainIQ предоставляет широкий набор инструментов ведения логирования, и с его помощью вы можете быть уверены, что ваши разработчики получают информацию, необходимую им для быстрой и точной отладки и улучшения своих приложений.