GH GambleHub

Analytics API ve performans metrikleri

1) Neden ihtiyacınız var

API - platform "dolaşım sistemi. "Katı metrikler olmadan şunları yapamayız:
  • SLO ve SLA'nın uygulanmasını kanıtlamak,
  • Bant genişliği ve sorgu ekonomisini yönetmek,
  • Bozulmayı hızlı bir şekilde yerelleştirin (p99-kuyruklar, 5xx patlamaları),
  • İş etki optimizasyonlarına öncelik verin.

Amaç: Her isteğin ortak tanımlayıcılar ve tutarlı SLI'larla çevreden DB'ye kadar izlendiği tek bir gözlemlenebilirlik modeli.

2) Metriklerin taksonomisi

Teknik: RPS, gecikme (p50/p95/p99), hata oranı (4xx/5xx), doygunluk (CPU, bellek, dosya-desc), kuyruk süresi.
Ürün: başarılı işlemler/dak, adım dönüştürme (200/toplam), oran sınırlı pay (429), retrays, kullanıcı segmentleri.
Maliyet: Maliyet/istek (CPU-ms + çıkış + veritabanı istekleri), özellik/uç nokta maliyeti, $/kiracı, $/1k çağrıları.

3) "Altın Sinyaller": KIRMIZI ve KULLANIM

RED (API için):
  • Rate - requests/sn (uç nokta/kiracı/plana göre).
  • Hatalar - 4xx/5xx/429 kesirler ve mutlak.
  • Süre - p50/p95/p99 uçtan uca ve aşamalara göre (ingress, uygulama, DB, üçüncü taraf).
KULLANIM (kaynaklar için):
  • Kullanım - CPU/IO/kanal yükü.
  • Doygunluk - kuyruklar (run-queue, backlog, DB wait).
  • Hatalar - sürücü hataları/zaman aşımları.

4) Temel tanımlar ve formüller

Kullanılabilirlik SLI: '1 − (5xx + gateway_timeout )/ all_requests'.
Başarı SLI: '2xx/( tüm − 429_shadow)' (gölge kilitleri hariç).
Apdex: '(|T≤T| + 0. 5·|T≤4T| )/all ', burada' T 'hedef'iyi "eşiğidir.
Kuyruk amplifikasyonu: 'p99 _ total − max (p99_stage_i)' - kuyrukların/kompozisyonun katkısı.
99'da bütçe (ay) hatası. %9: 'bütçe = 0. 1 % period _ time '.

Önerilen gecikme histogramlarının yüzdelik kutuları: '[5ms, 10ms, 25ms, 50ms, 100ms, 250ms, 500ms, 1s, 2. 5s, 5s] '.

5) SLI/SLO ve yanma oranı ile uyarı

Örnek SLO (public API):
  • Kullanılabilirlik: ≥ 99. %9/30 gün.
  • P95 gecikme 'GET/cüzdan/bakiye' <150 ms; 'POST/payments' <400 ms.
  • Hatalar '5xx' <0. 2%. '429' (katı)
Yazma hızı uyarıları (iki pencereli):
  • 1 saat için bütçenin %2'si veya 6 saat için %5'i - mühendise sayfa.
  • Günde %10 - RCA önceliklendirmesi.

6) Metrikler kümesi (neyin toplanması zorunludur)

Çevre üzerinde (ağ geçidi/WAF):
  • 'http _ requests _ total {rota, yöntem, durum, kiracı, plan}'
  • 'http _ request _ duration _ seconds _ bucket {route,...}' (histogram)
  • 'tries _ total {reason}', 'rate _ limited _ total {key, policy}'
  • Gövde boyutları: 'request _ bytes', 'response _ bytes'
Lütfen ekli bulun:
  • 'db _ client _ requests _ total {op, table}', 'db _ latency _ seconds _ bucket {op}'
  • 'cache _ ops _ total {op}', önbellek isabet oranı harici çağrıları: 'outbound _ calls _ total {provider, op}', gecikme/hatalar/kuyruk zaman aşımları/havuzları: uzunluklar/gecikmeler, aktif kaynak KULLANIM çalışanları: CPU, RSS, FD, GC duraklatmaları

İşletme etiketleri: 'tenant _ id', 'region', 'kyc _ level', 'plan', 'feature _ flag'.

7) İz ve Korelasyon (OpenTelemetri)

Tüm şerbetçiotlarında W3C Trace-Context ('traceparent', 'tracestate').
Span-s by stages: ingress ^ authZ ^ app handler ^ DB/Redis ^ PSP/external.
Öznitelikler/etiketler: 'http. route ',' son kullanıcı. id ',' kiracı. id ',' idempotency. Anahtar ',' risk. Skor '.
Örnekler: Gecikme/hata grafiklerindeki noktaları belirli trace-id ile ilişkilendirir.

Örnekleme:
  • "Normal" yollar için kafa tabanlı %1-10,
  • Kuyruklar için kuyruk tabanlı (yavaş/hatalı alın),
  • Zirveler ve olaylar için uyarlanabilir.
  • Bagaj: Her olayı işaretlemeden kesimler için 'kiracı'/' risk' taşır.

8) Günlükler: yapı ve gizlilik

Yapılandırılmış JSON; Gerekli alanlar't ',' trace _ id ',' span _ id ',' route ',' status ',' latency _ ms ',' tenant ',' user _ id _ hash '.
PII politikası: maske PAN/PII; Sırları/belirteçleri inkar et.
Günlük örnekleme: 4xx/5xx/429 ve "uzun" istekler için yüksek.

9) Gösterge tablosu haritası (minimum set)

1. Exec-Summary: RPS, Kullanılabilirlik, Hata oranı, p95/p99 gecikme süresi, 429 paylaşım, yazma oranı bütçesi.
2. Per-Route: RPS/Error/Tail tarafından Üst Endoints; Versiyonların karşılaştırılması (kanarya).
3. Kiracı/Plan Başına: Yük/Maliyet/Hata Liderleri.
4. Bağımlılık Sağlığı: DB, önbellek, PSP/harici - gecikme, hatalar, doygunluk.
5. Kapasite: CPU/RAM/FD, kuyruklar, bağlantı havuzu, GC, konteyner sınırları.
6. Güvenlik/Kötüye Kullanım: 401/403, 429/politikacılar, geo/ASN dilimleri, retray sivri uçları.

10) Uyarılar (eşik ve trend)

'error _ rate {route}'> %2 (5 dakika) ve RPS> N> pager.
'p99 _ latency {critical}'> hedef eşiği (10 dakika).
Bütçeye göre 'burn _ rate' (bkz. § 5).
DB 'timeouts'/' deadlocks' veya growth 'queue _ time'> X ms.
Harici sağlayıcılar: 'outbound _ 5xx _ rate {provider}'> %1 + SLO bağımlı.

11) Kapasitif planlama ve performans

Little yasası: 'L = λ· W' (ortalama kuyruk uzunluğu = trafik × ortalama zaman).
Hedef p95 ayrıştırılır: 'Giriş + uygulama + DB + harici + kuyruk'.
Eşzamanlılık bütçesi: eşzamanlı yazma işlemlerinin maksimum sayısını düzeltin.
Bütçe metriği: "Istek başına CPU ms"; Zirveye %30-50'lik bir marj tutarız.
Oran sınırı ile etkileşim: Kotadaki "tavan" taleplerin oranını ve gecikme üzerindeki etkisini ölçün.

12) Yük ve sentetik kontroller

Türleri: temel yük, patlamalar × 10, "adımlar", uzun vadeli platolar, stres/kaos (düğüm öldürme, ağ gecikmeleri), kritik istemci senaryolarına göre sentetikler.
Profil oluşturma: CPU/alloc/lock-contention, N + 1 (SQL/HTTP), yavaş kodlar.
Regresyon kontrolü: p95/p99/hatalarının serbest bırakılmadan önce/sonra (kanarya) karşılaştırılması.

13) Maliyet-Gözlemlenebilirlik

Maliyet metrikleri: 'cpu _ ms', 'egress _ bytes', 'db _ calls', '$ per 1k requests'.
Uç nokta/kiracı/özelliğe ayırma: orkestratör + yük metriklerinden fatura etiketleri> API birim ekonomisi raporu.
Optimizasyon algoritması: "Trafik × maliyet × (p95 − hedefi)" ürünü tarafından ÜST uç noktaları seçin.

14) Kiracı başına analitik ve'adalet "

Tüm önemli metrikler 'tenant _ id/plan'olarak etiketlenmiştir.
P99 kuyruklarında'ağır "müşterilerin payı; bireysel limitler/kotalar ve bütçeleri yeniden ödeme.
Adil kesme: aşırı yüklendiğinde, "yüksek profilli" kiracıların payını azaltırız.

15) iGaming/Finansın Özellikleri

'Kyc _ level', 'risk _ tier', 'payment _ method' bölümlerine göre.
"Para" yolları için SLI ("POST/para yatırma", "POST/para çekme"): daha düşük hedef p95, ayrı hata bütçeleri.
Time-to-Wallet (TTW) metrikleri, dolandırıcılık karşıtı otomatik kilitlerin payı, ödeme dönüşümü.
Denetim: Finansal eylemler ve dolandırıcılıkla mücadele kararları için değişmez kayıtlar.

16) Enstrümantasyon: Uygulama Uygulamaları

Metrikleri adlandırma (örnek):
  • 'api _ http _ requests _ total' (sayaç)
  • 'api _ http _ request _ duration _ seconds' (histogram)
  • 'api _ outbound _ requests _ total', 'api _ db _ query _ duration _ seconds'
  • 'api _ rate _ limited _ total', 'api _ retry _ total {reason}'

Лейблы: 'route', 'method', 'status _ class', 'tenant', 'region', 'version', 'canary', 'provider', 'db _ table'.
Kardinalite: serbest değerlerden kaçının (user_id), "kovalar "/karma kullanın.
Örnekler: histogramlara bağlan p95/p99 - iz üzerine tıklayarak.

17) Antipatterns

Yüzdelik dilimler yerine orta; statü sınıflarına bölünme yok.
Tutarsız 'rota'/' yol' (dinamik kimlikler etiketlere "dikilir").
Yüksek kardinaliteye sahip etiketler (ham user_id, IP).
Harici sağlayıcıların ayrı bir muhasebesi yoktur (PSP/3. taraf).
"Gürültü'ile uyarılar (tek pencere ve bir eşik).
Kuyruk süresi hariç p99 (maskeler gerçek bozulma).

18) Prod Hazırlık Kontrol Listesi

  • SLI/SLO ve hata bütçesi tanımlanmış, işle anlaşılmış.
  • Tek gecikme histogramları ve durum sınıfları; Panolarda p95/p99.
  • Tam iz (OTel), log/metrik/iz korelasyonu.
  • Yazma hızı uyarıları (iki pencere), p99 eşikleri ve hata oranı.
  • Kiracı/plan başına bölümler ve maliyet raporları.
  • Panolar: Exec, Per-Route, Bağımlılıklar, Kapasite, Kötüye Kullanım.
  • Yük senaryoları (patlama/plato/stres), profilleme.
  • Jitter Retrai Politikaları; Retrays'in RPS üzerindeki etkisini açıklar.
  • Ortaklar ve kamu müşterileri için SLA/SLO belgeleri.
  • Tutma/günlük maskeleme, PII koruması.

19) TL; DR

SLI/SLO ve hata bütçesi etrafında gözlemlenebilirlik oluşturun, KIRMIZI/KULLANIM ölçün, p95/p99 ve kuyruk süresine sahip gecikme histogramlarını toplayın, çevreden DB'ye tek bir iz kimliği dağıtın, kuyruk/uyarlamalı örnekleme kullanın, kiracı başına tutma/maliyet kesintileri ve iki pencereli yanma oranı uyarısı. Kuyruk yasalarına göre kapasite planlaması ve iş ölçütleri üzerindeki etkisi; Antipatterns - persentil yerine orta, yüksek kardinalite ve hesaplanmamış dış bağımlılıklar.

Contact

Bizimle iletişime geçin

Her türlü soru veya destek için bize ulaşın.Size yardımcı olmaya her zaman hazırız!

Telegram
@Gamble_GC
Entegrasyona başla

Email — zorunlu. Telegram veya WhatsApp — isteğe bağlı.

Adınız zorunlu değil
Email zorunlu değil
Konu zorunlu değil
Mesaj zorunlu değil
Telegram zorunlu değil
@
Telegram belirtirseniz, Email’e ek olarak oradan da yanıt veririz.
WhatsApp zorunlu değil
Format: +ülke kodu ve numara (örneğin, +90XXXXXXXXX).

Butona tıklayarak veri işlemenize onay vermiş olursunuz.