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, in 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 number 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 Number | Facility Description | Facility Number | Facility Description | |
| 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 3 (local3) | |
| 8 | UUCP subsystem | 20 | local use 4 (local4) | |
| 9 | clock daemon | 21 | local use 5 (local5) | |
| 10 | security/authorization messages | 22 | local use 6 (local6) | |
| 11 | FTP daemon | 23 | local use 7 (local7) | |
| ** SMS default Note: Items in yellow are the facility numbers available on the SMS. Note: These Facility Numbers are only applicable to the T/TX products. The N/NX will not use these values and will always report 0. |
||||
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 LEVEL | EXPLANATION | |
| ** | SEVERITY IN EVENT | Default SMS setting for Syslog Security option. This setting will send all events to the remote Syslog system |
| 0 | EMERGENCY | A "panic" condition - notify all tech staff on call? (Earthquake? Tornado?) - affects multiple apps/servers/sites. |
| 1 | ALERT | Should be corrected immediately - notify staff who can fix the problem - an example is loss of backup ISP connection. |
| 2 | CRITICAL | Should be corrected immediately, but indicates failure in a primary system - fix CRITICAL problems before ALERT - an example is loss of primary ISP connection. |
| 3 | ERROR | Non-urgent failures - these should be relayed to developers or admins; each item must be resolved within a given time. |
| 4 | WARNING | Warning messages - not an error, but indicated 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. |
| 5 | NOTICE | Events 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. |
| 6 | INFORMATIONAL | Normal operational messages - may be harvested for reporting, measuring throughput, etc. - no action required. |
| 7 | DEBUG | Info is 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