Метрики

Если логи помогают понять «что именно произошло» (сообщают об ошибках и конкретных событиях), то метрики дают представление «как система работает в целом с течением времени». Используя метрики, ты видишь тренды, можешь прогнозировать исчерпание ресурсов или падение конверсии.

Технические метрики

• CPU и память: Наглядно видишь, какой микросервис подъедает больше всего ресурсов (утечки памяти).
• HTTP-запросы: Количество запросов (RPS), среднее время ответа (Latency), процент ошибок (Error Rate).
• Активные соединения: Помогает понять, нет ли узких мест в пуле коннектов к БД.

Бизнесовые метрики

• Конверсия: Сколько людей из всех посетителей завершили покупку.
• Доход в реальном времени: Сколько денег приносит продукт прямо сейчас.
• Активная аудитория: Регистрации, подписки, активность (DAU/MAU).

• Инструменты в коде: Большинство современных фреймворков (Spring Boot, Express.js, Go Prometheus client) имеют встроенные средства для сбора метрик и выставляют их наружу (обычно на эндпоинте /metrics).
• Агенты и экспортеры: Специальные плагины (exporters), которые автоматически собирают метрики о железе (Node Exporter) или базе данных (Postgres Exporter).
• Push-модель: Сам сервис агрегирует метрики и отправляет их в хранилище (например, Graphite или InfluxDB).
• Pull-модель (Стандарт индустрии): Хранилище (например, Prometheus) само периодически опрашивает эндпоинты (scrapes) во всех микросервисах и забирает данные.

Типичный флоу: Микросервисы выставляют метрики → Prometheus их собирает (pull) и хранит → Grafana рисует из этих данных красивые дашборды.

• Uber: Стандартизация метрик. У Uber тысячи микросервисов. Как они привели сбор метрик к единому стандарту, чтобы разработчики не сошли с ума? Читаем про их внутренний фреймворк uMetric.
• Victoria Metrics vs Prometheus. Prometheus — стандарт, но он жрет память на огромных масштабах. Разбираем, почему многие HighLoad-проекты переходят на VictoriaMetrics для долговременного хранения данных.