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+deshevoye сховище;
• Профайли: 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: зв'язок zapros→vebkhuk/sobytiye; корисно для 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-алерти: «помилковий бюджет витрачається швидше Х %/год» (прогнозуючі алерти).
Симптоми, не причини: алертит на рівень клієнта (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 як «центральну нервову систему». Для платіжних/юрисдикційних шляхів - пріоритетна телеметрія і сувора гігієна даних.