Leer logs sin pánico: el registrador de tu aplicación

La caja negra que habla por ti

Un log es la memoria de la aplicación: qué ocurrió, cuándo y con qué resultado. Cuando el error está en producción y no puedes «verlo», el log es tu único testigo. No lo escribes a mano: lo pides. Y aprendes a escanearlo buscando lo que brilla en rojo.

Los niveles: qué mira cada uno

En un incidente, ve directo a los «error» y luego retrocede desde ahí en el tiempo.
Nivel	Qué significa	Cuándo mirarlo
info	Todo normal, un hito	para seguir el flujo habitual
warn	Algo raro pero no roto	cuando sospechas de un borde
error	Algo falló	el primer sitio en un incidente
trace / stack	La ruta exacta del fallo por dentro	para localizar la línea culpable

Un log de ejemplo

El rastro de un 500

bash

[10:02:11] INFO  GET /contactos -> 200 (34 registros)\n[10:02:15] INFO  POST /contactos cuerpo={nombre:"Ana"}\n[10:02:15] WARN  email vacio, se acepto igual\n[10:02:40] ERROR GET /contactos/87 -> fallo: no existe\n[10:02:40] ERROR stack: findById(87) devolvio null; se llamo .telefono sobre null\n[10:02:40] INFO  respuesta al cliente: 500

Las dos líneas ERROR te dicen qué y dónde: buscar el id 87 que no existe y operar sobre null. Con eso, la IA corrige sin adivinar.

Qué le pides a la IA con esto

Le copias las líneas relevantes (no el archivo entero) y aplicas el protocolo del OA anterior. Los logs son el paso 4; unen el error con su contexto. También puedes pedir que instrumente la app para generar logs útiles donde aún no los hay:

Del log a la corrección y a la observabilidad

texto

El log de produccion muestra: ERROR stack: findById(87) devolvio null; se llamo .telefono sobre null.\nAnade un chequeo para que un id inexistente devuelva 404 con mensaje claro en vez de reventar.\nAdemas, instrumenta el endpoint GET /contactos/{id} con log INFO de la entrada y WARN si no encuentra registro.

Primero arreglas el fallo que el log reveló; después haces que el log exista para el próximo incidente.

Prueba

Tu app devolvió un error 500 en producción. ¿Qué línea del log te señala primero la causa?

Un log útil debe registrarse solo cuando algo falla; nunca conviene tener INFO de las operaciones normales.

Detecta el log inútil

Revisas cómo una IA dejó la aplicación instrumentada. Señala la decisión que te dejará ciego ante el próximo fallo:

Marca la línea o las líneas con error y pulsa Comprobar.

Pide a la IA que instrumente una ruta de tu proyecto con INFO, WARN y ERROR útiles. Provoca un fallo y localiza su causa leyendo solo el log.

Si no puedes explicar el fallo desde el log, tu registro todavía no te sirve.

Tu texto se guarda sólo en este dispositivo.