Real-Time Backend

Мониторинг real-time систем

В 2015 году Slack упал на 3 часа. Постмортем показал: инженеры заметили проблему через 20 минут после начала инцидента. При правильном мониторинге - первые алерты должны были прийти через 2 минуты. Разница - 18 минут downtime и тысячи злых пользователей.

**Discord** мониторит 26+ млн concurrent WebSocket-соединений через Prometheus + Grafana; алерты по connection drop и P99 latency уходят в PagerDuty с on-call ротацией 24/7.
**Datadog** использует P99 как primary SLO метрику для своих собственных WebSocket-эндпоинтов (real-time dashboard updates); SLO = 99.9% запросов < 200ms.
**Grafana** публично рассказывал, что GC pressure в Go серверах проявлялась как спайки P99 каждые несколько секунд - диагностировалось именно через histogram_quantile, не через среднее.

Connection Metrics

Connection metrics - фундамент мониторинга WebSocket-систем. Ключевые показатели: active connections (сколько соединений открыто прямо сейчас), connection rate (новых соединений/сек), disconnection rate и причины (normal close vs error vs timeout). Discord поддерживает 26+ млн concurrent WebSocket-соединений; потеря метрик на этом масштабе означает слепое управление системой.

Grafana + Prometheus - стандартный стек для WebSocket-мониторинга. Grafana предоставляет готовые alerting rules: например, alert если active connections упали более чем на 20% за 5 минут (признак массового disconnect или deploya без graceful shutdown).

График active connections показывает резкое падение с 50 000 до 5 000 за 30 секунд. Connection rate при этом остаётся нормальным (новые соединения приходят). Что скорее всего произошло?

Message Rate

Message rate - количество сообщений в единицу времени, как входящих (inbound), так и исходящих (outbound). Аномалии в соотношении inbound/outbound могут сигнализировать о проблемах: резкий рост inbound без роста outbound - bottleneck в обработке; падение outbound без падения inbound - проблемы с broadcast или downstream сервисами.

Разделение метрик по event_type (chat, join, ping, presence) позволяет видеть, какой тип сообщений создаёт нагрузку. Discord обнаружил, что presence updates (онлайн/офлайн статус) составляли 60%+ трафика gateway - что привело к оптимизации presence subsystem.

Grafana показывает: inbound messages/sec = 10 000, но processing time P50 = 200ms. Throughput сервера = 5 msg/sec на воркера при 1000 воркерах = 5000 msg/sec. Что происходит с очередью?

Latency P99

P99 latency (99-й перцентиль) показывает задержку, которую испытывает 1% самых медленных запросов. В real-time системах P99 критичнее среднего: если P50 = 5ms, но P99 = 2000ms - 1% пользователей видит зависший интерфейс. Discord цель - P99 < 100ms для message delivery. Datadog внутри использует P99 как primary SLO метрику.

Histogram в Prometheus - правильный инструмент для перцентилей: данные группируются по bucket'ам на клиенте (без хранения сырых значений), и P99 вычисляется через histogram_quantile() в Grafana. Summary тип в prom-client вычисляет перцентили на клиенте без возможности агрегации across instances.

В Grafana построен график: `histogram_quantile(0.99, rate(ws_e2e_latency_milliseconds_bucket[5m]))`. Значение = 450ms. Что это означает для пользователей?

Alerting

Alerting - автоматическое уведомление о выходе метрик за пороговые значения. Для WebSocket-систем стандартные алерты: active connections упали > 20% за 5 мин (deploy/crash), P99 latency > 500ms (деградация), error rate > 1% (проблемы обработки), message rate упал > 50% (проблемы upstream). Grafana Alerting и PagerDuty - стандартный стек в production системах.

Параметр `for` в Grafana Alert Rules задаёт, как долго условие должно выполняться до срабатывания алерта. Это защищает от flapping (мигающих алертов) при кратковременных спайках. Для critical алертов - 1-2 минуты, для warning - 5-10 минут. PagerDuty поддерживает routing: critical будит on-call инженера, warning отправляет в Slack.

Среднее значение (P50) latency - достаточная метрика для мониторинга WebSocket-систем

P99 и P999 критичны для real-time систем: среднее скрывает хвост распределения, где живут самые болезненные пользовательские опыты

При 100 000 active users P99 = 450ms означает 1000 пользователей с плохим опытом прямо сейчас. P50 = 10ms при этом создаёт ложное ощущение благополучия.

P99 latency спайкует до 800ms каждые 30 секунд на 5 секунд (GC pause в Node.js). Alert настроен: expr > 500ms, for: 5m. Сработает ли алерт?

Итоги

**Connection metrics** (active, rate, disconnection by code) - базовый индикатор здоровья; резкое падение соединений с нормальным connection rate = deploy без graceful shutdown.
**Message rate** (inbound vs outbound по event_type) выявляет bottleneck обработки; дисбаланс inbound > outbound означает накопление backlog.
**P99 latency через Histogram** (не Summary) - правильная метрика для real-time; алерты с `for: 5m` защищают от flapping на кратковременных спайках.

Связанные темы

Мониторинг связан с операционными и безопасностными аспектами системы:

DDoS и Abuse — Аномальный рост connection rate и message rate - первые сигналы DDoS, детектируемые через monitoring
Audit и Compliance — Операционные метрики дополняют audit trail: метрики для real-time реакции, audit log для forensic анализа
Horizontal Scaling — Multi-instance деплой требует агрегации метрик across instances; Prometheus автоматически агрегирует при scraping

Вопросы для размышления

Как измерить end-to-end latency если клиентские часы не синхронизированы с серверными (clock skew до 100ms)?
Какие метрики позволяют отличить деградацию из-за роста нагрузки от деградации из-за memory leak в Node.js процессе?
Как организовать monitoring для WebSocket-системы с горизонтальным масштабированием на 50 серверах - агрегировать на уровне инфраструктуры или приложения?

Связанные уроки