JP2010524130A - 集中ワークフロー・モニタリング - Google Patents

Abstract

コンテンツ管理システム（１０）などのシステムの集中監視が、ステータス情報重大度に応じてエレメントにより、システム内のエレメントからのステータス情報を記憶する監視装置（１１）によって実行される。監視装置は、当該情報についてのアラートを生成するか否かを判定するために少なくとも１つのユーザ規定規則を施すことにより、重大度の順序で各エレメントのステータス情報を処理する。

Description

本出願は、内容を本明細書及び特許請求の範囲に援用する、西暦２００７年４月１２日付け米国特許仮出願第６０／９２３１０１号明細書の優先権を米国特許法第１１９条（ｅ）項の下に主張する。

本発明は、複数のソースから収集されたステータス情報を管理する手法に関する。

オーディオ・ビデオ・プログラムを含む電子ファイルの形式のコンテンツを受信し、処理し、かつ／又は配信する放送業者などのエンティティは通常、前述のコンテンツを管理するために大規模システムを利用する。前述の大規模システムは決まって、コンテンツの受信、処理、及び／又は配信に関連付けられた種々の動作を監視する機能を有する。議論を容易にするために、前述の動作の組合せはコンテンツ・ワークフローとして表される。実際には、コンテンツ・ワークフローの監視により、ログ・ファイル及び／又はステータス・メッセージを含み得るステータス情報が生成される。コンテンツのワークフロー、及び受信コンテンツの量に関連付けられた動作の数に応じて、コンテンツ管理システムは大量のステータス情報を生成することが可能である。一部のステータス情報は、人間のオペレータによる即座の手当てを必要とする一方、他のステータス情報は、手当てを必要とする場合でもあまり必要としないものであり得る。

現在のコンテンツ管理システムに関連付けられたロギング・ツールでは、時間順に、コンテンツ・ワークフローを行うためのハードウェア及び／又はソフトウェア構成部分を含む複数のエレメントのビュー、ソートを行い、上記エレメントからステータス情報をフィルタリングする機能はほとんど提供されていない。ステータス情報の量が多いほど、この問題はより顕著になってきている。現在のコンテンツ管理システムのロギング・ツールは、動作アラームに含まれる汎用的なログ情報を、オペレータが適切に対応することが可能な適切な情報に変換することができないために別の問題を招いている。

管理されたエレメントは、膨大な数のフォールス・ポジティブを送出する傾向にあり、それにより、適切でない事象の追跡にオペレータが時間を費やすことになるので、このことは、エレメントの監視、及びそれに関連付けられたアラームのフィルタリング及び通知において、相変わらず、最も重大な課題となっている。

現在のロギング・ツールは通常、システム・ダッシュボード（すなわち、動作条件の視覚表示）を作成する機能も、レポートを生成する機能も欠いている。現在のコンテンツ管理システムによって通常生成されるステータス情報が大量であるため、オペレータは、適切な活動に関するレポート、及び定期的なアップデートを必要とする。現在のコンテンツ管理システムの、レポートを生成し、表示するためのダッシュボードを生成する方法において存在している手法は、機能も柔軟性も欠いているので、放送環境において不十分な状態に留まっている。

前述のロギング・ツ―ルの別の欠点は、効率的なメッセージ抑制を行うことができないという点である。実際には、メッセージ・ロギングを含む監視システムは、メッセージをプロンプトする状態が続いている限り、等間隔でメッセージを生成する。前述の反復メッセージは、緊急状態の場合に有用であることが分かり得る。しかし、特定の活動の完了などの多くの定常状態の場合、前述の状態を示すメッセージの反復はむだが多いことが分かる。前述の問題は、大半の監視アプリケーションが被り、それにより、膨大な量のデータ・ソート及びむだの多い記憶がもたらされる。

現在のコンテンツ管理システムは更に、施設内の資産を追跡することができないことに苦慮する。現在のコンテンツ管理システムは、大量のディジタル資産を施設にわたって移動させることが可能であるが、その施設内の複数の場所においてディジタル資産の品質を表示し、測定するための標準的な機構を欠いている。特定の場所において資産の品質を表示し、測定するための前述の標準的な機構を欠いていることにより、複数のベンダの別々の機器の混合及びマッチングが妨げられ得る。

簡潔に言えば、本願の原理の好ましい実施例により、ネットワーク等などのシステムにおけるエレメントから受け取られたステータス情報を管理する方法を提供する。上記方法は、エレメントの特性、及びステータス情報の重大度により、エレメントからの前述のステータス情報を記憶することによって始まる。ステータス情報が取り出され、その後、前述の情報についてのアラートを生成するか否かを判定するための少なくとも１つのユーザ規定された規則を施すことにより、エレメント毎の重大度の順序で処理される。

本願の原理による、ステータス情報を管理するための監視装置を組み入れたコンテンツ管理システムの例示的な実施例を表すブロック概略図である。 図１の監視装置を表すブロック概略図である。 図１及び図２の監視システムによって供給されるステータス情報の例示的な表示を表す図である。 図１及び図２の監視システムによって供給されるステータス情報の例示的な表示を表す図である。 図１及び図２の監視システムによって供給されるステータス情報の例示的な表示を表す図である。 監視装置が特定のステータス情報を抑制するやり方を表す、図２の監視装置の一部分を表すブロック概略図である。 資産追跡を行うために、図２の監視装置によって実行される方法の工程をフローチャート形式で表す図である。

図１は、本願の原理により、コンテンツ管理システムから受け取られたステータス情報を管理するための、以下に更に詳細に説明する監視装置１１を含むコンテンツ管理システム１０の例示的な実施例のブロック概略図を表す。通常、コンテンツ管理システム１０は、全て、ワーク・フロー・マネージャ１２の制御下で動作する複数の個々のエレメントを含む。各エレメントは、コンテンツの受信、処理及び／又は配信（すなわち、コンテンツ・ワークフロー）のうちの少なくとも１つに関連付けられた少なくとも１つのタスクを行うための１つ又は複数のハードウェア装置及び／あるいは１つ又は複数のソフトウェア・プログラムの形式をとる。実際には、コンテンツ管理システム１０は、１つ又は複数のソースからのコンテンツを受信し、記憶する役目を担う第１のエレメント１３を含む。前述のコンテンツ・ソースは、インターネット１４によって表されるコンテンツ配信ネットワーク（ＣＤＮ）、テレビジョン・カメラ１６によって表される生コンテンツのソース、衛星受信器１８によって表される無線ＣＤＮ、及びコンテンツ記憶装置２０によって表される記憶コンテンツのうちの１つ又は複数を含み得る。

着信コンテンツのバッファリングに加えて、コンテンツ受信エレメント１３は、着信コンテンツの復号化などの１つ又は複数の更なる処理を行うことが可能である。コンテンツ受信エレメント１３において当初受信されたコンテンツは第２のエレメント２２に進み、第２のエレメント２２は、例えば、特定のメタデータを受信コンテンツに加える工程を含み得る少なくとも１つの処理「Ａ」を行う。エレメント２２において処理されたコンテンツは次いで、エレメント２４に進み、エレメント２４は、コンテンツに対して少なくとも１つの第２の処理「Ｂ」を行う。第２の処理は、コンテンツの編集を含み得る。図１は、２つの処理Ａ及びＢを連続して行うためのエレメント２２及び２４のみを表しているが、図１のコンテンツ管理システム１０は、着信コンテンツに対して連続して、より多く又はより少ない数の処理を行うためのより多いエレメント又はより少ないエレメント（図示せず）を含み得る。

連続した処理を行うためのエレメント２２及び２４に加えて（又はエレメント２２及び２４の代わりに）、コンテンツ管理システム１０は、並列に処理を行うための２つ以上のエレメントを含み得る。図１の例証的な実施例では、コンテンツ管理システム１０は、エレメント２４の出力において受信されたコンテンツに対して処理「Ｃ」、「Ｄ」及び「Ｅ」それぞれのうちの少なくとも１つをそれぞれが行うエレメント２６、２８及び３０を含む。受信されたコンテンツに対して処理Ｃ、Ｄ及びＥそれぞれのうちの少なくとも１つをエレメント２６、２８及び３０のうちのどれが行うかはコンテンツに関連付けられた１つ又は複数の属性に依存する。例えば、コンテンツのサイズは、行われた特定の処理を支配し得る。図１は、並列処理Ｃ、Ｄ及びＥそれぞれを行うための３つのエレメント２６、２８及び３０を表すが、コンテンツ管理システムは、より少ない数又はより多い数の処理を並列に行うためのより少ない数又はより多い数のエレメントを含み得る。コンテンツ・フィニシング・エレメント３２は、エレメント２６、２８及び３０それぞれによって処理されたコンテンツを受信し、通常、コンテンツ記憶及び／又は配信の前に１つ又は複数の処理を行う。例えば、コンテンツ・フィニシング・エレメント３２は、コンテンツ圧縮を行うことが可能である。

エレメントの厳密な数、及びそれによって行われる処理の特性は、連続であっても並列であっても変わり得る。相変わらず重要な点は、エレメント１３及び２２乃至３２のうちの１つ又は複数が通常、コンテンツ・ワークフローの過程で（併せて「ステータス情報」と表す）ログ・ファイル及び／又はステータス・メッセージを生成するという点である。コンテンツ管理システム１０におけるエレメントの数が多く、処理されるコンテンツの量が多いほど、監視装置１１によって処理されるステータス情報の量が多くなる。

本明細書及び特許請求の範囲記載の、本願の原理の監視装置１１は効果的には、情報及びステータス情報の重大度を供給したエレメントに応じて前述のステータス情報を記憶する。監視装置１１は、記憶されたステータス情報を取り出し、その後、当該情報についてのアラートを生成するか否かを判定するために少なくとも１つのユーザ規定規則を施すことにより、エレメント毎の重大度の順序でステータス情報を処理する。実際には、ディスプレイ３４は前述のアラートを表示するが、前述のアラートは他のやり方で供給することが可能である。

図２は、図１の監視装置１１のブロック概略図を表す、図２に表すように、監視装置は少なくとも１つの情報リスナを有し、好ましくは、複数の情報リスナ（例証的には、情報リスナ２００_１、２００_２及び２００_３として表す）を有する。情報リスナ２００_１乃至２２０_３それぞれは、エレメント１２及び２２乃至３２の１つ又は複数からの特定のプロトコル又は形式におけるログ・ファイル及び／又はメッセージの形式でステータス情報を受け取るための１つ又は複数のハードウェア・エレメント及び／あるいは１つ又は複数のソフトウェア・プログラムを備える。各情報リスナは、受信されたステータス情報を共通形式に合致させる。例えば、情報リスナ２００_１は、「シスログ」プロトコルにおける情報を求めてリッスンする一方、情報リスナ２００_２は、「ＷＳ管理」プロトコルにおいてインターネットのワールドワイド・ウェブを介して搬送される情報を求めてリッスンする。最後に、情報リスナ２００_３は、将来開発されるプロトコルを表すプロトコル「ｘ」における情報にリッスンする。図２の例証された実施例は３つの情報リスナ２００_１乃至２００_３を表すが、処理監視装置１１は、本願の原理から逸脱しない限り、前述の情報リスナのより少ない数又はより多い数を含み得る。

情報リスナ２００_１乃至２００_３それぞれによって合致させたステータス情報は、プロセッサ２０２による処理を行う。特に、プロセッサ２０２は、その知識が受信ステータス情報に含まれる、ステータス情報の重大度、及び情報を供給した図１のコンテンツ管理システム１０内のエレメントに応じて情報リスナ２００_１乃至２００_３からの受信ステータス情報を編成する。プロセッサ２０２は、インデックスされたデータベース２０４においてそのやり方で編成されたステータス情報を記憶する。よって、データベース２０４にアクセスすることにより、プロセッサ２０２はよって、重大度の順序で、特定のエレメントのステータス情報を得ることが可能である。

実際には、データベース２０４は、説明されたやり方で編成されるステータス情報を記憶するのみならず、特定のステータス・メッセージについてのアラートを生成する時点を供給する少なくとも１つの（、及び好ましくは複数の）ユーザ規定された規則も記憶する。むしろ、データベース２０４に、ユーザ規定された規則を記憶する。別個のデータベース（図示せず）は前述の規則を記憶することが可能である。

ユーザ規定された規則により、少なくとも１つの所定の状態の検出により、アラートを生成するようにしている。例えば、ユーザ規定された規則により、特定のエレメントについて、上記エレメントが、「心拍」信号とも時々呼ばれる周期信号を特定の間隔内に生成せず、エレメントに障害が生じた旨が示唆された場合、アラート・メッセージを生成すべきであるようにしている。別の例として、特定のエレメントについて、エレメントがコンテンツ・オーバフローを受けた場合にアラートが生じる。よって、ユーザ規定された特定の規則が全てのエレメント、一部のエレメント、又は単一のエレメントのみに適用され得る。特定のエレメントについて、ユーザ規定された規則は、ステータス情報の重大度にかかわらず、アラートの生成を要求することが可能である。あるいは、ユーザ規定された規則は、特定の重大度レベルを上回る場合にのみ、アラートの生成を要求することが可能である。

ユーザ規定された規則は、受信ステータス情報内の複数のステータス・メッセージの存在によって反映されるように、アラートをトリガするために２つ以上の条件の存在を必要とし得る。実際に、１つ又は複数のユーザ規定された規則は、ブール論理を使用して、アラートをトリガするために１つ又は複数のエレメントに関連付けられた種々の条件を規定することが可能である。実際に、ユーザ規定された規則は、ステータス情報及びその重大度を発信するエレメントと無関係に他の要因を考慮に入れてアラートをトリガすることが可能である。例えば、時刻及び／又は曜日が、アラートを生成するか否かに影響を及ぼし得る。１つ又は複数のユーザ規定された規則に従ってアラートをトリガし得る考えられる条件は、ここで言及するには多すぎる。

プロセッサ２０２は、図２中の決定ブロック２０６によって示されるようなデータベース２０４内の記憶されたステータス情報に、ユーザ規定された規則を適用して、アラートを生成するか否かを判定する。ステータス情報が少なくとも１つの規則に一致していることが分かると、プロセッサは、ブロック２０８における動作によって示されるようなアラートを生成する。前述の通り、データベース２０４に常駐しているステータス情報は、ステータス情報の重要度の順序でエレメントによって索引化される。よって、プロセッサ２０２は、ステータス情報の重大度の順序に、連続したエレメントについてのアラートを生成する。このようにして、オペレータは、装置、装置タイプ、日時、及びメッセージ重大度に基づいてログ・メッセージを表示し、ソートすることが可能である。プロセッサ２０２は、ステータス情報の表示を最適化し、高速応答をもたらすためにページネーション手法を利用する。

図１の監視装置１１は、ネットワーク運用センター（ＮＯＣ）（図示せず）と通信することが可能である。関連付けられたコンテンツ管理システム１０によって行われる特定のコンテンツ・ワークフローの場合、そのコンテンツ管理システムに関連付けられた監視装置１１は、ＨＴＭＬにより、オンデマンドでＮＯＣに当該情報を供給するためにステータス情報を記憶するためのそれ自身のデータベースを維持する。

前述の通り、装置を監視し、アラームを生成するようステータス・メッセージをフィルタリングする現在のコンテンツ管理システムは、適切でないイベントを追跡する時間をオペレータが費やすことを必要とする非常に多数のフォールス・ポジティブを発生させるという問題に苦慮する。図１の監視装置１１は効果的には、１つ又は複数のユーザ規定された規則の適用によって定められるような、コンテンツ管理システム１０の動作に関連したステータス情報をアラームに変換する。そうすることにより、汎用的なログ機構に対処する場合、施設内のフォールス・アラームの率が削減される。

プロセッサ２０２は、装置及びステータス情報重大度によって編成されるような、ステータス情報の種々の部分の表示をもたらすための種々の表示（多くの場合、「ダッシュボード」として表す）を生成する機能を有するグラフィクス・エンジン（図示せず）を含む。前述のグラフィクス・エンジンは、情報の図形表示を作成する機能を有する１つ又は複数の周知のソフトウェア・プログラムを含み得る。プロセッサ２０２におけるグラフィクス・エンジンは、自動ダッシュボード回転を可能にし、種々の構成要素のステータスのシステム全体を概観することを可能にする。より多くの情報が特定のエレメントについて望ましい場合、単にアイテムの上にマウスを移動させることにより、更なる詳細がもたらされる。現在のステータスに対する高速アクセスをもたらすために、特定のエレメントについて、そのエレメントについての当該情報の記憶を局所に行い、そのエレメントについての当該情報をウェブページを介して扱うことが可能である。特定のエレメントのステータス情報は、ワークフロー環境設定を含むソフトウェア及びハードウェア構成部分に関連付けられた情報を含み得る。

図３Ａは、図１のコンテンツ管理システム１０内の特定のエレメントと、選択された宛先との間の往復レーテンシを表示する第１の例示的なダッシュボードを表す。図３Ｂは、特定のコンテンツ管理システムについて特定の期間の結果履歴を表示する第２の例示的なダッシュボードを表す。図３Ｃは、種々のコンテンツ管理システム・エレメントの重大ステータス情報を表示する更に別の例示的なダッシュボードを表す。そのグラフィックス・エンジンを使用すれば、プロセッサ２０２は、データベース２０４から、記憶されたステータス情報を抽出し、スタイル・シートにアクセスし、スタイル・シートを作成するためにＨＴＭＬを使用して複数の形式で前述の情報を表示することにより、他のダッシュボードを提供することが可能である。図３Ａ、図３Ｂ及び図３Ｃに表すものなどのダッシュボードは、図１のコンテンツ管理システム１０の動作全体の監視及び評価を可能にして、傾向分析を可能にする。

図２のプロセッサ２０２は効果的には、抑制されたステータス情報の頻度をユーザが観察することが可能であるように対数メッセージ抑制アルゴリズムを使用して特定のステータス情報を抑制することが可能である。プロセッサ２０２は、簡易ネットワーク管理プロトコル（ＳＮＭＰ）を使用してフォーマッティングされたステータス情報、及び非ＳＮＭＰフォーマッティングされたステータス情報を抑制することが可能である。話を単純にするために、ＳＮＭＰメッセージ抑制のみについて記載する。

図４は、１つ又は複数の「トラップ」を使用してメッセージ抑制を行う、図２のプロセッサ２０２内に常駐しているＳＮＭＰエンジン４００を表すブロック概略図である。以下に説明するように、各トラップは、当該メッセージを抑制する旨の特定の状態に関連付けられた特定のメッセージをフィルタリングする役目を担う。実際には、ＳＮＭＰエンジン４００は、抑制を行うための１つ又は複数のソフトウェア・プログラムを含む。しかし、説明を簡単にするために、前述のソフトウェア・プログラムは、機能エレメントとして図４に関して説明する。ＳＮＭＰエンジン４００は、特定のステータス情報を抑制すべきエレメント１２及び２２乃至３２のうちの特定の１つに関連付けられたインタフェースの形態をそれぞれがとる少なくとも１つの（好ましくは、複数の）トラップ・リスナ４０２を含む。各トラップ・リスナによって得られるステータスは、トラップ処理エンジン４０６によって確立される１つ又は複数のトラップに応じて、以下に説明するやり方で抑制を行うための１つ又は複数のソフトウェア・プログラムの形式をとる抑制エンジン４０４に進む。

抑制エンジン４０４は、受信されたトラップ毎に抑制情報を記憶するハッシュ・テーブルを有する。受信された各トラップは、トラップの頻度に依存する期間の間、ハッシュ・テーブルに留まる。

ハッシュ・テーブルは以下の構造を有する。
ｓｔｒｕｃｔ ＴｒａｐＫｅｙ
｛
ｓｔｒｉｎｇ ｓｔｒＤｅｖｉｃｅｌｐ；
ｓｔｒｉｎｇ ｓｔｒＴｒａｐＯｉｄ；
ｓｔｒｉｎｇ ｓｔｒＣｏｍｍａＳｅｐｅｒａｔｅｄＶａｒＢｉｎｄｉｎｇｓ；
｝
パラメータ「ｓｔｒＣｏｍｍａＳｅｐｅｒａｔｅｄＶａｒＢｉｎｄｉｎｇｓ」は、プロセッサ２０２に関心のある、トラップｖａｒｂｉｎｄ ｘｍｌデータとして表す、データベース４０８からの情報を使用することによって形成される列を構成する。例えば、トムソン・グラス・バレー（オレゴン州ビーバートン）から入手可能なトムソン・グラス・バレー「ＰＶＳ」タイプのサーバなどのビデオ・サ―バ内のファン（図示せず）におけるステータス変動を表すメッセージを抑制するためのトラップを考察する。トラップ
「ｐｖｓＦａｎＳｔａｔｕｓＣｈａｎｇｅ」（ｏｉｄ ＝ １．３．６．１．４．１．４９４７．２．２．２．０．４）の場合、変数バインディングは、
ｐｖｓＬａｓｔＴｒａｐＣａｔｅｇｏｒｙ （１．３．６．１．４．１．４９４７．２．２．２．１．４）
ｐｖｓＦａｎＳｔａｔｕｓ （ １．３．６．１．４．１．４９４７．２．２．２．３．７．１．１）である。

ＩＰがｘ．ｘ．ｘ．ｘであるデバイスから上記トラップが受信され、変数バインディングの値が２の場合、ハッシュ・テーブル鍵は、
ｓｔｒＤｅｖｉｃｅｌｐ ＝ 「ｘ．ｘ．ｘ．ｘ」
ｓｔｒＴｒａｐＯｉｄ ＝ 「１．３．６．１．４．１．４９４７．２．２．２．０．４」
ｓｔｒＣｏｍｍａＳｅｐｅｒａｔｅｄＶａｒＢｉｎｄｉｎｇｓ ＝ 「１．３．６．１．４．１．４９４７．２．２．２．１．４＝２，１．３．６．１．４．１．４９４７．２．２．２．３．７．１．１＝２」
になる。

更に、パラメータ「ｓｔｒＣｏｍｍａＳｅｐｅｒａｔｅｄＶａｒＢｉｎｄｉｎｇｓ」は、未使用変数バインディングでなく、プロセッサ２０２によって使用される変数バインディングのみを有する。どの全変数が有用であるかを判定するために、プロセッサ２０２は、セットアップ又はアップグレード時に、トラップ Ｖａｒｂｉｎｄ ｘｍｌデータについてデータベース４０８において検査する。

トラップＯＩＤが存在しない場合、２つの可能性が存在する。ユーザが未処理トラップの無視を選択した場合、そのトラップは無視される。さもなければ、トラップとともに送出された変数バインディングは全て、トラップ鍵を生成するために使用される。

変数バインディングからハッシュ・テーブル鍵を作成している間（又は、トラップｖａｒａｂｉｎｄ ｘｍｌファイル・データベース４０８においてトラップの変数バインディングをサーチしている間）、変数バインディングに付加されたインデクスは除去すべきである。さもなければ、比較は首尾良く実行されない。トラップが受信されると、プロセッサ２０２は、トラップのエントリが存在しているか否かを判定するようハッシュ・テーブルを検査する。

以下のデータ構造は、トラップ抑制に関する情報を記憶する。
ｓｔｒｕｃｔ ＴｒａｐＳｕｐｐｒｅｓｓｉｏｎＤａｔａ
｛
ｔｉｍｅ ｅｎｔｒｙＴｉｍｅ （ＥｎｔＴ）
ｉｎｔ ｎＳｕｐｐｒｅｓｓｉｏｎｌｎｔｅｒｖａｌ （ＳＩ）
ｉｎｔ ｎＳｕｐｐｒｅｓｓｉｏｎＣｏｕｎｔ （ＳＣ）
ｉｎｔ ｎＥｘｉｔＴｉｍｅ （ＥＴ）
ＨＶＢＬ ｈＶＢＬ
｝；
パラメータ「ｅｎｔｒｙＴｉｍｅ （ＥｎｔＴ）」は、トラップが抑制テーブルに入力される現在のシステム時間を構成する。更に、この時間は、抑制データがテーブルにおいてアップデートされる都度、アップデートされる。パラメータ「ＨＶＢＬ ｈＶＢＬ」は、変数バインディング・リストを構成する。パラメータ「Ｓｕｐｐｒｅｓｓｉｏｎｌｎｔｅｒｖａｌ（ＳＩ）」は、同じトラップが受信されると抑制される間隔を構成する。この間隔は、同じトラップが、トラップの頻度に応じて連続して受信されるかを調節する。この間隔は、同じトラップがエージング時間内に、かつ、旧い抑制期間が満了した後に受信された場合、２の累乗で増加する。トラップが始めて受信されると、この間隔は０秒である。同じトラップがエージング時間内に受信された場合、この間隔は１秒になる。１秒（２^０）内に受信されるトラップは何れも、その場合、（抑制期間が１であるので）抑制される。抑制期間（１秒）が経過した後に同じトラップが再受信された場合、抑制間隔は、１秒（２^１）になる、等である。よって、抑制間隔は式２^ｘに従う。ここで、ｘは、受信反復メッセージ全てが抑制される秒数である。２^ｘの期間内のトラップは何れも抑制される。

パラメータ「Ｓｕｐｐｒｅｓｓｉｏｎ Ｃｏｕｎｔ （ＳＣ）」は、特定の抑制間隔の間の抑制トラップの数を構成する。抑制間隔が変わると、抑制カウントが再びゼロから開始する。

いくつかの他のパラメータは、抑制アルゴリズムを完了するために算出を必要とする。パラメータ「ＡｇｉｎｇＴｉｍｅ（ＡＴ）」は、トラップがハッシュ・テーブル内に留まる間隔を構成する。デフォルトで、ＡＴはＥｎｔＴｉｍｅから３２秒になる。ＡＴのデフォルト値は、レジスタ鍵によって変えることが可能である。更に、これは、サポートされる最大抑制間隔を構成する。トラップが初めて受信されると、エージング時間はデフォルト値（現在のマシン時間から３２秒）にセットされ、トラップがテーブルに追加される。更に、上記間隔は更なる処理のために送出することが可能である。エージング時間が経過すると、トラップ・エントリは、テーブルから除外される。旧いトラップが既にテーブルに存在している間に同じトラップが再度受信された場合、エージング時間は、ＥｎｔＴｉｍｅ ＋ デフォルトのＡＴ ＋ Ｓｕｐｐｒｅｓｓｉｏｎｌｎｔｅｒｖａｌ（ＳＩ）にセットされる。更に、抑制されるトラップは何れも、ＡＴをＥｎｔＴｉｍｅ ＋ デフォルトのＡＴ ＋ Ｓｕｐｐｒｅｓｓｉｏｎｌｎｔｅｒｖａｌ（ＳＩ）に変える。

パラメータ「ＥｘｉｔＴｉｍｅ（ＥＴ）：ＥｎｔＴ ＋ ＳＩ」は、現在の抑制時間が満了する時間を構成し、何れかのトラップがこの間隔の終了時に抑制された場合、トラップは、抑制カウントとともに処理のために送出されなければならない。すなわち、これは、同じトラップが受信されたかを確かめるためにトラップが保留にされる時間である。トラップは、抑制されたトラップのカウントとともに出口時間後に処理のために転送される。

以下に、同じトラップがその間隔で到来した場合、ハッシュ・テーブルがどのようにして変更されるかの例である。

上述の通り、図１の監視装置１１は、コンテンツ・ワークフロー中に資産を追跡する機能を有する。図５は、本願の原理による、コンテンツ・ワークフロー中に資産を追跡する処理の工程をフロ―チャート形式で表す。図５の資産追跡処理は、図１のワークフロー・エンジン１２によって定められるような特定のコンテンツ・ワークフローについて選択される各エレメントのステータスを監視する。工程５０２中、エレメントが適切に動作しているかを判定するための検査が行われる。否定の場合、図１のプロセッサ２０２は、工程５０４中に、さもなければ、不良エレメントによる処理にセットされた資産を移動させるようワークフロー１２のエンジンに連絡する。さもなければ、プロセッサ２０２は、検査されたエレメントが適切に動作していることを確かめると、コンテンツ・ワ―クフロー中に資産を受信するようスケジューリングされた次のエレメントへのネットワーク伝導度をプロセッサが確実にする工程５０６が行われる。工程５０４及び工程５０６の何れかに続いて、プロセッサ２０２は、工程５０８で、図１のコンテンツ管理システム１０におけるエレメントを結びつけるネットワークを検査する。プロセッサ２０２は、工程５０８で、ネットワークの何れかの部分に不良があることを見出した場合、工程５１０中に図１のワークフロー・エンジン１２に警告する。プロセッサ２０２から受信された警告の特性に基づいて、ワークフロー・エンジン１２は、図５の工程５１０中に、ワークフローを終結させるか、又はなお適切に動作しているネットワークの部分が扱うエレメントを利用するワークフローに進むことにすることが可能である。

図５の工程５０８中にネットワークが適切に動作していることが見出されると、図２のプロセッサ２０２は、工程５１２中に資産を次のエレメントに移動させる旨を図１のワークフロー・エンジン１２に警告する。その後、ユーザは、工程５０４中に選択されたような別のルートを資産が進んだ場合でも資産の新たな場所を示す情報を工程５１４中に受信する。次に、工程５１６中に、資産はインテグリティ検査を経る。工程５１８中に、資産が良好であることが見出された場合、工程５２０中にコンテンツ・ワークフローは続く。さもなければ、資産が良好でない場合、処理は工程５１０に進む。工程５１０の間には、ワークフロー・エンジンは警告を受信する。

以上、コンテンツ管理システムを備えた種々のエレメントから収集されたステータス情報を管理する手法を説明した。ステータス情報管理手法は、コンテンツ管理システムの意味合いで説明しているが、より一般的に、複数のエレメントを有する何れのシステムにも当てはまり得る。

Claims (15)

1. エレメント及びステータス情報重大度に応じて索引化された、システムにおける複数のエレメントからのステータス情報を記憶する工程と、
   前記情報についてのアラートを生成するか否かを判定するために少なくとも１つのユーザ規定された規則を施すことにより、エレメント毎の前記ステータス情報重大度に応じてエレメント毎の前記ステータス情報を処理する工程と
   を含む方法。
2. 請求項１記載の方法であって、前記記憶する工程は、
   特定のプロトコルにおいて少なくとも１つのエレメントからステータス情報を受信する工程と、
   前記ステータス情報を共通形式に合致させる工程と
   を含む方法。
3. 請求項１記載の方法であって、前記ステータス情報の少なくとも一部分が前記少なくとも１つのユーザ規定された規則に一致する場合にアラートを生成する工程を更に含む方法。
4. 請求項１記載の方法であって、前記ステータス情報の少なくとも一部分が複数のユーザ規定された規則に一致する場合にアラートを生成する工程を更に含む方法。
5. 請求項３記載の方法であって、アラートを生成する工程が視覚アラートを生成する工程を含む方法。
6. 請求項１記載の方法であって、前記記憶されたステータス情報を、自動的に生成され、アップデートされるダッシュボードとして表示する工程を更に含む方法。
7. 請求項１記載の方法であって、前記処理する工程は、選択されたステータス情報を抑制する工程を更に含む方法。
8. 請求項７記載の方法であって、少なくとも１つの選択されたエレメントから発信されるステータス情報を抑制する工程を更に含む方法。
9. 請求項７記載の方法であって、複数の選択されたエレメントから発信されるステータス情報を抑制する工程を更に含む方法。
10. 請求項７記載の方法であって、ユーザによって選択された少なくとも１つのエレメントからのステータス情報を抑制する工程を更に含む方法。
11. 請求項７記載の方法であって、ユーザによって選択された複数のエレメントからのステータス情報を抑制する工程を更に含む方法。
12. 装置であって、
    少なくとも２つの別々の形式においてステータス情報を複数のエレメントから受信し、前記ステータス情報を共通形式に合致させる手段と、
    情報重大度の順序でエレメントによって索引化された前記ステータス情報を記憶する手段と、
    前記記憶されたステータス情報が少なくとも１つのユーザ規定された規則に一致する場合にアラートを生成するための少なくとも１つのユーザ規定された規則を施すことにより、前記記憶されたステータス情報を処理する手段とを備える装置。
13. 請求項１２記載の装置であって、前記プロセッサによって生成されるアラートを表示するためのディスプレイを更に含む装置。
14. 請求項１２記載の装置であって、前記プロセッサは、選択されたステータス情報を抑制する手段を含む装置。
15. 請求項１４記載の装置であって、前記抑制手段は更に、
    選択された条件に関するステータス情報の抑制を規定するトラップを検出する第１の手段と、
    前記第１の手段に応じ、前記記憶されたステータス情報が前記選択された条件に関するステータス情報を含むか否かを判定し、肯定の場合、前記選択された条件に関するステータス情報を削除する第２の手段とを備える装置。

Images