Самостоятельно размещаемые окружения находятся в публичной бета-версии на планах Team и Enterprise; Owner включает их, активируя Allow self-hosted environments на странице администратора Cloud environments. Эта страница является справочником по флагам и метрикам; см. quickstart для настройки и Deploy to production для рецептов флота.
/workspace и ~/.claude, предполагаются. Запустите claude self-hosted-runner --help для авторитетного списка на вашей установленной версии.
Серии метрик и несколько полей API по-прежнему используют pool для того, что эти страницы называют окружением; оба термина обозначают одно и то же. ID окружения — это поле pool_id с формой ccpool_...: везде, где эти страницы показывают идентификатор pool, он обозначает окружение. Флаги CLI и переменные окружения пишут его как environment, например --environment-secret-file; устаревшие написания pool по-прежнему работают, как описывает строка --environment-secret-file.
Флаги CLI Runner
Большинство флагов имеют соответствующую переменную окружения. Когда установлены оба, флаг имеет приоритет. Флаги длительности принимают минуты или секунды в CLI, но связанная переменная окружения всегда в миллисекундах, обозначаемая суффиксом_MS, и столбец Default показывает единицу флага: --exit-if-unused-min 10 эквивалентно SELF_HOSTED_RUNNER_IDLE_SHUTDOWN_MS=600000, а значение Helm вроде SELF_HOSTED_RUNNER_STARTUP_TIMEOUT_MS: "15" означает 15 миллисекунд, а не 15-минутное значение по умолчанию.
Большинство флагов длительности имеют максимум, выбранный для сохранения каждого timeout в потолке 32-битного таймера runtime примерно 24,85 дня. Флаги
--*-min ограничены 10080 минутами, 7 дней; --drain-grace-sec на 604800 секунд, также 7 дней; и --drain-wait-sec на 86400 секунд, 24 часа. --session-stop-grace-sec и --post-session-hook-timeout-sec не ограничены. Превышение лимита ведет себя по-разному в зависимости от поверхности:
- Флаг: запуск не удается с ошибкой.
- Переменная окружения: runner зажимает значение до потолка таймера вместо его отклонения.
Флаги CLI Orchestrator
Подкомандаself-hosted-runner orchestrator, которая порождает on-demand runners, принимает --api-url, --environment-secret-file, --hooks-dir, --health-port и --log-level с теми же значениями по умолчанию, что и runner и, где флаг runner имеет один, ту же переменную окружения, за исключением того, что --hooks-dir требуется и должен содержать hook spawn-runner. Он также принимает свои собственные флаги:
Флаги SCM connector
Orchestrator может держать постоянное подключение WebSocket к плоскости управления Anthropic, чтобы размещенные предсеансовые потоки, такие как средство выбора репозитория и средство разрешения ветви или ссылки, могли достичь хоста GitHub Enterprise Server, который маршрутизируется только изнутри вашей сети. Соединитель остается отключенным, если вы не установите--scm-connector-host.
Соединитель аутентифицируется с существующим секретом среды orchestrator и автоматически переподключается: с экспоненциальной задержкой при разорванном подключении или фиксированной 30-секундной задержкой, когда плоскость управления закрывает подключение, потому что другая реплика orchestrator уже его держит.
Параметры только для переменных окружения
Эти параметры runner читаются только из окружения и охватывают поведение, которое большинство развертываний оставляют по умолчанию:Телеметрия
Дочерние процессы сеанса отправляют операционную телеметрию в Anthropic, если вы её не отключите. Никакой код или содержимое репозитория не отправляется. Установите переменные телеметрии на процесс runner; runner переустанавливает их после применения переменных окружения, предоставленных сервером, поэтому параметр оператора всегда имеет приоритет. Один элемент управления специфичен для самостоятельно размещаемых сред:CLAUDE_CODE_BYOC_ENABLE_DATADOG=1 выбирает метрики операционной деятельности Datadog, которые по умолчанию отключены в самостоятельно размещаемых средах. Общие элементы управления телеметрией Claude Code, DISABLE_TELEMETRY, DO_NOT_TRACK, DISABLE_ERROR_REPORTING и CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, применяются к дочерним процессам сеанса, как задокументировано в справочнике переменных окружения. DISABLE_GROWTHBOOK связан, но отличается: установка DISABLE_GROWTHBOOK=1 отключает выборку флагов функций, и телеметрия остается включенной, если также не установлен DISABLE_TELEMETRY.
CLAUDE_CODE_ENABLE_TELEMETRY не связан: он включает экспорт OpenTelemetry на ваш собственный сборщик, как описано в Monitoring, и не контролирует аналитику Anthropic.
Конечная точка здоровья
Runner служитGET /healthz на настроенном порту здоровья. Ответ 200 OK всякий раз, когда процесс живой, независимо от состояния цикла опроса, поэтому зонд HTTP на этой конечной точке обнаруживает только мертвый процесс. Тело JSON описывает текущее состояние:
last_poll_age_ms как сигнал живости в пользовательских зондах; значение, которое растет без ограничений, указывает на то, что цикл опроса застрял. Оба last_poll_at и last_poll_age_ms равны null до завершения первого опроса.
Orchestrator служит своему собственному /healthz на его порту здоровья. Его конечная точка всегда возвращает 200, и тело несет поле connected, сообщающее, успешен ли последний опрос, плюс количество очереди порождения для каждого состояния в queue_counts. Ограничьте готовность и оповещение на connected вместо кода состояния.
Когда SCM connector настроен, тело /healthz orchestrator также несет scm_connector_connected и объект scm_connector с connected, last_connected_at, last_error, reconnects и requests_forwarded. Оба поля равны null, когда --scm-connector-host не установлен.
Метрики Prometheus
Каждый runner служит метрикам Prometheus вGET /metrics на том же порту, что и /healthz. Ключевые серии:
Orchestrator служит своим собственным сериям в
GET /metrics на том же порту, что и его /healthz:
Для автомасштабирования выберите серию, которая соответствует вашему стилю масштабирования, и ограничьте её перед подачей в масштабер:
- Масштабирование глубины очереди: подайте
claude_code_self_hosted_orchestrator_pool_pending_sessionsв ваш HPA или KEDA масштабер, а неqueue_pending_sessions. - Масштабирование емкости: масштабируйте по соотношению
active_sessionsrunner кcapacity. - Ограничение на
connected: отфильтруйте запрос с помощьюclaude_code_self_hosted_orchestrator_connected == 1на экземпляр, поэтому устаревшее значение отключенной реплики не подается в масштабер.
ignoreNullValues: "true" читает пустой результат как ноль и масштабирует; установите ignoreNullValues: "false" на ScaledObject, опционально с полом реплики fallback.
Следующий Prometheus Operator PodMonitor охватывает оба процесса. Он выбирает pods по метке app.kubernetes.io/part-of: claude-code-self-hosted-runner и именованному порту health, который устанавливает рецепт Kubernetes; отрегулируйте пространства имен в соответствии с вашим развертыванием:
Пропустить метрики дочернего процесса сеанса
Каждый сеанс работает в своем собственном дочернем процессе с собственными метриками OpenTelemetry; при--capacity выше одного runner переписывает, как эти метрики дочернего процесса выставляются. Установка OTEL_METRICS_EXPORTER=prometheus на хосте runner и CLAUDE_CODE_ENABLE_TELEMETRY=1 в окружении сеанса, например из вашего скрипта-обертки или собственного окружения runner, которое сеансы наследуют, переоткрывает счетчики и датчики каждого дочернего процесса на собственной конечной точке /metrics runner, наряду с сериями runner. Runner переписывает экспортер дочернего процесса для отправки по OTLP на приемник только для loopback на порту здоровья, помечает каждую серию метками session_id и client_platform и вытесняет серии сеанса при завершении этого сеанса. Гистограммы не проходят, и метрика дочернего процесса, чье имя будет конфликтовать с собственным префиксом runner, отпускается.
При значении по умолчанию --capacity 1 переписывание не применяется: дочерний процесс сеанса привязывает свою собственную конечную точку Prometheus на порту 9464 как обычно.
Семантика счетчика жизненного цикла сеанса
Счетчикиsessions_started_total, sessions_completed_total, sessions_failed_total и sessions_interrupted_total классифицируют каждый сеанс по тому, как он завершился. Каждый порожденный дочерний процесс сеанса увеличивает sessions_started_total во время порождения, и ровно один из трех других увеличивается при выходе, поэтому sessions_started_total минус сумма трех других равна количеству дочерних процессов сеанса, в настоящее время работающих.
completed: сеанс завершился чисто. Это охватывает дочерний процесс, выходящий самостоятельно с кодом0, сеанс, архивируемый или удаляемый, пока дочерний процесс был все еще подключен, и runner, передающий слот чисто: отпуск сеанса при timeout простоя, времени выхода на пенсию или лимите--kill-session-after-min; startup timeout; или деассайн на стороне сервера, который цикл опроса заметил перед выходом дочернего процесса. Увеличиваетsessions_completed_total.failed: дочерний процесс выходит самостоятельно с ненулевым кодом, либо сбой, либо сбой настройки после порождения. Увеличиваетsessions_failed_total.interrupted: runner завершил дочерний процесс по операционной причине, которая не является ни успехом сеанса, ни ошибкой runner, такой как осушение или завершение сеанса, который все еще был на runner, когда окончилось окно благодатиSELF_HOSTED_RUNNER_MAX_LIFETIME_GRACE_MSпосле его лимита--kill-session-after-min. Перезагрузка Kubernetes, отправляющаяSIGTERM, является одним примером осушения. Увеличиваетsessions_interrupted_total.
--kill-session-after-min, и подсчитывал его в sessions_interrupted_total.
Hook post-session классифицирует чистые передачи по-другому через CLAUDE_RUNNER_EXIT_REASON. Hook сообщает об отпуске, startup timeout и деассайне сервера как interrupted, потому что runner остановил дочерний процесс. Эти счетчики записывают те же события, что и completed, потому что слот был передан чисто.
Если вы согласовываете квитанции hook непосредственно с sessions_completed_total, вы недосчитываетесь завершений. Используйте hook для гарантий для каждого сеанса и счетчики для совокупных ставок.
В одноразовой среде --capacity 1 с значением по умолчанию --drain-grace-sec 0 каждый процесс runner выходит через несколько мгновений после завершения его одного сеанса. sessions_completed_total, sessions_failed_total и sessions_interrupted_total увеличиваются только при завершении сеанса, прямо перед этим выходом, поэтому скребок Prometheus каждые 15-60 секунд редко ловит увеличение перед исчезновением серии runner; эти три счетчика конца сеанса — это терминальные счетчики, на которые ссылается остальная часть этого раздела. sessions_started_total увеличивается при порождении и остается видимым в течение жизни сеанса, поэтому он надежно показывается, но в одноразовой среде он читается ближе к “сеансам, в настоящее время работающим”, чем к совокупному подсчету.
Используйте серию в этой таблице для соответствующей цели вместо терминальных счетчиков:
Строки
orchestrator_* существуют только в средах, работающих с on-demand orchestrator. На фиксированном флоте, чьи runner пережили свои сеансы, с --drain-grace-sec выше 0, используйте sum(rate(claude_code_self_hosted_runner_sessions_started_total[5m])) для пропускной способности; в одноразовом флоте эта серия имеет ту же проблему окна скребка, что и терминальные счетчики, поэтому полагайтесь на подсчет сеансов в очереди вместо этого. Проверьте невыполненные заказы на вкладке Activity среды, на странице администратора Cloud environments: runner не экспортируют серию глубины очереди.
Для отчетности результатов для каждого сеанса используйте вместо этого hook post-session: он срабатывает при каждом завершении сеанса, где был порожден дочерний процесс, кроме резкого завершения runner, такого как вытеснение VM, в соответствии с собственным контрактом hook.
Что дальше
- Self-hosted environments: среда, runner и модель сеанса; quickstart и Deploy to production содержат настройку и операции
- Customize sessions: скрипты-обертки, hooks жизненного цикла и on-demand runner
- Verify session identity: токен сеанса, его претензии и как его проверить