Observability и trace sampling

1) Por qué Observabilidad

• Métricas (agregados, reaccionan rápidamente);
• Registros (detalles y fuerza);
• Tracks (relaciones causales transversales);
• Perfiles (contenido CPU/heap/lock en modo prod).

Clave: correlación entre señales + economía de telemetría (sampleo, retenciones, compresión).

2) Mapa de señales y principios

2. 1 RED/USE

RED (para API): Rate (RPS), Errors (% 5xx/4xx importante), Duration (p50/p95/p99).
USE (para recursos): Utilización, Saturación, Errores (NIC, CPU, disco, colas).

2. 2 Invariantes del producto

Definir SLO (por ejemplo, "p95 latencia '/v1/pagos '≤ 300 ms, presupuesto erróneo 0. 5% en 30 días"). Las alertas solo deben «gritar» cuando violan el SLO o su combustión.

2. 3 Contexto

Implemente W3C Trace Context ('traceparent', 'tracestate') y baggage para transmitir de forma segura esos/atributos empresariales (por ejemplo, 'tenant', 'region', sin PII).

3) Arquitectura de la observabilidad

SDK/Auto-instrumentación: OpenTelemetry (OTel) en servicios (HTTP/gRPC/DB/clientes).
OTel Collector como neumático: recepción → enriquecimiento → sampleo → exportación (Prometheus, Tempo/Jaeger, Loki/ELK, ClickHouse).

• Métricas: Prometheus/Mimir/VictoriaMetrics;
• Tracks: Tempo/Jaeger/Zipkin;
• Registros: almacenamiento Loki/ELK/Vector→S3+deshevoye;
• Perfiles: Pyroscope/Parca.
• Correlación: gráficos de servicio, exemplares, transición del gráfico p99 a un trace específico.

4) Samplay Treasing: Estrategias

4. 1 sampling basado en cabeza (en la entrada, antes de conocer el resultado)

Implementación simple y barata (en SDK/ingress).
Contras: puede omitir errores raros/consultas lentas.

Cuándo: RPS altos, presupuestos estrictos, se requiere una proporción predecible (por ejemplo, 1-5%).

4. 2 Muestras de Tail-based (en la salida, conociendo el resultado)

La decisión se toma en el Coleccionista una vez finalizada la siesta.
Se puede garantizar la selección de anomalías: errores, p99, routs/tenantes específicos.
Contras: amortiguación, más difícil y más caro.

Cuándo: se necesitan tracks «significativos» a un costo moderado.

4. 3 Modelo combinado

Global head 1-5%, además de las reglas de tail: «guardar siempre los errores/slow-spans», «sampear el 50% del tráfico canario», «guardar todos los tracks de las rutas de pago en caso de incidente».

5) Sampling dinámico y presupuesto de telemetría

Budget-aware: mantener el volumen de ≤ N Tracks/min; cuando se supera - aumentar los umbrales (por ejemplo, seleccionar sólo p99. 5+, error-only).
Rules by route/tenant: endpoints/tenants importantes - con una mayor proporción.
Ventanas adaptativas: las ráfagas → aumentar temporalmente la proporción de errores/lentos.
Reducción de la cardinalidad: normalizar user-agent, IP/ASN, squash stack traces, enmascarar secretos.

6) Confecciones (referencias)

6. 1 OpenTelemetry Collector - tail-sampling (fragmento yaml)

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

processors:
batch: { send_batch_size: 8192, timeout: 2s }
tail_sampling:
decision_wait: 5s num_traces: 100000 expected_new_traces_per_sec: 5000 policies:
- name: always-error type: status_code status_code: { status_codes: [ERROR] }
- name: slow-endpoints type: latency latency: { threshold_ms: 300 }      # p95 цель
- name: important-routes type: string_attribute string_attribute: { key: http. target, values: ["/v1/payments", "/v1/payouts"] }
- name: tenant-eu1 type: string_attribute string_attribute: { key: tenant, values: ["eu-1"] }
- name: probabilistic-default type: probabilistic probabilistic: { sampling_percentage: 5. 0 }

exporters:
otlphttp/tempo: { endpoint: http://tempo:4318 }
prometheus: { endpoint: "0. 0. 0. 0:9464" }

service:
pipelines:
traces:
receivers: [otlp]
processors: [batch, tail_sampling]
exporters: [otlphttp/tempo]

6. 2 Prometheus - exemplars (fragmento)

En la aplicación, cuando escriba histogramas, agregue exemplars con 'trace _ id'. En Grafana, los clics de «agujas» llevan a la pista.

yaml scrape_configs:
- job_name: api scrape_interval: 10s honor_labels: true static_configs: [{ targets: ["api:9100"] }]
exemplar_limit: 10

6. 3 Loki - Reducir el costo de los registros

Las etiquetas sólo son estables ('service', 'env', 'region', 'route _ class').
La alta cardinalidad (request_id, user_id) está en el payload, pero con la redacción.
Muestree los registros de información «exitosos», guarde todos los errores/advertencias.

6. 4 Jaeger/Tempo - Retoque y Índice

Almacene los tracks crudos durante 3-7 días, agregados/simetrías - más tiempo.
Incluya parquet/blocks en almacenamiento barato (compatible con S3), los índices son compactos.

7) Simulación de senderismo

7. 1 Nombres y atributos

`service. name`, `service. version`, `deployment. environment`.
`http. method`, `http. route`, `http. target`, `http. status_code`, `net. peer. name`.
Atributos de negocio sin PII: 'tenant', 'region', 'payment _ provider', 'game _ id'.

7. 2 Eventos y comunicaciones

Span events: puntos importantes (inicio de transacciones DB, retray, circuito abierto, cache miss).
Enlaces: comunicación zapros→vebkhuk/sobytiye; útil para EDA y outbox/inbox.

7. 3 Instancias (exemplares)

Añada ejemplos a los histogramas latency/size con 'trace _ id': navegar «desde la métrica de → a la trais» con un solo clic.

8) Métricas: cuáles y cómo

8. 1 Técnico

RED en rutas/tenantes/proveedores (PSP, KYC).
Пулы: `db_connections_in_use`, `http_client_in_flight`, `queue_depth`.
Estabilización: retries, timeouts, circuit open/half-open, rate-limit hits.
Go/Java/Python runtime: GC pausa, heap, safepoints, GIL latencia.

8. 2 Métricas de negocio

Registros/logins/depósitos/retiros, conversiones, fallas de 3DS/KYC, chargeback-ratio.
Fichas importantes: time-to-wallet, success-rate payout.

8. 3 Cardinalidad y almacenamiento

Histogramas con buckets explícitos (por ejemplo, '[50,100,200,300,500,1000,2000] ms').
Evite las etiquetas de alta cardinalidad (raw user_id, request_id) - llevar en los registros/tracks.

9) Registros: estándares y correlación

Formato: JSON + claves necesarias ('timestamp', 'level', 'message', 'trace _ id', 'span _ id', 'service', 'env').
Edición: enmascarar PAN, tokens, PII.
Sampling: 100% para 'error/warn', 5-20% para' info 'en rutas' ruidosas '.
La referencia a las pistas es a través de 'trace _ id'. Las líneas de registro → «pivote» en la pista y viceversa.

10) Profiling en venta

Habilite el perfil continuo (Pyroscope/Parca) para CPU/heap/alloc/locks.
Correlacionar los picos p99 con las pilas calientes; almacene 7-14 días.

11) Alerting por SLO/presupuesto erróneo

SLO-alertas: «el presupuesto erróneo se gasta más rápido que X %/hora» (alertas predictivas).
Los síntomas no son las causas: alerte al nivel del cliente (RUM/edge o per root), no a la CPU.
Multi-window, multi-burn rate: 2% por 1 h y 5% por 6 h - dos condiciones.
Silencio en las degradaciones planificadas: cambio de umbrales en las banderas de fichas/canario.

12) Costo y retiro

Cuotas de volumen: tracks ≤ N TB/mes, logs - caliente 3-7 días, frío S3 30-90 días, métricas - downsampling (1 min → 5 min → 1 h).
Las reglas de tail reducen el volumen × 10- × 100, manteniendo el error/lento.
Las señales con el menor costo son las métricas; con el mayor valor son los tracks y perfiles «correctos».

13) Antipatternas

«100% tracks siempre» → explosión de valor, ruido y frenos.
Registros en formato libre sin teclas/enmascaramiento.
Métricas con etiquetas infinitas (user_id/ip/full UA).
No hay 'traceparent '/' baggage' - Corelación no es posible.
Alertas en CPU/heap en lugar de SLO - chat «quema» sin uso.
Sampling «rand 1%» sin prioridad de error/slow - pierde casos valiosos.

14) Ejemplos de dashboards (esqueletos)

API Overview: RPS, error-rate por clase, latency p95/p99 (exemplars clickable), top routs.
Release/Canary: comparación de métricas de la versión antigua/nueva, outlier-rate, open-circuits, retries.
PSP/KYC: tasa de éxito por proveedor, latencia y fallo, correlación con errores de payout.
Infra: USE por recursos, saturación de colas, drops de red.

15) Especificidad de iGaming/finanzas

Rutas críticas (depósitos/retiros): 100% de trayecto solo en incidentes o ventanas limitadas; en el modo normal - tail «todo con error/latencia larga».
Región/tenant: añadir 'tenant', 'jurisdiction', 'brand' en baggage; construye SLO por jurisdicción.
Filtro antifraude/bot: métricas y tracks de soluciones Risk API (allow/deny/challenge), challenge-pass-rate, velocity-hits.
Auditoría/cumplimiento: almacenar lo mínimo necesario, sin PII; registros inmutables - en un circuito separado.

16) Lista de comprobación prod

• Propagación de extremo a extremo ('traceparent', 'baggage'), correlación de registros/métricas/tracks.
• OTel Collector con tail-sampling (errors/slow/routs importantes) + probabilistic default.
• Métricas RED/USE, buckets explícitos, exemplares → transición a la vía.
• SLO y alerting por presupuesto erróneo (dos escalas de tiempo).
• Reglamentos de Retención y Presupuesto de Telemetría; downsampling métricas; cold storage para registros.
• Registro JSON estandarizado, redacción PII/secretos.
• Profiling en la venta incluido; los dashboards de los stacks «calientes» para el incidente.
• Dashboards canarios y comparación de versiones; liberación sin «zonas ciegas».
• Runbook: cómo elevar temporalmente la proporción de sampling en un incidente.
• Documentación de Neyming de atributos/etiquetas y prohibición de alta cardinalidad.

17) TL; DR

Construya la observabilidad alrededor de la correlación: métricas de RED/USE → exemplares → tracks → logs/perfiles. Gestione el coste a través de la empulación combinada: pequeñas reglas head% + tail (errores, rutas lentas, importantes/tenantes). Alertas - por SLO y presupuesto de errores. Mantenga las retenciones y la cardinalidad bajo control, use OTel Collector como «sistema nervioso central». Para las vías de pago/jurisdicciones - telemetría prioritaria y estricta higiene de datos.