Контекст

Сигнал полезен, когда помогает принять решение.

Выбрать сигнал для пользовательского симптома и отделить доступность API от качества модели.

Наблюдение начинается с вопроса

Сигнал полезен, когда помогает принять решение.

Аналогия: приборы на панели, журнал событий и карта поездки.

Четыре полезных сигнала

Задержка, поток запросов, ошибки и насыщение ресурсов.

Аналогия: скорость машины не показывает, сколько пассажиров не смогли сесть.

Инфраструктура и ML-качество

Исправный API может возвращать бесполезный прогноз.

Аналогия: исправность весов и полезность диеты — разные вопросы.

Команды и наблюдения

Ubuntu / Bash, lab

docker compose up -d
curl -sS http://127.0.0.1:8000/healthz
curl -sS http://127.0.0.1:8000/metrics
curl -i -H "Content-Type: application/json" -d '{"hours":-1}' http://127.0.0.1:8000/predict
docker compose logs --tail 10 app

Разбор результата

Есть healthz, текстовый metrics и структурированный лог отказа 400 с request_id.

Неверный вход — ожидаемая клиентская ошибка; не объявляем её падением инфраструктуры.

На macOS

HTTP, метрики и operational logs в контейнерном варианте одинаковы. Native macOS unified log — другой механизм и не требует journalctl.

curl -sS http://127.0.0.1:8000/metrics
docker compose logs --tail 10 app

Карта сигналов

1. Выберите пять симптомов: недоступен, медленный, 400, 500, неверная версия.
2. Для каждого назначьте полезную метрику или лог и проверочную команду.
3. Сгенерируйте нормальный и неверный запрос; сопоставьте ответ с журналом.
4. Укажите, какие вопросы о модели эти сигналы не решают.

Что должно получиться

Таблица симптом → сигнал → проверка → действие.

У каждого сигнала есть диагностическая цель; API и ML-качество не смешаны.

Ошибка для диагностики

Зелёный CPU используется как оправдание любых пользовательских проблем.

Основные выводы

1. Нет, healthz проверяет выбранные признаки исправности сервиса.
2. Чтобы сопоставлять события одного запроса без сохранения чувствительного содержимого.

После пары

Выбрать минимальный набор сигналов для собственного учебного ML-проекта.

Среднее и p95: увидеть медленный хвост

Контекст

Prometheus периодически читает endpoint метрик.

Поднять Prometheus, проверить target и построить rate и p95 из метрик StudyPulse.

Pull и временные ряды

Prometheus периодически читает endpoint метрик.

Аналогия: дежурный регулярно переписывает показания счётчика.

Counter, gauge, histogram

Тип метрики определяет корректную операцию.

Аналогия: одометр, спидометр и распределение длительностей поездок.

Labels и кардинальность

Каждая уникальная комбинация labels создаёт отдельный ряд.

Аналогия: отдельная папка на каждую категорию удобна, на каждую песчинку — нет.

Команды и наблюдения

Ubuntu / Bash, lab; PromQL в UI :9090

docker compose -f compose.yaml -f compose.monitoring.yaml up -d
python3 scripts/load.py --requests 60 --concurrency 3
# PromQL expressions
up{job="studypulse"}
sum(rate(studypulse_http_requests_total{route="/predict"}[1m]))
histogram_quantile(0.95, sum by (le) (rate(studypulse_request_duration_seconds_bucket{route="/predict"}[1m])))

Разбор результата

Target UP; rate появляется после нескольких scrape; p95 возвращается при наличии достаточных наблюдений.

Команды PromQL вводятся в интерфейсе Prometheus, не в Bash. Трафик ограничен своим localhost.

На macOS

Prometheus и PromQL одинаковы в контейнерном варианте. Если нужный учебный image не поддерживает архитектуру, проверьте manifest и используйте согласованную платформу/VM, а не случайную подмену версии.

docker compose -f compose.yaml -f compose.monitoring.yaml up -d
python3 scripts/load.py --requests 60 --concurrency 3

Из счётчика в график

1. Откройте Targets и проверьте app:8000.
2. Выполните ограниченную нагрузку; подождите 15–30 секунд.
3. Сравните значение counter, rate и p95 в PromQL.
4. Перезапустите app и объясните сброс счётчика без объявления отрицательной скорости.

Что должно получиться

Три запроса PromQL с интерпретацией, а не только скриншоты.

Единицы подписаны; request_id отсутствует в labels; up не подменяет smoke-test.

Ошибка для диагностики

Выражение rate без данных воспринимают как ошибку приложения.

Основные выводы

1. Он накопительный; нужна скорость изменения за окно.
2. Высокая кардинальность и ненужное раскрытие идентификаторов.

После пары

Подготовить два PromQL-запроса и объяснить их единицы и условия интерпретации.