Torrent Gear

Інструменти моніторингу API та інфраструктури

1) Принципи: від цілей до інструментів

SLO-first: вибирайте і налаштовуйте інструменти під продуктові цілі (логін, депозит, ставка), а не навпаки.

Open standards: OpenTelemetry (трейси/метрики/логи), Prometheus exposition format, Loki JSON-логи.

Єдиний контекст: 'trace _ id '/' span _ id'в логах і метриках; лінки «дашборд → трейс → лог».

Cost-aware: кардинальність метрик, TTL логів, sampling трейсів - заздалегідь.

2) Метрики: збір, зберігання, візуалізація

Збір: Prometheus / Agent-режим (VictoriaMetrics Agent, Grafana Agent, OpenTelemetry Collector).

Сховища (TSDB): Prometheus (single), Thanos/Cortex/Mimir (горизонтальне масштабування), VictoriaMetrics (економія CPU/RAM).

Візуалізація: Grafana як «скляна панель».

Що міряти для API (RED) та інфраструктури (USE):

RED: `rate(requests)`, `error_ratio`, `latency p95/p99` по `route`, `method`, `provider`.
USE: CPU/Mem, file descriptors, connection pools, queue lag, GC pauses.

Корисні експортери:

k8s: kube-state-metrics, node-exporter, cAdvisor, ingress/gateway exporters.
БД/кеші: postgres_exporter, mysql_exporter, redis_exporter, kafka_exporter, rabbitmq_exporter.
Сервіс-меш: Envoy metrics, istio/Linkerd dashboards.
PSP/зовнішні: custom exporters (webhook success, PSP success ratio, callback latency).

Приклади PromQL (начерки):

promql
Успішність депозитів (SLI)
sum(rate(ig_payments_requests_total{route="/payments/deposit",status=~"2.."}[5m]))
/
sum(rate(ig_payments_requests_total{route="/payments/deposit"}[5m]))

p95 latency API histogram_quantile(0. 95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, route))

Насичення пулу підключень до БД db_connections_in_use/ db_connections_max

3) Логи: пошук, кореляція, незмінюваність

Стек: OpenSearch/Elasticsearch + Beats/Vector/Fluent Bit або Grafana Loki (дешевше на зберіганні, «лог-як-стрім»).

Формат: JSON зі стандартними полями'ts, level, service, env, trace_id, user_pid, route, status, latency_ms'.

Практики: маскування PII, WORM-бакети для аудиту, TTL/ILM політики, партіонування по'env/region/brand'.

4) Трасування: де губляться мілісекунди

Стек: OpenTelemetry SDK/Collector → Jaeger/Tempo/Honeycomb/New Relic Traces.

Політика семплування: 100% помилок, адаптив для «повільних» запитів, 1-5% успішних.

Теги iGaming: `provider`, `psp`, `risk_decision`, `bonus_id`, `market`, `ws_table_id`.

Швидкий рецепт дебага: з червоного графа SLO → трейс проблемного маршруту → «товстий» спан на PSP/ігровому провайдері → лог вебхука.

5) APM-платформи: коли «все-в-одному»

Комерційні рішення (Datadog, New Relic, Dynatrace, Grafana Cloud) закривають APM, логи, трейси, синтетику, RUM.

Плюси: швидкість впровадження, кореляція «з коробки». Мінуси: вартість/вендор-лок.

Гібрид: ядро на OSS (Prometheus + Grafana + Tempo + Loki), «домальовувати» синтетику/алертинг комерційними модулями по критичних флоу.

6) Синтетика і RUM: «зовні» і «очима гравця»

Синтетика: Checkly, Grafana Synthetic Monitoring, k6 Cloud, Uptrends, Pingdom, Catchpoint, ThousandEyes.

Скрипти: логін → депозит (sandbox) → запуск гри → перевірка вебхука.

Гео: EU/LatAm/MEA/APAC, мобільні мережі, ASN-мікс.

RUM: Web-SDK (TTFB/LCP/CLS), мобільні SDK; сегментація по країні/мережі/пристрою.

7) Kubernetes-поверхні моніторингу

Control plane: etcd, API-server (apiserver_request_total, latency), scheduler/controllermanager.

Data plane: kubelet, CNI, ingress/gateway;'PodDisruptionBudget'і евікшени.

Автоскейл: HPA/VPA/Cluster Autoscaler метрики і події; warm-пули.

Мережеві політики: дропи/deny events, DNS latency.

8) Бази даних, черги, кеші

Postgres/MySQL: лаг реплікації, deadlocks, bloat, WAL, checkpoint duration, таймаути.

Kafka/RabbitMQ: consumer lag, rebalances, queue depth, redeliveries.

Redis: evictions, blocked clients, latency percentiles, репліка-лаг.

PITR/бекапи: завдання backup-операторів + дашборд «час до відновлення».

9) Мережа, CDN, WAF, провайдери ігор і PSP

CDN/Edge: hit-ratio, TTFB по регіонах, shield hit, «шторм промахів».

WAF/бот-менеджер: share челленджів/блоків, ASN/країни, FPR на логіні/депозиті.

Game providers: час запуску столу/слота, відмова/таймаути по студіях.

PSP: success ratio/latency за методом/країні/BIN, коди помилок 3DS/AVS, webhooks success & delay.

10) Алертінг і чергування

Роутинг: Alertmanager → PagerDuty/Opsgenie/Slack.

Правила: симптомні (SLO) + причинні (ресурси).

Антишум: угруповання, придушення ланцюгових алертів, вікна тиші на реліз.

SLO-гейти в CD: авто-пауза/відкат при порушеннях (Argo Rollouts/Flagger AnalysisRun).

Приклади алертів (спрощено):

`login_success_ratio < 99. 9% for 10m`
`p95 /payments/deposit > 0. 4s for 10m`
`db_connections_saturation > 0. 85 for 5m`
`kafka_consumer_lag > 30s`
`cdn_hit_ratio drop > 15% in 10m (per region)`

11) Дашборди, які реально допомагають

Флоу депозиту: воронка, p95/p99, помилки по PSP/BIN/країнам, затримка вебхуків.

Live-ігри/WS: підключення, RTT, resend/reconnect, помилки по провайдерам.

Здоров'я API: RED за маршрутами, saturations, top slow endpoints ↔ трейс.

DR-панель: replication lag, WAL shipping, synthetic login/deposit з DR-регіону.

Security: WAF, bot score, 401/403 аномалії, підписані вебхуки.

12) Управління вартістю телеметрії

Кардинальність метрик: не включайте'user _ id'в лейбли, ліміти на'route'і'provider'.

Downsampling і retention-класи (гарячі 7-14 днів, теплі 30-90, холодний архів).

Логи:стрибок подій - вмикайте семплювання/дедуп; зберігайте stacktrace окремо.

Трейси: динамічне sampling по «дорогих» шляхах (платежі/висновки).

13) Безпека і приватність в моніторингу

mTLS від агентів до колекторів; шифрування at-rest.

Псевдонімізація'user _ pid', заборона e-mail/телефону/документів в логах.

RBAC/MFA, WORM для аудиту; DPA зі сторонніми провайдерами моніторингу.

14) Інтеграція з CI/CD і автовідкат

Експозиція SLI як пром-метрик для CD-аналізів.

Release labels ('version','rollout _ step') в метриках/логах/трейсах.

Автоматичні канарські гейти: деплою продовжиться тільки при зелених SLO.

15) Швидкий старт-стек (референс)

Збір/транспорт: OTEL Collector + Prometheus/VM Agent + Fluent Bit.

Сховище: VictoriaMetrics/Thanos (метрики), Loki/OpenSearch (логи), Tempo/Jaeger (трейси).

Візуалізація: Grafana + готові дашборди k8s/Envoy/Postgres.

Синтетика & RUM: Checkly/k6 + Grafana RUM (або комерційний аналог).

Алертінг: Alertmanager → PagerDuty/Slack; runbooks в посиланнях.

16) Чек-лист впровадження (prod-ready)

Визначені SLO/SLI для логіну/депозиту/ставки/виведення.
Метрики RED/USE + бізнес-SLI; єдина онтологія лейблів.
Логи JSON з'trace _ id', маскування PII, WORM для аудиту.
OpenTelemetry end-to-end; семплювання помилок 100%.
Синтетика з ключових регіонів + RUM в проді.
Дашборди «флоу депозиту», «WS», «здоров'я API», «DR».
Алертінг: SLO-симптоми + ресурсні причини; Антишум.
SLO-гейти підключені до CD; Автовідкат.
План вартості: ретеншен/семплювання/кардинальність.
DPA/безпека: mTLS, RBAC, приватність логів.

Резюме

Сильний моніторинг - це не набір «красивих графіків», а зв'язна система: метрики RED/USE, логи з'trace _ id', OpenTelemetry-трасування, синтетика і RUM, плюс дашборди, алертинг і SLO-гейти, вбудовані в ваш CI/CD. Зберіть стек навколо відкритих стандартів, контролюйте вартість телеметрії і стандартизуйте онтологію лейблів - тоді будь-які проблеми з API та інфраструктурою будуть видні заздалегідь і лагодитися до того, як їх помітять гравці.