.🛠 Как логировать SQL-запросы только при ошибках

Часто сталкиваюсь с ситуацией: ошибка 500 в проде, а что именно пошло не так — неясно. Особенно если это была ошибка в SQL-запросе. Логировать все SQL-запросы — слишком жирно и шумно. Но логировать только при исключениях — вот это огонь!

🔍 Решение

Добавьте следующий сниппет в AppServiceProvider:

use Illuminate\Support\Facades\DB;
use Illuminate\Support\Facades\Log;

public function boot()
{
    DB::listen(function ($query) {
        if (app()->bound('exception.logged')) {
            Log::channel('sql')->debug($query->sql, $query->bindings);
        }
    });

    app()->singleton('exception.logged', function () {
        return true;
    });

    app()->error(function (\Throwable $e) {
        app()->instance('exception.logged', true);
    });
}

🔐 Пояснение
- При каждом SQL-запросе мы проверяем, был ли в этом запросе выброшен exception.
- Если да — логируем SQL.
- Используем отдельный лог-канал sql, чтобы не засорять основной laravel.log.

👉 Создайте в config/logging.php канал sql, направьте его в отдельный файл, например storage/logs/sql.log.


Теперь, если в продакшене будет падение — вы увидите какой SQL-запрос был выполнен перед ошибкой. Это невероятно ускоряет диагностику багов.

📲 Мы в MAX

👉 @php_lib

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

🔍 Ловим баги быстрее с помощью ray() от Spatie

Обычно мы используем dd() или dump() в Laravel, чтобы посмотреть, что творится с переменными. Но как только проект становится крупнее — эти методы начинают мешать, особенно когда нужно отслеживать несколько значений в разных местах.

Спасает Ray — инструмент от Spatie, который интегрируется с Laravel и выводит отладочную информацию в отдельное десктопное приложение.

Пример:

ray($user);
ray($order)->blue();
ray()->showQueries();

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

⚙️ Установка

composer require spatie/laravel-ray --dev

И по желанию установить десктоп-приложение с сайта Spatie.

В config/ray.php можно кастомизировать поведение: включать Ray только на dev-среде, логировать только определённые запросы и т.д.

🧠 Совет от себя

Ray особенно хорошо заходит, когда работаешь в команде — ты можешь добавить временный ray()-лог, не ломая исполнение и не мешая другим.


Пробовали Ray? Или у вас есть свои инструменты для отладки — может, кастомные макросы или трейты? Делитесь в комментах 👇

📲 Мы в MAX

👉 @php_lib

Сегодня я покажу вам, как удобно логировать в Laravel, не засоряя код и не превращая проект в болото из Log::info() на каждом шагу.

💡 Используем каналы логирования правильно

Laravel предоставляет мощную систему логирования на базе Monolog. Но часто мы ограничиваемся дефолтным логом. А зря.

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

// config/logging.php
'channels' => [
    'payment' => [
        'driver' => 'single',
        'path' => storage_path('logs/payment.log'),
        'level' => 'info',
    ],
],

Теперь в нужном месте можно писать:

Log::channel('payment')->info('Платёж прошёл', ['user_id' => $user->id, 'amount' => $amount]);

И всё — никакой путаницы. В laravel.log остаётся только то, что важно для всего проекта, а логи оплаты — отдельно. Можно и в телеграм скидывать, если настроить webhook.

👀 Бонус: helper-функция

Чтобы писать меньше:

if (!function_exists('payment_log')) {
    function payment_log($message, array $context = []) {
        \Log::channel('payment')->info($message, $context);
    }
}

Теперь вызываем везде просто payment_log('Платёж принят').

Пишите в комментах, какие каналы логирования вы используете и куда пишете — в файл, телегу или Sentry?

📲 Мы в MAX

👉 @php_lib