Бақылау және телеметрия

(Бөлім: Технологиялар және Инфрақұрылым)

Қысқаша түйіндеме

Бақылау - бұл «ол неге осылай жұмыс істейді?» деп жауап беру қабілеті жаңа билдтер шығарылмай. iGaming-те бұл өте маңызды: ең жоғары турнирлер, төлем шыңдары, көп аймақтық және жауапты гэмблинг/PII талаптары. Базис - жалпы сәйкестендіргіштермен және стандарттармен (OpenTelemetry), SLO-келісімшарттармен, шуға төзімді алертингпен және құнын бақылаумен біріктірілген метриктер, логтер, трассировкалар.

1) Бақылау қаңқасы: ол неден тұрады

Өлшемдер (уақыт бойынша сандар): RED/USE, бизнес-KPI, SLI. TSDB сақталады.
Логи (мәтіндегі оқиғалар/JSON): аудит, қателер, бизнес-фактілер, қауіпсіздік.
Трассировкалар (спендер): сервистер арқылы сұрау жолы, жасырындылық, кідіру себептері.
Профайлинг: CPU/жады/eBPF-ағындары, heap/lock-контеншн.
RUM және синтетика: нақты пайдаланушылар (web/app) + робот тексеру.
Телеметрия каталогы: схемалар, PII саясаты, сақтау мерзімі, құн тегтері.

2) Сигналдардың таксономиясы және қағидаттары

RED для API: Rate, Errors, Duration.
Инфрақұрылымға арналған USE: Utilization, Saturation, Errors (CPU, дискілер, желі, кезектер).
SLI/SLO: өлшенетін индикаторлар (мысалы, табысты сұрау салулар/барлығы, p95 latency), қол жетімділік мақсаттары (мысалы, "99. 9% 30 күнде"), қателер бюджеті → процестердің триггерлері.
High-cardinality ақылды: лейблдер кесінділерде пайдалы болуы тиіс (өңір/тенант/провайдер), бірақ TSDB жаруға болмайды.

3) Стандарттар және толассыз корреляция

OpenTelemetry (OTel): метриктер, логтар және трассировкалар үшін бірыңғай SDK/протокол.
Идентификаторлар: 'trace _ id', 'span _ id', 'correlation _ id', 'player _ id' (псевдонимделген), 'payment _ route'.
ID ағымы: кіріс шлюзі → барлық микросервистер → төлемдер/PSP → кезектер/джобтар → логи/метрика/спендер.

Мысал: корреляция тақырыптары

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

4) Өлшемдер: нені және қалай өлшейміз

Атау/лейблдер

`service="payments-api"`, `env="prod"`, `region="eu-west"`, `tenant`, `provider="pspX"`.

Prometheus мысалдары

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

Гистограммалар мен exemplars

Латенттік гистограммаларын (native-histograms/ β uckets) сақтаңыз және «баяу бакеттен» нақты трассаға секіру үшін exemplar 'trace _ id' -мен байланыңыз.

5) Логи: құрылымдалған және қауіпсіз

Тек JSON (өнімдегі «free-form» жоқ).
Поля: `timestamp`, `severity`, `service`, `trace_id`, `correlation_id`, `player_id_hash`, `event`, `amount`, `currency`, `ip_hash`.
PII бүркемелеу/хэштеу, сезімтал үшін жеке индекстер/retention.
Логтардың пайплайндары: парсинг → қалыпқа келтіру → байыту (geo/ASN) → редакциялау PII → индекстеу.

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) Трассалау: уақыт қайда жоғалады

Спендер: кіріс сұрауы, провайдерлердің қоңыраулары (PSP/ойын провайдерлері), ДБ/кэш, сервистік RPC.
Төлсипаттар: 'db. system`, `net. peer. name`, `messaging. system`, `psp. route`, `game. provider`.

• көлем үшін head-based (ықтималдық),
• tail-based (шарттар бойынша: қателер, p95 +, VIP-сегмент),
• guaranteed-keep төлем/PII-сыни үшін.

7) Майдан мен мобайлдың байқалуы

RUM: TTFB, FCP/LCP/CLS/INP, JS қателері, желілер және SPA-роутинг.
Краш-репорттар: символизация, деобфускация, билд нұсқасы, құрылғы/OS.
Синтетика: кіру/депозит/ставка сценарийлері; геоақпараттық тексерулер.

8) SLO, SLI және бюджет қателері

SLO мысалы (псевдо-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

«Әрбір метрика» бойынша емес, қателіктер бюджеті бойынша алертинг.
Бюджет жанған кезде Freeze-процедуралары: релиздерді/канареяны шектеу.

9) Шусыз алертинг

Multi-window, multi-burn ережелері: қысқа/ұзын терезе.
Дедупликация/рутинг: сервистер/өңірлер/on-call-дағы сындарлылық бойынша.
Runbook URL және мәтінмәнді автоматты түрде жинау (соңғы деплоилер, конфигурацияларды өзгерту, тәуелділік бағандары).
Жоспарлы жұмыстар кезінде тыныш сағаттар және басу.

Ереженің мысалы (PromQL идеясы)

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) Профайлинг және eBPF

eBPF/профайлерлер: CPU/alloc, I/O-жасырындылық, желілік дроптар, Syscall-аномалиялар.
p99 тар жерлер, «джиттер» және сирек тұрып қалу кезінде пайдалы.

11) Бизнес-бақылау (product & risk)

Қаржы/монетизация: депозиттердің конверсиясы, TTW (time-to-wallet), авториз ./сеттл.
Ойын белсенділігі: ретеншн/стрик, live-ставкалардың үлесі, провайдерлердің «жабысқақтығы».
Антифрод/абьюз: әрекет жылдамдығы, құрылғылардың/IP сәйкес келуі, корреляциялар.
RG-индикаторлар: ұзақ сессиялар, «догон», стейктердің өсуі.
Бизнес-метриктер техметриктермен және релиздермен (annotation events) корреляцияланады.

12) Қауіпсіздік, PII және сәйкестік

Data-zones: datacets/log тегтері ('pii = true', 'region = EU').
Индекстеуге дейін бүркемелеу, сәйкестендіргіштерді псевдонимдеу.
аудит үшін WORM-сақтау орны; логқа рөлдік қатынау.
Сақтау мерзімі: техлогтар/аудит/бизнес үшін әртүрлі.
Логтарда шикі құпияларға тыйым салу; CI сканерлеу.

13) Құнын басқару (FinOps)

Түбегейлілік шегі: абайлаңыз с 'user _ id', 'session _ id'.
Партиялану/ретеншн: ыстық (7-14 күн), жылы (30-90), суық (мұрағат).
Сэмплинг трасс (tail-based) және downsampling метрик.
'team', 'service', 'tenant' тегтері бойынша биллинг: «байқауды кім жағады» есептері.

14) Құрал-сайман (референс-стек)

Метриктер: Prometheus/лэйк үшін метриктер, дашбордтар Grafana.
Логи: Loki/ELK; ingestion ережелері, reduction/парсинг.
Трейдерлер: Tempo/Jaeger/OTel-коллекторлар; метрикадан exemplars-линкалары.
Синтетика: Blackbox экспорттаушы, браузерлік роботтар.
Alerting: Alertmanager/чат-интеграция, on-call ротация.
Профайлинг: eBPF/continuous profiling.

15) Мысалдар: негізді жылдам енгізу

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) Процестер және операциялық

Метрик/лейблдердің бірыңғай сөздігі (naming-guide) және дашборд үлгісі.
Release-annotations автоматты түрде бағандарда.
Инциденттер: карточка, таймлайн, RCA айыптаусыз, action items.
Оқу дабылдары («game-day»): құлауды имитациялау, PSP кідірістері, кэштің қызып кетуі.
Runbooks: қадамдық нұсқаулықтар мен автосілтемелер.

17) Жетілгендік чек-парағы

1. OTel SDK/коллектор → метриктер/логтар/трейлерлердің бірыңғай экспорты.
2. RED/USE + SLI/SLO барлық сервистерін негізгі API бойынша жабады.
3. 'trace _ id' корреляциясы ⇄ метрикалық логтар ⇄ (exemplars, jump-links).
4. Бюджет бойынша алерталар multi-burn және рунабук-сілтемелерімен қателер.
5. RUM + синтетика «депозитке/мөлшерлемеге/шығарылымға».
6. Ақ тізім бойынша профайлинг (eBPF).
7. PII-саясат: бүркемелеу, аймақтар, қол жеткізу, сақтау мерзімдері.
8. Телеметрия құны бойынша қаржылық есеп (тегтер 'team/service').
9. «Ең жоғары жүктемеге дайындық»: тест-жоспар, кэштерді жылыту, alert-шаблондар.
10. Тұрақты RCA және SLO/шектерді қайта қарау.

18) Антипаттерндер

Құрылымы жоқ «жаймалармен» және 'trace _ id'.
Әрбір метрика бойынша алерталар → алерт-фэтИг.
Түзету бакеттерсіз гистограммалар → «жазық» p95.
Лейблдердің шексіз түбегейлілігі → құн жарылысы.
RUM/синтетиканың болмауы - «бәрі жақсы», ал пайдаланушыға жоқ.
PII-ді техлогтармен араластыру, мерзімсіз ретенция.
Телеметрияны бизнес-KPI-дан оқшаулау - «жасырындылық төмендейді, түсім де төмендейді».

Күшті бақылау - бұл өнім, SRE, қауіпсіздік және төлемдер арасындағы ортақ тіл. Метриканы, логды, трассаны OTel-ге біріктіріп, SLO-ны қателер бюджетімен енгізіп, алертингті ақылды және басқарылатын құнды ете отырып, сіз бұрын проблемаларды байқайтын, тез қалпына келетін және трафик пен турнирлік жүктемелердің ең жоғары шегінен өтетін жүйені аласыз.