Monitoreo y lógica

1) Por qué es importante en iGaming

Dinero en tiempo real: recepción de depósitos, pagos instantáneos, liquidación de apuestas y ganancias, torneos - todo es sensible a retrasos y fallas.
Regulación y auditoría: se requiere una trazabilidad completa de las acciones (KYC/AML, pagos, límites de juego responsable).
Arquitectura distribuida compleja: pasarelas API, orquestación de pagos, EDA/Kafka, servicios de proveedores, clientes móviles, frentes, BI-bus.
Objetivo: reducir el MTTD/MTTR, mantener el SLO a través de señales doradas y proporcionar un forensic de incidentes.

2) Conceptos básicos de observabilidad

Registros: eventos detallados (estructurados por JSON) adecuados para investigaciones y auditorías.
Métricas: unidades de tiempo (TSDB), adecuadas para SLO/alertas.
Tracks: cadenas de consultas causales (trace/span) a través de servicios/brókeres/DB.
Eventos: eventos de dominio (BetPlaced, Depositapproved) es el puente entre las métricas de negocio y la técnica.

3) «Señales de oro» y SLI/SLO para iGaming

Latency: P95/P99 de flujo crítico (autorización, depósito, apuesta, inicio de sesión, giro).
Tráfico: RPS por API, TPS por pago, EPS por evento.
Errores: fracción 5xx/4xx, tasa de defecto, fallidos-withdrawals, errores de proveedores.
Saturation: CPU, memory, IO, Kafka lag, DB connections, thread-pools.

• SLI: `1 - (failed_payments / total_payments)`
• SLO: 99. 7% de autorizaciones de tarjetas exitosas en 30 días (error budget 0. 3%).

4) Arquitectura de recogida y procesamiento

1. Ingesto: agentes (OTel Collector/Fluent Bit), SDK en la aplicación, RUM/sintética.
2. Enrutamiento: corredor/bus de telemetría (OTLP/HTTP/GRPC), filtros y enmascaramiento PII.

• Métricas: TSDB (agregaciones, downsampling).
• Registros: hot (indexado )/warm (menos indexado )/cold (almacenamiento de objetos, WORM).
• Tracks: almacenamiento en tiempo indexado con retenciones y tail-sampling.
• 4. Análisis/alertas: reglas (PromQL/LogQL/SQL), correlación con treisamia y lanzamientos.
• 5. Dashboards: técnicas + tipos de negocio (pagos, RNG/proveedores, motor de torneos).

5) Estándar de registro (JSON) y taxonomía de eventos

Se recomienda una lógica JSON estricta, claves y niveles únicos.

Уровни: `DEBUG < INFO < NOTICE < WARN < ERROR < FATAL < AUDIT`

Таксономия: `auth.`, `payment.`, `gameplay.`, `risk.`, `psp.`, `kyc.`, `rg.` (responsible gaming), `ops.`.

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

• Enmascarar PAN/BIN (almacenar sólo los campos válidos por política), email/teléfono - hash/token.
• IP truncar a/24, GeoIP almacenar por separado.
• Prohibimos el texto libre en 'extra' para la entrada personalizada sin sanidad.

6) Correlación: trace_id, correlation_id, idempotency_key

En cada registro y métrica añadir 'trace _ id' (de OTel), 'span _ id', 'correlation _ id' (de extremo a extremo para el proceso empresarial), 'idempotency _ key' (para solicitudes de pago).
Pasar baggage (tenant/brand, market, opción A/B) para construir cortes.

7) Métricas: técnicas y empresariales

Técnico: RPS, p95 latency, error rate, saturation, GC, pool usage, Kafka consumer lag.
Negocios: CR registratsii→depozit, autorizaciones exitosas, cancelaciones de pagos, NGR/GGR, ARPPU, anomalías RTP, drop-off en el paso KYC, fracción de límites responsables.

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

8) Senderismo y OpenTelemetry

Instrumentamos gateway, orquestador de pago, núcleo de juego, notificaciones, KYC/AML, integraciones con proveedores.
Head-sampling para flujo total + tail-sampling (elevado) para errores/latent spans y pagos.
Propagación de contexto: 'traceparent '/' tracestate', Kafka headers, gRPC metadata.
Anotamos los eventos de dominio: 'BetPlaced', 'WithdrawalRequested'.

9) Alerting sin ruido

Umbrales de varias etapas (warning/critical), supresión de flapping, deduplicación, ranuras de tiempo.
Correlación: asociamos «crecimiento 5xx» + «Kafka lag» + «p95 latency PSP» → un incidente.
alertas SLO-based: desperdiciar error-budget - escalar.
Alertas-as-Code (GitOps), rugidos y pruebas de reglas.

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) Búsqueda por logotipos (ejemplo de LogQL)

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

El objetivo es eliminar rápidamente el ruido y resaltar las «caras» negativas en la región objetivo.

11) Dashboards: lo que es obligatorio

Payments Health: éxito/fallos por PSP, latencia por método, mapa de regiones, proveedores de SLA.
Game Core: RPS por proveedor, p95 spin, error ratio SDK, RTP anomalías por ranura.
Player Journey: registratsiya→KUS→depozit→igra→vyvod (embudo de conversión, tiempo entre pasos).
Infra: Kafka lag, DB connections, cache hit ratio, clúster Kubernetes (red de pods/nodos).

12) Almacenamiento, retenciones y costo (FinOps)

Cardinalidad bajo control: evitar las métricas con etiquetas altamente cambiables (user_id).
Retenciones: métricas hot 30-90 días., downsampling a 13 meses.; registros hot 7-14 días., warm 30-90 días., cold 1-3 años (teniendo en cuenta la regulación).
WORM/immutability para registros de auditoría, Object Lock.
Compresión/partición y políticas ILM; índices separados para audit/PII-safe.
Sampling de registros en INFO/DEBUG; ERROR/AUDIT - completo.

13) Seguridad y cumplimiento

PII/PCI: tokenización, hashing, enmascaramiento; minimizar los datos.
RBAC/ABAC: acceso a logs/tries - por roles, separación de toldos.
Secretos y claves: no lógica credentials/tokens; detectores de secretos en CI.
Audit Trail: entradas de administración, cambios en los límites/pagos, ajustes manuales de balance - sólo en el índice AUDIT, invariablemente.
Legal-hold: mecanismo para congelar las retenciones en las investigaciones.

14) Calidad de los datos de telemetría

Registro de Schema para registros/eventos (versionamiento, compatibilidad).
Nomenclatura de campo único (snake_case, unidades).
Validación en el higo (drop de eventos sucios, métricas sobre el matrimonio).
Backpressure y protección contra «tormentas de registros».

15) Procesos SRE, Oncoll y Runbucks

Matriz de cáncer y escalamiento; Quiet Hours y rotaciones.
Los runbooks están enlazados a alertas (pasos de diagnóstico, recetas SQL/LogQL, fichflags para la degradación).
Postmortem sin castigos, action items con propietarios y deadline.
Indicadores del equipo: MTTD/MTTR, porcentaje de alertas ruidosas, cobertura con runbooks.

16) RUM y sintético

RUM: WebVitals (LCP, CLS, INP), errores de frente, impresiones de dispositivos, regiones/proveedores.
Sintética: escenarios «registratsiya→depozit→spin→vyvod» de diferentes regiones; ubicaciones privadas para rutas internas (administración/back office).

17) Prácticas de lanzamientos, experimentos y fichflags

Linkoem tracks con versiones de lanzamientos (commit/artefact).
Etiquetas A/B en baggage → dashboard «impacto del experimento en SLI».
Canary/Blue-Green: paneles separados para Canarias, error-budget burn rate.

18) Detección de anomalías y señales antifraude

Desencadenantes estadísticos (seasonality-aware) en la lista/chargeback-risk/estallido de nuevos mapas.
Correlaciones: «crecimiento de depósitos fallidos + nueva versión del adaptador PSP».
Reglas de streaming (Kafka → Flink) para reacciones near-real-time.

19) Hoja de ruta para la aplicación (por etapas)

Etapa 0 - Base: Logs JSON, campos de corea única, métricas básicas de servicios, dashboards compartidos, primeras alertas.
Etapa 1 - Treasing: OTel-instrumentación, head + tail sampling, enlace a logs.
Fase 2 - SLI/SLO de negocios: pagos/conclusiones/métricas de juego, alertas de SLO, procesos de error-budget.
Fase 3 - Madurez: Alertas-as-Code, ILM, retenciones separadas, anomalía-detect, servicio de runbooks, prácticas SRE en CI/CD.

20) Lista de verificación para rugir

• Logs sólo JSON, llaves únicas, camuflaje PII.
• En cada evento: 'trace _ id', 'span _ id', 'correlation _ id', 'tenant'.
• Las métricas cubren las señales de oro y los flujos de negocios.
• Los SLOs se describen, hay error-budget y alertas en la tasa burn.
• Tail-sampling está habilitado para errores de pago y altas latencias.
• ILM/retenciones y WORM están configurados para los registros de auditoría.
• RBAC en telemetría, auditoría de acceso.
• Dashboards por Payments/Game Core/Player Journey/Infra.
• Los runbooks están atados a cada alerta crítica.
• Los posmortems y los items de acción están en un backlog con los propietarios.

Aplicación A: atributos de OpenTelemetry (recomendación)

`service. name`, `service. version`, `deployment. environment`

`cloud. region`, `k8s. pod. name`, `k8s. container. name`

`tenant`, `brand`, `market`, `ab_test`, `user_segment`

`payment. method`, `psp`, `game. provider`, `game. id`

Anexo B: ejemplos de métricas para SLO

`payment_success_ratio`, `withdrawal_ttw_p95` (time-to-wallet), `psp_latency_p99`

`game_spin_latency_p95`, `provider_error_rate`, `kafka_consumer_lag`

`auth_success_ratio`, `kyc_step_dropout`, `cache_hit_ratio`

Anexo C: recetas rápidas de investigación

«Crece 'payment _ error _ rate'» → comparar por PSP/región/método, comprobar las rutas de tail, ver la versión del adaptador.
«p99 giros ↑» → de seguimiento de front→geytvey→provayder, comprobar proveedores/canales, límites de thread pools, retraídas de red.
«Kafka lag ↑» → la salud de los consumidores, productores retraídos, backpressure, sinks lentos/DB.