---
title: "Эксплуатация: что мониторить в первую очередь"
description: "Красный метод мониторинг: что мониторить сервис в первую очередь — трафик, ошибки, латентность, насыщение; порядок внедрения, первые дашборды и алерты."
course: "Мониторинг Go с Prometheus: метрики, Grafana, алерты"
url: "https://golangmaster.ru/courses/prometheus/lessons/24-ekspluataciya/"
published: "2026-09-19"
updated: "2026-09-24"
minutes: 16
---

# Эксплуатация: что мониторить в первую очередь

*Курс «Мониторинг Go с Prometheus: метрики, Grafana, алерты», урок 24 из 25. ~16 минут. Обновлено 24.09.2026. Источник: https://golangmaster.ru/courses/prometheus/lessons/24-ekspluataciya/*

Красный метод мониторинга — короткий ответ на вопрос, что мониторить сервис в первую очередь: трафик, ошибки, латентность и насыщение. Остальные приборы имеют смысл, когда эти четыре уже отвечают за тридцать секунд, — в этом уроке раскладываем порядок внедрения для существующего сервиса.

Задача в тикете звучит безобидно: «добавьте сервису мониторинг». Через неделю в проекте двести метрик, четыре дашборда по сорок панелей и ни одного человека, который знает, где смотреть, когда сервис грустит. Ошибка не в лени, а в порядке: метрики добавлялись по списку из статьи, а не по вопросам дежурного. Эксплуатация переворачивает постановку: сначала вопрос — «сервис жив и справляется?», потом минимальный набор приборов, который отвечает за полминуты, и только потом роскошь детальных графиков. Весь курс шёл именно к этому порядку: типы метрик, лейблы, гистограммы и PromQL — инструменты, а этот урок — последовательность, в которой их выкатывают в живой сервис без паузы в работе.

### Красный метод мониторинга: четыре сигнала

Название идёт от RED — Rate, Errors, Duration, метода Тома Вилки, описывающего каждый запрос тремя числами: сколько идёт, сколько падает, как долго длится. Четвёртый сигнал добавляет книга Google SRE с её четырьмя золотыми сигналами: traffic, errors, latency, saturation — и это то, что в русскоязычных командах называют красным методом мониторинга целиком. Трафик — сколько работы приходит: RPS, сообщений в секунду, заказов в минуту. Ошибки — какая доля работы падает: пятьсотые статусы, невалидные результаты, отказы зависимостей. Латентность — как быстро отвечает сервис, причём интересен хвост: p99, а не средняя, как объяснял [урок про гистограммы](/courses/prometheus/lessons/07-histogram/). Насыщение — насколько сервис забит: глубина очереди, число обработчиков в работе, длина пула соединений. У родственного USE-метода Брендана Грегга та же логика, только для ресурсов: утилизация, насыщение, ошибки.

### Четыре сигнала и их серии

| Сигнал | Вопрос дежурного | Серия из курса |
| --- | --- | --- |
| Трафик | работа вообще приходит? | rate(http_requests_total) |
| Ошибки | какая доля падает? | rate(http_requests_total{status=~"5.."}) |
| Латентность | насколько медленно? | histogram_quantile по гистограмме |
| Насыщение | не забит ли сервис? | inflight, очередь, go_goroutines |

### Порядок внедрения: живой сервис за неделю

Порядок для существующего сервиса дисциплинирует и время, и объём. День первый — трафик: счётчик http_requests_total с лейблами route, method и status из [урока про HTTP-метрики](/courses/prometheus/lessons/09-http-metriki/) и одна панель суммарного RPS. День второй — ошибки: та же серия, срез по статусам, панель доли пятисотых. День третий — латентность: гистограмма по route с осмысленными бакетами и панель p50 и p99. День четвёртый — насыщение: датчики обработчиков в работе и очередей, плюс бесплатные go_- и process_-метрики из [одиннадцатого урока](/courses/prometheus/lessons/11-default-metriki/). Дальше — неделя молчания: команда смотрит на дашборд в будни и релизы, запоминает нормальные уровни, и только после этого пишутся алерты. Каждый шаг мелкий и обратимый, а через неделю у сервиса есть то, чего не давали двести метрик из тикета: ответ на вопрос «жив ли он» за один взгляд.

### Кейс: метрика молчала, сервис лежал

Сервис приёма платежей два часа отказывал половине заказов, и дежурство узнало об этом от поддержки. Приборная панель тем временем сияла: процессор на тридцати процентах, память в норме, диск спокойный — ресурсы машины выглядели образцово. Что происходило на деле: внутренняя очередь заказов переполнилась после замедления шлюза, новые заказы стали отваливаться по таймауту, а сервис честно съедал процессор на бесполезных ретраях. Метрика трафика молчала — заказы продолжали приходить, — и именно она не должна была молчать: следить требовалось за глубиной очереди и долей ошибок, то есть за насыщением домена, а не утилизацией железа. Вывод кейса длинной в один абзац: дашборд дежурного начинается с сигналов работы — трафик, ошибки, латентность, насыщение, — а графики CPU и памяти существуют, чтобы объяснить уже найденный симптом, а не найти его.

### Какие дашборды первыми

Первый дашборд — здоровье сервиса, шесть-восемь панелей: RPS суммарно, доля ошибок, p50 и p99, обработчики в работе, глубина очереди, горутины и память, статус readiness из [девятнадцатого урока](/courses/prometheus/lessons/19-zdorovie-servisa/). Критерий качества простой: дежурный отвечает на вопрос «что сломалось» за тридцать секунд без чтения документации. Второй дашборд — разрезы: трафик и ошибки по route из [шестого урока](/courses/prometheus/lessons/06-labels/) с переменной route вверху, как в [уроке про Grafana](/courses/prometheus/lessons/13-grafana-obzor/); он отвечает на вопрос «где именно». Третий — релизный: сравнение недель до и после выката, латентность и ошибки по версиям. Дальше панелей больше не нужно, пока не появился новый вопрос: дашборд — это справочник дежурного, а не архив графиков, и на вопрос «зачем эта панель» ответ обязан существовать.

### Насыщение: приборы, которые видят очередь

Насыщение — самый капризный из четырёх сигналов: у него нет универсальной серии, и прибор подбирается под архитектуру. Для веб-сервиса начинается с датчика обработчиков в работе — то, что рантайм знает сам: число одновременных обработок. Дальше по слоям: глубина очереди заказов в памяти или брокере, время, которое сообщение провело в очереди до обработки, занятость пула соединений к базе, число горутин как косвенный след зависших операций. Важно держать в голове различие: латентность запроса отвечает «как быстро обрабатываем», а время в очереди — «как долго ждём», и растёт обычно первым. CPU и память в этот список не входят: утилизация процессора ничего не говорит о забитости до тех пор, пока не упрётся в потолок, — как раз потому, что кейс платежей лежал при тридцати процентах загрузки. Выбор приборов насыщения — это разговор с архитектором на полчаса, потраченный впрок, потому что именно эти панели останавливают инцидент до таймаутов.

Красный метод — первый экран; вторая волна приборов приходит не из статей, а из разборов. Каждый настоящий инцидент заканчивается вопросом: какая серия предупредила бы об этом за десять минут до поддержки, — и ответ превращается в одну новую метрику или панель. Промахи кэша после затычки базы, латентность вызова внешнего шлюза, глубина отставания потребителя очереди, счётчик таймаутов downstream — так по одному за квартал собирается дашборд, который знает ваш сервис лучше любых рекомендаций. Обратное тоже верно: список «полезно собирать всё» из интернета обычно пополняется без инцидентов, а потому без сценариев действия. Спорная граница: метрика без алерта и без читателя всё же может остаться на стенде, где она используется для исследования, — в прод её пропускают только после первого вопроса, который она закрыла. Через полгода такого режима у сервиса остаётся приборная панель, в которой каждая строка помнит свой инцидент, — лучший отбор, известный эксплуатации.

### Минимальный набор красного метода

```go
var (
        httpRequests = prometheus.NewCounterVec(
                prometheus.CounterOpts{
                        Name: "http_requests_total",
                        Help: "Запросы по маршруту, методу и статусу",
                },
                []string{"route", "method", "status"},
        )
        httpDuration = prometheus.NewHistogramVec(
                prometheus.HistogramOpts{
                        Name:    "http_request_duration_seconds",
                        Help:    "Латентность запросов",
                        Buckets: []float64{.01, .025, .05, .1, .25, .5, 1, 2.5},
                },
                []string{"route", "method"},
        )
        inflight = prometheus.NewGauge(prometheus.GaugeOpts{
                Name: "http_inflight_requests",
                Help: "Обработчики в работе",
        })
)

prometheus.MustRegister(httpRequests, httpDuration, inflight)
```

Три объявления закрывают три сигнала из четырёх: счётчик отвечает за трафик и ошибки разом — лейбл status позволяет посчитать долю падений, гистограмма за латентность хвоста. Четвёртый сигнал, насыщение, начинается с датчика обработчиков в работе и растёт в очередь домена. Бакеты выбраны под веб-запросы: от десяти миллисекунд до двух с половиной секунд, с границами вокруг обычных бюджетов.

### Алерты после, а не вместе с дашбордом

Соблазн поставить алерты в первый же день велик, и он ошибочен: без недели наблюдения пороги пишутся из головы, и дежурство учится игнорировать канал. Порядок такой: дашборд, неделя нормальных уровней, затем алерты на то, что уже видели глазами. Первые три алерта типовые. Доля ошибок выше одного процента в течение пяти минут — симптом, который всегда требует действия. p99 выше согласованного бюджета, скажем секунды, в течение десяти минут — пользователи заметили раньше дежурного. И переключатель мёртвой зоны, dead man's switch: постоянное правило, которое горит всегда, а тишину ловит внешний канал — так обнаруживается пропажа самого мониторинга, о чём писал [урок про алерты](/courses/prometheus/lessons/14-alerts-obzor/). Всё остальное — алерты на память, горутины, скрейп — добавляется, когда найден их сценарий действия, а не из солидности.

> **Типичная ошибка: соберём всё, разберёмся потом.** Команда включает экспорт всех метрик подряд — сто серий на хост, каждая с лейблом окружения и имени узла, — и через месяц Prometheus ест гигабайты, а дашборд из сорока панелей никто не открывал. Метрика без вопроса, на который она отвечает, — это расход диска и время скрейпа; кардинальность из [семнадцатого урока](/courses/prometheus/lessons/17-kardinalnost/) усугубляет счёт. Граница честная: исследовательский сбор всего оправдан на стенде и на ограниченный срок, когда ищешь, чем болеет сервис, — но в прод попадает только то, у чего есть читатель и вопрос.

### Проверка: четыре сигнала

**Вопрос:** Какой набор сигналов задаёт красный метод в широком смысле?

- ✅ Трафик, ошибки, латентность, насыщение
- CPU, память, диск, сеть
- Логи, трейсы, метрики, события
- Доступность, надёжность, безопасность, стоимость

Красный метод в широком смысле повторяет четыре золотых сигнала SRE: трафик, ошибки, латентность и насыщение. Ресурсы машины — следующий слой объяснения, три вида телеметрии — карта видов данных, а не сигналов одного сервиса.

### Проверка: первый шаг в живом сервисе

**Вопрос:** С чего начинают мониторинг существующего сервиса без метрик?

- ✅ Счётчик запросов с лейблами route и status
- Экспорт всех метрик зависимостей
- Алерты на память и CPU
- Дашборд из сорока панелей

Первый шаг — трафик: счётчик с маршрутом и статусом сразу даёт два сигнала, и на нём строятся первые панели и будущий алерт доли ошибок. Алерты без недели наблюдения дают ложные срабатывания, а объёмный сбор — расход без читателя.

### Доля ошибок на панели

```go
# RPS ошибок
sum(rate(http_requests_total{status=~"5.."}[5m]))  // 20
# RPS всего
sum(rate(http_requests_total[5m]))                 // 500
```

**Что выведет программа?**

- ✅ Доля 4%: алерт на пороге 1% обязан гореть
- Доля 0.04%: доля и проценты перепутаны местами
- Доля 40%: ошибки умножены на десять
- Доля 96%: посчитали долю успешных

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

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

Соберите запрос девяносто девятого перцентиля.

```go
histogram_quantile(0.99,
  sum by (___) (rate(___[5m])))
```

Подсказка: Гистограмма приходит в Prometheus сериями бакетов с лейблом границы — le, а квантиль считается по суффиксу _bucket.

Правильные ответы в пропусках: `le`, `http_request_duration_seconds_bucket`

### Внедрение мониторинга в живом сервисе

Расставьте шаги порядка внедрения.

Правильный порядок строк:

1. `Обернуть хендлеры счётчиком запросов с лейблами route и status`
2. `Добавить гистограмму латентности с бакетами под веб-запросы`
3. `Выставить датчики насыщения: обработчики в работе и глубина очереди`
4. `Собрать дашборд здоровья из шести-восьми панелей красного метода`
5. `Неделю наблюдать нормальные уровни на буднях и релизах`
6. `Поставить первые алерты: доля ошибок, p99 и dead man's switch`

### Карточки: эксплуатация и красный метод

- **RED** — Rate, Errors, Duration — три числа на каждый запрос; четвёртый сигнал насыщения добавляют четыре золотых сигнала SRE.
- **Насыщение** — Насколько сервис забит: очередь, обработчики в работе, пул соединений. Симптом при зелёном CPU — кейс платежей.
- **Дашборд дежурного** — Шесть-восемь панелей здоровья: RPS, доля ошибок, p50 и p99, насыщение, память, readiness. Ответ за тридцать секунд.
- **Dead man's switch** — Правило, которое горит всегда, и внешний канал, ловящий тишину: обнаруживает пропажу самого мониторинга и сервисов.
- **Порядок внедрения** — Трафик, ошибки, латентность, насыщение, дашборд, неделя наблюдения, алерты. Каждый шаг мелкий и обратимый.

> **Проверка на локальном Go.** Песочница сайта исполняет только fmt, strings, strconv, math, sort, errors и time, поэтому порядок внедрения проверяется локально: соберите три метрики из этого урока, поднимите сервис из [третьего урока](/courses/prometheus/lessons/03-ustanovka-client-golang/) и сгенерируйте ошибки таймаутом в зависимости — доля пятисотых на панели обязана вырасти за минуту.

Эксплуатационный порядок собирает курс в последовательность, а [итоговый проект](/courses/prometheus/lessons/25-itogovyj-proekt-prom/) — в один файл: там три метрики из этого урока обрастут бизнес-счётчиком и перечнем панелей с тремя алертами. Запросы для панелей — в [уроке про PromQL](/courses/prometheus/lessons/12-promql-basics/), переменные дашборда — в [уроке про Grafana](/courses/prometheus/lessons/13-grafana-obzor/), порог кардинальности — в [семнадцатом уроке](/courses/prometheus/lessons/17-kardinalnost/). Полный маршрут — на [странице Prometheus](/courses/prometheus/); про порядок middleware, который держит метрики и пробы вне бизнес-логики, — в [уроке chi про слои](/courses/chi/lessons/18-middleware-poryadok/).

## Коротко: что запомнить

- Красный метод в широком смысле — четыре сигнала: трафик, ошибки, латентность, насыщение.
- Порядок внедрения: счётчик запросов, гистограмма, насыщение, дашборд, неделя наблюдения, алерты.
- Дашборд дежурного — шесть-восемь панелей и ответ за тридцать секунд; разрезы и релизы — вторые дашборды.
- Насыщение домена (очередь, обработчики в работе) важнее утилизации железа: CPU может быть зелёным, пока заказы стоят.
- Алерты пишутся после недели наблюдения: доля ошибок, p99 выше бюджета и dead man's switch.
- Метрика без вопроса — расход диска; исследовательский сбор всего живёт на стенде и временно.
- Ресурсы машины объясняют найденный симптом, а не находят его.

## Домашнее задание

Возьмите живой или учебный сервис и проведите его по порядку внедрения: за четыре шага добавьте счётчик с route и status, гистограмму, датчик насыщения и go_-метрики, затем соберите дашборд здоровья из шести панелей. Неделю ведите записи нормальных уровней, после чего напишите три алерта из урока и прогоните каждый по сценарию: какие действия он требует. В конце удалите из проекта одну метрику, у которой нет ни читателя, ни вопроса.

## Вопросы и ответы по уроку

### Чем красный метод отличается от USE?

Направлением взгляда: RED и четыре золотых сигнала смотрят на работу сервиса — сколько пришло, сколько упало, как быстро и насколько забито; USE у Брендана Грегга смотрит на ресурсы — утилизация, насыщение, ошибки процессора, памяти, диска. Дежурство начинает с работы сервиса, ресурсы подключает при объяснении симптома — поэтому красный метод задаёт первый слой панелей.

### Почему нельзя ставить алерты сразу?

Порог без наблюдения — это догадка, и она обычно либо будит дежурного по мелочи, либо спит на реальных проблемах. Неделя дашборда даёт нормальные уровни по будням и релизам, после чего порог пишется из факта. Исключение — dead man's switch: ему порог не нужен, он горит всегда и ловит тишину.

### Сколько панелей должно быть на дашборде здоровья?

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