[Azazlokus]

Что

OpenTelemetry-трассировка control-plane — итерация 34 (лейн Инфра/прод). Новый пакет
internal/tracing поднимает глобальный TracerProvider (OTLP/HTTP или stdout-экспортёр,
батч-процессор, ParentBased-семплер) + W3C-пропагатор и возвращает функцию слива
(flush+shutdown). Инструментируются только операции control-plane:

• HTTP-API — otelhttp на /api/* (серверный спан на запрос);
• join-хендшейк — ограниченный спан game.join на шлюзе (upgrade→токен→бан→комната),
  завершается ДО долгоживущей сессии; входящий traceparent извлекается из заголовков апгрейда;
• SQL — otelsql в store.Open (спаны запросов дочерние от контекста запроса).

Compose-стек (итер. 32) получил Jaeger (OTLP-приёмник + UI :16686); сервер шлёт трейсы
туда, Grafana — datasource Jaeger.

Зачем

Метрики (Prometheus) уже есть с итер. 6/25, но нет распределённой трассировки: не видно, из чего
складывается латентность запроса (HTTP → БД) и рукопожатия join. OTel даёт полный трейс
запрос→БД с разбивкой по SQL и join-фазам.

Как / границы

• Горячий путь неприкосновенен: игровой тик 30 Гц НЕ трассируется, internal/game про OTel
  не знает — тик по-прежнему 0 allocs/op (проверено бенчем). Спаны — только на control-plane.
• Выключено по умолчанию: без экспортёра остаётся глобальный no-op провайдер (нулевые
  накладные), поэтому инструментовка стоит безусловно, без ветвлений по флагу.
• Env: ARENA_OTEL_ENABLED / _ENDPOINT / _INSECURE / _STDOUT / _SAMPLE_RATIO /
  _SERVICE_NAME. Слив буферизованных спанов — при shutdown.
• Зависимости: otel SDK v1.45, otlptracehttp, stdouttrace, otelhttp v0.70, XSAM/otelsql v0.43.

Тестирование

• internal/tracing: выключено → no-op слив; stdout → реальный SDK-провайдер; экспорт спана
  через in-memory экспортёр (конвейер ресурс/семплер/батч).
• cmd/server: TestTracingConfig (env), integration TestE2ETracingJoinSpan (реальный WS:
  join зарегистрированного аккаунта даёт спан game.join + дочерний SQL-спан otelsql в ТОМ ЖЕ трейсе).
• make check (lint 0 issues + -race все пакеты) и make integration — зелёные. Тик 0 allocs/op.
• govulncheck: «вызываемые» уязвимости — только stdlib crypto/x509@go1.26 (fixed в go1.26.1;
  CI на stable Go их не видит); новые зависимости дают лишь НЕвызываемые.
• docker-compose (Jaeger) — статическая валидация YAML (Docker в dev недоступен, как в итер. 32).
• Игровые стражи не гонялись (игра/провод/симуляция/Checksum/горячий путь не тронуты).