Logging en aplicaciones: qué registrar para que los logs sean útiles

Los logs son el rastro de pan que dejan tus aplicaciones en producción. Pero si ese rastro es un desorden de mensajes incomprensibles, de poco te sirve cuando necesitas depurar un problema. He visto sistemas con gigabytes de logs al día, donde encontrar la causa de un fallo era un desafío.

Mi enfoque es simple: los logs deben ser una herramienta de diagnóstico, no un vertedero de texto. Si no te ayudan a entender qué pasó, quién lo hizo y por qué, entonces estás perdiendo tiempo y espacio en disco.

Registra el qué, el quién y el cuándo

La diferencia entre un log útil y uno inútil no es la cantidad de texto, sino la información que contiene. Un buen log te da contexto inmediato sin tener que buscar en otras fuentes. Incluye siempre la fecha y hora, el nivel de severidad y un mensaje claro.

Más allá de lo básico, considera registrar identificadores únicos. Un requestId que siga una petición a través de múltiples servicios es oro puro para depurar microservicios. Cuando un cliente me llega con un problema de “algo no funciona”, lo primero que pido es el ID de la operación que falló.

El formato importa: structured logging

La tentación de usar console.log("Algo ha pasado: " + variable) es fuerte, pero es un error en producción. Los logs en texto plano son difíciles de parsear de forma automática y complican la vida a las herramientas de análisis. La solución es el structured logging.

Registrar tus logs en JSON te permite añadir campos clave-valor que se pueden buscar, filtrar y agregar fácilmente. Esto transforma tus logs en datos analizables, no solo en un flujo de texto.

{
  "timestamp": "2026-10-05T10:30:00Z",
  "level": "ERROR",
  "message": "Fallo al procesar pago",
  "requestId": "abc-123-def-456",
  "userId": "user-789",
  "orderId": "order-001",
  "component": "payment-service",
  "errorDetails": {
    "code": "PAYMENT_GATEWAY_TIMEOUT",
    "gatewayResponse": "504 Gateway Timeout"
  }
}

Este tipo de log es legible para un humano y procesable por una máquina. Es lo que siempre busco implementar en proyectos que se prevé que tendrán un volumen de uso real.

Niveles de log y cuándo usarlos

No todos los mensajes tienen la misma importancia. Usar los niveles de log correctamente te permite filtrar el ruido y centrarte en lo que realmente importa.

• ERROR: Algo grave ha fallado y requiere atención inmediata. La aplicación no puede continuar con una parte de su funcionalidad.
• WARN: Algo inesperado ha ocurrido, pero la aplicación puede recuperarse o continuar. Podría ser un síntoma de un problema futuro.
• INFO: Eventos importantes que muestran el progreso normal de la aplicación. Inicio de un proceso, finalización de una tarea crítica.
• DEBUG: Información detallada útil solo para desarrolladores durante la depuración. No debe estar activa en producción salvo en casos muy específicos.

Mi regla es clara: en producción, los logs DEBUG están deshabilitados. Solo INFO, WARN y ERROR son visibles por defecto. Esto evita que el volumen de logs se dispare y que el equipo de operaciones se ahogue en información irrelevante.

El tradeoff honesto del logging

Implementar un buen sistema de logging tiene sus ventajas, pero también sus complejidades.

Lo que ganas:

• Depuración rápida: Identificas problemas de forma exponencialmente más veloz, reduciendo el tiempo de inactividad.
• Visibilidad operativa: Entiendes el comportamiento de tus aplicaciones en tiempo real, no solo cuando algo falla.
• Análisis de tendencias: Puedes detectar patrones de error o cuellos de botella antes de que se conviertan en fallos críticos.

Lo que complicas:

• Coste de almacenamiento: Los logs estructurados son más grandes y requieren más espacio y, a menudo, sistemas de gestión dedicados.
• Rendimiento: Un logging excesivo o mal implementado puede impactar negativamente el rendimiento de la aplicación.
• Configuración inicial: Requiere una inversión de tiempo en definir qué loguear y cómo, además de integrar bibliotecas de logging.

Lo que no negocias:

• Seguridad: Nunca registres información sensible como contraseñas, claves API o datos personales sin anonimizar. Es un riesgo de seguridad enorme y una violación de la privacidad.
• Consistencia: El formato y el nivel de detalle de los logs deben ser consistentes en todas tus aplicaciones y servicios.

Si quieres evitar quebraderos de cabeza con los errores que solo aparecen en producción, necesitas entender la diferencia entre código local y producción. Para una gestión más eficiente de los registros, especialmente en servidores, te aconsejo revisar cómo funciona la rotación de logs en un VPS. Y si ya tienes un buen sistema de logs, el siguiente paso es pensar en cómo diseñar un sistema de notificaciones que te avise cuando algo crítico suceda.