Sign In with your
Trend Micro Account
Need Help?
Need More Help?

Create a technical support case if you need further support.

What are Syslog Facilities and Levels?

    • Updated:
    • Product/Version:
    • TippingPoint SMS All
    • TippingPoint Virtual SMS
    • Platform:
Summary
This bulletin describes the parts of Syslog protocol, which is used to convey event notification messages.
Details
Public

SMS events can be directed to a remote Syslog server. Through the SMS Admin interface, you can configure which events are sent to a remote Syslog server. When you create a new remote Syslog server, you have the option to exclude backlog events.

Each Syslog message includes a priority value at the beginning of the text. The priority value ranges from 0 to 191 and is not space or leading zero padded. The priority is enclosed in "<>" delimiters. E.g. <PRI>HEADER MESSAGE.

The priority value is calculated using the formula (Priority = Facility * 8 + Level). For example, a kernel message (Facility=0) with a Severity of Emergency (Severity=0) would have a Priority value of 0. Also, a "local use 4" message (Facility=20) with a Severity of Notice (Severity=5) would have a Priority value of 165.

Syslog Facilities

The facility represents the machine process that created the syslog event. For example, is the event created by the kernel, by the mail system, by security/authorization processes, etc.? In the context of this field, the facility represents a kind of filter, instructing SMS to forward to the remote Syslog Server only those events whose facility matches the one defined in this field. So by changing the facility number and/or the severity level you change the amount of alerts (messages) that are sent to the remote syslog server

The Facility value is a way of determining which process of the machine created the message. Since the Syslog protocol was originally written on BSD Unix, the Facilities reflect the names of UNIX processes and Daemons.

List of available Facilities as per RFC5424:

Facility NumberFacility DescriptionFacility NumberFacility Description
0kernel messages12NTP subsystem
1user-level messages13log audit
2mail system14log alert
3system daemons15clock daemon
4**security/authorization messages16local use 0 (local0)
5messages generated internally by syslog17local use 1 (local1)
6line printer subsystem18local use 2 (local2)
7network news subsystem19local use 3 (local3)
8UUCP subsystem20local use 4 (local4)
9clock daemon21local use 5 (local5)
10security/authorization messages22local use 6 (local6)
11FTP daemon23local use 7 (local7)
** SMS default
Note: Items in yellow are the facility numbers available on the SMS.


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

Syslog Severity Levels

Recommended practice is to use the Notice or Informational level for normal messages.

Explanation of the severity Levels:

SEVERITY LEVELEXPLANATION
**SEVERITY IN EVENTDefault SMS setting for Syslog Security option. This setting will send all events to remote Syslog system
0EMERGENCYA "panic" condition - notify all tech staff on call? (Earthquake? Tornado?) - affects multiple apps/servers/sites.
1ALERTShould be corrected immediately - notify staff who can fix the problem - example is loss of backup ISP connection.
2CRITICALShould be corrected immediately, but indicates failure in a primary system - fix CRITICAL problems before ALERT - example is loss of primary ISP connection.
3ERRORNon-urgent failures - these should be relayed to developers or admins; each item must be resolved within a given time.
4WARNINGWarning messages - not an error, but indication that an error will occur if action is not taken, e.g. file system 85% full - each item must be resolved within a given time.
5NOTICEEvents that are unusual but not error conditions - might be summarized in an email to developers or admins to spot potential problems - no immediate action required.
6INFORMATIONALNormal operational messages - may be harvested for reporting, measuring throughput, etc. - no action required.
7DEBUGInfo useful to developers for debugging the app, not useful during operations.
** SMS default


The following is a list of RFCs that define the Syslog protocol:

  • RFC 3195 Reliable Delivery for syslog
  • RFC 5424 The Syslog Protocol
  • RFC 5425 TLS Transport Mapping for Syslog
  • RFC 5426 Transmission of Syslog Messages over UDP
  • RFC 5427 Textual Conventions for Syslog Management
  • RFC 5848 Signed Syslog Messages
  • RFC 6012 Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog
Premium
Internal
Rating:
Category:
Configure; Troubleshoot; Deploy
Solution Id:
TP000086250
Feedback
Did this article help you?

Thank you for your feedback!

To help us improve the quality of this article, please leave your email here so we can clarify further your feedback, if neccessary:
We will not send you spam or share your email address.

*This form is automated system. General questions, technical, sales, and product-related issues submitted through this form will not be answered.

If you need additional help, you may try to contact the support team. Contact Support


To help us improve the quality of this article, please leave your email here so we can clarify further your feedback, if neccessary:
We will not send you spam or share your email address.

*This form is automated system. General questions, technical, sales, and product-related issues submitted through this form will not be answered.