Anoche pasó algo: dónde está realmente el registro

Una alerta dice que pasó algo. Un registro dice por qué. El detalle: el registro que más falta hace cubre el minuto en que la máquina murió, y en una instalación por defecto es justo el que más probablemente no está.

AtlasPVE ·

Esta entrada responde a

  • proxmox logs tras caída
  • proxmox ubicación archivos de registro
  • proxmox registro de tareas ubicación
  • proxmox syslog ubicación
  • proxmox logs after crash

La máquina se reinició durante la noche y nadie se lo pidió. Todo vuelve a funcionar, nada está visiblemente roto, y la única frase honesta posible es esta: pasó algo.

La supervisión tiene tres registros y responden a tres preguntas distintas. Una alerta dice que pasó algo. Una métrica dice qué forma tenía. Un registro dice por qué. Este texto trata del tercero, y de ese hecho incómodo: el registro que cubre el minuto interesante es el que con más probabilidad ya no está.

La primera pregunta es más pequeña de lo que parece

Antes de cualquier teoría sobre el hardware, haga la pregunta más barata disponible: ¿la apagaron, o murió?

Una sola línea lo responde. Un apagado limpio deja una firma al final del registro del arranque anterior: el servicio de registro anota que le pidieron detenerse, y después anota que se detuvo. Una máquina que se quedó sin corriente no deja final alguno. El registro simplemente se corta en mitad de una actividad corriente.

Esa sola distinción parte la investigación en dos. Un final limpio significa que algo decidió reiniciar, así que busque quién lo pidió: una actualización, un perro guardián, una tarea programada, una persona. Sin final significa que la máquina fue interrumpida, así que mire la alimentación, el calor, la memoria y el almacenamiento que hay debajo.

Pero solo si el arranque anterior sigue existiendo

Aquí está la trampa. El journal conserva historial de forma permanente solo cuando existe un directorio concreto en el disco. Si falta, el journal vive en memoria, y cada reinicio borra exactamente la prueba que vino a buscar. No hay error ni aviso; usted pide el arranque anterior y le responden que no hay ninguno.

Conviene comprobarlo una tarde tranquila y no la mañana en que hace falta. Es un directorio, y es lo que separa tener un registro de creer que lo tiene.

Además tiene la misma forma que una trampa que merece nombrarse dos veces: un grabador que comparte el destino de lo grabado. La curva que más quiere es la que dejó de escribirse justo cuando la cosa se puso interesante; y el registro que más quiere pertenece al arranque que ya no existe.

El archivo que medio internet le dice que lea puede no estar

Medido en una instalación actual, Proxmox VE 9.2.6 sobre Debian 13.6: el clásico demonio de registro del sistema no está instalado, y /var/log/syslog no existe.

Pesa más de lo que suena. Buena parte de los consejos de diagnóstico escritos en los últimos quince años empieza con "mira /var/log/syslog". En una máquina actual ese comando no devuelve nada, y para alguien bajo presión el resultado se lee como *no tengo registros* en lugar de *estoy mirando en el sitio equivocado*. El registro del sistema hoy es el journal, y no se abre en un editor, se consulta.

Proxmox lleva un segundo registro, y responde a otra pregunta

Aparte del journal del sistema, Proxmox VE lleva su propio registro de tareas. Toda operación iniciada desde la interfaz web o la API se convierte en una tarea con identificador, hora de inicio, hora de fin y estado final, y junto a los archivos de cada tarea hay un archivo índice. En un único host de laboratorio ese índice tenía 283 líneas, con unos 960 archivos de tareas detrás.

Los dos registros son buenos en cosas distintas. El journal es bueno en "qué estaba haciendo el sistema". El registro de tareas es bueno en "quién pidió qué, y si llegó a terminar". Cuando una máquina virtual tiene una instantánea que nadie recuerda haber tomado, o aparece un cambio sin autor, el registro de tareas suele responder antes que el journal, porque es una lista de intenciones y no un flujo de eventos.

Decida el techo antes de necesitar el historial

Por defecto el límite del journal se expresa como porción del sistema de archivos y no como duración. En el host medido arriba no había límite explícito y el journal había crecido hasta unos 276 MB.

Dos números conviene conocerlos de antemano: cuánto espacio puede ocupar el journal, y hasta dónde llega eso realmente en esa máquina. El orden importa, y es el mismo que con las métricas. Decida hasta dónde necesita ver hacia atrás, y luego elija el ajuste que llegue hasta allí. Descubrir la respuesta en mitad del incidente es descubrir que la respuesta es "no lo bastante atrás".

Qué hace Atlas, y qué no

Atlas no sustituye al journal ni intenta leer sus registros por usted. Aquí no hay búsqueda de registros, y decir lo contrario le prepararía una mala mañana.

Lo que Atlas lleva es la primera mitad: el resumen diario informa de un reinicio no planificado como hecho, con la máquina y la hora, para que la pregunta al menos se formule. La lectura sigue siendo suya y la respuesta sigue viviendo en el journal.

En eso consiste todo. La peor versión de anoche no es el reinicio que investigó con el archivo equivocado abierto. Es el reinicio que nadie notó, porque un registro que nunca se abre no responde a nada.

Fuentes

La documentación oficial de Proxmox. En inglés, y en este asunto es ella la que tiene la última palabra.

Entradas relacionadas

¿Cómo se ve esto dentro de Atlas?

Ir a la página del producto