Observability и trace sampling

1) Зачем Observability

• Метрики (агрегаты, быстро реагируют);
• Логи (детали и форензика);
• Трейсы (сквозные причинно-следственные связи);
• Профайлы (CPU/heap/lock contention в режиме prod).

Ключ: корреляция между сигналами + экономика телеметрии (сэмплирование, ретенции, сжатие).

2) Карта сигналов и принципы

2.1 RED/USE

RED (для API): Rate (RPS), Errors (% 5xx/4xx важные), Duration (p50/p95/p99).
USE (для ресурсов): Utilization, Saturation, Errors (NIC, CPU, диск, очереди).

2.2 Инварианты продукта

Определите SLO (например, «p95 латентности `/v1/payments` ≤ 300 мс, ошибочный бюджет 0.5% в 30 дней»). Алерты должны «кричать» только при нарушении SLO или его сгорании.

2.3 Контекст

Внедрите W3C Trace Context (`traceparent`, `tracestate`) и baggage для безопасной передачи тех/бизнес-атрибутов (например, `tenant`, `region`, без PII).

3) Архитектура наблюдаемости

SDK/автоинструментация: OpenTelemetry (OTel) в сервисах (HTTP/gRPC/DB/клиенты).
OTel Collector как шина: прием → обогащение → сэмплирование → экспорт (Prometheus, Tempo/Jaeger, Loki/ELK, ClickHouse).

• Метрики: Prometheus/Mimir/VictoriaMetrics;
• Трейсы: Tempo/Jaeger/Zipkin;
• Логи: Loki/ELK/Vector→S3+дешевое хранилище;
• Профайлы: Pyroscope/Parca.
• Корреляция: графы сервисов, exemplars, переход из графика p99 в конкретный трейс.

4) Сэмплирование трейсинга: стратегии

4.1 Head-based sampling (на входе, до знания исхода)

Простая и дешевая реализация (в SDK/ingress).
Минусы: может пропустить редкие ошибки/медленные запросы.

Когда: высокие RPS, строгие бюджеты, требуется предсказуемая доля (например, 1–5%).

4.2 Tail-based sampling (на выходе, зная исход)

Решение принимается в Collector после завершения спана.
Можно гарантированно отбирать аномалии: ошибки, p99, конкретные роуты/тенанты.
Минусы: буферизация, сложнее и дороже.

Когда: нужны «значимые» трейсы при умеренной стоимости.

4.3 Комбинированная модель

Глобальный head 1–5%, плюс tail-правила: «всегда сохранять ошибки/slow-спаны», «сэмплировать 50% canary-трафика», «сохранять все трейсы платежных путей при инциденте».

5) Динамическое сэмплирование и бюджет телеметрии

Budget-aware: удерживать объем ≤ N трейсов/мин; при превышении — повышать пороги (например, отбирать только p99.5+, error-only).
Rules by route/tenant: важные эндпоинты/тенанты — с большей долей.
Адаптивные окна: всплески → временно увеличивать долю ошибок/медленных.
Снижение кардинальности: нормализуйте user-agent, IP/ASN, squash stack traces, маскируйте секреты.

6) Конфиги (референсы)

6.1 OpenTelemetry Collector — tail-sampling (yaml-фрагмент)

yaml receivers:
otlp: { protocols: { http: {}, grpc: {} } }

processors:
batch: { send_batch_size: 8192, timeout: 2s }
tail_sampling:
decision_wait: 5s num_traces: 100000 expected_new_traces_per_sec: 5000 policies:
- name: always-error type: status_code status_code: { status_codes: [ERROR] }
- name: slow-endpoints type: latency latency: { threshold_ms: 300 }      # p95 цель
- name: important-routes type: string_attribute string_attribute: { key: http. target, values: ["/v1/payments", "/v1/payouts"] }
- name: tenant-eu1 type: string_attribute string_attribute: { key: tenant, values: ["eu-1"] }
- name: probabilistic-default type: probabilistic probabilistic: { sampling_percentage: 5. 0 }

exporters:
otlphttp/tempo: { endpoint: http://tempo:4318 }
prometheus: { endpoint: "0. 0. 0. 0:9464" }

service:
pipelines:
traces:
receivers: [otlp]
processors: [batch, tail_sampling]
exporters: [otlphttp/tempo]

6.2 Prometheus — exemplars (фрагмент)

В приложении при записи гистограмм добавляйте exemplars с `trace_id`. В Grafana клики по «иголкам» ведут в трейс.

yaml scrape_configs:
- job_name: api scrape_interval: 10s honor_labels: true static_configs: [{ targets: ["api:9100"] }]
exemplar_limit: 10

6.3 Loki — снижение стоимости логов

Метки только стабильные (`service`, `env`, `region`, `route_class`).
Высокая кардинальность (request_id, user_id) — в payload, но с redaction.
Семплируйте «успешные» инфо-логи, сохраняйте все ошибки/предупреждения.

6.4 Jaeger/Tempo — ретеншн и индекс

Храните сырые трейсы 3–7 дней, агрегаты/симметрии — дольше.
Включите parquet/blocks в дешевом хранилище (S3-совместимом), индексы — компактные.

7) Моделирование трейсинга

7.1 Именование и атрибуты

`service.name`, `service.version`, `deployment.environment`.
`http.method`, `http.route`, `http.target`, `http.status_code`, `net.peer.name`.
Бизнес-атрибуты без PII: `tenant`, `region`, `payment_provider`, `game_id`.

7.2 События и связи

Span events: важные точки (начало DB транзакции, ретрай, circuit open, cache miss).
Links: связь запрос→вебхук/событие; полезно для EDA и outbox/inbox.

7.3 Экземпляры (exemplars)

Добавляйте к гистограммам latency/size примеры с `trace_id`: навигация «из метрики → в трейс» за один клик.

8) Метрики: какие и как

8.1 Технические

RED по маршрутам/тенантам/провайдерам (PSP, KYC).
Пулы: `db_connections_in_use`, `http_client_in_flight`, `queue_depth`.
Стабилизация: retries, timeouts, circuit open/half-open, rate-limit hits.
Go/Java/Python runtime: GC паузы, heap, safepoints, GIL-задержки.

8.2 Бизнес-метрики

Регистрации/логины/депозиты/выводы, конверсия, провалы 3DS/KYC, chargeback-ratio.
Важные фичи: time-to-wallet, success-rate payout.

8.3 Кардинальность и хранение

Гистограммы с явными buckets (например, `[50,100,200,300,500,1000,2000] ms`).
Избегайте меток с высокой кардинальностью (raw user_id, request_id) — выносить в логи/трейсы.

9) Логи: стандарты и корреляция

Формат: JSON + необходимые ключи (`timestamp`, `level`, `message`, `trace_id`, `span_id`, `service`, `env`).
Редактирование: маскируйте PAN, токены, PII.
Семплинг: 100% для `error/warn`, 5–20% для `info` на «шумных» путях.
Привязка к трейсам — через `trace_id`. Лог-строки → «pivot» в трейс и наоборот.

10) Профайлинг в проде

Включите continuous profiling (Pyroscope/Parca) для CPU/heap/alloc/locks.
Коррелируйте пики p99 с горячими стеками; храните 7–14 дней.

11) Алертинг по SLO/ошибочному бюджету

SLO-алерты: «ошибочный бюджет расходуется быстрее X%/час» (прогнозирующие алерты).
Симптомы, не причины: алертите на уровень клиента (RUM/edge или пер-роут), а не на CPU.
Multi-window, multi-burn rate: 2% за 1 ч и 5% за 6 ч — два условия.
Тишина при плановых деградациях: сдвиг порогов при фиче-флагах/канарейке.

12) Стоимость и ретеншн

Квоты на объемы: трейсы ≤ N ТБ/мес, логи — горячее 3–7 дней, холодное S3 30–90 дней, метрики — downsampling (1 мин → 5 мин → 1 ч).
Tail-rules снижают объем ×10–×100, сохраняя ошибочные/медленные.
Сигналы с наименьшей стоимостью — метрики; с наибольшей ценностью — «правильные» трейсы и профайлы.

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

«100% трейсы всегда» → взрыв стоимости, шум и тормоза.
Логи в свободном формате без ключей/маскирования.
Метрики с бесконечными лейблами (user_id/ip/full UA).
Нет `traceparent`/`baggage` — корелляция невозможна.
Алерты на CPU/heap вместо SLO — чат «горит» без пользы.
Сэмплирование «рандом 1%» без приоритета ошибок/slow — теряете ценные кейсы.

14) Примеры дашбордов (скелеты)

API Overview: RPS, error-rate по классам, latency p95/p99 (exemplars кликабельны), топ-роуты.
Release/Canary: сравнение метрик старой/новой версии, outlier-rate, open-circuits, retries.
PSP/KYC: success-rate по провайдерам, latency и откази, корреляция с payout-ошибками.
Infra: USE по ресурсам, saturation очередей, network drops.

15) Специфика iGaming/финансов

Критичные пути (депозиты/выводы): 100% трейсинг только при инцидентах или ограниченных окнах; в штатном режиме — tail «все с ошибкой/долгой латентностью».
Регион/тенант: добавляйте `tenant`, `jurisdiction`, `brand` в baggage; строите SLO по юрисдикции.
Антифрод/бот-фильтр: метрики и трейсы решений Risk API (allow/deny/challenge), challenge-pass-rate, velocity-hits.
Аудит/комплаенс: хранить минимально необходимое, без PII; неизменяемые журналы — в отдельном контуре.

16) Чек-лист prod-готовности

• Сквозная пропагация (`traceparent`, `baggage`), корреляция логов/метрик/трейсов.
• OTel Collector с tail-sampling (errors/slow/важные роуты) + probabilistic default.
• RED/USE метрики, явные buckets, exemplars → переход в трейс.
• SLO и алертинг по ошибочному бюджету (две временные шкалы).
• Регламенты ретенции и бюджет телеметрии; downsampling метрик; cold storage для логов.
• Стандартизированный JSON-лог, redaction PII/секретов.
• Профайлинг в проде включен; дашборды «горячих» стэков на инцидент.
• Канареечные дашборды и сравнение версий; выпуск без «слепых зон».
• Runbook: как временно поднять долю сэмплирования при инциденте.
• Документация нейминга атрибутов/меток и запрет high-cardinality.

17) TL;DR

Стройте наблюдаемость вокруг корреляции: метрики RED/USE → exemplars → трейсы → логи/профайлы. Управляйте стоимостью через комбинированное сэмплирование: небольшой head% + tail-правила (ошибки, медленные, важные маршруты/тенанты). Алерты — по SLO и бюджету ошибок. Держите ретенции и кардинальность под контролем, используйте OTel Collector как «центральную нервную систему». Для платежных/юрисдикционных путей — приоритетная телеметрия и строгая гигиена данных.