Пара 21: Grafana, SLI, SLO и осмысленные алерты

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

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

Создать небольшой dashboard и объяснить порог оповещения в терминах пользователя.

План занятия

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

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

Dashboard — ответ на вопросы

Сначала пользовательский путь, затем объясняющие ресурсы.

Предоставленный dashboard показывает доступность target, скорость predict, долю 5xx и p95. Grafana запрашивает Prometheus datasource по внутреннему адресу http://prometheus:9090; браузер открывает Grafana через localhost:3000. Один график должен иметь понятное название, единицу и окно времени. Не заполняем экран CPU всех машин ради красоты. Отсутствие данных обозначаем как отсутствие данных, а не ноль. Студент должен объяснить, что бы он сделал после каждого наблюдения. Dashboard без действий становится декоративным экраном.

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

SLI и SLO

Измерение и целевое качество формулируются отдельно.

SLI — измеряемый показатель услуги, например доля успешных predict из валидных запросов. SLO — целевой уровень на определённом окне, например учебная гипотеза 99% за неделю; это не обещание фактического результата курса. SLA — внешнее соглашение с последствиями, его не моделируем как просто красивую цель. Определите, какие запросы входят в знаменатель, какие ошибки считаются и откуда берётся наблюдение. Внутренний scrape не доказывает доступность из браузера студента. Error budget — допустимая доля неуспеха относительно выбранного SLO, а не разрешение игнорировать сбои.

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

Алерт должен вести к действию

Уведомление требует симптома, длительности и инструкции.

Учебное правило StudyPulseDown срабатывает, когда up=0 держится 30 секунд. for уменьшает реакцию на одиночные краткие провалы. Это демонстрационный порог, в реальности его выбирают по последствиям и времени реакции. В annotation указываем симптом и ссылку на runbook. У нас показаны состояния inactive, pending, firing в Prometheus; внешняя отправка в мессенджер не подключена и уведомлений людям не создаёт. Для рабочих оповещений понадобятся Alertmanager, маршрутизация и дежурство. Алерт на CPU без понятного пользовательского риска часто создаёт шум.

Аналогия: пожарная сигнализация должна вести к плану эвакуации, а не просто пищать.

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

Окружение: Ubuntu / Bash, lab; затем браузер.

docker compose -f compose.yaml -f compose.monitoring.yaml up -d
# Open http://127.0.0.1:3000 and the provisioned StudyPulse dashboard
python3 scripts/load.py --requests 80 --concurrency 4
docker compose stop app
# Wait for at least 30 seconds plus scrape/rule evaluation
docker compose start app

Anonymous Viewer включён только для локального учебного Grafana. Не публикуйте этот compose в интернет. Пароль администратора задаётся локально через GRAFANA_PASSWORD.

Ожидаемый результат: Dashboard меняется; в Prometheus /alerts видны pending и firing, после запуска — восстановление.

Вариант для macOS

Grafana, SLI/SLO и алерт одинаковы. Браузер открывает localhost:3000/9090, внутренний datasource остаётся prometheus:9090.

docker compose stop app
docker compose start app
bash scripts/smoke.sh

Практика: Алерт с инструкцией

  1. Объясните четыре панели dashboard и единицы.
  2. Сформулируйте SLI predict с точным числителем/знаменателем.
  3. Остановите только app; наблюдайте переход алерта, затем восстановите.
  4. Напишите runbook из проверки target, процесса, журнала, исправления и smoke.

Результат: Определение SLI/SLO и runbook с проверенным восстановлением.

Проверка: Не обещаны внешние уведомления; порог назван учебным; отсутствие данных не объявлено успехом.

Неисправность для разбора: Dashboard показывает внутреннюю доступность, а её принимают за проверку пользовательской сети.

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

После остановки app target станет DOWN; rule с for=30s пройдёт pending. Реальный момент firing зависит от scrape и evaluation interval. Для восстановления docker compose start app, затем curl healthz и bash scripts/smoke.sh. Grafana password находится только в собственном lab/.env и не коммитится. Runbook не должен начинаться с удаления volume или переустановки всей системы.

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

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

Подготовить runbook для одного пользовательского симптома собственного проекта.

Источники