Plataforma observable no es aplicación observable

Hay una conversación que se repite en muchas áreas de tecnología. La organización invirtió en una plataforma APM de primer nivel, los agentes están desplegados, los paneles muestran mapas de servicios y la detección de anomalías funciona. Y aun así, cuando ocurre un incidente que afecta a clientes, el diagnóstico sigue tardando horas, termina en una sala con cinco equipos y se resuelve cuando alguien que conoce el código lee logs a mano.

La plataforma no está fallando. Está haciendo exactamente lo que puede hacer. El problema es una confusión de fondo: creer que una plataforma observable convierte en observable a la aplicación que corre encima. No es así, y entender por qué es la diferencia entre comprar visibilidad y tenerla.

Lo que una plataforma APM ve sola

Las plataformas APM actuales capturan una cantidad notable de información sin que el equipo de desarrollo escriba una línea. Dynatrace, con su OneAgent, y Datadog, con su agente y sus librerías de trazas, instrumentan de forma automática los entornos de ejecución más comunes. En términos generales, sin cambiar el código obtienes:

• Infraestructura: CPU, memoria, disco, red, contenedores, procesos y eventos del orquestador.
• Spans autoinstrumentados: solicitudes HTTP entrantes y salientes, llamadas a bases de datos, colas y frameworks conocidos, con su duración y su código de resultado.
• Dependencias: qué servicio llama a cuál, qué base de datos usa cada uno, cómo se conecta el conjunto.
• Señales técnicas de salud: tasa de errores HTTP, excepciones no controladas, latencia por endpoint, saturación de recursos.

Esto es mucho, y tiene un valor enorme. Antes de estas herramientas, armar el mapa de dependencias de una aplicación distribuida era un proyecto en sí mismo. Hoy la plataforma lo descubre. Detectar que un servicio está saturado, que una consulta SQL se volvió lenta o que un despliegue disparó los errores 500 es, en buena medida, un problema resuelto.

A esto lo llamamos plataforma observable: la infraestructura y la mecánica técnica de la aplicación son visibles.

Lo que ninguna plataforma puede adivinar

El límite aparece cuando la pregunta deja de ser técnica y pasa a ser de negocio. Un agente ve que una función tardó 300 milisegundos y devolvió un código 200. No puede saber que esa respuesta 200 contenía un rechazo de crédito por una regla mal configurada, que la transferencia quedó en estado pendiente en lugar de confirmada o que el cliente afectado es un comercio cuyo cierre diario depende de esa operación.

Hay cuatro tipos de información que solo existen dentro de la aplicación:

• Contexto de negocio: qué operación se estaba ejecutando (una apertura de cuenta, un pago, una emisión de póliza), sobre qué producto, por qué canal, en qué paso del flujo.
• Errores de dominio: los fallos que no son excepciones. Un saldo insuficiente, una validación regulatoria que no pasa, un proveedor que responde "en revisión". Para la plataforma, todo esto es una respuesta exitosa.
• Eventos significativos: los hitos que el negocio entiende. "Pago autorizado", "pago conciliado", "pago revertido". Sin ellos, solo hay llamadas HTTP.
• Continuidad del contexto: cuando una operación cruza una cola, un proceso por lotes o un sistema heredado sin instrumentación automática, la traza se corta salvo que el código propague el contexto de forma explícita.

Ninguna detección de anomalías, por buena que sea, puede inferir un significado que nunca se emitió. La inteligencia de la plataforma trabaja sobre los datos que recibe. Si los datos describen solo la mecánica, el diagnóstico será mecánico.

La plataforma te dice qué componente sufre. Solo la aplicación puede decirte qué le pasó al cliente.

Un incidente visto desde los dos lados

Un ejemplo ilustrativo ayuda a ver la diferencia. Supón que un lunes por la mañana crecen los reclamos porque las transferencias a otros bancos "no llegan". Ningún panel está en rojo.

Con plataforma observable y aplicación opaca, la plataforma muestra que el servicio de transferencias responde rápido y sin errores. La cola hacia el sistema de compensación tiene volumen normal. El equipo de operaciones escala a desarrollo. Desarrollo pide logs, que son texto libre sin identificador de transacción. Alguien correlaciona a mano por hora y monto. Horas después se descubre que un cambio en una tabla de parámetros hace que un tipo de transferencia quede en estado "retenida para revisión" sin notificar a nadie. Técnicamente, todo funcionó.

Con plataforma observable y aplicación observable, el servicio emite una métrica de transferencias por estado final. El panel muestra que las transferencias "retenidas" pasaron de casi cero a una proporción relevante desde una hora concreta. Los spans llevan atributos como tipo de transferencia y regla aplicada, y los logs estructurados llevan el trace_id. En minutos se ve que todas las retenidas comparten la misma regla, y la línea de tiempo coincide con el cambio de parámetros. La plataforma es la misma. Lo que cambió es lo que la aplicación le cuenta.

Qué significa escribir software para ser observable

Una aplicación observable no es una aplicación que escribe muchos logs. Es una aplicación que emite, de forma deliberada y consistente, la información que hace falta para explicar su comportamiento. En la práctica, se traduce en cinco hábitos de ingeniería:

1. Logs estructurados: en JSON o equivalente, con campos estables (servicio, operación, resultado, código de error de dominio), no frases que cambian con cada versión.
2. Identificadores de correlación: cada log lleva el trace_id y el span_id activos, y cuando corresponde, un identificador de negocio no sensible (por ejemplo, un identificador interno de operación).
3. Propagación de contexto: el contexto de traza viaja en las cabeceras HTTP, en los metadatos de los mensajes de colas y en los procesos asíncronos, usando el estándar W3C Trace Context.
4. Métricas de negocio: contadores e histogramas de lo que importa al negocio (operaciones por estado, montos procesados por canal en agregados, tiempos por paso del flujo), con etiquetas de baja cardinalidad.
5. Eventos significativos y errores de dominio: spans propios para los pasos clave del flujo, con atributos que describen la decisión tomada, y estado de error cuando el resultado de negocio es un fallo aunque la respuesta técnica sea exitosa.

OpenTelemetry es el estándar abierto de referencia para hacer todo esto, y las principales plataformas APM, Dynatrace y Datadog incluidas, aceptan datos de OpenTelemetry. Eso significa que el esfuerzo de instrumentar el código no queda atado a una herramienta, y que la plataforma que ya tienes puede combinar lo que captura sola con lo que tu aplicación le aporta.

Quién aporta qué

Separar responsabilidades evita dos errores simétricos: pedirle a la plataforma lo que no puede dar y pedirle a desarrollo que reinstrumente lo que la plataforma ya resuelve.

Necesidad	La plataforma APM lo cubre	Lo debe aportar la aplicación
Salud de hosts, contenedores y procesos	Sí, de forma automática	No
Mapa de dependencias entre servicios	Sí, para protocolos y frameworks soportados	Solo en tramos no soportados (colas propias, procesos por lotes)
Latencia y errores técnicos por endpoint	Sí	No
Qué operación de negocio se ejecutó y con qué resultado	No	Sí: atributos de span y eventos
Errores de dominio con respuesta técnica exitosa	No	Sí: estado de error y código de dominio
Indicadores de negocio en tiempo real	No	Sí: métricas propias
Correlación entre logs y trazas	Parcial, según lenguaje y configuración	Sí: logs estructurados con trace_id

Cómo empezar sin reescribir la aplicación

Volver observable una aplicación existente no exige un proyecto de reescritura. Exige foco. Recomendamos esta secuencia:

1. Elige los flujos críticos: dos o tres operaciones de negocio cuya falla tiene más impacto en clientes, en el SLA o en el cumplimiento.
2. Define las preguntas: para cada flujo, escribe qué necesitarías saber en un incidente. "¿Cuántas operaciones quedaron en cada estado?", "¿en qué paso se detuvieron?", "¿qué regla las rechazó?".
3. Instrumenta lo mínimo para responderlas: una métrica por estado final, spans en los pasos clave, atributos de negocio no sensibles y logs estructurados con trace_id.
4. Cierra los cortes de contexto: identifica dónde se pierde la traza (colas, procesos por lotes, integraciones heredadas) y propaga el contexto ahí.
5. Incorpóralo al estándar de desarrollo: que la observabilidad sea parte de la definición de terminado y de la revisión de código, no una tarea posterior de operaciones.

Medir el avance también es sencillo: el tiempo medio hasta identificar la causa en incidentes reales, y la proporción de incidentes en los que se llegó a la causa sin leer logs a mano.

La plataforma APM sigue siendo indispensable. Lo que cambia es la expectativa. La plataforma hace observable el terreno; el equipo de desarrollo hace observable el negocio que corre sobre él. Cuando ambas partes hacen su trabajo, la causa raíz deja de ser una investigación y pasa a ser una consulta.