RFC1224 日本語訳
1224 Techniques for managing asynchronously generated alerts. L.Steinberg. May 1991. (Format: TXT=54303 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group L. Steinberg
Request for Comments: 1224 IBM Corporation
May 1991
コメントを求めるワーキンググループL.スタインバーグ要求をネットワークでつないでください: 1224 IBM社の1991年5月
Techniques for Managing Asynchronously Generated Alerts
管理するためのテクニックは警戒を非同期に生成しました。
Status of this Memo
このMemoの状態
This memo defines common mechanisms for managing asynchronously produced alerts in a manner consistent with current network management protocols.
このメモは、現在のネットワーク管理プロトコルと一致した方法における非同期に生産された警戒を管理するために一般的なメカニズムを定義します。
This memo specifies an Experimental Protocol for the Internet community. Discussion and suggestions for improvement are requested. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このメモはExperimentalプロトコルをインターネットコミュニティに指定します。 議論と改善提案は要求されています。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This RFC explores mechanisms to prevent a remotely managed entity from burdening a manager or network with an unexpected amount of network management information, and to ensure delivery of "important" information. The focus is on controlling the flow of asynchronously generated information, and not how the information is generated.
このRFCは、離れて管理された実体が予期していなかった量のネットワークマネージメント情報でマネージャかネットワークを負担するのを防いで、「重要な」情報の配送を保証するためにメカニズムを探ります。 焦点が情報がどう発生しているかではなく、非同期に発生している情報の流れを制御するところにあります。
Table of Contents
目次
1. Introduction................................................... 2
2. Problem Definition............................................. 3
2.1 Polling Advantages............................................ 3
(a) Reliable detection of failures............................... 3
(b) Reduced protocol complexity on managed entity................ 3
(c) Reduced performance impact on managed entity................. 3
(d) Reduced configuration requirements to manage remote entity... 4
2.2 Polling Disadvantages......................................... 4
(a) Response time for problem detection.......................... 4
(b) Volume of network management traffic generated............... 4
2.3 Alert Advantages.............................................. 5
(a) Real-time knowledge of problems.............................. 5
(b) Minimal amount of network management traffic................. 5
2.4 Alert Disadvantages........................................... 5
(a) Potential loss of critical information....................... 5
(b) Potential to over-inform a manager........................... 5
3. Specific Goals of this Memo.................................... 6
4. Compatibility with Existing Network Management Protocols....... 6
1. 序論… 2 2. 問題定義… 3 2.1 世論調査利点… 3 (a) 失敗の信頼できる検出… 3 (b)は管理された実体のプロトコルの複雑さを減少させました… 3 (c)は管理された実体で性能影響を減少させました… 3 (d)はリモート実体を管理するという構成必要条件を減らしました… 4 2.2 世論調査損失… 4 (a) 問題検出のための応答時間… トラフィックが生成したネットワークマネージメントの4(b)ボリューム… 4 2.3 利点を警告してください… 5 (a) 問題に関するリアルタイムの知識… ネットワークマネージメントトラフィックの5(b)最少量… 5 2.4 損失を警告してください… 5 (a) 重要情報の潜在的損失… 5 (b) マネージャに知らせ過ぎる可能性… 5 3. このMemoの特定のGoals… 6 4. 既存のネットワーク管理プロトコルとの互換性… 6
Steinberg [Page 1] RFC 1224 Managing Asynchronously Generated Alerts May 1991
1991年5月に警戒であると非同期に生成されたスタインバーグ[1ページ]RFC1224管理
5. Closed Loop "Feedback" Alert Reporting with a "Pin" Sliding
Window Limit................................................... 6
5.1 Use of Feedback............................................... 7
5.1.1 Example..................................................... 8
5.2 Notes on Feedback/Pin usage................................... 8
6. Polled, Logged Alerts.......................................... 9
6.1 Use of Polled, Logged Alerts.................................. 10
6.1.1 Example..................................................... 12
6.2 Notes on Polled, Logged Alerts................................ 12
7. Compatibility with SNMP and CMOT .............................. 14
7.1 Closed Loop Feedback Alert Reporting.......................... 14
7.1.1 Use of Feedback with SNMP................................... 14
7.1.2 Use of Feedback with CMOT................................... 14
7.2 Polled, Logged Alerts......................................... 14
7.2.1 Use of Polled, Logged Alerts with SNMP...................... 14
7.2.2 Use of Polled, Logged Alerts with CMOT...................... 15
8. Notes on Multiple Manager Environments......................... 15
9. Summary........................................................ 16
10. References.................................................... 16
11. Acknowledgements.............................................. 17
Appendix A. Example of polling costs............................. 17
Appendix B. MIB object definitions............................... 19
Security Considerations........................................... 22
Author's Address.................................................. 22
5. 「ピン」引窓限界で報告するクローズドループ「フィードバック」警戒… 6 5.1 フィードバックの使用… 7 5.1 .1の例… 8 Feedback/ピン用法に関する5.2の注… 8 6. 投票されて、登録された警戒… 9 6.1 投票されて、登録された警戒の使用… 10 6.1 .1の例… 12 6.2 投票されて、登録された警戒では、注意します。 12 7. SNMPとCMOTとの互換性… 14 7.1は輪のフィードバック警戒報告を終えました… 14 7.1 .1 SNMPとのフィードバックの使用… 14 7.1 .2 CMOTとのフィードバックの使用… 14 7.2 投票されて、登録された警戒… 14 7.2 .1 SNMPとの投票されて、登録された警戒の使用… 14 7.2 .2 CMOTとの投票されて、登録された警戒の使用… 15 8. 複数のマネージャ環境に関する注… 15 9. 概要… 16 10. 参照… 16 11. 承認… 17 世論調査コストの付録A.Example… 17 付録B. MIBオブジェクト定義… 19 セキュリティ問題… 22作者のアドレス… 22
1. Introduction
1. 序論
This memo defines mechanisms to prevent a remotely managed entity from burdening a manager or network with an unexpected amount of network management information, and to ensure delivery of "important" information. The focus is on controlling the flow of asynchronously generated information, and not how the information is generated. Mechanisms for generating and controlling the generation of asynchronous information may involve protocol specific issues.
このメモは、離れて管理された実体が予期していなかった量のネットワークマネージメント情報でマネージャかネットワークを負担するのを防いで、「重要な」情報の配送を保証するためにメカニズムを定義します。 焦点が情報がどう発生しているかではなく、非同期に発生している情報の流れを制御するところにあります。 非同期な情報の世代がかかわるかもしれない生成するのと制御のためのメカニズムは特定の問題について議定書の中で述べます。
There are two understood mechanisms for transferring network management information from a managed entity to a manager: request- response driven polling, and the unsolicited sending of "alerts". Alerts are defined as any management information delivered to a manager that is not the result of a specific query. Advantages and disadvantages exist within each method. They are detailed in section 2 below.
管理された実体からマネージャまでネットワークマネージメント情報を移すための2つの理解されているメカニズムがあります: 投票しているのに追い立てられた応答、および「警戒」の求められていない送付を要求してください。 警戒は特定の質問の結果でないマネージャに提供されたどんな経営情報とも定義されます。 各メソッドの中に利点と難点があります。 それらは下のセクション2で詳細です。
Alerts in a failing system can be generated so rapidly that they adversely impact functioning resources. They may also fail to be delivered, and critical information maybe lost. Methods are needed both to limit the volume of alert transmission and to assist in delivering a minimum amount of information to a manager.
逆に影響を与えるほど急速に機能しているリソースであると経営状態が悪い組織における警戒を生成することができます。 また、彼らは提供されないかもしれません、そして、多分、重要情報は失われました。 メソッドが、ともに注意深いトランスミッションのボリュームを制限して、最小の量の情報をマネージャに提供するのを助けるのに必要です。
Steinberg [Page 2] RFC 1224 Managing Asynchronously Generated Alerts May 1991
1991年5月に警戒であると非同期に生成されたスタインバーグ[2ページ]RFC1224管理
It is our belief that managed agents capable of asynchronously generating alerts should attempt to adopt mechanisms that fill both of these needs. For reasons shown in section 2.4, it is necessary to fulfill both alert-management requirements. A complete alert-driven system must ensure that alerts are delivered or their loss detected with a means to recreate the lost information, AND it must not allow itself to overburden its manager with an unreasonable amount of information.
これらの必要性の両方をいっぱいにするのは、警戒を非同期に生成することができる管理されたエージェントが、メカニズムを採用するのを試みるべきであるという私たちの信念です。 セクション2.4で示された理由に、両方の注意深い管理要件を実現させるのが必要です。 完全な注意深い駆動システムが、警戒が提供されるのを確実にしなければなりませんか、または無くなっている情報、およびそれを再作成する手段で検出されたそれらの損失は、それ自体が無理な情報量でマネージャに負担をかけるのを許容してはいけません。
2. Problem Definition
2. 問題定義
The following discusses the relative advantages and disadvantages of polled vs. alert driven management.
以下は親類のために追い立てられた警戒に対して投票された管理の利点と損失について議論します。
2.1 Polling Advantages
2.1 世論調査利点
(a) Reliable detection of failures.
(a) 失敗の信頼できる検出。
A manager that polls for all of its information can
more readily determine machine and network failures;
a lack of a response to a query indicates problems
with the machine or network. A manager relying on
notification of problems might assume that a faulty
system is good, should the alert be unable to reach
its destination, or the managed system be unable to
correctly generate the alert. Examples of this
include network failures (in which an isolated network
cannot deliver the alert), and power failures (in which
a failing machine cannot generate an alert). More
subtle forms of failure in the managed entity might
produce an incorrectly generated alert, or no alert at
all.
情報のすべてのための投票が、より容易に決定できるマネージャは、失敗を機械加工して、ネットワークでつなぎます。 質問への応答の不足はマシンかネットワークに関する問題を示します。 問題の通知に依存するマネージャは、不完全なシステムが良いと仮定するかもしれなくて、警戒が目的地、または管理されたシステムに達することができないなら、正しく警戒を生成することができないでください。 この例はネットワーク失敗(孤立しているネットワークはそこで警戒を提供できない)、および停電(失敗マシンはそこで警戒を生成することができない)を含んでいます。 不当に発生している警戒を生産しますが、管理された実体における、より微妙なフォームの失敗はどんな警戒も全く生産しないかもしれません。
(b) Reduced protocol complexity on managed entity
(b) 管理された実体の減少しているプロトコルの複雑さ
The use of a request-response based system is based on
conservative assumptions about the underlying transport
protocol. Timeouts and retransmits (re-requests) can
be built into the manager. In addition, this allows
the manager to affect the amount of network management
information flowing across the network directly.
ベースの要求応答システムの使用は基本的なトランスポート・プロトコルに関する保守的な仮定に基づいています。 タイムアウト、再送する、(再要求)をマネージャに組み込むことができます。 さらに、これで、マネージャはネットワークの向こう側に直接流れるネットワークマネージメント情報の量に影響できます。
(c) Reduced performance impact on managed entity
(c) 管理された実体に関する減少している性能影響
In a purely polled system, there is no danger of having
to often test for an alert condition. This testing
takes CPU cycles away from the real mission of the
managed entity. Clearly, testing a threshold on each
純粋に投票されたシステムには、注意深い状態がないかどうかしばしばテストしなければならないという危険が全くありません。 このテストは管理された実体の本当の任務からCPUサイクルを取り除きます。 それぞれで明確に敷居をテストすること。
Steinberg [Page 3] RFC 1224 Managing Asynchronously Generated Alerts May 1991
1991年5月に警戒であると非同期に生成されたスタインバーグ[3ページ]RFC1224管理
packet received could have unwanted performance effects
on machines such as gateways. Those who wish to use
thresholds and alerts must choose the parameters to be
tested with great care, and should be strongly
discouraged from updating statistics and checking values
frequently.
受け取られたパケットは求められていない性能影響をゲートウェイなどのマシンに与えるかもしれません。 敷居と警戒を使用したがっている人は、細心の注意を払ってテストされるためにパラメタを選ばなければならなくて、統計をアップデートして、値をチェックして、頻繁に強くがっかりするべきです。
(d) Reduced Configuration Requirements to manage remote
entity
(d) リモート実体を管理する減少しているConfiguration Requirements
Remote, managed entities need not be configured
with one or more destinations for reporting information.
Instead, the entity merely responds to whomever
makes a specific request. When changing the network
configuration, there is never a need to reconfigure
all remote manageable systems. In addition, any number
of "authorized" managers (i.e., those passing any
authentication tests imposed by the network management
protocol) may obtain information from any managed entity.
This occurs without reconfiguring the entity and
without reaching an entity-imposed limit on the maximum
number of potential managers.
リモートで、管理された実体は、情報を報告するために1つ以上の目的地によって構成される必要はありません。 代わりに、実体は単に造のa詳細が要求する人なら誰でもに応じます。 ネットワーク・コンフィギュレーションを変えるとき、すべてのリモート処理しやすいシステムを再構成する必要が決してありません。さらに、いろいろな「認可された」マネージャ(すなわち、ネットワーク管理プロトコルによって課されたどんな認証テストにも合格するもの)がどんな管理された実体からも情報を得るかもしれません。 これは実体を再構成することなしで潜在的マネージャの最大数における実体で課された限界に達することなしで起こります。
2.2 Polling Disadvantages
2.2 世論調査損失
(a) Response time for problem detection
(a) 問題検出のための応答時間
Having to poll many MIB [2] variables per machine on
a large number of machines is itself a real
problem. The ability of a manager to monitor
such a system is limited; should a system fail
shortly after being polled there may be a significant
delay before it is polled again. During this time,
the manager must assume that a failing system is
acceptable. See Appendix A for a hypothetical
example of such a system.
多くのマシンの上で多くの1マシンあたりのMIB[2]変数に投票しなければならないのは、それ自体で実際の問題です。 マネージャがそのようなシステムをモニターする能力は限られています。 それが再び投票される前にそこに投票されるのが、重要な遅れであったかもしれないすぐ後にシステムは失敗するはずですか? この間に、マネージャは、経営状態が悪い組織が許容できると仮定しなければなりません。 そのようなシステムの仮定している例に関してAppendix Aを見てください。
It is worthwhile to note that while improving the mean
time to detect failures might not greatly improve the
time to correct the failure, the problem will generally
not be repaired until it is detected. In addition,
most network managers would prefer to at least detect
faults before network users start phoning in.
それが失敗を検出する平均時を改良している間失敗を修正する時間を大いに改良しないかもしれないことに注意する価値がある、一般に、それが検出されるまで、問題は修理されないでしょう。 さらに、ほとんどのネットワークマネージャが、ネットワーク利用者が電話で伝え始める前に欠点を少なくとも検出するのを好むでしょう。
(b) Volume of network management traffic
(b) ネットワークマネージメントトラフィックのボリューム
Polling many objects (MIB variables) on many machines
greatly increases the amount of network management
多くのマシンの上の多くのオブジェクト(MIB変数)に投票すると、ネットワークマネージメントの量は大いに増強されます。
Steinberg [Page 4] RFC 1224 Managing Asynchronously Generated Alerts May 1991
1991年5月に警戒であると非同期に生成されたスタインバーグ[4ページ]RFC1224管理
traffic flowing across the network (see Appendix A).
While it is possible to minimize this through the use
of hierarchies (polling a machine for a general status
of all the machines it polls), this aggravates the
response time problem previously discussed.
ネットワーク(Appendix Aを見る)の向こう側に流れるトラフィック。 階層構造(それが投票するすべてのマシンの一般的な状態にマシンに投票する)の使用でこれを最小にするのが可能ですが、これは以前に議論した応答時間問題をいらいらさせます。
2.3 Alert Advantages
2.3 注意深い利点
(a) Real-time Knowledge of Problems
(a) 問題に関するリアルタイムの知識
Allowing the manager to be notified of problems
eliminates the delay imposed by polling many objects/
systems in a loop.
マネージャが問題について通知されるのを許容するのが輪の多くのオブジェクト/システムに投票することによって課された遅れを排除します。
(b) Minimal amount of Network Management Traffic
(b) Network Management Trafficの最少量
Alerts are transmitted only due to detected errors.
By removing the need to transfer large amounts of status
information that merely demonstrate a healthy system,
network and system (machine processor) resources may be
freed to accomplish their primary mission.
警戒は検出された誤りだけのため伝えられます。 単に健康なシステムを実施説明する多量の状態情報を移す必要性を取り除くことによって、ネットワークとシステム(マシンプロセッサ)リソースは彼らのプライマリ任務を実行するために解放されるかもしれません。
2.4 Alert Disadvantages
2.4 注意深い損失
(a) Potential Loss of Critical Information
(a) 重要情報の潜在的損失
Alerts are most likely not to be delivered when the
managed entity fails (power supply fails) or the
network experiences problems (saturated or isolated).
It is important to remember that failing machines and
networks cannot be trusted to inform a manager that
they are failing.
警戒は、管理された実体が失敗するか(電源は失敗します)、またはネットワークが問題(飽和状態にされているか、または隔離される)を経験するとき、提供されないように最もありそうです。 マシンとネットワークに失敗するのが、失敗していることをマネージャに知らせると信じることができなかったのを覚えているのは重要です。
(b) Potential to Over-inform the Manager
(b) マネージャに知らせ過ぎる可能性
An "open loop" system in which the flow of alerts to
a manager is fully asynchronous can result in an excess
of alerts being delivered (e.g., link up/down messages
when lines vacillate). This information places an extra
burden on a strained network, and could prevent the
manager from disabling the mechanism generating the
alerts; all available network bandwidth into the manager
could be saturated with incoming alerts.
マネージャへの警戒の流れが完全に非同期である「転々流通」システムは提供される警戒の過剰をもたらすことができます(例えば、系列が揺れたら、/下にメッセージにリンクしてください)。 マネージャは、この情報で、張りつめているネットワークに付加的な負担をかけて、警戒を生成するメカニズムを無効にすることができないかもしれません。 入って来る警戒でマネージャへのすべての利用可能なネットワーク回線容量を飽和状態にすることができました。
Most major network management systems strive to use an optimal combination of alerts and polling. Doing so preserves the advantages of each while eliminating the disadvantages of pure polling.
ほとんどの主要なネットワーク管理システムが、警戒と世論調査の最適の組み合わせを使用するように努力します。 そうするのは純粋な世論調査の損失を排除している間、それぞれの利点を保存します。
Steinberg [Page 5] RFC 1224 Managing Asynchronously Generated Alerts May 1991
1991年5月に警戒であると非同期に生成されたスタインバーグ[5ページ]RFC1224管理
3. Specific Goals of this Memo
3. このMemoの特定のGoals
This memo suggests mechanisms to minimize the disadvantages of alert usage. An optimal system recognizes the potential problems associated with sending too many alerts in which a manager becomes ineffective at managing, and not adequately using alerts (especially given the volumes of data that must be actively monitored with poor scaling). It is the author's belief that this is best done by allowing alert mechanisms that "close down" automatically when over- delivering asynchronous (unexpected) alerts, and that also allow a flow of synchronous alert information through a polled log. The use of "feedback" (with a sliding window "pin") discussed in section 5 addresses the former need, while the discussion in section 6 on "polled, logged alerts" does the latter.
このメモは、注意深い用法の損失を最小にするためにメカニズムを示します。 最適のシステムは警戒を使用することにおけるマネージャが適切にで効力がないのではなく管理で効力がなくなるあまりに多くの警戒を送ると関連している潜在的な問題を認識します(貧乏人が比例する状態で活発にモニターしなければならないデータのボリュームを特に考えて)。 非同期な(予期していなかった)警戒を提供し過ぎるとき自動的に「休業し」て、また同期注意深い情報の流れの投票されたログに通ることを許す警告メカニズムを許容することによって最も上手にこれをするのは、作者の信念です。 セクション5で議論した「フィードバック」(引窓「ピン」がある)の使用は前の必要性を扱います、「投票されて、登録された警戒」のセクション6での議論は後者をしますが。
This memo does not attempt to define mechanisms for controlling the asynchronous generation of alerts, as such matters deal with specifics of the management protocol. In addition, no attempt is made to define what the content of an alert should be. The feedback mechanism does require the addition of a single alert type, but this is not meant to impact or influence the techniques for generating any other alert (and can itself be generated from a MIB object or the management protocol). To make any effective use of the alert mechanisms described in this memo, implementation of several MIB objects is required in the relevant managed systems. The location of these objects in the MIB is under an experimental subtree delegated to the Alert-Man working group of the Internet Engineering Task Force (IETF) and published in the "Assigned Numbers" RFC [5]. Currently, this subtree is defined as
このメモは、警戒の非同期な世代を制御するためにメカニズムを定義するのを試みません、そのような件が管理プロトコルの詳細に対処するとき。 さらに、警戒の内容が何であるべきであるかを定義するのを試みを全くしません。 いかなる他の警戒も生成するためのテクニックにフィードバック・メカニズムが単独の注意深いタイプの追加を必要としますが、影響を与えることになっていないか、これが影響を及ぼすことになっていない、(缶自体、MIBオブジェクトか管理プロトコルから生成されてください、) このメモで警告メカニズムのどんな有効な使用についても説明させるのに、数個のMIBオブジェクトの実装が関連管理されたシステムで必要です。MIBのこれらのオブジェクトの位置がインターネット・エンジニアリング・タスク・フォース(IETF)のAlert-男性ワーキンググループへ代表として派遣されて、「規定番号」RFC[5]で発行された実験下位木の下にあります。 現在、この下位木は定義されます。
alertMan ::= { experimental 24 }.
alertMan:、:= 実験的な24。
4. Compatibility With Existing Network Management Protocols
4. 既存のネットワーク管理プロトコルとの互換性
It is the intent of this document to suggest mechanisms that violate neither the letter nor the spirit of the protocols expressed in CMOT [3] and SNMP [4]. To achieve this goal, each mechanism described will give an example of its conformant use with both SNMP and CMOT.
手紙もCMOT[3]とSNMP[4]に表されたプロトコルの精神も違反しないのは、このドキュメントがメカニズムを示す意図です。 この目標を達成するために、説明された各メカニズムはSNMPとCMOTの両方があるconformant使用に関する例を出すでしょう。
5. Closed Loop "Feedback" Alert Reporting with a "Pin" Sliding
Window Limit
5. 「ピン」引窓限界で報告するクローズドループ「フィードバック」警戒
One technique for preventing an excess of alerts from being delivered involves required feedback to the managed agent. The name "feedback" describes a required positive response from a potentially "over- reported" manager, before a remote agent may continue transmitting alerts at a high rate. A sliding window "pin" threshold (so named for the metal on the end of a meter) is established as a part of a
警戒の過剰が提供されるのを防ぐための1つのテクニックが必要なフィードバックに管理されたエージェントにかかわります。 名前「フィードバック」は潜在的に「報告され過ぎる」マネージャから必要な積極的な応答について説明します、リモートエージェントが、高価で警戒を伝え続けるかもしれない前に。 引窓「ピン」敷居(したがって、1メーターの端の金属にちなんで命名される)はaの一部と書き立てられます。
Steinberg [Page 6] RFC 1224 Managing Asynchronously Generated Alerts May 1991
1991年5月に警戒であると非同期に生成されたスタインバーグ[6ページ]RFC1224管理
user-defined SNMP trap, or as a managed CMOT event. This threshold
defines the maximum allowable number of alerts ("maxAlertsPerTime")
that may be transmitted by the agent, and the "windowTime" in seconds
that alerts are tested against. Note that "maxAlertsPerTime"
represents the sum total of all alerts generated by the agent, and is
not duplicated for each type of alert that an agent might generate.
Both "maxAlertsPerTime" and "windowTime" are required MIB objects of
SMI [1] type INTEGER, must be readable, and may be writable should
the implementation permit it.
ユーザによって定義されたSNMPは捕らえるか、または管理されたCMOTイベントとしてそうします。 この敷居はエージェントによって伝えられるかもしれない最大の許容数の警戒("maxAlertsPerTime")を定義します、そして、それが警告する秒の"windowTime"にテストされます。 "maxAlertsPerTime"がエージェントによって生成されたすべての警戒の総和を表して、エージェントが生成するかもしれないそれぞれのタイプの警戒のためにコピーされないことに注意してください。 実装がそれを可能にするなら、"maxAlertsPerTime"と"windowTime"の両方が、SMI[1]タイプINTEGERの必要なMIBオブジェクトであり、読み込み可能でなければならなく、書き込み可能であるかもしれません。
Two other items are required for the feedback technique. The first is a Boolean MIB object (SMI type is INTEGER, but it is treated as a Boolean whose only value is zero, i.e., "FALSE") named "alertsEnabled", which must have read and write access. The second is a user defined alert named "alertsDisabled". Please see Appendix B for their complete definitions.
他の2つの項目がフィードバックのテクニックに必要です。 1番目は読んで、アクセサリーを書かなければならない"alertsEnabled"というブールMIBオブジェクト(SMIタイプはINTEGERですが、aとしてブールで扱われて、ゼロがだれの唯一の値であるか、そして、すなわち、「虚偽」ということである)です。 2番目は"alertsDisabled"というユーザの定義された警戒です。 彼らの完全な定義に関してAppendix Bを見てください。
5.1 Use of Feedback
5.1 フィードバックの使用
When an excess of alerts is being generated, as determined by the total number of alerts exceeding "maxAlertsPerTime" within "windowTime" seconds, the agent sets the Boolean value of "alertsEnabled" to "FALSE" and sends a single alert of type "alertsDisabled".
警戒の過剰が生成されているとき、"windowTime"秒以内に"maxAlertsPerTime"を超えている警戒の総数で決定するように、エージェントは、"alertsEnabled"のブール値を「誤っていること」に設定して、タイプ"alertsDisabled"のただ一つの警戒を送ります。
Again, the pin mechanism operates on the sum total of all alerts generated by the remote system. Feedback is implemented once per agent and not separately for each type of alert in each agent. While it is also possible to implement the Feedback/Pin technique on a per alert-type basis, such a discussion belongs in a document dealing with controlling the generation of individual alerts.
一方、ピンメカニズムはリモートシステムによって生成されたすべての警戒の総和を作動させます。 フィードバックは各エージェントのそれぞれのタイプの警戒のために別々にではなくエージェントに一度実装されます。 また、注意深いタイプ基礎あたりのaでFeedback/ピンがテクニックであると実装するのも可能ですが、個々の警戒の世代を制御することのドキュメントの取扱いにはそのような議論はあります。
The typical use of feedback is detailed in the following steps:
フィードバックの典型的な使用は以下のステップで詳細です:
(a) Upon initialization of the agent, the value of
"alertsEnabled" is set to "TRUE".
(a) エージェントの初期化のときに、"alertsEnabled"の値は「本当に」設定されます。
(b) Each time an alert is generated, the value of
"alertsEnabled" is tested. Should the value be "FALSE",
no alert is sent. If the value is "TRUE", the alert is
sent and the current time is stored locally.
(b) 警戒が発生している各回、"alertsEnabled"の値はテストされます。 値が「誤っている」なら、警戒を全く送りません。 値が「本当である」なら、警戒を送ります、そして、局所的に現在の時間を保存します。
(c) If at least "maxAlertsPerTime" have been generated, the
agent calculates the difference of time stored for the
new alert from the time associated with alert generated
"maxAlertsPerTime" previously. Should this amount be
less than "windowTime", a single alert of the type
"alertsDisabled" is sent to the manager and the value of
(c) 少なくとも"maxAlertsPerTime"が生成されたなら、エージェントは以前に新しい警戒のために注意深い発生している"maxAlertsPerTime"に関連している時間から保存された時間の違いについて計算します。 "windowTime"とタイプ"alertsDisabled"のただ一つの警戒をマネージャと値に送るよりこの量は少ないはずです。
Steinberg [Page 7] RFC 1224 Managing Asynchronously Generated Alerts May 1991
1991年5月に警戒であると非同期に生成されたスタインバーグ[7ページ]RFC1224管理
"alertsEnabled" is then set to "FALSE".
そして、"alertsEnabledする"であることは、「誤っていること」へのセットです。
(d) When a manager receives an alert of the type "Alerts-
Disabled", it is expected to set "alertsEnabled" back
to "TRUE" to continue to receive alert reports.
(d) マネージャが「警戒は無効にした」タイプの警戒を受けるとき、注意深いレポートを受け取り続けるために「本当である」"alertsEnabled"を遅らせると予想されます。
5.1.1 Example
5.1.1 例
In a sample system, the maximum number of alerts any single managed entity may send the manager is 10 in any 3 second interval. A circular buffer with a maximum depth of 10 time of day elements is defined to accommodate statistics keeping.
サンプルシステムでは、どんな3 2番目の間隔にどんなただ一つの管理された実体もマネージャに送るかもしれない警戒の最大数は10のコネです。 10の時刻要素の最大の深さがある円形のバッファは、統計キープを収容するために定義されます。
After the first 10 alerts have been sent, the managed entity tests the time difference between its oldest and newest alerts. By testing the time for a fixed number of alerts, the system will never disable itself merely because a few alerts were transmitted back to back.
最初の10の警戒を送った後に、管理された実体は最も古くて最も新しい警戒の時差をテストします。 警戒の定数のための時間をテストすることによって、単にいくつかの警戒が背中合わせに伝えられたので、システムはそれ自体を決して無効にしないでしょう。
The mechanism will disable reporting only after at least 10 alerts have been sent, and the only if the last 10 all occurred within a 3 second interval. As alerts are sent over time, the list maintains data on the last 10 alerts only.
少なくとも10の警戒を送って、唯一が最後の10であるなら3 2番目の間隔以内にすべて起こった後にだけメカニズムは報告を無効にするでしょう。 時間がたつにつれて警戒を送るとき、リストは最後の10の警戒だけに関するデータを保守します。
5.2 Notes on Feedback/Pin Usage
5.2 フィードバック/ピン用法に関する注
A manager may periodically poll "alertsEnabled" in case an "alertsDisabled" alert is not delivered by the network. Some implementers may also choose to add COUNTER MIB objects to show the total number of alerts transmitted and dropped by "alertsEnabled" being FALSE. While these may yield some indication of the number of lost alerts, the use of "Polled, Logged Alerts" offers a superset of this function.
"alertsDisabled"警戒がネットワークによって提供されないといけないので、マネージャは定期的に"alertsEnabled"に投票するかもしれません。 また、いくらかのimplementersが、警戒の総数がFALSEであるので"alertsEnabled"を伝えて、立ち寄ったのを示すためにCOUNTER MIBオブジェクトを加えるのを選ぶかもしれません。 これらは無くなっている警戒の数のいくつかのしるしをもたらすかもしれませんが、「投票されて、登録された警戒」の使用はこの機能のスーパーセットを提供します。
Testing the alert frequency need not begin until a minimum number of alerts have been sent (the circular buffer is full). Even then, the actual test is the elapsed time to get a fixed number of alerts and not the number of alerts in a given time period. This eliminates the need for complex averaging schemes (keeping current alerts per second as a frequency and redetermining the current value based on the previous value and the time of a new alert). Also eliminated is the problem of two back to back alerts; they may indeed appear to be a large number of alerts per second, but the fact remains that there are only two alerts. This situation is unlikely to cause a problem for any manager, and should not trigger the mechanism.
注意深い頻度をテストするのは最小の数の警戒を送るまで(円形のバッファは完全です)始まる必要はありません。 その時でさえ、実際のテストは与えられた期間の警戒の数ではなく、警戒の定数を得る経過時間です。 これは体系(頻度として1秒あたりの現在の警戒を保って、前の値と新しい警戒の時間に基づく現行価値を再決定する)を平均する複合体の必要性を排除します。 また、排除されているのは、警戒を支持する2後部の問題です。 彼らは、多くの1秒あたりの警戒であるように本当に見えるかもしれませんが、2つの警戒しかないという事実は残っています。 この状況は、どんなマネージャのためにも問題を引き起こしそうになくて、メカニズムの引き金となるべきではありません。
Since alerts are supposed to be generated infrequently, maintaining the pin and testing the threshold should not impact normal performance of the agent (managed entity). While repeated testing
警戒がまれに生成されるべきであるので、ピンを維持して、敷居をテストすると、エージェント(実体を管理する)の正常動作は影響を与えられるべきではありません。 繰り返されたテストをゆったり過ごしてください。
Steinberg [Page 8] RFC 1224 Managing Asynchronously Generated Alerts May 1991
1991年5月に警戒であると非同期に生成されたスタインバーグ[8ページ]RFC1224管理
may affect performance when an excess of alerts are being transmitted, this effect would be minor compared to the cost of generating and sending so many alerts. Long before the cost of testing (in CPU cycles) becomes relatively high, the feedback mechanism should disable alert sending and affect savings both in alert sending and its own testing (note that the list maintenance and testing mechanisms disable themselves when they disable alert reporting). In addition, testing the value of "alertsEnabled" can limit the CPU burden of building alerts that do not need to be sent.
伝えられます、この効果が小さい方であるだろうということであることが生成することの費用にたとえて、とても多くの発信が警告する警戒の過剰であるときに、性能に影響するかもしれません。 テストする(CPUサイクルで)費用が比較的高くなるずっと前に、フィードバック・メカニズムは、注意深い送付とそれ自身のテストで注意深い発信を無効にして、貯蓄に影響するはずです(注意深い報告を無効にするとリスト管理とテストメカニズムが自分たちを無効にすることに注意してください)。 さらに、"alertsEnabled"の値をテストすると、送られる必要はないビル警戒のCPU負担を制限できます。
It is advised that the implementer consider allowing write access to both the window size and the number of alerts allowed in a window's time. In doing so, a management station has the option of varying these parameters remotely before setting "alertsEnabled" to "TRUE". Should either of these objects be set to 0, a conformant system will disable the pin and feedback mechanisms and allow the agent to send all of the alerts it generates.
implementerが、許容が窓が生きている間に許容されたウィンドウサイズと警戒の数の両方へのアクセスを書くと考えると忠告されます。 そうする際に、管理局は「本当である」"alertsEnabled"を設定する前にこれらのパラメタを離れて変えるオプションを持っています。 これらのオブジェクトのどちらかが0に設定されると、conformantシステムは、ピンとフィードバックがメカニズムであると無効にして、エージェントがそれが生成する警戒のすべてを送るのを許容するでしょう。
While the feedback mechanism is not high in CPU utilization costs, those implementing alerts of any kind are again cautioned to exercise care that the alerts tested do not occur so frequently as to impact the performance of the agent's primary function.
フィードバック・メカニズムがCPU使用率コストで高くない間、運動させるどんな種類の実装する警戒も再び警告されるものは、テストされた警戒がエージェントのプライマリ機能の性能に影響を与えるくらいの頻繁に起こらないのを気にかけます。
The user may prefer to send alerts via TCP to help ensure delivery of the "alerts disabled" message, if available.
利用可能であるなら、ユーザは、「無効にされた警戒」メッセージの配送を確実にするのを助けるためにTCPを通して警戒を送るのを好むかもしれません。
The feedback technique is effective for preventing the over-reporting of alerts to a manager. It does not assist with the problem of "under-reporting" (see "polled, logged alerts" for this).
マネージャへの警戒の報告過ぎるのを防ぐのに、フィードバックのテクニックは効果的です。 それは「過少に報告」であるという問題を助けません(これのために「投票されて、登録された警戒」を見てください)。
It is possible to lose alerts while "alertsEnabled" is "FALSE". Ideally, the threshold of "maxAlertsPerTime" should be set sufficiently high that "alertsEnabled" is only set to "FALSE" during "over-reporting" situations. To help prevent alerts from possibly being lost when the threshold is exceeded, this method can be combined with "polled, logged alerts" (see below).
"alertsEnabled"は「誤っています」が、警戒を失うのは可能です。 理想的に、"maxAlertsPerTime"の敷居は「報告過ぎる」状況の間、"alertsEnabled"が「虚偽で」設定されるだけである高値を十分設定することであるべきです。 敷居が超えられているとき、警戒がことによると失われているのを防ぐのを助けるために、「投票されて、登録された警戒」にこのメソッドを結合できます(以下を見てください)。
6. Polled, Logged Alerts
6. 投票されて、登録された警戒
A simple system that combines the request-response advantages of polling while minimizing the disadvantages is "Polled, Logged Alerts". Through the addition of several MIB objects, one gains a system that minimizes network management traffic, lends itself to scaling, eliminates the reliance on delivery, and imposes no potential over-reporting problems inherent in pure alert driven architectures. Minimizing network management traffic is affected by reducing multiple requests to a single request. This technique does not eliminate the need for polling, but reduces the amount of data
損失を最小にしている間に世論調査の要求応答利点を結合する簡単なシステムは「投票されて、登録された警戒」です。 数個のMIBオブジェクトの追加を通して、1つは純粋の固有である問題が駆動アーキテクチャを警告すると報告し過ぎるネットワークマネージメントトラフィックを最小にして、スケーリングに適して、配送への信用を排除して、可能性を全く課さないシステムを獲得します。 ネットワークマネージメントトラフィックを最小にするのは、ただ一つの要求に複数の要求を減らすことによって、影響を受けます。 このテクニックは、世論調査の必要性を排除しませんが、データ量を減少させます。
Steinberg [Page 9] RFC 1224 Managing Asynchronously Generated Alerts May 1991
1991年5月に警戒であると非同期に生成されたスタインバーグ[9ページ]RFC1224管理
transferred and ensures the manager either alert delivery or notification of an unreachable node. Note again, the goal is to address the needs of information (alert) flow and not to control the local generation of alerts.
移して、手の届かないノードの注意深い配送か通知のどちらかをマネージャに保証します。 一方、目標が情報(警戒)流動の必要性を扱って、警戒の地方の世代を制御しないことであることに注意してください。
6.1 Use of Polled, Logged Alerts
6.1 投票されて、登録された警戒の使用
As alerts are generated by a remote managed entity, they are logged locally in a table. The manager may then poll a single MIB object to determine if any number of alerts have been generated. Each poll request returns a copy of an "unacknowledged" alert from the alert log, or an indication that the table is empty. Upon receipt, the manager might "acknowledge" any alert to remove it from the log. Entries in the table must be readable, and can optionally allow the user to remove them by writing to or deleting them.
警戒がリモート管理された実体によって生成されるとき、それらはテーブルに局所的に登録されます。 そして、マネージャは、いろいろな警戒が生成されたかどうか決定するために単一のMIBオブジェクトに投票するかもしれません。 それぞれの投票要求はテーブルが空であるという注意深いログ、または指示から「不承認」の警戒のコピーを返します。 領収書では、マネージャは、どんな警戒もログからそれを取り除くと「承認するかもしれません」。 テーブルのエントリーは、読み込み可能でなければならなく、任意にそれらを書くか、または削除しながらそれらを取り除くユーザを許容できます。
This technique requires several additional MIB objects. The alert_log is a SEQUENCE OF logTable entries that must be readable, and can optionally have a mechanism to remove entries (e.g., SNMP set or CMOT delete). An optional read-only MIB object of type INTEGER, "maxLogTableEntries" gives the maximum number of log entries the system will support. Please see Appendix B for their complete definitions.
このテクニックは数個の追加MIBオブジェクトを必要とします。 警戒_ログが読み込み可能でなければならなく、任意にエントリーを取り除くメカニズムを持つことができるSEQUENCE OF logTableエントリーである、(例えば、SNMPが設定するか、またはCMOTが削除する、) タイプINTEGERの任意の書き込み禁止MIBオブジェクト、「maxLogTableEntries」はシステムがサポートする航空日誌記入事項の最大数を与えます。 彼らの完全な定義に関してAppendix Bを見てください。
The typical use of Polled, Logged Alerts is detailed below.
Polledの典型的な使用であり、Logged Alertsは以下で詳細です。
(a) Upon initialization, the agent builds a pointer to a log
table. The table is empty (a sequence of zero entries).
(a) 初期化のときに、エージェントはログテーブルに指針を築き上げます。 テーブルは空です(エントリーがない系列)。
(b) Each time a local alert is generated, a logTable entry
is built with the following information:
(b) 地方の警戒が発生している各回、logTableエントリーは以下の情報で組み込まれます:
SEQUENCE {
alertId INTEGER,
alertData OPAQUE
}
系列alertId整数、alertData不透明なもの
(1) alertId number of type INTEGER, set to 1 greater
than the previously generated alertId. If this is
the first alert generated, the value is initialized
to 1. This value should wrap (reset) to 1 when it
reaches 2**32. Note that the maximum log depth
cannot exceed (2**32)-1 entries.
(1) 1に以前に発生しているalertIdよりすばらしい状態で用意ができているタイプINTEGERのalertId番号。 これが生成された第一警戒であるなら、値は1に初期化されます。 2**32に達すると、この値は(リセット)を1に包装するべきです。 最大のログの深さが-1のエントリーを超えることができないことに(2**32)注意してください。
(2) a copy of the alert encapsulated in an OPAQUE.
(2) 警戒のコピーはOPAQUEで要約されました。
(c) The new log element is added to the table. Should
addition of the element exceed the defined maximum log
(c) 新しいログ要素はテーブルに加えられます。 要素の追加は定義された最大のログを超えるべきですか?
Steinberg [Page 10] RFC 1224 Managing Asynchronously Generated Alerts May 1991
1991年5月に警戒であると非同期に生成されたスタインバーグ[10ページ]RFC1224管理
table size, the oldest element in the table (having the
lowest alertId) is replaced by the new element.
サイズを見送ってください、そして、テーブル(最も低いalertIdを持っている)で最も古い要素を新しい要素に取り替えます。
(d) A manager may poll the managed agent for either the next
alert in the alert_table, or for a copy of the alert
associated with a specific alertId. A poll request must
indicate a specific alertId. The mechanism for obtaining
this information from a table is protocol specific, and
might use an SNMP GET or GET NEXT (with GET NEXT
following an instance of zero returning the first table
entry's alert) or CMOT's GET with scoping and filtering
to get alertData entries associated with alertId's
greater or less than a given instance.
(d) マネージャは警戒_テーブルの次の警戒、または特定のalertIdに関連している警戒のコピーのために管理されたエージェントに投票するかもしれません。 投票要求は特定のalertIdを示さなければなりません。 テーブルからこの情報を得るためのメカニズムは、プロトコル特有であり、関連しているよりすばらしいalertIdのものでalertDataエントリーか与えられたインスタンス以下を得るのに見るのとフィルタリングがあるSNMP GET、GET NEXT(GET NEXTが最初のテーブル項目の警戒を返しながらゼロのインスタンスに続いている)またはCMOTのGETを使用するかもしれません。
(e) An alertData GET request from a manager must always be
responded to with a reply of the entire OPAQUE alert
(SNMP TRAP, CMOT EVENT, etc.) or a protocol specific
reply indicating that the get request failed.
(e) マネージャからのalertData GET要求が全体のOPAQUE警戒(SNMP TRAP、CMOT EVENTなど)かプロトコルの回答が特定の状態でそれを示しながら返答するためにいつも反応しなければならない、要求は失敗されてください。
Note that the actual contents of the alert string, and
the format of those contents, are protocol specific.
警告ストリングの実際のコンテンツ、およびそれらの内容の形式がプロトコル特有であることに注意してください。
(f) Once an alert is logged in the local log, it is up to
the individual architecture and implementation whether
or not to also send a copy asynchronously to the
manager. Doing so could be used to redirect the focus
of the polling (rather than waiting an average of 1/2
the poll cycle to learn of a problem), but does not
result in significant problems should the alert fail to
be delivered.
(f) 警戒がローカルのログにいったん登録されると、aがまた、発信するためにコピーされるか否かに関係なく、それはマネージャに個々のアーキテクチャと実装まで非同期に達しています。 そうするのは世論調査(平均投票が問題を知るために循環させる1/2を待つよりむしろ)の焦点を向け直すのに使用できましたが、警戒が提供しないなら、重大な問題をもたらしません。
(g) Should a manager request an alert with alertId of 0,
the reply shall be the appropriate protocol specific
error response.
(g) 0、回答のalertIdがある警戒がそうするものとするマネージャ要求が適切であるなら、特定の誤り応答について議定書の中で述べてください。
(h) If a manager requests the alert immediately following
the alert with alertId equal to 0, the reply will be the
first alert (or alerts, depending on the protocol used)
in the alert log.
(h) すぐに0と等しいalertIdと共に警戒に続いて、マネージャが警戒を要求すると、回答は注意深いログで第一警戒(または、使用されるプロトコルによる警戒)でしょう。
(i) A manager may remove a specific alert from the alert log
by naming the alertId of that alert and issuing a
protocol specific command (SET or DELETE). If no such
alert exists, the operation is said to have failed and
such failure is reported to the manager in a protocol
specific manner.
(i) マネージャは特定のコマンド(SETかDELETE)とその警戒とプロトコルを発行するalertIdを命名する注意深いログから特定の警戒を取り除くかもしれません。 何かそのような警戒が存在していないなら、操作は失敗したと言われます、そして、そのような失敗はプロトコルの特定の方法でマネージャに報告されます。
Steinberg [Page 11] RFC 1224 Managing Asynchronously Generated Alerts May 1991
1991年5月に警戒であると非同期に生成されたスタインバーグ[11ページ]RFC1224管理
6.1.1 Example
6.1.1 例
In a sample system (based on the example in Appendix A), a manager must monitor 40 remote agents, each having between 2 and 15 parameters which indicate the relative health of the agent and the network. During normal monitoring, the manager is concerned only with fault detection. With an average poll request-response time of 5 seconds, the manager polls one MIB variable on each node. This involves one request and one reply packet of the format specified in the XYZ network management protocol. Each packet requires 120 bytes "on the wire" (requesting a single object, ASN.1 encoded, IP and UDP enveloped, and placed in an ethernet packet). This results in a serial poll cycle time of 3.3 minutes (40 nodes at 5 seconds each is 200 seconds), and a mean time to detect alert of slightly over 1.5 minutes. The total amount of data transferred during a 3.3 minute poll cycle is 9600 bytes (120 requests and 120 replies for each of 40 nodes). With such a small amount of network management traffic per minute, the poll rate might reasonably be doubled (assuming the network performance permits it). The result is 19200 bytes transferred per cycle, and a mean time to detect failure of under 1 minute. Parallel polling obviously yields similar improvements.
サンプルシステム(Appendix Aの例に基づいている)では、マネージャは40人のリモートエージェントをモニターしなければなりません、それぞれエージェントとネットワークの相対的な健康を示す2〜15のパラメタを持っていて。 正常なモニターの間、マネージャは欠点検出だけに関係があります。 各ノードの上に5秒の平均した投票要求応答時間、マネージャの投票の1MIBの変数がある状態で。 これはXYZネットワーク管理プロトコルで指定された形式の1つの要求と1つの回答パケットにかかわります。 各パケットは「ワイヤ」の120バイトを必要とします(イーサネットパケットにおおわれて、置かれた単一のオブジェクト、コード化されたASN.1、IP、およびUDPを要求して)。 これは3.3分(200秒の5秒の40のノード)の連続の投票サイクルタイム、および1.5分余りの警戒を検出する平均時で結果として生じます。 3.3分の投票サイクルの間に移されたデータの総量は9600バイト(それぞれの40のノードのための120の要求と120の回答)です。 そのような少量の1分あたりのネットワークマネージメントトラフィックで、投票率は合理的に倍にされるかもしれません(ネットワークが性能であると仮定するのがそれを可能にします)。 結果は、1サイクル単位で移された19200バイトと、1分未満の失敗を検出する平均時です。 平行な世論調査は明らかに同様の改良をもたらします。
Should an alert be returned by a remote agent's log, the manager notifies the operator and removes the element from the alert log by setting it with SNMP or deleting it with CMOT. Normal alert detection procedures are then followed. Those SNMP implementers who prefer to not use SNMP SET for table entry deletes may always define their log as "read only". The fact that the manager made a single query (to the log) and was able to determine which, if any, objects merited special attention essentially means that the status of all alert capable objects was monitored with a single request.
警戒がリモートエージェントのログによって返されるなら、マネージャは、注意深いログからSNMPと共にそれを設定するか、またはCMOTと共にそれを削除することによって、オペレータに通知して、要素を取り除きます。 そして、正常な注意深い検出手順は従われています。 エントリーが削除するテーブルにSNMP SETを使用しないのを好むSNMP implementersはいつも「書き込み禁止」と彼らのログを定義するかもしれません。 マネージャが、ただ一つの質問(ログへの)をして、どれがもしあれば反対するかが本質的には特別な注意に値したことを決定できたという事実は、すべての警告できるオブジェクトの状態がただ一つの要求でモニターされたことを意味します。
Continuing the above example, should a remote entity fail to respond to two successive poll attempts, the operator is notified that the agent is not reachable. The operator may then choose (if so equipped) to contact the agent through an alternate path (such as serial line IP over a dial up modem). Upon establishing such a connection, the manager may then retrieve the contents of the alert log for a chronological map of the failure's alerts. Alerts undelivered because of conditions that may no longer be present are still available for analysis.
リモート実体が2つの連続した投票試みまで応じないなら上記の例を続けていて、オペレータはエージェントに届いていないように通知されます。 そして、オペレータは、代替パス(ダイヤルアップモデムの上のシリアル・ラインIPなどの)を通ってエージェントに連絡するのを選ぶかもしれません(そうだとすれば、備えられています)。 そして、そのような接続を確立すると、マネージャは失敗の警戒の年代順の地図のための注意深いログのコンテンツを検索するかもしれません。 もう存在しないかもしれない状態のために非提供された警戒はまだ分析に利用可能です。
6.2 Notes on Polled, Logged Alerts
6.2 投票されて、登録された警戒に関する注
Polled, logged alert techniques allow the tracking of many alerts while actually monitoring only a single MIB object. This dramatically decreases the amount of network management data that must flow across the network to determine the status. By reducing
投票されて、登録された注意深いテクニックは実際に単一のMIBオブジェクトだけをモニターしている間、多くの警戒の追跡を許します。 これは状態を決定するためにネットワークの向こう側に流れなければならないネットワークマネージメントデータの量を劇的に減少させます。 減少で
Steinberg [Page 12] RFC 1224 Managing Asynchronously Generated Alerts May 1991
1991年5月に警戒であると非同期に生成されたスタインバーグ[12ページ]RFC1224管理
the number of requests needed to track multiple objects (to one), the poll cycle time is greatly improved. This allows a faster poll cycle (mean time to detect alert) with less overhead than would be caused by pure polling.
要求の数は、複数のオブジェクト(1つへの)の跡をつける必要があって、投票サイクルタイムは大いに改良されています。 これは純粋な世論調査で引き起こされるだろうより少ないオーバーヘッドがあるさらに速い投票サイクル(警戒を検出する平均時)を許容します。
In addition, this technique scales well to large networks, as the concept of polling a single object to learn the status of many lends itself well to hierarchies. A proxy manager may be polled to learn if he has found any alerts in the logs of the agents he polls. Of course, this scaling does not save on the mean time to learn of an alert (the cycle times of the manager and the proxy manager must be considered), but the amount of network management polling traffic is concentrated at lower levels. Only a small amount of such traffic need be passed over the network's "backbone"; that is the traffic generated by the request-response from the manager to the proxy managers.
さらに、このテクニックは大きいネットワークによく比例します、多くの状態を学ぶために単一のオブジェクトに投票する概念がそれ自体を階層構造によく与えるとき。 プロキシマネージャは、彼が何か彼が投票するエージェントのログにおける警戒を見つけたかどうか学ぶために投票されるかもしれません。 もちろん、このスケーリングは警戒を知る平均時に保存されませんが(マネージャとプロキシマネージャのサイクルタイムを考えなければなりません)、ネットワークマネージメント世論調査トラフィックの量は下のレベルで集結されます。 そのような少量のトラフィックだけがネットワークの「バックボーン」の上に通過されなければなりません。 それはマネージャからプロキシマネージャまでの要求応答で生成されたトラフィックです。
Note that it is best to return the oldest logged alert as the first table entry. This is the object most likely to be overwritten, and every attempt should be made ensure that the manager has seen it. In a system where log entries may be removed by the manager, the manager will probably wish to attempt to keep all remote alert logs empty to reduce the number of alerts dropped or overwritten. In any case, the order in which table entries are returned is a function of the table mechanism, and is implementation and/or protocol specific.
最初のテーブル項目として最も古い登録された警戒を返すのが最も良いことに注意してください。 これは最も上書きされそうなオブジェクトです、そして、最善の努力をするべきです。マネージャがそれを見たのを確実にしてください。 航空日誌記入事項がマネージャによって取り除かれるかもしれないシステムでは、マネージャは、たぶん警戒の数を減少させるために空のすべてのリモート注意深いログを下げられるか、または上書きし続けるのを試みたくなるでしょう。 どのような場合でも、テーブル項目が返されるオーダーは、テーブルメカニズムの機能であり、実装、そして/または、プロトコル特有です。
"Polled, logged alerts" offers all of the advantages inherent in polling (reliable detection of failures, reduced agent complexity with UDP, etc.), while minimizing the typical polling problems (potentially shorter poll cycle time and reduced network management traffic).
「投票されて、登録された警戒」は典型的な世論調査問題(潜在的により短い投票サイクルタイムと減少しているネットワークマネージメントトラフィック)を最小にしている間、世論調査(失敗の信頼できる検出、UDPがある減少しているエージェントの複雑さなど)に固有の利点のすべてを提供します。
Finally, alerts are not lost when an agent is isolated from its manager. When a connection is reestablished, a history of conditions that may no longer be in effect is available to the manager. While not a part of this document, it is worthwhile to note that this same log architecture can be employed to archive alert and other information on remote hosts. However, such non-local storage is not sufficient to meet the reliability requirements of "polled, logged alerts".
エージェントがマネージャから隔離されるとき、最終的に、警戒は無くなっていません。 接続が回復するとき、マネージャにとって、もう有効でないかもしれない状態の歴史は利用可能です。 このドキュメントの一部でない間、リモートホストの注意深くて他の情報を格納するのにこの同じログアーキテクチャを使うことができることに注意する価値があります。 しかしながら、そのような非地方のストレージは、「投票されて、登録された警戒」に関する信頼度要求事項を満たすために十分ではありません。
Steinberg [Page 13] RFC 1224 Managing Asynchronously Generated Alerts May 1991
1991年5月に警戒であると非同期に生成されたスタインバーグ[13ページ]RFC1224管理
7. Compatibility with SNMP [4] and CMOT [3]
7. SNMP[4]とCMOTとの互換性[3]
7.1 Closed Loop (Feedback) Alert Reporting
7.1 クローズドループ(フィードバック)の注意深い報告
7.1.1 Use of Feedback with SNMP
7.1.1 SNMPとのフィードバックの使用
At configuration time, an SNMP agent supporting Feedback/Pin is loaded with default values of "windowTime" and "maxAlerts-PerTime", and "alertsEnabled" is set to TRUE. The manager issues an SNMP GET to determine "maxAlertsPerTime" and "windowTime", and to verify the state of "alertsEnabled". Should the agent support setting Pin objects, the manager may choose to alter these values (via an SNMP SET). The new values are calculated based upon known network resource limitations (e.g., the amount of packets the manager's gateway can support) and the number of agents potentially reporting to this manager.
構成時に、"windowTime"と"maxAlerts-PerTime"のデフォルト値にFeedback/ピンを支えるSNMPエージェントを積みます、そして、"alertsEnabled"をTRUEに設定します。 マネージャは、"maxAlertsPerTime"と"windowTime"を決定して、"alertsEnabled"の状態について確かめるためにSNMP GETを発行します。 エージェントが、設定がPinオブジェクトであるとサポートするなら、マネージャは、これらの値(SNMP SETを通した)を変更するのを選ぶかもしれません。 新しい値は知られているネットワーク資源制限(例えば、マネージャのゲートウェイがサポートすることができるパケットの量)と潜在的にこのマネージャに報告するエージェントの数に基づいた状態で計算されます。
Upon receipt of an "alertsDisabled" trap, a manager whose state and network are not overutilized immediately issues an SNMP SET to make "alertsEnabled" TRUE. Should an excessive number of "alertsDisabled" traps regularly occur, the manager might revisit the values chosen for implementing the Pin mechanism. Note that an overutilized system expects its manager to delay the resetting of "alertsEnabled".
"alertsDisabled"罠を受け取り次第、州とネットワークがすぐに過剰利用されないマネージャは、"alertsEnabled"TRUEを作るためにSNMP SETを発行します。 過度の数の"alertsDisabled"罠が定期的に起こるなら、マネージャはPinメカニズムを実装するのに選ばれた値を再訪させるかもしれません。 過剰利用されたシステムが、マネージャが"alertsEnabled"のリセットを遅らせると予想することに注意してください。
As a part of each regular polling cycle, the manager includes a GET REQUEST for the value of "alertsEnabled". If this value is FALSE, it is SET to TRUE, and the potential loss of traps (while it was FALSE) is noted.
それぞれの通常の世論調査サイクルの一部として、マネージャは"alertsEnabled"の値のためのGET REQUESTを入れます。 この値がFALSEであるなら、それはTRUEへのSETです、そして、罠(それはFALSEでしたが)の潜在的損失は注意されます。
7.1.2 Use of Feedback with CMOT
7.1.2 CMOTとのフィードバックの使用
The use of CMOT in implementing Feedback/Pin is essentially identical to the use of SNMP. CMOT GET, SET, and EVENT replace their SNMP counterparts.
Feedback/ピンを実装することにおけるCMOTの使用は本質的にはSNMPの使用と同じです。 CMOT GET、SET、およびEVENTは彼らのSNMP対応者を取り替えます。
7.2 Polled, Logged Alerts
7.2 投票されて、登録された警戒
7.2.1 Use of Polled, Logged alerts with SNMP
7.2.1 Polledの使用、SNMPがあるLogged警戒
As a part of regular polling, an SNMP manager using Polled, logged
alerts may issue a GET_NEXT Request naming
{ alertLog logTableEntry(1) alertId(1) 0 }. Returned is either the
alertId of the first table entry or, if the table is empty, an SNMP
reply whose object is the "lexicographical successor" to the alert
log.
定期的な世論調査の一部、Polledを使用しているSNMPマネージャとして、登録された警戒はGET_ネクストRequest命名alertLog logTableEntry(1) alertId(1)0を発行するかもしれません。 返しているのは、オブジェクトが注意深いログの「辞書編集の後継者」である最初のテーブル項目のalertIdかテーブルが空であるなら、SNMP回答のどちらかです。
Should an "alertId" be returned, the manager issues an SNMP GET
naming { alertLog logTableEntry(1) alertData(2) value } where "value"
"alertId"を返すなら、マネージャがSNMP GET命名alertLog logTableEntry(1) alertData(2)価値にどこを発行するか、「値」
Steinberg [Page 14] RFC 1224 Managing Asynchronously Generated Alerts May 1991
1991年5月に警戒であると非同期に生成されたスタインバーグ[14ページ]RFC1224管理
is the alertId integer obtained from the previously described GET NEXT. This returns the SNMP TRAP encapsulated within an OPAQUE.
以前に説明されたGET NEXTからalertId整数を得ますか? これはOPAQUEの中でカプセル化されたSNMP TRAPを返します。
If the agent supports the deletion of table entries through SNMP
SETS, the manager may then issue a SET of { alertLog logTableEntry(1)
alertId(1) value } to remove the entry from the log. Otherwise, the
next GET NEXT poll of this agent should request the first "alertId"
following the instance of "value" rather than an instance of "0".
エージェントがSNMP SETSを通したテーブル項目の削除をサポートするなら、マネージャは、ログからエントリーを取り除くためにalertLog logTableEntry(1) alertId(1)価値のSETを発行するかもしれません。 さもなければ、「0インチ」のインスタンスよりむしろ「値」のインスタンスに続いて、このエージェントの次のGETネクスト投票は最初の"alertId"を要求するべきです。
7.2.2 Use of Polled, Logged Alerts with CMOT
7.2.2 CMOTとの投票されて、登録された警戒の使用
Using polled, logged alerts with CMOT is similar to using them with SNMP. In order to test for table entries, one uses a CMOT GET and specifies scoping to the alertLog. The request is for all table entries that have an alertId value greater than the last known alertId, or greater than zero if the table is normally kept empty by the manager. Should the agent support it, entries are removed with a CMOT DELETE, an object of alertLog.entry, and a distinguishing attribute of the alertId to remove.
CMOTがある投票されて、登録された警戒を使用するのはSNMPと共にそれらを使用するのと同様です。 テーブル項目がないかどうかテストするために、1つは、CMOT GETを使用して、alertLogにおいて見ながら、指定します。 テーブルがマネージャによって通常空に保たれるならalertId値を最後に知られているalertId、またはゼロ以上よりすばらしくするすべてのテーブル項目には要求があります。 エージェントがそれをサポートするなら、CMOT DELETE、alertLog.entryのオブジェクト、および取り外すalertIdの区別属性でエントリーを取り除きます。
8. Multiple Manager Environments
8. 複数のマネージャ環境
The conflicts between multiple managers with overlapping administrative domains (generally found in larger networks) tend to be resolved in protocol specific manners. This document has not addressed them. However, real world demands require alert management techniques to function in such environments.
中の管理ドメイン(一般に、より大きいネットワークで見つけられる)は決議されるために傾向がある重なるとの複数のマネージャの間の闘争が特定のマナーについて議定書の中で述べます。 このドキュメントはそれらを扱っていません。 しかしながら、本当の世界の需要は、注意深い管理技術がそのような環境で機能するのを必要とします。
Complex agents can clearly respond to different managers (or managers in different "communities") with different reply values. This allows feedback and polled, logged alerts to appear completely independent to differing autonomous regions (each region sees its own value). Differing feedback thresholds might exist, and feedback can be actively blocking alerts to one manager even after another manager has reenabled its own alert reporting. All of this is transparent to an SNMP user if based on communities, or each manager can work with a different copy of the relevant MIB objects. Those implementing CMOT might view these as multiple instances of the same feedback objects (and allow one manager to query the state of another's feedback mechanism).
複雑なエージェントは異なった回答値で明確に異なったマネージャ(または、異なった「共同体」のマネージャ)に応じることができます。 これはフィードバック、および投票されて、登録された警戒を異なった自治区に完全に独立しているように見せます(各領域はそれ自身の値を見ます)。 異なったフィードバック敷居は存在するかもしれません、そして、別のマネージャがそれ自身の注意深い報告を再可能にした後にさえフィードバックは活発に1人のマネージャに警戒を妨げることであることができます。 共同体に基づいているなら、SNMPユーザにとって、このすべてが透明であるか、または各マネージャは関連MIBオブジェクトの異なったコピーで働くことができます。 CMOTを実装する人は同じフィードバックオブジェクトの複数のインスタンスであるとこれらをみなすかもしれません(1人のマネージャに別のもののフィードバック・メカニズムの事情について質問させてください)。
The same holds true for polled, logged alerts. One manager (or manager in a single community/region) can delete an alert from its view without affecting the view of another region's managers.
同じくらいは投票されて、登録された警戒に当てはまります。 別の領域のマネージャの視点に影響しないで、1人のマネージャ(または、ただ一つの共同体/領域のマネージャ)が視点から警戒を削除できます。
Those preferring less complex agents will recognize the opportunity to instrument proxy management. Alerts might be distributed from a manager based alert exploder which effectively implements feedback
それほど複雑でないエージェントを好む人が器具プロキシ管理に機会を認識するでしょう。 警戒は事実上、フィードバックを実装するマネージャに基づいている警告発破器から分配されるかもしれません。
Steinberg [Page 15] RFC 1224 Managing Asynchronously Generated Alerts May 1991
1991年5月に警戒であると非同期に生成されたスタインバーグ[15ページ]RFC1224管理
and polled, logged alerts for its subscribers. Feedback parameters are set on each agent to the highest rate of any subscriber, and limited by the distributor. Logged alerts are deleted from the view at the proxy manager, and truly deleted at the agent only when all subscribers have so requested, or immediately deleted at the agent with the first proxy request, and maintained as virtual entries by the proxy manager for the benefit of other subscribers.
そして、加入者のための投票されて、登録された警戒。 フィードバックパラメタは、各エージェントの上にどんな加入者の最も高いレートにも設定されて、ディストリビュータによって制限されます。 すべての加入者が他の加入者の利益のためにプロキシマネージャによるエントリーを最初のプロキシ要求のエージェントで削除して、要求するのですぐに仮想として維持したときだけ、登録された警戒は、プロキシマネージャで視点から削除されて、本当に、エージェントで削除されます。
9. Summary
9. 概要
While "polled, logged alerts" may be useful, they still have a limitation: the mean time to detect failures and alerts increases linearly as networks grow in size (hierarchies offer shorten individual poll cycle times, but the mean detection time is the sum of 1/2 of each cycle time). For this reason, it may be necessary to supplement asynchronous generation of alerts (and "polled, logged alerts") with unrequested transmission of the alerts on very large networks.
「投票されて、登録された警戒」が役に立つかもしれない間、それらには、制限がまだあります: ネットワークがサイズに生えているのに従って(階層構造申し出は個々の投票サイクルタイムを短くしますが、意地悪な検出時間は合計それぞれの1/2のサイクルタイムです)、失敗と警戒を検出する平均時は直線的に増加します。 この理由に、警戒の非要求された送信が非常に大きいネットワークにある警戒(そして、「投票されて、登録された警戒」)の非同期な世代を補うのが必要であるかもしれません。
Whenever systems generate and asynchronously transmit alerts, the potential to overburden (over-inform) a management station exists. Mechanisms to protect a manager, such as the "Feedback/Pin" technique, risk losing potentially important information. Failure to implement asynchronous alerts increases the time for the manager to detect and react to a problem. Over-reporting may appear less critical (and likely) a problem than under-informing, but the potential for harm exists with unbounded alert generation.
システムが警戒を生成して、非同期、伝えるときはいつも、管理局に負担をかける(知らせ過ぎます)可能性は存在しています。 「フィードバック/ピン」のテクニックなどのマネージャを保護するメカニズムは、潜在的に重要な情報を失う危険を冒します。 非同期な警戒を実装しない場合、マネージャが問題に検出して、反応する時間を増強します。 報告過ぎるのは下案内ほど重要で(ありそう)でない問題に現れるかもしれませんが、害の可能性は限りない注意深い世代と共に存在しています。
An ideal management system will generate alerts to notify its management station (or stations) of error conditions. However, these alerts must be self limiting with required positive feedback. In addition, the manager should periodically poll to ensure connectivity to remote stations, and to retrieve copies of any alerts that were not delivered by the network.
理想的なマネージメントシステムは、エラー条件の管理局(または、ステーション)に通知するために警戒を生成するでしょう。 しかしながら、これらの警戒は必要な積極的なフィードバックがある自己制限であるに違いありません。 さらに、マネージャは、遠隔局に接続性を確実にして、ネットワークによって提供されなかったどんな警戒のコピーも検索するために定期的に投票するべきです。
10. References
10. 参照
[1] Rose, M., and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based Internets", RFC 1155,
Performance Systems International and Hughes LAN Systems, May
1990.
[1] ローズ、M.、K.McCloghrie、「TCP/IPベースのインターネットのための経営情報の構造と識別」、RFC1155、国際言語運用機構、およびヒューズLANシステム(1990年5月)。
[2] McCloghrie, K., and M. Rose, "Management Information Base for
Network Management of TCP/IP-based internets", RFC 1213, Hughes
LAN Systems, Inc., Performance Systems International, March 1991.
[2]McCloghrie、K.、およびM.ローズ、「TCP/IPベースのインターネットのNetwork Managementのための管理Information基地」、RFC1213、ヒューズLAN Systems Inc.、国際パフォーマンスSystems、1991年3月。
[3] Warrier, U., Besaw, L., LaBarre, L., and B. Handspicker, "Common
Management Information Services and Protocols for the Internet
[3]Warrier、U.、Besaw、L.、LaBarre、L.、B.Handspicker、および「インターネットへの共通管理情報サービスとプロトコル」
Steinberg [Page 16] RFC 1224 Managing Asynchronously Generated Alerts May 1991
1991年5月に警戒であると非同期に生成されたスタインバーグ[16ページ]RFC1224管理
(CMOT) and (CMIP)", RFC 1189, Netlabs, Hewlett-Packard, The Mitre
Corporation, Digital Equipment Corporation, October 1990.
「(CMOT)と(CMIP)」、RFC1189、Netlabs、ヒューレット・パッカード斜め継ぎ社、DEC、10月1990日
[4] Case, J., Fedor, M., Schoffstall, M., and C. Davin, "Simple
Network Management Protocol" RFC 1157, SNMP Research, Performance
Systems International, Performance Systems International, MIT
Laboratory for Computer Science, May 1990.
[4] ケースとJ.とヒョードルとM.とSchoffstall、M.とC.デーヴィン、「簡単なネットワーク管理プロトコル」RFC1157、SNMPは研究します、国際言語運用機構、国際言語運用機構、MITコンピュータサイエンス研究所、1990年5月。
[5] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060,
USC/Information Sciences Institute, March 1990.
[5] USC/情報科学が1990年3月に設けるレイノルズ、J.、およびJ.ポステル、「規定番号」、RFC1060。
11. Acknowledgements
11. 承認
This memo is the product of work by the members of the IETF Alert-Man Working Group and other interested parties, whose efforts are gratefully acknowledged here:
このメモはIETF Alert-男性作業部会のメンバーと取り組みがここで感謝して承認される他の利害関係者による仕事の成果です:
Amatzia Ben-Artzi Synoptics Communications
Neal Bierbaum Vitalink Corp.
Jeff Case University of Tennessee at Knoxville
John Cook Chipcom Corp.
James Davin MIT
Mark Fedor Performance Systems International, Inc.
Steven Hunter Lawrence Livermore National Labs
Frank Kastenholz Clearpoint Research
Lee LaBarre Mitre Corp.
Bruce Laird BBN, Inc
Gary Malkin FTP Software, Inc.
Keith McCloghrie Hughes Lan Systems
David Niemi Contel Federal Systems
Lee Oattes University of Toronto
Joel Replogle NCSA
Jim Sheridan IBM Corp.
Steve Waldbusser Carnegie-Mellon University
Dan Wintringham Ohio Supercomputer Center
Rich Woundy IBM Corp.
Amatziaベン-Artzi SynopticsコミュニケーションニールBierbaum Vitalink社のジェフケースノクスビルション・クックChipcom社のジェームスデーヴィンMITマークヒョードル言語運用機構の国際Inc.スティーブン・ハンターローレンスリバーモアの国家のテネシー大学研究室フランクKastenholz Clearpoint研究リーLaBarre斜め継ぎ社; ブルース地主BBN、IncゲーリーマルキンFTPソフトウェアInc.キースMcCloghrieヒューズランシステムデヴィッドNiemiコンテルの連邦政府のSystemsのスティーブ・Waldbusserカーネギーメロン大学ダン・ウィントリンガム・リーOattesトロント大学ジョエルリプルーグルNCSAジムシェリダンIBM社のオハイオのスーパーコンピュータのセンターの豊かなWoundy IBM社
Appendix A
付録A
Example of polling costs
世論調査コストに関する例
The following example is completely hypothetical, and arbitrary.
It assumes that a network manager has made decisions as to which
systems, and which objects on each system, must be continuously
monitored to determine the operational state of a network. It
does not attempt to discuss how such decisions are made, and
assumes that they were arrived at with the full understanding that
the costs of polling many objects must be weighed against the
以下の例は、完全に仮定していて、任意です。 それは、ネットワークの操作上の事情を決定するために、モニターされていた状態でネットワークマネージャがどのシステムに関して決定をするか、そして、各システムの上の目的が絶え間なくそうであるに違いないそれを仮定します。 それは、どうそのような決定をするかについて議論するのを試みないで、多くのオブジェクトに投票するコストに不利に働かなければならないという十分な理解でそれらに達したと仮定します。
Steinberg [Page 17] RFC 1224 Managing Asynchronously Generated Alerts May 1991
1991年5月に警戒であると非同期に生成されたスタインバーグ[17ページ]RFC1224管理
level of information required.
情報のレベルが必要です。
Consider a manager that must monitor 40 gateways and hosts on a
single network. Further assume that the average managed entity
has 10 MIB objects that must be watched to determine the device's
and network's overall "health". Under the XYZ network management
protocol, the manager may get the values of up to 4 MIB objects
with a single request (so that 3 requests must be made to
determine the status of a single entity). An average response
time of 5 seconds is assumed, and a lack of response within 30
seconds is considered no reply. Two such "no replies" are needed
to declare the managed entity "unreachable", as a single packet
may occasionally be dropped in a UDP system (those preferring to
use TCP for automated retransmits should assume a longer timeout
value before declaring the entity "unreachable" which we will
define as 60 seconds).
ただ一つのネットワークで40門とホストをモニターしなければならないマネージャを考えてください。 平均した管理された実体がデバイスとネットワークの総合的な「健康」を決定するのを見なければならない10個のMIBオブジェクトを持っているとさらに仮定してください。 XYZネットワーク管理プロトコルの下では、マネージャはただ一つの要求で最大4個のMIBオブジェクトの値を得るかもしれません(単一体の状態を決定するのを3つの要求をしなければならないように)。 5秒の平均応答時間は思われます、そして、30秒以内の無反応は回答でないと考えられます。 そのような2「回答がありません」が管理された実体が「手が届きません」と宣言するのに必要です、単一のパケットがUDPシステムで時折下げられるとき(自動化されて、TCPを使用するそれらの好みが再送される、実体が「手が届きません」と宣言する前の私たちが60秒と定義するつもりであるより長いタイムアウト値を仮定するべきである、)
We begin with the case of "sequential polling". This is defined
as awaiting a response to an outstanding request before issuing
any further requests. In this example, the average XYZ network
management protocol packet size is 300 bytes "on the wire"
(requesting multiple objects, ASN.1 encoded, IP and UDP enveloped,
and placed in an ethernet packet). 120 request packets are sent
each cycle (3 for each of 40 nodes), and 120 response packets are
expected. 72000 bytes (240 packets at 300 bytes each) must be
transferred during each poll cycle, merely to determine that the
network is fine.
私たちは「連続した世論調査」に関するケースで始めます。 これはどんなさらなる要求も出す前に傑出している要求への応答を待つと定義されます。 この例では、平均したXYZネットワーク管理プロトコルパケットサイズは「ワイヤ」の300バイト(イーサネットパケットにおおわれて、置かれた複数のオブジェクト、コード化されたASN.1、IP、およびUDPを要求して)です。 それぞれのサイクル(それぞれの40のノードのための3)120のリクエスト・パケットを送ります、そして、120の応答パケットを予想します。 単にネットワークがすばらしいことを決定するために、それぞれの投票サイクルの間、72000バイト(それぞれ300バイトにおける240のパケット)を移さなければなりません。
At five seconds per transaction, it could take up to 10 minutes to
determine the state of a failing machine (40 systems x 3 requests
each x 5 seconds per request). The mean time to detect a system
with errors is 1/2 of the poll cycle time, or 5 minutes. In a
failing network, dropped packets (that must be timed out and
resent) greatly increase the mean and worst case times to detect
problems.
1トランザクションあたり5秒に、失敗マシンの状態を決定するには最大10分かかることができました(40台のシステムx3は各xを1要求あたり5秒要求します)。 誤りがあるシステムを検出する平均時はサイクルタイム、または5分間1/2の投票です。 失敗ネットワークでは、下げられたパケット(それを外で調節して、再送しなければならない)は、問題を検出するために平均と最悪の場合回を大いに増強します。
Note that the traffic costs could be substantially reduced by
combining each set of three request/response packets in a single
request/response transaction (see section 6.1.1 "Example").
ただ一つの要求/応答トランザクションでそれぞれのセットの3つの要求/応答パケットを結合することによってトラフィックコストをかなり削減できるだろうことに注意してください(セクション6.1.1「例」を見てください)。
While the bandwidth use is spread over 10 minutes (giving a usage
of 120 bytes/second), this rapidly deteriorates should the manager
decrease his poll cycle time to accommodate more machines or
improve his mean time to fault detection. Conversely, increasing
his delay between polls reduces traffic flow, but does so at the
expense of time to detect problems.
帯域幅使用はマネージャが欠点検出により多くのマシンを収容するか、または彼の平均時を改良するために彼の投票サイクルタイムを減少させるなら10分間(120バイト/秒の用法を与える)以上、これが急速に悪化させる普及ですが。 逆に、交通の流れを減少させますが、投票の間の彼の遅れはそう問題を検出する時間を犠牲にして増強されます。
Many network managers allow multiple poll requests to be "pending"
多くのネットワークマネージャが「未定である」という複数の投票要求を許します。
Steinberg [Page 18] RFC 1224 Managing Asynchronously Generated Alerts May 1991
1991年5月に警戒であると非同期に生成されたスタインバーグ[18ページ]RFC1224管理
at any given time. It is assumed that such managers would not
normally poll every machine without any delays. Allowing
"parallel polling" and initiating a new request immediately
following any response would tend to generate larger amounts of
traffic; "parallel polling" here produces 40 times the amount of
network traffic generated in the simplistic case of "sequential
polling" (40 packets are sent and 40 replies received every 5
seconds, giving 80 packets x 300 bytes each per 5 seconds, or 4800
bytes/second). Mean time to detect errors drops, but at the cost
of increased bandwidth. This does not improve the timeout value
of over 2 minutes to detect that a node is not responding.
その時々で。 通常、そのようなマネージャが少しも遅れなしであらゆるマシンに投票するというわけではないと思われます。 「平行な世論調査」を許容して、すぐにどんな応答にも続いて、新しい要求を開始するのは、多く以上の量のトラフィックを生成する傾向があるでしょう。 ここの「平行な世論調査」は「連続した世論調査」の安易な場合で生成された量の40倍のネットワークトラフィックを生産します(40のパケットを送りました、そして、40の回答が5秒毎に受信されました、80のパケットxを2分のそれぞれ5秒あたり300バイト、または4800バイト/バイト与えて)。 しかし、誤りを検出する平均時は増強された帯域幅の費用で低下します。 これはノードが反応させていない検出する2分以上のタイムアウト値を改良しません。
Even with parallel polling, increasing the device count (systems
to manage) not only results in more traffic, but can degrade
performance. On large networks the manager becomes bounded by the
number of queries that can be built, tracked, responses parsed,
and reacted to per second. The continuous volume requires the
timeout value to be increased to accommodate responses that are
still in transit or have been received and are queued awaiting
processing. The only alternative is to reduce the poll cycle.
Either of these actions increase both mean time to detect failure
and worst case time to detect problems.
デバイスカウント(管理するシステム)を増強すると、平行な世論調査があっても、より多くのトラフィックをもたらすだけではなく、性能を下げることができます。 大きいネットワークでは、マネージャは分析されて、1秒単位で反応される組立の、そして、追跡された応答であるかもしれない質問の数に従って境界があるようになります。 連続したボリュームは、処理を待ちながら、タイムアウト値をまだトランジット中であることの応答を収容するために増強されるか、受け取られて、または列に並ばせてあるのを必要とします。 唯一の選択肢は投票サイクルを短縮することです。 これらの動作のどちらかが失敗を検出する平均時と問題を検出する最悪の場合時間の両方を増強します。
If alerts are sent in place of polling, mean time to fault
detection drops from over a minute to as little as 2.5 seconds
(1/2 the time for a single request-response transaction). This
time may be increased slightly, depending on the nature of the
problem. Typical network utilization is zero (assuming a
"typical" case of a non-failing system).
世論調査に代わって警戒を送るなら、欠点検出への平均時が1分から最小2.5秒まで低下する、(1/2、ただ一つの要求応答トランザクションのための時間) 問題の性格によって、今回はわずかに増強されるかもしれません。 典型的なネットワーク利用はゼロ(非経営状態が悪い組織の「典型的な」ケースを仮定して)です。
Appendix B
付録B
All defined MIB objects used in this document reside
under the mib subtree:
本書では使用されるすべての定義されたMIBオブジェクトがmib下位木の下で住んでいます:
alertMan ::= { iso(1) org(3) dod(6) internet(1)
experimental(3) alertMan(24) ver1(1) }
alertMan:、:= iso(1) org(3) dod(6)インターネット(1)実験的な(3)alertMan(24) ver1(1)
as defined in the Internet SMI [1] and the latest "Assigned
Numbers" RFC [5]. Objects under this branch are assigned
as follows:
インターネットSMI[1]と最新の「規定番号」RFC[5]で定義されるように。 この支店の下のオブジェクトは以下の通り割り当てられます:
RFC 1224-MIB DEFINITIONS ::= BEGIN
RFC 1224-MIB定義:、:= 始まってください。
alertMan OBJECT IDENTIFIER ::= { experimental 24 }
alertManオブジェクト識別子:、:= 実験的な24
ver1 OBJECT IDENTIFIER ::= { alertMan 1 }
ver1 OBJECT IDENTIFIER:、:= alertMan1
Steinberg [Page 19] RFC 1224 Managing Asynchronously Generated Alerts May 1991
1991年5月に警戒であると非同期に生成されたスタインバーグ[19ページ]RFC1224管理
feedback OBJECT IDENTIFIER ::= { ver1 1 }
polledLogged OBJECT IDENTIFIER ::= { ver1 2 }
フィードバックOBJECT IDENTIFIER:、:= ver1 1、polledLogged OBJECT IDENTIFIER:、:= ver1 2
END
終わり
1) Feedback Objects
1) フィードバックオブジェクト
OBJECT:
------
オブジェクト: ------
maxAlertsPerTime { feedback 1 }
maxAlertsPerTimeフィードバック1
Syntax:
Integer
構文: 整数
Access:
read-write
アクセス: -読まれて、書いてください。
Status:
mandatory
状態: 義務的
OBJECT:
------
オブジェクト: ------
windowTime { feedback 2 }
windowTimeフィードバック2
Syntax:
Integer
構文: 整数
Access:
read-write
アクセス: -読まれて、書いてください。
Status:
mandatory
状態: 義務的
OBJECT:
------
オブジェクト: ------
alertsEnabled { feedback 3 }
alertsEnabledしました。フィードバック3
Syntax:
Integer
構文: 整数
Access:
read-write
アクセス: -読まれて、書いてください。
Status:
状態:
Steinberg [Page 20] RFC 1224 Managing Asynchronously Generated Alerts May 1991
1991年5月に警戒であると非同期に生成されたスタインバーグ[20ページ]RFC1224管理
mandatory
義務的
2) Polled, Logged Objects
2) 投票されて、登録されたオブジェクト
OBJECT:
------
オブジェクト: ------
alertLog { polledLogged 1 }
alertLog1をpolledLoggedしました。
Syntax:
SEQUENCE OF logTableEntry
構文: logTableEntryの系列
Access:
read-write
アクセス: -読まれて、書いてください。
Status:
mandatory
状態: 義務的
OBJECT:
------
オブジェクト: ------
logTableEntry { alertLog 1 }
logTableEntryalertLog1
Syntax:
構文:
logTableEntry ::= SEQUENCE {
logTableEntry:、:= 系列
alertId
INTEGER,
alertData
OPAQUE
}
alertId整数、alertData不透明なもの
Access:
read-write
アクセス: -読まれて、書いてください。
Status:
mandatory
状態: 義務的
OBJECT:
------
オブジェクト: ------
alertId { logTableEntry 1 }
alertIdlogTableEntry1
Syntax:
Integer
構文: 整数
Steinberg [Page 21] RFC 1224 Managing Asynchronously Generated Alerts May 1991
1991年5月に警戒であると非同期に生成されたスタインバーグ[21ページ]RFC1224管理
Access:
read-write
アクセス: -読まれて、書いてください。
Status:
mandatory
状態: 義務的
OBJECT:
------
オブジェクト: ------
alertData { logTableEntry 2 }
alertDatalogTableEntry2
Syntax:
Opaque
構文: 不透明なもの
Access:
read-only
アクセス: 書き込み禁止
Status:
mandatory
状態: 義務的
OBJECT:
------
オブジェクト: ------
maxLogTableEntries { polledLogged 2 }
maxLogTableEntries2をpolledLoggedしました。
Syntax:
Integer
構文: 整数
Access:
read-only
アクセス: 書き込み禁止
Status:
optional
状態: 任意
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Author's Address
作者のアドレス
Lou Steinberg IBM NSFNET Software Development 472 Wheelers Farms Rd, m/s 91 Milford, Ct. 06460
ルウスタインバーグIBM NSFNET Software Development472Wheelers Farms Rd、m/s91ミルフォードCt。 06460
Phone: 203-783-7175 EMail: LOUISS@IBM.COM
以下に電話をしてください。 203-783-7175 メールしてください: LOUISS@IBM.COM
Steinberg [Page 22]
スタインバーグ[22ページ]
一覧
スポンサーリンク
