Alarms in Syslog
RFC 5674
|
Document |
Type |
|
RFC - Proposed Standard
(October 2009; No errata)
|
|
Authors |
|
Sharon Chisholm
,
Rainer Gerhards
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
html
pdf
htmlized
bibtex
|
|
Reviews |
|
|
Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
IESG |
IESG state |
|
RFC 5674 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Dan Romascanu
|
|
Send notices to |
|
(None)
|
Network Working Group S. Chisholm
Request for Comments: 5674 Nortel
Category: Standards Track R. Gerhards
Adiscon GmbH
October 2009
Alarms in Syslog
Abstract
This document describes how to send alarm information in syslog. It
includes the mapping of ITU perceived severities onto syslog message
fields. It also includes a number of alarm-specific SD-PARAM
definitions from X.733 and the IETF Alarm MIB.
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Chisholm & Gerhards Standards Track [Page 1]
RFC 5674 Alarms in Syslog October 2009
Table of Contents
1. Introduction ....................................................2
2. Severity Mapping ................................................2
3. Alarm STRUCTURED-DATA Elements ..................................3
3.1. resource ...................................................3
3.2. probableCause ..............................................4
3.3. perceivedSeverity ..........................................4
3.4. eventType ..................................................4
3.5. trendIndication ............................................4
3.6. resourceURI ................................................5
4. Examples ........................................................5
5. Security Considerations .........................................6
6. IANA Considerations .............................................6
7. Acknowledgments .................................................6
8. References ......................................................7
8.1. Normative References .......................................7
8.2. Informative References .....................................7
1. Introduction
In addition to sending out alarm information asynchronously via
protocols such as the Simple Network Management Protocol (SNMP) or
the Network Configuration Protocol (Netconf), many implementations
also log alarms via syslog. This memo defines a set of SD-PARAMs to
support logging and defines a mapping of syslog severity to the
severity of the alarm.
The Alarm MIB [RFC3877] includes mandatory alarm fields from X.733
[X.733] as well as information from X.736 [X.736]. In additional,
the Alarm MIB introduces its own alarm fields. This memo reuses
terminology and fields from the Alarm MIB.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Alarm-related terminology is defined in [RFC3877].
SD-ID, SD-PARAM, and other syslog-related terms are defined in
[RFC5424].
2. Severity Mapping
The Alarm MIB [RFC3877] defines ITU perceived severities; it is
useful to be able to relate these to the syslog message fields,
particularly in the case where alarms are being logged. This memo
describes the representation of ITU perceived severities in
Chisholm & Gerhards Standards Track [Page 2]
RFC 5674 Alarms in Syslog October 2009
appropriate syslog fields, which are described in [RFC5424]. Syslog
offers both a so-called SEVERITY as well as STRUCTURED-DATA. Due to
constraints in syslog, there is no one-to-one mapping possible for
SEVERITY. A STRUCTURED-DATA element is defined in this document to
allow inclusion of the unmodified ITU perceived severity.
Syslog supports Severity values different from ITU perceived
severities. These are defined in Section 6.2.1 of [RFC5424]. The
Show full document text