¿Qué es observabilidad y en qué se diferencian logs, métricas y trazas?
Publicado el 2026-10-20 por frfrand
Observabilidad explicada: qué cuentan logs, métricas y trazas, cómo investigar errores y cuándo conviene combinarlas.
Observabilidad es la capacidad de comprender el estado interno de un sistema a partir de información que produce mientras funciona. En software, tres tipos de señales aparecen constantemente: logs, métricas y trazas.
La palabra suena sofisticada, pero intenta resolver una pregunta muy concreta: «¿por qué está fallando mi aplicación si aparentemente todo está encendido?».
El ejemplo del auto
Cuando conducís, el velocímetro te muestra la velocidad y la temperatura indica si el motor se calienta: se parecen a las métricas.
Si el vehículo registra «falló el sensor a las 10:42», eso se parece a un log.
Si pudieras seguir todo el recorrido de una orden desde el acelerador hasta los componentes que reaccionan, tendrías algo parecido a una traza.
Ninguna señal, por sí sola, cuenta siempre toda la historia.
¿Qué son los logs?
Son registros de eventos. Pueden indicar que un usuario inició sesión, que falló una consulta o que se reinició un proceso.
Los buenos logs tienen información suficiente para investigar sin exponer contraseñas, tokens ni datos privados innecesarios. El mensaje «Error inesperado» repetido mil veces sirve mucho menos que un evento claro con hora, componente y contexto seguro.
¿Qué son las métricas?
Son valores que podés medir a lo largo del tiempo: consumo de CPU, memoria, peticiones por segundo, latencia o proporción de errores.
Una métrica te ayuda a detectar tendencias. Por ejemplo, si la duración de las solicitudes aumenta después de un despliegue, es una pista para investigar.
Pero saber que hay más errores no significa saber cuál línea de código los produjo.
¿Qué son las trazas?
Una traza representa el recorrido de una operación a través de componentes. En una arquitectura con frontend, API, base de datos y un servicio externo, permite observar qué parte consume más tiempo o dónde falla.
Se compone de operaciones llamadas spans. Cada una puede registrar duración y contexto, según cómo se instrumente.
Esto resulta especialmente útil en sistemas distribuidos, donde un error visible para el usuario puede originarse en un servicio lejano.
Un caso práctico
Una tienda empieza a responder lentamente. La métrica muestra que el tiempo de respuesta subió. Los logs indican que hay consultas lentas. La traza de una compra concreta señala que casi todo el tiempo se consume en una operación de base de datos.
Con esa combinación podés investigar el índice, consulta o bloqueo que corresponde, en lugar de reiniciar servidores sin motivo.
Observabilidad no significa guardar absolutamente todo
Registrar información sin límites puede costar dinero, consumir almacenamiento y exponer datos. Conviene decidir qué eventos son útiles, cuánto tiempo se conservan y qué información debe anonimizarse o eliminarse.
También importa la cardinalidad de las métricas. Si creás una serie diferente por cada identificador de usuario, el volumen puede crecer de manera descontrolada.
¿Qué debería medir una aplicación pequeña?
Comenzá por disponibilidad, errores, duración de solicitudes, uso de recursos y logs útiles al diagnosticar fallos. Si hay varias aplicaciones comunicándose, las trazas distribuidas pueden añadir mucho valor.
No hace falta instalar una plataforma gigantesca antes de tener una primera web funcionando. Lo importante es poder responder qué cambió, cuándo y con qué impacto.
¿Cómo aplicarlo en ArduMaker?
Las aplicaciones desplegadas en VPS de ArduMaker pueden producir logs, métricas y, si se instrumentan, trazas. Organizar esas señales permite diferenciar un problema de red de una consulta lenta o un fallo de despliegue.
En una frase: métricas muestran tendencias, logs cuentan eventos y trazas conectan operaciones. La observabilidad aparece cuando podés relacionar esas señales para entender el comportamiento real.
Fuentes: OpenTelemetry Observability Primer · Google SRE: Monitoring Distributed Systems.