Encaminhamento do rsyslog para o syslog-ng sobre o TCP não está funcionando (embora os pacotes estejam atingindo o servidor)

Question

Usamos o syslog-ng em nosso servidor syslog central (syslog-ng-2.1.4-9.el5 no CentOS 5.9). Estávamos alegremente enviando logs usando syslogd e rsyslog de uma mistura de hosts Linux e Solaris sobre UDP até ontem, quando finalmente ficou claro para mim que estamos perdendo um número significativo de entradas (sim, eu deveria ter atendido a todos os avisos).

Estou tentando mudar para o uso do TCP. Eu estou interessado (no momento) em ficar com o syslog-ng no centro e o rsyslog nos remetentes, e meu entendimento é que isso deve funcionar. O servidor syslog central possui múltiplas interfaces virtuais que são usadas para segmentar conjuntos de logs por função (é por isso que as instruções udp () e tcp () especificam o endereço IP ao qual se ligar).

Eu ativei os listeners TCP no syslog-ng end (veja extração do arquivo de configuração abaixo) - netstat -l mostra listeners na porta 514. Como um teste eu mudei a cláusula forwarding em um host (CentOS 6.4 com rsyslog-5.8. 10-6.el6.x86_64) de @unixlog para @@ unixlog. Eu vejo os pacotes chegando no servidor central e os pacotes voltando (olhando com o tcpdump no unixlog), então acho que eliminei problemas com o iptables, mas nada aparece no arquivo de saída. Eu apenas tentei desligar o iptables por um tempo para verificar isso - a mesma coisa.

Eu não tentei ativar a depuração para o syslog-ng porque este é um servidor ocupado - minha próxima etapa é provavelmente configurar um servidor syslog-ng de teste e apontar um único host para ele. Antes de fazer isso, há mais alguma coisa que eu deveria estar olhando? Preciso alterar o formato das mensagens encaminhadas? Minha leitura dos docs do Syslog-ng 2.x sugere que isso funcione sem nenhuma alteração. Eu tentei mudar a opção de nível de compatibilidade que o rsyslog é chamado com. Foi inicialmente definido como 5, eu tentei 0 .. 4 e removendo o parâmetro completamente - sem diferença de comportamento.

Rsyslog.conf no remetente (com comentários e arquivos locais removidos)…

$ModLoad imuxsock
$ModLoad imklog
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
*.err;kern.debug;daemon.notice;mail.crit                @unixlog.ncl.ac.uk
local3.debug                                            @cmdloghost.ncl.ac.uk

Extraia do rsyslog.conf no unixlog

options {
  long_hostnames(off);
  sync(0);
  create_dirs(yes);
};

destination d_syslog {
  file("/var/log/incoming/syslogs/$HOST/syslog.$YEAR$MONTH$DAY.log");
};

# unixlog is 10.8.232.202
source unixlog_net { udp(ip(10.8.232.202)); tcp(ip(10.8.232.202)); };

log {
  source(unixlog_net);
  destination(d_syslog);
};

    

Answer 1

O problema era tcpwrappers, o que era óbvio quando eu configurava uma instância syslog-ng de teste e a executava com a saída de depuração ativada. Adicionando a seguinte cláusula para /etc/hosts.allow fez o truque

syslog-ng: 10.0.0.0/255.0.0.0

Também percebi que não lidamos com as mensagens internas do syslog-ng (o que pode ter nos dito qual era o problema). Agora adicionamos as seguintes linhas para fazer isso ...

# Deal with syslog-ng's own messages
source s_internal { internal(); };
destination d_internal {file("/var/log/syslog-ng.log"); };
log { source(s_internal); destination(d_internal); };