Skip to end of banner
Go to start of banner

Remote Syslog - Admin Guide - English

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 16 Next »

Document description

Created: March 2018

Permalink:


Background

Initial Ticket: 

Error rendering macro 'jira' : Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Rsyslog is the system for log processing. It offers high-performance, great security features and a modular design. While it started as a regular syslogd, rsyslog has evolved into a kind of swiss army knife of logging, being able to accept inputs from a wide variety of sources, transform them, and output to the results to diverse destinations.

Rsyslog can deliver over one million messages per second to local destinations when limited processing is applied. 

Configuration

Main rsyslog configuration file located in /etc/rsyslog.conf but it should not be used for manual configuration.

Remote logging can be configured via WMS Interface Settings -> System -> Remote syslog


Remote logging settings are stored in sqlite database /var/www/wmsdb in system table

Based on this settings remote logging configuration file is created /rw2/etc/rsyslog.d/remote-server.conf

Every time when remote syslog feature is enabled/disabled - remote syslog daemon is restarted.

When feature is disabled remote-server.conf is removed from directory

Directory /rw2/etc/rsyslogd/ is a symlink for /etc/rsyslog.d/

Messages filter

The most used and well-known way to filter syslog messages is to use the facility/priority-based filters which filter syslog messages based on two conditions: facility and priority separated by a dot.

  • FACILITY specifies the subsystem that produces a specific syslog message. For example, the mail subsystem handles all mail-related syslog messages. FACILITY can be represented by one of the following keywords (or by a numerical code): kern(0), user (1), mail (2), daemon (3), auth (4), syslog (5), lpr (6), news (7), uucp (8), cron (9), authpriv (10), ftp (11), and local0 through local7 (16 - 23).

  • PRIORITY specifies a priority of a syslog message. The priority defines the severity of the message. PRIORITY can be represented by one of the following keywords (or by a number): debug (7), info (6), notice (5), warning (4), err (3), crit (2), alert (1), and emerg (0). The keywords error, warn and panic are deprecated and should not be used anymore. The aforementioned syntax selects syslog messages with the defined or higherpriority. By preceding any priority keyword with an equal sign (=), you specify that only syslog messages with the specified priority will be selected. All other priorities will be ignored. Conversely, preceding a priority keyword with an exclamation mark (!) selects all syslog messages except those with the defined priority.

In addition to the keywords specified above, you may also use an asterisk (*) to define all facilities or priorities (depending on where you place the asterisk, before or after the comma). Specifying the priority keyword 'none' serves for facilities with no given priorities. Both facility and priority conditions are case-insensitive.
To define multiple facilities and priorities, separate them with a comma (,). To define multiple selectors on one line, separate them with a semi-colon (;). Note that each selector in the selector field is capable of overwriting the preceding ones, which can exclude some priorities from the pattern.




Default filters

*.* - all messages will be sent

*.=error - only error messages will be sent

*.=warn - only warnings will be sent

*.=info - only info messages will be sent

Messages format

Templates are a key feature of rsyslog. They allow to specify any format a user might want. They are also used for dynamic file name generation. Every output in rsyslog uses templates - this holds true for files, user messages and so on. The database writer expects its template to be a proper SQL statement - so this is highly customizable too.

Template example

Standard Template for Writing to Files

template(name="FileFormat" type="list") {
    property(name="timestamp" dateFormat="rfc3339")
    constant(value=" ")
    property(name="hostname")
    constant(value=" ")
    property(name="syslogtag")
    property(name="msg" spifno1stsp="on" )
    property(name="msg" droplastlf="on" )
    constant(value="\n")
    }

Template names beginning with “RSYSLOG_” are reserved for rsyslog use. 

  • Forward (RSYSLOG_ForwardFormat) - a new high-precision forwarding format very similar to the traditional one, but with high-precision timestamps and timezone information. Recommended to be used when sending messages to rsyslog 3.12.5 or above.
  • Traditional Forward (RSYSLOG_TraditionalForwardFormat) - the traditional forwarding format with low-precision timestamps. Most useful if you send messages to other syslogd’s or rsyslogd below version 3.12.5.
  • Syslog protocol 23 (RSYSLOG_SyslogProtocol23Format) - the format specified in IETF’s internet-draft ietf-syslog-protocol-23, which is very close to the actual syslog standard RFC5424. This format includes several improvements. You may use this format with all relatively recent versions of rsyslog or syslogd.

Addititonal info about templates is avaialble in rsyslog documentation.

Server transport and Server destination

How to Receive Rsyslog Traffic

In linux netcat can be used to listen to specified ports e.g.

To listen to TCP port 

nc -l <port number>

To listen to UDP port 

nc -ul <port number>

Then server transport & destination with address and port should be configured in remote syslog settings


  • No labels