Назад | Перейти на главную страницу

Предотвращение потери нескольких строк при сохранении сообщений системного журнала в базе данных Postgres

У меня есть приложение, создающее централизованные отчеты с использованием системного журнала, и я храню их в базе данных Postgres для индивидуального использования.

База данных имеет определенный формат (с учетом того, что данные, которые я централизирую, находятся в виде CSV, каждый столбец имеет определенное значение). Пока все хорошо, данные правильно вставлены в базу данных в правильном формате.

Если плохо отформатированное сообщение попадает в системный журнал (например, с текстом вместо int), я получаю ошибку вставки, потому что тип недействителен, что ожидается ... НО следующие сообщения пакета также удаляются без уведомления (Я считаю, что это потому, что вставка в транзакции)

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

У меня вопрос: как я могу этого избежать?

Я обдумываю эти решения:

Что ж, это сложная задача, тем более что я проверяю по $ programname и $ msg, я действительно не могу использовать regexp

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

Что ж, я не особо заинтересован в этом решении

О, и я использую rsyslog 4.6.4-2

Спасибо !

Редактировать : Наконец, я обошел это решение, отфильтровав сообщение с помощью довольно сложного регулярного выражения

: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

Это непросто поддерживать, но с тех пор он работает и не ломается. Спасибо за ваше предложение щелчок, Я рассмотрю использование хранимой процедуры в ближайшем будущем.

Наконец, я обошел это решение, отфильтровав сообщение с помощью довольно сложного регулярного выражения

: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

Это непросто поддерживать, но с тех пор он работает и не ломается. Спасибо за ваше предложение, я рассмотрю возможность использования хранимой процедуры в ближайшем будущем.

Просто идея, я не уверен, поможет ли это:

Как насчет изменения шаблона SQL INSERT по умолчанию так, чтобы он вызывал STORED PROCEDURE PL / pgSQL, у которого есть достаточная логика для обработки искаженного ввода? Здесь есть некоторая информация: http://www.rsyslog.com/doc/ommysql.html (он предназначен для MySQL, но применяется аналогично модулю PostgreSQL).