Моніторинг в реальному часі

(Розділ: Операції та Управління)

1) Навіщо real-time моніторинг

• миттєва видимість доступності та затримок (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↔sobytiya↔vebkhuki.
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 по регіонах.

• Доступність 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/ціни: розбіжності vitrina↔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 історії (1s→10s→1min), зберігайте перцентильні ескізи.
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 Dostupnost↓: перемкнути роутинг, включити 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, тримаєте бюджет під контролем і впевнено масштабуєте екосистему по регіонах і тенантах.