Что собираешь в метриках?

Мониторинг и метрики в PHP Backend

Как backend-разработчик с 10+ лет опыта, я собираю метрики на нескольких уровнях абстракции, чтобы получить полную картину здоровья системы, производительности и поведения пользователей. Метрики — это не просто данные, а основа для принятия решений и проактивного реагирования на проблемы.

1. Метрики инфраструктуры и хоста

Эти метрики показывают, насколько стабильно работает "железо" и ОС:

• Загрузка CPU (user, system, idle, iowait) — чтобы видеть узкие места в вычислениях.
• Использование памяти (RAM, swap) — предотвращаем исчерпание памяти и OOM Killer.
• Дисковое пространство и I/O — свободное место, read/write latency, IOPS.
• Сетевая активность — входящий/исходящий трафик, количество соединений, ошибки.
• Процессы и файловые дескрипторы — отслеживаем утечки ресурсов.

# Пример метрик с хоста (через node_exporter)
cpu_usage{instance="api-01", mode="user"} 45.23
memory_available_bytes{instance="api-01"} 2.1e+09
disk_used_percent{instance="api-01", mount="/"} 78.5

2. Метрики приложения (PHP-FPM / Swoole)

Для PHP-приложений критически важно мониторить сам runtime:

• Статус процессов PHP-FPM (active, idle, max children) — настраиваем пул воркеров.
• Запросы в секунду (RPS) и время обработки — базовые показатели нагрузки.
• Очередь запросов — если запросы ждут свободных воркеров.
• Пиковое использование памяти на запрос — находим "прожорливые" эндпоинты.
• Статус OPcache (hit rate, memory usage, interned strings) — эффективность кеширования байткода.

// Пример сбора метрик времени выполнения эндпоинта
$start = microtime(true);
// ... логика обработки запроса ...
$duration = microtime(true) - $start;
$metrics->histogram('http_request_duration_seconds', $duration, ['endpoint' => '/api/v1/users']);

3. Метрики бизнес-логики

Здесь мы переходим от "как работает система" к "что делают пользователи":

• Количество операций (регистрации, платежи, заказы) — ключевые события продукта.
• Распределение значений (сумма чека, размер загружаемого файла) — понимаем паттерны использования.
• Счетчики ошибок бизнес-логики (недостаточно средств, дубликаты) — отличаем технические ошибки от бизнес-валидации.
• Активность пользователей по сегментам (гео, тарифный план) — для анализа аудитории.

4. Метрики зависимостей (базы данных, кеши, внешние API)

Ни одно приложение не работает в вакууме:

• Время запросов к БД и количество соединений — находим медленные запросы и дедлоки.
• Хит-рейт кешей (Redis, Memcached) — эффективность стратегии кеширования.
• Латентность внешних API и процент ошибок — отслеживаем SLA сторонних сервисов.
• Очереди сообщений (RabbitMQ, Kafka) — размер очередей, задержки обработки.

-- Пример метрики для мониторинга БД
SELECT 
  query, 
  AVG(execution_time) as avg_time,
  COUNT(*) as calls
FROM slow_query_log 
WHERE timestamp > NOW() - INTERVAL 5 MINUTE
GROUP BY query;

5. Метрики HTTP/API

Для веб-приложений это обязательный минимум:

• HTTP статус-коды (2xx, 3xx, 4xx, 5xx) распределение — общее здоровье API.
• Время ответа (p50, p95, p99) — перцентили показывают опыт реальных пользователей.
• Размеры запросов и ответов — оптимизируем трафик.
• Скорость отдачи контента (TTFB, время до первого байта) — критично для UX.

6. Специфические метрики для PHP

• Сборки мусора (GC cycles) и потребление памяти — особенно важно для long-running процессов (Swoole, RoadRunner).
• Загрузка классов и автолоадинг — производительность в development vs production.
• Профилирование XHProf/Tideways — sampling для production-трассировки.
• JIT-компиляция в PHP 8 — эффективность компиляции "горячих" участков кода.

Инструменты и практики

Я использую Prometheus как основной сборщик метрик с Grafana для визуализации. Для бизнес-метрик иногда добавляю StatsD или отправляю события прямо в TimescaleDB. Ключевые принципы:

• Метрики должны быть дешевыми по сбору и хранению
• Лейблы (labels) вместо отдельных метрик — для агрегации и группировки
• USE и RED методологии — Utilization, Saturation, Errors + Rate, Errors, Duration
• Alerting на основе метрик — но только для действительно важных инцидентов

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