İzleme ve günlüğe kaydetme

1) iGaming'de neden önemli?

Gerçek zamanlı para: para yatırma, anında ödeme, bahisleri ve kazançları hesaplama, turnuvalar - her şey gecikmelere ve başarısızlıklara karşı hassastır.
Düzenleyici ve denetim: Eylemlerin tam izlenebilirliği gereklidir (KYC/AML, ödemeler, sorumlu oyunun sınırları).
Karmaşık dağıtılmış mimari: API ağ geçitleri, ödeme orkestrasyonu, EDA/Kafka, sağlayıcı hizmetleri, mobil müşteriler, cepheler, BI veri yolu.
Amaç: MTTD/MTTR'yi azaltmak, SLO'yu altın sinyallerde tutmak ve olay oranı sağlamak.

2) Gözlemlenebilirliğin temel kavramları

Günlükler: Soruşturma ve denetimler için uygun ayrıntılı olaylar (yapılandırılmış JSON).
Metrikler: Zaman içinde kümeler (TSDB), SLO/uyarılar için uygundur.
İzler: hizmetler/brokerler/veritabanları aracılığıyla taleplerin neden ve sonuç zincirleri (trace/span).
Etkinlikler: Etki alanı etkinlikleri (BetPlaced, DepositApproved) - iş metrikleri ve teknoloji arasında bir köprü.

3) "Altın Sinyaller've iGaming için SLI/SLO

Gecikme: Kritik akışlarda P95/P99 (yetkilendirme, depozito, oran, oturum başlangıcı, spin).
Trafik: API ile RPS, ödeme ile TPS, olaya göre EPS.
Hatalar: 5xx/4xx paylaşımı, düşüş oranı, içeride başarısız oldu, sağlayıcı hataları.
Doygunluk: CPU, bellek, IO, Kafka lag, DB bağlantıları, iplik havuzları.

• SLI: '1 - (failed_payments/ total_payments)'
• SLO: 99. 30 gün içinde başarılı kart yetkilendirmelerinin %7'si (hata bütçesi 0. 3%).

4) Toplama ve işleme mimarisi

1. Enjeksiyon: Ajanlar (OTel Collector/Fluent Bit), uygulamada SDK, RUM/sentetikler.
2. Yönlendirme: broker/telemetri veri yolu (OTLP/HTTP/GRPC), filtreler ve PII maskeleme.

• Metrikler: TSDB (toplama, altörnekleme).
• Günlükler: sıcak (dizinlenmiş )/sıcak (daha az dizinlenmiş )/soğuk (nesne depolama, WORM).
• Yollar: Retentions ve kuyruk örnekleme ile zaman endeksli depolama.
• 4. Analytics/uyarılar: kurallar (PromQL/LogQL/SQL), parçalar ve sürümler ile korelasyon.
• 5. Gösterge tabloları: teknik + iş türleri (ödemeler, RNG/sağlayıcılar, turnuva motoru).

5) Günlük standardı (JSON) ve olay taksonomisi

Sıkı JSON günlüğü, tek tuşlar ve seviyeler önerilir.

Уровни: '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 (yalnızca politikaya göre geçerli alanları saklıyoruz), e-posta/telefon - hash/token'ı maskeliyoruz.
• IP/24, GeoIP deposuna ayrı olarak kesilir.
• Sterilizasyon olmadan kullanıcı girişi için 'ekstra' içindeki serbest metni yasaklıyoruz.

6) Korelasyon: trace_id, correlation_id, idempotency_key

Her log ve metriğe 'trace _ id' (OTel'den), 'span _ id', 'correlation _ id' (iş süreci için uçtan uca), 'idempotency _ key' (ödeme istekleri için) ekleyin.
Dilimler oluşturmak için bagaj transferi (kiracı/marka, pazar, A/B seçeneği).

7) Metrikler: Teknik ve İş

Teknik: RPS, p95 gecikme, hata oranı, doygunluk, GC, havuz kullanımı, Kafka tüketici gecikmesi.
İş: CR registratsii - depozit, başarılı yetkilendirmeler, ödemelerin iptali, NGR/GGR, ARPPU, RTP anomalileri, KYC adımında bırakma, sorumlu sınırların paylaşımı.

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

8) İzleme ve OpenTelemetry

Ağ geçidini, ödeme düzenleyicisini, oyun çekirdeğini, bildirimleri, KYC/AML'yi, sağlayıcılarla entegrasyonu sağlıyoruz.
Toplam akış için kafa örneklemesi + hatalar/gizli açıklıklar ve ödemeler için kuyruk örneklemesi (yükseltilmiş).
Bağlam yayılımı: 'traceparent'/' tracestate', Kafka başlıkları, gRPC meta verileri.
Açıklama, etki alanı olaylarıyla yayılır: 'BetPlaced', 'WithinRequested'.

9) Gürültü olmadan uyarı

Çok aşamalı eşikler (uyarı/kritik), çırpma bastırma, veri tekilleştirme, zaman dilimleri.
Korelasyon: "5xx growth" + "Kafka lag" + "p95 latency PSP" - bir olayı ilişkilendiriyoruz.
SLO tabanlı uyarılar: harcama hatası bütçesi - yükseltir.
Alerts-as-Code (GitOps), inceleme ve kural testleri.

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) Günlük arama (örnek LogQL)

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

Amaç, gürültüyü hızlı bir şekilde ayıklamak ve hedef bölgedeki "pahalı" arızaları vurgulamaktır.

11) Gösterge Tabloları: zorunlu olan şey

Ödemeler Sağlık: PSP tarafından başarı/başarısızlıklar, yöntemle gecikme, bölgelerin haritası, SLA sağlayıcıları.
Oyun Çekirdeği: Sağlayıcılar tarafından RPS, p95 spin, hata oranı SDK, yuvalar tarafından RTP anomalileri.
Oyuncu Yolculuğu: registratsiya ^ KUS ^ depozit ^ igra ^ vyvod.
Infra: Kafka gecikmesi, DB bağlantıları, önbellek isabet oranı, Kubernetes kümesi (bölmeler/düğümler ızgarası).

12) Depolama, saklama ve maliyet (FinOps)

Kontrol altında kardinalite: Son derece değiştirilebilir etiketlere sahip metriklerden kaçının (user_id).
Retentions: sıcak metrikler 30-90 gün, 13 aya kadar aşağı örnekleme; Sıcak 7-14 gün, sıcak 30-90 gün, soğuk 1-3 yıl (düzenleme dikkate alınarak).
WORM/denetim günlükleri için değişmezlik, Nesne Kilidi.
Sıkıştırma/bölümleme ve ILM politikaları; Denetim/PII-güvenli için ayrı indeksler.
INFO/DEBUG üzerinde örnekleme günlükleri; HATA/DENETIM - tamamlandı.

13) Güvenlik ve uyumluluk

PII/PCI: tokenization, hashing, masking; verileri minimize etmek.
RBAC/ABAC: günlüklere/izlere erişim - role göre, tentelerin ayrılması.
Sırlar ve anahtarlar: kimlik bilgilerini/belirteçleri kaydetmeyin; Muhbirdeki gizli dedektörler.
Denetim izi: yönetici paneline girişler, limitlerde/ödemelerde değişiklikler, manuel denge ayarlamaları - yalnızca AUDIT endeksine, her zaman.
Legal-hold: Soruşturmalarda retention'ların dondurulması için bir mekanizma.

14) Telemetri veri kalitesi

Günlükler/olaylar için Şema Kayıt Defteri (sürüm oluşturma, uyumluluk).
Alanların tek isimlendirilmesi (snake_case, ölçü birimleri).
Enjeksiyonda doğrulama (kirli olayların düşmesi, evlilik metrikleri).
"Log fırtınalarına" karşı geri basınç ve koruma.

15) SRE süreçleri, çevrimiçi aramalar ve runbook'lar

Oncall matris ve yükselmeleri; Sessiz Saatler ve rotasyonlar.
Runbook'lar uyarılara bağlıdır (tanılama adımları, SQL/LogQL tarifleri, bozulma için phicheflags).
Ceza olmadan ölüm sonrası, sahipli eylem öğeleri ve son tarihler.
Takım göstergeleri: MTTD/MTTR, gürültülü uyarıların yüzdesi, Runbuk kapsamı.

16) RUM ve sentetikler

RUM: WebVitals (LCP, CLS, INP), ön hatalar, cihaz parmak izleri, bölgeler/sağlayıcılar.
Sentetikler: farklı bölgelerden "registratsiya, depozit, spin, vyvod" senaryoları; Dahili yollar için özel konumlar (yönetici/arka ofis).

17) Serbest bırakma uygulamaları, deneyler ve phicheflags

Parçaları sürüm sürümleriyle (commit/artefact) bağlarız.
Bagajdaki A/B etiketleri - pano "deneyin SLI üzerindeki etkisi".
Kanarya/Mavi-Yeşil: kanaryalar için ayrı paneller, hata bütçeli yanma oranı.

18) Anomali tespiti ve sahtekarlık karşıtı sinyaller

Yeni kartların düşüş hızı/ters ibraz riski/dalgalanması ile ilgili istatistiksel tetikleyiciler (mevsimselliğin farkında).
Korelasyonlar: "Başarısız depozitlerin büyümesi + PSP adaptörünün yeni serbest bırakılması".
Gerçek zamana yakın reaksiyonlar için akış kuralları (Kafka Flink).

19) Uygulama Yol Haritası (aşama aşama)

Aşama 0 - Temel: JSON günlükleri, birleşik korelasyon alanları, temel hizmet metrikleri, ortak gösterge panoları, ilk uyarılar.
Aşama 1 - İzleme: OTel enstrümantasyonu, baş + kuyruk örneklemesi, günlüklere bağlantı.
Aşama 2 - İş SLI/SLO: ödemeler/çıktılar/oyun metrikleri, SLO uyarıları, hata bütçesi süreçleri.
Aşama 3 - Olgunluk: Alerts-as-Code, ILM, ayrı retentions, anomaly-detection, per-service runbuki, CI/CD SRE uygulamaları.

20) İnceleme kontrol listesi

• JSON sadece günlükleri, tek tuşlar, PII maskeleme.
• Her olayda: 'trace _ id', 'span _ id', 'correlation _ id', 'tenant'.
• Metrikler altın sinyalleri ve iş akışlarını kapsar.
• SLO'lar açıklanmıştır, bir hata bütçesi ve yanma oranı ile ilgili uyarılar vardır.
• Kuyruk örnekleme, ödeme hataları ve yüksek gecikmeler için etkinleştirilmiştir.
• ILM ve WORM denetim günlükleri için yapılandırılmıştır.
• Telemetri için RBAC, erişim denetimi.
• Ödemeler/Oyun Çekirdeği/Oyuncu Yolculuğu/Infra için Gösterge Tabloları.
• Runbook'lar her kritik uyarıya bağlıdır.
• Postmortemler ve eylem kalemleri - sahipleriyle birlikte birikmiş işlerde.

Ek A: OpenTelemetry nitelikleri (öneri)

hizmet. İsim ',' hizmeti. Sürüm ',' dağıtım. Çevre '

'cloud. Bölge ',' k8s. Pod. Name ',' k8s. Konteyner. İsim '

'tenant', 'brand', 'market','ab _ test ',' user _ segment '

'ödeme. method ',' psp ',' game. sağlayıcı ',' oyunu. 'idid

Ek B: SLO için Metrik Örnekleri

'ödeme _ başarı _ oranı', 'para çekme _ ttw _ p95' (cüzdan zamanı), 'psp _ latency _ p99'

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

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

Ek C: Hızlı Araştırma Tarifleri

"Büyüyen 'payment _ error _ rate'" - PSP/region/method ile karşılaştırın, kuyruk izlerini kontrol edin, adaptör sürümüne bakın.
"P99 spins" ↑ trace, front, geytvey, provayder check provider/channels, thread pool limits, network retrays.
"Kafka lag ↑" - sağlık tüketicileri, retro üreticiler, geri basınç, yavaş lavabolar/DB.

Bu uygulamalara bağlı kalarak, platform bir mühendislik aracı, iş radarı ve uygunluk garantörü olarak ikiye katlanan sağlam, doğrulanabilir ve uygun maliyetli bir gözlemlenebilirlik sistemi alır.