Golden Signals vs RED vs USE. Какие методики мониторинга выбрать

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

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

Для этого существуют несколько популярных методик:

• Golden Signals — мониторинг с точки зрения пользователя;
• RED Method — анализ состояния сервисов и API;
• USE Method — контроль инфраструктурных ресурсов.

Эти подходы не конкурируют между собой. На практике они дополняют друг друга.

Почему нельзя мониторить всё подряд

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

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

• нормальный рост нагрузки;
• фоновая задача;
• обработка очереди;
• временный пик.

Поэтому хороший мониторинг отвечает не на вопрос:

Какие показатели мы можем собрать?

А на вопрос:

Как понять, что сервис работает плохо?

Golden Signals: взгляд глазами пользователя

Методика Golden Signals описана в книге Site Reliability Engineering, где инженеры Google обобщили свой опыт эксплуатации крупных систем. Она предлагает оценивать сервис через четыре основных показателя.

Latency — задержка. Показывает, сколько времени занимает выполнение операции: время ответа API, скорость загрузки страницы, задержка обработки задачи. Обычно используют не среднее значение, а перцентили — p95 и p99. Среднее время может скрывать проблемы: если 99% запросов выполняются быстро, а 1% занимает 10 секунд, пользователи все равно столкнутся с задержками.

Так выглядит запрос p95 в Prometheus:

histogram_quantile(0.95,
  sum(rate(http_request_duration_seconds_bucket[5m])) by (le)
)

Traffic — нагрузка. Показывает объем работы системы: запросы в секунду, количество операций, сообщения в очереди. Рост нагрузки сам по себе не является проблемой. Важно понимать, справляется ли система с ней.

Errors — ошибки. Показывает количество неуспешных операций: HTTP 500, ошибки базы данных, таймауты, исключения приложения. Лучше анализировать процент ошибок, а не только абсолютное количество. Например, 100 ошибок при миллионе запросов могут быть менее критичными, чем 50 ошибок при тысяче запросов.

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

Golden Signals хорошо подходят для веб-приложений, API и пользовательских сервисов.

RED Method: мониторинг сервисов

Методику RED предложил Том Уилки, сооснователь Weaveworks и один из мейнтейнеров Prometheus. По сути это адаптация Golden Signals под микросервисы: из четырех сигналов остаются три, которые можно измерить одинаково для любого сервиса.

Название состоит из трех показателей: Rate, Errors и Duration.

Rate — количество запросов. Показывает интенсивность работы сервиса:

sum(rate(http_requests_total[5m])) by (service)

Резкое падение количества запросов может означать проблемы с приложением или балансировщиком — трафик просто перестал доходить до сервиса.

Errors — ошибки. Доля неуспешных ответов от общего числа запросов:

sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

Ошибки можно анализировать по endpoint, по версии приложения, по типу операции.

Duration — время выполнения. Показывает производительность сервиса. Здесь работает тот же принцип, что и с Latency в Golden Signals: смотрите на перцентили, а не на среднее.

Сила RED в единообразии: когда все сервисы отдают одни и те же три метрики, дашборд для нового сервиса не нужно придумывать заново, а при деградации сразу видно, какой компонент цепочки её вызывает.

USE Method: мониторинг инфраструктуры

Методику USE сформулировал Брендан Грегг, инженер по производительности, известный по работе в Netflix и Intel. Она создавалась как чек-лист для поиска узких мест: пройтись по каждому ресурсу системы и проверить три показателя — Utilization, Saturation и Errors.

Utilization — использование. Насколько активно используется ресурс. Например, загрузка CPU по данным node_exporter:

1 - avg(rate(node_cpu_seconds_total{mode="idle"}[5m]))

Saturation — перегрузка. Наличие очередей и ожидания: load average выше числа ядер, очередь дисковых операций, свопинг из-за нехватки памяти. Именно saturation часто помогает найти настоящую причину проблем: ресурс может быть загружен на 80% и работать нормально, но как только появляется очередь — время ответа растет для всех.

Errors — ошибки. Сбои оборудования: ошибки дисков, сетевые проблемы, ошибки памяти.

USE применяется для серверов, виртуальных машин, Kubernetes nodes и сетевого оборудования.

Golden Signals vs RED vs USE

Методики работают на разных уровнях:

Например:

Пользователь сообщает, что сайт стал медленным.

Golden Signals показывает:

Latency выросла с 200 мс до 3 секунд

RED помогает найти сервис:

checkout-api:
Duration ↑
Errors ↑

USE показывает причину:

Database server:
CPU 95%
Disk IO saturation 100%

Так можно пройти путь от симптома к конкретной причине.

Типичные ошибки при внедрении

Алерты на utilization вместо saturation. Самая частая ошибка — оповещение «CPU выше 80%». Процессор, загруженный на 90%, может обслуживать пользователей без деградации, а система с CPU 60% — стоять в очереди на диске. Алертить стоит на симптомы (задержка, ошибки), а utilization использовать для диагностики.

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

Абсолютные числа вместо долей. «500 ошибок за час» ничего не значит без контекста трафика. Считайте процент ошибок от общего числа запросов.

Алерт на каждую метрику. Когда оповещений слишком много, команда перестает на них реагировать — это называют alert fatigue. Начните с малого: 3–4 алерта на сигналы, которые напрямую отражают опыт пользователя.

Мониторинг только изнутри. Prometheus и Grafana видят систему изнутри периметра. Если упала сеть до пользователей, истек TLS-сертификат или ошибся DNS — все внутренние дашборды останутся зелеными, а сайт будет недоступен. Поэтому внутренние метрики дополняют внешними проверками.

Какую методику выбрать

На практике лучше использовать комбинацию подходов.

Для инфраструктуры — USE: CPU, память, диски, сеть. Классический стек — Prometheus, node_exporter и Grafana.

Для приложений — RED: количество запросов, ошибки, время ответа.

Для пользовательских сервисов — Golden Signals: задержка, нагрузка, ошибки, насыщение.

При этом два из четырех золотых сигналов — задержку и ошибки — проще всего начать измерять снаружи, так же, как их видит пользователь. Для этого не нужен Prometheus: внешний мониторинг вроде Statuser проверяет сайт или API из разных регионов, фиксирует время ответа и ошибки и уведомляет, когда сервис становится недоступен. Это хорошая отправная точка, если полноценная система метрик еще не построена, и обязательная страховка, если она уже есть.

Заключение

Хороший мониторинг — это не максимальное количество графиков. Это система, которая помогает быстро ответить:

1. Есть ли проблема?
2. Где находится причина?
3. Что нужно сделать?

Golden Signals показывают влияние проблемы на пользователей, RED помогает найти неисправный сервис, а USE объясняет ограничения инфраструктуры.

Вместе эти методики позволяют построить полноценную систему наблюдаемости, где метрики не просто собираются, а помогают принимать решения.