نظارت و ورود به سیستم

1) چرا در iGaming مهم است

پول در زمان واقعی: پذیرش سپرده، پرداخت فوری، محاسبه شرط و برنده، مسابقات - همه چیز حساس به تاخیر و شکست است.
مقررات و حسابرسی: ردیابی کامل اقدامات مورد نیاز است (KYC/AML، پرداخت، محدودیت بازی مسئول).
مجتمع معماری توزیع شده: دروازه API، ارکستراسیون پرداخت، EDA/کافکا، خدمات ارائه دهنده، مشتریان تلفن همراه، جبهه، اتوبوس BI.
هدف: برای کاهش MTTD/MTTR، نگه داشتن SLO در سیگنال های طلا و ارائه نرخ حادثه.

2) مفاهیم اساسی مشاهده پذیری

سیاهههای مربوط: رویدادهای دقیق (ساختار JSON) مناسب برای تحقیقات و ممیزی.
معیارها: aggregates in time (TSDB)، مناسب برای SLO/هشدار.
ردیابی: زنجیره علت و اثر درخواست (ردیابی/دامنه) از طریق خدمات/کارگزاران/پایگاه داده.
رویدادها: رویدادهای دامنه (BetPlaced، DepositApproved) - پلی بین معیارهای تجاری و فناوری.

3) «سیگنال های طلایی» و SLI/SLO برای iGaming

تأخیر: P95/P99 بر جریانهای بحرانی (مجوز، سپرده، نرخ، شروع جلسه، چرخش).
ترافیک: RPS توسط API، TPS توسط پرداخت، EPS توسط رویداد.
خطاها: سهم 5xx/4xx, کاهش نرخ, شکست خورده در, خطاهای ارائه دهنده.
اشباع: CPU، حافظه، IO، تاخیر کافکا، اتصالات DB، استخر موضوع.

• SLI: «1 - (failed_payments/ total_payments)»
• SLO: 99 7٪ از مجوز کارت موفق در 30 روز (بودجه خطا 0. 3%).

4) معماری جمع آوری و پردازش

1. تزریق: عوامل (OTel Collector/Fluent Bit)، SDK در برنامه، RUM/synthetics.
2. مسیریابی: اتوبوس کارگزار/تله متری (OTLP/HTTP/GRPC)، فیلترها و ماسک PII.

• معیارها: TSDB (تجمع، downsampling).
• سیاهههای مربوط: گرم (نمایه شده )/گرم (کمتر نمایه شده )/سرد (ذخیره سازی شی، WORM).
• مسیرهای پیاده روی: ذخیره سازی شاخص زمان با retentions و نمونه برداری دم.
• 4. تجزیه و تحلیل ترافیک/هشدار: قوانین (PromQL/LogQL/SQL)، همبستگی با آهنگ ها و انتشار.
• 5. داشبورد: فنی + انواع کسب و کار (پرداخت، RNG/ارائه دهندگان، موتور مسابقات).

5) استاندارد ورود (JSON) و طبقه بندی رویداد

ورود به سیستم JSON دقیق، کلید های تک و سطوح توصیه می شود.

Уровни: 'DEBUG

Таксономия: 'auth.', 'payment.', 'gameplay.', 'risk.', 'psp.', 'kyc.', 'rg.' (responsible gaming), 'ops.'.

json
{
"ts": "2025-11-04T19:45:31. 842Z",
"lvl": "AUDIT",
"event_type": "payment. deposit_approved",
"correlation_id": "c-7d2c1f0b",
"trace_id": "2d6a9c0e4c0b1f72",
"span_id": "9f3a81d2a1c3b764",
"request_id": "r-8f12de9e",
"tenant": "brand_eu",
"psp": "acq_xyz",
"user_id_hash": "u:sha256:1e63…",
"device_id": "d-3c8f…",
"ip_trunc": "203. 0. 113. 0/24",
"amount_minor": 5000,
"currency": "EUR",
"result": "approved",
"latency_ms": 312,
"tags": ["pci_safe", "kyc_passed", "low_risk"],
"extra": {
"bin": "411111",
"method": "card",
"region": "EU",
"ab_test": "checkout_v2"
}
}

• ما ماسک PAN/BIN (ما فقط زمینه های معتبر توسط سیاست ذخیره)، ایمیل/تلفن - هش/رمز.
• IP کوتاه به/24، فروشگاه GeoIP به طور جداگانه.
• ما متن رایگان را در «اضافی» برای ورودی کاربر بدون پاکسازی ممنوع می کنیم.

6) همبستگی: trace_id، correlation_id، idempotency_key

«trace _ id» (از OTel)، «span _ id»، «correlation _ id» (پایان به پایان برای فرآیند کسب و کار)، «idempotency _ key» (برای درخواست پرداخت) را به هر ورود و متریک اضافه کنید.
انتقال چمدان (مستاجر/نام تجاری، بازار، گزینه A/B) برای ساخت برش.

7) معیارها: فنی و تجاری

فنی: RPS، تاخیر P95، میزان خطا، اشباع، GC، استفاده از استخر، تاخیر مصرف کننده کافکا.
کسب و کار: ثبت نام CR → deposit، مجوزهای موفق، لغو پرداخت، ناهنجاری های NGR/GGR، ARPPU، RTP، رها کردن در مرحله KYC، سهم محدودیت های مسئول.

promql sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

8) ردیابی و تله متری باز

ما ابزار دروازه، ارکستراتور پرداخت، هسته بازی، اطلاعیه ها، KYC/AML، ادغام با ارائه دهندگان.
سر نمونه برداری برای جریان کل + دم نمونه برداری (بالا) برای خطاها/دهانه نهفته و پرداخت.
انتشار زمینه: 'traceparent '/' tracestate'، هدر کافکا، ابرداده gRPC.
حاشیه نویسی با رویدادهای دامنه: «BetPosted»، «WithinRequested».

9) هشدار بدون سر و صدا

آستانه چند مرحله ای (هشدار/بحرانی)، سرکوب فلاپ، deduplication، اسلات زمان.
همبستگی: ما «رشد 5xx» + «تاخیر کافکا» + «PSP تاخیر p95» → یک حادثه را مرتبط می کنیم.
هشدارهای مبتنی بر SLO: صرف بودجه خطا - تشدید می شود.
Alerts-as-Code (GitOps)، بررسی و آزمایش قوانین.

yaml groups:
- name: payments rules:
- alert: PaymentErrorSpike expr: (sum(rate(payment_errors_total[5m])) / sum(rate(payment_attempts_total[5m]))) > 0. 02 for: 10m labels: { severity: "critical", team: "payments" }
annotations:
summary: "Payment errors> 2% per 10m"
runbook: "runbooks/payments/error-spike. md"

10) جستجوی ورود (به عنوان مثال LogQL)

logql
{app="psp-orchestrator", level=~"ERROR    FATAL"}
= "decline"
json amount_minor > 10000 region="EU"

هدف این است که به سرعت از بین بردن سر و صدا و برجسته کردن «گران» شکست در منطقه هدف.

11) داشبورد: چه اجباری است

پرداخت سلامت: موفقیت/شکست توسط PSP، تاخیر با روش، نقشه مناطق، ارائه دهندگان SLA.
هسته بازی: RPS توسط ارائه دهندگان، چرخش P95، نسبت خطا SDK، RTP ناهنجاری های اسلات.
سفر بازیکن: ثبت نام → KUS → deposit → igra → vyvod.
Infra: تاخیر کافکا، اتصالات DB، نسبت ضربه کش، خوشه Kubernetes (شبکه غلاف/گره).

12) ذخیره سازی، نگهداری و هزینه (FinOps)

کاردینالیتی تحت کنترل: اجتناب از معیارهای با برچسب های بسیار قابل تغییر (user_id).
Retentions: معیارهای داغ 30-90 روز، downsampling تا 13 ماه ؛ سیاهههای مربوط گرم 7-14 روز، گرم 30-90 روز، سرد 1-3 سال (با توجه به مقررات).
WORM/غیر قابل تغییر برای گزارش های حسابرسی، قفل شی.
سیاست های فشرده سازی/پارتیشن بندی و ILM ؛ شاخص های جداگانه برای حسابرسی/PII-safe.
سیاهههای مربوط نمونه برداری در INFO/DEBUG ؛ خطا/حسابرسی - کامل است.

13) ایمنی و انطباق

PII/PCI: توکن سازی، هش کردن، ماسک کردن ؛ به حداقل رساندن داده ها.
RBAC/ABAC: دسترسی به سیاهههای مربوط/آهنگ - توسط نقش، جدایی از سایبان.
اسرار و کلید ها: اعتبارنامه ها/نشانه ها را وارد نکنید ؛ آشکارسازهای مخفی در CI.
دنباله حسابرسی: ورود به پنل مدیریت، تغییر در محدودیت ها/پرداخت ها، تنظیمات تعادل دستی - فقط به شاخص AUDIT، همواره.
نگهداری قانونی: مکانیزمی برای انجماد مجدد در تحقیقات.

14) کیفیت داده های تله متری

ثبت طرحواره برای سیاههها/رویدادها (نسخهبندی، سازگاری).
نامگذاری تنها از زمینه (snake_case، واحد اندازه گیری).
اعتبار سنجی در تزریق (قطره حوادث کثیف، معیارهای ازدواج).
Backpressure و حفاظت در برابر «طوفان ورود به سیستم».

15) فرآیندهای SRE، تماس های آنلاین و runbooks

ماتریس آنکال و افزایش ؛ ساعت ها و چرخش های آرام

Runbooks به هشدار (مراحل تشخیصی، دستور العمل SQL/LogQL، phicheflags برای تخریب) گره خورده است.
پس از مرگ بدون مجازات، موارد اقدام با صاحبان و مهلت.
شاخص های تیم: MTTD/MTTR، درصد هشدار پر سر و صدا، پوشش Runbuk.

16) RUM و مصنوعی

RUM: WebVitals (LCP، CLS، INP)، خطاهای جلو، اثر انگشت دستگاه، مناطق/ارائه دهندگان.
Synthetics: scenarios «registratsiya → depozit → spin → vyvod» از مناطق مختلف ؛ مکان های خصوصی برای مسیرهای داخلی (admin/back office).

17) شیوه های انتشار, آزمایش و phicheflags

ما آهنگ ها را با نسخه های انتشار (commit/artefact) پیوند می دهیم.
برچسبهای A/B در چمدان → داشبورد «تأثیر آزمایش بر SLI».
Canary/Blue-Green: پانل های جداگانه برای قناری ها، میزان سوزاندن خطا در بودجه.

18) تشخیص ناهنجاری و سیگنال های ضد تقلب

عوامل آماری (فصلی آگاه) در کاهش نرخ/chargeback خطر/افزایش کارت های جدید.
همبستگی: «رشد سپرده های ناموفق + انتشار جدید آداپتور PSP».
قوانین جریان (کافکا → فلینک) برای واکنش های نزدیک به زمان واقعی.

19) نقشه راه پیاده سازی (توسط فاز)

مرحله 0 - پایه: سیاهههای مربوط JSON، زمینه همبستگی یکپارچه، معیارهای خدمات اولیه، داشبورد مشترک، اولین هشدار.
مرحله 1 - ردیابی: ابزار OTel، سر + نمونه برداری دم، اتصال به سیاهههای مربوط.
مرحله 2 - SLI/SLO کسب و کار: پرداخت/خروجی/معیارهای بازی، هشدارهای SLO، فرآیندهای خطا بودجه.
مرحله 3 - بلوغ: هشدارها به عنوان کد، ILM، retentions جداگانه، تشخیص ناهنجاری، runbuki در هر سرویس، شیوه های SRE در CI/CD.

20) چک لیست بررسی

• JSON فقط سیاهههای مربوط، کلیدهای تک، ماسک PII.
• در هر رویداد: 'ردیابی _ id'، 'span _ id'، 'همبستگی _ id'، 'مستاجر'.
• معیارها سیگنال های طلا و جریان های تجاری را پوشش می دهند.
• SLO شرح داده شده است، یک بودجه خطا و هشدار در میزان سوختگی وجود دارد.
• نمونه برداری دم برای خطاهای پرداخت و تاخیرهای بالا فعال است.
• ILM و WORM برای گزارش های حسابرسی پیکربندی شده اند.
• RBAC برای تله متری، ممیزی دسترسی.
• داشبورد برای پرداخت/هسته بازی/سفر بازیکن/Infra.
• Runbooks به هر هشدار بحرانی متصل است.
• Postmortems و آیتم های عمل - در عقب با صاحبان.

ضمیمه A: ویژگی های OpenTelemetry (توصیه)

در خدمت شما هستم. نام، خدمات. نسخه '،' استقرار. محیط زیست "

با صدای بلند. منطقه '،' k8s. غلاف. نام '،' k8s. ظرف. نام و نام خانوادگی

«tenant»، «brand»، «market»، «ab _ test»، «user _ segment»

حق الزحمه. روش '،' PSP '،' بازی. ارائه دهنده '،' بازی. من..

ضمیمه B: نمونه هایی از معیارهای SLO

«پرداخت _ موفقیت _ نسبت»، «برداشت _ ttw _ p95» (زمان به کیف پول)، «psp _ latency _ p99»

'game _ spin _ latency _ p95', 'provider _ error _ rate', 'kafka _ consumer _ lag'

'auth _ success _ ratio', 'kyc _ step _ dropout', 'cache _ hit _ ratio'

ضمیمه C: دستور العمل های تحقیقاتی سریع

"در حال رشد" payment _ error _ rate "→ مقایسه توسط PSP/region/method، بررسی دنباله دم، مشاهده انتشار آداپتور.
«p99 چرخش ↑» ردیابی →, جلو → geytvey → provayder بررسی ارائه دهنده/کانال, محدودیت استخر موضوع, retrays شبکه.
«↑ تاخیر کافکا» → مصرف کنندگان سلامت، تولید کنندگان یکپارچهسازی با سیستمعامل، فشار پشتی، غرق آهسته/DB.

با پیروی از این شیوه ها، پلت فرم یک سیستم قابل مشاهده، قابل اثبات و مقرون به صرفه است که به عنوان یک ابزار مهندسی، رادار کسب و کار و ضامن انطباق دو برابر می شود.