5.1.1 · блок 5
Модель метрик: USE и RED
Модель метрик: USE и RED
Зачем это нужно
«Сервис лежит» — слишком грубо. SRE и MLE нужны измеримые сигналы: utilization CPU, latency p99, error rate, saturation queue. Без общей модели метрик каждый рисует свои графики, алерты шумят, а root cause ищут вслепую.
Для ML inference те же принципы, плюс позже — метрики качества модели (урок 5.3.4). Начинаем с инфраструктурной observability: USE и RED.
Основные идеи
Golden signals (Google SRE). Latency, traffic, errors, saturation — четыре универсальных измерения. USE и RED — частные шаблоны, как их применять к ресурсам и сервисам.
USE — для ресурсов (CPU, GPU, disk, network, memory).
| Буква | Вопрос | Пример |
|-------|--------|--------|
| **U** Utilization | Насколько занят ресурс? | CPU 80%, GPU SM 90% |
| **S** Saturation | Есть очередь / ожидание? | GPU jobs queued, disk iowait |
| **E** Errors | Ошибки на уровне ресурса? | GPU ECC errors, disk read fail |
Применяют к узлам, GPU, дискам — не к HTTP API напрямую.
RED — для сервисов (request-driven, sync API).
| Буква | Вопрос | Пример |
|-------|--------|--------|
| **R** Rate | Сколько запросов в секунду? | 1200 RPS на `/predict` |
| **E** Errors | Доля failed requests? | 5xx / total, timeout |
| **D** Duration | Сколько длится запрос? | p50, p95, p99 latency |
Идеально для REST/gRPC inference за Istio Ingress.
ML inference mapping.
- Rate — predictions/sec; batch size affects duration.
- Errors — HTTP 5xx, 4xx validation, model load fail.
- Duration — end-to-end including feature fetch (если in-process — один span позже).
- Utilization — GPU memory used, batch queue depth in Triton/TorchServe.
- Saturation — HPA at max replicas, request queue length.
Histograms vs averages. Средняя latency обманывает. Prometheus histogram buckets → p95/p99 в Grafana. SLO почти всегда на percentile, не mean.
Labels ( cardinality caution ). Полезно: service, namespace, model_version, route. Опасно: user_id, request_id as metric label — взрыв cardinality.
USE vs RED — когда что.
- Диагностика «GPU bottleneck» → USE on GPU nodes.
- Диагностика «клиенты видят тормоза» → RED on inference Service.
- Оба нужны на dashboard ML platform.
Как это выглядит на практике
Dashboard «Churn Scoring» (Grafana):
Row RED — Service
rate(http_requests_total{service="churn-serving",status=~"5.."}[5m]) / rate(http_requests_total{service="churn-serving"}[5m])— error ratio.histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))— p95 latency.sum(rate(http_requests_total[5m]))— RPS.
Row USE — GPU node
- DCGM
DCGM_FI_DEV_GPU_UTIL— utilization. DCGM_FI_DEV_MEM_COPY_UTIL— memory bandwidth saturation proxy.- GPU XID errors — errors.
Alert example: p95 latency > 200 ms AND RPS stable → likely model/input issue or CPU; p95 up AND GPU util 99% → scale GPU or optimize batch.
Istio добавляет RED без изменения кода приложения (sidecar metrics) — урок 5.1.2.
Что сделать после занятия
- [ ] Для учебного inference API выпишите 3 RED и 2 USE метрики с именами (conceptual).
- [ ] Объясните, почему p99 важнее average для SLA online scoring.
- [ ] Найдите одну метрику с высокой cardinality, которую не стоит хранить в Prometheus.