Network Working Group S. Chisholm
Request for Comments: 5674 Nortel
Category: Standards Track R. Gerhards
Adiscon GmbH
October 2009
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.
本文档介绍如何在syslog中发送报警信息。它包括将ITU感知的严重性映射到syslog消息字段。它还包括X.733和IETF报警MIB中的一些特定于报警的SD-PARAM定义。
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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括《信托法律条款》第4.e节中所述的简化BSD许可文本，并且提供BSD许可中所述的代码组件时不提供任何担保。
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 ....................................................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
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.
除了通过简单网络管理协议（SNMP）或网络配置协议（Netconf）等协议异步发送报警信息外，许多实现还通过syslog记录报警。此备忘录定义了一组支持日志记录的SD参数，并定义了系统日志严重性与报警严重性的映射。
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.
报警MIB[RFC3877]包括来自X.733[X.733]的强制报警字段以及来自X.736[X.736]的信息。此外，报警MIB还引入了自己的报警字段。此备忘录重用报警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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Alarm-related terminology is defined in [RFC3877].
[RFC3877]中定义了报警相关术语。
SD-ID, SD-PARAM, and other syslog-related terms are defined in [RFC5424].
SD-ID、SD-PARAM和其他系统日志相关术语在[RFC5424]中定义。
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
报警MIB[RFC3877]定义了ITU感知的严重性；能够将这些字段与syslog消息字段关联非常有用，尤其是在记录报警的情况下。本备忘录描述了国际电联感知的严重性在
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.
[RFC5424]中描述的相应系统日志字段。Syslog提供了所谓的严重性和结构化数据。由于syslog中的限制，严重性不可能一对一映射。本文件中定义了结构化数据元素，以允许包含未修改的ITU感知严重性。
Syslog supports Severity values different from ITU perceived severities. These are defined in Section 6.2.1 of [RFC5424]. The mapping shown in Table 1 below SHOULD be used to map ITU perceived severities to syslog severities.
Syslog支持不同于ITU感知严重性的严重性值。这些在[RFC5424]第6.2.1节中定义。应使用下表1中所示的映射将ITU感知的严重性映射到系统日志严重性。
ITU Perceived Severity syslog SEVERITY (Name) Critical 1 (Alert) Major 2 (Critical) Minor 3 (Error) Warning 4 (Warning) Indeterminate 5 (Notice) Cleared 5 (Notice)
ITU感知严重性系统日志严重性（名称）严重1（警报）严重2（严重）轻微3（错误）警告4（警告）不确定5（通知）清除5（通知）
Table 1. ITUPerceivedSeverity to Syslog SEVERITY Mapping
表1。iTunesPerceivedSeverity到系统日志严重性映射
STRUCTURED-DATA allows the inclusion of any structured information into a syslog message. The following are defined in this document to support the structuring of alarm information.
STRUCTURED-DATA允许将任何结构化信息包含到系统日志消息中。本文件中定义了以下内容，以支持报警信息的结构。
o Resource Under Alarm
o 警觉中的资源
o Probable Cause
o 可能原因
o Event Type
o 事件类型
o Perceived Severity
o 感知严重性
o Trend Indication
o 趋势指示
o Resource URI
o 资源URI
Support of the "alarm" SD-ID is optional but, once supported, some of the SD-PARAMS are mandatory.
支持“报警”SD-ID是可选的，但一旦支持，一些SD-PARAMS是强制性的。
If the "alarm" SD-ID is included, the "resource" SD-PARAM MUST be included. This item uniquely identifies the resource under alarm within the scope of a network element.
如果包含“报警”SD-ID，则必须包含“资源”SD-PARAM。此项唯一标识网元范围内处于报警状态的资源。
If the "alarm" SD-ID is included, the "probableCause" SD-PARAM MUST be included. This parameter is the mnemonic associated with the IANAItuProbableCause object defined within [RFC3877] and any subsequent extensions defined by IANA. For example, IANAItuProbableCause defines a transmission failure to a probable cause of 'transmissionError (10)'. The value of the parameter in this case would be 'transmissionError'.
如果包含“报警”SD-ID，则必须包含“可能原因”SD-PARAM。此参数是与[RFC3877]中定义的IAAITURBABLECAUSE对象以及IANA定义的任何后续扩展相关联的助记符。例如，IANAITUPBABLECAUSE将变速器故障定义为“变速器错误（10）”的可能原因。在这种情况下，参数的值为“transmissionError”。
If the "alarm" SD-ID is included, the "perceivedSeverity" SD-PARAM MUST be included. Similar to the definition of perceived severity in [X.736] and [RFC3877], this object can take the following values:
如果包含“报警”SD-ID，则必须包含“感知严重性”SD-PARAM。与[X.736]和[RFC3877]中的感知严重性定义类似，此对象可以采用以下值：
o cleared
o 变明朗
o indeterminate
o 不确定的
o critical
o 批评的
o major
o 专业
o minor
o 少数的
o warning
o 警告
See Section 2 for the relationship between this severity and syslog severity.
有关此严重性和系统日志严重性之间的关系，请参见第2节。
If the "alarm" SD-ID is included, the "eventType" SD-PARAM SHOULD be included. This parameter is the mnemonic associated with the IANAItuEventType object defined within [RFC3877] and any subsequent extensions defined by IANA. For example, IANAItuEventType defines an environmental alarm to an event type of 'environmentalAlarm (6)'. The value of the parameter in this case would be 'environmentalAlarm'.
如果包含“报警”SD-ID，则应包含“eventType”SD-PARAM。此参数是与[RFC3877]中定义的IANAItuEventType对象以及IANA定义的任何后续扩展相关联的助记符。例如，IANAItuEventType将环境警报定义为事件类型“environmentalAlarm（6）”。在本例中，参数的值为“environmentalAlarm”。
If the "alarm" SD-ID is included, the "trendIndication" SD-PARAM SHOULD be included. Similar to the definition of perceived severity in [X.733] and [RFC3877], this object can take the following values:
如果包括“报警”SD-ID，则应包括“趋势指示”SD-PARAM。与[X.733]和[RFC3877]中的感知严重性定义类似，此对象可以采用以下值：
o moreSevere
o 更严重
o noChange
o 不改变
o lessSevere
o 莱塞维尔
If the "alarm" SD-ID is included, the "resourceURI" SD-PARAM SHOULD be included. This item uniquely identifies the resource under alarm.
如果包含“报警”SD-ID，则应包含“resourceURI”SD-PARAM。此项唯一标识报警下的资源。
The value of this field MUST conform to the URI definition in [RFC3986] and its updates. In the case of an SNMP resource, the syntax in [RFC4088] MUST be used and "resourceURI" must point to the same resource as alarmActiveResourceId [RFC3877] for this alarm.
此字段的值必须符合[RFC3986]及其更新中的URI定义。对于SNMP资源，必须使用[RFC4088]中的语法，并且“resourceURI”必须指向与此警报的alarmActiveResourceId[RFC3877]相同的资源。
Both the "resource" and the "resourceURI" parameters point at the resource experiencing the alarm, but the "resourceURI" has syntactic constraint requiring it to be a URI. This makes it easy to correlate this syslog alarm with any alarms that are received via other protocols, such as SNMP, or to use SNMP or other protocols to get additional information about this resource.
“resource”和“resourceURI”参数都指向发生警报的资源，但“resourceURI”具有语法约束，要求它是URI。这使得将此syslog报警与通过其他协议（如SNMP）接收的任何报警关联起来变得很容易，或者使用SNMP或其他协议来获取有关此资源的其他信息。
Example 1 - Mandatory Alarm Information
示例1-强制报警信息
<165>1 2003-10-11T22:14:15.003Z mymachine.example.com evntslog - ID47 [exampleSDID@32473 iut="3" eventSource= "Application" eventID="1011"][alarm resource="su root" probableCause="unauthorizedAccessAttempt" perceivedSeverity="major"] BOMAn application event log entry...
<165>12003-10-11T22:14:15.003Z mymachine.example.com evntslog-ID47[exampleSDID@32473iut=“3”eventSource=“Application”eventID=“1011”][alarm resource=“su root”probableCause=“UnauthorizedAccessTest”perceivedSeverity=“major”]BOMAn应用程序事件日志条目。。。
In this example, extended from [RFC5424], the VERSION is 1 and the Facility has the value of 4. The severity is 2. The message was created on 11 October 2003 at 10:14:15pm UTC, 3 milliseconds into the next second. The message originated from a host that identifies itself as "mymachine.example.com". The APP-NAME is "evntslog" and the PROCID is unknown. The MSGID is "ID47". We have included both the structured data from the original example, a single element with the value "[exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"]", and a new element with the alarm information defined in this memo. The alarm SD-ID contains the mandatory SD-PARAMS of resource, probableCause, and preceivedSeverity. The MSG itself is "An application event log entry..." The BOM at the beginning of the MSG indicates UTF-8 encoding.
在本例中，从[RFC5424]扩展而来，版本为1，设施的值为4。严重程度为2。该消息创建于2003年10月11日UTC时间晚上10:14:15，再过3毫秒。该消息来自一个将自身标识为“mymachine.example.com”的主机。APP-NAME为“evntslog”，PROCID未知。MSGID是“ID47”。我们已经包含了原始示例中的结构化数据，一个值为“的元素”[exampleSDID@32473iut=“3”eventSource=“Application”eventID=“1011”]”，以及具有此备忘录中定义的报警信息的新元素。报警SD-ID包含resource、probableCause和PrevivedSeverity的强制SD-PARAMS。消息本身是“应用程序事件日志条目…”消息开头的BOM表示UTF-8编码。
Example 2 - Additional Alarm Information
示例2-附加报警信息
<165>1 2004-11-10T20:15:15.003Z mymachine.example.com
evntslog - ID48 [alarm resource="interface 42"
probableCause="unauthorizedAccessAttempt"
perceivedSeverity="major"
eventType="communicationsAlarm"
resourceURI="snmp://example.com//1.3.6.1.2.1.2.2.1.1.42"]
<165>1 2004-11-10T20:15:15.003Z mymachine.example.com
evntslog - ID48 [alarm resource="interface 42"
probableCause="unauthorizedAccessAttempt"
perceivedSeverity="major"
eventType="communicationsAlarm"
resourceURI="snmp://example.com//1.3.6.1.2.1.2.2.1.1.42"]
In this example, we include two optional alarm fields: eventType and resourceURI.
在本例中，我们包括两个可选的报警字段：eventType和resourceURI。
In addition to the general syslog security considerations discussed in [RFC5424], the information contained with alarms may provide hackers with helpful information about parts of the system currently experiencing stress as well as general information about the system, such as inventory.
除了[RFC5424]中讨论的一般系统日志安全注意事项外，警报中包含的信息可能会为黑客提供有关系统当前承受压力的部分的有用信息以及有关系统的一般信息，如库存。
Users should not have access to information in alarms that their normal access permissions would not permit if the information were accessed in another manner.
如果以其他方式访问信息，则用户不应访问其正常访问权限不允许的报警中的信息。
There is no standardized access control model for syslog, and hence the ability to filter alarms based on a notion of a receiver identity is, at best, implementation specific.
syslog没有标准化的访问控制模型，因此，基于接收器标识概念过滤警报的能力最多是特定于实现的。
IANA registered the syslog Structured Data ID values and PARAM-NAMEs shown below:
IANA注册了syslog结构化数据ID值和参数名称，如下所示：
SD-ID PARAM-NAME alarm OPTIONAL resource MANDATORY probableCause MANDATORY perceivedSeverity MANDATORY eventType OPTIONAL trendIndication OPTIONAL resourceURI OPTIONAL
SD-ID参数名称报警可选资源强制可能原因强制感知严重性强制事件类型可选趋势指示可选资源URI可选
Thanks to members of the Syslog and OPSAWG work group who contributed to this specification. We'd also like to thank Juergen Schoenwaelder, Dave Harrington, Wes Hardaker, and Randy Presuhn for their reviews.
感谢Syslog和OPSAWG工作组中对本规范做出贡献的成员。我们还要感谢Juergen Schoenwaelder、Dave Harrington、Wes Hardaker和Randy Presuhn的评论。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3877] Chisholm, S. and D. Romascanu, "Alarm Management Information Base (MIB)", RFC 3877, September 2004.
[RFC3877]Chisholm，S.和D.Romascanu，“报警管理信息库（MIB）”，RFC 3877，2004年9月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC4088] Black, D., McCloghrie, K., and J. Schoenwaelder, "Uniform Resource Identifier (URI) Scheme for the Simple Network Management Protocol (SNMP)", RFC 4088, June 2005.
[RFC4088]Black，D.，McCloghrie，K.，和J.Schoenwaeld，“简单网络管理协议（SNMP）的统一资源标识符（URI）方案”，RFC 4088，2005年6月。
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5424]Gerhards，R.，“系统日志协议”，RFC 54242009年3月。
[X.733] ITU-T, "Information Technology - Open Systems Interconnection - System Management: Alarm Reporting Function", ITU-T X.733, 1992.
[X.733]ITU-T，“信息技术-开放系统互连-系统管理：报警报告功能”，ITU-T X.733，1992年。
[X.736] ITU-T, "Information Technology - Open Systems Interconnection - System Management: Security Alarm Reporting Function", ITU-T X.736, 1992.
[X.736]ITU-T，“信息技术-开放系统互连-系统管理：安全警报报告功能”，ITU-T X.7361992。
Authors' Addresses
作者地址
Sharon Chisholm Nortel 3500 Carling Ave Nepean, Ontario K2H 8E9 Canada
加拿大安大略省内皮恩卡林大道3500号莎伦·奇肖姆北电K2H 8E9
EMail: schishol@nortel.com
EMail: schishol@nortel.com
Rainer Gerhards Adiscon GmbH Mozartstrasse 21 Grossrinderfeld, BW 97950 Germany
Rainer Gerhards Adiscon GmbH Mozartstrasse 21 Grossrinderfeld，BW 97950德国
EMail: rgerhards@adiscon.com
EMail: rgerhards@adiscon.com