Ключевые выводы
- Мониторинг CDP Prometheus Grafana — стандартный стек для on-prem-инсталляций; покрывает все слои: инфраструктуру, приложение, данные и бизнес-метрики
- Базовый дашборд CDP включает 4 категории метрик: системные, application, data quality, бизнес
- Самые критичные алерты: задержка обработки событий, доля неуспешных доставок, latency API, использование памяти/диска
- Без data quality-метрик мониторинг даёт картину «всё зелёное», но клиенты получают неправильные коммуникации
- Минимальный production-set: 30-50 метрик, 15-25 алертов, 4-6 дашбордов под разные роли (DevOps, аналитик, маркетолог, business owner)
Мониторинг CDP Prometheus Grafana — обязательная часть on-prem-инсталляции, без которой команда узнаёт о проблемах от пользователей, а не от системы. В отличие от SaaS, где мониторинг — забота вендора, в on-prem это полная ответственность заказчика.
Эта статья — практическое руководство по настройке мониторинга CDP-стека. С конкретными метриками, алертами и шаблонами дашбордов, которые покрывают типовые проблемы on-prem-инсталляций.
Архитектура мониторинга
- Prometheus — TSDB, собирающий метрики со всех компонентов
- Grafana — визуализация и дашборды
- Alertmanager — маршрутизация алертов в Telegram, email, PagerDuty
- Loki — для логов (опционально, если есть бюджет)
- Tempo / Jaeger — для distributed tracing (опционально)
- Node Exporter — системные метрики на каждом сервере
- cAdvisor — метрики контейнеров
- Кастомные exporter'ы — для специфичных интеграций
Стек размещается на отдельной инфраструктуре, не зависящей от продуктовой. Это критично: если падает продакшен, мониторинг должен продолжать работать.
Метрики системного уровня
| Метрика | Алерт | Что показывает |
|---|---|---|
| node_cpu_usage | >80% 5 мин | Нехватка CPU |
| node_memory_usage | >85% 5 мин | Возможный OOM |
| node_filesystem_free | <15% | Скоро закончится диск |
| node_load1 | >cpu_count*1.5 | Перегрузка системы |
| network_errors | >10/мин | Сетевые проблемы |
| node_iowait | >20% | Узкое место по диску |
Метрики application-уровня
- http_request_duration_seconds — latency API endpoint'ов (p50, p95, p99)
- http_requests_total — RPS по endpoint'ам и статусам
- http_error_rate — доля 5xx ответов
- active_connections — открытые соединения с БД
- jvm_memory_used или process_memory — потребление памяти процессом
- gc_pause_duration — длительность пауз GC (для Java/Go-сервисов)
- thread_pool_queue_size — размер очереди задач
Метрики данных
Самая часто пропускаемая категория — но самая важная для CDP:
- events_ingested_per_minute — поток входящих событий
- events_processing_lag — отставание обработки от поступления
- profiles_total — количество профилей в системе (рост во времени)
- identity_resolution_success_rate — доля успешных склеек профилей
- data_quality_null_rate — доля записей с критичными null-полями
- duplicate_profiles_detected — найденные дубликаты, требующие slowdown
- kafka_consumer_lag — задержка консьюмера от продюсера в очереди
Метрики бизнес-уровня
- email_send_rate — отправки в час/минуту
- email_bounce_rate — доля bounce-доставок
- email_open_rate — open rate в реальном времени
- active_campaigns — количество запущенных кампаний
- segment_size — размер сегментов (мониторинг резких изменений)
- scenario_trigger_rate — срабатывания триггерных сценариев
- conversion_rate_by_scenario — конверсии по сценариям
Топ-15 алертов
- Disk space < 15% — критично, может остановить запись событий
- Memory usage > 90% 10 мин — риск OOM
- Kafka consumer lag > 5 минут — события обрабатываются с опозданием
- API p99 latency > 2 сек — деградация производительности
- API error rate > 1% — рост ошибок
- Database connection pool > 90% — приближение к лимиту соединений
- Email bounce rate > 5% — проблемы с deliverability
- Identity resolution rate < 70% — деградация качества склейки
- Data ingestion stopped — события не приходят (сильное падение rate)
- Scenario trigger rate dropped — сценарии не срабатывают (потенциальная регрессия)
- Backup failed — последний бэкап неуспешен
- Replication lag > 30 сек — БД не успевает реплицироваться
- SSL certificate expires < 30 дней — заканчивается сертификат
- SMTP queue backup > 10000 — отправка email не успевает
- Unauthorized access attempts — попытки взлома
Дашборды по ролям
DevOps дашборд
CPU, RAM, диск, сетевые ошибки на каждом сервере. Topology graph всех сервисов. Heatmap latency. Логи ошибок по сервисам.
Application дашборд
RPS, latency, error rate по endpoint'ам. Метрики JVM/runtime. Connection pools. Thread pools. Распределение времени запроса по слоям (DB, cache, application logic).
Data quality дашборд
Поток событий. Лаг обработки. Identity resolution rate. Доля null в критичных полях. Duplicate detection rate. Размер очередей.
Business дашборд
Активные кампании. Email/push отправки в реальном времени. Open rate, click rate, conversion rate. Размер ключевых сегментов. Доходы от триггерных сценариев. NPS-проксирующие метрики (open rate, спам-жалобы).
Стоимость и сроки настройки
| Этап | Срок | Бюджет |
|---|---|---|
| Развёртывание Prometheus + Grafana | 1-2 недели | 0.4-0.6 млн ₽ |
| Настройка exporter'ов и сбор метрик | 2-3 недели | 0.8-1.2 млн ₽ |
| Создание дашбордов и алертов | 2-3 недели | 0.6-1 млн ₽ |
| Интеграция с уведомлениями | 1 неделя | 0.2-0.3 млн ₽ |
| Итого | 6-9 недель | 2-3 млн ₽ |
Поддержка и развитие — 0.5-1 млн ₽/год. С каждым новым сервисом или интеграцией добавляются метрики и алерты.
FAQ о мониторинге CDP
Можно ли использовать managed-сервисы вместо self-hosted Prometheus?
Yandex Monitoring, VK Cloud Monitoring и аналоги дают подходящую инфраструктуру. Они дороже на больших объёмах, но дешевле в эксплуатации. Подходящее решение зависит от объёма метрик и зрелости команды DevOps.
Как часто обновлять дашборды?
Постоянно — это живой инструмент. Каждый инцидент — это сигнал, что в дашбордах не хватает метрики, которая помогла бы предсказать проблему. Раз в квартал — ревью всех дашбордов и алертов на актуальность.
Что делать с шумными алертами?
Шумные алерты быстро игнорируются командой — это худшая ситуация. Если алерт срабатывает чаще 1-2 раз в неделю и не требует действия — нужно либо изменить пороги, либо удалить. Каждый алерт должен иметь runbook с конкретными шагами реагирования.
Какая retention для метрик?
Системные и application — 30-90 дней (этого достаточно для большинства задач). Бизнес-метрики и data quality — 1-3 года (для долгосрочного анализа трендов). С учётом этих требований нужно планировать дисковое пространство Prometheus.
Нужны ли SLO и error budget?
Для зрелых проектов — да. SLO (Service Level Objectives) задают целевые показатели качества (например, «99.9% запросов API быстрее 500мс»). Error budget — допустимый объём отклонений от SLO. Эти концепции помогают команде принимать рациональные решения о приоритете надёжности vs новых фичей.
Что в итоге
Мониторинг CDP Prometheus Grafana — обязательная инвестиция для любой on-prem-инсталляции. Базовая настройка занимает 2-3 месяца и стоит 2-3 млн ₽. Без неё команда работает в режиме «пожар после жалобы клиента».
Главное — не экономить на data quality-метриках. Системный мониторинг показывает, что серверы работают; data quality показывает, что они работают правильно.
Готовы помочь с проектированием observability-стека под вашу CDP-инсталляцию — обсудим в формате архитектурной сессии.
Дополнение: эволюция мониторинга в проекте
Мониторинг CDP Prometheus Grafana — это не «настроил и забыл», а система, которая растёт вместе с проектом:
- Месяц 1-3: базовый мониторинг — системные метрики, основные application-метрики, 5-7 алертов
- Месяц 4-6: добавление data quality дашборда, расширение алертов до 15-20
- Месяц 7-12: бизнес-дашборды, кастомные метрики под специфику процессов
- Год 2: distributed tracing, корреляция событий между сервисами
- Год 3+: SLO-based alerting, error budget, predictive alerts на основе ML
На каждом этапе observability-стек становится более зрелым. Основная инвестиция приходится на первый год — потом только инкрементальные улучшения. Это типовая траектория для production-grade мониторинга CDP в enterprise.