イベントや事故はネットワーク運用の不可欠な部分です。 数千のイベントが毎秒記録され、運用サービスは常にいくつかの事故をなくすために忙しく、おそらくどこかにさらにいくつかの事故がありますが、まだ検出および診断されていません。 運用上の診断と事故の検出は非常に困難な作業であり、一連の組織的および技術的な対策によってのみ解決できます。 そして、それにおける少なくとも役割は、事故を検出して処理する自動化された手段によって果たされません。
ICMPおよびSNMPプロトコルを使用してネットワークおよびネットワークサービスをアクティブにスキャンする多くの監視システムがあります。 迅速かつ誤った答えは明らかです。 魔法の監視システムをセットアップすれば十分であり、完全な幸福が訪れます。 このエラーのすべての欺ceは時間とともに理解されます。 まず、事故の検出は監視されているサービスでのみ発生することがわかりました。 まあ、少なくとも基本的なサービスをカバーできたなら。 残りは悲しいかな、苦い経験の結果として、遅れた反応を犠牲にして監視されます。 少し後に、神秘主義が始まります。 何かが明らかに間違って働いている、苦情がありますが、監視システムはすべてが正常であると言います。 その理由は何ですか？
その理由は、サービスの調査が時間的に離散的であり、特定の間隔で行われ、サービスが継続的に提供されるためです。 問題も発生し、継続的に解消されます。 運がよければ、彼らは問題を見つけようとして問題を見つけたので、彼女は自分を辞めました。 結果は奇妙です。クライアントは文句を言いますが、何も見えないようです。 ポーリング間隔を短くすることは可能ですが、同時に、監視するサービスの負荷、そして最良の伝統では、クラッシュを検出するように設計されたシステム自体がそれらを生成し始めます。
ほぼ真ん中に、深刻な事故の場合、アクティブな危害監視システムは情報を過剰に提供し、実際の問題の検出を妨げるため、それ以上のものになるという理解があります。 もちろん、アクティブ監視システムは有用であり、その機能を果たします。 しかし、それらが特効薬ではないことは明らかであり、それらに完全に依存することは近視眼的です。 障害管理システム（FMS）が助けになります。 最初の近似では、これらはイベントを分析および処理するためのシステムです。 一般的なフローでは、おそらく事故に関する情報を含むいくつかのイベントがあります。 FMSの最初のタスクは、過剰なものを除外し、ただちに注意が必要なものだけを残すことです。 通常、まだ多くの情報が残っており、オペレーターにはそれを処理する時間がありません。 したがって、FMSシステムは、検出された事故に優先順位を付けて、最も重要な事故を強調する必要があります。 さらに、イベントは独立しておらず、それらの一部は相互接続されていることがわかります。 イベントの相関の結果として、FMSは障害間の接続を確立し、冗長な情報を隠します。 次に、最も難しい質問が発生します。重大度の異なる多くの事故が見つかりましたが、どれが原因ですか。 たとえば、リンクのドロップにより、数百のMPLS LSP、数十のBGPセッションが切断され、IGPでトポロジが再構築され、数千のサーバーのファームがしばらくアクセスできなくなることがあります。 一部のFMSシステムは根本原因分析を実行します。 その結果、オペレータには、誘発されたすべてのクラッシュの真の原因が表示され、時間を無駄にすることなくトラブルシューティングをすぐに開始することができます。
用語を定義しましょう：
- イベント：ネットワーク内の任意のポイントで任意の時間に発生および発生し、ネットワークステータスの変化を引き起こしたことに関するメッセージ
- アラーム：サービスの部分的または完全な低下につながり、オペレーターからの即時対応が必要な重大なインシデント
FMSの主な利点は、アクティブな監視システムと比較されます。 当分の間、それらは受動的であり、ネットワークデバイスに不必要な負荷をかけず、ハードウェアを提供するログとSNMPトラップをリッスンするだけです。 さらに、それらには別の顕著な品質があります-イベントの流れの直後に緊急事態が監視され始め、システムに何を見る必要があるかを正確に示す必要はありません。 最初の結果は単に衝撃的です。システムは、長い間使用されていない電源、故障したトランシーバー、点滅するリンクを突くなど、あらゆる方法で妨害を修正する動機を見つけます。
技術的には、FMSはリアルタイムのエキスパートシステムです。 システムの中心は知識ベースであり、一般化されたエイリアンの経験と特定のネットワークを調査した結果として得られた新しい知識の両方が含まれています。 これが、FMSと監視システムの主な違いです。 監視システムはインストール中に教えられたことだけを行いますが、FMSは他のネットワークを操作する長年の経験を使用するだけでなく、ネットワーク自体を学習して適応させることもできます。
ナレッジベースの組織に応じて、FMSは4つの主要なカテゴリに分類できます。
- ルールベース：最も単純なタイプ。 知識ベースは、推論に使用される一連のルールで構成されます
- コードブック：事故につながる可能性のある一連のイベントを処理する
- ニューラルネットワーク：知識ベースの基礎は、事前に訓練されたニューラルネットワークです。
各タイプのシステムには、独自の利点と欠点があります。 一方、ルールベースのシステムはいくぶんSoldafonの直接的なアプローチになりがちです-可能な限り予測可能であり、システムがどの結論を下したかに基づいて常に理解できます。 Codebook Vectorは、頑固性が低いため、より良い結果を示す場合がありますが、ミスをする場合があります。 ニューラルネットワークは学習することができ、ノイズの多い条件で、またはイベントの一部が失われた状態でより良く機能します。 一方、システムがどのような洞察を具体的な結論に至ったのかを理解するのは難しい場合があります。 一般に、これにより、オペレーターとシステムの間でいくらかの警戒と相互不信が生じます。 さらに、すべてのニューラルネットワークと同様に、このタイプのFMSは突然自分自身に気付き、世界中の権力を握ろうとする傾向があります。
読者には非常に合理的な質問があるかもしれません-そのような素晴らしいシステムがあれば、なぜそれらは従来の監視システムほど広くないのですか？ 特に予算のインストールでは、誰もがnagios / zabbiks / cactiを配置したいのですが、通常はFMSについて覚えていませんか？ この質問への答えは非常に簡単です-価格！ FMSは決して安価なものではありません。 実際、FMSは洗練された異星人の経験であり、その経験には大きな価値があります。 価格が高い2番目の理由は、特定のネットワーク用にFMSをさらにカスタマイズする必要がある可能性が高いため、開発者の経験に加えて、インテグレーターの経験も購入する必要があることです。
通常、FMSの実装予算には通常6個以上のゼロが含まれており、自動的に多数の大規模ネットワークになります。 気配りのある読者は間違いなく言うでしょう-しかし、私たちはオープンソースを持っています！ もちろん、オープンソースというフレーズはマントラとして繰り返すことができますが、口の中で甘くなることはありません。 オープンソースでのFMSの方向は表されていないと仮定できます。
前の記事で説明したネットワーク管理への統合アプローチの一環として、私たちはNOCのフレームワーク内で本格的なFMSを提供しました。 NOCのフレームワーク内でのFMSプロジェクトの主な目的は、オープンソースプロジェクトのフレームワーク内で商用システムの本格的なFMSレベルを作成することです。
オープンソースFMSの作成に至った基本的な考え方は非常に単純です。FMSは経験です。 ネットワーカは、オープンソース製品を喜んで使用し、同様にそれらを開発することをいとわない。 では、何が彼らの経験を少し形式化し、同僚と共有することを妨げるのでしょうか？ その結果、システムは、ソーシャルネットワークに既に近い予期せぬプロパティを取得します。 システムの学習プロセスは分散されます。 誰かがシステムを知らない事故に遭遇し、それを学び、新しいルールが一般的なデータベースに入り、次の更新で全員に広まりました。 現時点では、システムは約40種類の事故を認識できます（詳細については、 こちらをご覧ください ）。 システムトレーニングは、ジュニパー、Force10、Cisco、f5、DLink、Zyxel機器に基づいて構築されたネットワークで実施され、ハードウェアサポートは常に拡大しています。 計画によれば、 NOC 0.7は9月にリリースされ、強固な知識ベースを持つ新しいFMSが含まれます。 時間が経つにつれて、FMSが大規模なネットワークの多くでなくなり、さらに普及することを願っています。
NOCでのFMSの実装の機能については、以下の記事で詳しく説明します。