Базовые концепции мониторинга, типы метрик, золотые сигналы SRE и почему мониторинг критичен для production
«Без данных вы просто ещё один человек с мнением» — W. Edwards Deming
Представьте: вы запустили приложение в production. Пользователи работают, всё выглядит нормально. Но что происходит на самом деле?
Без мониторинга вы слепы. Вы узнаете о проблеме только когда пользователи начнут жаловаться. А это уже поздно.
Observability (наблюдаемость) — это способность понять внутреннее состояние системы по её внешним выходам.
Три столпа observability:
В этом курсе мы сфокусируемся на метриках (Prometheus) и логах (Loki), потому что это база, без которой нельзя двигаться дальше.
Не все метрики одинаково полезны. Давайте разберёмся, что и зачем измерять.
Google в своей книге Site Reliability Engineering выделяет четыре ключевых типа метрик:
| Сигнал | Что измеряет | Пример |
|---|---|---|
| Latency (задержка) | Время обработки запроса | 95-й перцентиль ответа API = 250ms |
| Traffic (трафик) | Нагрузка на систему | 1000 запросов/секунду |
| Errors (ошибки) | Частота неудач | 0.5% HTTP 5xx ответов |
| Saturation (насыщение) | Насколько система «заполнена» | 85% использования памяти |
Почему именно эти четыре? Они универсальны. Неважно, что вы мониторите — веб-сервер, базу данных или очередь сообщений — эти сигналы работают везде.
┌─────────────────────────────────────────────────┐
│ Ваше приложение │
├─────────────────────────────────────────────────┤
│ │
│ Traffic: ████████░░ 1000 req/s │
│ Latency: ██████░░░░ 250ms (p95) │
│ Errors: █░░░░░░░░░ 0.5% (5xx) │
│ Saturation: ███████░░░ 75% CPU, 60% RAM │
│ │
└─────────────────────────────────────────────────┘
Если Traffic резко упал — возможно, проблема с балансировщиком или сетью. Если Latency выросла — приложение тормозит, нужно искать узкое место. Если Errors подскочили — что-то сломалось, пора смотреть логи. Если Saturation высокая — пора масштабироваться.
Мониторинг работает на нескольких уровнях абстракции:
Что мониторим: серверы, виртуальные машины, контейнеры
Ключевые метрики:
Зачем: чтобы понять, хватает ли ресурсов. Если CPU постоянно на 100% — приложение не сможет работать быстро, сколько бы вы ни оптимизировали код.
Что мониторим: само приложение, его внутреннее состояние
Ключевые метрики:
Зачем: чтобы понять, как приложение ведёт себя под нагрузкой. Инфраструктура может быть в порядке, но приложение — тормозить из-за блокировок в коде или медленных запросов к БД.
Что мониторим: метрики, важные для бизнеса
Ключевые метрики:
Зачем: чтобы связать технические проблемы с бизнес-последствиями. Если упала база данных — это техническая проблема. Если из-за этого упала выручка на 50% — это уже проблема бизнеса.
Существует два основных подхода к сбору метрик:
Приложение само отправляет метрики в систему мониторинга.
Приложение ──(метрики)──> Мониторинг
Плюсы:
Минусы:
Система мониторинга сама забирает метрики у приложения.
Мониторинг ──(запрос)──> Приложение
<(метрики)──
Плюсы:
Минусы:
Prometheus использует pull-модель. Это фундаментальное решение, которое влияет на всю архитектуру.
Временной ряд (timeseries) — это последовательность значений метрики во времени.
Пример:
Время │ CPU usage
────────────┼──────────
10:00:00 │ 45%
10:00:15 │ 47%
10:00:30 │ 52%
10:00:45 │ 48%
10:01:00 │ 55%
Каждая точка данных имеет:
cpu_usage)host=server1, region=us-east)Лейблы — это мощнейший механизм. Они позволяют «нарезать» данные разными способами:
cpu_usage{host="server1", region="us-east"} = 45%
cpu_usage{host="server2", region="us-east"} = 52%
cpu_usage{host="server1", region="eu-west"} = 38%
Теперь можно задать вопросы:
Мониторинг без алертинга — как дымовая сигнализация, которая не звонит пожарным.
Пример хорошего алерта:
«Error rate превысил 5% за последние 5 минут на сервисе payment-api. Проверь логи и последние деплои.»
Пример плохого алерта:
«CPU high on server-42» (И что делать? Какой CPU считается высоким? Когда началось?)
Далее: Архитектура Prometheus: как устроен сбор метрик