Потоки телеметрии
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 исторических рядов (1с→10с→1м), перцентильные агрегаты, exemplars.
Трейсы: tail-based семплинг (поднимать долю при аномалиях, PSP-ошибках, p99-“всплесках”).
Логи: уровень по профилю, сжатие, отброс шума (health-пинги, DEBUG на проде — запрещено).
Ретеншн: “горячее” (7–14 дней деталь), “холодное” (агрегаты/архив). Политики per-класс данных и стоимость.
7) Приватность и комплаенс
PII-гигиена: маскирование/токенизация идентификаторов; запрет документов KYC/карточных токенов в телеметрии.
Гео-локализация: хранение по юрисдикциям; экспорт — только через утвержденные 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-платформы в пиковых режимах.