It is possible to set the facility field with the set-facility() rewrite function. When set, the set-facility() rewrite function will only rewrite the $PRIORITY field in the message to the first parameter value specified in the function.
NOTE: If the parameter value is not a valid parameter value, the function ignores it and sends a debug message, but the application still sends the message.
Declaration
log {
source { system(); };
if (program("postfix")) {
rewrite { set-facility("mail"); };
};
destination { file("/var/log/mail.log"); };
flags(flow-control);
};
Parameters
The set-facility() rewrite function has a single, mandatory parameter that can be defined as follows:
set-facility( "parameter1" );
Accepted values
The set-facility() rewrite function accepts the following values:
- numeric strings: [0-7]
- named values: emerg, emergency, panic, alert, crit, critical, err, error, warning, warn, notice, info, informational, debug
Example usage for the set-facility() rewrite function
The following example can be used in production for the set-facility() rewrite function.
rewrite {
set-facility("info");
set-facility("6");
set-facility("${.json.severity}");};
You can set the PRI value of a BSD or IETF syslog message with the set-pri() rewrite function by specifying a template string. This is useful, for example, if incoming messages do not have a PRI value specified by default, but a PRI value is required for filtering purposes.
When configured, the set-pri() function will only rewrite the PRI value of the message field.
NOTE: If the specified parameter value is not a valid value, the function ignores it and sends a debug message. However, the syslog-ng Open Source Edition (syslog-ng OSE) application will still send the message.
Declaration
rewrite <rule-name> {
set-pri("template-string");
};
Parameters
The set-pri() rewrite function expects a template string as its only parameter, for example:
Accepted values
The template string specified for the set-pri() rewrite function must expand to a natural number in the interval of 0–1023, inclusive. This means that if you, for example, extract the value from a syslog <PRI> header (such as <42>), then you need to remove the opening and closing brackets (< >) in the specified template string.
Example: Temporarily raising the priority of an application
In the following example, the set-pri() rewrite function is used to temporarily raise the priority of the application myprogram:
log {
source { system(); };
if (program("myprogram")){
rewrite { set-pri("92"); };
};
destination { file("/var/log/mail.log"); };
flags(flow-control);
}
Example: Changing the priority of an application log message in JSON format
In the following example, an application sends log messages in the following JSON format:
{
"time": "2003-10-11T22:14:15.003Z",
"host": "mymachine",
"priority": "165",
"message": "An application event log entry."
}
You can parse these logs with the syslog-ng JSON parser function:
{
parser p_json {
json-parser (prefix(".json."));
}
As the application message contains a valid priority field, you can use the set-pri() rewrite function to modify the priority of the message:
set-pri("$.json.priority");
You can unset macros or fields of the message, including any user-defined macros created using parsers (for details, see parser: Parse and segment structured messages and db-parser: Process message content with a pattern database (patterndb)). Note that the unset operation completely deletes any previous value of the field that you apply it on.
Use the following syntax:
Declaration:
rewrite <name_of_the_rule> {
unset(value("<field-name>"));
};
Example: Unsetting a message field
The following example unsets the HOST field of the message.
rewrite r_rewrite_unset{
unset(value("HOST"));
};
To unset a group of fields, you can use the groupunset() rewrite rule.
Declaration:
rewrite <name_of_the_rule> {
groupunset(values("<expression-for-field-names>"));
};
Example: Unsetting a group of fields
The following rule clears all SDATA fields:
rewrite r_rewrite_unset_SDATA{
groupunset(values(".SDATA.*"));
};
If you use RFC5424-formatted (IETF-syslog) messages, you can also create custom fields in the SDATA part of the message (For details on the SDATA message part, see The STRUCTURED-DATA message part). According to RFC5424, the name of the field (its SD-ID) must not contain the @ character for reserved SD-IDs. Custom SDATA fields must be in the following format: .SDATA.group-name@<private enterprise number>.field-name, for example, .SDATA.mySDATA-field-group@18372.4.mySDATA-field. (18372.4 is the private enterprise number of One Identity LLC, the developer of syslog-ng OSE.)
Example: Rewriting custom SDATA fields
The following example sets the sequence ID field of the RFC5424-formatted (IETF-syslog) messages to a fixed value. This field is a predefined SDATA field with a reserved SD-ID, therefore its name does not contain the @ character.
rewrite r_sd {
set("55555" value(".SDATA.meta.sequenceId"));
};
It is also possible to set the value of a field that does not exist yet, and create a new, custom name-value pair that is associated with the message. The following example creates the .SDATA.groupID.fieldID@18372.4 field and sets its value to yes. If you use the ${.SDATA.groupID.fieldID@18372.4} macro in a template or SQL table, its value will be yes for every message that was processed with this rewrite rule, and empty for every other message.
The next example creates a new SDATA field-group and field called custom and sourceip, respectively:
rewrite r_rewrite_set {
set("${SOURCEIP}" value(".SDATA.custom@18372.4.sourceip"));
};
If you use the ${.SDATA.custom@18372.4.sourceip} macro in a template or SQL table, its value will be that of the SOURCEIP macro (as seen on the machine where the SDATA field was created) for every message that was processed with this rewrite rule, and empty for every other message.
You can verify whether or not the format is correct by looking at the actual network traffic. The SDATA field-group will be called custom@18372.4, and sourceip will become a field within that group. If you decide to set up several fields, they will be listed in consecutive order within the field-group's SDATA block.
