Es lunes por la mañana. Abres el correo y ahí está: la factura de tu plataforma de observabilidad ha subido un 40% este mes. Te conectas al panel de costes y descubres que las trazas distribuidas se están comiendo el presupuesto. Tu aplicación genera millones de trazas al día, la mayoría de peticiones rutinarias que funcionan perfectamente, pero todas están siendo capturadas, procesadas, almacenadas y facturadas. Mientras tanto, cuando algo falla de verdad, encontrar la traza relevante entre ese océano de datos es como buscar una aguja en un pajar del tamaño de un estadio de fútbol.
Bienvenido al dilema central del tracing distribuido: capturar todo es carísimo e inmanejable, pero capturar poco puede dejarte ciego justo cuando más necesitas ver. El sampling de trazas es la respuesta a este problema, pero no es una solución mágica que se configura una vez y se olvida. Es una estrategia que requiere entender qué estás intentando conseguir, qué puedes permitirte perder y cómo equilibrar visibilidad con realismo económico.
Por qué no puedes capturar todas las trazas (aunque quisieras)
Imagina una aplicación medianamente popular que procesa mil peticiones por segundo. Eso son 86 millones de peticiones al día. Si cada traza ocupa unos pocos kilobytes entre todos sus spans, estás generando cientos de gigabytes de datos de tracing diarios. Ahora multiplica eso por el coste de transmisión, procesamiento, almacenamiento y consulta. Los números escalan rápido.
Pero el problema no es solo económico. Capturar todo genera ruido operativo. Cuando intentas depurar un problema, te encuentras filtrando millones de trazas normales para encontrar las pocas que muestran el comportamiento anómalo. Las consultas se vuelven lentas. Los dashboards tardan en cargar. Y lo peor: empiezas a perder confianza en tus herramientas porque encontrar información útil se convierte en un ejercicio de paciencia.
El sampling no es una limitación técnica que ojalá desapareciera con mejor hardware. Es una decisión consciente de qué datos merecen tu atención y tu presupuesto. La pregunta no es si hacer sampling, sino cómo hacerlo sin quedarte ciego.
Las dos grandes familias: head-based y tail-based
Existen dos enfoques fundamentales para decidir qué trazas conservar, y la diferencia entre ellos no es solo técnica: cambia completamente lo que puedes y no puedes hacer.
El head-based sampling toma la decisión al principio de la traza, cuando llega la primera petición. Es como decidir en la puerta de un concierto a quién dejas entrar sin saber todavía qué va a pasar dentro. Defines una tasa de muestreo —digamos, el 10%— y cada traza tiene esa probabilidad de ser capturada completa. Es simple, predecible y barato de implementar porque la decisión se toma una vez y se propaga a todos los servicios involucrados.
El problema es obvio: si una petición falla pero cae en el 90% que descartaste, no tienes traza. Justo cuando más la necesitas, no está. Es frustrante depurar un error del que no tienes evidencia porque el azar decidió no capturarlo.
El tail-based sampling es más sofisticado: espera a que la traza complete antes de decidir si la conserva. Puede aplicar reglas inteligentes: conservar todas las trazas con errores, las que superan cierto umbral de latencia, las que tocan servicios críticos, o una muestra representativa del resto. Es como revisar la grabación del concierto después y decidir qué momentos merecen guardarse.
Suena perfecto, pero tiene compensaciones serias. Necesitas infraestructura que retenga temporalmente todas las trazas hasta decidir su destino, con los buffers, memoria y procesamiento adicional que eso implica. Y hay una restricción arquitectónica que sorprende a mucha gente cuando la descubre en producción: todos los spans de una misma traza deben llegar a la misma instancia del collector para que la decisión de sampling sea coherente. En un despliegue horizontal con varias instancias del Collector de OpenTelemetry, eso obliga a usar un load balancer con sticky routing por trace ID antes del collector de tail sampling, lo que añade una capa más al stack. En entornos muy distribuidos, no es complejidad accidental: es un requisito de diseño que conviene planificar desde el principio.
Cuándo usar cada enfoque
El head-based sampling tiene sentido cuando tu presupuesto es ajustado, tu infraestructura es simple, y puedes vivir con la incertidumbre de perder trazas de errores ocasionales. Funciona bien en entornos donde los problemas son recurrentes: si un error aparece mil veces, aunque solo captures el 10%, tendrás cien ejemplos para analizar.
El tail-based sampling brilla cuando necesitas garantías: capturar todos los errores, todas las latencias anómalas, todas las interacciones con sistemas externos críticos. Es la opción si tu SLO es estricto y no puedes permitirte perder visibilidad de ningún fallo. Pero requiere inversión en infraestructura, sticky routing, y aceptar mayor complejidad operativa.
Muchas organizaciones acaban usando híbridos: head-based sampling agresivo para el tráfico normal, con excepciones configuradas para capturar siempre ciertos patrones críticos. No es elegante, pero es pragmático.
Estrategias de sampling que realmente funcionan
Más allá de la mecánica técnica, lo que importa es la estrategia. ¿Qué trazas necesitas conservar para mantener visibilidad operativa sin arruinarte?
Prioriza los errores siempre. Parece obvio, pero es sorprendente cuántos sistemas aplican sampling ciego que descarta trazas fallidas. Si implementas tail-based sampling, la primera regla debe ser conservar cualquier traza con códigos de error HTTP 5xx, excepciones no capturadas, o timeouts. Los errores son raros por definición —si no lo son, tienes problemas mayores— así que capturarlos todos no dispara los costes.
Captura las colas de latencia. Una traza que tarda 50 milisegundos es rutinaria. Una que tarda 5 segundos cuenta una historia: un servicio lento, una base de datos saturada, una red congestionada. Configurar umbrales de latencia por servicio y capturar todo lo que los supera te da visibilidad de degradaciones antes de que se conviertan en incidentes.
Muestrea proporcionalmente al volumen. Si un endpoint recibe mil peticiones por segundo y otro recibe diez, aplicar la misma tasa del 1% significa capturar diez trazas del primero y prácticamente ninguna del segundo. Algunos sistemas permiten sampling adaptativo que ajusta las tasas según el volumen, manteniendo representatividad estadística sin sesgar hacia los endpoints más populares. Jaeger, por ejemplo, implementa un mecanismo de adaptive sampling en el que el backend calcula dinámicamente las probabilidades de muestreo observando el tráfico real por servicio y endpoint, y las publica como estrategias que los SDKs consultan y aplican — el sampling en sí lo ejecutan los SDKs, no el backend directamente.
Conserva diversidad, no solo volumen. Capturar mil trazas idénticas de la misma operación exitosa no aporta más información que capturar diez. Lo valioso es la diversidad: diferentes rutas de código, diferentes combinaciones de servicios, diferentes condiciones de carga. Algunas plataformas propietarias aplican su propia lógica de selección para priorizar trazas que muestran comportamiento anómalo o rutas de código poco frecuentes, aunque estos mecanismos no son equivalentes al modelo de sampling configurable del ecosistema OpenTelemetry.
Los errores que te costarán dinero o visibilidad
El primer error es configurar sampling y olvidarse. Tu aplicación evoluciona, añades servicios, cambian los patrones de tráfico, y esa tasa del 5% que era razonable hace seis meses ahora es insuficiente para ciertos flujos o excesiva para otros. El sampling necesita revisión periódica, especialmente después de cambios arquitectónicos importantes.
El segundo error es no etiquetar las trazas adecuadamente antes de aplicar sampling. Si tus trazas no incluyen metadatos sobre el tipo de operación, el tenant, el entorno o el nivel de criticidad, no puedes tomar decisiones inteligentes de sampling. Acabas aplicando reglas genéricas que tratan igual una operación crítica de pago que una consulta de caché.
El tercer error es asumir que el sampling es binario: o capturas una traza completa o no capturas nada. Algunos sistemas permiten sampling jerárquico: capturar todos los spans de nivel superior pero solo una muestra de los spans internos. Conservas la visibilidad de flujo entre servicios sin pagar por cada llamada interna a base de datos.
Y el error más sutil: optimizar solo para coste. Es tentador subir el sampling al 0,1% y celebrar la factura reducida, hasta que llega un incidente y descubres que no tienes datos para depurarlo. El sampling es una compensación entre coste y capacidad de respuesta. La pregunta correcta no es «¿cuánto puedo ahorrar?» sino «¿cuánta ceguera puedo permitirme?»
Cómo saber si tu estrategia funciona
Una buena estrategia de sampling es invisible cuando todo va bien y salvadora cuando algo falla. Pero ¿cómo evalúas si la tuya funciona?
Primero, mide la cobertura de errores. Durante el último mes, ¿cuántos errores reportados por tus usuarios no tenían traza correspondiente? Si la respuesta es más del 5%, tu sampling es demasiado agresivo o mal configurado. Los errores deben tener cobertura casi total.
Segundo, revisa los incidentes pasados. Cuando investigaste el último problema de producción, ¿tenías trazas suficientes para entender qué pasó? ¿Tuviste que recurrir a logs porque las trazas no estaban? Si la respuesta es frecuente, necesitas ajustar.
Tercero, observa la distribución de tus trazas capturadas. Si el 90% corresponde al mismo endpoint exitoso repetido millones de veces, estás desperdiciando presupuesto en redundancia. Necesitas sampling más inteligente que capture diversidad.
Y finalmente, compara coste con valor. Si tu factura de tracing es el 30% de tu presupuesto de observabilidad pero solo consultas esas trazas una vez al mes, algo no cuadra. El tracing debe ganarse su coste siendo consultado regularmente, no ser un seguro carísimo que nunca usas.
El equilibrio que cada equipo debe encontrar
No existe una configuración de sampling universal que funcione para todos. Un sistema de pagos con SLOs estrictos necesita capturar casi todo lo relevante, mientras que un blog personal puede permitirse sampling agresivo sin consecuencias. La clave es entender tu contexto: qué tan crítico es tu sistema, qué presupuesto tienes, qué tipo de problemas necesitas depurar.
El sampling bien hecho es transparente para el desarrollo pero consciente para la operación. Los desarrolladores instrumentan su código sin preocuparse de tasas de muestreo, mientras que el equipo de plataforma ajusta las reglas según necesidades operativas y restricciones económicas. Esa separación de responsabilidades es sana.
Y recuerda: el objetivo del sampling no es ahorrar dinero a costa de visibilidad, sino mantener visibilidad útil dentro de un presupuesto razonable. Si tu estrategia te deja ciego ante problemas reales, no es una estrategia, es una apuesta. Y en producción, las apuestas se pierden en el peor momento posible.
Para seguir aprendiendo
Documentación oficial de OpenTelemetry sobre sampling (https://opentelemetry.io/docs/concepts/sampling/) — Explica los diferentes procesadores de sampling disponibles en el Collector, cuándo usar cada uno, y la distinción entre head-based y tail-based con ejemplos de configuración.
Especificación técnica de probability sampling en OpenTelemetry (https://opentelemetry.io/docs/specs/otel/trace/tracestate-probability-sampling/) — El documento técnico que define cómo funciona el sampling consistente en el estándar, incluyendo propagación de decisiones entre servicios mediante W3C TraceState.
Distributed Tracing in Practice, de Austin Parker, Daniel Spoonhower, Jonathan Mace, Ben Sigelman y Rebecca Isaacs (O’Reilly, 2020) — Dedica un capítulo completo a estrategias de sampling con casos de uso reales de empresas que operan tracing a gran escala.
Documentación de Jaeger sobre sampling (https://www.jaegertracing.io/docs/latest/architecture/sampling/) — Describe tanto el sampling remoto estático como el adaptive sampling, con explicación de los algoritmos y backends de almacenamiento soportados.
Observability Engineering (segunda edición), de Charity Majors, Liz Fong-Jones y George Miranda (O’Reilly, 2024) — Incluye perspectivas prácticas sobre cómo equilibrar coste y visibilidad en sistemas de observabilidad modernos, con énfasis en tracing y eventos de alta cardinalidad.
