Observabilidad y telemetría

(Sección: Tecnologías e Infraestructura)

Resumen breve

La observabilidad es la capacidad de responder «¿por qué funciona así?» sin el lanzamiento de nuevos billetes. En iGaming, esto es crítico: torneos de pico, picos de pago, multirregionales y requisitos de juego responsable/PII. La base son métricas, registros, trazados combinados con identificadores y estándares comunes (OpenTelemetry), con contratos SLO, alerting resistente al ruido y control de valor.

1) Marco de observación: en qué consiste

Métricas (números en el tiempo): RED/USE, KPI de negocios, SLI. Almacenados en TSDB.
Registros (eventos en texto/JSON): auditoría, errores, hechos empresariales, seguridad.
Tracks (spans): ruta de consulta a través de servicios, latencias, causas de retrasos.
Profiling: CPU/memoria/eBPF-streams, heap/lock-contenshing.
RUM y sintética: usuarios reales (web/app) + verificaciones de robot.
Catálogo de telemetría: esquemas, políticas PII, plazos de retención, etiquetas de valor.

2) Taxonomía de las señales y principios

RED для API: Rate, Errors, Duration.
USE para infraestructura: Utilización, Saturación, Errores (CPU, discos, red, colas).
SLI/SLO: indicadores medibles (por ejemplo, solicitudes exitosas/todas, p95 latencia), objetivos de accesibilidad (por ejemplo, "99. 9% en 30 días"), presupuesto de errores → disparadores de procesos.
Alta cardinalidad con inteligencia: las etiquetas deben ser útiles en cortes (región/tenant/proveedor), pero no detonar TSDB.

3) Normas y correlación transversal

OpenTelemetry (OTel): protocolo/SDK único para métricas, registros y rastreos.
Identificadores: 'trace _ id', 'span _ id', 'correlation _ id', 'player _ id' (alias), 'payment _ route'.
ID de flujo: puerta de enlace de entrada → todos los microservicios → pagos/PSP → colas/jobs → registros/métricas/spanas.

Ejemplo: encabezados de correlación

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

4) Métricas: qué y cómo medimos

Nombres/etiquetas

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

Ejemplos de 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

Histogramas y exemplares

Almacena los histogramas de latencia (native-histograms/ β uckets) y enlaza exemplar con 'trace _ id' para saltar de un «lenta baqueta» a una pista específica.

5) Registros: estructurado y seguro

Sólo JSON (ningún «formulario libre» en venta).
Поля: `timestamp`, `severity`, `service`, `trace_id`, `correlation_id`, `player_id_hash`, `event`, `amount`, `currency`, `ip_hash`.
Enmascaramiento/hashing PII, índices separados/retention para el sensible.
Pipelines de registro: parcing → normalización → enriquecimiento (geo/ASN) → edición PII → indexación.

Ejemplo de evento 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) Seguimiento: donde se pierde tiempo

Spans: solicitud de entrada, llamadas de proveedores (PSP/proveedores de juegos), BD/caché, RPC interservicios.
Atributos: 'db. system`, `net. peer. name`, `messaging. system`, `psp. route`, `game. provider`.

• head-based (probabilístico) para el volumen,
• tail-based (según las condiciones: errores, p95 +, segmento VIP),
• guaranteed-keep para pagos/PII-crítico.

7) Observabilidad del frente y del móvil

RUM: TTFB, FCP/LCP/CLS/INP, errores de JS, redes y enrutamiento SPA.
Informes de choque: simbolización, desofuscación, versión de build, dispositivo/OS.
Sintética: scripts de entrada/depósito/apuesta; inspecciones georreferenciadas.

8) SLO, SLI y presupuesto de errores

Ejemplo de 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

Alerting sobre el presupuesto de errores, no sobre «cada métrica».
Tratamientos libres en la combustión del presupuesto: limitar las liberaciones/Canarias.

9) Alerting sin ruido

Multi-window, multi-burn reglas: ventana corta/larga.
Deduplicación/rutina: por servicio/región/criticidad en on-call.
Runbook URL y autocorrección de contexto (últimos deployes, cambios de configuración, grafo de dependencia).
Horas de silencio y supresión durante los trabajos programados.

Ejemplo de regla (idea 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) Profiling y eBPF

eBPF/perfiles: gráficos flame CPU/alloc, latencia I/O, drops de red, anomalías de Syscall.
Es útil en lugares estrechos p99, «jitter» y raras colisiones.

11) Observabilidad empresarial (product & risk)

Finanzas/monetización: conversión de depósitos, TTW (time-to-wallet), autorización ./settle, cancelaciones/charjbacks.
Actividad de juego: retoque/strick, cuota de apuestas en vivo, «pegajosidad» de los proveedores.
Antifraude/Abuse: velocidad de acción, coincidencias de dispositivos/IP, correlaciones.
Indicadores RG: largas sesiones, «dogon», crecimiento de filetes.
Las métricas empresariales se correlacionan con las técnicas y lanzamientos (eventos de anotación).

12) Seguridad, PII y cumplimiento

Data-zones: etiquetas de datasets/logs ('pii = true', 'región = EU').
Enmascaramiento antes de la indexación, seudonimización de identificadores.
Almacenamiento WORM para auditoría; Acceso de rol a la guarida.
Períodos de retención: diferentes para los técnicos/auditoría/negocio.
Prohibición de secretos crudos en las guaridas; pruebas de detección en CI.

13) Gestión de costes (FinOps)

Límite de cardinalidad: cuidado con 'user _ id', 'session _ id'.
Partido/retiro: caliente (7-14 días), caliente (30-90), frío (archivo).
Sampling tracks (tail-based) y downsampling métricas.
Facturación por etiquetas 'team', 'service', 'tenant': informes de 'quién quema la observabilidad'.

14) Kit de herramientas (pila de referencia)

Métricas: Prometheus/lake para métricas, dashboards de Grafana.
Registros: Loki/ELK; reglas de ingestión, reducción/parsing.
Tracks: Tempo/Jaeger/OTel-colectores; líneas exemplars de métricas.
Sintética: exportador de Blackbox, robots de navegador.
Alerta: Alertmanager/integración de chat, rotación on-call.
Profiling: eBPF/perfil continuo.

15) Ejemplos: implementar rápidamente el marco

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) Procesos y operaciones

Un único diccionario de métricas/etiquetas (naming-guide) y un patrón de dashboards.
Release-annotations con autómata en los gráficos.
Incidentes: tarjeta, timeline, RCA sin cargos, action items.
Alarmas de aprendizaje («game-day»): simulaciones de caídas, retrasos PSP, sobrecalentamiento de caché.
Runbooks: instrucciones paso a paso y enlaces de auto de alertas.

17) Lista de verificación de madurez

1. OTel SDK/colector → una sola exportación de métricas/registros/tracks.
2. RED/USE cubre todos los servicios + SLI/SLO por API clave.
3. Correlación 'trace _ id' ⇄ registros ⇄ métricas (exemplars, jump-links).
4. Alertas de presupuesto de errores con enlaces de multi-burn y runabook.
5. RUM + sintético en «depósito/apuesta/retiro».
6. Profiling (eBPF) en venta en la lista blanca.
7. Políticas PII: enmascaramiento, zonas, acceso, períodos de retención.
8. Informe financiero sobre el coste de la telemetría (etiquetas 'team/service').
9. «Preparación para la carga máxima»: plan de prueba, calentar cachés, patrones de alerta.
10. RCA regulares y revisión de SLO/umbrales.

18) Antipattern

Los logs son «sábanas» sin estructura y 'trace _ id'.
Alertas para cada métrica → alert fatIg.
Los histogramas sin baquetas correctas → p95 «planas».
La cardinalidad ilimitada de las etiquetas → una explosión de valor.
La ausencia de RUM/sintéticos es «todo está bien», y el usuario no lo está.
Mezcla de PII con techlogs, retención indefinida.
Aislamiento de la telemetría de los KPI empresariales - «la latencia está cayendo, los ingresos también».

los Totales

Una fuerte observancia es el lenguaje común entre el producto, los ERE, la seguridad y los pagos. Conectando métricas, registros, pistas bajo OTel, introduciendo SLO con el presupuesto de errores, haciendo el alerting inteligente y el costo manejable, se obtiene un sistema que antes nota problemas, se recupera más rápido y previsiblemente pasa picos de tráfico y cargas de torneos.