Documentation forSolarWinds Platform Self-Hosted

Syslog message priorities

This topic applies to the following products if you are NOT using the Orion Log Viewer to monitor syslogs.

DPAIMNAMNCMNPMNTASAMSRMVNQM

At the beginning of each Syslog message, there is a priority value. The priority value is calculated using the following formula:

Priority = Facility * 8 + Severity

Syslog facilities

The facility value indicates which machine process created the message. The Syslog protocol was originally written on BSD Unix, so Facilities reflect the names of UNIX processes and daemons.

If you are receiving messages from a UNIX system, consider using the User Facility as your first choice. Local0 through Local7 are not used by UNIX and are traditionally used by networking equipment. Cisco routers, for example, use Local6 or Local7.

Number

Source

Number

Source

0

kernel messages

12

NTP subsystem

1

user-level messages

13

log audit

2

mail system

14

log  alert

3

system daemons

15

clock daemon

4

security/authorization messages

16

local use 0 (local0)

5

messages generated internally by Syslog

17

local use 1 (local1)

6

line printer subsystem

18

local use 2 (local2)

7

network news subsystem

19

local use 2 (local3)

8

UUCP subsystem

20

local use 2 (local4)

9

clock daemon

21

local use 2 (local5)

10

security/authorization messages

22

local use 2 (local6)

11

FTP daemon

23

local use 2 (local7)

Syslog severities

The following table provides a list of Syslog severity levels with descriptions and suggested actions for each.

Number

Severity

Suggested Actions

0

Emergency

A "panic" condition affecting multiple applications, servers, or sites. System is unusable. Notify all technical staff on call.

1

Alert

A condition requiring immediate correction, for example, the loss of a backup ISP connection. Notify staff who can fix the problem.

2

Critical

A condition requiring immediate correction or indicating a failure in a primary system, for example, a loss of a primary ISP connection. Fix CRITICAL issues before ALERT-level problems.

3

Error

Non-urgent failures. Notify developers or administrators as errors must be resolved within a given time.

4

Warning

Warning messages are not errors, but they indicate that an error will occur if required action is not taken. An example is a file system that is 85% full. Each item must be resolved within a given time.

5

Notice

Events that are unusual but are not error conditions. These items might be summarized in an email to developers or administrators to spot potential problems. No immediate action is required.

6

Informational

Normal operational messages. These may be harvested for network maintenance functions like reporting and throughput measurement. No action is required.

7

Debug

Information useful to developers for debugging an application. This information is not useful during operations.