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-минутные агрегаты и почему именно там?