Distributed Tracing

(განყოფილება: ტექნოლოგიები და ინფრასტრუქტურა)

მოკლე რეზიუმე

განაწილებული ტრეკები იძლევა პასუხს კითხვაზე, თუ სად და რატომ იკარგება დრო მოთხოვნის გზაზე კარიბჭის, API, რიგების, მონაცემთა ბაზის, გარე პროვაიდერების მეშვეობით (PSP/თამაშის სტუდიები). OpenTelemetry (OTel) არის SDK/აგენტის/პროტოკოლის ღია სტანდარტი, რომელიც აერთიანებს ტრასებს, მეტრიკებსა და ლოგებს. IGaming- ში ეს არის ძირითადი ინსტრუმენტი, რომ შეინარჩუნოს p95/p99, სწრაფად მოახდინოს გადახდის პრობლემების ლოკალიზაცია და პიკის ტურნირებამდე „ვიწრო ადგილების“ იდენტიფიცირება.

1) OTel კონცეფციები

Trace - ოპერაციის სრული გზა (ანაბარი, ფსონი, დასკვნა).
Span არის სამუშაო ადგილი (HTTP ჰენდლერი, SQL მოთხოვნა, რიგის ზარი/პროვაიდერი).
Attributes არის გასაღები მნიშვნელობა დეტალებით ('net. peer. name`, `db. system`, `psp. route`).
Events - მყისიერი მოვლენები (retray, Timaut, ქეში გამოტოვება).
ბმულები - კავშირი სხვა ტრეკებთან (მნიშვნელოვანია ასინკ/queue- სთვის).
Resource - პროცესის მეტამონაცემები: 'service. name`, `service. version`, `deployment. environment`, `cloud. region`.

2) კონტექსტის პროპაგანდა

traceparent: 00-<trace_id>-<span_id>-01 tracestate:...

გარდა ამისა - უსაფრთხო ღილაკების დაბომბვა (მაგალითად, 'tenant', 'route'), იქ არ განათავსოთ PII.

სად უნდა მოხდეს კონტექსტი: API კარიბჭე - შიდა RPC - პროდიუსერი, როგორც გარე HTTP (PSP/პროვაიდერები).

3) სემანტიკური კონვენციები (სავალდებულო მინიმუმი)

HTTP/RPC: `http. method`, `http. route`, `http. status_code`.
DB/ქეში: 'db. system` (`mysql`/`postgresql`/`redis`), `db. statement '(შენიღბული),' db. operation`.
რიგები: 'messaging. system` (`kafka`/`rabbitmq`), `messaging. destination`, `messaging. operation` (`send`/`process`).
გადახდები: 'psp. route`, `psp. provider`, `payment. id '(ფსევდონიმი),' amount ',' currency '.
iGaming დომენი: 'game. provider`, `game. session_id` (hash), `player. id_hash`.

ერთიანი ტაქსონომია არის დაშბორდების შედარება და მიზეზების სწრაფი ძებნა.

4) სამპლინგი: როგორ არ დაიხრჩო მონაცემები

Head-based (მოთხოვნის შეყვანა)

მარტივი, იაფი; შესაფერისია ზოგადი ნაკადისთვის.
მინუს - შეგიძლიათ დაკარგოთ „საინტერესო“ ნელი/არასწორი მარშრუტები.

Tail-based (в Collector)

გადაწყვეტილება მიიღება სპანების დასრულების შემდეგ: ჩვენ მხოლოდ ვიცავთ შეცდომებს/ნელი/მნიშვნელოვან სეგმენტებს (VIP/გადახდები).
იდეალურია სარეკლამო დატვირთვისთვის: მნიშვნელოვნად ამცირებს ღირებულებას მაღალი ინფორმატიკით.

• Head: 5-10% „ფონის“ საფარისთვის.
• Tail: შეცდომების 100% + p95 + ნელი + გადახდის მარშრუტები/კანარის გამოშვებები.

5) OpenTelemetry Collector ტოპოლოგია

Agent sidcar (თითოეულ კვანძზე/პოდზე): ადგილობრივი მიღება, მინიმალური ბუფერი, აგრეგატორში ექსპორტი.
Gateway (კასეტა): tail-sampling, მარშრუტიზაცია, გამდიდრება, ექსპორტი Tempo/Jaeger/Zipkin/OTLP- ში.

მაგალითი: tail-sampling (YAML ფრაგმენტი)

yaml processors:
tailsampling:
decision_wait: 5s policies:
- name: errors type: status_code status_code:
status_codes: [ ERROR ]
- name: slow_p95 type: latency latency:
threshold_ms: 250
- name: payments type: string_attribute string_attribute:
key: service. name values: [ "payments-api", "payments-worker" ]

6) კორელაცია მეტრიკებით და ლოგებით

დაამატეთ 'trace _ id '/' spank _ id' თითოეულ ლოგოს ჩანაწერში.
ლატენტობის მეტრიკა შეინახეთ როგორც ჰისტოგრამები და ჩართეთ exemplars - წარმომადგენლობითი 'trace _ id „ბმული“ p95-ყუთიდან კონკრეტულ ბილიკამდე „გადასვლისთვის“.
გამოშვების მენიუ (Git SHA, გრაფიკის ვერსია) - როგორც events/ეტიკეტები.

7) ინსტრუმენტალიზაცია (ენები და ავტო აგენტები)

Go (სახელმძღვანელო + მანქანა)

go tp:= sdktrace. NewTracerProvider(
sdktrace. WithBatcher(exporter),
sdktrace. WithResource(resource. NewWithAttributes(
semconv. SchemaURL,
semconv. ServiceName("payments-api"),
)),
)
otel. SetTracerProvider(tp)

ctx, span:= tracer. Start(ctx, "Deposit")
defer span. End()
span. SetAttributes(
attribute. String("psp. route","pspX"),
attribute. String("currency","EUR"),
)

Java

ავტო აგენტი '-javaaagent: opentelemetry-javaagent. jar ', ჩამორთმეული env (' OTEL _ SERVER _ NAME ',' OTEL _ EXPORTER _ OTLP _ ENDPOINT ').
ხელით - ხახვის ადგილების მენიუ/ინსტრუმენტი (JDBC აუზები, ქეში).

Node. js / Python

მანქანის ინსტრუმენტი SDK + მოდულებით (Express/FastAPI/celery).
რიგებისთვის - მწარმოებლის/კონსუტერის შეფუთვა, რომ დადგინდეს 'მესიჯი.' და ბმულები.

8) რიგები და ასინსი: სწორი ძილი

პროდიუსერი ('send'): span გაგზავნეთ ტოპიკზე/რიგში.
Consumer ('process'): შეტყობინებების დამუშავების ახალი პაკეტი ლინკიდან მწარმოებლის span- მდე (შეინარჩუნეთ მიზეზობრივი კავშირი საერთო 'trace _ id' გარეშე).
ატრიბუტები: 'messaging. kafka. partition`, `messaging. rabbitmq. routing_key`, `messaging. message_id`.
სიტყვით გამოსვლისას - ღონისძიება 'retry', მცდელობის მრიცხველი.

9) BD/ქეში და N + 1

ჩართეთ BD დრაივერების ტრეისინგი, შეუკვეთეთ იგივე ტიპის მოთხოვნები ბატებში.
Redis/ქეში - cache ატრიბუტები. hit`/`cache. miss`.
მიიტანეთ „მძიმე“ მოთხოვნები ცალკეულ სპანებში - ხედავთ სად არის p99.

10) გარე პროვაიდერები: PSP/თამაშის სტუდიები

გადააკეთეთ HTTP კლიენტები: 'psp. provider`, `psp. route`, `timeout_ms`, `attempt`.
შეაფასეთ კოდები/შეცდომების ტიპები, მაგრამ არა PII (ბარათის ნომერი, ნიშნები).
შეადარეთ სტუდიები/მარშრუტები 'duration', 'error-rate'.

11) Frontend და RUM

OTel Web SDK: `page_view`, `resource_load`, `xhr`.
გადაიტანეთ 'traceparent' ზურგჩანთაში, რათა გაიაროთ მომხმარებლის ბილიკი UI-API BD.
ქსელის გეო/პროვაიდერების სეგმენტი არჩევითი ეტიკეტებია.

12) უსაფრთხოება და PII

ნიღაბი ველები ('db. სერტიფიკატი 'რედაქტირებით), დააყოვნეთ' player _ id '.
მონაცემთა ზონები: 'pii = true', 'region = EU/TR/LATAM'.
გადახდის ბილეთებზე წვდომის კონტროლი (როლი დაფუძნებულია).
WORM/Retention: მგრძნობიარე კვალი შენახვის დრო, პოლიტიკის მოცილება.

13) პროდუქტიულობა და ღირებულება

Tail-sampling პოლიტიკაში: „შეცდომები + ნელი + გადახდა + კანარის გამოშვებები“.
Downsampling histogram metrick, logs აგრესიული დედაპლიკაცია.
კარდინალობის შეზღუდვა: არ დაიწეროთ 'user _ id', როგორც მეტრიკის ეტიკეტი.
ბუფერები/ბატები კოლექტორში, OTLP კომპრესია.

14) დაშბორდი და ანალიზი

მომსახურება: სერვისების დამოკიდებულება, შეცდომა/ლატენტობა.
Release compare: სტაბილური vs კანარის გადასინჯვა (p95, error-rate, payments conv).
Top slow traces: მარშრუტზე '/deposit ', ჭრა PSP/რეგიონში.
Queue lag: მარშრუტები ღრმა მოხმარების შეფერხებით.

15) კოლექტორის კონფიგურაციის მაგალითები

Pipelines (მეტრიკა/ტრეისი/ლოგები, ფრაგმენტი)

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

processors:
batch:
memory_limiter:
limit_mib: 1024 spike_limit_mib: 256 attributes/payments:
actions:
- key: "psp. provider"
action: insert value: "pspX"

exporters:
otlp/traces: { endpoint: tempo:4317, tls: { insecure: true } }
otlp/metrics:{ endpoint: prometheus-otlp:4317, tls: { insecure: true } }
otlp/logs:  { endpoint: loki-otlp:4317, tls: { insecure: true } }

service:
pipelines:
traces:
receivers: [ otlp ]
processors: [ memory_limiter, batch, tailsampling ]
exporters: [ otlp/traces ]
metrics:
receivers: [ otlp ]
processors: [ batch ]
exporters: [ otlp/metrics ]
logs:
receivers: [ otlp ]
processors: [ batch ]
exporters: [ otlp/logs ]

16) Runbooks (ტიპიური სცენარები)

ა) ზრდა p99 'payments-ap'

1. გახსენით „Top slow traces“ - ის სპილოები BD/PSP.
2. თუ PSP პრობლემა არის მარშრუტის გადაცემა, ჩართეთ retrais/Timauts.
3. შეამოწმეთ 'withdrawals' რიგები, გაზარდეთ კონსიუმერები.

ბ) 5xx შეცდომები გამოშვების შემდეგ

1. სერვისის ფილტრი. version`.
2. შეადარეთ სტაბილური/კანარი; იპოვნეთ spakes 'psp. route`.
3. გაყინვა, გამოტოვება (იხ. „გამოშვების სტრატეგიები „/“ როლბეკი “).

C) ეჭვი N + 1

1. ტრეისი დიდი რაოდენობით მოკლე DB სპანებით.
2. ჩართეთ აგრეგაცია/ჯოინები, დაამატეთ ქეშის ფენა.

17) განხორციელების შემოწმების სია

1. ჩართეთ OTel SDK და ერთიანი Resource ატრიბუტები ('service. name`, `env`, `region`).
2. W3C Trace Contex- ის პროპაგანდა ყველა ფენისა და ხაზის მეშვეობით.
3. სემანტიკური ატრიბუტების მინიმალური ნაკრები (HTTP/DB/queue/PSP).
4. Tail-sampling: შეცდომები, p95 +, გადახდა, საკაბელო.
5. Logs 'trace _ id '/' spank _ id', მეტრიკა exemplars- დან.
6. Dashboards: სერვისი, release compare, payments flow.
7. PII პოლიტიკა: შენიღბვა, ზონები, როლები, ჭრა.
8. ტესტები/დატვირთვა: მწვერვალების წინ კორელაციისა და ტრეფიკის შემოწმება.
9. ალერტებში runbook ბმულების ავტომატური წარმოება.
10. ანგარიში ტელემეტრიისა და კარდინალების ღირებულების შესახებ.

18) ანტიპატერები

კვალი „მხოლოდ შესასვლელში“ DD/რიგების გარეშე არ არის სასარგებლო.
ასინკში პროპაგანდის არარსებობა - მიზეზობრივი კავშირების ჯაჭვები „იშლება“.
Sampling შემთხვევითი 1% tail ლოგიკის გარეშე - ჩვენ არ ვიღებთ ნელი/მცდარი.
Logs 'trace _ id' არ არის კორელაცია.
ნედლეული PII ატრიბუტებში/ლოგოებში - შესაბამისობის რისკი.
„ჭერის“ კარდინალობა (user/session, როგორც მეტრიკის ეტიკეტი), ფასის აფეთქებას წარმოადგენს.

შედეგები

OpenTelemetry აქცევს დაკვირვებას მიმოფანტული ინსტრუმენტების კომპლექტიდან შესრულების სრულ ენად. კონტექსტის, სისუფთავე სემანტიკის, tail-sampling- ის და „Log- ის მეტრიკის“ ლიგატის სწორად პროპაგანდით, iGaming ბრძანებას უჭირავს p95/p99 კონტროლის ქვეშ, სწრაფად იზოლირებს ვიწრო ადგილებს (BD, რიგები, PSP) და თავდაჯერებულად გამოსცემს გამოშვებებს ტრაფიკის მწვერვალებშიც კი.