Stanotte è successo qualcosa: dove sta davvero la registrazione

La macchina ha riavviato durante la notte e nessuno gliel'ha chiesto. Tutto funziona di nuovo, niente è visibilmente rotto, e l'unica frase onesta possibile è questa: è successo qualcosa.

Il monitoraggio ha tre registrazioni e rispondono a tre domande diverse. Un avviso dice che è successo qualcosa. Una metrica dice che forma aveva. Un log dice perché. Questo testo parla della terza, e di quel fatto scomodo: il log che copre il minuto interessante è quello che più probabilmente non c'è più.

La prima domanda è più piccola di quanto sembri

Prima di ogni teoria sull'hardware, fatevi la domanda meno costosa: è stata spenta, o è morta?

Basta una riga per rispondere. Uno spegnimento pulito lascia una firma alla fine del log dell'avvio precedente: il servizio di registrazione annota che gli è stato chiesto di fermarsi, poi annota che si è fermato. Una macchina rimasta senza corrente non lascia alcuna fine. La registrazione si interrompe semplicemente a metà di un'attività ordinaria.

Questa sola distinzione taglia in due l'indagine. Una fine pulita significa che qualcosa ha deciso di riavviare, quindi cercate chi l'ha chiesto: un aggiornamento, un cane da guardia, un lavoro pianificato, una persona. Nessuna fine significa che la macchina è stata interrotta, quindi guardate alimentazione, calore, memoria e lo storage sottostante.

Ma solo se l'avvio precedente esiste ancora

Ecco la trappola. Il journal conserva la cronologia in modo permanente solo se sul disco esiste una directory precisa. Se manca, il journal vive in memoria, e ogni riavvio cancella esattamente la prova che siete venuti a cercare. Nessun errore, nessun avviso; chiedete l'avvio precedente e vi si risponde che non esiste.

Conviene verificarlo in un pomeriggio tranquillo, non la mattina in cui serve. È una directory, ed è quella che separa l'avere una registrazione dal credere di averla.

Ha anche la stessa forma di una trappola che vale la pena nominare due volte: un registratore che condivide il destino di ciò che registra. Il grafico che volete di più è quello che ha smesso di essere scritto proprio quando la cosa è diventata interessante; e il log che volete di più appartiene all'avvio che non esiste più.

Il file che mezza internet vi dice di leggere potrebbe non esserci

Misurato su un'installazione attuale, Proxmox VE 9.2.6 su Debian 13.6: il classico demone di registrazione di sistema non è installato, e /var/log/syslog non esiste.

Pesa più di quanto sembri. Gran parte dei consigli di risoluzione dei problemi scritti negli ultimi quindici anni si apre con "guarda /var/log/syslog". Su una macchina attuale quel comando non restituisce nulla, e per chi è sotto pressione il risultato si legge come *non ho log* invece che *sto guardando nel posto sbagliato*. La registrazione di sistema oggi è il journal, e non si apre in un editor, si interroga.

Proxmox tiene una seconda registrazione, e risponde a un'altra domanda

Separatamente dal journal di sistema, Proxmox VE tiene il proprio log delle attività. Ogni operazione avviata dall'interfaccia web o dall'API diventa un'attività con un identificatore, un orario di inizio, uno di fine e uno stato finale, e accanto ai singoli file delle attività c'è un file indice. Su un singolo host di laboratorio quell'indice conteneva 283 righe, con circa 960 file di attività dietro.

Le due registrazioni sono brave in cose diverse. Il journal è bravo su "cosa stava facendo il sistema". Il log delle attività è bravo su "chi ha chiesto cosa, ed è arrivato in fondo". Quando una macchina virtuale ha uno snapshot che nessuno ricorda di aver preso, o una modifica compare senza autore, il log delle attività di solito risponde prima del journal, perché è un elenco di intenzioni e non un flusso di eventi.

Decidete il tetto prima di avere bisogno della cronologia

Per impostazione predefinita il limite del journal è espresso come quota del filesystem e non come durata. Sull'host misurato sopra non era impostato alcun limite esplicito e il journal era cresciuto a circa 276 MB.

Due numeri vale la pena conoscerli in anticipo: quanto spazio può occupare il journal, e quanto indietro questo arriva davvero su quella macchina. L'ordine conta, ed è lo stesso che vale per le metriche. Decidete quanto indietro dovete vedere, poi scegliete l'impostazione che arriva fin lì. Scoprire la risposta durante l'incidente significa scoprire che la risposta è "non abbastanza indietro".

Cosa fa Atlas, e cosa non fa

Atlas non sostituisce il journal e non prova a leggere i log al posto vostro. Qui non c'è ricerca nei log, e dire il contrario vi preparerebbe una brutta mattinata.

Quello che Atlas porta è la prima metà: il riepilogo giornaliero segnala un riavvio non pianificato come fatto, con macchina e orario, così che la domanda venga almeno posta. La lettura resta vostra e la risposta abita ancora nel journal.

È tutto qui il punto. La versione peggiore di stanotte non è il riavvio che avete indagato con il file sbagliato aperto. È il riavvio che nessuno ha notato, perché una registrazione che nessuno apre mai non risponde a niente.