journalctl explicado con ejemplos: encontrar errores de una app Linux
Publicado el 2026-10-26 por frfrand
Buscar logs de servicios por unidad, prioridad y fecha con journalctl
Cuando una app se cae a las tres de la mañana, la pregunta no es «¿qué comando reinicia todo?». Es «¿qué pasó justo antes?». journalctl te deja consultar logs de servicios con filtros de tiempo, unidad y prioridad.
Te muestro dónde está el problema, cómo comprobarlo sin adivinar y qué haría en una aplicación que de verdad tiene usuarios. No necesitás memorizar un manual entero para resolver un fallo concreto.
Qué significa journalctl en la práctica
El journal de systemd guarda eventos de aplicaciones y servicios compatibles. Se puede filtrar por unidad (-u), arranque (-b), prioridad (-p) y ventanas temporales. La retención depende de la configuración y el espacio disponible.
Una aclaración antes de tocar el servidor: si el proyecto ya está en producción, guardá el estado que encontraste y comprobá en qué usuario y máquina vas a ejecutar los comandos. Trabajar como root sin necesidad y cambiar varias cosas a la vez dificulta encontrar la causa de un error.
Comandos útiles para empezar
sudo journalctl -u miapp -n 100 --no-pager
sudo journalctl -u miapp --since '2026-10-26 09:00' --until '2026-10-26 10:00'
sudo journalctl -b -p err --no-pager
sudo journalctl -u miapp -f
sudo journalctl --disk-usageLas rutas, nombres de unidades y dominios son ejemplos. Adaptalos a tu servicio. Si un comando requiere permisos de administrador, revisá qué cambia y por qué. Las consultas de diagnóstico deberían venir antes de las modificaciones.
Paso a paso, con comprobaciones
- Identifica el nombre real de la unidad que ejecuta la aplicación.
- Busca la hora del fallo y acótala con
--sincey--until. - Sigue primero el error más antiguo de la cadena, no el último síntoma.
- Si hay varios servicios, compara las marcas de tiempo de Nginx, API y worker.
- Define la retención y evita registrar contraseñas o datos personales.
Después de cada paso, verifica un resultado observable: un estado, un archivo, una respuesta HTTP o una entrada de log. Si encuentras un mensaje inesperado, guárdalo para investigar en lugar de ocultarlo con reinicios repetidos.
Ejemplo real: una aplicación que hay que mantener
Una reserva devuelve 500 solo cuando el usuario añade una nota larga. Los registros muestran un error de validación antes de cualquier conexión a PostgreSQL: el problema no era el VPS ni el proxy.
Al final, prueba el camino completo: entrar por dominio, llamar a la API, escribir un dato de prueba y verificar que la información sigue ahí tras un reinicio controlado. Un servidor que «arranca» no siempre es una aplicación que funciona.
Errores que vale la pena evitar
Si la aplicación guarda sus registros únicamente en un archivo propio, journalctl quizá no muestre toda la información. Confirma dónde se escriben stdout, stderr y registros estructurados.
También es importante que las credenciales no terminen en el historial de la terminal, registros, archivos compartidos o capturas. Para usuarios y servicios, usa permisos mínimos y documenta quién puede revocar el acceso.
Cómo entra ArduMaker en este escenario
En ArduMaker, la consulta de logs por VPS y proceso ayuda a investigar sin reiniciar a ciegas. Usá esa evidencia para crear incidencias con pasos de reproducción claros.
ArduMaker puede ayudarte a administrar los VPS, desplegar repositorios y trabajar con servicios, bases y dominios desde la misma plataforma. No reemplaza lo que acabamos de explicar sobre Linux: precisamente por eso conviene entender el diagnóstico y tener una forma de repetirlo.
Cuándo conviene automatizarlo
Si la tarea se repite, documentá primero el procedimiento manual y sus comprobaciones. Después considerá un script o una tarea programada con errores visibles, logs y permisos limitados. No automatices un comando que todavía no sabés recuperar cuando sale mal.
Preguntas habituales
¿Puedo probarlo sin afectar clientes? En muchos casos sí: un VPS de staging o un servicio de prueba separado permite validar la configuración antes de cambiar producción.
¿Cómo sé si quedó bien? Mirá logs y una operación funcional, no solamente que el comando terminó con código cero.
¿Cuándo necesito más recursos? Cuando las métricas indiquen saturación de CPU, RAM, disco o conexiones. Un fallo de configuración rara vez se arregla contratando más memoria.
Referencias
En una frase: primero entiende el error, después cambia una cosa concreta y comprueba su efecto. Esa disciplina te ahorra muchas horas de soporte.