Alarms in Syslog
Extracted elements (9)
Both 'resource' and 'resourceURI' point at the alarmed resource, but 'resourceURI' adds a syntactic URI constraint enabling easy cross-protocol alarm correlation with SNMP or other management protocols.
Syslog severity values do not map one-to-one to ITU perceived severities, so a STRUCTURED-DATA element is defined to carry the unmodified ITU perceived severity alongside the approximate syslog SEVERITY mapping.
For SNMP resources, the 'resourceURI' value must use RFC 4088 URI syntax and must point to the same resource as alarmActiveResourceId (RFC 3877), enabling correlation between syslog alarms and SNMP alarms.
If the 'alarm' SD-ID is included, the 'resourceURI' SD-PARAM SHOULD be included. Its value MUST conform to the URI definition in RFC 3986; for SNMP resources, the syntax in RFC 4088 MUST be used.
The mapping in Table 1 SHOULD be used to map ITU perceived severities to syslog severities: Critical→Alert(1), Major→Critical(2), Minor→Error(3), Warning→Warning(4), Indeterminate→Notice(5), Cleared→Notice(5).
The 'alarm' SD-ID is an optional STRUCTURED-DATA element that carries alarm-specific fields in syslog messages, including resource, probableCause, perceivedSeverity, eventType, trendIndication, and resourceURI.
IANA registered the syslog Structured Data ID 'alarm' and its PARAM-NAMEs: resource (MANDATORY), probableCause (MANDATORY), perceivedSeverity (MANDATORY), eventType (OPTIONAL), trendIndication (OPTIONAL), resourceURI (OPTIONAL). The SD-ID itself is OPTIONAL.
Alarm information may disclose to attackers which parts of a system are under stress and general system inventory details. Users should not have access to alarm data that exceeds their normal access permissions.
There is no standardized access control model for syslog, so the ability to filter alarms based on receiver identity is at best implementation-specific.