Tagging messages
You can label the messages with custom tags. Tags are simple labels, identified by their names, which must be unique. Currently syslog-ng PE can tag a message at two different places:
When syslog-ng receives a message, it automatically adds the .source.<id_of_the_source_statement> tag to the message. Use the tags() option of the source to add custom tags, and the tags() option of the filters to select only specific messages.
-
Tagging messages and also filtering on the tags is very fast, much faster than other types of filters.
-
Tags are available locally, that is, if you add tags to a message on the client, these tags will not be available on the server.
-
To include the tags in the message, use the ${TAGS} macro in a template. Alternatively, if you are using the IETF-syslog message format, you can include the ${TAGS} macro in the .SDATA.meta part of the message. Note that the ${TAGS} macro is available only in syslog-ng PE 3.1.1 and later.
For an example on tagging, see Example: Adding tags and filtering messages with tags.
Filter functions
The following functions may be used in the filter statement, as described in Filters.
Table 14: Filter functions available in syslog-ng PE
| facility() |
Filter messages based on the sending facility. |
| filter() |
Call another filter function. |
| host() |
Filter messages based on the sending host. |
| in-list() |
File-based whitelisting and blacklisting. |
| level() or priority() |
Filter messages based on their priority. |
| match() |
Use a regular expression to filter messages based on a specified header or content field. |
| message() |
Use a regular expression to filter messages based on their content. |
| netmask() and netmask6() |
Filter messages based on the IP address of the sending host. |
| program() |
Filter messages based on the sending application. |
| source() |
Select messages of the specified syslog-ng PE source statement. |
| tags() |
Select messages having the specified tag. |
facility()
| Synopsis: |
facility(<facility-name>) or facility(<facility-code>) or facility(<facility-name>..<facility-name>) |
Description: Match messages having one of the listed facility codes.
The facility() filter accepts both the name and the numerical code of the facility or the importance level. Facility codes 0-23 are predefined and can be referenced by their usual name. Facility codes above 24 are not defined.
You can use the facility filter the following ways:
-
Use a single facility name, for example, facility(user)
-
Use a single facility code, for example, facility(1)
-
Use a facility range (works only with facility names), for example, facility(local0..local5)
The syslog-ng application recognizes the following facilities: (Note that some of these facilities are available only on specific platforms.)
Table 15: syslog Message Facilities recognized by the facility() filter
| 0 |
kern |
kernel messages |
| 1 |
user |
user-level messages |
| 2 |
mail |
mail system |
| 3 |
daemon |
system daemons |
| 4 |
auth |
security/authorization messages |
| 5 |
syslog |
messages generated internally by syslogd |
| 6 |
lpr |
line printer subsystem |
| 7 |
news |
network news subsystem |
| 8 |
uucp |
UUCP subsystem |
| 9 |
cron |
clock daemon |
| 10 |
authpriv |
security/authorization messages |
| 11 |
ftp |
FTP daemon |
| 12 |
ntp |
NTP subsystem |
| 13 |
security |
log audit |
| 14 |
console |
log alert |
| 15 |
solaris-cron |
clock daemon |
| 16-23 |
local0..local7 |
locally used facilities (local0-local7) |
filter()
| Synopsis: |
filter(filtername) |
Description: Call another filter rule and evaluate its value. For example:
filter demo_filter { host("example") and match("deny" value("MESSAGE")) };
filter inverted_demo_filter { not filter(demo_filter) }
