Logging with syslog-ng
The syslog-ng application reads incoming messages and forwards them to the selected destinations. The syslog-ng application can receive messages from files, remote hosts, and other sources.
Log messages enter syslog-ng in one of the defined sources, and are sent to one or more destinations.
Sources and destinations are independent objects, log paths define what syslog-ng does with a message, connecting the sources to the destinations. A log path consists of one or more sources and one or more destinations: messages arriving from a source are sent to every destination listed in the log path. A log path defined in syslog-ng is called a log statement.
Optionally, log paths can include filters. Filters are rules that select only certain messages, for example, selecting only messages sent by a specific application. If a log path includes filters, syslog-ng sends only the messages satisfying the filter rules to the destinations set in the log path.
Other optional elements that can appear in log statements are parsers and rewriting rules. Parsers segment messages into different fields to help processing the messages, while rewrite rules modify the messages by adding, replacing, or removing parts of the messages.
Procedure 2.1. The route of a log message in syslog-ng
Purpose:
The following procedure illustrates the route of a log message from its source on the syslog-ng client to its final destination on the central syslog-ng server.
Steps:
-
A device or application sends a log message to a source on the syslog-ng client. For example, an Apache web server running on Linux enters a message into the
/var/log/apachefile. -
The syslog-ng client running on the web server reads the message from its
/var/log/apachesource. -
The syslog-ng client processes the first log statement that includes the
/var/log/apachesource. -
The syslog-ng client performs optional operations (message filtering, parsing, and rewriting) on the message, for example, it compares the message to the filters of the log statement (if any). If the message complies with all filter rules, syslog-ng sends the message to the destinations set in the log statement, for example, to the remote syslog-ng server.
Caution: Message filtering, parsing, and rewriting is performed in the order that the operations appear in the log statement.
NOTE: The syslog-ng client sends a message to all matching destinations by default. As a result, a message may be sent to a destination more than once, if the destination is used in multiple log statements. To prevent such situations, use the
finalflag in the destination statements. For details, see Table 8.1, “Log statement flags”. -
The syslog-ng client processes the next log statement that includes the
/var/log/apachesource, repeating Steps 3-4. -
The message sent by the syslog-ng client arrives from a source set in the syslog-ng server.
-
The syslog-ng server reads the message from its source and processes the first log statement that includes that source.
-
The syslog-ng server performs optional operations (message filtering, parsing, and rewriting) on the message, for example, it compares the message to the filters of the log statement (if any). If the message complies with all filter rules, syslog-ng sends the message to the destinations set in the log statement.
Caution: Message filtering, parsing, and rewriting is performed in the order that the operations appear in the log statement.
-
The syslog-ng server processes the next log statement, repeating Steps 7-9.
NOTE: The syslog-ng application can stop reading messages from its sources if the destinations cannot process the sent messages. This feature is called flow-control and is detailed in the section called “Managing incoming and outgoing messages with flow-control”.
Modes of operation
The syslog-ng Premium Edition application has three distinct operation scenarios: Client, Server, and Relay. The syslog-ng PE application running on a host determines the mode of operation automatically based on the license and the configuration file.
In client mode, syslog-ng collects the local logs generated by the host and forwards them through a network connection to the central syslog-ng server or to a relay. Clients often also log the messages locally into files.
No license file is required to run syslog-ng in client mode.
In relay mode, syslog-ng receives logs through the network from syslog-ng clients and forwards them to the central syslog-ng server using a network connection. Relays also log the messages from the relay host into a local file, or forward these messages to the central syslog-ng server.
You cannot use the following destinations in relay mode: mongodb(), pipe(), sql(). The file() and logstore() destinations work only for local messages that are generated on the relay.
No license file is required to run syslog-ng in relay mode.
In server mode, syslog-ng acts as a central log-collecting server. It receives messages from syslog-ng clients and relays over the network, and stores them locally in files, or passes them to other applications, for example log analyzers.
Running syslog-ng Premium Edition in server mode requires a license file. The license determines how many individual hosts can connect to the server. For details on how syslog-ng PE calculates the number of hosts, see the section called “Licensing”.
Global objects
The syslog-ng application uses the following objects:
-
Source driver: A communication method used to receive log messages. For example, syslog-ng can receive messages from a remote host via TCP/IP, or read the messages of a local application from a file. For details on source drivers, see Chapter 6, Collecting log messages — sources and source drivers.
-
Source: A named collection of configured source drivers.
-
Destination driver: A communication method used to send log messages. For example, syslog-ng can send messages to a remote host via TCP/IP, or write the messages into a file or database. For details on destination drivers, see Chapter 7, Sending and storing log messages — destinations and destination drivers.
-
Destination: A named collection of configured destination drivers.
-
Filter: An expression to select messages. For example, a simple filter can select the messages received from a specific host. For details, see the section called “Customizing message format”.
-
Macro: An identifier that refers to a part of the log message. For example, the
${HOST}macro returns the name of the host that sent the message. Macros are often used in templates and filenames. For details, see the section called “Customizing message format”. -
Parser: Parsers are objects that parse the incoming messages, or parts of a message. For example, the
csv-parser()can segment messages into separate columns at a predefined separator character (for example a comma). Every column has a unique name that can be used as a macro. For details, see Chapter 15, Parsing and segmenting structured messages and Chapter 16, Processing message content with a pattern database. -
Rewrite rule: A rule modifies a part of the message, for example, replaces a string, or sets a field to a specified value. For details, see the section called “Modifying messages”.
-
Log paths: A combination of sources, destinations, and other objects like filters, parsers, and rewrite rules. The syslog-ng application sends messages arriving from the sources of the log paths to the defined destinations, and performs filtering, parsing, and rewriting of the messages. Log paths are also called log statements. Log statements can include other (embedded) log statements and junctions to create complex log paths. For details, see Chapter 8, Routing messages: log paths, reliability, and filters.
-
Template: A template is a set of macros that can be used to restructure log messages or automatically generate file names. For example, a template can add the hostname and the date to the beginning of every log message. For details, see the section called “Customizing message format”.
-
Option: Options set global parameters of syslog-ng, like the parameters of name resolution and timezone handling. For details, see Chapter 9, Global options of syslog-ng PE.
For details on the above objects, see the section called “The configuration syntax in detail”.
Timezones and daylight saving
The syslog-ng application receives the timezone and daylight saving information from the operating system it is installed on. If the operating system handles daylight saving correctly, so does syslog-ng.
The syslog-ng application supports messages originating from different timezones. The original syslog protocol (RFC3164) does not include timezone information, but syslog-ng provides a solution by extending the syslog protocol to include the timezone in the log messages. The syslog-ng application also enables administrators to supply timezone information for legacy devices which do not support the protocol extension.
Procedure 2.2. How syslog-ng PE assigns timezone to the message
When syslog-ng PE receives a message, it assigns timezone information to the message using the following algorithm.
-
The sender application (for example the syslog-ng client) or host specifies the timezone of the messages. If the incoming message includes a timezone it is associated with the message. Otherwise, the local timezone is assumed.
-
Specify the
time-zone()parameter for the source driver that reads the message. This timezone will be associated with the messages only if no timezone is specified within the message itself. Each source defaults to the value of therecv-time-zone()global option. It is not possible to override only the timezone information of the incoming message, but setting thekeep-timestamp()option tonoallows syslog-ng PE to replace the full timestamp (timezone included) with the time the message was received.NOTE: When processing a message that does not contain timezone information, the syslog-ng PE application will use the timezone and daylight-saving that was effective when the timestamp was generated. For example, the current time is
2011-03-11(March 11, 2011) in theEU/Budapesttimezone. When daylight-saving is active (summertime), the offset is+02:00. When daylight-saving is inactive (wintertime) the timezone offset is+01:00. If the timestamp of an incoming message is2011-01-01, the timezone associated with the message will be+01:00, but the timestamp will be converted, because 2011-01-01 meant winter time when daylight saving is not active but the current timezone is+02:00. -
Specify the timezone in the destination driver using the
time-zone()parameter. Each destination driver might have an associated timezone value: syslog-ng converts message timestamps to this timezone before sending the message to its destination (file or network socket). Each destination defaults to the value of thesend-time-zone()global option.NOTE: A message can be sent to multiple destination zones. The syslog-ng application converts the timezone information properly for every individual destination zone.
Caution: If syslog-ng PE sends the message is to the destination using the legacy-syslog protocol (RFC3164) which does not support timezone information in its timestamps, the timezone information cannot be encapsulated into the sent timestamp, so syslog-ng PE will convert the hour:min values based on the explicitly specified timezone.
-
If the timezone is not specified, local timezone is used.
-
When macro expansions are used in the destination filenames, the local timezone is used. (Also, if the timestamp of the received message does not contain the year of the message, syslog-ng PE uses the local year.)
If the clients run syslog-ng, then use the ISO timestamp, because it includes timezone information. That way you do not need to adjust the recv-time-zone() parameter of syslog-ng.
If you want syslog-ng to output timestamps in Unix (POSIX) time format, use the S_UNIXTIME and R_UNIXTIME macros. You do not need to change any of the timezone related parameters, because the timestamp information of incoming messages is converted to Unix time internally, and Unix time is a timezone-independent time representation. (Actually, Unix time measures the number of seconds elapsed since midnight of Coordinated Universal Time (UTC) January 1, 1970, but does not count leap seconds.)