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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクション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
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-PARAMSのセットを定義し、アラームの重大度にsyslogの重大度のマッピングを定義します。
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.736 [X.736]から必須のアラームX.733 [X.733]からフィールドならびに情報を含みます。追加では、アラーム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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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、および他のsyslog関連用語は、[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 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.
アラームMIB [RFC3877]はITU知覚重大度を定義します。特にアラームが記録されている場合には、シスログメッセージフィールドにこれらを関連付けることができるように有用です。このメモは、ITUの表現は[RFC5424]に記載されている適切なsyslogの分野で重大度を知覚記述する。 syslogは、いわゆる重症度だけでなく、構造化データの両方を提供しています。 syslogに制約により、SEVERITYのための可能な1対1のマッピングはありません。構造化データ要素は、非修飾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は、syslogの重大度に重大度を知覚マッピングするために使用されるべきです。
ITU Perceived Severity syslog SEVERITY (Name)
Critical 1 (Alert)
Major 2 (Critical)
Minor 3 (Error)
Warning 4 (Warning)
Indeterminate 5 (Notice)
Cleared 5 (Notice)
Table 1. ITUPerceivedSeverity to Syslog SEVERITY Mapping
Syslogの重大度のマッピングを表1 ITUPerceivedSeverity
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は、syslogメッセージに任意の構造化された情報を含めることを可能にします。以下は、アラーム情報の構造化をサポートするために、このドキュメントで定義されています。
o Resource Under Alarm
Oリソースの下でアラーム
o Probable Cause
O考えられる原因
o Event Type
Oイベントの種類
o Perceived Severity
O知覚重要度
o Trend Indication
トレンドの表示
o Resource 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が含まれている場合は、「probableCause」SD-PARAMを含まなければなりません。このパラメータは、[RFC3877]内で定義されたIANAItuProbableCauseオブジェクトとIANAによって定義された任意の後続の拡張機能に関連付けられたニーモニックです。例えば、IANAItuProbableCause「はtransmissionError（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が含まれている場合は、「perceivedSeverity」SD-PARAMを含まなければなりません。 [X.736]で知覚重症度の定義と[RFC3877]と同様に、この目的は、以下の値をとることができます。
o cleared
Oクリア
o indeterminate
O不定
o critical
重要O
o major
主要なO
o minor
お みのｒ
o warning
o警告
See Section 2 for the relationship between this severity and syslog severity.
この重大度とsyslogの重症度との関係については、セクション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が含まれている場合は、「trendIndication」SD-PARAMが含まれるべきです。 [X.733]で知覚重症度の定義と[RFC3877]と同様に、この目的は、以下の値をとることができます。
o moreSevere
moreSevere上
o noChange
O NOCHANGE
o lessSevere
O lessSevere
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.
このフィールドの値は、URI [RFC3986]で定義し、その更新に従わなければなりません。 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.
「リソース」と「resourceURI」パラメータの両方は、アラームが発生してリソースを指すが、「resourceURIは、」URIであることを必要と構文制約を有しています。これは、SNMPなどの他のプロトコルを介して受信されているすべてのアラームでこのsyslogのアラームを相関させる、またはこのリソースに関する追加情報を取得するために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> 1 2003-10-11T22：14：15.003Z mymachine.example.com evntslog - ID47 [exampleSDID @ 32473 IUT = "3" のEventSource = "アプリケーション" のeventID = "1011"] [アラーム資源= "SUルート" probableCause = "unauthorizedAccessAttempt" perceivedSeverity = "大手"] 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であり、ファシリティは、重大度が2のメッセージは、次の第二に午前10時14分15秒PM UTC、3ミリ秒で2003年10月11日に作成されました4の値を有します。 。メッセージは「mymachine.example.com」として自分自身を識別するホストから発信しました。 APP-NAMEは、「evntslog」であるとPROCIDは不明です。 MSGIDは "ID47" です。我々は、定義されたアラーム情報を「[exampleSDID @ 32473 IUT =」3" のEventSource = 『』のeventID = 『1011アプリケーション』]」、および新しい要素元の例から構造化データ、値を持つ単一要素の両方を含んでいますこのメモインチアラームSD-IDは、リソース、probableCause、およびpreceivedSeverityの必須SD-PARAMSが含まれています。 MSG自体は、「アプリケーションイベントログエントリ...」MSGの先頭に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 [アラーム資源= "インターフェース42" probableCause = "unauthorizedAccessAttempt" perceivedSeverity = "主要な" 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：この例では、我々は2つのオプションのアラームフィールドを含みます。
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]で説明した一般的なsyslogのセキュリティ問題に加えて、アラームで含まれている情報は、在庫、現在のストレスを経験するシステムの部分に関する有用な情報、ならびにシステムに関する一般的な情報と、ハッカーを提供することができます。
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値を登録して、以下に示すPARAM-NAMES：
SD-ID PARAM-NAME alarm OPTIONAL resource MANDATORY probableCause MANDATORY perceivedSeverity MANDATORY eventType OPTIONAL trendIndication OPTIONAL resourceURI OPTIONAL
SD-ID PARAM-NAMEのアラームオプションのリソースMANDATORY probableCause MANDATORY perceivedSeverity MANDATORYのeventTypeオプションtrendIndicationオプションresourceURIオプション
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ワークグループのメンバーに感謝します。我々はまた、彼らのレビューのためにユルゲンSchoenwaelder、デイブ・ハリントン、ウェスHardaker、およびランディPresuhnに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3877] Chisholm, S. and D. Romascanu, "Alarm Management Information Base (MIB)", RFC 3877, September 2004.
[RFC3877]チザム、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]バーナーズ - リー、T.、フィールディング、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]ブラック、D.、McCloghrie、K.、およびJ. Schoenwaelder、 "統一資源識別子（URI）簡易ネットワーク管理プロトコル（SNMP）のためのスキーム"、RFC 4088、2005年6月。
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5424] Gerhards氏、R.、 "Syslogのプロトコル"、RFC 5424、2009年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.736、1992。
Authors' Addresses
著者のアドレス
Sharon Chisholm Nortel 3500 Carling Ave Nepean, Ontario K2H 8E9 Canada
シャロン・チザムノーテル3500カーリングアベニューオタワ、オンタリオK2H 8E9カナダ
EMail: schishol@nortel.com
メールアドレス：schishol@nortel.com
Rainer Gerhards Adiscon GmbH Mozartstrasse 21 Grossrinderfeld, BW 97950 Germany
レイナー・ガーハーズAdiscon社Mozartstrasse 21頭の大きな牛フィールド、BW 97950ドイツ
EMail: rgerhards@adiscon.com
メールアドレス：rgerhards@adiscon.com