файл конфигурации rsyslogd (8) (rsyslogd(8) configuration file)
ACTIONS
The action field of a rule describes what to do with the message.
In general, message content is written to a kind of "logfile".
But also other actions might be done, like writing to a database
table or forwarding to another host.
Regular file
Typically messages are logged to real files. The file has to be
specified with full pathname, beginning with a slash ('/').
Example:
*.*
/var/log/traditionalfile.log;RSYSLOG_TraditionalFileFormat
# log to a file in the traditional format
Note: if you would like to use high-precision timestamps in your
log files, just remove the ";RSYSLOG_TraditionalFormat". That
will select the default template, which, if not changed, uses RFC
3339 timestamps.
Example:
*.* /var/log/file.log # log to a file with RFC3339
timestamps
By default, files are not synced after each write. To enable
syncing of log files globally, use either the
"$ActionFileEnableSync" directive or the "sync" parameter to
omfile. Enabling this option degrades performance and it is
advised not to enable syncing unless you know what you are doing.
To selectively disable syncing for certain files, you may prefix
the file path with a minus sign ("-").
Named pipes
This version of rsyslogd(8) has support for logging output to
named pipes (fifos). A fifo or named pipe can be used as a
destination for log messages by prepending a pipe symbol ('|') to
the name of the file. This is handy for debugging. Note that the
fifo must be created with the mkfifo(1) command before
rsyslogd(8) is started.
Terminal and console
If the file you specified is a tty, special tty-handling is done,
same with /dev/console.
Remote machine
There are three ways to forward message: the traditional UDP
transport, which is extremely lossy but standard, the plain TCP
based transport which loses messages only during certain
situations but is widely available and the RELP transport which
does not lose messages but is currently available only as part of
rsyslogd 3.15.0 and above.
To forward messages to another host via UDP, prepend the hostname
with the at sign ("@"). To forward it via plain tcp, prepend two
at signs ("@@"). To forward via RELP, prepend the string
":omrelp:" in front of the hostname.
Example:
*.* @192.168.0.1
In the example above, messages are forwarded via UDP to the
machine 192.168.0.1, the destination port defaults to 514. Due to
the nature of UDP, you will probably lose some messages in
transit. If you expect high traffic volume, you can expect to
lose a quite noticeable number of messages (the higher the
traffic, the more likely and severe is message loss).
Sockets for forwarded messages can be bound to a specific device
using the "device" option for the omfwd module.
Example:
action(type="omfwd" Target="192.168.0.1" Device="eth0"
Port=514 Protocol="udp")
In the example above, messages are forwarded via UDP to the
machine 192.168.0.1 at port 514 over the device eth0. TCP can be
used by setting Protocol to "tcp" in the above example.
For Linux with VRF support, the device option is used to specify
the VRF to send messages.
If you would like to prevent message loss, use RELP:
*.* :omrelp:192.168.0.1:2514
Note that a port number was given as there is no standard port
for relp.
Keep in mind that you need to load the correct input and output
plugins (see "Modules" above).
Please note that rsyslogd offers a variety of options in
regarding to remote forwarding. For full details, please see the
HTML documentation.
List of users
Usually critical messages are also directed to ``root'' on that
machine. You can specify a list of users that shall get the
message by simply writing ":omusrmsg:" followed by the login
name. You may specify more than one user by separating them with
commas (','). If they're logged in they get the message (for
example: ":omusrmsg:root,user1,user2").
Everyone logged on
Emergency messages often go to all users currently online to
notify them that something strange is happening with the system.
To specify this wall(1)-feature use an ":omusrmsg:*".
Database table
This allows logging of the message to a database table. By
default, a MonitorWare-compatible schema is required for this to
work. You can create that schema with the createDB.SQL file that
came with the rsyslog package. You can also use any other schema
of your liking - you just need to define a proper template and
assign this template to the action.
See the HTML documentation for further details on database
logging.
Discard
If the discard action is carried out, the received message is
immediately discarded. Discard can be highly effective if you
want to filter out some annoying messages that otherwise would
fill your log files. To do that, place the discard actions early
in your log files. This often plays well with property-based
filters, giving you great freedom in specifying what you do not
want.
Discard is just the single 'stop' command with no further
parameters.
Example:
*.* stop # discards everything.
Output channel
Binds an output channel definition (see there for details) to
this action. Output channel actions must start with a $-sign,
e.g. if you would like to bind your output channel definition
"mychannel" to the action, use "$mychannel". Output channels
support template definitions like all all other actions.
Shell execute
This executes a program in a subshell. The program is passed the
template-generated message as the only command line parameter.
Rsyslog waits until the program terminates and only then
continues to run.
Example:
^program-to-execute;template
The program-to-execute can be any valid executable. It receives
the template string as a single parameter (argv[1]).
