- 01Entender
- 02Priorizar
- 03Actuar
La observabilidad suele empezar como un proyecto técnico y terminar como una línea presupuestaria difícil de explicar. El tráfico crece, aparecen nuevas etiquetas y nadie sabe qué datos consulta realmente. Reducir costos de observabilidad no significa apagar señales: significa pagar por evidencia útil.
De dónde viene la factura
Según el proveedor y el modelo de despliegue, el costo puede depender de:
- GB ingeridos de logs, trazas y perfiles.
- Series métricas activas y cardinalidad.
- Hosts, contenedores o servicios observados.
- Retención y almacenamiento.
- Consultas y datos analizados.
- Transferencia entre regiones o nubes.
- Infraestructura y personal de un stack autogestionado.
El primer paso es traducir la factura a unidades técnicas. Sin esa relación, los equipos no pueden modificar su comportamiento.
1. Crear un presupuesto de telemetría
Asigná visibilidad de volumen y costo por servicio, equipo, entorno y señal. Cada owner debería conocer:
- GB diarios de logs y trazas.
- Series métricas activas.
- Retención aplicada.
- Principales etiquetas por cardinalidad.
- Dashboards, alertas y consultas que usan esos datos.
El objetivo no es cobrar internamente desde el primer día, sino mostrar causa y efecto.
2. Controlar cardinalidad antes de filtrar datos
Una métrica crea una serie por combinación de etiquetas. Agregar user_id, URL completa o request ID puede producir miles o millones de combinaciones.
Acciones de alto impacto:
- Parametrizar rutas:
/orden/{id}. - Eliminar IDs únicos de labels.
- Revisar buckets de histogramas.
- Evitar dimensiones que nunca se agrupan o filtran.
- Establecer tests de cardinalidad en instrumentación.
Los valores únicos pueden conservarse en logs o spans si son necesarios para una investigación.
3. Diseñar logs por niveles de valor
No todos los logs merecen la misma retención.
| Nivel | Ejemplo | Estrategia |
|---|---|---|
| Crítico | Seguridad, auditoría, transacción | Alta integridad y retención definida |
| Operativo | Errores y cambios de estado | Búsqueda rápida y retención media |
| Diagnóstico | Debug detallado | Activación temporal o retención corta |
| Ruido | Health checks repetitivos | Agregación, métricas o descarte |
Un log que se emite miles de veces por minuto y nunca se consulta no es cobertura: es deuda.
4. Aplicar muestreo con contexto
El head sampling decide al inicio de la traza y reduce procesamiento. El tail sampling decide cuando conoce el resultado y puede priorizar:
- Errores.
- Latencia elevada.
- Servicios críticos.
- Clientes o regiones estratégicas.
- Eventos raros.
- Una muestra del tráfico saludable.
La política debe probarse con incidentes conocidos. Un porcentaje fijo para todo el tráfico es simple, pero puede eliminar justamente la transacción que se necesita investigar.
5. Separar retención operativa e histórica
Los últimos días requieren consultas rápidas. Los datos antiguos pueden moverse a almacenamiento más económico o agregarse.
Definí retención por pregunta:
- ¿Cuánto tarda en detectarse normalmente un incidente?
- ¿Qué período exige auditoría o regulación?
- ¿Qué tendencia necesita datos crudos y cuál acepta agregados?
- ¿Existe un procedimiento para recuperar archivos fríos?
Retener “por las dudas” no reemplaza una política.
6. Filtrar cerca del origen
Enviar datos innecesarios para descartarlos después consume red e ingestión. El OpenTelemetry Collector puede filtrar, transformar, redactar y muestrear antes del backend.
Sin embargo, las reglas centralizadas deben versionarse y observarse. Un filtro incorrecto puede ocultar evidencia en todos los servicios al mismo tiempo.
7. Revisar dashboards y alertas huérfanos
Inventariá quién usa cada dashboard, alerta y fuente. Un recurso sin owner ni consultas durante meses es candidato para archivo o eliminación controlada.
La revisión también descubre duplicaciones: la misma telemetría enviada a dos plataformas durante una migración puede permanecer años.
Métrica clave: costo por servicio observable
Relacioná costo con servicio, volumen y valor. Algunas aplicaciones críticas justifican telemetría profunda; otras sólo requieren disponibilidad y errores.
Un indicador útil combina:
- Costo mensual por servicio.
- Porcentaje de incidentes donde la telemetría fue utilizada.
- Tiempo medio para encontrar la causa.
- Volumen sin consultas.
- Cambio de costo por release o crecimiento de tráfico.
Unit economics de telemetría
El costo absoluto crece naturalmente con el negocio. Para saber si está fuera de control, relacioná consumo con una unidad estable: millón de transacciones, mil usuarios activos, servicio crítico o deployment.
Si el costo por millón de requests sube aunque el stack no cambió, investigá nuevas etiquetas, logs repetitivos o menor eficiencia de muestreo. Si baja, confirmá que la cobertura y el tiempo de diagnóstico no empeoraron.
Esta métrica permite conversar con Finanzas sin reducir la discusión a “la herramienta es cara”. También ayuda a proyectar escenarios de crecimiento y a negociar compromisos basados en volumen real.
Plan de reducción en 30 días
- Días 1–5: mapear unidades de cobro y top consumidores.
- Días 6–10: corregir cardinalidad extrema.
- Días 11–15: eliminar logs repetitivos y debug permanente.
- Días 16–20: diseñar muestreo y retención por criticidad.
- Días 21–25: archivar dashboards y pipelines sin owner.
- Días 26–30: establecer presupuestos y alertas de consumo.
Cada cambio debe compararse contra una prueba de diagnóstico para verificar que no se pierde evidencia esencial.
Guardá una línea base antes de optimizar: volumen, costo, tiempo de consulta y capacidad de resolver tres incidentes conocidos. Repetí las mismas investigaciones después. El ahorro es válido sólo si la evidencia continúa disponible dentro del tiempo que la operación necesita.
Próximo paso
CTL puede realizar un assessment de costos, cardinalidad y cobertura sobre plataformas comerciales u open source. Agendá una revisión para identificar ahorros sin comprometer SLOs ni respuesta a incidentes.
Preguntas frecuentes
¿Open source elimina el costo?
Elimina o reduce licencias, pero mantiene cómputo, almacenamiento, red, alta disponibilidad, upgrades y horas de especialistas. Debe compararse costo total.
¿Conviene borrar logs de health checks?
Muchas veces pueden convertirse en métricas o muestrearse, pero primero hay que verificar si cumplen una función de auditoría o diagnóstico.
¿Quién debería gobernar el costo?
Una práctica de plataforma o observabilidad puede definir estándares, pero los equipos dueños de servicios deben ver y controlar su consumo.