Syslog

Severity

Each message Priority has a decimal Severity level indicator between 0 – 7. The lower the value, the higher the priority. RAPTOR’s Software is provisioned with more than 1500 SYSLOG messages covering errors, alerts, and major events. Table 1 shows the list of all severity levels along with their numerical values.

Priority

Each syslog message includes a priority value in the beginning of the text message. The priority value ranges between 0 to 191 and it made up of facility and severity values. The priority is enclosed with in “<>” delimiters. The formula for calculating the priority value is:

Priority Value = Facility Level Numerical Value + Severity Value

For example, for a local4 message (Facility level value 160) with a Severity of Notice (Severity=5), the Priority would have a Priority value of 165.

Facility

Facility code is used to specify the type of program logging the message. Messages with different facilities can be handled differently. This term comes into picture when we start using remote logging mechanism. There are total of 8 facility levels ranging between local0 and local7. Each facility level has a value assigned to it—local0 (128), local1 (136), local2 (144), local3(152), local4(160), local5(168), local6(176), and local7 (184). Raptor is configured with default facility level (local0) and all messages are sent with this facility level unless configured to use different facility level. The idea of the facility level configuration is to differentiate and filter logs.

Example of Valid Syslog Message

<165>1 2003-08-24T05:14:15.000003-07:00 192.0.2.1 su 8710 ID47 BOM 'su root' failed for lonvick on /dev/pts/8

This example of valid syslog messages is based on section 6.5 Examples of RFC 5425.

Factory Default Syslog Configuration Values

Shown below is the list of factory default values configured after a clean start.

Logging Mechanisms Types and Default Configuration

There are two types of local logging mechanisms. Mechanism 1 is stored in RAM and 2 is stored in Flash memory.

Local Logging Mechanism 1

In this mechanism, the Syslog messages are stored in RAM. Syslog client in Raptor can store 200 messages (default) at a time which can be configured to maximum of 4096 messages. Once the maximum level is reached, it rolls on i.e. the latest messages will be displayed and the oldest messages will be erased.

There is a rule in local logging mechanism as per which all levels below the configured reference severity level are automatically logged. For example, if critical is the default level with priority value of 2, the levels below are alert with a value of 1 and emergency (level 0). Both below levels are automatically logged. Therefore, there will be no need for configuration needed if the administrator needs to log only critical and levels below messages. If we had configured the logging severity as debugging whose value is 7 (the maximum), in that case, all severity levels (7-0) would have been logged automatically

CLI Commands for Local Logging Method 1

From the above shown CLI commands, the logging severity level is configured as debugging, and hence the priority value below 7 (emergency/alert/critical/error/warning/notice/info/debug) is automatically logged in RAM.

The “show logging” command lists all captured syslog messages in RAM. It displays the latest collected logs and deletes the oldest messages. The buffer size is set to max 4096 and the facility level configured is local0 (see below).

System Log Information

----------------------

Syslog logging : enabled(Number of messages 127)

Console logging : disabled(Number of messages 0)

TimeStamp option : enabled

Severity logging : Critical

Facility : local1

Buffered size : 4096 Entries

Local Logging Mechanism 2

This second local logging method is storing syslog messages in flash memory. We can set a file name of user choice in a flash and redirect all syslog messages to the created file. First, we create a file name and next associate the messages (based on severity) to the log file.

Each created file can accommodate 4 MB of data. Once the 4 MB data quota is reached, the log messages will be moved to the same file name with a .bk extension and a new file will be created (with the same name) in which the live logging will continue. This process is a repeating cycle, as each time 4 MB of data is reached, the old logs are moved to a .bk file and the live logging takes place in a new file. So, the flash consumption is restricted to max of 8MB (4 MB for. bk file which has the old log messages and 4 MB where the current live logging takes place).

There is CLI command to set the flash file size and its threshold limit at run time. This option helps user to maximize the file storage size from default 4 MB up to 10 MB. The CLI configuration is:

CLI Commands for Setting Flash Size and Threshold Limit

A maximum of 3 files can be created. The CLI commands for configuring the files are shown in the table below.

Logging to Flash Files CLI Commands

The original command provided was as shown in Table 6. In the original command, the user had to provide the priority value between 0-191. It is a bit tedious process to choose the value as the user had to do some calculation of the priority based on the numerical values of facility and severity level of the syslog message that needs to be logged on.

Therefore, the command had been simplified as shown in Table 6. The user does not need to provide the hard coded value but rather just specify the severity of the message that needs to be logged into the file.

Flash Space Restriction Mechanisms

All Syslog and other log files (fsir.log.xxx & audit log) are created and stored under /mnt/log flash folder. The capacity of the log folder is 118 MB. To prevent the flash log folder getting fully occupied, a restriction mechanism had been devised.

Warning Messages

When the usage of this folder reaches the threshold, in the console prompt, a warning message such as the one shown below is generated for the user. The warning will appear every time when there is an attempt for a syslog message to be logged in a flash file and until space in the flash file is freed.

Warning: Syslog flash storage crossed its threshold limit. Do you want to erase logs (Y/N) [N]?

If an user presses Yes, all log files in the flash log directory will be deleted.

If an user selects No or just presses Enter (i.e. the default option which is No is activated), the console prompt is returned to normal operation. The administrator can later transfer the log messages from the flash directory to an external Windows / Linux machine and erase the logs to save space. The CLI configuration commands to do the same are outlined in Table 7.

Error Messages

When the flash is occupied to its maximum capacity of 118 MB, a second level of restriction mechanism is activated, and an error message as captured below is generated. The user will be prevented from creating new file.

iS5Comm <config># syslog filename-two <string(32)>

ERROR: Flash space exhausted. Please delete log files and then try again

iS5Comm <config>#

USB option for copying logs to external USB flash drive

There will be a new CLI command added for copying the Syslog file from internal flash to external USB flash drive. The command is outlines in the table below.

CLI Command for Listing File Contents of Flash

Example configuration for Local (Flash) Logging

iS5Comm <config># logging severity debugging

iS5Comm <config># syslog filename-one one 

iS5Comm <config># syslog filename-two two

iS5Comm <config># syslog filename-three three

iS5Comm <config># logging local flash debugging file one

iS5Comm <config># logging local flash alert file two

iS5Comm <config># logging local flash critical file three 

iS5Comm <config># end

As per the example configuration shown above, the above set of configurations creates flash file named “one”, “two”, and “three” in the flash directory /mnt/log/ and the debugging severity messages are directed to file “one”, alert severity messages are directed to “two”, and critical severity messages are directed to “three”.

For instance, if file “one” has reached its quota 4 MB, the log messages in file “one” is backed up in a new file named “one.bk” and the newly generated messages are still logged to file “one” as a new file. This cycle is repeated every time 4 MB is reached.

Remote Logging

The remote logging is transferring the Syslog messages to syslog remote server running in any Windows/Linux machine. These messages are transferred instantly when an event (e.g. Link up/down, attaining max temperature threshold) occurs in RAPTOR via a UDP socket. These messages can be filtered based on the severity & facility level.

For the remote logging to take place, first we need to set the reference severity, and then configure which severity to be logged to the remote syslog server. The default logging severity is Critical (3). So, when an event occurs the SYSLOG client application first check if the severity level of the message is less that or equal to reference severity level, and second, it checks if there is any remote server configured for that severity. Only if both conditions are satisfied, the log will be transferred to the remote server.

Remote Logging Syslog CLI Commands

The original CLI command for logging the message to remote server is shown in Table 10. In a similar manner as the logging-file CLI command, this command also requires a user to specify the priority value between 0-191. loggingfile CLI command had been replaced with a CLI commands for remote logging which uses severity levels instead of priority levels. The new CLI commands for remote logging are displayed in Table 11.

We can have maximum of seven different syslog server IP address configurations, and ideally each severity level (total 0 - 7) can be logged to eight different servers.

Remote Logging Syslog Facility Level Configuration

There are eight facility levels in total which can be configured. The purpose of these commands is to differentiate and filter syslog messages in the external syslog severs. The default facility is Local0.

Example 1 for Configuration for Remote Logging

iS5Comm <config># logging severity debugging

iS5Comm <config># logging remote debugging ipv4 192.168.10.67

iS5Comm <config># remote critical ipv4 192.168.10.68

iS5Comm <config># end

The above set of configurations logs debugging severity messages under facility level local1. Facility level is a onetime configuration. Once it is set, all message generation will follow the same facility level, i.e. severity cannot be set to different facility level.

Example 2 for Configuration for Remote Logging

iS5Comm <config># logging severity debugging

iS5Comm <config># logging facility local1

iS5Comm <config># logging remote debugging ipv4 192.168.10.67

iS5Comm <config># end

The above set of configurations logs debugging severity messages under facility level local1. Facility level is a onetime configuration, and once it is set, all message generation will follow the same facility level, i.e. severity cannot be set with different facility level.

Syslog List

What follows is a list of the Syslogs supported by the device.