Потоки телеметрії

1) Призначення та контекст

Потоки телеметрії забезпечують безперервний приплив спостережних даних про роботу платформи: що відбувається, чому і скільки це коштує. В iGaming це ключ до раннього виявлення деградацій депозитів/ставок, видимості зовнішніх провайдерів (PSP/KYC/ігрові студії) і доказової відповідності SLO/комплаєнсу.

2) Карта джерел телеметрії

Метрики (TSDB): RED/USE, бізнес-SLI (успіх авторизацій,% успішних ставок).
Трейси (OTel): ланцюжки запитів через фронт → API → брокери → БД/PSP.
Логи (структуровані): події, аудит операцій, помилки.
RUM: TTFB/LCP, помилки JS, гео/пристрій.
Синтетика: зовнішні пробні транзакції (логін/депозит/» пісочна» ставка) з різних GEO.
Низькорівнева телеметрія: eBPF/профайлінг CPU/IO/alloc, мережеві p95/p99.
Зовнішні статуси: вебхуки/пули PSP/KYC/CDN/WAF.

3) Стандарти та схеми

OpenTelemetry как lingua franca: уніфікація семантики атрибутів (service. name, deployment. environment, enduser. id - маскується, trace/SpanID, PSP-коди).
Угоди про схеми: версіонування, schema registry для логів/трейсів, «breaking-changes» тільки через двійковий прапор і grace-період.
Correlation-ID: єдиний'correlation _ id'для платежу/ставки крізь всі шари + exemplars в перцентилях метрик.

4) Конвеєр інжесту (high-level)

1. Producers: SDK/агенти/колектори (OTel Collector на вузлах).
2. Edge-буферизація: локальні черги (memory/disk) з лімітами.
3. Transport: gRPC/HTTP OTLP → брокер повідомлень (Kafka/Pulsar) з idempotency-ключами.
4. Processors: нормалізація, збагачення (GEO/тенант/канал), PII-фільтри, тонкий семплінг.
5. Fan-out: в TSDB (метрики), в сховище трас, в систему логів, в lake/DWH, в алертинг/правила.
6. Consumers: дашборди, SLO-альберти (burn-rate), розслідування, статус-сторінка, авто-гейти релізів.

5) QoS і класи потоків

Клас A (реальний час, P1): SLI/SLO, синтетика, ключові провайдери (PSP/KYC). SLA доставки: <5–10 c, ≥99. 9%.
Клас B (операційні): трейси/логи для RCA, SLA: <1-2 хв.
Клас C (аналітичні): агрегати і батчі в lake/DWH, SLA: годину/добу.
Маршрутизація по класу → пріоритизація, різні ретенції, окремі черги/топіки.

6) Семплінг, агрегація, ретеншн

Метрики: downsampling історичних рядів (1s→10s→1m), перцентильні агрегати, exemplars.
Трейси: tail-based семплінг (піднімати частку при аномаліях, PSP-помилках, p99- «сплесках»).
Логи: рівень за профілем, стиснення, відкидання шуму (health-пінги, DEBUG на проді - заборонено).
Ретеншн: «гаряче» (7-14 днів деталь), «холодне» (агрегати/архів). Політики per-клас даних і вартість.

7) Приватність і комплаєнс

PII-гігієна: маскування/токенізація ідентифікаторів; заборона документів КУС/карткових токенів у телеметрії.
Гео-локалізація: зберігання по юрисдикціях; експорт - тільки через затверджені workflow (шифрування, TTL, аудит).
Контроль доступу: RBAC/ABAC до сховищ телеметрії, SoD на вивантаження.

8) Надійність потоків

Ідемпотентність: ключі на події, дедуп в процесорах.
Backpressure: ліміти інжесту per-тенант/сервіс; drop-політики для низькопріоритетних полів при перевантаженні.
Replays: зберігання в брокері ≥72 год для повторної обробки.
Dead-letter: маршрутизація помилок (схема, розмір, PII-порушення) в безпечний DLQ з алертами.
Версіонування: «двопоточність» при зміні схем (v1 + v2) і міграція споживачів.

9) Мульти-тенант та ізоляція

Теги'tenant _ id/brand/region'в кожній події; пертенантні квоти і бюджети.
Ізоляція потоків A/B по топіках; showback/chargeback за інжестом і зберіганням.
Маскування/агрегація до межі тенанта при експорті.

10) Каталог потоків (приклад полів)

Ідентифікатор: `telemetry. payments. auth. success. rate. eu`

Клас: A (реальний час)

Схема: `{timestamp, tenant, region, psp, bank_bin_group, success_rate, window}`

Джерело: OTel Collector + PSP-router metrics

Споживачі: SLO-алерти, Exec-дашборд, статус-сторінка

Ретеншн: гаряче 30 днів, агрегати 12 міс

Власник: Payments SRE, dpo-owner (privacy)

SLO потоку: затримка <10 c p95, втрата <0. 1 %/добу

11) Інтеграція з алертингом і релізами

SLO-алерти за burn-rate (швидке/повільне вікно) для депозитів/ставок.
Release-gates: канареечний аналіз SLI; авто-стоп/rollback при деградації.
Статус-сторінка: фід оновлень з інцидент-картки + агрегати SLI.

12) Набір ключових дашбордів

Exec: аптайм, burn-rate, успіх авторизацій/ставок (по GEO/PSP), статус провайдерів, $/RPS телеметрії.
SRE/Платформа: RED/USE по сервісах, lag черг, outlier-детекція, eBPF-профілі.
Payments/Risk: конверсія по банках/PSP, soft/hard declines, KYC SLA, ранні сигнали chargeback.
Cost-obs: обсяг інжесту за джерелами, топ-лейбли кардинальності, вартість за потоками.

13) Фінанси спостереження (FinOps)

KPI вартості: $/GB ingest, $/trace, $/SLI-дашборд; звіт по «важким» метрикам і лейблам.
Оптимізації: агрегація і downsampling, динамічний семплінг, очищення чатті-логів, клас зберігання за важливістю.
Політики: квоти на high-cardinality, ліміти на частоту емісії, review схем раз на квартал.

14) Процеси і ролі

Data/Observability Owners на домены (Payments, Games, Core API, Infra).
Change-Control для схем: PR-рев'ю, тестові стенди, сумісність у споживачах.
Tabletop/Chaos-days: відключення провайдерів, перевантаження брокера, перевірка backpressure/ідемпотентності.
Post-mortem: включати аналіз телеметрії (достатність сигналів, помилкові спрацьовування, вартість).

15) Дорожня карта впровадження (8-12 тижнів)

Нед. 1–2: аудит поточних потоків, карта джерел, цілі SLO телеметрії, вибір стандартів (OTel, TSDB, трейси, логи).
Нед. 3–4: OTel-колектори, єдиний correlation-ID, базові RED/USE + бізнес-SLI на депозит/ставку, каталог потоків v0.
Нед. 5–6: tail-based семплінг, синтетика по GEO, DLQ/ідемпотентність, privacy-фільтри.
Нед. 7–8: FinOps-панель (ingest/retention), downsampling, квоти кардинальності, SLO-альберти (burn-rate).
Нед. 9–10: eBPF/низькорівневі сигнали, статус-сторінка фід, release-gates.
Нед. 11–12: chaos-тести, оптимізація вартості, formal SLA потоків, запуск квартального review схем.

16) Шаблони артефактів

Telemetry Stream Spec: id, власник, схема, клас QoS, джерела, споживачі, ретеншн, SLO/альберти, privacy-політика.
Schema PR Template: зміна/міграція, сумісність, тести, план відкату.
Sampling Policy: правила підняття семплінгу при аномаліях; цільові бюджети.
Cost Review Pack: топ-джерела по $/цінності, пропозиції по TTL/агрегаціям.
Incident Telemetry Checklist: список графіків/трейсів/логів, які зобов'язані бути для RCA.

17) KPI/KRI потоків телеметрії

Доставка: p95 затримки по класу,% втрачених повідомлень/добу.
Покриття: частка критичних шляхів з трасингом> 90%, частка SLI, закритих метриками.
Якість сигналів: % інцидентів, спійманих по SLI до скарг, помилкові/пропущені алерти.
Вартість: $/RPS на телеметрію, $/trace, частка «шуму» в інжесті.
Надійність: час відновлення після деградації брокера, обсяг реплеїв.

18) Антипатерни

High-cardinality метрики (userId, sessionId) в TSDB.
Єдиний «чорний ящик» логів без структурування і схем.
Відсутність DLQ/ідемпотентності → дублі і втрати при піках.
«Нескінченні» ретенції без FinOps → експоненціальне зростання рахунків.
Трейси без бізнес-контексту (PSP/банк/GEO) → слабка діагностичність.
Неузгоджені схеми між командами → ламаються споживачі.

Підсумок

Потоки телеметрії - це керована, багатошарова система: OTel-стандарти і схеми → надійний інжест з QoS і backpressure → семплінг/агрегація і ретенції під вартість → приватність і мульти-тенант-ізоляція → SLO-альберти, дашборди і гейти релізів. Такий контур дає ранні сигнали, швидке RCA, передбачувані витрати і стійкість iGaming-платформи в пікових режимах.