監視和編寫

1）為什麼這在iGaming中很重要

實時金錢：接受存款，即時付款，計算賭註和獲勝，比賽-都對延誤和失敗敏感。
監管和審計：需要完全可跟蹤的活動（KYC/AML，付款，責任遊戲限制）。
復雜的分布式體系結構：API網關，支付編排，EDA/Kafka，提供商服務，移動客戶，前端，BI總線。
目的：減少MTTD/MTTR，保持SLO的金色信號，並提供事件力。

2）可觀察性的基本概念

Logs：適合調查和審計的詳細事件（結構化JSON）。
度量：時間聚合（TSDB），適用於SLO/Alert。
Traces： 通過服務/經紀人/DB的因果查詢鏈（trace/span）。
活動：域事件（BetPlaced, DepositApproved）是業務指標與技術之間的橋梁。

3）適用於iGaming的「黃金信號」和SLI/SLO

Latency：按關鍵流（授權、存款、出價、會議開始、旋轉）進行P95/P99。
Traffic：API的RPS，支付的TPS，事件的EPS。
Errors： 5xx/4xx, decline-rate, failed-withdrawals,供應商錯誤。

Saturation: CPU, memory, IO, Kafka lag, DB connections, thread-pools.

• SLI: `1 - (failed_payments / total_payments)`
• SLO: 99.7%在30天內成功獲得卡片授權（error budget 0.3%).

4）收集和處理架構

1.無花果：試劑（OTel Collector/Fluent Bit），應用程序中的SDK，RUM/合成。
2.路由：遙測經紀人/總線（OTLP/HTTP/GRPC），過濾器和偽裝PII。

• 度量：TSDB（聚合，downsampling）。
• Logs： hot （索引）/warm （索引較少）/cold（對象存儲,WORM）。
• 預告片：帶有復古和尾隨采樣的時間索引存儲。
• 4.Analytics/Alerta：規則（PromQL/LogQL/SQL）,與示例和版本相關。
• 5.Dashbords：技術+業務類型（付款，RNG/提供商，錦標賽引擎）。

5）Logs標準（JSON）和事件分類法

建議嚴格的JSON生成，單鍵和關卡。

Уровни: `DEBUG < INFO < NOTICE < WARN < ERROR < FATAL < AUDIT`

Таксономия: `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」（來自OTel），「span_id」，「correlation_id」（用於業務流程的端到端），「idempotency_key」（用於支付請求）。
傳輸baggage（tenant/brand，market，A/B變體）以建造切片。

7）度量標準： 技術和商業

技術： RPS, p95 latency, error rate, saturation, GC, pool usage, Kafka consumer lag.

業務：CR registratsii→depozit，成功授權，取消付款，NGR/GGR，ARPPU，RTP異常，KYC步驟中的下降，責任限制的份額。

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

8）Tracing和OpenTelemetry

指導網關，支付編排器，遊戲核心，通知，KYC/AML，與提供商的集成。
用於總流+tail-sampling（升高）的頭部采樣，用於錯誤/潛伏式span和付款。
上下文宣傳：「traceparent」/「tracestate」，Kafka頭條，gRPC元數據。
我們註釋了域事件：「BetPlaced」，「WithdrawalRequested」。

9）無噪音的Alerting

多級閾值（警告/臨界值）、阻塞、重復數據消除、超時。
相關：將「5xx」+「Kafka lag」+「p95 latency PSP」鏈接→一次事件。
基於SLO的Alerts：浪費錯誤預算-我們升級。
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） Dashbords： 什麼是必需的

Payments Health：PSP成功/失敗，方法遲緩，區域地圖，SLA提供商。
遊戲核心：按提供者劃分的RPS，p95旋轉，錯誤評分SDK，按插槽劃分的RTP異常。
播放器之旅：registratsiya→KUS→depozit→igra→vyvod（轉換漏鬥，步進之間的時間）。
Infra：Kafka lag，DB連接，cache hit ratio，Kubernetes集群（pod/節點網格）。

12）存儲、回避和成本（FinOps）

控制中的基數：避免使用高度可變的標簽（user_id)。
Retenties： hot 30-90 dn., downsampling至13個月；7-14 dn., warm 30-90 dn., cold 1-3 years（考慮監管）。

WORM/immutability for audit log, Object Lock.

壓縮/參與和ILM政策；用於審計/PII-safe的單獨索引。
在INFO/DEBUG上進行博客；ERROR/AUDIT-完整。

13）安全和合規性

PII/PCI：令牌，哈希，偽裝；將數據最小化。
RBAC/ABAC：按角色訪問登錄記錄/跟蹤,分割內容。
秘密和鑰匙：不寫信用/代幣；CI上的秘密探測器。
審核跟蹤：管理登錄,限制/付款更改,手動資產負債表調整-僅在AUDIT指數中,總是。
法律保留：在調查中凍結回避的機制。

14）遙測數據的質量

Log/Events的Schema Registry（版本，兼容性）。
單個字段namenclatura（snake_case，單位）。
註射驗證（骯臟事件的下降，婚姻指標）。
Backpressure和針對「日誌風暴」的防禦。

15）SRE過程，腫瘤和符文

腫瘤矩陣和升級；安靜的時間和旋轉。
Runbooks綁定到Alert（診斷步驟，SQL/LogQL處方，ficheflagi降解）。
Postmortem沒有懲罰，與業主和截止日期一起行動。
指示器：MTTD/MTTR，噪音差百分比，符文覆蓋。

16） RUM和合成

RUM：WebVitals（LCP，CLS，INP），前部錯誤，設備打印，區域/提供商。
合成：來自不同地區的「registratsiya→depozit→spin→vyvod」情景；內部軌道的私人位置（管理層/後臺）。

17）發布，實驗和ficheflags的實踐

鏈接發布版本的預告片（commit/artefact）。
baggage → dashbord中的A/B標簽「實驗對SLI的影響」。
金絲雀/藍綠色：金絲雀的單獨面板，錯誤的budget burn rate。

18）異常檢測和反氟化信號

統計觸發器（seasonality-aware）在decline-rate/chargeback-risk/新卡激增。
相關性：「非緊急存款增長+PSP適配器的新版本」。
流媒體規則（Kafka → Flink）用於近實時反應。

19）實施路線圖（按階段）

第0階段-Basis：JSON logs，單重合字段，基本服務度量，通用行車記錄儀，第一個變速箱。
步驟1-Tracing： OTel教學,頭部+尾部采樣,鏈接到日誌。
階段2-業務SLI/SLO：付款/結論/遊戲指標，SLO-Alerta，錯誤預算流程。
第3階段-成熟度：Alerts-as-Code，ILM，分離復制，異常特征，Runbook的先發服務，CI/CD中的SRE實踐。

20）歡呼的支票清單

• Logi只有JSON，單鍵，PII偽裝。
• 在每個事件中：'trace_id'、'span_id'、'correlation_id'、'tenant'。
• 度量標準涵蓋黃金線索和業務流。
• 描述了SLO，在burn rate上有error-budget和alerta。
• Tail-sampling包含支付錯誤和高潛伏期。
• ILM/轉義和 WORM配置用於審核日誌。
• RBAC用於遙測，訪問審核。
• Payments/Game Core/Player Journey/Infra上的Dashbords。
• Runbooks綁在每個臨界值上。
• Postmortems和Action items-與所有者背面。

附錄A： OpenTelemetry屬性（建議）

`service.name`, `service.version`, `deployment.environment`

`cloud.region`, `k8s.pod.name`, `k8s.container.name`

`tenant`, `brand`, `market`, `ab_test`, `user_segment`

`payment.method`, `psp`, `game.provider`, `game.id`

附件B： SLO的示例指標

`payment_success_ratio`, `withdrawal_ttw_p95` (time-to-wallet), `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/區域/方法進行比較，檢查尾巴預告片，查看適配器版本。
「p99旋轉↑ 」→跟蹤front→geytvey→provayder，檢查提供商/頻道，線程池限制，網絡中繼。
「Kafka lag ↑ 」→健康領事，制片人撤退，後壓，慢速彈出/DB。