Метод USE (Utilization, Saturation, Errors)

Метод USE (Утилизация, Насыщенность, Ошибки) предложен Брэнданом Греггом как способ системно проверять “здоровье” ресурсов инфраструктуры (CPU, память, диск, сеть и пр.) (brendangregg.com)

Идея проста: для каждого ресурса отслеживай три аспекта:

• Utilization (утилизация) — сколько времени ресурс занят полезной работой (в процентах).
• Saturation (насыщенность) — имеются ли очереди задач, ждут ли они доступ к ресурсу.
• Errors (ошибки) — сколько операций завершилось с ошибкой или сбоем.

Этот подход помогает быстро выявлять “узкие места” на уровне оборудования или базовых систем, даже когда ты не знаешь заранее, где может быть проблема. (brendangregg.com)

USE особенно удобен как первый шаг при расследовании проблем производительности: просматриваешь ресурсы, видишь, где есть деградация, и дальше спускаешься в детали. (brendangregg.com)

Метод RED (Rate, Errors, Duration)

Метод RED (Частота запросов / Ошибки / Длительность) разработан Томом Вилки (Tom Wilkie) и ориентирован не на “железо”, а на пользовательский опыт и поведение сервисов. (Weaveworks Blog, InfoWorld)

• Rate — сколько запросов в секунду (напр., HTTP-запросы).
• Errors — сколько из них завершились неудачей.
• Duration (длительность) — сколько времени занимает обработка запроса (latency).

RED отлично подходит для алертинга и мониторинга уровня сервисов, потому что показывает, как пользователи видят работу системы. (Grafana Labs)

Четыре “Золотых сигнала” (Four Golden Signals)

В книге Google SRE (раздел про мониторинг распределённых систем) выделяются четыре основных сигнала, которые стоит отслеживать в первую очередь: latency, traffic, errors, saturation (Google SRE). Эти сигналы — отличный “минимум”, если у тебя мало времени или ресурсов:

• Latency (задержка) — сколько занимает ответ системы.
• Traffic (трафик) — нагрузка, сколько запросов или транзакций проходит через сервис.
• Errors (ошибки) — доля неудачных запросов.
• Saturation (насыщенность) — насколько ресурс загружен и есть ли “затор” (очередь).

Этот подход во многом пересекается с RED, но акцентирует внимание на том, что насыщенность тоже важна — особенно при высоких нагрузках. (Google SRE)

Бизнес-метрики: пользователи, конверсии, активность

Помимо технических методологий мониторинга, важно отслеживать бизнес-показатели, которые помогают понять, как техническое состояние системы влияет на бизнес-результаты:

• Users (пользователи) — сколько людей пользуется сервисом.
• Conversions (конверсии) — сколько из них совершили целевое действие (покупка, регистрация и т.д.).
• Activity (активность) — как часто и как активно пользователи взаимодействуют с продуктом (например, логины, сессии, просмотры).

Эти метрики позволяют связать технические показатели с бизнес-результатами: если видишь ухудшения в бизнес-показателях, ты можешь “спуститься” к RED/USE, чтобы найти техническую причину.

Пятиуровневая модель дашборда

Чтобы удовлетворить потребности разных ролей в компании (руководство, DevOps, SRE, аналитика), можно использовать модель дашбордов из пяти уровней:

Уровень 1: Верхнеуровневый (Executive / бизнес)

Показывает ключевые бизнес-метрики и общее «здоровье» сервисов: рост пользователей, доходы, количество транзакций.

Уровень 2: Событийный (Event / инфраструктура)

Мониторинг событий инфраструктуры, серверов, сети, баз данных, интеграций — всё, что может сигнализировать о сбоях.

Уровень 3: Карта сервисов / связей

Графическое представление взаимосвязей между компонентами системы — какие сервисы зависят друг от друга, как данные перетекают через систему.

Уровень 4: Агрегированный дашборд с переходом вниз

Основной рабочий дашборд для инженеров: “светофоры”, статусные панели и возможность кликнуть и углубиться в метрики конкретного компонента.

Уровень 5: Сырые данные

Трейсы (traces), логи, события в “сыром” виде — это самые детализированные данные, к которым переходят при глубокой диагностике.

Примеры дашбордов по уровням

Верхнеуровневый дашборд

Представляет ключевые бизнес-метрики и агрегированные показатели, показывая общее состояние системы. Например: общее число активных пользователей, коэффициенты конверсий, рост транзакций и т.д.

Событийный дашборд

Отображает тревоги, события инфраструктуры, сбои в интеграциях, доступность сервисов. Часто это набор индикаторов “ок / предупреждение / критика”.

Карта сервисов / взаимосвязей

Показывает, как сервисы связаны между собой, какие зависимости, через какие коммуникации идут данные. Полезен для быстрого понимания контекста проблемы.

Агрегированная панель с переходом вниз

Основной “рабочий” дашборд, где видно сводные метрики по компонентам (CPU, сеть, БД и т.д.), с порогами (светофоры). Можно щёлкнуть на компонент и перейти к отдельному дашборду с деталями.

Сырые данные

Представление логов, трасс, событий, которые позволяют глубоко погрузиться в причину проблемы, увидеть порядок операций, трассы запросов и прочее.

Примеры панелей

Панель системного мониторинга

Панель прикладного мониторинга

Пример продуктовой панели

• DAU (Daily Active Users) — количество уникальных пользователей в день
• WAU (Weekly Active Users) — за неделю
• MAU (Monthly Active Users) — за месяц
• PCU (Peak Concurrent Users) — пиковое число одновременно активных
• ACU (Average Concurrent Users) — среднее число одновременно активных

Также можно смотреть коэффициент “прилипания” — DAU/WAU, DAU/MAU и др.

Как сочетать методы (USE, RED, бизнес-метрики)

• Используй USE для низкоуровневого анализа инфраструктуры (CPU, диск, сеть).
• RED / Four Golden Signals применяй к сервисам, которые обслуживают запросы пользователей.
• Бизнес-метрики помогают смотреть на показатели продукта, ставить приоритеты.
• Когда видишь проблему в бизнес-метриках или RED, “спускайся” к USE, чтобы найти истоки (узкие места инфраструктуры).

Ресурсы и ссылки

Основные источники

1. The USE Method — Brendan Gregg (официальный сайт)
2. Monitoring Distributed Systems — Google SRE (Four Golden Signals)
3. Performance Analysis Methodology — Brendan Gregg
4. Google Site Reliability Engineering Book — раздел о мониторинге распределённых систем
5. The RED Method: key metrics for microservices architecture — introduced by Tom Wilkie
6. The RED method: A new strategy for monitoring microservices — InfoWorld
7. The RED Method: How to Instrument Your Services — Grafana Labs

Совет: Начинай с Four Golden Signals или RED для сервисов, затем добавляй USE для инфраструктуры. Это даст максимальное покрытие при минимальных усилиях.

📱 Telegram: @DevITWay
🌐 Сайт: devopsway.ru