1RSYSLOG.CONF(5)           Linux System Administration          RSYSLOG.CONF(5)
2
3
4

NAME

6       rsyslog.conf - rsyslogd(8) configuration file
7

DESCRIPTION

9       The  rsyslog.conf  file  is  the  main configuration file for the rsys‐
10       logd(8) which logs system messages on *nix systems.  This  file  speci‐
11       fies  rules for logging.  For special features see the rsyslogd(8) man‐
12       page. Rsyslog.conf is backward-compatible with  sysklogd's  syslog.conf
13       file.  So  if you migrate from sysklogd you can rename it and it should
14       work.
15
16       Note that this version of rsyslog ships with extensive documentation in
17       HTML  format.   This is provided in the ./doc subdirectory and probably
18       in a separate package if you installed rsyslog via a packaging  system.
19       To  use rsyslog's advanced features, you need to look at the HTML docu‐
20       mentation, because the man pages only cover basic aspects of operation.
21
22
23

MODULES

25       Rsyslog has a modular design. Consequently, there is a  growing  number
26       of modules. See the HTML documentation for their full description.
27
28
29       omsnmp SNMP trap output module
30
31       omgssapi
32              Output module for GSS-enabled syslog
33
34       ommysql
35              Output module for MySQL
36
37       omrelp Output  module  for the reliable RELP protocol (prevents message
38              loss).  For details, see below at imrelp and the HTML documenta‐
39              tion.  It can be used like this:
40
41              *.*  :omrelp:server:port
42
43              *.*  :omrelp:192.168.0.1:2514 # actual sample
44
45       ompgsql
46              Output module for PostgreSQL
47
48       omlibdbi
49              Generic  database  output  module  (Firebird/Interbase,  MS SQL,
50              Sybase, SQLite, Ingres, Oracle, mSQL)
51
52       imfile Input module for text files
53
54       imudp  Input plugin for UDP syslog. Replaces the deprecated -r  option.
55              Can be used like this:
56
57              $ModLoad imudp
58
59              $UDPServerRun 514
60
61       imtcp  Input  plugin  for  plain TCP syslog. Replaces the deprecated -t
62              option. Can be used like this:
63
64              $ModLoad imtcp
65
66              $InputTCPServerRun 514
67
68
69       imrelp Input plugin for the RELP protocol. RELP can be used instead  of
70              UDP  or  plain TCP syslog to provide reliable delivery of syslog
71              messages. Please note that plain TCP  syslog  does  NOT  provide
72              truly reliable delivery, with it messages may be lost when there
73              is a connection problem or the server shuts down.  RELP prevents
74              message loss in those cases.  It can be used like this:
75
76              $ModLoad imrelp
77
78              $InputRELPServerRun 2514
79
80       imgssapi
81              Input plugin for plain TCP and GSS-enable syslog
82
83       immark Support for mark messages
84
85       imklog Kernel logging. To include kernel log messages, you need to do
86
87              $ModLoad imklog
88
89              Please  note  that  the  klogd daemon is no longer necessary and
90              consequently no longer provided by the rsyslog package.
91
92       imuxsock
93              Unix sockets, including the system log socket. You need to spec‐
94              ify
95
96              $ModLoad imuxsock
97
98              in  order  to  receive log messages from local system processes.
99              This config directive should only left out if you  know  exactly
100              what you are doing.
101
102
103

BASIC STRUCTURE

105       Lines  starting  with  a  hash  mark ('#') and empty lines are ignored.
106       Rsyslog.conf should contain following sections (sorted  by  recommended
107       order in file):
108
109
110       Global directives
111              Global  directives  set  some global properties of whole rsyslog
112              daemon, for example size of main  message  queue  ($MainMessage‐
113              QueueSize),  loading external modules ($ModLoad) and so on.  All
114              global directives need to be specified on a line  by  their  own
115              and  must  start with a dollar-sign. The complete list of global
116              directives can be found in HTML documentation in  doc  directory
117              or online on web pages.
118
119
120       Templates
121              Templates  allow  you  to  specify format of the logged message.
122              They are also used for dynamic file name generation.  They  have
123              to be defined before they are used in rules. For more info about
124              templates see TEMPLATES section of this manpage.
125
126
127       Output channels
128              Output channels provide an umbrella for any type of output  that
129              the  user  might  want.  They have to be defined before they are
130              used in rules. For more info about output  channels  see  OUTPUT
131              CHANNELS section of this manpage.
132
133
134       Rules (selector + action)
135              Every  rule line consists of two fields, a selector field and an
136              action field. These two fields are separated by one or more spa‐
137              ces  or  tabs. The selector field specifies a pattern of facili‐
138              ties and priorities belonging to the specified action.
139
140

SELECTORS

142       The selector field itself again consists of two parts, a facility and a
143       priority,  separated by a period ('.'). Both parts are case insensitive
144       and can also be specified as decimal numbers, but don't  do  that,  you
145       have been warned.  Both facilities and priorities are described in sys‐
146       log(3). The names mentioned below correspond to the similar LOG_-values
147       in /usr/include/syslog.h.
148
149       The  facility  is  one of the following keywords: auth, authpriv, cron,
150       daemon, kern, lpr, mail, mark, news, security (same as  auth),  syslog,
151       user,  uucp  and local0 through local7. The keyword security should not
152       be used anymore and mark is only for internal use and therefore  should
153       not be used in applications.  Anyway, you may want to specify and redi‐
154       rect these messages here. The facility  specifies  the  subsystem  that
155       produced the message, i.e. all mail programs log with the mail facility
156       (LOG_MAIL) if they log using syslog.
157
158       The priority is one of the following keywords, in ascending order:  de‐
159       bug, info, notice, warning, warn (same as warning), err, error (same as
160       err), crit, alert, emerg, panic (same as emerg).  The  keywords  error,
161       warn  and panic are deprecated and should not be used anymore. The pri‐
162       ority defines the severity of the message.
163
164       The behavior of the original BSD syslogd is that all  messages  of  the
165       specified priority and higher are logged according to the given action.
166       Rsyslogd behaves the same, but has some extensions.
167
168       In addition to the above mentioned names  the  rsyslogd(8)  understands
169       the  following  extensions: An asterisk ('*') stands for all facilities
170       or all priorities, depending on where it is used (before or  after  the
171       period). The keyword none stands for no priority of the given facility.
172
173       You  can  specify multiple facilities with the same priority pattern in
174       one statement using the comma (',') operator. You may specify  as  much
175       facilities  as you want. Remember that only the facility part from such
176       a statement is taken, a priority part would be skipped.
177
178       Multiple selectors may be specified for a single action using the semi‐
179       colon  (';')  separator.  Remember  that  each selector in the selector
180       field is capable to overwrite the preceding ones. Using  this  behavior
181       you can exclude some priorities from the pattern.
182
183       Rsyslogd  has a syntax extension to the original BSD source, that makes
184       its use more intuitively. You may precede every priority with an equals
185       sign  ('=')  to  specify  only  this single priority and not any of the
186       above. You may also (both is valid, too) precede the priority  with  an
187       exclamation mark ('!') to ignore all that priorities, either exact this
188       one or this and any higher priority. If you use  both  extensions  then
189       the exclamation mark must occur before the equals sign, just use it in‐
190       tuitively.
191
192

ACTIONS

194       The action field of a rule describes what to do with  the  message.  In
195       general,  message  content  is written to a kind of "logfile". But also
196       other actions might be done, like writing to a database table  or  for‐
197       warding to another host.
198
199
200   Regular file
201       Typically  messages are logged to real files. The file has to be speci‐
202       fied with full pathname, beginning with a slash ('/').
203
204       Example:
205              *.*     /var/log/traditionalfile.log;RSYSLOG_TraditionalFileFor‐
206              mat      # log to a file in the traditional format
207
208       Note:  if  you  would like to use high-precision timestamps in your log
209       files, just remove the ";RSYSLOG_TraditionalFormat". That  will  select
210       the default template, which, if not changed, uses RFC 3339 timestamps.
211
212       Example:
213              *.*      /var/log/file.log  #  log  to a file with RFC3339 time‐
214              stamps
215
216       By default, files are not synced after each write. To enable syncing of
217       log files globally, use either the "$ActionFileEnableSync" directive or
218       the "sync" parameter to omfile. Enabling this option  degrades  perfor‐
219       mance  and it is advised not to enable syncing unless you know what you
220       are doing.  To selectively disable syncing for certain files,  you  may
221       prefix the file path with a minus sign ("-").
222
223
224   Named pipes
225       This  version  of  rsyslogd(8)  has support for logging output to named
226       pipes (fifos). A fifo or named pipe can be used as  a  destination  for
227       log messages by prepending a pipe symbol ('|') to the name of the file.
228       This is handy for debugging. Note that the fifo must  be  created  with
229       the mkfifo(1) command before rsyslogd(8) is started.
230
231
232   Terminal and console
233       If  the file you specified is a tty, special tty-handling is done, same
234       with /dev/console.
235
236
237   Remote machine
238       There are three ways to forward message: the traditional UDP transport,
239       which  is  extremely  lossy but standard, the plain TCP based transport
240       which loses messages only  during  certain  situations  but  is  widely
241       available  and  the  RELP transport which does not lose messages but is
242       currently available only as part of rsyslogd 3.15.0 and above.
243
244       To forward messages to another host via UDP, prepend the hostname  with
245       the  at  sign ("@").  To forward it via plain tcp, prepend two at signs
246       ("@@"). To forward via RELP, prepend the string ":omrelp:" in front  of
247       the hostname.
248
249       Example:
250              *.* @192.168.0.1
251
252       In  the  example  above,  messages are forwarded via UDP to the machine
253       192.168.0.1, the destination port defaults to 514. Due to the nature of
254       UDP,  you  will  probably lose some messages in transit.  If you expect
255       high traffic volume, you can expect to lose a quite  noticeable  number
256       of messages (the higher the traffic, the more likely and severe is mes‐
257       sage loss).
258
259       Sockets for forwarded messages can be bound to a specific device  using
260       the "device" option for the omfwd module.
261
262       Example:
263              action(type="omfwd"  Target="192.168.0.1" Device="eth0" Port=514
264              Protocol="udp")
265
266       In the example above, messages are forwarded via  UDP  to  the  machine
267       192.168.0.1  at  port 514 over the device eth0. TCP can be used by set‐
268       ting Protocol to "tcp" in the above example.
269
270       For Linux with VRF support, the device option is used  to  specify  the
271       VRF to send messages.
272
273       If you would like to prevent message loss, use RELP:
274              *.* :omrelp:192.168.0.1:2514
275
276       Note  that  a  port  number  was given as there is no standard port for
277       relp.
278
279       Keep in mind that you need to load the correct input and output plugins
280       (see "Modules" above).
281
282       Please  note  that rsyslogd offers a variety of options in regarding to
283       remote forwarding. For full details, please see the HTML documentation.
284
285
286   List of users
287       Usually critical messages are also directed to  ``root''  on  that  ma‐
288       chine.  You  can  specify a list of users that shall get the message by
289       simply writing ":omusrmsg:" followed by the login name. You may specify
290       more  than  one  user  by separating them with commas (','). If they're
291       logged   in   they   get   the   message    (for    example:    ":omus‐
292       rmsg:root,user1,user2").
293
294
295   Everyone logged on
296       Emergency  messages  often  go  to all users currently online to notify
297       them that something strange is happening with the  system.  To  specify
298       this wall(1)-feature use an ":omusrmsg:*".
299
300
301   Database table
302       This  allows logging of the message to a database table.  By default, a
303       MonitorWare-compatible schema is required for this  to  work.  You  can
304       create  that schema with the createDB.SQL file that came with the rsys‐
305       log package. You can also use any other schema of  your  liking  -  you
306       just  need  to define a proper template and assign this template to the
307       action.
308
309       See the HTML documentation for further details on database logging.
310
311
312   Discard
313       If the discard action is carried out, the received message  is  immedi‐
314       ately  discarded. Discard can be highly effective if you want to filter
315       out some annoying messages that otherwise would fill your log files. To
316       do that, place the discard actions early in your log files.  This often
317       plays well with property-based filters, giving  you  great  freedom  in
318       specifying what you do not want.
319
320       Discard is just the single 'stop' command with no further parameters.
321
322       Example:
323              *.*   stop      # discards everything.
324
325
326
327   Output channel
328       Binds  an output channel definition (see there for details) to this ac‐
329       tion. Output channel actions must start with  a  $-sign,  e.g.  if  you
330       would  like  to  bind your output channel definition "mychannel" to the
331       action, use "$mychannel". Output channels support template  definitions
332       like all all other actions.
333
334
335   Shell execute
336       This  executes  a program in a subshell. The program is passed the tem‐
337       plate-generated message as the only  command  line  parameter.  Rsyslog
338       waits until the program terminates and only then continues to run.
339
340       Example:
341              ^program-to-execute;template
342
343       The  program-to-execute  can  be  any valid executable. It receives the
344       template string as a single parameter (argv[1]).
345
346

FILTER CONDITIONS

348       Rsyslog offers three different types "filter conditions":
349          * "traditional" severity and facility based selectors
350          * property-based filters
351          * expression-based filters
352
353
354   Selectors
355       Selectors are the traditional way of filtering syslog  messages.   They
356       have  been  kept  in  rsyslog with their original syntax, because it is
357       well-known, highly effective and also  needed  for  compatibility  with
358       stock  syslogd configuration files. If you just need to filter based on
359       priority and facility, you should do this with selector lines. They are
360       not second-class citizens in rsyslog and offer the best performance for
361       this job.
362
363
364   Property-Based Filters
365       Property-based filters are unique to rsyslogd. They allow one to filter
366       on any property, like HOSTNAME, syslogtag and msg.
367
368       A property-based filter must start with a colon in column 0. This tells
369       rsyslogd that it is the new filter type. The colon must be followed  by
370       the  property name, a comma, the name of the compare operation to carry
371       out, another comma and then the value to compare  against.  This  value
372       must be quoted.  There can be spaces and tabs between the commas. Prop‐
373       erty names and compare operations are case-sensitive, so  "msg"  works,
374       while  "MSG"  is  an  invalid property name. In brief, the syntax is as
375       follows:
376
377              :property, [!]compare-operation, "value"
378
379       The following compare-operations are currently supported:
380
381              contains
382                     Checks if the string provided in value  is  contained  in
383                     the property
384
385              isequal
386                     Compares  the  "value"  string  provided and the property
387                     contents. These two  values  must  be  exactly  equal  to
388                     match.
389
390              startswith
391                     Checks  if the value is found exactly at the beginning of
392                     the property value
393
394              regex
395                     Compares the property against the  provided  regular  ex‐
396                     pression.
397
398
399   Expression-Based Filters
400       See the HTML documentation for this feature.
401
402
403

TEMPLATES

405       Every  output  in  rsyslog  uses templates - this holds true for files,
406       user messages and so on. Templates compatible with  the  stock  syslogd
407       formats  are  hardcoded  into rsyslogd. If no template is specified, we
408       use one of these hardcoded templates. Search for  "template_"  in  sys‐
409       logd.c and you will find the hardcoded ones.
410
411       A  template  consists  of a template directive, a name, the actual tem‐
412       plate text and optional options. A sample is:
413
414              $template   MyTemplateName,"\7Text    %property%    some    more
415              text\n",<options>
416
417       The  "$template"  is the template directive. It tells rsyslog that this
418       line contains a template. The backslash is an escape character. For ex‐
419       ample,  \7  rings  the bell (this is an ASCII value), \n is a new line.
420       The set in rsyslog is a bit restricted currently.
421
422       All text in the template is used literally, except  for  things  within
423       percent  signs.  These  are properties and allow you access to the con‐
424       tents of the syslog message. Properties are accessed via  the  property
425       replacer  and  it  can for example pick a substring or do date-specific
426       formatting. More on this is the PROPERTY REPLACER section of this  man‐
427       page.
428
429       To escape:
430          % = \%
431          \ = \\ --> '\' is used to escape (as in C)
432       $template    TraditionalFormat,"%timegenerated%   %HOSTNAME%   %syslog‐
433       tag%%msg%\n"
434
435       Properties can be accessed by the property replacer (see there for  de‐
436       tails).
437
438       Please  note that templates can also by used to generate selector lines
439       with dynamic file names.  For example, if you would like to split  sys‐
440       log  messages  from  different hosts to different files (one per host),
441       you can define the following template:
442
443              $template DynFile,"/var/log/system-%HOSTNAME%.log"
444
445       This template can then be used when defining an output  selector  line.
446       It will result in something like "/var/log/system-localhost.log"
447
448
449   Template options
450       The <options> part is optional. It carries options influencing the tem‐
451       plate as whole.  See details below. Be sure NOT to mistake template op‐
452       tions with property options - the later ones are processed by the prop‐
453       erty replacer and apply to a SINGLE property, only (and not  the  whole
454       template).
455
456       Template options are case-insensitive. Currently defined are:
457
458
459              sql    format  the  string suitable for a SQL statement in MySQL
460                     format. This will replace single  quotes  ("'")  and  the
461                     backslash  character  by their backslash-escaped counter‐
462                     part ("´" and "\") inside each field. Please note that in
463                     MySQL  configuration,  the NO_BACKSLASH_ESCAPES mode must
464                     be turned off for this format to work (this  is  the  de‐
465                     fault).
466
467
468              stdsql format the string suitable for a SQL statement that is to
469                     be sent to a standards-compliant sql  server.  This  will
470                     replace  single  quotes ("'") by two single quotes ("''")
471                     inside each field.  You must  use  stdsql  together  with
472                     MySQL  if in MySQL configuration the NO_BACKSLASH_ESCAPES
473                     is turned on.
474
475       Either the sql or stdsql option MUST be specified when  a  template  is
476       used for writing to a database, otherwise injection might occur. Please
477       note that due to the unfortunate fact that several  vendors  have  vio‐
478       lated  the  sql standard and introduced their own escape methods, it is
479       impossible to have a single option doing all the work.  So you yourself
480       must make sure you are using the right format.  If you choose the wrong
481       one, you are still vulnerable to sql injection.
482
483       Please note that the database writer *checks* that the  sql  option  is
484       present  in  the template. If it is not present, the write database ac‐
485       tion is disabled.  This is to guard you against  accidental  forgetting
486       it  and  then  becoming vulnerable to SQL injection. The sql option can
487       also be useful with files - especially if you want to import them  into
488       a  database on another machine for performance reasons. However, do NOT
489       use it if you do not have a real need for it - among others,  it  takes
490       some toll on the processing time. Not much, but on a really busy system
491       you might notice it ;)
492
493       The default template for the write to database action has the  sql  op‐
494       tion set.
495
496
497   Template examples
498       Please  note  that  the samples are split across multiple lines. A tem‐
499       plate MUST NOT actually be split across multiple lines.
500
501       A template that resembles traditional syslogd file output:
502
503              $template TraditionalFormat,"%timegenerated% %HOSTNAME%
504              %syslogtag%%msg:::drop-last-lf%\n"
505
506       A template that tells you a little more about the message:
507
508              $template precise,"%syslogpriority%,%syslogfacility%,%timegener‐
509              ated%,%HOSTNAME%,
510              %syslogtag%,%msg%\n"
511
512       A template for RFC 3164 format:
513
514              $template   RFC3164fmt,"<%PRI%>%TIMESTAMP%  %HOSTNAME%  %syslog‐
515              tag%%msg%"
516
517       A template for the format traditionally used for user messages:
518
519              $template usermsg," XXXX%syslogtag%%msg%\n\r"
520
521       And a template with the traditional wall-message format:
522
523              $template  wallmsg,"\r\n\7Message  from  syslogd@%HOSTNAME%   at
524              %timegenerated%"
525
526       A  template that can be used for writing to a database (please note the
527       SQL template option)
528
529              $template MySQLInsert,"insert iut, message, receivedat values
530              ('%iut%', '%msg:::UPPERCASE%', '%timegenerated:::date-mysql%')
531              into systemevents\r\n", SQL
532
533              NOTE 1: This template is embedded into core application under
534              name StdDBFmt , so you don't need to define it.
535
536              NOTE 2: You have to have MySQL module installed to use this tem‐
537              plate.
538
539

OUTPUT CHANNELS

541       Output Channels are a new concept first introduced in rsyslog 0.9.0. As
542       of  this writing, it is most likely that they will be replaced by some‐
543       thing different in the future.  So if you  use  them,  be  prepared  to
544       change  you  configuration  file syntax when you upgrade to a later re‐
545       lease.
546
547       Output channels are defined via an $outchannel directive.  It's  syntax
548       is as follows:
549
550              $outchannel name,file-name,max-size,action-on-max-size
551
552       name is the name of the output channel (not the file), file-name is the
553       file name to be written to, max-size the maximum allowed size  and  ac‐
554       tion-on-max-size  a  command to be issued when the max size is reached.
555       This command always has exactly one parameter. The binary is that  part
556       of  action-on-max-size  before the first space, its parameter is every‐
557       thing behind that space.
558
559       Keep in mind that $outchannel just defines a channel  with  "name".  It
560       does  not activate it.  To do so, you must use a selector line (see be‐
561       low). That selector line includes the channel name plus ":omfile:$"  in
562       front of it. A sample might be:
563
564              *.* :omfile:$mychannel
565
566

PROPERTY REPLACER

568       The  property replacer is a core component in rsyslogd's output system.
569       A syslog message has a number of well-defined properties  (see  below).
570       Each of this properties can be accessed and manipulated by the property
571       replacer. With it, it is easy to use only part of a property  value  or
572       manipulate the value, e.g. by converting all characters to lower case.
573
574
575   Accessing Properties
576       Syslog  message properties are used inside templates. They are accessed
577       by putting them between percent signs. Properties can  be  modified  by
578       the property replacer. The full syntax is as follows:
579
580              %propname:fromChar:toChar:options%
581
582       propname is the name of the property to access.  It is case-sensitive.
583
584
585   Available Properties
586       msg    the MSG part of the message (aka "the message" ;))
587
588       rawmsg the  message  exactly as it was received from the socket. Should
589              be useful for debugging.
590
591       HOSTNAME
592              hostname from the message
593
594       FROMHOST
595              hostname of the system the message was received from (in a relay
596              chain,  this  is  the  system immediately in front of us and not
597              necessarily the original sender)
598
599       syslogtag
600              TAG from the message
601
602       programname
603              the "static" part of the tag, as defined by BSD syslogd. For ex‐
604              ample, when TAG is "named[12345]", programname is "named".
605
606       PRI    PRI part of the message - undecoded (single value)
607
608       PRI-text
609              the  PRI  part  of  the  message  in  a textual form (e.g. "sys‐
610              log.info")
611
612       IUT    the monitorware InfoUnitType - used when talking to  a  Monitor‐
613              Ware backend (also for phpLogCon)
614
615       syslogfacility
616              the facility from the message - in numerical form
617
618       syslogfacility-text
619              the facility from the message - in text form
620
621       syslogseverity
622              severity from the message - in numerical form
623
624       syslogseverity-text
625              severity from the message - in text form
626
627       timegenerated
628              timestamp  when the message was RECEIVED. Always in high resolu‐
629              tion
630
631       timereported
632              timestamp from the message. Resolution depends on what was  pro‐
633              vided in the message (in most cases, only seconds)
634
635       TIMESTAMP
636              alias for timereported
637
638       PROTOCOL-VERSION
639              The  contents  of  the  PROTOCOL-VERSION  field  from IETF draft
640              draft-ietf-syslog-protocol
641
642       STRUCTURED-DATA
643              The contents of the STRUCTURED-DATA field from IETF draft draft-
644              ietf-syslog-protocol
645
646       APP-NAME
647              The  contents  of the APP-NAME field from IETF draft draft-ietf-
648              syslog-protocol
649
650       PROCID The contents of the PROCID field from IETF draft draft-ietf-sys‐
651              log-protocol
652
653       MSGID  The  contents of the MSGID field from IETF draft draft-ietf-sys‐
654              log-protocol
655
656       $NOW   The current date stamp in the format YYYY-MM-DD
657
658       $YEAR  The current year (4-digit)
659
660       $MONTH The current month (2-digit)
661
662       $DAY   The current day of the month (2-digit)
663
664       $HOUR  The current hour in military (24 hour) time (2-digit)
665
666       $MINUTE
667              The current minute (2-digit)
668
669
670       Properties starting with a  $-sign  are  so-called  system  properties.
671       These do NOT stem from the message but are rather internally-generated.
672
673
674   Character Positions
675       FromChar and toChar are used to build substrings. They specify the off‐
676       set within the string that should be copied. Offset counting starts  at
677       1, so if you need to obtain the first 2 characters of the message text,
678       you can use this syntax: "%msg:1:2%". If you do  not  wish  to  specify
679       from and to, but you want to specify options, you still need to include
680       the colons. For example, if you would like to convert the full  message
681       text  to  lower case, use "%msg:::lowercase%". If you would like to ex‐
682       tract from a position until the end of the string, you can place a dol‐
683       lar-sign  ("$") in toChar (e.g. %msg:10:$%, which will extract from po‐
684       sition 10 to the end of the string).
685
686       There is also support for regular expressions.  To use them,  you  need
687       to  place  a  "R" into FromChar.  This tells rsyslog that a regular ex‐
688       pression instead of position-based extraction is  desired.  The  actual
689       regular expression must then be provided in toChar. The regular expres‐
690       sion must be followed by the string "--end". It denotes the end of  the
691       regular  expression  and  will not become part of it.  If you are using
692       regular expressions, the property replacer will return the part of  the
693       property  text  that  matches  the regular expression. An example for a
694       property   replacer   sequence   with   a   regular   expression    is:
695       "%msg:R:.*Sev:. \(.*\) \[.*--end%"
696
697       Also,  extraction  can  be  done based on so-called "fields". To do so,
698       place a "F" into FromChar. A field in its current  definition  is  any‐
699       thing  that is delimited by a delimiter character. The delimiter by de‐
700       fault is TAB (US-ASCII value 9). However, if  can  be  changed  to  any
701       other US-ASCII character by specifying a comma and the decimal US-ASCII
702       value of the delimiter immediately after the "F". For example,  to  use
703       comma  (",") as a delimiter, use this field specifier: "F,44".  If your
704       syslog data is delimited, this is a quicker way  to  extract  than  via
705       regular  expressions  (actually,  a *much* quicker way). Field counting
706       starts at 1. Field zero is accepted, but will always lead to  a  "field
707       not  found"  error.  The same happens if a field number higher than the
708       number of fields in the property is requested. The field number must be
709       placed  in  the "ToChar" parameter. An example where the 3rd field (de‐
710       limited by TAB) from the msg  property  is  extracted  is  as  follows:
711       "%msg:F:3%".   The   same   example  with  semicolon  as  delimiter  is
712       "%msg:F,59:3%".
713
714       Please note that the special characters "F" and "R" are case-sensitive.
715       Only  upper  case  works, lower case will return an error. There are no
716       white spaces permitted inside the sequence (that  will  lead  to  error
717       messages and will NOT provide the intended result).
718
719
720   Property Options
721       Property options are case-insensitive. Currently, the following options
722       are defined:
723
724       uppercase
725              convert property to lowercase only
726
727       lowercase
728              convert property text to uppercase only
729
730       drop-last-lf
731              The last LF in the message (if any), is dropped. Especially use‐
732              ful for PIX.
733
734       date-mysql
735              format as mysql date
736
737       date-rfc3164
738              format as RFC 3164 date
739
740       date-rfc3339
741              format as RFC 3339 date
742
743       escape-cc
744              replace control characters (ASCII value 127 and values less then
745              32) with an escape sequence. The sequence is "#<charval>"  where
746              charval  is  the 3-digit decimal value of the control character.
747              For example, a tabulator would be replaced by "#009".
748
749       space-cc
750              replace control characters by spaces
751
752       drop-cc
753              drop control characters - the resulting string will neither con‐
754              tain control characters, escape sequences nor any other replace‐
755              ment character like space.
756
757

QUEUED OPERATIONS

759       Rsyslogd supports queued operations to handle offline outputs (like re‐
760       mote  syslogd's or database servers being down). When running in queued
761       mode, rsyslogd buffers messages to memory and optionally to disk (on an
762       as-needed basis). Queues survive rsyslogd restarts.
763
764       It is highly suggested to use remote forwarding and database writing in
765       queued mode, only.
766
767       To learn more about queued operations, see the HTML documentation.
768
769

FILES

771       /etc/rsyslog.conf
772              Configuration file for rsyslogd
773

SEE ALSO

775       rsyslogd(8), logger(1), syslog(3)
776
777       The complete documentation can be found in the doc folder of the  rsys‐
778       log distribution or online at
779
780              https://www.rsyslog.com/doc/
781
782       Please  note that the man page reflects only a subset of the configura‐
783       tion options. Be sure to read the HTML documentation for  all  features
784       and  details.  This  is  especially vital if you plan to set up a more-
785       then-extremely-simple system.
786

AUTHORS

788       rsyslogd is taken from sysklogd sources, which have been heavily  modi‐
789       fied by Rainer Gerhards (rgerhards@adiscon.com) and others.
790
791
792
793Version 7.2.0                   22 October 2012                RSYSLOG.CONF(5)
Impressum