Log on to the Linux device whose messages you want to forward to the server as a super user. Note : If the Web NMS server is running in a Linux device, you need to make the following configuration in the server to receive the forwarded messages. In Linux devices, by default, the syslog daemon occupies the port This port must be freed in the machine where the Web NMS server is running, so that it listens for syslog messages at port. You can change the port number for the syslog daemon so that port can be used by the server.
The steps are explained below. In the services file, all the services and their corresponding port numbers are listed. Ensure that the port number is not occupied by some other service you can configure a different port if the default port is occupied. You can configure a different port for the Web NMS server to listen for syslog messages. The port number is configured in the file called NmsProcessBE. But, the UDP port must be same for the forwarding devices and the device where the server is running.
So, it is mandatory that you change the port number in all the forwarding devices. Log files are files that contain messages about the system, including the kernel, services, and applications running on it.
There are different log files for different information. For example, there is a default system log file, a log file just for security messages, and a log file for cron tasks. Log files can be very useful when trying to troubleshoot a problem with the system such as trying to load a kernel driver or when looking for unauthorized log in attempts to the system.
This chapter discusses where to find log files, how to view log files, and what to look for in log files. Some log files are controlled by a daemon called rsyslogd. Configuring rsyslog. It is essentially divided in the following parts:. Due to its modular design, rsyslog offers a variety of modules which provide dynamic functionality. Note that modules can be written by third parties.
Essentially, modules are comprised of various configuration directives that become available when a module is loaded. To load a module, use the following syntax:. Input Modules — Input modules gather messages from various sources. The name of an input module always starts with the im prefix, such as imfile , imrelp , etc. Output Modules — Output modules process messages into different formats or perform various actions on them.
The name of an output module always starts with the om prefix, such as omsnmp , omrelp , etc. Filter Modules — Filter modules provide the ability to filter messages according to specified rules. The name of a filter module always starts with the fm prefix. Parser Modules — Parser modules use the message parsers to parse message content of any received messages. The name of a parser module always starts with the pm prefix, such as pmrfc , pmrfc , etc.
Message Modification Modules — Message modification modules change the content of asyslog message. The message modification modules only differ in their implementation from the output and filter modules but share the same interface.
String Generator Modules — String generator modules generate strings based on the message content and strongly cooperate with the template feature provided by rsyslog. For more information on templates, refer to. The name of a string generator module always starts with the sm prefix, such as smfile , smtradfile , etc.
By default, the log file is synchronized every time a syslog message is generated. Use a dash mark - as a prefix of the file path you specified to omit syncing:. Note that you might lose information if the system terminates right after a write attempt. However, this setting can improve performance, especially if you run programs that produce very verbose log messages.
Your specified file path can be either static or dynamic. Static files are represented by a fixed file path as shown in the example above. Dynamic file paths can differ according to the received message. Dynamic file paths are represented by a template and a question mark? You can use the dash prefix - to disable syncing, also you can use multiple templates separated by a colon ;. For more information on templates, see Generating Dynamic File Names. This feature allows you to administer syslog messages of multiple hosts on one machine.
To forward syslog messages to a remote machine, use the following syntax:. The at sign indicates that the syslog messages are forwarded to a host using the UDP protocol. To use the TCP protocol, use two at signs with no space between them. Compression gain is automatically checked by rsyslogd , messages are compressed only if there is any compression gain and messages below 60 bytes are never compressed. When specifying an IPv6 address as the host, enclose the address in square brackets [ , ].
The following are some examples of actions that forward syslog messages over the network note that all actions are preceded with a selector that selects all messages with any priority. To forward messages to The following compresses messages with zlib level 9 compression and forwards them to db using the UDP protocol.
Output channels are primarily used to specify the maximum size a log file can grow to. This is very useful for log file rotation for more information see Log Rotation. An output channel is basically a collection of information about the output action. Output channels can write only into files, not pipes, terminal, or other kind of output.
This value is specified in bytes. The following output shows a simple log rotation through the use of an output channel. This script can contain anything from moving the file into a different folder, editing specific content out of it, or simply removing it.
To specify more than one user, separate each user name with a comma ,. Consequently, specify a template that formats the received message and passes it to the specified executable as a one line parameter for more information on templates, see Templates. This program can be any valid executable.
In the following example, any syslog message with any priority is selected, formatted with the template template and passed as a parameter to the test-program program, which is then executed with the provided parameter:. When accepting messages from any host, and using the shell execute action, you may be vulnerable to command injection.
An attacker may try to inject and execute commands in the program you specified to be executed in your action. To avoid any possible security threats, thoroughly consider the use of the shell execute action. Selected syslog messages can be directly written into a database table using the database writer action. The database writer uses the following syntax:. For more information on templates, see Templates. For more information on rsyslog modules, see Using Rsyslog Modules.
The discard action is mostly used to filter out messages before carrying on any further processing. It can be effective if you want to omit some repeating messages that would otherwise fill the log files. The results of discard action depend on where in the configuration file it is specified, for the best results place these actions on top of the actions list.
Please note that once a message has been discarded there is no way to retrieve it in later configuration file lines.
For each selector, you are allowed to specify multiple actions. Specifying multiple actions improves the overall performance of the desired outcome since the specified selector has to be evaluated only once. In the following example, all kernel syslog messages with the critical priority crit are sent to user user1 , processed by the template temp and passed on to the test-program executable, and forwarded to Any action can be followed by a template that formats the message.
To specify a template, suffix an action with a semicolon ; and specify the name of the template. A template must be defined before it is used in an action, otherwise it is ignored. Any output that is generated by rsyslog can be modified and formatted according to your needs with the use of templates.
The currently supported template options are sql and stdsql , which are used for formatting the text as an SQL query. Note that the database writer checks whether the sql or stdsql options are specified in the template.
If they are not, the database writer does not perform any action. This is to prevent any possible security threats, such as SQL injection. See section Storing syslog messages in a database in Actions for more information. Templates can be used to generate dynamic file names. By specifying a property as a part of the file path, a new file will be created for each unique property, which is a convenient way to classify syslog messages. For example, use the timegenerated property, which extracts a time stamp from the message, to generate a unique file name for each syslog message:.
You must use it inside a rule for it to take effect. A list of all available properties and their detailed description can be found in the rsyslog. Alternatively, regular expressions can be used to specify a range of characters. A list of all available property options and their detailed description can be found in the rsyslog. The following property obtains the whole message text of a syslog message and drops its last line feed character:.
The following property obtains the first 10 characters of the time stamp that is generated when the syslog message is received and formats it according to the RFC date standard. A wall message template shows a template that resembles a traditional wall message a message that is send to every user that is logged in and has their mesg 1 permission set to yes.
A database formatted message template shows a template that formats a syslog message so that it can be used as a database query. Notice the use of the sql option at the end of the template specified as the template option. The following list shows these predefined templates along with their definitions. A modern-style logfile format similar to TraditionalFileFormat, but with high-precision time stamps and time zone information. Global directives are configuration options that apply to the rsyslogd daemon.
They usually specify a value for a specific predefined variable that affects the behavior of the rsyslogd daemon or a rule that follows. Only one directive can be specified per line. The following is an example of a global directive that specifies the maximum size of the syslog message queue:. The default size defined for this directive 10, messages can be overridden by specifying a different value as shown in the example above.
A directive affects the behavior of all configuration options until another occurrence of that same directive is detected. Global directives can be used to configure actions, queues and for debugging. A comprehensive list of all available configuration directives can be found in Online Documentation. However, classic global directives remain supported as a legacy format. All of the lines in the sample configuration file define global options that apply to every log file.
In our example, log files are rotated weekly, rotated log files are kept for four weeks, and all rotated log files are compressed by gzip into the. Any lines that begin with a hash sign are comments and are not processed. You may define configuration options for a specific log file and place it under the global options. The settings specified here override the global settings where possible. The following is a list of some of the directives you can specify in your logrotate configuration file:.
Similar directives include:. If the value 0 is specified, old log files are removed instead of rotated. This is the default option when mail is enabled. For the full list of directives and various configuration options, see the logrotate 8 manual page. In rsyslog version 6, a new configuration syntax was introduced. This new configuration format aims to be more powerful, more intuitive, and to prevent common mistakes by not permitting certain invalid constructs.
The syntax enhancement is enabled by the new configuration processor that relies on RainerScript. RainerScript is a scripting language designed for processing network events and configuring event processors such as rsyslog.
RainerScript was first used to define expression-based filters, see Expression-based Filters. The new syntax differs mainly in that it is much more structured; parameters are passed as arguments to statements, such as input, action, template, and module load. The scope of options is limited by blocks. This enhances readability and reduces the number of bugs caused by misconfiguration. There is also a significant performance gain.
Some functionality is exposed in both syntaxes, some only in the new one. This significantly reduces the number of parameters used in configuration, improves readability, and also provides higher execution speed. For more information on RainerScript statements and parameters see Online Documentation. Leaving special directives aside, rsyslog handles messages as defined by rules that consist of a filter condition and an action to be performed if the condition is true.
This process starts with the first rule and continues until all rules have been processed or until the message is discarded by one of the rules. However, rules can be grouped into sequences called rulesets. With rulesets, you can limit the effect of certain rules only to selected inputs or enhance the performance of rsyslog by defining a distinct set of actions bound to a specific input.
In other words, filter conditions that will be inevitably evaluated as false for certain types of messages can be skipped. With the new configuration format in rsyslog 7, the input and ruleset statements are reserved for this operation. Replace rulesetname with an identifier for your ruleset. With rule and rule2 you can define rules in filter-action format mentioned above. With the call parameter, you can nest rulesets by calling them from inside other ruleset blocks.
Other parameters such as file or tag can be specified for input. Replace rulesetname with a name of the ruleset to be evaluated against the message. In case an input message is not explicitly bound to a ruleset, the default ruleset is triggered. You can also use the legacy format to define rulesets, for more information see Online Documentation. The following rulesets ensure different handling of remote messages coming from different ports. Rulesets shown in the above example define log destinations for the remote input from two ports, in case of , messages are sorted according to the facility.
Then, the TCP input is enabled and bound to rulesets. Note that you must load the required modules imtcp for this configuration to work. From rsyslog version 6, compatibility mode specified via the -c option has been removed. Also, the syslogd-style command-line options are deprecated and configuring rsyslog through these command-line options should be avoided.
However, you can use several templates and directives to configure rsyslogd to emulate syslogd-like behavior. For more information on various rsyslogd options, see the rsyslogd 8 manual page. Queues are used to pass content, mostly syslog messages, between components of rsyslog.
With queues, rsyslog is capable of processing multiple messages simultaneously and to apply several actions to a single message at once. The data flow inside rsyslog can be illustrated as follows:. Whenever rsyslog receives a message, it passes this message to the preprocessor and then places it into the main message queue. Messages wait there to be dequeued and passed to the rule processor. The rule processor is a parsing and filtering engine.
Based on these rules, the rule processor evaluates which actions are to be performed. Each action has its own action queue. Messages are passed through this queue to the respective action processor which creates the final output. Note that at this point, several actions can run simultaneously on one message.
For this purpose, a message is duplicated and passed to multiple action processors. Only one queue per action is possible. Depending on configuration, the messages can be sent right to the action processor without action queuing. This is the behavior of direct queues see below. In case the output action fails, the action processor notifies the action queue, which then takes an unprocessed element back and after some time interval, the action is attempted again.
To sum up, there are two positions where queues stand in rsyslog : either in front of the rule processor as a single main message queue or in front of various types of output actions as action queues.
Queues provide two main advantages that both lead to increased performance of message processing:. Apart from this, queues can be configured with several directives to provide optimal performance for your system.
These configuration options are covered in the following sections. If an output plug-in is unable to deliver a message, it is stored in the preceding message queue.
If the queue fills, the inputs block until it is no longer full. This will prevent new messages from being logged via the blocked queue. In the absence of separate action queues this can have severe consequences, such as preventing SSH logging, which in turn can prevent SSH access.
Therefore it is advised to use dedicated action queues for outputs which are forwarded over a network or to a database. Based on where the messages are stored, there are several types of queues: direct , in-memory , disk , and disk-assisted in-memory queues that are most widely used. You can choose one of these types for the main message queue and also for action queues.
Here, you can apply the setting for the main message queue replace object with MainMsg or for an action queue replace object with Action. The default setting for a main message queue is the FixedArray queue with a limit of 10, messages.
Action queues are by default set as Direct queues. For many simple operations, such as when writing output to a local file, building a queue in front of an action is not needed.
To avoid queuing, use:. Replace object with MainMsg or with Action to use this option to the main message queue or for an action queue respectively. With direct queue, messages are passed directly and immediately from the producer to the consumer.
Disk queues store messages strictly on a hard drive, which makes them highly reliable but also the slowest of all possible queuing modes.
This mode can be used to prevent the loss of highly important log data. However, disk queues are not recommended in most use cases. Disk queues are written in parts, with a default size 10 Mb. This default size can be modified with the following configuration directive:. The defined size limit is not restrictive, rsyslog always writes one complete queue entry, even if it violates the size limit.
Each part of a disk queue matches with an individual file. The naming directive for these files looks as follows:. This sets a name prefix for the file followed by a 7-digit number starting at one and incremented for each file. With in-memory queue, the enqueued messages are held in memory which makes the process very fast.
The queued data is lost if the computer is power cycled or shut down. There are two types of in-memory queues:. FixedArray queue — the default mode for the main message queue, with a limit of 10, elements. This type of queue uses a fixed, pre-allocated array that holds pointers to queue elements.
Due to these pointers, even if the queue is empty a certain amount of memory is consumed. However, FixedArray offers the best run time performance and is optimal when you expect a relatively low number of queued messages and high performance.
LinkedList queue — here, all structures are dynamically allocated in a linked list, thus the memory is allocated only when needed. LinkedList queues handle occasional message bursts very well. In general, use LinkedList queues when in doubt. Compared to FixedArray, it consumes less memory and lowers the processing overhead.
Both disk and in-memory queues have their advantages and rsyslog lets you combine them in disk-assisted in-memory queues. This queue then becomes disk-assisted , which means it couples an in-memory queue with a disk queue to work in tandem. The disk queue is activated if the in-memory queue is full or needs to persist after shutdown. With a disk-assisted queue, you can set both disk-specific and in-memory specific configuration parameters.
This type of queue is probably the most commonly used, it is especially useful for potentially long-running and unreliable actions. To specify the functioning of a disk-assisted in-memory queue, use the so-called watermarks :.
Replace number with a number of enqueued messages. When an in-memory queue reaches the number defined by the high watermark, it starts writing messages to disk and continues until the in-memory queue size drops to the number defined with the low watermark. Correctly set watermarks minimize unnecessary disk writes, but also leave memory space for message bursts since writing to disk files is rather lengthy.
The difference between the high watermark and the overall queue size is a spare memory buffer reserved for message bursts. On the other hand, setting the high watermark too low will turn on disk assistance unnecessarily often. Rsyslog is often used to maintain a centralized logging system, where log messages are forwarded to a server over the network.
To avoid message loss when the server is not available, it is advisable to configure an action queue for the forwarding action. This way, messages that failed to be sent are stored locally until the server is reachable again. Note that such queues are not configurable for connections using the UDP protocol. To establish a fully reliable connection, for example when your logging server is outside of your private network, consider using the RELP protocol described in Using RELP.
Suppose the task is to forward log messages from the system to a server with host name example. To do so, perform the following steps:.
With the above configuration, rsyslog keeps messages in memory if the remote server is not reachable. A file on disk is created only if rsyslog runs out of the configured memory queue space or needs to shut down, which benefits the system performance. Each destination server requires a separate forwarding rule, action queue specification, and backup file on disk.
All types of queues can be further configured to match your requirements. You can use several directives to modify both action queues and the main message queue. Currently, there are more than 20 queue parameters available, see Online Documentation. Some of these settings are used commonly, others, such as worker thread management, provide closer control over the queue behavior and are reserved for advanced users.
With advanced settings, you can optimize rsyslog 's performance, schedule queuing, or modify the behavior of a queue on system shutdown. You can set the queue size only as the number of messages, not as their actual memory size. The default queue size is 10, messages for the main message queue and ruleset queues, and for action queues. Disk assisted queues are unlimited by default and can not be restricted with this directive, but you can reserve them physical disk space in bytes with the following settings:.
Replace object with MainMsg or with Action. When the size limit specified by number is hit, messages are discarded until sufficient amount of space is freed by dequeued messages. When a queue reaches a certain number of messages, you can discard less important messages in order to save space in the queue for entries of higher priority. The threshold that launches the discarding process can be set with the so-called discard mark :. Here, number stands for a number of messages that have to be in the queue to start the discarding process.
To define which messages to discard, use:. Replace priority with one of the following keywords or with a number : debug 7 , info 6 , notice 5 , warning 4 , err 3 , crit 2 , alert 1 , and emerg 0.
With this setting, both newly incoming and already queued messages with lower than defined priority are erased from the queue immediately after the discard mark is reached. You can configure rsyslog to process queues during a specific time period. With this option you can, for example, transfer some processing into off-peak hours. To define a time frame, use the following syntax:.
With hour you can specify hours that bound your time frame. Use the hour format without minutes. A worker thread performs a specified action on the enqueued message. For example, in the main message queue, a worker task is to apply filter logic to each incoming message and enqueue them to the relevant action queues. When a message arrives, a worker thread is started automatically. When the number of messages reaches a certain number, another worker thread is turned on.
0コメント