Пара 19: Наблюдаемость: метрики, логи и трассировка

90 минут · 3 курс, ML.

Содержание и результат

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

План занятия

0–10: контекст и исходная задача. 10–40: устройство и механизмы. 40–55: демонстрация команд. 55–80: лабораторная работа. 80–90: разбор результата и фиксация исправлений.

Практика выполняется в своей учебной папке и на localhost. Подготовка окружения описана в lab/README.md.

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

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

Мониторинг следит за заранее выбранными показателями и условиями. Наблюдаемость помогает объяснять внутреннее поведение по внешним сигналам. Метрики удобны для тенденций и агрегатов, логи — для конкретных событий, трассировка — для пути запроса через компоненты. Для одного маленького сервиса полный tracing-stack избыточен; добавляем request_id и показываем идею на схеме. Вместо «соберём всё» задаём вопросы: доступен ли predict, сколько ошибочных запросов, выросло ли время ответа? Каждый сигнал должен иметь понятный источник и действие при отклонении.

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

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

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

Latency показывает время ответа, traffic — объём запросов, errors — долю неуспешных ответов, saturation — приближение к пределу ресурсов. Одной CPU-метрики недостаточно: сервис может ждать диск или внешнюю сеть. Среднее время может скрывать медленный хвост, поэтому позже исследуем p95. Ошибки клиента и ошибки сервера имеют разный смысл, их не смешиваем без объяснения. Метрики инфраструктуры дополняют пользовательский путь, но не заменяют его. Просим студентов предложить причину медленного API при низком CPU: очередь, I/O, ожидание зависимости.

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

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

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

На этом курсе проверяем доступность, контракт, задержку и версию артефакта. В реальном ML-проекте качество модели, распределение входов и дрейф данных — отдельная область ответственности. Нельзя выводить точность модели из 200 OK или из того, что контейнер healthy. Не собираем сырые персональные входы для «наблюдаемости». Полезный инфраструктурный сигнал — версия модели в healthz и журнале; он помогает сопоставить изменение поведения с выпуском. StudyPulse возвращает синтетическую оценку, поэтому не обсуждаем её как научный показатель.

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

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

Окружение: 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 используется как оправдание любых пользовательских проблем.

Решение и диагностика

Недоступность: внешний curl и up от Prometheus. Медленно: histogram времени, нагрузка и ресурсы. 400: контракт входа и лог request_id. 500: исключение, версия и зависимость. Неверная версия: healthz, image ID, checksum артефакта. Количество 400 может быть полезно для UX, но не всегда включается в доступность сервиса как ошибка сервера.

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

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

Самостоятельная работа

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

Источники

• Документация
• Документация