GH GambleHub

Analityka API i wskaźniki wydajności

1) Dlaczego go potrzebujesz

API - platforma "układ krążenia. "Bez ścisłych mierników, nie możemy:
  • udowodnić wdrożenie SLO i SLA,
  • zarządzanie przepustowością i ekonomiką zapytań,
  • szybko zlokalizować degradację (ogony p99, pęknięcia 5xx),
  • nadać priorytet optymalizacji wpływu biznesu.

Cel: jeden model obserwacji, w którym każdy wniosek jest śledzony od obwodu do DB z wspólnymi identyfikatorami i spójnymi SLIs.

2) Taksonomia mierników

Techniczne: RPS, latency (p50/p95/p99), szybkość błędów (4xx/5xx), nasycenie (CPU, pamięć, desc-plik), czas kolejki.
Produkt: udane operacje/min, konwersja kroków (200/razem), ograniczony udział (429), przekładki, segmenty użytkownika.
Koszt: koszt/żądanie (CPU-ms + egress + żądania bazy danych), koszt funkcji/punktu końcowego, $/najemca, połączenia $/1k.

3) „Złote sygnały”: CZERWONY I UŻYCIE

RED (dla API):
  • Szybkość - żądania/sec (według punktu końcowego/lokatora/planu).
  • Błędy - 4xx/5xx/429 frakcji i absolutów.
  • Czas trwania - p50/p95/p99 end-to-end i według etapów (ingress → app → DB → strona trzecia).
WYKORZYSTANIE (dla zasobów):
  • Wykorzystanie - obciążenie procesora/IO/kanału.
  • Nasycenie - kolejki (run-queue, backlog, DB wait).
  • Błędy - błędy/czasy sterownika.

4) Podstawowe definicje i wzory

Dostępność SLI: '1 − (5xx + gateway_timeout )/ all_requests'.
Sukces SLI: '2xx/( wszystkie − 429_shadow)' (z wyłączeniem zamków cieni).
Apdex: '(|T≤T| + 0. 5·|T≤4T| )/wszystkie ", gdzie" T "jest docelowym progiem" dobrego ".
Wzmacnianie ogona: 'p99 _ total − max (p99_stage_i)' - wkład kolejek/składu.
Budżet błędu (miesiąc) na 99. 9%: 'budżet = 0. 1% period _ time '.

Zalecane pojemniki percentylowe histogramów opóźnień: '[5ms, 10ms, 25ms, 50ms, 100ms, 250ms, 500ms, 1s, 2. 5s, 5s] ".

5) SLI/SLO i alert według szybkości spalania

Przykład SLO (public API):
  • Dostępność: ≥ 99. 9 %/30 dni.
  • p95 opóźnienie „GET/portfel/balance” <150 ms; „POST/płatności” <400 ms.
  • Błędy '5xx' <0. 2%. „429” (stałe) <1% całkowitego ruchu.
Alerty spalania (dwupoziomowe):
  • 2% budżetu na 1 godzinę lub 5% na 6 godzin → strona do inżyniera.
  • 10% dziennie → priorytety RCA.

6) Zestaw mierników (co do zebrania jest obowiązkowe)

Na obwodzie (brama/WAF):
  • „http _ requests _ total {route, method, status, najemca, plan}”
  • 'http _ request _ duration _ seconds _ bucket {route,...}' (histogram)
  • 'retries _ total {reason}', 'rate _ limited _ total {key, policy}'
  • Rozmiary ciała: 'request _ bytes', 'response _ bytes'
Proszę znaleźć załącznik:
  • 'db _ client _ requests _ total {op, table}', 'db _ latency _ seconds _ bucket {op}'
  • 'cache _ ops _ total {op}', cache hit-rate external calls: 'outbound _ calls _ total {provider, op}', latency/errors/queue timeouts/pools: lengths/delays, active resource USE workers: CPU, RSS, FD, GC pauses

Etykiety firmowe: 'lokator _ id',' region ',' kyc _ level ',' plan ',' feature _ flag '.

7) Ślad i korelacja (OpenTelemetry)

W3C Trace-Context („traceparent”, „tracestate”) na wszystkich chmielach.
Span-s według etapów: ingress → authZ → app handler → DB/Redis → PSP/zewnętrzny.
Atrybuty/etykiety: "http. trasa ',' enduser. id ',' najemca. id ',' idempotencja. klucz „,” ryzyko. wynik '.
Przykłady: Powiązanie punktów na wykresach opóźnień/błędów z określonym identyfikatorem śladu.

Pobieranie próbek:
  • 1-10% w przypadku ścieżek „normalnych”,
  • ogon oparty na ogonach (wolno/błędnie),
  • adaptacyjne do szczytów i incydentów.
  • Bagaż: przenieść „najemcę ”/„ ryzyko” w przypadku cięć bez oznaczania każdego zdarzenia.

8) Dzienniki: struktura i prywatność

Struktura JSON; wymagane pola to 'ts',' trace _ id', 'span _ id',' route ',' status ',' latency _ ms ',' lokator ',' user _ id _ hash '.
Polityka PII: maska PAN/PII; zaprzeczać tajemnicom/żetonom.
Próbkowanie dziennika: wysokie dla 4xx/5xx/429 i „długie” żądania.

9) Mapa deski rozdzielczej (minimalny zestaw)

1. Exec-Summary: RPS, Dostępność, Wskaźnik błędów, Opóźnienie p95/p99, Udział 429, Budżet oparzenia.
2. Na trasie: Górne punkty końcowe według RPS/Error/Tail; porównanie wersji (kanarka).
3. Per-Najemca/Plan: Load/Cost/Error Leaders.
4. Zależność Zdrowie: DB, pamięć podręczna, PSP/zewnętrzne - opóźnienie, błędy, nasycenie.
5. Pojemność: procesor/pamięć RAM/FD, kolejki, pula połączeń, GC, ograniczenia kontenerów.
6. Bezpieczeństwo/Nadużycia: 401/403, 429/politycy, plasterki geo/ASN, kolce retray.

10) Wpisy (próg i tendencja)

'error _ rate {route}'> 2% (5 minut) i RPS> N → pager.
'p99 _ latency {critical}'> próg docelowy (10 minut).
„burn _ rate” według budżetu (zob. § 5).
DB 'timeouts '/' impasy' lub wzrost 'queue _ time'> X ms.
Dostawcy zewnętrzni: 'outbound _ 5xx _ rate {provider}'> 1% + SLO-dependent.

11) Planowanie pojemnościowe i wydajność

Prawo małego: 'L = α· W' (średnia długość kolejki = ruch × średni czas).
Cel p95 jest rozkładany: 'ingress + app + DB + zewnętrzna + kolejka'.
Budżet równoległy: ustalić maksymalną liczbę jednoczesnych operacji zapisu.
Metryka budżetu: „CPU ms per request”; Utrzymujemy margines 30-50% do szczytu.
Interakcja z limitem stawek: Zmierzyć odsetek wniosków przy „pułapie” kontyngentu oraz wpływ na opóźnienia.

12) Kontrole obciążenia i syntetyczne

Rodzaje: obciążenie bazowe, wybuchy × 10, „kroki”, długotrwały płaskowyż, stres/chaos (zabijanie węzłów, opóźnienia sieci), syntetyka według krytycznych scenariuszy klienta.
Profilowanie: CPU/alloc/lock-contention, N + 1 (SQL/HTTP), powolne kody.
Kontrola regresji: porównanie p95/p99/błędy przed/po zwolnieniu (kanarka).

13) Obserwowalność kosztów

Mierniki kosztów: 'cpu _ ms', 'egress _ bytes', 'db _ calls', '$ per 1k requests'.
Przydział do punktu końcowego/najemcy/funkcji: tagi rozliczeniowe z orkiestry + wskaźniki obciążenia → raport ekonomiczny jednostki API.
Algorytm optymalizacji: wybrać punkty końcowe TOP według produktu „ruch × koszt × (p95 − cel)”.

14) Analityka na jednego najemcę i „sprawiedliwość”

Wszystkie kluczowe mierniki są oznaczone jako „najemca _ id/plan”.
Udział „ciężkich” klientów w ogonach p99; indywidualne limity/kwoty i budżety na przekwalifikowanie.
Uczciwe ścinanie: po przeciążeniu zmniejszamy udział „wysokich” najemców.

15) Szczegóły dotyczące iGaming/Finance

Sekcje według 'kyc _ level', 'risk _ tier', 'payment _ method'.
SLI dla ścieżek „money” („POST/deposits”, „POST/withdrawals”): niższy cel p95, oddzielne budżety na błędy.
Metryka czasu do portfela (TTW), udział w automatycznych blokadach zwalczania oszustw, konwersja wypłat.
Audyt: niezmienne kłody dotyczące działań finansowych i decyzji dotyczących zwalczania nadużyć finansowych.

16) Instrumenty: praktyki wykonawcze

Nazywanie mierników (przykład):
  • 'api _ http _ requests _ total' (licznik)
  • 'api _ http _ request _ duration _ seconds' (histogram)
  • 'api _ outbound _ requests _ total', 'api _ db _ query _ duration _ seconds'
  • „api _ rate _ limited _ total”, „api _ retry _ total {reason}”

Левла: „trasa”, „metoda”, „status _ class”, „tenide”, „region”, „wersja”, „kanaryjska”, „dostawca”, „db _ table”.
Kardynalność: unikać wolnych wartości (user_id), używać „wiadra „/hash.
Przykłady: połączyć się z histogramami p95/p99 → klikając na ślad.

17) Antypattery

Średni zamiast percentyli; brak podziału na klasy statusu.
Niespójne 'trasa '/' ścieżka' (dynamiczne identyfikatory są „szyte” do etykiet).
Etykiety o wysokiej kardynalności (surowe user_id, IP).
Brak odrębnej księgowości dostawców zewnętrznych (PSP/trzecia strona).
Wpisy przez „hałas” (jedno okno i jeden próg).
p99 z wyłączeniem czasu kolejki (maski rzeczywistej degradacji).

18) Lista kontrolna gotowości Prod

  • SLI/SLO oraz zdefiniowany budżet błędów, uzgodniony z przedsiębiorstwami.
  • Pojedyncze histogramy opóźnień i klasy statusu; p95/p99 na deskach rozdzielczych.
  • Pełny ślad (OTel), logarytm/korelacja metryczna/śladowa.
  • Alerty spalania (dwurzędowe), progi p99 i wskaźnik błędów.
  • Sekcje per-najemca/per-plan i raporty kosztów.
  • Deski rozdzielcze: Exec, Per-Route, Dependencies, Capacity, Abuse.
  • Scenariusze obciążenia (wybuch/płaskowyż/stres), profilowanie.
  • Jitter Retrai Policies; rozliczanie wpływu przekładni na RPS.
  • Dokumentacja SLA/SLO dla partnerów i klientów publicznych.
  • Retention/log masking, ochrona PII.

19) TL; DR

Zbuduj obserwowalność wokół SLI/SLO i budżetu błędów, zmierz RED/USE, zbierz histogramy latencji z p95/p99 i czasu kolejki, rozprowadzić pojedynczy identyfikator z obwodu do DB, użyć próbkowania ogonowego/adaptacyjnego, trzymać na najemcę/cięcia kosztów i oparzenia dwoma oknami Alarm szybki. Planowanie zdolności zgodnie z przepisami dotyczącymi kolejek oraz wpływ na wskaźniki biznesowe; antypaterie - medium zamiast percentyli, wysoka kardynalność i nieznane zależności zewnętrzne.

Contact

Skontaktuj się z nami

Napisz do nas w każdej sprawie — pytania, wsparcie, konsultacje.Zawsze jesteśmy gotowi pomóc!

Telegram
@Gamble_GC
Rozpocznij integrację

Email jest wymagany. Telegram lub WhatsApp są opcjonalne.

Twoje imię opcjonalne
Email opcjonalne
Temat opcjonalne
Wiadomość opcjonalne
Telegram opcjonalne
@
Jeśli podasz Telegram — odpowiemy także tam, oprócz emaila.
WhatsApp opcjonalne
Format: kod kraju i numer (np. +48XXXXXXXXX).

Klikając przycisk, wyrażasz zgodę na przetwarzanie swoich danych.