Мониторинг и устранение неполадок самостоятельно размещаемых воркеров

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

Чтение глубины очереди

client.beta.environments.work.stats() возвращает состояние очереди для среды:

import os

import anthropic

client = anthropic.Anthropic()

stats = client.beta.environments.work.stats(os.environ["ANTHROPIC_ENVIRONMENT_ID"])
print(f"depth={stats.depth} pending={stats.pending}")

{
  "type": "work_queue_stats",
  "depth": 0,
  "pending": 0,
  "oldest_queued_at": null,
  "workers_polling": 0
}

Корректная остановка сеанса

Используйте client.beta.environments.work.stop(), чтобы попросить воркер, обрабатывающий конкретный сеанс, завершить его.

По умолчанию элемент работы переходит в состояние stopping. Воркер замечает это при следующем heartbeat-сигнале аренды, отменяет выполняющийся вызов инструмента сеанса и подтверждает завершение. После этого элемент работы переходит в состояние stopped.

Передайте force=True, чтобы немедленно пометить элемент работы как stopped, не дожидаясь подтверждения от воркера.

Поскольку эти вызовы выполняются из ваших инструментов эксплуатации, а не на хосте воркера, ANTHROPIC_WORK_ID не устанавливается автоматически. Перед запуском следующих примеров задайте в этой переменной ID целевого элемента работы. Чтобы найти ID элемента работы, получите список элементов работы среды через конечные точки Environments Work.

import os

import anthropic

client = anthropic.Anthropic()

work = client.beta.environments.work.stop(
    os.environ["ANTHROPIC_WORK_ID"],
    environment_id=os.environ["ANTHROPIC_ENVIRONMENT_ID"],
)
print(work.state)

Корректная остановка воркеров

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

Принудительно завершённый (killed) процесс не выполняет никакой очистки. Чтобы корректно остановить воркер:

1. Убедитесь, что SIGTERM и SIGINT отменяют воркер. Способ зависит от воркера:

   Воркер	Что сделать
   ant CLI	Ничего. CLI сам обрабатывает оба сигнала: он отменяет выполняющийся вызов инструмента, отправляет результат с ошибкой и освобождает элемент работы.
   Воркер SDK, работающий как отдельный процесс	EnvironmentWorker не устанавливает обработчики сигналов. Отменяйте воркер из обработчика сигнала, как это сделано в примерах автономных воркеров.
   Воркер SDK внутри сервера вебхуков	Отменяйте воркер из собственного хука завершения сервера, как это сделано в примерах с вебхуками. Воркер не должен перехватывать сигналы сервера.

2. Останавливайте воркер сигналом SIGTERM и выделяйте не менее 30 секунд до любого принудительного завершения. Финальная выгрузка может занять столько времени. По умолчанию Docker отправляет SIGKILL через 10 секунд после сигнала остановки. Увеличьте этот лимит с помощью --stop-timeout в docker run или с помощью периода ожидания завершения (termination grace period) вашего оркестратора.

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

Устранение неполадок

Воркер не подключается

Если workers_polling остаётся равным 0, воркер не достигает очереди. Убедитесь, что ANTHROPIC_ENVIRONMENT_KEY и ANTHROPIC_ENVIRONMENT_ID заданы на хосте воркера.

Сеанс остаётся в очереди

Ни один воркер не получает работу. Сеанс в очереди ожидает, а не завершается с ошибкой. Проверьте workers_polling и depth в разделе Чтение глубины очереди.

Хранилища памяти не монтируются

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

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

Вызов пользовательского инструмента не возвращает результат

Если сеанс приостановлен с причиной остановки requires_action, ни один воркер или клиент не обслуживает этот инструмент. См. Предоставление пользовательского инструмента.

Вызов обёрнутого инструмента MCP зависает

Без тайм-аута на клиенте MCP зависший вызов к обёрнутому серверу MCP превращается в результат инструмента с ошибкой только при срабатывании страховочного механизма: