Real-Time Backend

Live Dashboards

Grafana dashboard с 20 панелями и 1000 одновременными пользователями делает 40 000 запросов в минуту к базе метрик. Без правильной архитектуры мониторинг убивает сам себя.

  • **Grafana Cloud** обрабатывает более 10 млрд метрик в сутки; Grafana Labs использует собственный продукт для мониторинга Grafana Cloud - "dogfooding" в production масштабе
  • **Datadog** рендерит dashboards для Netflix, Samsung, Airbnb одновременно; их query engine обрабатывает 10+ триллионов точек данных в день с latency <1с на p99
  • **Cloudflare Radar** - публичный live dashboard, показывающий глобальный интернет-трафик в реальном времени; агрегирует 100M+ DNS-запросов в секунду в визуализации с 5-минутными окнами
  • **AWS CloudWatch** обслуживает более 1 триллиона API-запросов в месяц; live dashboards для Lambda, EC2 и RDS обновляются с задержкой <60с

Metrics Streaming

Metrics streaming - это непрерывная доставка числовых показателей от системы к dashboard в реальном времени. Grafana Cloud принимает более 10 миллиардов точек метрик в сутки от команд по всему миру. Datadog обрабатывает 10+ триллионов метрик в день от клиентов вроде Samsung, Airbnb и Peloton. Ключевое отличие от классического polling: данные приходят сами, как только появляются.

Push vs Pull - фундаментальный выбор архитектуры. Prometheus использует pull: сервер опрашивает /metrics endpoint каждые 15с. Это упрощает Service Discovery, но добавляет минимум 15с задержки. Grafana Live (SSE/WebSocket) и InfluxDB push-модель дают задержку <1с. Для operational dashboards ("что происходит прямо сейчас") нужен push; для capacity planning достаточно pull с 1-минутным интервалом.

  • **SSE (Server-Sent Events)**: одностороннй push, автоматический reconnect, HTTP/2 мультиплексирование - идеален для dashboards
  • **WebSocket**: двусторонняя связь, нужен для интерактивных операций (drill-down запросы, фильтры)
  • **Long polling**: fallback для окружений без SSE/WS; добавляет 100-500 мс задержку на каждый запрос
  • **StatsD protocol**: UDP-based, fire-and-forget; агенты Datadog/Prometheus node_exporter слушают порт 8125

Dashboard показывает CPU load 50 серверов. Нужно обновление раз в 1 секунду без интерактивности. Что выбрать?

Aggregation Windows

Сырые метрики приходят тысячами точек в секунду - отображать все нет смысла. Aggregation window группирует точки за период (1с, 1м, 5м) и вычисляет агрегат: avg, max, p99. InfluxDB задействует downsample retention policies: raw данные хранятся 7 дней, 1-минутные агрегаты - 30 дней, часовые - 1 год. Это снижает объём хранилища в 1000x.

Выбор размера окна - компромисс между детализацией и стабильностью. Grafana Cloud рекомендует: для realtime dashboard (последние 5 минут) - окно 5с; для дневного view - окно 1м; для недельного - окно 1ч. Слишком маленькое окно даёт шумный график с всплесками; слишком большое - скрывает важные пики (p99 за 1 час может выглядеть нормально, хотя 30 секунд всё было сломано).

  • **Tumbling window**: неперекрывающиеся интервалы [0:10), [10:20); используется для billing counters
  • **Sliding window**: вычисляет агрегат за последние N секунд каждые M секунд; laten для rate-of-change
  • **p99 vs avg**: среднее скрывает tail latency; Datadog рекомендует всегда показывать p99 для SLO-метрик
  • **Downsampling**: raw → 1m → 1h → 1d; каждый уровень хранится дольше при меньшей детализации

API response time в среднем 120 мс, но пользователи жалуются на медленную работу. В чём причина?

Sparklines

Sparkline - компактный inline-график без осей и подписей, показывающий тренд в одной строке таблицы. Grafana использует sparklines в table panels для отображения тренда метрики рядом с текущим значением. Datadog's widget system рендерит тысячи sparklines на одном dashboard - каждый показывает последние 2 часа агрегированных данных.

Sparklines эффективны благодаря принципу data density от Tufte: максимум информации на минимуме пространства. В 100x20 пикселях помещается 100 точек данных, достаточно чтобы увидеть тренд, seasonality и аномалии. Критично: sparkline должен использовать consistent Y scale внутри одного dashboard, иначе нельзя сравнивать серверы. Grafana по умолчанию нормализует каждый sparkline отдельно - это нужно отключать для сравнительных dashboards.

Dashboard показывает 50 серверов с sparklines CPU. У сервера A sparkline занимает всю высоту (выглядит тревожно), хотя CPU всего 15%. У сервера B sparkline плоский, но CPU 80%. В чём проблема?

Dashboard Architecture

Grafana Cloud обслуживает миллионы dashboard-запросов в день. Архитектура live dashboard имеет специфический bottleneck: fan-out запросов. Один dashboard с 20 панелями делает 20 параллельных запросов к backend при загрузке. При 1000 одновременных пользователей - 20 000 запросов/сек к метрической БД только от одного dashboard.

Grafana использует Query Caching с TTL, соответствующим refresh interval панели. Если 50 пользователей смотрят один dashboard с refresh 30с, сервер делает не 50 × 20 = 1000 запросов/30с, а 20 запросов/30с - результаты кешируются и раздаются всем. ClickHouse и InfluxDB оптимизированы для этого паттерна: один heavy query быстрее тысячи мелких из-за column-store storage и vectorized execution.

  • **BFF паттерн**: Backend for Frontend агрегирует N запросов панелей в один WebSocket поток
  • **Query deduplication**: кешировать идентичные запросы в пределах одного refresh interval
  • **Incremental updates**: отправлять только новые точки, не весь timeseries заново
  • **Variable timerange**: при zoom-out переключаться на downsampled данные (Grafana делает это автоматически)
  • **Alert-driven refresh**: при нормальных метриках обновлять раз в 30с; при аномалии - раз в 1с

Чем больше refresh rate dashboard (чаще обновляется), тем лучше для мониторинга

Агрессивный refresh (< 5с) при большом числе пользователей создаёт Query Storm на метрической БД и может привести к деградации самой системы мониторинга

Grafana Cloud ограничивает минимальный refresh до 5с именно поэтому. Вместо частого polling для критических метрик правильнее использовать alerting: система сама уведомляет при пересечении порога без постоянного опроса.

1000 пользователей открыли один Grafana dashboard с 20 панелями, refresh 30с. Сколько запросов в минуту получит InfluxDB без оптимизаций?

Итоги

  • **SSE vs polling**: Server-Sent Events дают push-модель с автоматическим reconnect; для read-only dashboard лучше WebSocket по простоте и поддержке HTTP/2
  • **Aggregation windows**: avg скрывает tail latency; всегда отслеживать p99 для SLO; размер окна - компромисс между детализацией и стабильностью
  • **Sparklines**: нормализация Y-оси должна быть глобальной для сравнительных panels, иначе 15% CPU выглядит страшнее 80%
  • **Query Storm**: 1000 пользователей × 20 панелей = 20 000 параллельных запросов; query caching и BFF-паттерн сокращают нагрузку в 1000 раз

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

Live dashboards строятся на нескольких технологиях из курса realtime-backend:

  • IoT Real-Time — IoT-телеметрия - типичный источник данных для operational dashboards; InfluxDB + Grafana - стандартный стек для промышленного IoT
  • Rate Limiting Real-Time — Метрические БД лимитируют query rate; агрессивный dashboard refresh без rate limiting ломает сам инструмент мониторинга
  • Financial Trading — Trading dashboards - экстремальный случай: обновление каждый tick (миллисекунды), sparklines для bid/ask spreads, aggregation windows для VWAP

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

  • Dashboard команды Netflix показывает error rate 50 микросервисов. Как определить оптимальный aggregation window чтобы видеть реальные инциденты, но не реагировать на шум?
  • 1000 инженеров открыли Grafana во время инцидента. Dashboard сам начал падать от нагрузки. Какую архитектуру нужно было заложить заранее?
  • Sparkline показывает CPU одного сервера за последние 2 часа. В какой момент нужно переключиться с 1-секундных данных на 1-минутные агрегаты и почему именно там?

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

  • db-19-redis
Live Dashboards

0

1

Войти