Para ver los registros de un servicio en Linux, consulta el diario de su unidad con journalctl. Filtra el diario de systemd por unidad y por hora para reconstruir lo que ocurrió antes de la falla.
Consultar los registros de un servicio en Linux paso a paso
Ajusta la hora del incidente
Anota la hora y zona horaria del VPS. Identifica el nombre de la unidad de systemd que atiende la aplicación. Sustituye nginx.service en los ejemplos por esa unidad.
dateFiltra el diario por unidad
Busca mensajes inmediatamente anteriores y posteriores al incidente. Si ocurrió antes, amplía el intervalo. Conserva la fecha, la unidad y la secuencia de mensajes relacionados.
journalctl -u nginx.service --since '30 minutes ago' --no-pagerCompara con el arranque actual
Consulta hasta 50 mensajes del arranque actual para contrastar los resultados. Si faltan entradas, verifica tus permisos de lectura y si la aplicación escribe en un archivo propio.
journalctl -u nginx.service -b -n 50 --no-pagerEjemplo de diagnóstico
Una persona reporta que el sitio dejó de responder a las diez. Si su hora local es distinta de la del servidor, una búsqueda en el intervalo equivocado podría parecer vacía. Convierte las horas o registra ambas zonas. Amplía primero unos minutos alrededor del incidente y reduce después la búsqueda hasta encontrar la secuencia pertinente.
Lee también las líneas que aparecen antes del error más visible. Un mensaje de reintento puede deberse a un fallo anterior, como una dependencia que dejó de responder. Conserva el orden y las marcas de tiempo al compartir un fragmento. Una colección de mensajes separados sin hora hace más difícil distinguir la causa de los efectos posteriores.
Cómo comprobar tu conclusión
Un diario vacío no demuestra que la aplicación funcionó bien. Puede que la cuenta tenga acceso parcial, que el registro se conserve por poco tiempo o que la aplicación escriba en otra ubicación. El filtro del arranque actual tampoco muestra un fallo anterior al último reinicio. Ajusta una condición a la vez para saber por qué cambió el resultado.
Ejercicio para reconstruir una secuencia
Abre una nota y registra cuatro datos antes de filtrar: qué operación se intentó, en qué unidad esperas encontrarla, a qué hora empezó y a qué hora se recuperó. Busca ese intervalo conservando unas líneas antes y después. Si aparecen muchos resultados, reduce primero el intervalo. Si aparecen muy pocos, retira temporalmente una condición para comprobar cuál dejó fuera las entradas esperadas.
Clasifica tres líneas relevantes por su función en el incidente. Una puede indicar que el servicio estaba iniciando, otra puede contener el primer error y una tercera puede registrar el intento de recuperación. Mantén el texto técnico que permite distinguirlas. Si todas muestran el mismo segundo, conserva el orden en que aparecen en el diario en vez de reconstruirlo de memoria.
Para entregar la evidencia, comparte únicamente el fragmento necesario. Sustituye por etiquetas consistentes los nombres privados o identificadores de clientes. Si ocultas el mismo dato de dos formas distintas, puede parecer que el registro habla de dos clientes diferentes. Incluye el nombre de la unidad, la zona horaria y si consultaste el arranque actual o un periodo que abarca más de un arranque.
Cómo interpretar el resultado
Si varios servicios registran errores en el mismo minuto, conserva el orden de los mensajes. Una advertencia posterior puede ser consecuencia de la primera falla.
Pregunta frecuente
¿Qué comparto con soporte?
Envía el intervalo, la zona horaria, el síntoma y las líneas pertinentes. Oculta tokens, direcciones privadas de clientes y datos personales.
¿Necesitas más ayuda?
Cuéntanos qué estabas revisando y a qué hora ocurrió el problema. Te apoyamos en español mexicano. Contactar a HostingLeón por WhatsApp.
Referencia técnica de journalctl.1
Consulta otras guías en el centro de ayuda de HostingLeón.