Rsyslog interrompe l'invio di dati al server remoto dopo la rotazione del registro


9

Nella mia configurazione, ho rsyslog che si occupa delle seguenti modifiche /home/user/my_app/shared/log/unicorn.stderr.logall'utilizzo imfile. Il contenuto viene inviato a un altro server di registrazione remoto tramite TCP.

Quando il file di registro ruota, rsyslog interrompe l'invio di dati al server remoto.

Ho provato a ricaricare rsyslog, inviare un segnale HUP e riavviarlo del tutto, ma nulla ha funzionato.

Gli unici modi in cui ho scoperto che funzionava davvero erano sporchi:

  • interrompere il servizio, eliminare i file delle statistiche rsyslog e riavviare rsyslog. Tutto ciò in un gancio postrotate nel mio file logrotate.
  • kill -9 rsyslog e ricominciare da capo.

C'è un modo corretto per farlo senza toccare gli interni di rsyslog?

File Rsyslog

$ ModLoad immark
$ ModLoad imudp
$ ModLoad imtcp
$ ModLoad imuxsock
$ ModLoad imklog
$ ModLoad imfile

$ template WithoutTimeFormat, "[ambiente] [% syslogtag%] -% msg%"

$ WorkDirectory / var / spool / rsyslog

$ InputFileName /home/user/my_app/shared/log/unicorn.stderr.log
$ InputFileTag unicorn-stderr
$ InputFileStateFile stat-unicorn-stderr
$ InputFileSeverity informazioni
$ InputFileFacility local8
$ InputFilePollInterval 1
$ InputFilePersistStateInterval 1
$ InputRunFileMonitor

# Inoltra al server remoto
se $ syslogtag contiene 'apache-' allora @@ my_server: 5000; WithoutTimeFormat
: syslogtag, contiene, "apache-" ~

*. * @@ my_server: 5000; SyslFormat

Logrotate file

/home/user/my_app/shared/log/*.log {
  quotidiano
  missingok
  dateext
  ruota di 30
  comprimere
  notifempty
  estensione gz
  copytruncate
  crea 640 utenti utente
  sharedscripts
  post-rotazione
    (ferma rsyslog && rm / var / spool / rsyslog / stat- * && avvia rsyslog 2> & 1) || vero
  endscript
}

Cordiali saluti, il file è leggibile per l'utente rsyslog, il mio server è raggiungibile e altri file di registro che non ruotano sullo stesso ciclo continuano a essere tracciati correttamente.

Sto eseguendo Ubuntu 12.04.

Risposte:


8

Il problema in realtà proveniva da logrotate.

Fondamentalmente con la mia configurazione, eseguendo unicorno, non ho bisogno di usare la copytruncatedirettiva. (che è ciò che causa problemi qui)

USR1: riapre tutti i registri di proprietà del processo di lavoro. Vedi Unicorn :: Util.reopen_logs per quello che è considerato un registro. I file di registro non vengono riaperti fino al termine dell'elaborazione della richiesta corrente, quindi più righe di registro per una richiesta (come eseguita da Rails) non verranno suddivise su più registri.

Questo ha iniziato a funzionare correttamente dopo l'aggiornamento a questa configurazione:

/home/user/my_app/shared/log/*.log {
  daily
  missingok
  dateext
  rotate 30
  compress
  notifempty
  extension gz
  create 640 user user
  sharedscripts

  post-rotate
    # Telling Unicorn to reload files
    test -s /home/user/my_app/shared/pids/unicorn.pid && kill -USR1 "$(cat /home/user/my_app/shared/pids/unicorn.pid)"

    # Reloading rsyslog telling it that files have been rotated
    reload rsyslog 2>&1 || true
  endscript
}

Se queste sono copie dirette del tuo file, penso che il tuo problema fosse in realtà quello che stavi usando post-rotate(cosa che non è una cosa) invece di postrotate, perché quello script logrotate originale che avresti dovuto avere avrebbe dovuto funzionare bene con rsyslog (se lo script postrotate fosse in esecuzione ) ...?
mltsy,

2
Non ricordo quando, ma sono cambiato post-rotateper lastaction. Il tuo commento è ancora molto sensato e potrebbe aver risolto il mio problema in quel momento :). Per la cronaca, eviterò comunque di utilizzarlo copytruncatein futuro perché è lento e gioca con gli handle di file.
Vincent B.

2

Il file logrotate contiene una voce per /home/user/shared/log/*.log, che non corrisponde al file di log in /home/user/my_app/shared/log/unicorn.stderr.log. Devi aggiungere una voce logrotate per quella directory e assicurarti che contenga copytruncate- così com'è, rsyslog sta rinominando il file corrente e ne sta creando uno nuovo, e imfile continua a seguire il filehandle del file ora rinominato.


Spiacenti, il nome file è solo un errore di battitura. Tuttavia, copytruncate potrebbe essere un buon punto. Vorrei solo esaminare quello :).
Vincent B.,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.