05 · Observability5.1 · Метрики5.1.1лёгкий

Модель метрик: 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.

Официальные материалы