Encaminhando o rsyslog para syslog-ng, com FQDN e separação de instalação

4

Estou tentando configurar meus clientes rsyslog para encaminhar mensagens para meus sistemas de repositório de logs syslog-ng. O encaminhamento de mensagens funciona "fora da caixa", mas meus clientes estão registrando nomes abreviados, não FQDNs. Como resultado, as mensagens no repositório do syslog também usam nomes abreviados, o que é um problema porque não é possível determinar de qual sistema a mensagem se originou facilmente. Meus clientes recebem seus nomes através de DHCP / DNS.

Eu tentei várias soluções tentando fazer isso funcionar, mas sem sucesso. Estou usando o rsyslog 4.6.2 e o syslog-ng 3.2.5.

Eu tentei definir $PreserveFQDN on como a primeira diretiva em /etc/rsyslog.conf (e reiniciar o rsyslog, é claro). Parece não ter efeito.

hostname --fqdn no cliente retorna o FQDN correto, portanto, o problema não é se o sistema pode realmente descobrir seu próprio FQDN.

$LocalHostName <fqdn> parecia promissor, mas esta diretiva não está disponível na minha versão do rsyslog (Disponível desde 4.7.4+, 5.7.3+, 6.1.3+). A atualização não é uma opção no momento.

Configurar o servidor syslog-ng para preencher nomes com base em pesquisas inversas via DNS não é uma opção. Existem complexidades com DNS reverso e a nuvem pública.

Especificar para o encaminhador usar um modelo personalizado parece ser uma opção viável à primeira vista. Eu posso especificar o seguinte, o que faz com que o log local comece a usar o FQDN no repositório syslog-ng.

$template MyTemplate, "%timestamp% <FQDN> %syslogtag%%msg%"
$ActionForwardDefaultTemplate MyTemplate

No entanto, quando eu coloco isso no lugar, o syslog-ng parece ser incapaz de categorizar mensagens por facilidade ou prioridade. As mensagens chegam como FQDN, mas tudo é colocado em user.log. Quando não uso o modelo personalizado, as mensagens são devidamente categorizadas em facilidade e prioridade, mas com o nome abreviado.

Portanto, em resumo, se eu enganar manualmente o rsyslog para incluir o FQDN, a prioridade e a facilidade serão perdidos em detalhes para o syslog-ng. Como posso obter o rsyslog para fazer o registro em log do FQDN que funciona corretamente indo para um repositório do syslog-ng?

config do cliente rsyslog:

$ModLoad imuxsock.so    # provides support for local system logging (e.g. via logger command)
$ModLoad imklog.so      # provides kernel logging support (previously done by rklogd)
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
*.info;mail.none;authpriv.none;cron.none                /var/log/messages
authpriv.*                                              /var/log/secure
mail.*                                                  -/var/log/maillog
cron.*                                                  /var/log/cron
*.emerg                                                 *
uucp,news.crit                                          /var/log/spooler
local7.*                                                /var/log/boot.log
$WorkDirectory /var/spool/rsyslog # where to place spool files
$ActionQueueFileName fwdRule1 # unique name prefix for spool files
$ActionQueueMaxDiskSpace 1g   # 1gb space limit (use as much as possible)
$ActionQueueSaveOnShutdown on # save messages to disk on shutdown
$ActionQueueType LinkedList   # run asynchronously
$ActionResumeRetryCount -1    # infinite retries if host is down
*.* @syslog-ng1.example.com
*.* @syslog-ng2.example.com

configuração do syslog-ng (abreviada por brevidade):

options {
    flush_lines (0);
    time_reopen (10);
    log_fifo_size (1000);
    long_hostnames (off);
    use_dns (no);
    use_fqdn (yes);
    create_dirs (no);
    keep_hostname (yes);
};
source src {
    unix-stream("/dev/log");
    internal();
    udp(ip(0.0.0.0) port(514));
};
destination per_host_destination {
file( "/var/log/syslog-ng/devices/$HOST/$FACILITY.log" owner("root") group("root")  perm(0644) dir_owner(root) dir_group(root) dir_perm(0775) create_dirs(yes));
};
log { source(src); destination(per_facility_destination); };
    
por Joshua Miller 30.10.2013 / 15:31

1 resposta

2

Ok, achei um jeito. Acontece que o $ ActionForwardDefaultTemplate, por padrão, está definido como:

$ActionForwardDefaultTemplate RSYSLOG_ForwardFormat

Por esta documentação do rsyslog , o RSYSLOG_ForwardFormat é especificamente usado para manter a interoperabilidade entre diferentes syslogs. No shocker, então, se você modificar este modelo Forward como descrevi originalmente, alguma funcionalidade para outros syslogs será quebrada:

$template MyTemplate, "%timestamp% <FQDN> %syslogtag%%msg%"
$ActionForwardDefaultTemplate MyTemplate

A solução que encontrei foi desenterrar o modelo de back-end que o RSYSLOG_ForwardFormat usa e imitá-lo. Depois de vasculhar a fonte, acabei descobrindo que RSYSLOG_ForwardFormat é realmente isso:

"<%PRI%>%TIMESTAMP% %HOSTNAME% %syslogtag:1:32%%msg:::sp-if-no-1st-sp%%msg%"

Portanto, se eu criar um modelo personalizado com quase o mesmo conteúdo, mas substituir o meu FQDN no lugar da macro %HOSTNAME% , a separação do syslog-ng funciona corretamente e o sistema registra com o FQDN:

$template MyForwardTemplate, "<%PRI%>%TIMESTAMP% <fqdn> %syslogtag:1:32%%msg:::sp-if-no-1st-sp%%msg%"
$ActionForwardDefaultTemplate MyForwardTemplate
    
por 31.10.2013 / 17:25