Perhaps the functionality is there and I don't realize it, and this is not critical if it's not, but it would come in handy to be able to do something like the following: destination d_sql { sql( ... values( "${FOO:-default_value}", ...) In other words, being able to specify a default value for the name-value pair when one doesn't exist much like you can do in UNIX shell scripts. Similarly, but in my case otherwise, using patterndb, it would be handy to be able to set a name-value pair per <pattern>. I believe right now you can only do do based on the upper level <patterns> hierarchy. To help clarify the reasoning, I have a database table with a field that I'd like to fill with at least a default value, but that field might not exist in the log message in some cases. For instance, BIND 9.x query logs can log the "view", but unless you configure views for all the possible classes, which is generally not done, queries for other classes will not have the view identifier. Compare these common examples: <test_message>queries: info: client 127.0.0.1#1024: view lopback: query: 1.0.0.127.in-addr.arpa IN PTR +</test_message> <test_message>queries: info: client 192.0.2.1#1024: query: version.bind CH TXT + (192.0.2.1)</test_message> Right now the view field gets logged as a null, which is OK, but I'd rather it be inserted with a default view of 'default' in this example. John
On Fri, 2011-02-11 at 11:03 -0600, John Kristoff wrote:
Perhaps the functionality is there and I don't realize it, and this is not critical if it's not, but it would come in handy to be able to do something like the following:
destination d_sql { sql( ... values( "${FOO:-default_value}", ...)
this should work with exactly this syntax.
In other words, being able to specify a default value for the name-value pair when one doesn't exist much like you can do in UNIX shell scripts.
Similarly, but in my case otherwise, using patterndb, it would be handy to be able to set a name-value pair per <pattern>. I believe right now you can only do do based on the upper level <patterns> hierarchy.
To help clarify the reasoning, I have a database table with a field that I'd like to fill with at least a default value, but that field might not exist in the log message in some cases. For instance, BIND 9.x query logs can log the "view", but unless you configure views for all the possible classes, which is generally not done, queries for other classes will not have the view identifier. Compare these common examples:
<test_message>queries: info: client 127.0.0.1#1024: view lopback: query: 1.0.0.127.in-addr.arpa IN PTR +</test_message> <test_message>queries: info: client 192.0.2.1#1024: query: version.bind CH TXT + (192.0.2.1)</test_message>
Right now the view field gets logged as a null, which is OK, but I'd rather it be inserted with a default view of 'default' in this example.
John ______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.campin.net/syslog-ng/faq.html
-- Bazsi
participants (2)
-
Balazs Scheidler
-
John Kristoff