Obserwowalność i telemetria

(Sekcja: Technologia i infrastruktura)

Krótkie podsumowanie

Obserwowalność jest umiejętnością reagowania na „dlaczego tak działa?” bez uwolnienia nowych budowli. W iGaming, jest to krytyczne: turnieje szczytowe, szczyty płatności, wielowymiarowość i odpowiedzialne wymagania hazardowe/PII. Podstawa - metryki, kłody, ślady, zjednoczone przez wspólne identyfikatory i standardy (OpenTelemetry), z kontraktami SLO, odporne na hałas alarmu i kontroli kosztów.

1) Ramy obserwacji: co składa się z

Mierniki (liczby według czasu): RED/USE, business KPI, SLI. Przechowywany w TSDB.
Dzienniki (wydarzenia w tekście/JSON): audyt, błędy, fakty biznesowe, bezpieczeństwo.
Ślady (przęsła): ścieżka żądania przez usługi, opóźnienia, przyczyny opóźnień.
Profilowanie: CPU/pamięć/eBPF strumienie, hałas/blokada zawartości.
RUM i syntetyka: prawdziwi użytkownicy (web/app) + kontrole robotów.
Katalog telemetrii: schematy, zasady PII, okresy retencji, znaczniki kosztów.

2) Taksonomia sygnału i zasady

RED дла API: Rate, Errors, Duration.
ZASTOSOWANIE do infrastruktury: Wykorzystanie, Nasycenie, Błędy (procesor, dyski, sieć, kolejki).
SLI/SLO: wskaźniki wymierne (np. udane wnioski/wszystkie, opóźnienia p95), cele dostępności (np. "99. 9% w 30 dni"), budżet błędu → wyzwalacze procesu.
Wysoka kardynalność mądrze: etykiety powinny być przydatne w cięciach (region/najemca/dostawca), ale nie wysadzić TSDB.

3) Normy i korelacja końcowa

OpenTelemetry (OTel): pojedynczy SDK/protokół dla mierników, dzienników i śladów.
Identyfikatory: 'trace _ id',' span _ id', 'correlation _ id',' player _ id' (pseudonimized), 'payment _ route'.
Flow ID: ingress gateway → wszystkie mikroservice → płatności/PSP → kolejki/oferty pracy → logs/metrics/spans.

Przykład: Nagłówki korelacji

traceparent: 00-<trace_id>-<span_id>-01 x-request-id: <correlation_id>

4) Metryka: co i jak mierzymy

Nazwy/etykiety

'service =' payments-api '', 'α =' prod', 'region =' eu-west ',' najemca ',' provider = 'pspX'.

Przykłady Prometeusza

prometheus
RED http_requests_total{service="api",route="/deposit",method="POST",status="200"}
http_request_duration_seconds_bucket{service="api",le="0. 25",route="/deposit"} 1234 http_request_errors_total{service="api",route="/deposit"}

USE cpu_utilization_ratio{node="n1"} 0. 71 queue_depth{queue="withdrawals"} 128

Бизнес payments_success_total{psp="X",currency="EUR"} 4521 payment_conversion_ratio{route="pspX"} 0. 948

Histogramy i wzorce

Przechowywać histogramy opóźnień (rodzime histogramy/β kieszenie) i wiązać wzorzec z 'trace _ id', aby przejść z' wolnego wiadra 'do określonego toru.

5) Kłody: ustrukturyzowane i bezpieczne

Tylko JSON (brak „wolnej formy” w prod).
Мола: 'timestamp', 'severity', 'service', 'trace _ id',' correlate _ id', 'player _ id _ hash', 'event', 'amount', 'currency', 'ip _ hash'.
Maskowanie/hashing PII, oddzielne indeksy/retencja dla wrażliwych.
Rurociągi dziennika: parsing → normalizacja → wzbogacenie (geo/ASN) → edycja PII → indeksowanie.

Przykład zdarzenia JSON

json
{
"ts":"2025-11-05T10:42:31Z",
"sev":"ERROR",
"service":"payments-api",
"event":"psp_timeout",
"trace_id":"9c5e...e2",
"route":"pspX",
"duration_ms": 3100,
"attempt":2,
"player_id_hash":"p:1b7f...",
"pii_redacted":true
}

6) Ślady: gdzie traci się czas

Przęsła: żądanie wejścia, połączenia dostawców (dostawców PSP/gier), bazy danych/pamięci podręcznej, międzywydziałowych RPC.
Atrybuty: 'db. system „,” net. peer. nazwa ',' wiadomości. system „,” psp. trasa ',' gra. dostawca ".

• głowica do objętości,
• oparty na tail (według warunków: błędy, p95 +, segment VIP),
• gwarantowane przechowywanie płatności/PII-critical.

7) Obserwowalność przedniej i ruchomej

RUM: TTFB, FCP/LCP/CLS/INP, błędy JS, sieci i routing SPA.
Raporty awaryjne: symbolizm, deobfuscation, build version, device/OS.
Syntetyka: scenariusze wejścia/depozytu/oprocentowania; kontrole geodistributu.

8) SLO, SLI i budżet na błędy

Przykład SLO (Pseudo-YAML)

yaml service: payments-api sli:
- name: availability expr: sum(rate(http_requests_total{status=~"2..    3.."}[5m]))
/ sum(rate(http_requests_total[5m]))
- name: latency_p95 expr: histogram_quantile(0. 95, rate(http_request_duration_seconds_bucket[5m]))
targets:
availability: "99. 9%/30d"
latency_p95: "<=250ms/30d"
error_budget_policy:
fast_burn: 5% for 1h -> page, freeze deploy slow_burn: 20% for 24h -> incident, improvement plan

Alarmowanie przez budżet błędu, nie przez „każdą metrykę”.
Procedury zamrożenia spalania budżetu: zwolnienia limitów/kanarki.

9) Ostrzeganie bez hałasu

Multi-window, zasady multi-burn: krótkie/długie okno.
Deduplicacja/ukorzenienie: według usługi/regionu/krytyki w dyżurze.
URL w książce startowej i autokollection kontekstowej (najnowsze wysyłki, zmiany konfiguracyjne, wykres zależności).
Ciche godziny i tłumienie podczas zaplanowanej pracy.

Reguła przykładowa (PromQL idea)

promql alert: PaymentsSLOFastBurn expr: slo_error_rate_5m > 2 slo_budget_rate for: 15m labels: { severity="page", service="payments-api" }
annotations:
summary: "SLO fast burn"
runbook: "https://runbooks/payments/slo"

10) Profilowanie i eBPF

eBPF/profilery: wykresy płomieni CPU/alloc, opóźnienie I/O, krople do sieci, anomalie Syscall.
Przydatne do wąskich gardeł p99, jitter i rzadkich zamrażarek.

11) Obserwowalność działalności gospodarczej (produkt i ryzyko)

Finanse/monetyzacja: konwersja depozytów, TTW (czas do portfela), autor ./rozrachunek, anulowanie/obciążenie zwrotne.
Aktywność gry: retencja/smuga, udział zakładów na żywo, „lepkość” dostawców.
Przeciwdziałanie nadużyciom: szybkość działania, zapałki urządzenia/IP, korelacje.
Wskaźniki RG: długie sesje, „dogon”, wzrost steków.
Wskaźniki biznesowe są skorelowane z metrykami technicznymi i zdarzeniami adnotacyjnymi.

12) Bezpieczeństwo, PII i zgodność

Strefy danych: zbiory danych/znaczniki dziennika („pii = true”, „region = UE”).
Maskowanie przed indeksowaniem, aliasowanie identyfikatorów.
Sklepy WORM do audytu; dostęp do dziennika opartego na rolach.
Okresy przechowywania: różne dla techlogów/audytów/przedsiębiorstw.
Zakaz surowych tajemnic w dziennikach; sprawdzenie skanowania w CI.

13) Zarządzanie wartością (FinOp)

Limit kardynalności: ostrożnie z 'user _ id',' session _ id'.
Udział/zatrzymanie: gorące (7-14 dni), ciepłe (30-90), zimne (archiwum).
Próbki na bazie ogona i metryki obniżające poziom.
Billing by tags' team ',' service ',' lokator ': raporty „kto spala obserwowalność”.

14) Narzędzia (komin referencyjny)

Metryka: Prometeusz/jezioro do mierników, deski rozdzielcze Grafana.
Dzienniki: Loki/ELK; zasady spożywania, redukcja/parsowanie.
Szlaki: kolektory Tempo/Jaeger/OTel; przykładowe linki z metryk.
Syntetyka: eksporter Blackbox, roboty przeglądarki.
Uwaga: integracja Alertmanager/chat, rotacja dyżurów.
Profilowanie: eBPF/profilowanie ciągłe.

15) Przykłady: Szybko wdrożyć fundację

python from prometheus_client import Counter, Histogram, start_http_server reqs = Counter('http_requests_total','', ['route','method','status'])
lat = Histogram('http_request_duration_seconds','', ['route'])
def handle(req):
with lat. labels(route=req. route). time():
status = app(req)
reqs. labels(route=req. route,method=req. method,status=str(status)). inc()

go tid:= ctx. Value("trace_id")
logger = logger. With("trace_id", tid)
logger. Info("deposit-accepted", "amount", amt, "route", route)

prometheus http_request_duration_seconds_bucket{..., le="0. 25"} 1023 # exemplar: trace_id=9c5e...

16) Procesy i system operacyjny

Jednolity słownik metryk/etykiet (naming-guide) i szablon deski rozdzielczej.
Adnotacje uwalniania automatycznie w kolumnach.
Incydenty: karta, linia czasu, RCA bez opłat, elementy akcji.
Alarmy treningowe („gra-day”): symulowane krople, opóźnienia PSP, przegrzanie pamięci podręcznej.
Runbooks: instrukcje krok po kroku i auto-linki z wpisów.

17) Lista kontrolna zapadalności

1. OTel SDK/kolektor → pojedynczy eksport metryk/kłód/szlaków.
2. RED/USE obejmuje wszystkie usługi + SLI/SLO przez key API.
3. Korelacja 'trace _ id' ⇄ dzienniki ⇄ mierniki (przykłady, skoki).
4. Wpisy dotyczące błędów budżetowych z linkami multi-burn i runabook.
5. RUM + syntetyki dla „depozytu/stopy/wypłaty”.
6. Profilowanie (eBPF) w sprzedaży białej listy.
7. Polityka PII: maskowanie, strefy, dostęp, okresy retencji.
8. Sprawozdanie finansowe dotyczące kosztów telemetrii (znaczniki "zespół/serwis').
9. „Gotowość do obciążenia szczytowego”: plan testowy, podgrzewanie buforów, szablony alarmowe.
10. Regularne RCA i korekty SLO/progowe.

18) Antypattery

Dzienniki „arkusze” bez struktury i 'trace _ id'.
Wpisy dla każdej metryki → alert FAT.
Histogramy bez poprawnych wiader → „płaski” p95.
Nieograniczona kardynalność etykiet → eksplozja wartości.
Brak RUM/syntetyki jest „w porządku”, ale użytkownik nie jest.
Mieszanie PII z technologami, retencja na czas nieokreślony.
Izolacja telemetrii od KPI biznesowych - „opóźnienie spada, przychody też”.

Podsumowanie

Silna obserwacja to wspólny język między produktem, SRE, bezpieczeństwem i płatnościami. Poprzez podłączenie mierników, dzienników, utworów dla OTel, wprowadzenie SLO z budżetem błędów, dzięki czemu alarmowanie inteligentne i opłacalne, otrzymasz system, który wcześniej zauważa problemy, odzyskuje szybciej i przewidywalnie przechodzi szczyty ruchu i obciążenia turniejowe.