Evitando perda de linha múltipla ao armazenar mensagens syslog em um banco de dados Postgres

Question

Eu tenho um aplicativo que cria relatórios centralizados usando o syslog e os armazeno em um banco de dados do Postgres para uso personalizado.

O banco de dados tem um formato específico (dado que os dados que estou centralizando estão em uma espécie de csv, cada coluna com um significado específico). Até aqui, tudo bem, os dados estão corretamente inseridos no banco de dados, no formato correto.

Se uma mensagem mal formatada chegar ao syslog (por exemplo, com texto em vez de um int), recebo um erro de inserção porque o tipo é inválido, o que é esperado ... MAS as próximas mensagens do lote são também caiu silenciosamente (acredito que seja porque o insert em transacional)

Sep 2 16:10:45 my-computer postgres[7642]: [2-2] 2011-09-02 16:10:45 CEST STATEMENT: insert into RudderSysEvents (executionDate, nodeId, configurationRuleId, policyInstanceId, serial, Component, KeyValue, executionTimeStamp, eventType, msg, Policy) values ('2011-09-02T16:10:45.592739+02:00','bla', '' , '', '', '', '', '', '', '', 'sdfsfsf' ) Sep 2 16:10:45 nicolas-laptop postgres[7643]: [2-1] 2011-09-02 16:10:45 CEST ERROR: invalid input syntax for integer: "" at character 224

Minha pergunta é: como posso evitar isso?

Estou pensando nessas soluções:

• Tentando tornar a inserção não transacional no lado do rsyslog ou fazer transações de uma linha

  $ActionQueueSize 1
  $ActionQueueType Direct
  $MainMsgQueueSize 1
  $MainMsgQueueType Direct
  

  Mas não funcionou (e eu suspeito que seja um assassino de performance)

• Verifique com regexp o conteúdo dos campos antes de inseri-los

Bem, é uma tarefa difícil, especialmente porque estou verificando por $ programname e $ msg, não consigo usar o regexp

    if $programname startswith 'rudder' and $msg startswith '  R: @@' then

• Relaxando restrições no banco de dados, e elas têm um acionador copiando dados válidos em outra tabela ou um programa analisando esse conteúdo e inserindo linhas relevantes em uma nova tabela.

Bem, não estou muito interessado nessa solução

Ah, e eu estou usando o rsyslog 4.6.4-2

Obrigado!

Editar: Por fim, contornei essa solução filtrando a mensagem com uma expressão regular bastante complexa

:msg, ereregex, "R: @@[a-zA-Z0-9\-]+?@@[a-zA-Z0-9_\-]{1,64}?@@[a-zA-Z0-9\-]+@@[a-zA-Z0-9\-]+?@@[0-9]+?@@[a-zA-Z0-9\-]+?@@[a-zA-Z0-9\-]+?@@[0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2}[+-][0-9]{2}:[0-9]{2}##[a-zA-Z0-9\-]+?@#.*"  :ompgsql:localhost,rudder,rudder,Normation;RudderDbLinuxReportFormat

Isso não é realmente fácil de manter, mas funciona e não quebrou desde então. Obrigado por sua sugestão snap , examinarei o uso de um procedimento armazenado em um futuro não muito distante.

    

Answer 1

Por fim, contornei essa solução filtrando a mensagem com uma expressão regular bastante complexa

:msg, ereregex, "R: @@[a-zA-Z0-9\-]+?@@[a-zA-Z0-9_\-]{1,64}?@@[a-zA-Z0-9\-]+@@[a-zA-Z0-9\-]+?@@[0-9]+?@@[a-zA-Z0-9\-]+?@@[a-zA-Z0-9\-]+?@@[0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2}[+-][0-9]{2}:[0-9]{2}##[a-zA-Z0-9\-]+?@#.*"  :ompgsql:localhost,rudder,rudder,Normation;RudderDbLinuxReportFormat

Isso não é realmente fácil de manter, mas funciona e não quebrou desde então. Obrigado pela sua sugestão instantânea, examinarei o uso de um procedimento armazenado em um futuro não tão distante.

    

Answer 2

Apenas uma ideia, não tenho certeza se isso ajuda:

Que tal modificar o modelo SQL INSERT padrão para que ele chame um PROCEDIMENTO ARMAZENADO PL / pgSQL que tenha uma lógica suficiente para manipular a entrada ilegível? Há algumas informações aqui: link (é para o MySQL, mas se aplica de forma semelhante ao módulo PostgreSQL).