Мониторинг ML-модели: Prometheus + Grafana

Живой дашборд Grafana: model-monitoring.185.79.138.118.nip.io — модель работает на сервере, поток идёт непрерывно, вход не нужен. Запись полного прогона по всему датасету: bestmark1.github.io/model-monitoring. Деплой: docs/deployment.md.

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

Результат

Прогон по всему потоку: 40 312 примеров (май 1996 — декабрь 1998), дообучение каждые 1000 размеченных примеров.

Модель	Accuracy по потоку
Дообучаемая (live)	74,8%
Первая версия без дообучения (frozen)	70,1%
Всегда угадывать частый класс	57,1%

Дообучение дало +4,7 п.п. Главная причина видна на панели дрейфа: в обучающих данных признаки рынка Виктории (vicprice, vicdemand, transfer) были константой, а в потоке появились реальные значения. Замороженная модель этого изменения не замечает, дообучаемая подстраивается.

Что сделано

Критерий задания	Где
Создана модель	SGDClassifier (логистическая регрессия) + StandardScaler, app/model.py
Метрики модели передаются в Prometheus	эндпоинт /metrics (prometheus_client), скрапинг каждые 5 с, prometheus/prometheus.yml
На дашборде отображены метрики модели	18 панелей, источник данных и дашборд подключаются автоматически (provisioning), grafana/
Модель можно дообучать	partial_fit на накопленных размеченных примерах: автоматически каждые RETRAIN_EVERY примеров или вручную POST /retrain; каждая версия сохраняется (model_v{N}.joblib)

Сверх задания:

• Контрольная модель. Первая версия модели работает рядом с дообучаемой на тех же запросах, поэтому выигрыш от дообучения измеряется, а не предполагается.
• Дрейф данных. PSI (Population Stability Index) по каждому признаку: последние 1000 запросов против обучающей выборки.
• Алерты Prometheus: падение accuracy, дообученная модель хуже исходной, сильный дрейф, сервис недоступен — prometheus/alerts.yml.
• Тесты (pytest), линтер (ruff), проверка конфига Prometheus через promtool в CI.

Как это устроено

simulator ──POST /predict──▶ model (FastAPI) ◀──scrape /metrics── Prometheus ◀── Grafana
          ──POST /feedback─▶   ├─ live-модель: дообучается каждые 1000 ответов
                               ├─ frozen v1: контрольная, не меняется
                               └─ PSI признаков, окно качества, версии модели

1. simulator проигрывает датасет в хронологическом порядке: отправляет признаки в /predict, затем истинный ответ в /feedback (на реальном рынке ответ известен через полчаса).
2. Сервис считает качество обеих моделей на скользящем окне из 500 примеров и складывает размеченные примеры в буфер.
3. Когда в буфере набирается 1000 примеров, модель дообучается (partial_fit), версия увеличивается, чекпоинт сохраняется в том models.
4. Prometheus забирает метрики каждые 5 секунд, Grafana строит по ним дашборд.

Метрики

Метрика	Тип	Что показывает
model_accuracy, model_f1, model_logloss {model="live"|"frozen"}	gauge	качество на последних 500 размеченных примерах
model_errors_total, model_labels_total	counter	ошибки и размеченные примеры (из них — доля ошибок за любой интервал)
model_predictions_total{predicted_class}, model_prediction_probability	counter, histogram	распределение прогнозов: сигнал, доступный до прихода ответов
model_version, model_retrains_total{trigger}, model_retrain_duration_seconds, model_trained_samples, model_retrain_buffer_size	gauge, counter, histogram	жизненный цикл дообучения
model_feature_psi{feature}	gauge	дрейф каждого признака
model_requests_total{endpoint}, model_prediction_latency_seconds	counter, histogram	нагрузка и задержка сервиса

Данные

Electricity (Elec2) — Harries, M. (1999), Splice-2 comparative evaluation: Electricity pricing. 45 312 получасовых записей рынка Нового Южного Уэльса (Австралия), май 1996 — декабрь 1998. Целевая переменная — выросла ли цена (UP/DOWN) относительно среднего за 24 часа. Классический датасет для моделей на потоке со сдвигом распределения. Первые 5000 записей идут на первичное обучение, остальные 40 312 — поток. Датасет скачивается при сборке Docker-образа, в репозитории не хранится.

Запуск

Нужен Docker.

git clone https://github.com/bestmark1/model-monitoring.git
cd model-monitoring
docker compose up -d --build

Сервис	Адрес
Grafana (дашборд открывается сразу, вход не нужен)	http://localhost:3000
Prometheus	http://localhost:9090
Модель: Swagger	http://localhost:8000/docs
Модель: метрики	http://localhost:8000/metrics

Первая точка на графиках качества появится через несколько секунд, первое дообучение — меньше чем через минуту.

Параметры (переменные окружения при docker compose up):

Переменная	По умолчанию	Смысл
RATE	20	запросов в секунду от симулятора
RETRAIN_EVERY	1000	дообучать после N размеченных примеров; 0 — только вручную
WINDOW	500	размер окна для метрик качества
LIMIT	0	остановить симулятор после N примеров; 0 — крутить поток по кругу
GRAFANA_ADMIN_PASSWORD	admin	пароль администратора Grafana

Ручное дообучение и проверка прогноза:

curl -X POST localhost:8000/retrain
curl -s localhost:8000/model

Обновить демо-страницу после своего прогона: python scripts/export_snapshot.py --minutes 15.

Разработка

python -m venv .venv && source .venv/bin/activate
pip install -r requirements-dev.txt
ruff check . && pytest -q
python scripts/build_dashboard.py   # дашборд описан кодом; JSON генерируется

Ограничения

• Состояние окна качества и буфера живёт в памяти одного процесса: сервис рассчитан на один экземпляр. Для нескольких реплик буфер и разметку нужно вынести во внешнее хранилище.
• Дообучение идёт синхронно внутри запроса /feedback; на этом датасете оно занимает миллисекунды, для тяжёлой модели его нужно вынести в фоновую задачу.
• Дообучение не проверяется перед выкаткой: контроль идёт постфактум, через сравнение с frozen и алерт ModelWorseThanFrozen.

Стек

Python · scikit-learn · FastAPI · prometheus_client · Prometheus · Grafana · Docker Compose · pytest · Ruff · GitHub Actions