The map-value-pairs() parser allows you to map existing name-value pairs to a different set of name-value pairs. You can rename them in bulk, making it easy to use for log normalization tasks (for example, when you parse information from different log messages, and want to convert them into a uniform naming scheme). You can use the normal value-pairs expressions, similarly to value-pairs based destinations.
Available in syslog-ng OSE version
parser parser_name { map-value-pairs( <list-of-value-pairs-options> ); };
The following example creates a new name-value pair called username, adds the hashed value of the .apache.username to this new name-value pair, then adds the webserver prefix to the name of every name-value pair of the message that starts with .apache
parser p_remap_name_values { map-value-pairs( pair("username", "'($sha1 $.apache.username)") key('.apache.*' rekey(add-prefix("webserver"))) ); };
Starting with
Using conditions in rewrite rules can simplify your syslog-ng OSE configuration file, as you do not need to create separate log paths to modify certain messages.
The following procedure summarizes how conditional rewrite rules (rewrite rules that have the condition() parameter set) work. The following configuration snippet is used to illustrate the procedure:
rewrite r_rewrite_set{ set( "myhost", value("HOST") condition(program("myapplication")) ); }; log { source(s1); rewrite(r_rewrite_set); destination(d1); };
The log path receives a message from the source (s1).
The rewrite rule (r_rewrite_set) evaluates the condition. If the message matches the condition (the PROGRAM field of the message is "myapplication"), syslog-ng OSE rewrites the log message (sets the value of the HOST field to "myhost"), otherwise it is not modified.
The next element of the log path processes the message (d1).
The following example sets the HOST field of the message to myhost only if the message was sent by the myapplication program.
rewrite r_rewrite_set{set("myhost", value("HOST") condition(program("myapplication")));};
The following example is identical to the previous one, except that the condition references an existing filter template.
filter f_rewritefilter {program("myapplication");}; rewrite r_rewrite_set{set("myhost", value("HOST") condition(filter(f_rewritefilter)));};
To add or delete a tag, you can use rewrite rules. To add a tag, use the following syntax:
rewrite <name_of_the_rule> { set-tag("<tag-to-add>"); };
To delete a tag, use the following syntax:
rewrite <name_of_the_rule> { clear-tag("<tag-to-delete>"); };
You cannot use macros in the tags.
Starting with version
Set a timezone to a specific value
Fix a timezone if it was improperly parsed
Assuming the sender is sending messages in near-real-time, syslog-ng OSE can guess the timezone
By default, these operations modify the date-related macros of the message that correspond to the date the message was sent (that is, the S_ macros). You can modify the dates when syslog-ng OSE has received the messages (that is, the R_ macros), but this is rarely needed. To do so, include the time-stamp(recvd) option in the operation, for example:
rewrite { fix-time-zone("EST5EDT" time-stamp(recvd)); };
Use the fix-time-zone() operation to correct the timezone of a message if it was parsed incorrectly for some reason, or if the client did not include any timezone information in the message. You can specify the new timezone as the name of a timezone, or as a template string. For example, use the following rewrite rule to set the timezone to EST5EDT:
rewrite { fix-time-zone("EST5EDT"); };
If you have lots of clients that do not send timezone information in the log messages, you can create a database file that stores the timezone of the clients, and feed this data to syslog-ng OSE using the add-contextual-data() feature. For details, see Adding metadata from an external file.
Use the guess-time-zone() operation attempts to set the timezone of the message automatically, using heuristics on the timestamps. Normally the syslog-ng OSE application performs this operation automatically when it parses the incoming message. Using this operation in a rewrite rule can be useful if you cannot parse the incoming message for some reason (and use the flags(no-parse) option in your source, but you want to set the timezone automatically later (for example, after you have preprocessed the message).
Using this operation is identical to using the flags(guess-timezone) flag in the source.
Use the set-time-zone() operation to set the timezone of the message to a specific value, that is to convert an existing timezone to a different one. This operation is identical to setting the time-zone() option in a destination or as a global option, but can be applied selectively to the messages using conditions.
© ALL RIGHTS RESERVED. Nutzungsbedingungen Datenschutz Cookie Preference Center