У меня есть приложение, создающее централизованные отчеты с использованием системного журнала, и я храню их в базе данных 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
У меня вопрос: как я могу этого избежать?
Я обдумываю эти решения:
Попытка сделать вставку нетранзакционной на стороне rsyslog или выполнить однострочные транзакции
$ActionQueueSize 1
$ActionQueueType Direct
$MainMsgQueueSize 1
$MainMsgQueueType Direct
Но это не сработало (и я подозреваю, что это убьет производительность)
Проверьте с помощью регулярного выражения содержимое полей перед их вставкой
Что ж, это сложная задача, тем более что я проверяю по $ 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).