Логи и наблюдаемость

Что платформа пишет в логи, какие есть проверки состояния и где смотреть текущую нагрузку и ошибки.

Коротко

Метрик в платформе нет. Есть проверки состояния, экраны администрирования и логи в стандартный вывод. На этом можно построить рабочий контроль, но это не система метрик.

Проверки состояния

Адрес	Что отвечает
GET /healthz на API	Признак работоспособности API и признак доступности Runtime
GET /healthz на Runtime	Только признак того, что процесс жив
GET /internal/status на Runtime	Полный снимок загрузки: сколько запусков идёт, сколько шагов выполняется, сколько ожидает, сколько рабочих процессов и живых сессий

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

Чего нет в проверке состояния

Доступность базы данных не проверяется. Отдельной проверки готовности, отличной от проверки живости, тоже нет. Адрес /internal/status не защищён авторизацией и должен быть доступен только из внутренней сети.

Экраны для наблюдения

Экран	Что показывает
Администрирование, Рантайм	Состояние обеих частей, текущие лимиты, живые сессии с владельцами, распределение запусков по состояниям, последние неудачные запуски, очередь и счётчики внешнего API
Администрирование, Расход	Сводка по израсходованным токенам и обращения к моделям

Экран Рантайма обновляется опросом каждые 2,5 секунды. В очереди видны только служебные сведения, текст сообщений там не показывается.

Логи

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

Ограничения логирования

Уровень логирования не настраивается. Скрытия чувствительных значений в логах нет. Идентификатор запроса не передаётся между API и Runtime, поэтому связать запрос пользователя с запуском в Runtime по логам напрямую нельзя.

Чего в платформе нет

Нет	Пояснение
Адреса /metrics	Совместимости с Prometheus нет
OpenTelemetry, трассировки	Не подключены
Отправки ошибок во внешний сервис	Не подключена
Настраиваемых уровней и выгрузки логов в файл	Не реализованы

Что можно делать сегодня

Разумный набор действий при эксплуатации:

• проверки живости направлять на GET /healthz обеих частей;
• собирать стандартный вывод контейнера, это готовые строки JSON;
• следить за экраном Рантайма: нагрузка, очередь, последние неудачные запуски;
• следить за экраном Расхода, чтобы видеть потребление токенов;
• считать двумя основными источниками ошибок неудачные запуски и состояние серверов MCP с текстом последней ошибки.

Если нужны метрики и графики, это доработка платформы, а не вопрос настройки.