Monitorowanie i pozyskiwanie drewna

1) Dlaczego ma znaczenie w iGaming

Pieniądze w czasie rzeczywistym: przyjmowanie depozytów, błyskawiczne płatności, obliczanie zakładów i wygranych, turnieje - wszystko jest wrażliwe na opóźnienia i awarie.
Regulacja i audyt: wymagana jest pełna identyfikowalność działań (KYC/AML, płatności, limity odpowiedzialności).
Złożona architektura rozproszona: bramy API, orkiestra płatnicza, EDA/Kafka, usługi dostawcy, klienci mobilni, fronty, autobus BI.
Cel: aby zmniejszyć MTTD/MTTR, utrzymać SLO na złotych sygnałach i zapewnić szybkość incydentów.

2) Podstawowe pojęcia obserwowalności

Dzienniki: szczegółowe zdarzenia (strukturyzowany JSON) odpowiednie do dochodzeń i audytów.
Mierniki: kruszywa w czasie (TSDB), odpowiednie do SLO/wpisów.
Ślady: łańcuchy przyczynowo-skutkowe żądań (śledzenie/rozpiętość) za pośrednictwem usług/brokerów/baz danych.
Wydarzenia: wydarzenia domeny (BetPlaced, DepositApproved) - most między metrykami biznesowymi a technologią.

3) „Złote sygnały” i SLI/SLO dla iGaming

Opóźnienie: P95/P99 o przepływach krytycznych (autoryzacja, depozyt, stopa, start sesji, spin).
Ruch: RPS przez API, TPS przez płatność, EPS przez zdarzenie.
Błędy: 5xx/4xx share, decline-rate, failed-within, dostawca błędów.
Nasycenie: procesor, pamięć, IO, Kafka lag, połączenia DB, gwintowane baseny.

• SLI: „1 - (failed_payments/ total_payments)”
• SLO: 99. 7% udanych autoryzacji kart w ciągu 30 dni (budżet błędu 0. 3%).

4) Architektura zbierania i przetwarzania

1. Wstrzyknięcie: środki (OTel Collector/Fluent Bit), SDK w aplikacji, RUM/syntetyki.
2. Routing: broker/telemetry bus (OTLP/HTTP/GRPC), filtry i maskowanie PII.

• Mierniki: TSDB (agregacja, downsampling).
• Dzienniki: gorący (indeksowany )/ciepły (mniej indeksowany )/zimny (obiekt przechowywania, WORM).
• Szlaki: indeksowane czasowo przechowywanie z retencjami i pobieraniem próbek ogonowych.
• 4. Analityka/wpisy: zasady (PromQL/LogQL/SQL), korelacja z utworami i wydaniami.
• 5. Deski rozdzielcze: techniczne + rodzaje działalności (płatności, RNG/dostawcy, silnik turniejowy).

5) Standard dziennika (JSON) i taksonomia zdarzeń

Zaleca się ścisłe rejestrowanie JSON, pojedyncze klawisze i poziomy.

Мровна: 'DEBUG

Таксоновий: "auth.", "payment.", "gameplay.", "risk.", "psp.", "kyc'.," rg. "(odpowiedzialne gaming)," op. ".

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"
}
}

• Maskujemy PAN/BIN (przechowujemy tylko pola ważne według zasad), e-mail/telefon - hash/token.
• Skrót IP do/24, GeoIP przechowywać oddzielnie.
• Zabraniamy bezpłatnego tekstu w 'extra' dla wejścia użytkownika bez sanitarnego.

6) Korelacja: trace_id, correlation_id, idempotency_key

Dodaj 'trace _ id' (z OTel),' span _ id', 'correlation _ id' (end-to-end dla procesu biznesowego),' idempotence _ key '(dla żądań płatności) do każdego dziennika i metryki.
Transfer bagażu (najemca/marka, rynek, opcja A/B) do budowy plasterków.

7) Metryki: Techniczne i biznesowe

Techniczne: RPS, p95 latency, wskaźnik błędów, nasycenie, GC, wykorzystanie puli, Kafka consumer lag.
Biznes: CR registratsii → depozit, udane autoryzacje, anulowanie płatności, NGR/GGR, ARPPU, anomalie RTP, drop-off na kroku KYC, udział odpowiedzialnych limitów.

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

8) Odwzorowanie i OpenTelemetry

Oferujemy bramę, orkiestrę płatności, rdzeń gry, powiadomienia, KYC/AML, integrację z dostawcami.
Pobieranie próbek głowicy dla całkowitego przepływu + pobieranie próbek ogonowych (podwyższonych) dla błędów/utajonych przęseł i płatności.
Rozmnażanie kontekstowe: „traceparent ”/„ tracestate”, nagłówki Kafka, metadane gRPC.
Adnotacja przęseł z zdarzeniami domeny: 'BetPlaced', ' Requested'.

9) Ostrzeganie bez hałasu

Progi wielostopniowe (ostrzegawcze/krytyczne), tłumienie klapowania, deduplikacja, sloty czasowe.
Korelacja: kojarzymy „5xx growth” + „Kafka lag” + „p95 latency PSP” → jeden incydent.
Wpisy oparte na SLO: wydać błąd-budżet - eskalować.
Alerts-as-Code (GitOps), przegląd i testy reguł.

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) Wyszukiwanie dziennika (przykład LogQL)

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

Celem jest szybkie usunięcie hałasu i podkreślenie „drogich” awarii w regionie docelowym.

11) Deski rozdzielcze: co jest obowiązkowe

Zdrowie płatności: sukces/porażki PSP, opóźnienia metodą, mapą regionów, dostawcami usług SLA.
Rdzeń gry: RPS przez dostawców, spin p95, stosunek błędów SDK, anomalie RTP przez szczeliny.
Player Journey: registratsiya → KUS → depozit → igra → vyvod.
Infra: Kafka lag, połączenia DB, współczynnik trafienia pamięci podręcznej, gromada Kubernetes (siatka strąków/węzłów).

12) Przechowywanie, zatrzymywanie i koszt (FinOps)

Kardynalność pod kontrolą: unikać metryki z wysoce zmiennymi etykietami (user_id).
Retencje: hot metrics 30-90 dni, obniżenie sampling do 13 miesięcy; kłody gorące 7-14 dni, ciepłe 30-90 dni, zimne 1-3 lata (biorąc pod uwagę regulację).
WORM/immutability for audits logs, Object Lock.
kompresja/podział i polityka ILM; oddzielne indeksy audytu/bezpieczeństwa PII.
Pobieranie próbek dzienników na INFO/DEBUG; BŁĄD/AUDYT - zakończenie.

13) Bezpieczeństwo i zgodność

PII/PCI: tokenizacja, hashing, maskowanie; zminimalizowanie danych.
RBAC/ABAC: dostęp do kłód/utworów - według roli, separacji markiz.
Sekrety i klucze: nie loguj poświadczeń/żetonów; tajne detektory na CI.
Ścieżka audytu: wpisy do panelu administracyjnego, zmiany limitów/płatności, ręczne korekty salda - tylko do indeksu AUDYTU, niezmiennie.
Posiadanie prawa: mechanizm zamrażania zatrzymań w dochodzeniach.

14) Jakość danych telemetrycznych

Schemat Rejestr dzienników/zdarzeń (wersioning, kompatybilność).
Pojedyncza nomenklatura pól (snake_case, jednostki miary).
Walidacja przy wstrzyknięciu (kropla brudnych zdarzeń, wskaźniki małżeństwa).
Ciśnienie wsteczne i ochrona przed „burzami dziennika”.

15) Procesy SRE, połączenia online i książki startowe

Macierz Oncall i eskalacje; Ciche godziny i obroty.
Zakładki są powiązane z wpisami (etapy diagnostyczne, przepisy SQL/LogQL, ficheflagi do degradacji).
Postmortem bez kar, pozycje działania z właścicielami i terminy.
Wskaźniki zespołu: MTTD/MTTR, odsetek hałaśliwych wpisów, zasięg Runbuk.

16) RUM i syntetyki

RUM: WebVitals (LCP, CLS, INP), błędy czołowe, odciski palców urządzenia, regiony/dostawcy.
Syntetyka: scenariusze „registratsiya → depozit → spin → vyvod” z różnych regionów; prywatne lokalizacje dla ścieżek wewnętrznych (admin/back office).

17) Praktyki uwalniania, eksperymentów i ficheflagów

Łączymy utwory z wersjami wydania (commit/artefact).
A/B tagi w bagażu → deska rozdzielcza „efekt eksperymentu na SLI”.
Canary/Blue-Green: oddzielne panele dla kanaryjczyków, wskaźnik oparzeń błędów w budżecie.

18) Wykrywanie anomalii i sygnały zwalczania nadużyć finansowych

Uruchamianie statystyczne (świadomość sezonowości) w zakresie spadku/ryzyka obciążenia zwrotnego/wzrostu liczby nowych kart.
Korelacje: „wzrost nieudanych depozytów + nowe wydanie adaptera PSP”.
Zasady przesyłania strumieniowego (Kafka → Flink) dla reakcji w czasie zbliżonym do rzeczywistego.

19) Plan działania na rzecz realizacji (według etapów)

Etap 0 - Podstawa: dzienniki JSON, jednolite pola korelacji, podstawowe mierniki usług, wspólne deski rozdzielcze, pierwsze wpisy.
Etap 1 - Odwzorowanie: Oprzyrządowanie OTel, próbkowanie głowy + ogona, powiązanie z dziennikami.
Etap 2 - Business SLI/SLO: płatności/wyjścia/wskaźniki gry, wpisy SLO, procesy błędów-budżetu.
Etap 3 - Dojrzałość: Alerts-as-Code, ILM, oddzielne zatrzymania, anomalia-detection, per-service runbuki, praktyki SRE w CI/CD.

20) Lista kontrolna

• Tylko dzienniki JSON, pojedyncze klucze, maskowanie PII.
• W każdym przypadku: 'trace _ id',' span _ id', 'correlation _ id',' lokator '.
• Wskaźniki obejmują sygnały złota i przepływy biznesowe.
• Opisano SLO, istnieje budżet błędów i wpisy dotyczące szybkości spalania.
• Pobieranie próbek za pomocą ogona jest możliwe w przypadku błędów w płatnościach i dużych opóźnień.
• ILM i WORM są skonfigurowane dla dzienników audytu.
• RBAC dla telemetrii, audyt dostępu.
• Dashboards for Payments/Game Core/Player Journey/Infra.
• Książki startowe są powiązane z każdym krytycznym wpisem.
• Postmortems i pozycje akcji - w zaległości z właścicielami.

Dodatek A: Atrybuty OpenTelemetry (zalecenie)

"służba publiczna. nazwa „,” usługi. wersja „,” wdrożenie. środowisko "

'głośno. region „,” k8s. pod. nazwa „,” k8s. pojemnik. nazwa "

„najemca”, „marka”, „rynek”, „ab _ test”, „user _ segment”

"płatność. metoda ',' psp ',' gra. dostawca „,” gra. „ida”

Dodatek B: Przykłady wskaźników SLO

„payment _ success _ ratio”, „withdrawal _ ttw _ p95” (czas do portfela), „psp _ latency _ p99”

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

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

Dodatek C: Szybkie przepisy dochodzeniowe

„Rosnąca 'płatność _ error _ rate'” → porównaj według PSP/region/metoda, sprawdź ścieżki ogonowe, patrz wydanie adaptera.
„p99 spins” trace →, front → geytvey → provayder check provider/channels, thread pool limits, network retrays.
„Kafka lag” → konsumenci zdrowia, producenci retro, backpressure, powolne zlewy/DB.