Перейти до змісту

Розділ 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 Використання диска VM

Скрипти перевірки стану під час роботи

Ці скрипти є операційною основою для наскрізної перевірки працездатності системи.

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
  • Життєвий цикл пропозицій
  • Пробний запуск відкату

Кожна перевірка повертає 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"

Автентифікація канаркових перевірок

Скрипти перевірки стану автентифікуються за допомогою змінних середовища:

Змінна Призначення
CATSCAN_CANARY_EMAIL Заголовок X-Email для прямих викликів API (локально на VM)
CATSCAN_BEARER_TOKEN Bearer-токен (середовище CI, зберігається у GitHub secrets)
CATSCAN_SESSION_COOKIE Сесійний cookie OAuth2 Proxy (середовище CI)

З хоста VM використовуйте CATSCAN_CANARY_EMAIL з http://localhost:8000. Із CI (зовнішній доступ) використовуйте CATSCAN_BEARER_TOKEN або CATSCAN_SESSION_COOKIE з https://scan.rtb.cat/api.

Інтерпретація результатів

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

Пов'язані розділи