Cómo detectar errores en logs de Linux con IA

Dónde viven los logs en Linux

En Linux los logs viven en dos lugares, y conviene conocer ambos. Un log es simplemente un archivo donde el sistema y las aplicaciones anotan lo que hacen: cada arranque, cada error, cada conexión. Saber dónde busca cada programa es la mitad del trabajo.

El primer sitio es el journal de systemd, un registro binario centralizado que consultas con el comando journalctl. Ahí escriben casi todos los servicios modernos: el arranque del sistema, los reinicios, los fallos de un servicio que no levanta.

El segundo sitio es la carpeta /var/log, con archivos de texto plano que puedes abrir con cualquier herramienta. Los más importantes:

Un detalle que ahorra sustos: en las distribuciones tipo Red Hat (Rocky Linux, AlmaLinux) el syslog no existe con ese nombre; el registro general está en /var/log/messages y buena parte del sistema vive ya solo en el journal.

Cómo leer un log sin ahogarte

Para leer un log no lo abras entero: usa tail, grep y journalctl para quedarte solo con lo que importa. Un archivo de log puede tener cientos de miles de líneas; abrirlo con un editor es la peor idea. Estos tres comandos resuelven el 90 % de los casos.

Ver las últimas líneas. tail muestra el final del archivo, que es donde está lo más reciente:

sudo tail -n 100 /var/log/nginx/error.log

Seguir el log en vivo. La bandera -f deja la terminal abierta mostrando cada línea nueva según se escribe. Ideal para reproducir un error y verlo aparecer:

sudo tail -f /var/log/nginx/error.log

Buscar una palabra concreta. grep filtra solo las líneas que contienen un texto. La opción -i ignora mayúsculas y minúsculas:

sudo grep -i "error" /var/log/mysql/error.log

Consultar el journal de systemd. Aquí journalctl es el rey. Las combinaciones que más se usan:

# Solo errores (prioridad "err" o peor)
sudo journalctl -p err

# Errores de la última hora
sudo journalctl -p err --since "1 hour ago"

# Todo lo de un servicio concreto
sudo journalctl -u nginx --since "today"

# Los mensajes del último arranque del sistema
sudo journalctl -b

La bandera -p err es la más útil de todas: filtra por prioridad y te deja solo los mensajes de nivel error o más graves, descartando el ruido informativo. Si combinas -p err con --since, pasas de miles de líneas a una lista corta que sí puedes leer.

Qué patrones buscar

La línea que explica una caída casi siempre contiene una de estas palabras: error, failed, refused, denied, timeout, fatal o out of memory. Buscar esos términos con grep es el atajo más directo hacia la causa.

Estos son los patrones que más se repiten y lo que suelen significar:

Hay un segundo dato tan importante como la palabra: la hora. La línea que importa no es donde ves el síntoma, sino la de justo antes de que el servicio dejara de responder. Si tu web murió a las 03:14, el comando que te interesa es:

sudo journalctl --since "03:10" --until "03:20"

Ese recorte de diez minutos suele contener la línea que lo explica todo: un out of memory que tumbó a PHP-FPM, un connection refused a la base de datos, un reinicio de servicio que no terminó bien. Si quieres profundizar en dos síntomas concretos, tenemos guías dedicadas al error 502 Bad Gateway en Nginx y al error 504 Gateway Timeout, y una referencia de los códigos de estado HTTP para saber qué te está diciendo el navegador.

Dónde falla la lectura manual

Leer logs a mano funciona hasta que el problema cruza varios servicios a la vez. El error real puede empezar en MySQL, propagarse a PHP-FPM y aparecer como un 502 en Nginx. Tú ves el 502, pero la causa está tres logs más atrás, con una marca de tiempo que tienes que correlacionar manualmente entre archivos distintos.

Ahí es donde la lectura línea por línea se vuelve lenta y frustrante. Necesitas abrir el error.log de Nginx, cruzarlo con el journal de PHP-FPM, mirar el log de MySQL a la misma hora y sostener las tres cronologías en la cabeza al mismo tiempo. Es un trabajo mecánico y aburrido, justo el tipo de tarea en la que un modelo de lenguaje rinde bien: leer mucho texto, encontrar el hilo y resumirlo.

Cómo un agente de IA lee los logs por ti

Un agente de IA lee los logs por SSH, ejecuta los mismos comandos que usarías tú, correlaciona las horas entre servicios y te resume la causa en dos frases. La diferencia con preguntarle a un chatbot genérico es que el agente está conectado a tu servidor real: no adivina, lee tu máquina.

En Terranode ese agente se llama Cortex AI y viene incluido sin costo adicional en todos los planes VPS. Un VPS (servidor privado virtual) es una máquina Linux completa que alquilas y administras tú. Si quieres el panorama del concepto está el artículo sobre VPS con inteligencia artificial y la ficha detallada de Cortex AI.

El uso es una conversación. Le escribes en español:

> "Revisa por qué se cayó el sitio a las 3 a.m."

Y Cortex se conecta por SSH, acota el journal a esa franja horaria, revisa los logs de Nginx, PHP y MySQL, y te contesta algo como:

> "PHP-FPM se quedó sin memoria a las 03:14 y el kernel lo mató (oom-killer). Nginx devolvió 502 durante seis minutos hasta que systemd reinició el servicio. El pico coincide con un proceso de backup que corrió a esa hora."

Eso es leer cientos de líneas y devolver la causa, la hora y el efecto, en el tiempo que tardas en leer un mensaje. Y todo con controles: confirma antes de cualquier acción con consecuencias, bloquea los comandos destructivos, deja un registro consultable de lo que hizo y guarda su llave SSH cifrada con AES-256, con cada cliente aislado del resto. Leer un log fluye solo; reiniciar un servicio, no: eso te lo pregunta primero. Por ahora funciona únicamente sobre Linux.

Cortex no sustituye saber leer un log: te ahorra el trabajo pesado y te muestra los comandos que ejecuta, así que también se aprende viéndolo trabajar. Para el caso más frecuente de todos hay una guía específica: diagnosticar un servidor Linux lento con IA.