rsyslog con logrotate: ricarica rsyslog vs copytruncate

Sto lavorando su Ubuntu 14 con l'utility rsyslog e logrotate predefinita.

Nella /etc/logrotate.d/rsyslogconfigurazione di logrotate rsyslog predefinita vedo quanto segue:

/var/log/syslog
{
        rotate 7
        daily
        missingok
        notifempty
        delaycompress
        compress
        postrotate
                reload rsyslog >/dev/null 2>&1 || true
        endscript
}

Da quello che ho capito, si consiglia di utilizzare copytruncate in tutti gli scenari di logrotate, poiché non sposta il registro corrente, ma piuttosto tronca il registro in modo che qualsiasi processo con un gestore di file aperto sarà in grado di continuare a scrivere su di esso.

Quindi, come mai la configurazione predefinita usando invece la funzione di ricarica di rsyslog?

Per rispondere alla tua domanda, devi prima capire il diverso compromesso di ricarica e copiatroncata:

• ricaricare : il vecchio file di registro viene rinominato e il processo di scrittura in quel registro viene notificato (tramite segnale Unix) per ricreare il suo file di registro. Questo è il metodo overhead più veloce / più basso: le operazioni di rinomina / spostamento sono molto veloci e hanno un tempo di esecuzione costante. Inoltre, si tratta di un'operazione quasi atomica: ciò significa che (quasi) nessuna voce di registro andrà persa durante lo spostamento / ricarica. D'altra parte, è necessario un processo in grado di ricaricare e riaprire il suo file di registro. Rsyslog è un tale processo, quindi la configurazione di logrotate predefinita utilizza il metodo di ricaricamento. L'uso di questa modalità con rsyslog è fortemente raccomandato da rsyslog a monte.
• copytruncate : il vecchio file di registro viene copiato in un file di archivio, quindi viene troncato per "eliminare" le vecchie righe di registro. Mentre l'operazione di troncamento è molto veloce, la copia può essere piuttosto lunga (a seconda della dimensione del file di registro). Inoltre, è possibile perdere alcune voci del registro durante l'intervallo tra l'operazione di copia (ricordare, può essere lento) e il troncamento. Per questi motivi, copytruncate non viene utilizzato per impostazione predefinita per i servizi in grado di ricaricare e ricreare i propri file di registro. D'altra parte, se un server non è in grado di ricaricare / ricreare i file di registro, copytruncate è la scommessa più sicura. In altre parole, non richiede alcun supporto a livello di servizio. Il progetto upstream di rsyslog sconsiglia vivamente di utilizzare questa modalità.

Parlando come autore di rsyslog, copytruncate è in realtà una scelta molto, molto, molto brutta. È intrinsecamente audace e usarlo è quasi una garanzia che perderai i dati di registro. Più frequentemente viene scritto il file, più perderai. E questo non fa solo parte dell'ultima riga, ma può essere di diverse centinaia, a seconda del momento esatto e dello stato del sistema nel momento in cui avviene la rotazione.

Quando il file viene spostato e viene creato un nuovo inode (file), rsyslog tiene traccia del file precedente e completa l'elaborazione. Quindi non hai alcuna perdita in questo caso. Garantito (tranne se si smonta il file system ...).

Su "reopenOnTruncate": personalmente ho visto reopenOnTruncate essere audace anche sotto altri aspetti, in particolare con NFS e simili. Qualche tempo fa ho completamente rimosso quella funzionalità, ma in seguito sono stato persuaso a fondere funzionalità simili. Rimarrà "sperimentale" molto probabilmente per sempre, poiché so davvero che le persone si trovano in difficoltà su sistemi molto carichi. "copytruncate" non è semplicemente una modalità decente per lavorare con i file di registro.

Attualmente lavoro sul refactoring dell'imfile (ETA 8.34 o 8.35). La versione refactored sarà probabilmente in grado di impedire il re-invio accidentale a causa della corsa API, ma non può nemmeno proteggersi dalla perdita di dati, poiché ciò è concettualmente impossibile.

Questo dipende completamente da come il processo sta scrivendo i registri.
copytruncatefunziona solo se i messaggi di registro vengono aggiunti al file (ad es whatever >> logfile.
e non quando reindirizza l'output (ad es whatever > logfile.).

Dalla versione 8.16 rsyslog ha l'opzione imfile reopenOnTruncateche gestisce il problema copytruncte.

Per rsyslog in particolare, probabilmente ha più senso lasciare le cose come sono.

Il motivo di base è che rsyslog ha code interne che può usare nei casi in cui il suo handle di output diventa non disponibile.

Il ricaricamento a) farà sì che rsyslog ricrea il proprio file di registro eb) causerà lo svuotamento di tutti gli eventi in coda nel file al momento della creazione.

Potrebbe trattarsi di copytruncate non fa male (anche se sarei preoccupato per il troncamento di righe parzialmente scritte), ma tenderei a pensare che copiare / cancellare / ricaricare sia "più sicuro" dal punto di vista dell'integrità.

Come menzionato da @ faker , poiché rsyslog è in grado di gestire la situazione in cui il suo file non è disponibile, non esiste un motivo convincente per utilizzare copytruncate.

E come menzionato da @ SelivanovPavel , rsyslog in realtà richiede una configurazione specifica per gestire correttamente il troncamento della copia.

Quindi, se non altro perché l'utilizzo reloaddell'approccio richiede una minore deviazione dalla configurazione predefinita, lo terrei.