Observability и trace sampling

1) რატომ Observability

• მეტრიკა (აგრეგატები, სწრაფად რეაგირებენ);
• ლოგოები (დეტალები და წინსვლა);
• ტრეისი (მიზეზობრივი კავშირების გავლა);
• პროფილები (CPU/heap/lock contention რეჟიმში).

გასაღები: კორელაცია სიგნალებს შორის + ტელემეტრიული ეკონომიკა (სემპლაცია, რენტგენოლოგია, შეკუმშვა).

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 ms, მცდარი ბიუჯეტი 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.
• კორელაცია: მომსახურების გრაფიკები, ექსპლარები, გადასვლა p99 გრაფიკიდან კონკრეტულ ტრეისამდე.

4) ტრეფიკის მოდიფიკაცია: სტრატეგია

4. 1 Head-based sampling (შესასვლელში, გამოსვლის ცოდნამდე)

მარტივი და იაფი განხორციელება (SDK/ingress).
უარყოფითი: შეიძლება გამოტოვოთ იშვიათი შეცდომები/ნელი მოთხოვნები.

როდის: მაღალი RPS, მკაცრი ბიუჯეტები, საჭიროა პროგნოზირებადი წილი (მაგალითად, 1-5%).

4. 2 Tail-based sampling (გამოსასვლელში, იცის შედეგი)

გადაწყვეტილება მიიღება კოლექტორში ძილის დასრულების შემდეგ.
თქვენ შეგიძლიათ გარანტირებული აირჩიოთ ანომალიები: შეცდომები, p99, კონკრეტული როუტები/ტენანტები.
უარყოფითი მხარეები: ბუფერიზაცია, უფრო რთული და ძვირი.

როდის: საჭიროა „მნიშვნელოვანი“ ტრეისი ზომიერი ღირებულებით.

4. 3 კომბინირებული მოდელი

გლობალური head 1-5%, პლუს tail წესები: „ყოველთვის შეინარჩუნეთ შეცდომები/slow-spans“, „შეავსეთ 50% საკაბელო ტრაფიკი“, „შეინარჩუნეთ ინციდენტის დროს გადახდის ბილიკების ყველა ტრეისი“.

5) დინამიური ნაკრები და ტელემეტრიული ბიუჯეტი

Budget-aware: შეინარჩუნეთ T ტრეისების/წთ/წთ; ჭარბი რაოდენობით - ბარიერების გაზრდა (მაგალითად, მხოლოდ p99 არჩევა). 5+, error-only).
Rules by route/tenant: მნიშვნელოვანი endpoints/tenants - უფრო დიდი წილით.
ადაპტირებული ფანჯრები: ადიდებულმა ციმციმებმა დროებით გაზარდოს შეცდომების/ნელი.
კარდინალობის დაქვეითება: შეამოწმეთ საიდუმლოებები, 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 ლოკი - ლოგების ღირებულების შემცირება

ეტიკეტები მხოლოდ სტაბილურია ('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', 'provider', 'game _ id'.

7. 2 მოვლენები და კავშირები

Spanevents: მნიშვნელოვანი წერტილები (DB გარიგების დასაწყისი, retray, ღია ცის ქვეშ, cache miss).
Links: მოთხოვნის კავშირი - ვებჰუკი/მოვლენა; სასარგებლოა EDA და outbox/inbox.

7. 3 ეგზემპლარები

დაამატეთ მაგალითები 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.
მნიშვნელოვანი ხრიკები: დრო-ვალეტი, success-rate payout.

8. 3 კარდინალობა და შენახვა

ჰისტოგრამები აშკარა ბუკეტებით (მაგალითად, '[50.100.300.5000,1000,2000] mms').
თავიდან აიცილეთ ეტიკეტები მაღალი კარდინალურობით (raw user _ id, request _ id) - გადაიტანეთ logs/traces.

9) ლოგოები: სტანდარტები და კორელაცია

ფორმატი: JSON + საჭირო გასაღებები ('timestamp', 'level', 'მესიჯი', 'trace _ id', 'spank _ id', 'service', 'env').
რედაქტირება: შენიღბეთ PAN, ნიშნები, PII.
Sempling: 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 ან per-rout), და არა CPU- ზე.
Multi window, multi-burn: 2% 1 საათში და 5% 6 საათში - ორი პირობა.
დუმილი დაგეგმილი დეგრადაციებისთვის: ბარიერების შეცვლა წინა დროშების/კანარის ქვეშ.

12) ღირებულება და ჭრა

მოცულობის კვოტები: ტრეისები N TB/თვე, ლომბარდი - ცხელი 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%“ სამპლინგი შეცდომების პრიორიტეტის გარეშე/ნელი - დაკარგეთ ღირებული შემთხვევები.

14) დაშბორდის მაგალითები (ჩონჩხი)

API Overview: RPS, error-rate კლასებში, latency p95/p99 (exemplars clickabelns), ტოპ როუტები.
Release/Canary: ძველი/ახალი ვერსიის მეტრიკის შედარება, outlier-rate, Open-circuits, retries.
PSP/KYC: success-rate პროვაიდერების, ლატენციისა და უარის თქმის შესახებ, კორელაცია payout შეცდომებთან.
Infra: USE რესურსების, სატურნის რიგების, ქსელის განადგურების შესახებ.

15) iGaming/ფინანსების სპეციფიკა

კრიტიკული გზები (დეპოზიტები/დასკვნები): 100% ვაჭრობა მხოლოდ ინციდენტებით ან შეზღუდული ფანჯრებით; ნორმალურ რეჟიმში - tail „ყველაფერი შეცდომით/გრძელი ლატენტობით“.
რეგიონი/ტენანტი: დაამატეთ 'tenant', 'jurisdiction', 'brand' baggage; ააშენეთ SLO იურისდიქციით.
ანტიფროდი/ბოტი ფილტრი: მეტრიკა და Risk API გადაწყვეტილებების ტრეისი (allow/deny/challenge), challenge-pass-rate, velocity-hits.
აუდიტი/შესაბამისობა: შეინახეთ მინიმალური, PII გარეშე; უცვლელი ჟურნალები - ცალკე წრეში.

16) მზადყოფნის სიის სია

• პროპაგანდა ('traceparent', 'baggage'), ლოგოების/მეტრიკის/ტრასის კორელაცია.
• OTel Collector ერთად tail-sampling (errors/slow/მნიშვნელოვანი routs) + probabilistic default.
• RED/USE მეტრიკები, აშკარა ბუკეტები, ექსპლარები - გადასვლა ტრეისზე.
• SLO და ალერტინგი არასწორი ბიუჯეტისთვის (ორი დროებითი მასშტაბის).
• რეგლამენტი და ტელემეტრიული ბიუჯეტი; downsampling მეტრიკა; cold სცენა ლოგებისთვის.
• სტანდარტიზებული JSON ჟურნალი, redaction PII/საიდუმლოებები.
• პროფილინგი შედის გაყიდვაში; ინციდენტის ცხელი გაფიცვის დაშბორდები.
• კანარის დაშბორდები და ვერსიების შედარება; გამოშვება „უსინათლო ზონების“ გარეშე.
• Runbook: როგორ დროებით გაზარდოს ინციდენტის წილი.
• ატრიბუტების/ეტიკეტების ნეიმინგის დოკუმენტაცია და მაღალი სტანდარტების აკრძალვა.

17) TL; DR

ააშენეთ დაკვირვება კორელაციის გარშემო: მეტრიკა RED/USE - exemplars - ტრეისები, ლოგოები/პროფილები. აკონტროლეთ ღირებულება კომბინირებული სიმულაციით: მცირე head% + tail წესები (შეცდომები, ნელი, მნიშვნელოვანი მარშრუტები/ტენანტები). ალერტები - SLO და შეცდომების ბიუჯეტი. შეინარჩუნეთ რეტენციები და კარდინალობა კონტროლის ქვეშ, გამოიყენეთ OTel Collector, როგორც „ცენტრალური ნერვული სისტემა“. გადახდის/იურისდიქციის გზებისთვის - პრიორიტეტული ტელემეტრია და მონაცემთა მკაცრი ჰიგიენა.