Reconfigurar facilidade / severidade no rsyslog v7 antes de enviar para um coletor remoto

Question

Eu tenho uma máquina "A" com um rsyslogd local e uma máquina coletor remota "B" em outro lugar ouvindo com seu próprio daemon syslog e mecanismo de processamento de log. Tudo funciona muito bem ... exceto que há um processo em A que registra em local0.notice, que é algo que o mecanismo de B não pode manipular.

O que eu quero fazer é reescrever local0.notice para local5.info antes que o evento seja enviado para B. Infelizmente eu não posso mudar B e não posso mudar a maneira como o processo é feito. posso atualizar o rsyslogd em A da v7.6 para v8 (que parece ter alguns recursos muito úteis, como o mmexternal, o que pode ter ajudado).

Acho que devo estar perdendo algo óbvio, não posso ser a primeira pessoa a precisar desse tipo de recurso. Basicamente, tudo se resume a encontrar uma maneira de passar pelo rsyslog duas vezes com um filtro no meio: uma vez que o processo registra, através do filtro para alterar o prio, e depois novamente para encaminhá-lo.

O que eu tentei:

• configurando o rsyslog para registrar local0.notice em um arquivo e, em seguida, lendo esse arquivo com uma diretiva imfile que o marca e configura o novo fac / sev, seguido por uma instrução if que procura a tag e chama uma ação omfwd. Eu pensei que talvez eu pudesse persuadir o rsyslog a escrever um arquivo no prio certo e então ter o rsyslog voltando e naturalmente pegá-lo. Infelizmente, não há dados.
• carregando um módulo omprog que chama logger -p local5.info se syslogfacility-text == 'local0', parando de processar lá ... e então tendo outro elemento de configuração checando por syslogfacility-text == 'local5' e se sim chamando uma ação omfwd. Estranhamente isso funciona, mas não atrapalha as mensagens originais, agora eu só recebo dois conjuntos de logs sendo encaminhados para B, um local0 e um local5.

Existe alguma solução por aí?

    

Answer 1

É mais um hack do que uma solução, mas não consegui encontrar uma maneira "limpa" para resolver o problema:

A carga útil do pacote UDP para mensagens local0.notice sempre será iniciada com um < 133 > valor (16 * 8 + 5 de acordo com rfc3164), enquanto um local5.info mapeia para < 174 > (21 * 8 + 6).

Você pode usar nfqueue + scapy em A para reescrever todas as ocorrências de < 133 > para < 174 > enquanto envia os pacotes no fio e B receberá e registrará mensagens local5.info em vez de local0.notice.

Todos os outros pacotes UDP do syslog não serão afetados e serão registrados normalmente.

Exemplo simples: link

O RFC: link

Script para valores tabulares de PRI: link

    

Answer 2

Tendo trabalhado com o syslog-ng, acredito que você pode fazer o que estiver procurando usando-o como seu daemon syslog principal no "Host A" e encaminhar sua mensagem manipulada para o "Host B". No entanto, como é necessário reescrever os sinalizadores de mensagem "codificados permanentemente", você precisará desabilitar a análise de campo do próprio syslog-ng, para poder aplicar uma expressão regular à mensagem bruta de syslog (protocolo).

Você encontrará o Syslog-NG com uma abordagem muito poderosa de manipulação de mensagens, em geral, lendo link

Depois de ler isso, você verá que, infelizmente, provavelmente precisará desabilitar a análise da mensagem syslog do próprio Syslog-NG e trabalhar com os dados brutos, configurando a seguinte opção no syslog-ng.conf:

flags(no-parse)

Isso pode causar problemas. Por exemplo, você não receberá mais mensagens syslog de várias linhas como "uma mensagem", porque o syslog-ng precisa analisar a mensagem para entender que é uma única mensagem.

Referência: link