- 01Entender
- 02Priorizar
- 03Actuar
La observabilidad full stack es la capacidad de explicar por qué una experiencia digital se degradó conectando lo que sucede en el navegador, la aplicación, las APIs, las bases de datos, la infraestructura y los servicios de terceros. Su promesa no es mostrar más gráficos: es reducir el tiempo entre una señal confusa y una decisión correcta.
En una arquitectura distribuida, un checkout lento puede originarse en una consulta SQL, una dependencia externa, un despliegue reciente, saturación de CPU o una cadena de reintentos entre microservicios. Si cada equipo mira una consola distinta, el incidente se transforma en una reunión. La observabilidad busca que la evidencia ya llegue relacionada.
Definición breve: qué es observabilidad full stack
OpenTelemetry define la observabilidad como la capacidad de comprender un sistema a partir de la telemetría que emite. En la práctica, full stack agrega una condición: esa comprensión debe atravesar todas las capas que participan de la experiencia del usuario.
Una plataforma observable debería responder, al menos, estas preguntas:
- ¿Qué servicio está afectando al usuario?
- ¿Cuándo comenzó y qué cambió antes?
- ¿La causa está en código, infraestructura o una dependencia?
- ¿Qué clientes, regiones o transacciones están impactados?
- ¿Existe riesgo operativo o de seguridad asociado?
Si sólo puede confirmar que “la CPU está alta”, existe monitoreo. Si permite seguir una transacción lenta hasta el servicio y la consulta responsables, existe observabilidad accionable.
Los tres pilares y el contexto que los vuelve útiles
Métricas
Las métricas resumen comportamientos en el tiempo: tasa de solicitudes, errores, latencia, saturación, uso de recursos o conversión. Son eficientes para detectar tendencias y activar alertas, pero normalmente no explican por sí solas una anomalía individual.
Logs
Los logs registran eventos con detalle. Ayudan a reconstruir decisiones de una aplicación, errores y actividad de seguridad. Para que escalen deben ser estructurados, consistentes y contener contexto como servicio, entorno, versión y, cuando corresponde, trace_id.
Trazas
Las trazas distribuidas siguen una solicitud mientras atraviesa servicios. Permiten ver el recorrido, la duración de cada operación y el punto exacto donde aparece una demora o error. Son especialmente valiosas en microservicios y arquitecturas orientadas a eventos.
OpenTelemetry también trabaja sobre perfiles y eventos. Sin embargo, agregar señales sin un modelo común puede recrear el mismo problema en una plataforma nueva. La unidad de valor no es el dato: es la correlación.
Full stack no significa “guardar todo”
Una mala implementación captura cada evento, conserva todos los campos y habilita dashboards genéricos. El resultado suele ser una factura creciente y un equipo que continúa investigando manualmente.
Una implementación sostenible define primero:
| Decisión | Pregunta operativa |
|---|---|
| Servicios críticos | ¿Qué experiencia no puede degradarse sin impacto? |
| Señales | ¿Qué dato permite confirmar o descartar una hipótesis? |
| Identidad | ¿Cómo se nombran servicios, entornos y versiones? |
| Retención | ¿Cuánto tiempo conserva valor cada tipo de dato? |
| Muestreo | ¿Qué trazas deben guardarse siempre? |
| Responsabilidad | ¿Quién recibe la alerta y qué puede hacer? |
El objetivo es conservar suficiente evidencia para investigar, no transformar el backend de observabilidad en una copia ilimitada de producción.
Arquitectura mínima de observabilidad
Una arquitectura vendor-neutral puede organizarse en cinco capas:
- Instrumentación: agentes, SDKs y librerías generan telemetría.
- Recolección: un collector recibe datos y aplica filtros, enriquecimiento o muestreo.
- Transporte: OTLP u otros protocolos mueven la telemetría de forma controlada.
- Almacenamiento y análisis: uno o más backends consultan métricas, logs, trazas y perfiles.
- Operación: alertas, SLOs, playbooks y responsables convierten datos en acciones.
OpenTelemetry permite desacoplar instrumentación y destino. No elimina todas las migraciones, pero reduce la dependencia entre el código de la aplicación y una herramienta específica.
Qué cambia frente al monitoreo tradicional
El monitoreo tradicional verifica estados conocidos: disponibilidad, umbrales y recursos. Sigue siendo necesario. La observabilidad agrega capacidad para investigar comportamientos que no fueron anticipados al crear la alerta.
Google SRE recomienda observar latencia, tráfico, errores y saturación como señales fundamentales. En full stack, esas señales se conectan con despliegues, topología, usuarios y objetivos de servicio. Una alerta deja de ser “latencia mayor a 800 ms” y pasa a indicar qué versión, endpoint y segmento concentran el problema.
Plan de implementación en 90 días
Días 1 a 30: elegir una experiencia
Seleccioná un flujo crítico, por ejemplo autenticación, checkout o emisión de una orden. Documentá sus dependencias, responsables y SLO. Evitá empezar por toda la organización.
Días 31 a 60: correlacionar señales
Instrumentá el recorrido, normalizá atributos y validá que métricas, logs y trazas compartan identidad. Probá fallas controladas y verificá si la evidencia permite encontrar la causa.
Días 61 a 90: operar y optimizar
Definí alertas basadas en síntomas, playbooks, retención y presupuestos de telemetría. Medí el tiempo para detectar, diagnosticar y recuperar. Eliminá datos sin uso antes de ampliar cobertura.
Indicadores de que la estrategia funciona
- Menos tiempo para identificar el servicio responsable.
- Menos alertas sin acción definida.
- Mayor porcentaje de incidentes correlacionados con cambios.
- Menor volumen de telemetría que nadie consulta.
- SLOs asociados a experiencias reales, no sólo a componentes.
- Equipos de desarrollo, operaciones y seguridad usando contexto compartido.
La observabilidad madura no se reconoce por la cantidad de pantallas. Se reconoce porque una persona puede pasar del síntoma al impacto y de ahí a la causa sin cambiar de conversación cinco veces.
Próximo paso
CTL diseña e integra arquitecturas de observabilidad con Grafana, Prometheus, OpenTelemetry y plataformas APM comerciales. Agendá una reunión para evaluar el stack actual, los casos de uso y el costo de telemetría.
Preguntas frecuentes
¿Observabilidad y APM son lo mismo?
No. APM se concentra en rendimiento y comportamiento de aplicaciones. La observabilidad puede incluir APM, pero también infraestructura, redes, experiencia de usuario, negocio y seguridad.
¿Se puede implementar con herramientas open source?
Sí. Prometheus, Grafana, Loki, Tempo y OpenTelemetry pueden cubrir gran parte del flujo. La organización debe dimensionar también operación, alta disponibilidad, actualizaciones, retención y soporte.
¿Cuál es el primer dashboard que conviene crear?
Uno orientado a una experiencia crítica con tasa, errores, duración y dependencias. Los dashboards por tecnología pueden complementar, pero no deberían ser el punto de partida.