Мониторинг в реальном времени
(Раздел: Операции и Управление)
1) Зачем real-time мониторинг
Реальное время — это не «магия миллисекунд», а способность обнаруживать отклонения и действовать в пределах SLO-окон. Для iGaming/финтех это означает:- мгновенная видимость доступности и задержек (p50/p95/p99) критичных маршрутов;
- контроль целостности событий (вебхуки, платежи, RTP/лимиты);
- финансовую защищенность (egress/стоимость 1k событий, клиринг/эскроу);
- соблюдение комплаенса (квитанции, PII-гигиена).
2) Архитектурный контур
Слои:1. Producers: сервисы, SDK, edge-узлы, провайдеры платежей/контента.
2. Ingest-шлюзы: приемники `metrics/traces/logs/events` с backpressure и квотами.
3. Шина/стриминг: брокер с партиционированием (tenant/region/route), ретеншн для replay.
4. Stream-processing: оконные агрегации (T+5s/T+1m), дедуп, нормализация времени, расчет SLI.
5. Хранилища: time-series (оперативка), OLAP (история), WORM-журналы (аудит).
6. Аналитика и алертинг: правила SLO, статистические детекторы, аномалистка.
7. Дашборды и руны: UI для действий (pause/re-route/rollback/raise-limit).
Ключевые практики:- Data contracts на метрики/события (схемы, версии, валидация).
- Outbox/CDC для гарантированной публикации доменных событий.
- Idempotency и дедуп по `trace_id/event_id`.
- Clock sync: NTP/PTP, коррекция `skew`, водопады времени (event vs processing time).
3) Типы телеметрии и семантика
Metrics (SLI): счетчики/гейджи/гистограммы p-перцентилей.
Traces: сквозные `trace_id/span_id`, связка RPC↔события↔вебхуки.
Logs: структурированные, с `tenant_id/region/version`.
Business events: `PaymentAuthorized`, `WebhookDelivered`, `RTPWindowClosed`.
Receipts: квитанции/подписи (для финансов/критичных операций).
4) Время и окна
Виды времени: event-time, ingest-time, processing-time.
Окна: скользящие (5–30 c), тумблерные (1–5 мин), с задержкой воды (watermark) для поздних событий.
Компактность: агрегируйте в потоке (эскизы гистограмм) → храните только необходимые перцентильные бины.
5) Нормализация и качество данных
Валидация на входе: схему/диапазоны/обязательные поля; отклоненные — в карантин с меткой причины.
Дедупликация: по `(event_id, producer, seq)`; храните «seen-cache» в памяти+KV.
Коррекция метрик: против «double count» и «flatline» (датчики молчат).
Сэмплирование: для high-QPS — адаптивное, с погрешностью; критичные SLI — полно.
6) SLI/SLO (референс)
North Star: E2E Success Rate при целевых p95 по регионам.
SLI:- Доступность per-канал/регион.
- Латентность p50/p95/p99 по ключевым маршрутам.
- Error-rate/Retry-rate.
- Успешность доставок вебхуков (% подтвержденных квитанциями).
- Консистентность цен/налогов (`quote == checkout`, ±1 minor unit).
- Cost-SLI: стоимость 1k событий, egress/ingress на единицу.
- Доступность ≥ 99.95% в 28-дневном окне.
- p95: витрина ≤ 120 мс, quote/checkout ≤ 250 мс.
- Вебхуки успешны ≥ 99.5%/5-мин окно.
- Δ quote↔checkout = 0 (±1 minor unit).
- Реакция на P1 ≤ 10 мин, MTTR ≤ 60 мин.
7) Алертинг и руны (auto-actions)
Уровни: P1 (срыв SLO/безвыходность), P2 (деградация), P3 (тренд/риски).
Шумоподавление: дедуп по `trace_id`, корреляция причинно-следственных цепочек.
- «PriceMismatch» → refresh каталога, сверка `fx_version/tax_rule_version`, компенсационная политика;
- «WebhookLag» → перерасстановка воркеров, увеличение batch, приоритизация очередей;
- «RTP Drift» → пауза промо, проверка таблицы выплат/версии, откат профиля;
- «Egress Surge» → включить компрессию/кэш-пиннинг/альтернативный маршрут.
- Эскалации: матрица 24×7, on-call ротации, каналы (чат/звонок/SMS).
8) Дашборды (оперативные виджеты)
Здоровье платформы: доступность, p95/p99, error-rate, burn-down error-бюджета.
Интеграции/вебхуки: успешность, лаг, дубли/идемпотентность, квитанции.
Checkout/цены: расхождения витрина↔checkout, версии FX/Tax, отказ-кейсы.
RTP/лимиты: теор. vs observed RTP, срабатывания лимитов, экспозиция.
FinOps: cost per 1k, egress/ingress, бюджеты/кап-алерты.
Security/Compliance: SoD, JIT, MFA, запросы к PII, подписи крит. операций.
Release/Flags: статусы фич, канареечные регионы, связка с инцидентами.
9) Мультирегион и multi-tenant
Партиционирование по `tenant/region`.
Независимые SLO/квоты по регионам; ограничения кросс-регионных алертов (чтобы локальный сбой не «красил» весь мир).
Зоны доверия данных: PII/финансы — только там, где разрешено; в общем дашборде — агрегаты/хэши.
10) Безопасность, приватность, доказуемость
Аутентификация ingest: ключи/мутуал-TLS, rate-limits, подписи пакетов.
PII-минимизация: токены вместо первички, маски/хэш-идентификаторы.
Квитанции (receipts): DSSE/подписи для финансовых/критичных событий.
WORM-журналы: неизменяемые логи для аудита, Merkle-срезы.
Access Control: RBAC/ABAC/ReBAC, JIT для чувствительных панелей.
11) Аномалистка и корреляции
Guardrails: статические пороги по SLI.
Статистика: Shewhart/CUSUM/EWMA для трендов.
ML/сигналы: сезонность/каналы/ASN/провайдеры; влияние релизов/фичефлагов.
Корреляции: связывайте инциденты с релизами, изменениями конфигов, всплесками трафика, акциями.
12) Производительность и стоимость
Бюджет телеметрии: cap на QPS/объем; отбраковка «болтливых» метрик.
Сжатие/агрегации: downsampling истории (1с→10с→1мин), храните перцентильные эскизы.
Egress-контроль: локальные кэши/агрегаты, edge-предобработка.
Cost-aware алерты: сигнал, если стоимость/1k событий или egress выходит за план.
13) Интеграции и контракты API
`POST /ingest/metrics` (JSON/OTLP): аутентификация, квоты, схема/версия.
`POST /ingest/events` (подписанные): дедуп/TTL/nonce.
`GET /kpis?filters=region,tenant,route` — агрегаты для UI.
`GET /traces/{trace_id}` — раскрутка цепочки.
Вебхуки: `IncidentRaised`, `QuotaCapReached`, `PriceMismatch`, `WebhookLag`, `RTPDrift`.
14) Плейбуки инцидентов (short-form)
P1 Доступность↓: переключить роутинг, включить circuit-breakers, снизить таймауты клиентов, аварийный пост о статусе.
P1 Quote≠Checkout: freeze промо/динамику цен, форс-инвалидация кэша, сравнение версий FX/Tax, компенсации.
P1 WebhookLag: увеличить воркеры/конкурентность, batch-размер, отключить несущественные вебхуки.
P2 RTP Drift: пауза бонусов, верификация таблиц выплат/версий, расширение окна наблюдения, отчет.
P2 Egress Surge: компрессия, edge-кэш, переезд части трафика, временные квоты.
15) Метрики качества самого мониторинга
Доступность UI/API ≥ 99.9%.
Freshness: лаг обновлений ≤ 30 с для оперативных панелей.
Completeness: ≥ 99.5% источников прислали данные в окно.
Correctness: расхождение с эталоном ≤ 0.1%.
MTTA/MTTR алерт-пайплайна: P1 ≤ 1/10 мин.
16) Чек-лист внедрения
- Определить North Star и набор SLI/SLO по регионам/каналам.
- Ввести data contracts и схемы для всех потоков телеметрии.
- Настроить ingest с квотами, backpressure и дедупом.
- Развернуть шину/стриминг и оконные агрегации с watermarks.
- Построить time-series/OLAP/WORM и связку с квитанциями.
- Завести алерты + авто-руны, матрицу эскалаций 24×7.
- Сформировать дашборды по ролям: SRE/Product/FinOps/Compliance/Partners.
- Включить PII-минимизацию, подписи и RBAC/ABAC/ReBAC.
- Ввести FinOps-метрики (cost/1k, egress, хранение) и капы.
- Провести GameDay: лаг вебхуков, рассинхрон цен, ретрай-бурст, отказ региона.
17) Привязка к iGaming/финтех
RTP & Limits: контроль наблюдаемого RTP и лимитов в минутах/часах, алерты на «over/under pay».
Платежи/выплаты: сквозная трассировка авторизаций, клиринга и квитанций; SLA PSP.
Аффилиаты: доставка конверсий (вебхуки) и споры → эскроу/сверки.
Промо: всплески трафика → защита очередей и цена egress; guardrails на бюджеты.
18) FAQ
Real-time обязателен везде?
Нет. «Горячие» контуры — секунды/минуты (инциденты, платежи, вебхуки). Экономика/аналитика — минуты/часы.
Как бороться с ложными тревогами?
SLO-ориентированные условия, агрегирование и дедуп по `trace_id`, корреляция с релизами, гистерезис порогов.
Нужно ли хранить все логи навсегда?
Нет. WORM — только для аудита/критичных потоков; остальное — downsampling/TTL.
Почему «quote≠checkout» встречается?
Версии FX/Tax, инвалидация кэша, округления. Лечится версиями, SWR-стратегией и тестами консистенции.
Резюме: Мониторинг в реальном времени — это дисциплина: строгие контракты данных, оконные вычисления, нормализованное время, связка с квитанциями и SLO-алертами, плюс кнопка действия в каждом виджете. Сделав это правильно, вы сокращаете MTTR, держите бюджет под контролем и уверенно масштабируете экосистему по регионам и тенантам.