Laravel

Для Laravel есть пакет steadrun/laravel-monitor. Он сам отправляет пинги из Scheduler и воркеров очередей, дописывать curl к каждой задаче не нужно.

Что умеет пакет:

Каждую часть можно включить отдельно.

Установка#

composer require steadrun/laravel-monitor

Нужны PHP 8.1 или новее и Laravel 10, 11, 12 или 13. Пакет регистрируется сам. Конфиг публиковать нужно, только если у Вас несколько очередей с разными проверками (об этом ниже):

php artisan vendor:publish --tag=steadrun-config

Задачи Scheduler#

Создайте в Steadrun проверку типа «Cron» с тем же расписанием, что у задачи, и добавьте pingSteadrun():

$schedule->command('backup:run')->dailyAt('03:00')->pingSteadrun('ВАШ-UUID');

Перед запуском задачи пакет отправит /start, после успешного завершения — обычный пинг, при ошибке — /fail. Так Steadrun узнает о падении сразу и посчитает, сколько работает задача.

Пинги уходят с таймаутом 5 секунд. Если Steadrun недоступен, пакет запишет предупреждение в лог, а задача и schedule:run продолжат работать как обычно.

Причина падения в алерте#

$schedule->command('backup:run')->dailyAt('03:00')->pingSteadrun('ВАШ-UUID', withOutput: true);

С withOutput: true при падении пакет отправит на /fail последние 8 КБ вывода задачи, и они придут в алерте. По умолчанию это выключено, и вот почему:

• вывод попадает в Steadrun и в алерты всем получателям. Не включайте для задач, которые могут напечатать пароли, токены или данные пользователей;
• чтобы получить вывод, Laravel пишет его в storage/logs/schedule-<hash>.log. Файл перезаписывается при каждом запуске. Если у задачи уже есть свой sendOutputTo() или appendOutputTo(), пакет его не трогает.

Работает ли schedule:run#

Пинги от отдельных задач не помогут, если не запускается сам Scheduler. Например, после переезда забыли строку в crontab или упал контейнер с планировщиком. Чтобы заметить это, добавьте в .env:

STEADRUN_CRON_UUID=ВАШ-UUID

Пакет добавит в расписание пустую задачу steadrun-cron-heartbeat, которая пингует каждые 5 минут. В Steadrun создайте проверку типа «Cron» с выражением */5 * * * * и grace-периодом в несколько минут.

Упавшие jobs#

STEADRUN_QUEUE_UUID=ВАШ-UUID

После этого каждый упавший job, в любой очереди, отправит /fail на эту проверку. В алерте будут класс job'а, соединение, очередь и текст исключения с трейсом (Steadrun оставит первые 10 КБ).

Кто вернёт проверку в «работает»#

/fail переводит проверку в «не отвечает». Обратно её вернёт только обычный пинг. Если на проверку приходят одни сообщения о падениях, после первого же упавшего job'а она так и останется лежать. О следующих упавших jobs алертов не будет, потому что для Steadrun это то же самое падение. Придут только напоминания раз в час.

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

STEADRUN_QUEUE_PROBE_UUID=ВАШ-UUID
STEADRUN_QUEUE_UUID=ВАШ-UUID

Проверочный job пингует раз в 5 минут. Упал job — придёт алерт. В течение пяти минут проверочный job вернёт проверку в «работает», придёт сообщение о восстановлении, и следующий упавший job снова даст алерт.

Несколько очередей#

Если падения в разных очередях должны приходить в разные проверки, опубликуйте конфиг и заполните queue_check_uuids в config/steadrun.php:

'queue_check_uuid' => env('STEADRUN_QUEUE_UUID'), // для всех остальных очередей

'queue_check_uuids' => [
    'emails' => env('STEADRUN_QUEUE_UUID_EMAILS'),
    'imports' => env('STEADRUN_QUEUE_UUID_IMPORTS'),
],

Очередь, которой нет в списке, пойдёт в общую проверку. Если общей нет, падения в ней не отправляются.

Жив ли воркер#

Алерт об упавшем job'е не придёт, если воркер умер целиком. Например, закончилась память или оборвалось соединение с Redis. Тогда нет ни выполненных jobs, ни упавших. Чтобы заметить такое, включите heartbeat:

STEADRUN_WORKER_HEARTBEAT_UUID=ВАШ-UUID

Воркер будет пинговать не чаще раза в минуту, даже если очередь пустая. В Steadrun нужна проверка типа «Очередь» с интервалом 1 минута. Интервал меняется переменной STEADRUN_WORKER_HEARTBEAT_INTERVAL (в секундах), тогда поменяйте его и в проверке.

Тонкости:

• Долгие jobs. Воркер пингует только между jobs. Пока идёт долгий импорт, пингов нет. Grace-период проверки должен быть больше самого долгого job'а в этой очереди.
• php artisan down. В режиме обслуживания воркер не берёт jobs и не пингует. Перед down ставьте проверку на паузу, после up возобновляйте. На тарифе «Команда» это удобно делать из скрипта деплоя через API.
• Несколько процессов. Если Supervisor запускает несколько процессов воркера (numprocs), каждый пингует сам. Это не страшно, даже десять процессов далеко от лимита в 120 пингов в минуту.

Heartbeat отвечает только на вопрос «процесс жив». Он не заметит, что очередь отстала на несколько часов или что воркер слушает не ту очередь. Для этого есть следующий раздел.

Не отстаёт ли очередь#

STEADRUN_QUEUE_PROBE_UUID=ВАШ-UUID

Пакет раз в 5 минут ставит в очередь по умолчанию маленький job QueueProbeJob. Когда воркер до него доходит, job отправляет пинг. Если в очереди затор, пинг опоздает, а если воркер слушает другую очередь, пинг не придёт совсем. В Steadrun нужна проверка типа «Очередь» с интервалом 5 минут. Grace-период равен задержке, которую Вы готовы терпеть, например 10 минут.

Для работы нужен запущенный schedule:run. Если нужна другая частота, поставьте job в расписание сами:

$schedule->job(new \Steadrun\LaravelMonitor\QueueProbeJob('ВАШ-UUID'))->everyMinute();

Все переменные#

Сопоставление очередей и проверок (queue_check_uuids) задаётся только в опубликованном конфиге.

Обновление с версии 0.2#

Актуальная версия пакета 0.3. Вот что в ней поменялось:

• пинги Scheduler идут через фасад Http. В тестах работает Http::fake(). Если Вы подменяли Guzzle в контейнере, например ради прокси, на пинги это больше не влияет;
• неудачный пинг пишется в лог как предупреждение и не попадает в обработчик исключений;
• все запросы пакета идут с таймаутом 5 секунд, раньше было 30.

Что дальше#

• Как это работает: когда придёт алерт, напоминания и пауза.
• Пинги: что значат /start и /fail, время выполнения задачи.