Distributed Tracing

(Sección: Tecnologías e Infraestructura)

Resumen breve

Los rastros distribuidos dan una respuesta a la pregunta de dónde y por qué se pierde tiempo en el camino de la consulta a través de gateway, API, cola, DB, proveedores externos (PSP/gaming studios). OpenTelemetry (OTel) es un estándar abierto de SDK/agentes/protocolo que combina tracks, métricas y registros. En iGaming es una herramienta básica para mantener p95/p99, localizar rápidamente los problemas de pago e identificar «cuellos de botella» antes de los torneos de pico.

1) Conceptos OTel

Trace - el camino completo de la operación (depósito, apuesta, retiro).
Span - sección de trabajo (handler HTTP, solicitud SQL, llamada de cola/proveedor).
Attributes - clave-valor con piezas ('net. peer. name`, `db. system`, `psp. route`).
Eventos - eventos instantáneos (retroceso, tiempo de espera, error de caché).
Enlaces - comunicación con otras pistas (importante para async/queue).
Resource - metadatos de proceso: 'service. name`, `service. version`, `deployment. environment`, `cloud. region`.

2) Propagación de contexto

traceparent: 00-<trace_id>-<span_id>-01 tracestate:...

Opcional - baggage para claves seguras (por ejemplo, 'tenant', 'route'), no ponga PII allí.

Dónde perforar el contexto: Puerta de enlace API → RPC interno → productor a la cola de → consumer → HTTP externo (PSP/proveedores).

3) Convenciones semánticas (mínimo obligatorio)

HTTP/RPC: `http. method`, `http. route`, `http. status_code`.
DB/caché: 'db. system` (`mysql`/`postgresql`/`redis`), `db. statement '(camuflado),' db. operation`.
Colas: 'messaging. system` (`kafka`/`rabbitmq`), `messaging. destination`, `messaging. operation` (`send`/`process`).
Pagos: 'psp. route`, `psp. provider`, `payment. id '(seudonimizar),' amount ',' currency '.
iGaming dominio: 'game. provider`, `game. session_id` (hash), `player. id_hash`.

Una taxonomía única → la comparabilidad de los dashboards y la búsqueda rápida de causas.

4) Sampling: cómo no ahogarse en los datos

Head-based (en la entrada de la solicitud)

Simple, barato; adecuado para el flujo total.
Menos - puede perder «interesantes» pistas lentas/erróneas.

Tail-based (в Collector)

La decisión se toma una vez finalizados los spans: solo mantenemos los errores/segmentos lentos/importantes (pagos VIP/).
Ideal para la carga prod: reduce enormemente el coste con una alta informatividad.

• Cabeza: 5-10% para cobertura «de fondo».
• Tail: 100% de errores + p95 + lenta + vías de pago/lanzamientos canarios.

5) Topologías OpenTelemetry Collector

Agent-saidkar (en cada nodo/pode): aceptación local, búfer mínimo, exportación al agregador.
Gateway (cluster): tail-sampling, enrutamiento, enriquecimiento, exportación a Tempo/Jaeger/Zipkin/OTLP.

Ejemplo: tail-sampling (fragmento YAML)

yaml processors:
tailsampling:
decision_wait: 5s policies:
- name: errors type: status_code status_code:
status_codes: [ ERROR ]
- name: slow_p95 type: latency latency:
threshold_ms: 250
- name: payments type: string_attribute string_attribute:
key: service. name values: [ "payments-api", "payments-worker" ]

6) Correlación con métricas y logotipos

En cada entrada de registro, agregue 'trace _ id '/' span _ id'.
Almacene las métricas de latencia como histogramas e incluya exemplares - una referencia a un 'trace _ id' representativo para «saltar» de una boqueta p95 a una huella específica.
Anotaciones de lanzamiento (Git SHA, versión chart) - como eventos/etiquetas.

7) Instrumentalización (idiomas y agentes automáticos)

Go (manual + auto)

go tp:= sdktrace. NewTracerProvider(
sdktrace. WithBatcher(exporter),
sdktrace. WithResource(resource. NewWithAttributes(
semconv. SchemaURL,
semconv. ServiceName("payments-api"),
)),
)
otel. SetTracerProvider(tp)

ctx, span:= tracer. Start(ctx, "Deposit")
defer span. End()
span. SetAttributes(
attribute. String("psp. route","pspX"),
attribute. String("currency","EUR"),
)

Java

Auto-agente '-javaagent: opentelemetry-javaagent. jar ', confit vía env (' OTEL _ SERVICE _ NAME ',' OTEL _ EXPORTER _ OTLP _ ENDPOINT ').
Manualmente - anotaciones/herramienta de ubicación de arco (grupos JDBC, caché).

Node. js / Python

Herramienta automática con complementos SDK + (Express/FastAPI/celery).
Para las colas, los envoltorios del productor/consumidor para poner 'messaging.' y links.

8) Colas y async: durmiendo correctamente

Productor ('nat'): span para enviar a un topic/cola.
Consumer ('process'): nuevo span de procesamiento de mensajes de link a span productor (mantener la causalidad sin' trace _ id 'común).
Atributos: 'messaging. kafka. partition`, `messaging. rabbitmq. routing_key`, `messaging. message_id`.
En retrocesos, el evento es 'retry', el contador de intentos.

9) BD/caché y N + 1

Habilita el trading de controladores de BD, agrupa las solicitudes del mismo tipo en batches.
Para Redis/caché, los atributos son 'cache. hit`/`cache. miss`.
Lleve las solicitudes «pesadas» a los dormitorios individuales - ver dónde p99.

10) Proveedores externos: PSP/estudios de juegos

Envuelva los clientes HTTP: 'psp. provider`, `psp. route`, `timeout_ms`, `attempt`.
Lógica códigos/tipos de errores, pero no PII (número de tarjeta, tokens).
Compara estudios/rutas a través de 'duration', 'error-rate'.

11) Frontend y RUM

OTel Web SDK: `page_view`, `resource_load`, `xhr`.
Pincha 'traceparent' en el backend para acoplar el camino del usuario a través de UI → API → DB.
Segmentación por geo/proveedores de red: etiquetas opcionales.

12) Seguridad y PII

Enmascarar campos ('db. statement 'con edición), hash' player _ id '.
Las zonas de datos son: 'pii = true', 'region = EU/TR/LATAM'.
Control de acceso a las pistas de pago (función basada).
WORM/Retention: tiempos de retención para huellas sensibles, eliminación por política.

13) Rendimiento y costo

Tail-sampling sobre políticas: «errores + lentos + pagos + lanzamientos canarios».
Downsampling histogramas métricos, deduplicación agresiva de registros.
Limitación de cardinalidad: no encajar 'user _ id' como etiqueta métrica.
Búferes/batches en Collector, compresión OTLP.

14) Dashboards y análisis

Mapa de servicio: dependencias de servicios, coloración por error/latencia.
Release compare: revisión estable vs canario (p95, error-rate, payments amb).
Top slow traces: a lo largo de la ruta '/depósito ', corte por PSP/región.
Registro de Queue: pistas con profundo retraso en el consumo.

15) Ejemplos de configuraciones de Collector

Pipelines (métricas/tracks/logs, fragmento)

yaml receivers:
otlp: { protocols: { http: {}, grpc: {} } }

processors:
batch:
memory_limiter:
limit_mib: 1024 spike_limit_mib: 256 attributes/payments:
actions:
- key: "psp. provider"
action: insert value: "pspX"

exporters:
otlp/traces: { endpoint: tempo:4317, tls: { insecure: true } }
otlp/metrics:{ endpoint: prometheus-otlp:4317, tls: { insecure: true } }
otlp/logs:  { endpoint: loki-otlp:4317, tls: { insecure: true } }

service:
pipelines:
traces:
receivers: [ otlp ]
processors: [ memory_limiter, batch, tailsampling ]
exporters: [ otlp/traces ]
metrics:
receivers: [ otlp ]
processors: [ batch ]
exporters: [ otlp/metrics ]
logs:
receivers: [ otlp ]
processors: [ batch ]
exporters: [ otlp/logs ]

16) Runbooks (scripts tipo)

A) Crecimiento p99 en 'payments-api'

1. Abrir «Top slow traces» → fallar en los durmientes DB/PSP.
2. Si el problema PSP es traducir la ruta, habilite retraídas/temporizadores.
3. Comprobar la cola 'withdrawals' (lag), aumentar los consumers.

B) Errores 5xx después de la versión

1. Filtro por 'servicio. version`.
2. Comparar estable/canario; encontrar spikes en 'psp. route`.
3. Congelar la promoción, retroceder (ver «Estrategias de lanzamiento «/» Rolbacks »).

C) Sospecha de N + 1

1. Tracks con un gran número de espanas cortas de DB.
2. Habilitar agregación/joynes, agregar una capa de caché.

17) Lista de verificación de implementación

1. Habilite OTel SDK y los atributos de recursos unificados ('service. name`, `env`, `region`).
2. Propagar W3C Trace Context a través de todas las capas y colas.
3. Conjunto mínimo de atributos semánticos (HTTP/DB/queue/PSP).
4. Tail-sampling: errores, p95 +, pagos, canario.
5. Logs con 'trace _ id '/' span _ id', métricas con exemplares.
6. Dashboards: service map, release compare, payments flow.
7. Políticas PII: enmascaramiento, zonas, roles, retiro.
8. Pruebas/carga: comprobación de la correlación y la completeness del senderismo antes de los picos.
9. Autogeneración de enlaces runbook en alertas.
10. Informe sobre el coste de la telemetría y la cardinalidad.

18) Antipattern

Trazados «sólo en la entrada» sin BD/colas → no hay uso.
La falta de propagación en async → «rasga» las cadenas de causalidad.
Sampling aleatorio 1% sin tail-lógica → no atrapar lenta/errónea.
Los registros sin 'trace _ id' → no tienen correlación de extremo a extremo.
PII crudos en atributos/logs → riesgos de cumplimiento.
La cardinalidad «en el techo» (user/session como etiquetas métricas) → una explosión de valor.

Resultados

OpenTelemetry transforma la observabilidad de un conjunto de herramientas dispersas en un lenguaje de rendimiento de extremo a extremo. Con la propagación correcta del contexto, la semántica ordenada, el tail-sampling y el conjunto de «métricas ↔ rutas ↔ registros», el equipo de iGaming mantiene el p95/p99 bajo control, aísla rápidamente los cuellos de botella (DB, colas, PSP) y libera lanzamientos con confianza incluso en picos de tráfico.