1C-Bitrix Agents Run Late: Where to Find the Queue

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

Чтобы не чинить расписание наугад, я разделяю задержку на три участка: вызов проверки агентов, выбор задачи, срок которой наступил, и работа самой функции. Для каждого участка нужны свои отметки времени. Иначе две разные проблемы выглядят одинаково: «агент опоздал».

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

Официальная документация главного модуля описывает проверку агентов как запуск функций, время которых наступило. В режиме на посещениях такая проверка привязана к началу обработки страницы. На малопосещаемом сайте это сразу создаёт понятную границу: нет подходящего посещения — нет точного минутного ритма.

Перенос на cron убирает зависимость от трафика, но не превращает расписание в отдельного исполнителя для каждого агента. Один вызов всё равно должен получить список задач и выполнить работу в доступном процессе.

Для периодического агента следующая дата привязана к предыдущему запланированному запуску и интервалу. Для непериодического — к моменту успешного завершения и интервалу. Эта разница важна при расследовании: длительная работа может по-разному выглядеть в истории и влиять на момент следующего выполнения.

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

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

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

• Есть ли регулярные старты процесса в ожидаемом часовом поясе.
• Доходит ли процесс до проверки агентов, а не завершается раньше.
• Одинаковы ли окружение, пользователь и доступ к нужной конфигурации.
• Не выполняется ли одновременно другой механизм, который меняет картину.

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

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

Минимальный набор наблюдений — идентификатор запуска, имя или идентификатор агента, время начала и окончания, результат, количество обработанных элементов и отметка последнего успешного шага. Рабочие данные и секреты в журнал не помещают. Если задача берёт порции, полезно фиксировать границы порции, чтобы повтор не выглядел новым успехом.

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

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

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

• T1 — момент, когда агент стал доступен для запуска.
• T2 — фактический вызов механизма проверки агентов.
• T3 — начало функции конкретного агента.
• T4 — подтверждённый бизнес-результат или передача в следующую очередь.

Разница T2 − T1 показывает задержку вызова. T3 − T2 — ожидание внутри механизма выполнения. T4 − T3 — длительность функции и следующих синхронных шагов. Если после агента есть отдельная очередь, добавляют ещё одну отметку результата её потребителя. Это учебная модель, но она заставляет формулировать проблему точнее, чем «cron тормозит».

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

Расписание меняют, если доказано, что проверка вызывается реже требуемого или запускается не тем окружением. Очередь разбирают, если вызов регулярный, но T3 заметно отстаёт от T2. Функцию оптимизируют или делят на порции, если основное время уходит между T3 и результатом.

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

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

In the agents list, the next run time is already in the past, cron has triggered, yet the email, export, or recalculation still appears late. It is tempting to blame cron. However, it may be running faithfully every minute and not be responsible for what happens afterward.

To avoid fixing the schedule blindly, I divide the delay into three stages: the trigger for the agent check, the selection of the task whose deadline has arrived, and the execution of the function itself. Each stage requires its own timestamp. Otherwise, two different problems look identical: "the agent was late."

The next run time field means the agent can be selected for execution after that moment. However, the check code must be invoked: either during page processing or by a separate scheduled process if the system uses cron. Therefore, the actual start cannot occur before the next invocation and may happen later due to the queue.

Official documentation for the main module describes agent checks as the execution of functions whose scheduled time has arrived. In visit-based mode, such checks are tied to the start of page processing. On a low-traffic site, this immediately creates a clear boundary: without a suitable visit, there is no precise minute-level rhythm.

Moving to cron removes the dependency on traffic, but it does not turn the schedule into a separate executor for each agent. One invocation must still receive the list of tasks and perform the work in an available process.

For a periodic agent, the next date is tied to the previous scheduled run and the interval. For a non-periodic agent, it is tied to the moment of successful completion and the interval. This difference is important during investigation: long-running tasks may appear differently in the history and affect the timing of the next execution.

A non-periodic scheme is convenient when a new launch cannot overlap with an unfinished previous one. However, it also means the interval starts only after the work ends. If the function took twenty minutes, waiting for the next result five minutes after the original deadline is incorrect.

Periodicity alone does not indicate whether a task completes, whether it repeats the same data batch, or whether it safely survives an error. These properties are defined by the function logic, not the schedule string.

The first pair of times is the planned cron moment and the actual process start. These are taken from the scheduler log and the handler's own startup log. A successful cron status without an internal marker in the handler proves only an attempt to run the environment command, not the execution of the required application path.

• Are there regular process starts in the expected time zone?
• Does the process reach the agent check instead of terminating early?
• Are the environment, user, and access to the required configuration identical?
• Is another mechanism not running simultaneously that changes the picture?

In this article, I intentionally do not provide a universal cron string. The project path, environment version, deployment method, and agent configuration settings differ. A copy-pasted command without these conditions more often adds a second launch than it explains the first.

If the check is triggered on time, compare the handler entry moment with the specific agent start moment. A large gap between them indicates a queue or work performed before the required agent. A small gap with a late result shifts focus to inside the function itself.

The minimal observation set includes the run identifier, agent name or ID, start and end times, result, number of processed items, and the timestamp of the last successful step. Operational data and secrets are not logged. If a task processes in batches, recording batch boundaries is useful so that a retry does not appear as a new success.

A long-running agent may occupy the process with network activity, an external API call, a large query, or processing an excessively large batch. Even when the server has sufficient CPU, waiting for an external system leaves subsequent tasks without a start. Therefore, a graph of overall load is useful but does not replace the duration of each segment.

The agent could have started on time and passed the work to a separate queue. In this case, the agent completion marker indicates only that the task was successfully queued, not that an email was sent or that the stock level was updated. A single identifier that travels from the agent to the queue consumer and the final event is required for such a scenario.

The reverse situation also occurs: the business result is created, but the interface displays an old state from the cache. If you check only the screen, execution delay mixes with display delay. First, search for the event in the result source, then trace the path to the interface.

• T1 — the moment the agent became available for execution.
• T2 — the actual call to the agent check mechanism.
• T3 — the start of the specific agent function.
• T4 — the confirmed business result or handover to the next queue.

The difference T2 − T1 shows the call delay. T3 − T2 represents the wait time within the execution mechanism. T4 − T3 indicates the function duration and subsequent synchronous steps. If a separate queue exists after the agent, add another result marker for its consumer. This is a training model, but it forces a more precise problem formulation than "cron is slow".

It is better to measure several sequential runs, including both normal and elevated load. A single successful run does not rule out a queue, and a single failure might coincide with maintenance of an external service. At the same time, monitoring must not itself generate heavy requests or expose order contents.

Change the schedule if it is proven that the check is called less frequently than required or runs in the wrong environment. Address the queue if the call is regular but T3 lags significantly behind T2. Optimize the function or split it into chunks if the main time is spent between T3 and the result.

Before making changes, it is useful to define the acceptable delay for a specific process. Sending a service report can wait, but removing unavailable items from sale carries a different risk. Having the same minute in the schedule does not make these tasks equally urgent.

If an agent runs late, a good outcome of the investigation is not a new cron line, but the identified delay segment and the verifiable stop condition. The call must be regular, the queue must be observable, the function must fit within its window, and the business result must be confirmed separately. Then the next delay will be visible by time and location, not by a random complaint.