El sampling agresivo es un parche, no una solución. Si tu batch es un ETL con pandas/polars, el problema no es el volumen de trazas, es que estás emitiendo una traza por fila. Eso es un antipatrón de instrumentación. OpenTelemetry tiene SpanProcessor con BatchSpanProcessor y ParentBased sampler, pero si no ajustas el max_queue_size y el schedule_delay_millis, el colector se convierte en un cuello de botella y acabas perdiendo trazas o pagando por lotes vacíos. En AWS, ADOT + AMP te cobra por métrica ingerida y por muestra almacenada, no por traza. Si mides duración y throughput con métricas, el coste es lineal con el número de etapas, no con el número de filas. El error es usar trazas para lo que son métricas.
Sobre el TCO del TB/día: S3 Glacier Deep Archive a 0,00099 $/GB/mes es imbatible, pero el coste de recuperación (hasta 0,02 $/GB y 48 h de espera) lo hace inútil para debugging activo. Ceph on-prem con réplica 3x y discos NVMe de consumo te sale a ~0,03 $/GB/mes solo en hardware, sin contar el tiempo de reemplazo ni el desgaste. Pero si tu retención activa es de 7 días y el resto va a cinta LTO-9 (0,005 $/GB/mes), el on-premise gana incluso con SRE. La clave está en separar la retención caliente de la fría, y en cloud eso se traduce en lifecycle policies que casi nadie configura bien.
