Por que o syslogd não está reportando mensagens para o servidor remoto durante e logo depois da inicialização?

Question

Eu configurei rsyslog para enviar logs para um servidor de registro central como este:

*.* @@192.168.1.20
$ActionExecOnlyWhenPreviousIsSuspended on
& @@192.168.1.21
& /var/log/failover
$ActionExecOnlyWhenPreviousIsSuspended off

Funciona bem, exceto quando a máquina está inicializando. Quando a máquina virtual é iniciada e aproximadamente vinte segundos após o início da máquina, nenhuma mensagem é enviada para 192.168.1.20 ou 192.168.1.21. No entanto, /var/log/failover contém todas essas mensagens "perdidas".

Como teste, iniciei a máquina e inseri manualmente:

$ logger 1
$ logger 2
$ logger 3
...

O primeiro servidor de registro central contém apenas:

Nov 28 13:57:40 demo arsene: 10

O segundo servidor de log não contém mensagens da máquina demo .

Por fim, var/log/failover on demo machine contém:

Nov 28 13:57:10 demo rsyslogd: [origin software="rsyslogd" swVersion="7.4.4" x-pid="361" x-info="http://www.rsyslog.com"] start
Nov 28 13:57:10 demo rsyslogd: rsyslogd's groupid changed to 104
Nov 28 13:57:10 demo rsyslogd: rsyslogd's userid changed to 101
... # more than a hundred usual messages from the kernel
Nov 28 13:57:20 demo kernel: [   12.127981] random: nonblocking pool is initialized
Nov 28 13:57:21 demo arsene: 1
Nov 28 13:57:22 demo arsene: 2
Nov 28 13:57:23 demo arsene: 3
Nov 28 13:57:25 demo arsene: 4
Nov 28 13:57:27 demo arsene: 5
Nov 28 13:57:28 demo arsene: 6
Nov 28 13:57:30 demo arsene: 7
Nov 28 13:57:32 demo arsene: 8
Nov 28 13:57:37 demo arsene: 9

Encontrei este problema para as máquinas virtuais Ubuntu e Debian.

Notas adicionais:

1. A conectividade de rede parece bem. Se eu tentar ping 192.168.1.20 e curl google.com durante o período em que as mensagens de log não são enviadas para o servidor de log, tanto ping quanto curl serão bem-sucedidas.

2. Desativar o firewall do servidor de registro não tem efeito.

3. A execução de tcpdump mostra que nada está sendo enviado para o servidor de logs durante o período de vinte segundos.

4. Outras máquinas Ubuntu na rede (que foram implementadas usando uma abordagem muito diferente) relatam seus logs para o servidor de log bem, inclusive durante a inicialização.

5. Ao comparar as máquinas defeituosas com as corretas, notei uma incompatibilidade de versões (7 x 8) para rsyslogd . A atualização de rsyslogd em máquinas defeituosas para a versão 8.14.0 não corrigiu o problema, mas agora vejo a seguinte mensagem um pouco após o relatório de log começa a funcionar:

   Nov 29 02:18:39 demo rsyslogd-2359: action 'action 11' resumed (module 'builtin:omfwd') [v8.14.0 try http://www.rsyslog.com/e/2359 ]
   

6. diff mostra que os arquivos /etc/rsyslog.conf e /etc/rsyslog.d/*.conf são exatamente os mesmos entre as novas máquinas defeituosas e as antigas que funcionam.

7. Um apt-get update , apt-get upgrade e até apt-get dist-upgrade não corrigiram o problema.

Answer 1

Como disse @ThomasDickey, a rede pode não ser completamente iniciada quando os programas da área de usuário começam a ser executados. Muitos switches ethernet empresariais não aceitam pacotes para alguns segundos depois que uma interface aparece, enquanto eles tentam negociar as configurações da árvore de abrangência.

O rsyslog tem uma configuração actionresumeinterval que é 30 segundos por padrão. Se você definir um valor menor antes de quaisquer diretivas que usem conexões TCP, isso aumentará a taxa de repetição e as conexões deverão ser concluídas mais rapidamente.

Existem também opções adicionais que você pode definir para garantir que as mensagens antigas sejam não enviada imediatamente é entregue assim que a conexão estiver pronta. Por exemplo, você pode usar as opções semelhantes a :

$ActionResumeInterval 5
$ActionQueueType disk
$WorkDirectory /var/spool/rsyslog
$ActionQueueFilename actionRq
$ActionQueueMaxDiskSpace 1m
$ActionQueueSize 4000
$ActionQueueTimeoutEnqueue    0
$ActionResumeRetryCount -1

    

Answer 2

Provavelmente, a rede não iniciou completamente durante esses 20 segundos. Até que isso aconteça, rsyslog não tem ninguém com quem conversar, então é escrito localmente.