Da dove viene la crescita del disco di un server VPN e come limitarla

Il tunnel smette di accettare connessioni, il servizio si riavvia due volte e poi non compare nulla nel suo log. Quel silenzio è l’indizio, perché è il log ad aver riempito il disco e il demone non ha dove scrivere l’errore che state aspettando. Qualsiasi servizio di lunga durata può arrivare a quello stato, e cancellare una directory chiamata logs raramente lo risolve. La soluzione duratura è sapere quale archivio è cresciuto, chi possiede la sua politica di conservazione e se lo scrittore ha davvero rilasciato lo spazio.

Trovate l’archivio cresciuto e il ritmo con cui è cresciuto

Iniziate da due numeri facili da dimenticare: blocchi liberi e inode liberi. Un filesystem può riportare molto spazio e rifiutare comunque una scrittura perché non ha più inode, cosa che accade quando un servizio crea un file per sessione. Chiedete entrambe le letture sullo stesso volume, perché le risposte possono contraddirsi lo stesso pomeriggio. Fatelo mentre l’host è sano, così che i numeri descrivano il funzionamento normale e non un guasto.

df -h /var
df -i /var

Poi attribuite la crescita a un proprietario. La cifra d’uso del journal copre solo il journal e non vedrà mai un demone che scrive in un percorso del suo file di configurazione.

journalctl --disk-usage

La crescita nel tempo dice più di qualsiasi lettura singola. Un livello di debug lasciato attivo, un ciclo di tentativi che registra ogni tentativo o un file di cattura che nessuno ha fermato: ciascuno può sembrare normale in un momento e allarmante un’ora dopo. Prendete una lettura, aspettate un periodo intenso, prendetene un’altra e dividete per l’intervallo. Un tasso che sapete enunciare trasforma la capacità in una decisione invece che in un incendio.

Che cosa fa la rotazione a un file aperto

Un file di log è un nome che punta a un inode, e lo spazio torna solo quando l’ultimo descrittore aperto viene chiuso. Rinominate il file e lo scrittore continua a riempire lo stesso inode; cancellatelo e lo scrittore continua a riempire un inode senza alcun nome. È per questo che «ho cancellato il file e il disco è rimasto pieno» descrive descrittori di file e non un filesystem guasto. Riavviare lo scrittore, o scegliere una modalità di rotazione che riapra il file, è ciò che restituisce davvero i blocchi.

lsof +L1 | head

La politica appartiene al componente che scrive il file. Il journal impone i propri limiti di archiviazione dal suo file di configurazione, mentre un servizio basato su file di solito si affida a logrotate, con una regola di creazione e un segnale di riapertura oppure con una modalità di troncamento sul posto quando lo scrittore non può riaprire. Confermate la decisione senza cambiare nulla prima:

logrotate -d /etc/logrotate.conf

Dove va collocato il limite e quanto deve essere grande

Mettete il limite dove è configurato lo scrittore, non al punto di mount. Una quota sull’intero volume protegge l’host ma non dice quale servizio fallirà per primo, e uno script di pulizia globale tende a cancellare le prove che serviranno al prossimo incidente. Un limite del journal, un numero di rotazioni con una dimensione massima e la conservazione a livello di applicazione limitano ciascuno un produttore. Insieme limitano il totale; da soli, ciascuno è una supposizione.

Dimensionate quel limite sulla base della conservazione che potete difendere, non dello spazio libero disponibile. Se una revisione richiede una settimana di tentativi di connessione, il journal deve tenere una settimana al ritmo più alto previsto, e quel ritmo è il numero misurato prima.

Il logging di debug è una modalità temporanea con un’ora di inizio registrata, non un piano di archiviazione. Tenete la questione della privacy dentro la stessa decisione, perché i log di connessione portano indirizzi e identificatori. Una conservazione più lunga è anche una scelta di trattamento dei dati e dovrebbe essere presa da chi conosce entrambi i vincoli.

Verificate il limite dopo un riavvio

Una modifica della conservazione che dura fino al riavvio successivo non è una modifica. Riavviate lo scrittore, confermate che il nuovo limite si applica e verificate che la rotazione funzioni ancora dopo. Per il journal, un riavvio e una lettura d’uso rispondono a entrambe le domande:

systemctl restart systemd-journald
journalctl --disk-usage

Per un servizio basato su file, eseguite il processo di rotazione una volta a mano e confermate che il file è stato sostituito e il descrittore riaperto. Uno scrittore che conserva il vecchio descrittore supera un controllo superficiale e fallisce la volta successiva in cui il volume si riempie. Osservate lo spazio libero durante il test, perché un file che si è ridotto mentre lo spazio non tornava significa che il vecchio inode è ancora trattenuto.

Confrontate la prossima lettura con questa

Tornate dopo una settimana e confrontate il tasso di crescita con quello registrato. Un tasso corrispondente significa che il limite tiene e che il carico è stabile; un tasso raddoppiato significa che qualcosa è cambiato, e la domanda utile è che cosa. Leggete prima il contenuto del log per gli errori ripetuti, perché un ciclo di tentativi è insieme sintomo e causa di volume. Poi controllate tutto ciò che è stato abilitato di recente, compresi i livelli di debug accesi durante un incidente e mai spenti.

Tenete i backup fuori dallo stesso volume, o accettate che un disco pieno si porti via il backup. Una copia scritta sull’host che protegge non è un piano di ripristino, e la sua conservazione ha bisogno di una risposta propria.

Scrivete che cosa viene conservato, dove, per quanto tempo e chi lo elimina. Quella frase è il risultato, ed è l’unica parte di questo lavoro che sopravvive al riavvio successivo.