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-ды «орталық жүйке жүйесі» ретінде пайдаланыңыз. Төлем/юрисдикциялық жолдар үшін - басым телеметрия және деректердің қатаң гигиенасы.