Наблюдаемость и телеметрия

(Раздел: Технологии и Инфраструктура)

Краткое резюме

Наблюдаемость — это способность отвечать на «почему оно так работает?» без релиза новых билдов. В iGaming это критично: пиковые турниры, платежные пики, многорегиональность и требования по ответственному гэмблингу/PII. Базис — метрики, логи, трассировки, объединенные общими идентификаторами и стандартами (OpenTelemetry), с SLO-контрактами, шумоустойчивым алертингом и контролем стоимости.

1) Каркас наблюдаемости: из чего он состоит

Метрики (числа по времени): RED/USE, бизнес-KPI, SLI. Хранятся в TSDB.
Логи (события в текст/JSON): аудит, ошибки, бизнес-факты, безопасность.
Трассировки (спэны): путь запроса через сервисы, латентности, причины задержек.
Профайлинг: CPU/память/eBPF-потоки, heap/lock-контеншн.
RUM и синтетика: реальные пользователи (web/app) + робот-проверки.
Каталог телеметрии: схемы, политики PII, сроки хранения, тэги стоимости.

2) Таксономия сигналов и принципы

RED для API: Rate, Errors, Duration.
USE для инфраструктуры: Utilization, Saturation, Errors (CPU, диски, сеть, очереди).
SLI/SLO: измеряемые индикаторы (например, успешные запросы/все, p95 latency), цели доступности (напр., «99.9% за 30 дней»), бюджет ошибок → триггеры процессов.
High-cardinality с умом: лейблы должны быть полезны в разрезах (регион/тенант/провайдер), но не взрывать TSDB.

3) Стандарты и сквозная корреляция

OpenTelemetry (OTel): единый SDK/протокол для метрик, логов и трассировок.
Идентификаторы: `trace_id`, `span_id`, `correlation_id`, `player_id` (псевдонимизированный), `payment_route`.
Протекание ID: входной шлюз → все микросервисы → платежи/PSP → очереди/джобы → логи/метрики/спэны.

Пример: заголовки корреляции

traceparent: 00-<trace_id>-<span_id>-01 x-request-id: <correlation_id>

4) Метрики: что и как измеряем

Именование/лейблы

`service="payments-api"`, `env="prod"`, `region="eu-west"`, `tenant`, `provider="pspX"`.

Примеры Prometheus

prometheus
RED http_requests_total{service="api",route="/deposit",method="POST",status="200"}
http_request_duration_seconds_bucket{service="api",le="0. 25",route="/deposit"} 1234 http_request_errors_total{service="api",route="/deposit"}

USE cpu_utilization_ratio{node="n1"} 0. 71 queue_depth{queue="withdrawals"} 128

Бизнес payments_success_total{psp="X",currency="EUR"} 4521 payment_conversion_ratio{route="pspX"} 0. 948

Гистограммы и exemplars

Храните гистограммы латентности (native-histograms/βuckets) и привязывайте exemplar с `trace_id` для прыжка от «медленного бакета» к конкретной трассе.

5) Логи: структурировано и безопасно

Только JSON (никакого «free-form» в проде).
Поля: `timestamp`, `severity`, `service`, `trace_id`, `correlation_id`, `player_id_hash`, `event`, `amount`, `currency`, `ip_hash`.
Маскирование/хэширование PII, отдельные индексы/retention для чувствительного.
Пайплайны логов: парсинг → нормализация → обогащение (geo/ASN) → редактирование PII → индексация.

Пример JSON-события

json
{
"ts":"2025-11-05T10:42:31Z",
"sev":"ERROR",
"service":"payments-api",
"event":"psp_timeout",
"trace_id":"9c5e...e2",
"route":"pspX",
"duration_ms": 3100,
"attempt":2,
"player_id_hash":"p:1b7f...",
"pii_redacted":true
}

6) Трассировки: где теряется время

Спэны: входной запрос, вызовы провайдеров (PSP/игровые провайдеры), БД/кэш, межсервисные RPC.
Атрибуты: `db.system`, `net.peer.name`, `messaging.system`, `psp.route`, `game.provider`.

• head-based (вероятностный) для объема,
• tail-based (по условиям: ошибки, p95+, VIP-сегмент),
• guaranteed-keep для платежных/PII-критичных.

7) Наблюдаемость фронта и мобайла

RUM: TTFB, FCP/LCP/CLS/INP, ошибки JS, сети и SPA-роутинг.
Краш-репорты: символикация, деобфускация, версия билда, устройство/OS.
Синтетика: сценарии входа/депозита/ставки; геораспределенные проверки.

8) SLO, SLI и бюджет ошибок

Пример SLO (псевдо-YAML)

yaml service: payments-api sli:
- name: availability expr: sum(rate(http_requests_total{status=~"2..    3.."}[5m]))
/ sum(rate(http_requests_total[5m]))
- name: latency_p95 expr: histogram_quantile(0. 95, rate(http_request_duration_seconds_bucket[5m]))
targets:
availability: "99. 9%/30d"
latency_p95: "<=250ms/30d"
error_budget_policy:
fast_burn: 5% for 1h -> page, freeze deploy slow_burn: 20% for 24h -> incident, improvement plan

Алертинг по бюджету ошибок, а не по «каждой метрике».
Freeze-процедуры при сгорании бюджета: ограничить релизы/канарею.

9) Алертинг без шума

Multi-window, multi-burn правила: короткое/длинное окно.
Дедупликация/рутинг: по сервисам/регионам/критичности в on-call.
Runbook URL и автосбор контекста (последние деплои, изменения конфигов, граф зависимости).
Тихие часы и подавление во время плановых работ.

Пример правила (идея PromQL)

promql alert: PaymentsSLOFastBurn expr: slo_error_rate_5m > 2 slo_budget_rate for: 15m labels: { severity="page", service="payments-api" }
annotations:
summary: "SLO fast burn"
runbook: "https://runbooks/payments/slo"

10) Профайлинг и eBPF

eBPF/профайлеры: flame-графы CPU/alloc, I/O-латентность, сетевые дропы, Syscall-аномалии.
Полезно при узких местах p99, «джиттере» и редких зависаниях.

11) Бизнес-наблюдаемость (product & risk)

Финансы/монетизация: конверсия депозитов, TTW (time-to-wallet), авториз./сеттл, отмены/чарджбеки.
Игровая активность: ретеншн/стрик, доля live-ставок, «липкость» провайдеров.
Антифрод/абьюз: скорость действий, совпадения устройств/IP, корреляции.
RG-индикаторы: длительные сессии, «догон», рост стейков.
Бизнес-метрики коррелируются с техметриками и релизами (annotation events).

12) Безопасность, PII и соответствие

Data-zones: теги датасетов/логов (`pii=true`, `region=EU`).
Маскирование до индексации, псевдонимизация идентификаторов.
WORM-хранилища для аудита; ролевой доступ к логу.
Сроки хранения: разные для техлогов/аудита/бизнеса.
Запрет сырых секретов в логах; скан-проверки в CI.

13) Управление стоимостью (FinOps)

Лимит кардинальности: осторожно с `user_id`, `session_id`.
Партиционирование/ретеншн: горячее (7–14 дней), теплое (30–90), холодное (архив).
Сэмплинг трасс (tail-based) и downsampling метрик.
Биллинг по тегам `team`, `service`, `tenant`: отчеты «кто сжигает наблюдаемость».

14) Инструментарий (референс-стек)

Метрики: Prometheus/лэйк для метрик, дашборды Grafana.
Логи: Loki/ELK; ingestion правила, reduction/парсинг.
Трейсы: Tempo/Jaeger/OTel-коллекторы; exemplars-линки из метрик.
Синтетика: Blackbox-экспортер, браузерные роботы.
Alerting: Alertmanager/чат-интеграции, on-call ротации.
Профайлинг: eBPF/continuous profiling.

15) Примеры: быстро внедрить основу

python from prometheus_client import Counter, Histogram, start_http_server reqs = Counter('http_requests_total','', ['route','method','status'])
lat = Histogram('http_request_duration_seconds','', ['route'])
def handle(req):
with lat. labels(route=req. route). time():
status = app(req)
reqs. labels(route=req. route,method=req. method,status=str(status)). inc()

go tid:= ctx. Value("trace_id")
logger = logger. With("trace_id", tid)
logger. Info("deposit-accepted", "amount", amt, "route", route)

prometheus http_request_duration_seconds_bucket{..., le="0. 25"} 1023 # exemplar: trace_id=9c5e...

16) Процессы и операционка

Единый словарь метрик/лейблов (naming-guide) и шаблон дашбордов.
Release-annotations автоматом в графах.
Инциденты: карточка, таймлайн, RCA без обвинений, action items.
Учебные тревоги («game-day»): имитации падений, задержек PSP, перегрева кэша.
Runbooks: пошаговые инструкции и автоссылки из алертов.

17) Чек-лист зрелости

1. OTel SDK/коллектор → единый экспорт метрик/логов/трейсов.
2. RED/USE покрывают все сервисы + SLI/SLO по ключевым API.
3. Корреляция `trace_id` ⇄ логи ⇄ метрики (exemplars, jump-links).
4. Алерты по бюджету ошибок с multi-burn и рунабук-ссылками.
5. RUM + синтетика на «депозит/ставка/вывод».
6. Профайлинг (eBPF) на проде по белому списку.
7. PII-политики: маскирование, зоны, доступ, сроки хранения.
8. Финансовый отчет по стоимости телеметрии (теги `team/service`).
9. «Готовность к пиковой нагрузке»: тест-план, прогрев кэшей, alert-шаблоны.
10. Регулярные RCA и пересмотр SLO/порогов.

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

Логи «простынями» без структуры и `trace_id`.
Алерты по каждой метрике → алерт-фэтИг.
Гистограммы без корректных бакетов → «плоские» p95.
Неограниченная кардинальность лейблов → взрыв стоимости.
Отсутствие RUM/синтетики — «все ок», а пользователю нет.
Смешение PII с техлогами, бессрочная ретенция.
Изоляция телеметрии от бизнес-KPI — «латентность падает, выручка тоже».

Итоги

Сильная наблюдаемость — это общий язык между продуктом, SRE, безопасностью и платежами. Соединив метрики, логи, трассы под OTel, введя SLO с бюджетом ошибок, сделав алертинг умным и стоимость управляемой, вы получаете систему, которая раньше замечает проблемы, быстрее восстанавливается и предсказуемо проходит пики трафика и турнирные нагрузки.