ردیابی توزیع شده

(بخش: تکنولوژی و زیرساخت)

خلاصه ای کوتاه

ردیابی توزیع شده پاسخ به این سوال که در آن و چرا زمان در طول مسیر درخواست از طریق دروازه، API، صف، پایگاه داده ها، ارائه دهندگان خارجی (PSP/استودیوهای بازی) از دست داده است. OpenTelemetry (OTel) یک استاندارد SDK/agent/protocol باز است که ترکیبی از مسیرها، معیارها و سیاهههای مربوط است. در iGaming، این یک ابزار اساسی برای حفظ p95/p99، به سرعت محلی سازی مسائل پرداخت و شناسایی تنگناها قبل از مسابقات اوج است.

1) مفاهیم OTel

ردیابی - مسیر کامل عملیات (سپرده، نرخ، برداشت).
محدوده کاری (HTTP handler، درخواست SQL، تماس صف/ارائه دهنده).
ویژگی ها - کلید ارزش با جزئیات ("خالص. همکار. اسم دی بی. سیستم '،' PSP. مسیر ').
رویدادها - رویدادهای فوری (عقب نشینی، اتمام وقت، از دست دادن حافظه پنهان).
پیوندها - پیوند به ردیابی های دیگر (مهم برای async/صف).
منبع - فراداده فرآیند: "سرویس. نام، خدمات. نسخه '،' استقرار. محیط زیست، ابر. منطقه ".

2) انتشار زمینه

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

علاوه بر این - چمدان برای کلید های امن (به عنوان مثال، «مستاجر»، «مسیر»)، PII را در آنجا قرار ندهید.

که در آن به سوراخ زمینه: API دروازه → RPC های داخلی → تولید کننده به صف → مصرف کننده HTTP خارجی (PSP/ارائه دهندگان).

3) قراردادهای معنایی (حداقل اجباری)

HTTP/RPC: 'http. روش '،' HTTP. مسیر '،' HTTP. status_code' است.
DB/کش: "db. system '(' mysql '/' postgresql '/' redis '),' db. statement '(masked)', 'db. عملیات...
صفها: "پیام. system '(' kafka '/' rabbitmq ')،' پیام. مقصد «،» پیام. عملیات ('ارسال '/' فرآیند').
پرداخت: PSP. مسیر، PSP. پرداخت «،» ارائه دهنده. id '(pseudonymize),' مقدار ',' ارز '.
دامنه iGaming: "بازی. ارائه دهنده '،' بازی. session_id' (هش)، بازیکن. id_hash' است.

یک طبقه بندی واحد → قابلیت مقایسه داشبورد و جستجوی سریع علل.

4) نمونه برداری: چگونه در داده ها غرق نشویم

مبتنی بر سر

ساده، ارزان ؛ مناسب برای جریان عمومی.
منفی - شما می توانید آهنگ های آهسته/اشتباه «جالب» را از دست بدهید.

مبتنی بر دم (جمع کننده в)

تصمیم پس از پایان دوره ها ساخته شده است: ما فقط خطاها/بخش های آهسته/مهم (VIP/پرداخت) را ذخیره می کنیم.
ایده آل برای بار تولید: به شدت هزینه با محتوای اطلاعات بالا را کاهش می دهد.

• سر: 5-10٪ برای پوشش «پس زمینه».
• Tail: 100% error + p95 + slow + payment tracks/canary releases.

5) توپولوژی جمع آوری OpenTelemetry

Agent-sidecar (در هر گره/غلاف): پذیرش محلی، حداقل بافر، صادرات به جمع کننده.
دروازه (خوشه): نمونه برداری دم، مسیریابی، غنی سازی، صادرات به Tempo/Jaeger/Zipkin/OTLP.

مثال: نمونه برداری دم (قطعه 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 '/' span _ id' به هر ورودی ورود.
معیارهای تأخیر را به عنوان هیستوگرام ذخیره کنید و شامل نمونه ها باشید - اشاره به نماینده «trace _ id» برای «پرش» از p95-boket به یک ردیابی خاص.
حاشیه نویسی انتشار (Git SHA، نسخه نمودار) - مانند رویدادها/برچسب ها.

7) ابزار دقیق (زبان ها و عوامل خودکار)

برو (دستی + خودکار)

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"),
)

جاوا

عامل خودکار "-javaagent: opentelemetry-javaagent. jar ', config via env (' OTEL _ SERVICE _ NAME ',' OTEL _ EXPORTER _ OTLP _ ENDPOINT ').
دستی - حاشیه نویسی/ابزار از مکان های پیاز (استخر JDBC, کش).

گره. JS/پایتون

ابزار خودکار با پلاگین SDK + (Express/FastAPI/کرفس).

برای صف - بسته بندی تولید کننده/مصرف کننده برای قرار دادن "پیام. و لینک ها

8) صف و async: دهانه های صحیح

Producer ('send'): دامنه برای ارسال به موضوع/صف.
Consumer ('process'): محدوده جدید پردازش پیام از لینک به محدوده تولید کننده (صرفه جویی در رابطه علی بدون 'trace _ id' مشترک).
برچسب ها: پیام کافکا. پارتیشن، پیام. رابيتمق. routing_key'، پیغام message_id' است.
With retrays - event «retry», try counter.

9) DB/کش و N + 1

فعال کردن ردیابی درایور پایگاه داده، گروه نمایش داده شد از همان نوع به دسته.
برای Redis/cache، صفات «cache» هستند. ضربه '/' کش. خانم...
درخواست های «سنگین» را برای جدا کردن دهانه ها بیرون بیاورید - می توانید ببینید کجا p99 است.

10) ارائه دهندگان خارجی: استودیوهای PSP/بازی

قرار دادن کلاینتهای HTTP: "psp. ارائه دهنده «،» PSP. route ',' timeout _ ms ',' تلاش '.
کدها/انواع خطا را وارد کنید، اما PII (شماره کارت، نشانه ها) نیست.
مقایسه استودیوها/مسیرها بر اساس «مدت زمان»، «نرخ خطا».

11) جلو و رام

OTEL WEB SDK: 'page _ view', 'resource _ load', 'xhr'.
پیرس «traceparent» را به باطن به کوک مسیر کاربر را از طریق رابط کاربر → API → پایگاه داده.
تقسیم بندی توسط ارائه دهندگان جغرافیایی/شبکه - برچسب های اختیاری.

12) ایمنی و PII

فیلدها را ماسک کنید ("db. statement 'edited), hash' player _ id '.
مناطق داده: 'pii = true'، 'region = EU/TR/LATAM'.
کنترل دسترسی به مسیرهای پرداخت (مبتنی بر نقش).
WORM/Retention: دوره های نگهداری برای ردیابی حساس، حذف توسط سیاست.

13) عملکرد و هزینه

Tail-sampling by policy: «خطاهای + پرداخت + آهسته + انتشار قناری».
Downsampling هیستوگرام متریک، deduplication ورود به سیستم تهاجمی.
محدودیت کاردینالیتی: «user _ id» را به عنوان برچسب متریک ننویسید.
بافر/دسته در جمع کننده، فشرده سازی OTLP.

14) داشبورد و تجزیه و تحلیل

نقشه سرویس: وابستگی های سرویس، رنگ آمیزی خطا/تاخیر.
مقایسه انتشار: پایدار در مقابل بازنگری قناری (p95، نرخ خطا، پرداخت conv).
آثار آهسته بالا: در طول مسیر «/سپرده »، بخش در امتداد PSP/منطقه.
تاخیر صف: آهنگ های تاخیر مصرف عمیق.

15) نمونه هایی از تنظیمات جمع کننده

خطوط لوله (متریک/مسیرهای پیاده روی/سیاهههای مربوط، قطعه)

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 در «پرداخت-نرم افزار»

1. باز کردن «بالا ردیابی آهسته» → سقوط به دهانه پایگاه داده/PSP.
2. اگر مشکل PSP ترجمه مسیر است، فعال کردن retrays/timeouts.
3. بررسی صف 'withdrawals' (تاخیر)، افزایش مصرف کنندگان.

ب) اشکالات 5xx پس از انتشار

1. فیلتر بر اساس سرویس نسخه '.
2. مقایسه پایدار/قناری ؛ پیدا کردن خوشه در PSP. مسیر ".
3. توقف ارتقاء، رول به عقب (نگاه کنید به استراتژی انتشار/رول بک).

ج) مشکوک N + 1

1. مسیرهای پیاده روی با تعداد زیادی از دهانه های کوتاه DB.
2. فعال کردن تجمع/joyns, اضافه کردن لایه کش.

17) چک لیست پیاده سازی

1. فعال کردن OTel SDK و ویژگی های منابع یکنواخت ('سرویس. نام '،' env '،' منطقه ').
2. انتشار W3C ردیابی زمینه از طریق تمام لایه ها و صف.
3. حداقل مجموعه ای از ویژگی های معنایی (HTTP/DB/صف/PSP).
4. Tail-sampling: errors, p95 +, payments, canary.
5. سیاهههای مربوط با 'trace _ id '/' span _ id'، معیارهای با نمونه.
6. داشبورد: نقشه خدمات، مقایسه انتشار، جریان پرداخت.
7. سیاست های PII: ماسک، مناطق، نقش ها، حفظ.
8. تست/بار: بررسی همبستگی و کامل ردیابی قبل از قله.
9. تولید خودکار لینک های runbook در هشدارها.

10. هزینه تله متری و گزارش کاردینالیتی

18) ضد گلوله

ردیابی «فقط در ورودی» بدون پایگاه داده/صف → بدون استفاده.
عدم انتشار در زنجیره علت و معلول async → شکستن.
نمونه برداری تصادفی 1٪ بدون منطق دم → آهسته/اشتباه گرفتن نیست.
Logs without trace _ id → no end-to-end correlation.
PII های خام در ویژگی ها/سیاهههای مربوط → خطرات انطباق.
کاردینالیتی «تا سقف» (کاربر/جلسه به عنوان برچسب متریک) → انفجار ارزش.

خلاصه

OpenTelemetry قابلیت مشاهده را از مجموعه ای از ابزارهای متفاوت به یک زبان عملکرد پایان می دهد. با انتشار صحیح زمینه، معناشناسی شسته و رفته، نمونه برداری دم و ترکیبی از «معیارها ↔ ردیابی ها ↔ سیاهههای مربوط»، تیم iGaming p95/p99 را تحت کنترل نگه می دارد، به سرعت تنگناها (DB، صف، PSP) را جدا می کند و با اطمینان حتی در اوج ترافیک منتشر می کند.