GH GambleHub

Observability и trace sampling

1) Observability не үшін

Observability (O11y) үш сұраққа жауап береді: не болып жатыр, неге, оны қалай түзету керек. Ол 4 сигналға сүйенеді:
  • Метриктер (агрегаттар, тез әрекет етеді);
  • Логи (бөлшектер мен форензика);
  • Трестер (өтпелі себеп-салдарлық байланыстар);
  • Профайлдар (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. 30 күнде 5%"). Алерттар 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-span қателерді сақтау», «canary-трафиктің 50% сэмплеу», «инцидент кезінде төлем жолдарының барлық трейдерлерін сақтау».

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 күн, агрегаттарды/симметрияларды - ұзақ сақтаңыз.
Арзан (S3 үйлесімді) қоймаға parquet/blocks қосыңыз, индекстер - ықшам.

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 бүркемелеу.
Семплинг: 'error/warn' үшін 100%, 'шу' жолдарында 'info' үшін 5-20%.
Трестерге байланыстыру - 'trace _ id' арқылы. Лог-жолдар → «pivot» трейске және керісінше.

10) Өнімдегі профайлинг

CPU/heap/alloc/locks үшін continuous profiling (Pyroscope/Parca) бағдарламасын қосыңыз.
p99 шыңдарын ыстық әйнектермен корреляциялаңыз; 7-14 күн сақтаңыз.

11) SLO/қате бюджет бойынша алертинг

SLO-алерты: «қате бюджет Х %/сағаттан тез жұмсалады» (болжамды алерты).
Симптомдар, себеп емес: CPU-ға емес, клиент деңгейіне (RUM/edge немесе пер-роут) алертит.
Multi-window, multi-burn rate: 1 сағат үшін 2% және 6 сағат үшін 5% - екі шарт.
Жоспарлы тозу кезіндегі тыныштық: фич-жалаулар/канарейка кезіндегі табалдырықтардың жылжуы.

12) Құны және ретеншн

Көлемдерге квоталар: Trace ≤ N ТБ/ай, Loi - ыстық 3-7 күн, суық S3 30-90 күн, метрика - downsampling (1 мин → 5 мин → 1 сағ).
Tail-rules қате/баяу сақтай отырып, 10- × 100 × көлемін азайтады.
Құны ең аз сигналдар - метрика; ең жоғары құндылығы - «дұрыс» трестер мен бейіндер.

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

«100% трейдерлер әрқашан» → құн жарылысы, шу және тежегіш.
Кілтсіз/бүркемелеусіз еркін пішімдегі логтар.
Шексіз лейблді метриктер (user_id/ip/full UA).
Жоқ 'traceparent '/' baggage' - корелляция мүмкін емес.
SLO орнына CPU/heap алерты - чат пайдасыз «жанады».
Қателер/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'), логтардың/метриктердің/трейстердің корреляциясы.
  • tail-sampling (errors/slow/маңызды роттар) + probabilistic default бар OTel Collector.
  • RED/USE өлшемдері, анық buckets, exemplars → трасса ауысу.
  • SLO және қате бюджет бойынша алертинг (екі уақыт шкаласы).
  • Ретенция регламенттері және телеметрия бюджеті; downsampling метрик; Логтар үшін cold storage.
  • Стандартталған JSON-лог, redaction PII/құпиялар.
  • Прондегі профайлинг қосылған; инцидентке «ыстық» стэктердің дашбордтары.
  • Канареялық дашбордтар және нұсқаларды салыстыру; «соқыр аймақсыз» шығару.
  • Runbook: оқиға болған кезде сэмплдау үлесін уақытша қалай көтеру керек.
  • Атрибуттар/белгілер неймингінің құжаттамасы және high-cardinality тыйым салу.

17) TL; DR

Корреляция айналасында бақылау жасаңыз: RED/USE → exemplars → traces → логи/профайлдар. Құрама сэмплеу арқылы құнды басқарыңыз: шағын head% + tail-ережелер (қателер, баяу, маңызды бағыттар/тенанттар). Алерталар - SLO және қателер бюджеті бойынша. Ретенцияны және түбегейлілікті бақылауда ұстаңыз, OTel Collector-ды «орталық жүйке жүйесі» ретінде пайдаланыңыз. Төлем/юрисдикциялық жолдар үшін - басым телеметрия және деректердің қатаң гигиенасы.

Contact

Бізбен байланысыңыз

Кез келген сұрақ немесе қолдау қажет болса, бізге жазыңыз.Біз әрдайым көмектесуге дайынбыз!

Telegram
@Gamble_GC
Интеграцияны бастау

Email — міндетті. Telegram немесе WhatsApp — қосымша.

Сіздің атыңыз міндетті емес
Email міндетті емес
Тақырып міндетті емес
Хабарлама міндетті емес
Telegram міндетті емес
@
Егер Telegram-ды көрсетсеңіз — Email-ге қоса, сол жерге де жауап береміз.
WhatsApp міндетті емес
Пішім: +ел коды және номер (мысалы, +7XXXXXXXXXX).

Батырманы басу арқылы деректерді өңдеуге келісім бересіз.