1С-БитриксАгентыCronМониторинг

Агенты Битрикс на cron: мониторинг b_agent через административный гаджет

22 июля 2026 г.

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

Практичный локальный индикатор — административный гаджет, который показывает активные агенты с просроченным NEXT_EXEC. Он не заменяет внешний мониторинг, но позволяет увидеть накопившуюся очередь прямо в панели Битрикс.

Что означают ACTIVE и NEXT_EXEC

Для первичной диагностики важны два поля:

ACTIVE = 'Y' — агент включён;
NEXT_EXEC — плановое время следующего запуска.

Если активный агент должен был запуститься давно, но NEXT_EXEC остаётся в прошлом, очередь, вероятно, не обрабатывается. Условие тревоги:

ACTIVE = Y
AND NEXT_EXEC < now - threshold

Порог обязателен. Проверка NEXT_EXEC < now даст ложные тревоги из-за обычной задержки между запусками cron, времени выполнения batch и конкуренции задач.

Выбор порога

Порог должен быть больше нормального интервала cron и ожидаемой длительности очереди. Если cron работает каждую минуту, стартовый warning-порог может составлять 10 минут, critical — 30 минут. Для тяжёлых ночных задач нужны отдельные правила.

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

Запрос к b_agent

Прямой запрос через D7 connection даёт понятный read-only контроль:

use Bitrix\Main\Application;
use Bitrix\Main\Type\DateTime;

$threshold = (new DateTime())->add('-10 minutes');
$helper = Application::getConnection()->getSqlHelper();

$sql = "
    SELECT ID, NAME, MODULE_ID, NEXT_EXEC
    FROM b_agent
    WHERE ACTIVE = 'Y'
      AND NEXT_EXEC IS NOT NULL
      AND NEXT_EXEC < " . $helper->convertToDbDateTime($threshold) . "
    ORDER BY NEXT_EXEC ASC
";

$rows = Application::getConnection()->query($sql)->fetchAll();

Перед использованием проверьте формат DateTime::add() на поддерживаемой версии Битрикс. Запрос читает системную таблицу и не меняет расписание. Лимитируйте выдачу, если агентов много.

Можно использовать API агентов, но для мониторингового среза прямой read-only запрос проще и не создаёт побочных эффектов. Имя таблицы и поля относятся к внутренней структуре продукта, поэтому проверку нужно повторять после крупных обновлений.

Что показать в гаджете

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

зелёный статус, если просроченных нет;
количество warning и critical;
максимальная задержка;
первые 10–20 агентов: MODULE_ID, безопасное имя, NEXT_EXEC;
время самой проверки;
ссылка на стандартный раздел агентов.

Имя функции может содержать параметры и технические данные. Перед выводом используйте htmlspecialcharsbx, не отображайте секреты из аргументов. Гаджет доступен только администраторам с подходящими правами.

foreach (array_slice($rows, 0, 20) as $row) {
    echo '<tr>';
    echo '<td>' . htmlspecialcharsbx((string) $row['MODULE_ID']) . '</td>';
    echo '<td>' . htmlspecialcharsbx((string) $row['NAME']) . '</td>';
    echo '<td>' . htmlspecialcharsbx((string) $row['NEXT_EXEC']) . '</td>';
    echo '</tr>';
}

Это минимальный фрагмент вывода. В production добавьте локализацию, CSRF-защиту для любых действий и разделение warning/critical.

Проверка cron

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

php /path/to/bitrix/modules/main/tools/cron_events.php

Путь приведён как общий пример и зависит от установки. В cron задайте явный PHP binary, рабочий каталог и лог ошибок. Не запускайте второй экземпляр чаще, чем первый успевает завершиться; используйте блокировку на уровне планировщика.

Ограничения проверки NEXT_EXEC

Просрочка говорит, что агент не был успешно перепланирован, но не объясняет причину. И обратное тоже верно: свежий NEXT_EXEC не доказывает успешный бизнес-результат.

Гаджет не обнаружит:

агент завершился без исключения, но не отправил заказ;
задача обработала только часть данных;
внешний API вернул логическую ошибку, которую код проглотил;
повторяющийся агент обновил расписание до фактической работы;
cron выполняется на неверной копии сайта;
время приложения и СУБД рассинхронизировано.

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

Снижение ложных тревог

Не считайте просроченными:

неактивные агенты;
задачи без NEXT_EXEC, если это допустимо их типом;
известные долгие операции в пределах их SLA;
период обслуживания, когда cron сознательно остановлен.

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

Сам гаджет не отправляет тревогу, пока администратор не открыл панель. Для круглосуточного контроля экспортируйте тот же read-only health check во внешний мониторинг. Не публикуйте endpoint без аутентификации и не возвращайте имена всех агентов наружу.

План внедрения

Зафиксировать фактический интервал cron.
Измерить нормальную задержку NEXT_EXEC.
Назначить warning и critical.
Добавить read-only запрос и ограниченный гаджет.
Проверить остановкой cron на тестовом контуре.
Добавить метрики критичных бизнес-очередей.
Настроить внешний сигнал, если нужна реакция без входа в админку.

Практический вывод

Связка cron и гаджета по b_agent закрывает базовый вопрос: выполняется ли очередь агентов примерно по расписанию. Проверяйте только ACTIVE = 'Y', сравнивайте NEXT_EXEC с осмысленным порогом и показывайте максимальную задержку.

Не выдавайте этот индикатор за полный мониторинг. Для заказов, платежей и обменов добавляйте проверку результата самой операции. Настройку cron, диагностику очередей и регулярный контроль можно включить в поддержку сайта на 1С-Битрикс.

По теме статьи

Поддержка и сопровождение сайта на 1С-Битрикс