Перейти к содержанию

Глава 13: Мониторинг состояния и диагностика

Аудитория: DevOps, платформенные инженеры

Эндпоинты состояния

/api/health: проверка работоспособности

Возвращает базовый статус API, git SHA и версию. Используется рабочим процессом развёртывания и внешним мониторингом.

curl -sS https://scan.rtb.cat/api/health | jq .

/system/data-health: полнота данных

Возвращает статус полноты данных по каждому байеру, включая состояние свежести для каждого типа отчёта. Принимает параметры days, buyer_id и availability_state.

Используется чек-листом первоначальной настройки и проверкой состояния при запуске.

Страница состояния системы (/settings/system)

Интерфейс отображает:

Проверка Что отслеживается
Python Версия и доступность среды выполнения
Node Сборка Next.js и состояние SSR
FFmpeg Возможность генерации миниатюр видео
Database Подключение к Postgres и количество записей
Thumbnails Статус пакетной генерации и очередь
Disk space Использование дискового пространства ВМ

Скрипты проверки состояния

Эти скрипты являются основой оперативной проверки работоспособности системы от начала до конца.

diagnose_v1_buyer_report_coverage.sh

Диагностирует причины отсутствия CSV-покрытия для конкретного байера.

export CATSCAN_CANARY_EMAIL="cat-scan@rtb.cat"
scripts/diagnose_v1_buyer_report_coverage.sh \
  --buyer-id 1487810529 \
  --timeout 180 \
  --days 14

Проверки (по порядку): 1. Маппинг мест: buyer_id -> bidder_id 2. Матрица импорта: pass/fail/not_imported по типу CSV 3. Свежесть данных: покрытие ячеек imported/missing 4. История импорта: последние записи импорта 5. Статус Gmail: количество непрочитанных, последняя причина, дата последней метрики

Результат: PASS или FAIL с конкретным диагнозом.

run_v1_runtime_health_strict_dispatch.sh

Выполняет полную проверку состояния при запуске, включающую:

  • Работоспособность API
  • Полнота данных (свежесть и покрытие измерений)
  • Состояние и готовность конверсий
  • Задержка запуска QPS
  • Сводка SLO страницы QPS
  • Экономика оптимизатора и модели
  • Валидация эндпоинтов моделей
  • Рабочий процесс score+propose
  • Жизненный цикл предложений
  • Пробный откат (dry-run)

Каждая проверка возвращает PASS, FAIL или BLOCKED (с указанием причины).

CI-рабочий процесс: v1-runtime-health-strict.yml

Выполняет строгую проверку в CI. Запускается вручную через workflow_dispatch.

gh workflow run v1-runtime-health-strict.yml \
  --ref unified-platform \
  -f api_base_url="https://scan.rtb.cat/api" \
  -f buyer_id="1487810529" \
  -f canary_profile="balanced" \
  -f canary_timeout_seconds="180"

Аутентификация canary-скриптов

Скрипты проверки состояния аутентифицируются через переменные окружения:

Переменная Назначение
CATSCAN_CANARY_EMAIL Заголовок X-Email для прямых API-вызовов (локально на ВМ)
CATSCAN_BEARER_TOKEN Bearer-токен (среда CI, хранится в GitHub secrets)
CATSCAN_SESSION_COOKIE Cookie сессии OAuth2 Proxy (среда CI)

С ВМ-хоста используйте CATSCAN_CANARY_EMAIL с http://localhost:8000. Из CI (внешний доступ) используйте CATSCAN_BEARER_TOKEN или CATSCAN_SESSION_COOKIE с https://scan.rtb.cat/api.

Интерпретация результатов

Статус Значение
PASS Проверка пройдена, система работает нормально
FAIL Проверка не пройдена, требуется немедленное расследование
BLOCKED Проверка не может быть завершена из-за отсутствия зависимости (например, нет данных для этого байера, отсутствует эндпоинт). Не обязательно ошибка в коде.

Связанные разделы