(57)【要約】【課題】  データのリモート監視方法を提供する。【解決手段】  ストレージ制限付き装置上で実行されているアプリケーション・プログラムから出力されるログ・データがメモリ内データ・ファイルとして、又は別のアプリケーションの入力にパイピングされた１つのアプリケーションからの出力として、又はデータをローカル・パブリッシャ・プログラムに引き渡す名前付きパイプとしてローカル・システム・メモリに保存され、その後ローカル・パブリッシャ・プログラムによってキャプチャされる。ローカル・パブリッシャ・プログラムは、当該データをパブリッシュ／サブスクライブ・ブローカに送信し、パブリッシュ／サブスクライブ・ブローカは、１つ又は複数のサブスクライバによる分析用に最新のパブリケーションを保持することができる。これにより、ストレージ制限付き装置上のディスク・ストレージに大量のデータを保存する必要が解消される。【選択図】  図４
2009519509.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーション・プログラムによって生成されるログ・データのリモート監視方法であって、
前記アプリケーション・プログラムによって生成されたログ・データを前記アプリケーション・プログラムのローカルに所在する第１のデータ処理システムのメモリに保存するステップと、
前記第１のデータ処理システム上で実行されるパブリッシャ・プログラムによって実施される、
新たに保存されたログ・データを前記メモリからキャプチャするステップと、
キャプチャされた前記ログ・データを一連のパブリケーションとしてパブリッシュ／サブスクライブ・マッチング・エンジンを含む第２のデータ処理システムに繰り返し送信するステップと
を含む方法。
【請求項２】
キャプチャされた前記ログ・データを繰り返し送信する前記ステップは、
前回のパブリケーション生成以降にキャプチャされたデータを収集するステップと、
前回のパブリケーション生成以降にキャプチャされたデータを含む一連のキャプチャ済みデータがいつ閾値サイズに到達するかを特定するステップと、
トピック識別子と、前回のパブリケーション生成以降にキャプチャされた前記データとを含む新しいパブリケーションを生成するステップと、
前記新しいパブリケーションを前記第２のデータ処理システムに送信するステップと
を含む、請求項１に記載の方法。
【請求項３】
前記閾値サイズは、事前定義されたバイト数のデータを含む、請求項２に記載の方法。
【請求項４】
前記閾値サイズは、コンソール出力としての表示用に生成される事前定義された行数のログ・データを含む、請求項２に記載の方法。
【請求項５】
前回のパブリケーション生成以降の事前定義期間の経過を特定するステップと、
トピック識別子と、前回のパブリケーション以降にキャプチャされたデータとを含む新しいパブリケーションを生成するステップと、
前記新しいパブリケーションを第２のデータ処理システムに送信するステップと
を更に含む、請求項２乃至４のいずれか一項に記載の方法。
【請求項６】
ログ・ファイルに書き込まれたキーワードを特定するステップと、
トピック識別子と、前記キーワードで表現されるイベントに関するアラートとを含む新しいパブリケーションを生成するステップと、
前記新しいパブリケーションを第２のデータ処理システムに送信するステップと
を更に含む、請求項２乃至５のいずれか一項に記載の方法。
【請求項７】
前記アプリケーション・プログラムのログ・データをメモリに保存する前記ステップは、前記ログ・データを、前記パブリッシャ・アプリケーションのメモリ内入力キューを含む名前付きパイプに保存するステップを含む、請求項１乃至６のいずれか一項に記載の方法。
【請求項８】
前記アプリケーション・プログラムのログ・データをメモリに保存する前記ステップは、最も早い時期に保存されたログ・データを上書きした後に、最近保存されたログ・データを上書きすることができるように、前記ログ・データをメモリ内のサイズ制限付きファイルに循環式に保存するステップを含む、請求項１乃至６のいずれか一項に記載の方法。
【請求項９】
前記パブリッシャ・プログラムは、前記サイズ制限付きファイルをテーリングして、新たに保存されたログ・データを受信するように構成されている、請求項７に記載の方法。
【請求項１０】
前記データ処理システムの前記メモリへの保存、キャプチャ、及びパブリッシュが行われる前記データは、主に直接接続されている表示ユニット又はユーザ・コンソールを介した表示のために前記アプリケーション・プログラムによって生成されるコンソール出力データを含んでおり、そのため、前記ローカル・データ処理システムが直接接続されている表示ユニット又はユーザ・コンソールを有するかどうかに関わらず、そのようなアプリケーション・プログラムによって生成されるコンソール出力データをキャプチャ及びパブリッシュするのに適している、請求項１乃至９のいずれか一項に記載の方法。
【請求項１１】
一連の前記パブリケーションが前記第２のデータ処理システムに送信された場合に、少なくとも各トピックに関して最近パブリッシュされたパブリケーションを前記第２のデータ処理システムにおいて保持するよう求める命令を送信するステップを更に含む、請求項１乃至１０のいずれか一項に記載の方法。
【請求項１２】
一連の前記パブリケーションが前記第２のデータ処理システムに送信された場合に、前記パブリッシャからサブスクライバへの保証型配信を実施するよう求める命令を送信するステップを更に含む、請求項１乃至１１のいずれか一項に記載の方法。
【請求項１３】
データ処理装置であって、
システム・メモリと、
ログ・データを前記システム・メモリに保存するように構成された第１のアプリケーション・プログラムと、
新たに保存されたログ・データを前記システム・メモリからキャプチャし、新たにキャプチャされた前記ログ・データを一連のパブリケーションとしてパブリッシュ／サブスクライブ・マッチング・エンジンを含む第２のデータ処理システムに繰り返し送信するように構成されたパブリッシャ・プログラムと
を備えるデータ処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、機器パラメータの監視やリモート・データ処理デバイス上で実行されるアプリケーション・プログラムの出力の監視等、データのリモート監視に関するものである。
【背景技術】
【０００２】
アプリケーション・プログラムから出力されるデータを監視する必要がある場合は、アプリケーション・プログラムの出力を不揮発性ストレージ内のファイルに保存することが可能である。保存されるデータとしては、選択されたイベント及び出力を表すログ・レコードを挙げることができる。アプリケーション・プログラムの障害が発生した場合は、保存されているログ・ファイル内のデータを閲覧して問題の判定を支援し、復旧作業に役立てることができる。特に、ログ・ファイルの末尾の数行は、アプリケーションの障害が発生した経緯について有益な手掛かりを提供することが多い。したがって、アプリケーションを実行しているデバイスがログ・レコードを記憶するのに十分な不揮発性ストレージを有する場合には、ローカル・ログ・ファイルに保存されているデータを分析することによって問題を診断することができる。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
近年、携帯電話及びＰＤＡ、機器パラメータ及び気候状態の監視デバイス、石油パイプライン内の流速モニタ、居住に適さない他の遠隔環境用モニタ、車載データ処理コンポーネント、冷蔵庫、警報システム、人工環境向けの気候制御システム等、普及する組込み型データ処理デバイスの利用が急激に拡大している。これらの普及する組込み型デバイスの多くは、メモリ空間が非常に限られており、不揮発性ストレージが殆ど存在しないことやまったく存在しないこともあるため、後のエラー分析のためにほんの僅かな情報しか維持することができない。
【０００４】
必要とされる記憶空間が数メガバイトに及ぶ可能性があり、また、利用可能なストレージがすぐに埋め尽くされてしまう恐れもあるため、一部の普及デバイス上では十分な量のログ・ファイルを維持することができない場合もある。また、揮発性ＲＡＭに保存されているデータはデバイス又はアプリケーションの障害が発生した場合は消失するため、障害の分析には不揮発性ストレージに保存されているログ・レコードしか利用できないことになる。
【０００５】
アプリケーションの中には、診断メッセージを出力するローカル・コンソール・ディスプレイの存在を想定しているものもある。そのようなアプリケーションはしばしば最小限の変更を加えた上でコンソール・ディスプレイを有さない組込み型デバイス上で実行されることもある。多くの組込み型デバイス及びリモート監視装置は、コンソール・ディスプレイを有しておらず、書き込まれるログ・レコード量に対して不十分なストレージしか存在しないため、診断情報が破棄されることも多く、そのような情報を生成する潜在的な利益が失われることが多い。
【課題を解決するための手段】
【０００６】
本発明の第１の態様は、アプリケーション・プログラムによって生成されるログ・データのリモート監視方法であって、
前記アプリケーション・プログラムによって生成されたログ・データを前記アプリケーション・プログラムのローカルに所在する第１のデータ処理システムのメモリに保存するステップと、
前記第１のデータ処理システム上で実行されるパブリッシャ・プログラムによって実施される、新たに保存されたログ・データを前記メモリからキャプチャするステップと、
キャプチャされた前記ログ・データを一連のパブリケーションとしてパブリッシュ／サブスクライブ・マッチング・エンジンを含む第２のデータ処理システムに繰り返し送信するステップと
を含む方法を提供する。
【０００７】
前記アプリケーション・プログラムは、ストレージ制限付き（ｓｔｏｒａｇｅ−ｃｏｎｓｔｒａｉｎｅｄ）データ処理装置上、即ち、書き込み可能な不揮発性ストレージを有さない（即ち、揮発性ＲＡＭのみを有する）データ処理システム上、あるいは任意の時点で装置上に記憶される出力データ量を制御する必要がある、非常に限られた書き込み可能揮発性メモリ及び不揮発性ストレージしか有さないデータ処理システム上で実行することができる。
【０００８】
本発明は、前記アプリケーション・プログラムによって生成されるデータを、ログ・ファイルに保存するためにキャプチャし、あるいは診断情報、システム・アラート、前記アプリケーション・プログラムの動作に関連する他のイベント特有の出力等のコンソール出力として表示するためにキャプチャする。そのようなデータを本明細書ではログ・データと呼ぶ。前記アプリケーションは、かなり長い時間にわたってデータをローカルで収集して後の分析を可能にする、データ・ロガーとすることができる。いくつかのアプリケーション・プログラムは、ログ・データを表示することができないヘッドレス・システム上、あるいは適切な量のログ・データをローカルに保存するのに十分な記憶容量を有さないシステム上でそのようなログ・データを生成する。
【０００９】
本発明は、ログ・データをキャプチャしそれらを繰り返しパブリッシュすることにより、ストレージ制限付き装置で大量のログ・データ・ファイルを保持する必要を解消し、そのようなデータをストレージ制限付き装置のディスク・ストレージに保存する必要を解消することができる。メモリに保存され、メモリからキャプチャされ、パブリッシュされたデータは、後にメモリ内で上書きすることができる。また、本発明は、ログ・データを書き込んでいるアプリケーション・プログラムによって想定されるよりも高い頻度でログ・データをリモート・システムに送信することができる。
【００１０】
前記アプリケーション・プログラムは、センサ又はメータ出力あるいはローカルで生成される他のデータを監視することができ、ローカルのコンソール・ディスプレイ上に表示することができないログ・データあるいはローカルの不揮発性ディスク・ストレージに保存することができないログ・データを生成することもできる。別法として、前記アプリケーション・プログラムは、専用ロガー・アプリケーションとすることもできる。前記ログ・データは、破棄されることなくリモート・システム上で実行されているパブリッシュ／サブスクライブ・メッセージ・ブローカに送信されるが、この処理は、前記アプリケーション・プログラムの記録を伴わずに実現することができる。前記データは、前記ブローカ内のパブリッシュ／サブスクライブ・マッチング・エンジンによって認識することが可能な１つのトピック（又は２つ以上のトピック）に関する一連のパブリケーションとして送信され、当該トピックに関するパブリケーションの受信をサブスクライブしたサブスクライバに転送される。パブリケーションは、分析又は記憶あるいはその両方の目的で２つ以上の登録済みサブスクライバに引き渡すこともできる（これは、データを単一のアプリケーションだけに提供する大部分のテレメトリ・システムとは対照的である）。
【００１１】
本発明の一実施形態では、ストレージ制限付き装置上で実行される前記アプリケーション・プログラムは、それ自体のログ・データを前記ストレージ制限付き装置の揮発性メモリ内の「循環型（ｃｉｒｃｕｌａｒ）」データ・ファイルに保存する。「循環型」データ・ファイルは、あるファイルがそれ自体に割り当てられたすべてのメモリ空間を使用した後で新しいデータがファイルに書き込まれる際に、最初に最も古いデータを上書きすることによって上書きが行われるデータ・ファイルである。これは、前記ログ・ファイルのサイズを管理する１つの可能なメカニズムである。次に、例えば前記循環型ログ・ファイルのテーリング（ｔａｉｌｉｎｇ）等を行うことによって新しいログ・データの抽出が繰り返し実施される。前記テーリングは、前記パブリッシャ・プログラムがパブリケーションを繰り返し生成して前記新しいログ・データをリモート・システムに送信することによって実施される。
【００１２】
データ抽出及びパブリケーションの頻度は、必要なデータをパブリッシュする前にそれを上書きしてしまうことがないように制御される。より具体的に言えば、パブリッシュの生成頻度は、生成されるログ・データ量と関連付けることができる。これを達成するには様々な選択肢が存在し、例えば、最後のパブリケーション生成及び送信以降に必要な行数又はバイト数のデータが前記ログ・ファイルに保存された後に、前記パブリッシャがパブリケーションを生成することによって達成することもできる。また、パブリケーションの生成は、前記ログに追加されるいくつかのキーワードを特定することによってトリガすることも、最後のパブリケーション送信以降に一定期間が経過した時点でトリガすることもできる。
【００１３】
一代替実施形態では、前記パブリッシャがメモリ内ファイルのテーリングを行う代わりに、ストレージ制限付き装置上で実行されている第１のアプリケーション・プログラムから出力される新しいログ・データがパブリッシャ・アプリケーションに「パイピング（ｐｉｐｅｄ）」される。かくして、前記パブリッシャ・プログラムは、ログ・ファイルのテーリングを行うことによって新たに保存されたログ・データを能動的にキャプチャすることも、アプリケーションから出力されたログ・データが前記パブリッシャ・プログラムの入力に直接パイピングされている場合にはより受動的にデータをキャプチャすることもできる。また、前記ログ・データは、前記アプリケーション・プログラムと前記パブリッシャとの間の名前付きパイプに保存することができる。
【００１４】
一実施形態では、前記パブリッシャ・アプリケーションは、新しいパブリケーションを生成し、メッセージ・クライアントを介して、やはり前記ストレージ制限付き装置上で実行されているリモート・システム（又は別の通信ハンドラ・コンポーネント）に送信する。これにより、パブリッシュ／サブスクライブ型メッセージング・ネットワーク内の単純なパブリッシャ・アプリケーションを使用して、多種多様なデータ収集デバイスから出力されるデータの統合が容易となる。前記メッセージ・クライアントは、（前記ネットワーク内の中間ネットワーク・ノード上に所在する任意のメッセージ・マネージャの支援を受けて）前記リモート・システム上のパブリッシュ／サブスクライブ・メッセージ・ブローカへの前記パブリケーションのルーティングを取り扱うものである。次に、前記ブローカ内のパブリッシュ／サブスクライブ・マッチング・エンジンは、受信されたパブリケーションのトピック名（又は他のコンテンツ）と、各トピック（又は他のコンテンツ）をサブスクライバと関連付けるサブスクリプション・セットとを比較することによって、前記パブリケーションを転送すべき１つ又は複数のサブスクライバを特定することができる。
【００１５】
本発明は、ログ・データ及びコンソール表示用に収集されるデータの使用可能性を改善する。このような改善は、ストレージ制限付き装置で障害が発生した場合に有益であり、特に、ローカル装置に十分なログ・レコードを記憶する容量が存在しない場合、又はローカル装置に不揮発性ストレージが存在しない場合に有利である。パブリッシュ／サブスクライブ型通信を使用することにより、前記ログ・データを処理するアプリケーション（及びその数）に柔軟性がもたらされ、問題のリモート分析が容易となる。
【００１６】
前記パブリッシュするステップは、規則正しい時間間隔で実施されても不規則な時間間隔で実施されてもよい。後者の一例は、キャプチャされた新しいデータが事前定義されたサイズ限界に到達したときに１つのパブリケーション又は複数のパブリケーションを送信する実装形態であり、別の一例は、新しいエントリがメモリ内データ・ファイルに追加される度に１つのパブリケーションを送信する実装形態である。
【００１７】
本発明の一実施形態において、キャプチャされたログ・データはメッセージ・ブローカに送信され、当該メッセージ・ブローカは、ＩＢＭコーポレーションの製品であるＷｅｂＳｐｈｅｒｅメッセージ・ブローカの内部で実装されるようなＩＢＭのＷｅｂＳｐｈｅｒｅ  ＭＱ  Ｔｅｌｅｍｅｔｒｙ  Ｔｒａｎｓｐｏｒｔプロトコルの「保持（ｒｅｔａｉｎ）」フラグ等が使用される「保持」メカニズムを含み、保証型メッセージ配信を実現する。「ＷｅｂＳｐｈｅｒｅ」及び「ＩＢＭ」は、米国及び他の国におけるインターナショナル・ビジネス・マシーンズ・コーポレーションの商標である。「保持」オプションがパブリッシャによって選択された場合は、各トピック毎に最後にパブリッシュされたメッセージがメッセージ・ブローカ内に保持される。
【００１８】
典型的なメッセージング環境では、最後にパブリッシュされたメッセージをブローカにおいて保持する機能を用いることによって任意の新しいサブスクライバが関連するメッセージ・トピックについて最近使用可能なデータを直ちに取得すること、即ち、そのようなデータを新しいパブリケーションを待たずに取得することが可能となるため、この機能が望ましいと考えられている。それ故、保持される最後のメッセージは、最後に知られる「良好なデータ（ｇｏｏｄ  ｄａｔａ）」となることが想定される。しかしながら、パブリッシュされるデータに診断情報が含まれる本発明の一実施形態で前記保持メカニズムを使用した場合には、ストレージ制限付き装置に障害が発生した場合に有益な情報が提供される可能性がある。即ち、最後に無事送信されたパブリケーションは、故障直前の前記装置に関する有益な情報を提供する可能性があり、そのようなデータは単に最新のものであるというだけでなく、障害の診断に最も重要なデータとなる可能性が高い。
【００１９】
本発明の第２の態様は、データ処理システムであって、
システム・メモリと、
ログ・データを前記システム・メモリに保存するように構成された第１のアプリケーション・プログラムと、
新たに保存されたログ・データを前記システム・メモリからキャプチャし、新たにキャプチャされた前記ログ・データを一連のパブリケーションとしてパブリッシュ／サブスクライブ・メッセージ・ブローカに繰り返し送信するように構成されたパブリッシャ・プログラムと
を備えるデータ処理システムを提供する。
【００２０】
前記パブリッシュ／サブスクライブ・メッセージ・ブローカは、典型的にはメッセージ通信プロトコル及びメッセージ・ルーティング機能を実装するコンピュータ・プログラムと、パブリッシュ／サブスクライブ・マッチング・エンジンとを含んでおり、別個のデータ処理装置上で実行されるものである。
【００２１】
本発明の第３の態様は、本発明に係る監視方法で使用される上述のパブリッシャ・コンピュータ・プログラムを提供する。前記パブリッシャ・コンピュータ・プログラムは、記録媒体上に記録されるプログラム・コードとして使用することも、通信ネットワークを介してダウンロードされるようにすることもできる。
【００２２】
以下では単なる例示として、本発明の諸実施形態を添付図面を参照してより詳細に説明する。
【発明を実施するための最良の形態】
【００２３】
多くのアプリケーション・プログラムは、コンソール・ディスプレイ上、例えば当該アプリケーションが実行されている装置（又は当該アプリケーションが実行されているウィンドウ）の表示ユニット上に表示される情報を出力する。そのような情報は通常、新しいデータが追加されたときに最も古いデータがビュー内から消えるようにスクロール・アップされるが、末尾の情報「画面」は閲覧できるようになっている。これには２つの利点がある。第１に、ユーザは、最新のイベント又はシステム・パラメータが報告された時点でそれらをすぐに見ることができる。第２に、アプリケーションが障害によって停止した場合にも、末尾の情報画面を閲覧することができるため、問題の判定に役立てることができる。
【００２４】
しかしながら、他の装置に組み込まれるコンピュータ等、多くのコンピュータには表示ユニットが取り付けられていない（このようなシステムは「ヘッドレス」と呼ばれる）。別の問題としては、人間のユーザが表示情報を必要な時間に常に閲覧できるわけではないことが挙げられる。通常、コンソール出力は、後の閲覧用に保存可能な不揮発性ストレージ内のログ・ファイルにリダイレクトすることが可能である。しかしながら、多くの普及デバイスにはそのようなログ・ファイルを記憶するのに利用可能なストレージが殆ど存在せず、あるいはまったく存在しないこともある。
【００２５】
したがって、ストレージ制限付きヘッドレス・システム及びユーザ利便性の低いストレージ制限付きシステムを対象とする監視ソリューションが必要とされている。本発明は、専用のパブリッシュ／サブスクライブ技術に基づく解決策を利用して上記の課題に対処するものである。
【００２６】
図１には、従来の分散パブリッシュ／サブスクライブ型通信ネットワークが示されている。１つ又は複数のパブリッシャ・アプリケーション・プログラム１０、２０がそれぞれデータ処理装置３０、４０上で実行されており、パブリッシュ／サブスクライブ・マッチング・エンジン５０を含むメッセージ・ブローカにパブリケーションを送信している。１つ又は複数のサブスクライバ６０、７０、８０がそれぞれデータ処理システム９０、１００、１１０上で実行されており、これらのサブスクライバがパブリッシュ／サブスクライブ・マッチング・エンジン５０に登録されることにより、ネットワーク・アドレス情報及び他の任意の通信要件が提供される。トピック・ベースのパブリッシュ／サブスクライブ型ネットワークでは、各サブスクライバは、受信したいと望むパブリケーションのトピックを指定する。パブリッシャ１０、２０（又は各パブリッシャに関連するメッセージング・ミドルウェア１２０）は、パブリッシュ／サブスクライブ・マッチング・エンジン５０にどのように到達するかを認識しており、それぞれのパブリケーション（例えばメッセージ・ヘッダー）にトピック識別子を含める。パブリッシャは、サブスクライバのネットワーク・アドレス情報を認識している必要はなく、更にはサブスクライバのＩＤを認識している必要もない。パブリッシュ／サブスクライブ・マッチング・エンジン５０は、典型的にはネットワーク・ルーティングも取り扱うメッセージ・ブローカ・プログラムの一部を含む。メッセージ・ブローカは、パブリッシャ及びサブスクライバと離れた中間ネットワーク位置に所在するデータ処理システム１３０上で実行され、パブリッシャ及びサブスクライバの通信を大幅に簡略化するものである。パブリッシュ／サブスクライブ・マッチング・エンジン５０は、受信された各パブリケーション中のトピック名と、それ自体に記憶されているトピック名リスト１４０とを比較し、そのトピックに関するパブリケーションの受信を望むことを表明した各サブスクライバにパブリケーションを転送する。
【００２７】
他の環境では、サブスクリプション・マッチング・コンポーネントのインスタンスを各サブスクライバ・システム上で実行することができ、当該インスタンスは、ローカル・サブスクライバが興味を示すパブリケーションを特定するのに使用される。
【００２８】
図２は、本発明の一実施形態に係る監視装置２００の概略図である。本例の監視装置２００は、ごく限られたデータ記憶容量しか有さないヘッドレス・データ処理システムである。監視装置２００は、監視アプリケーション及び制御アプリケーションから出力されるログ・データをパブリッシュ／サブスクライブ・メッセージ・ブローカ・システム３００に送信するパブリッシュ機能を含む。ブローカ・システム３００に送信されるパブリケーションは、監視装置２００上で実行されている監視アプリケーション２１０からキャプチャされたログ・データを含む。例えば、監視装置２００は、流速監視、及びパイプ内の流体に関する他のパラメータ監視の特定の目的で、石油パイプライン又はガス・パイプライン内のセンサ１５０と接続されるデータ処理装置とすることができる。他のパブリッシャ・システムとしては、例えば自動計測システムや、風速及び風向、降水量、気温、湿度、及び気圧に関するデータを提供するセンサを含む気象監視システムが挙げられる。後述の例では、各センサ毎に別個の監視アプリケーション・プログラムを提供することができる。監視制御、情報家電統合（ｓｍａｒｔ  ａｐｐｌｉａｎｃｅ  ｉｎｔｅｇｒａｔｉｏｎ）、及び警報／アラート発生を組み合わせたホーム・オートメーション・システム内の出力データを生成するいくつかのアプリケーションを提供することもできる。
【００２９】
当業界では、各アプリケーション・プログラムがそれぞれの出力データを含むメッセージをメッセージ・ブローカに送信し、メッセージ・ブローカが（例えばパブリッシュ／サブスクライブ・マッチング・メカニズムを使用して、特定のパブリケーション内の指定されたトピックに関するメッセージを必要とするサブスクライバを特定することによって）当該メッセージをリモート・システムに転送することが知られている。一方、本発明は、従来であればローカル・ログ・ファイルに保存されることになるアプリケーションのログ・データへのアクセスをパブリッシュ／サブスクライブ・メカニズムを利用して提供するものであり、また、大量のログ・ファイルをローカルに記憶するには十分な不揮発性ストレージ容量がないリモート位置のヘッドレス・デバイスを対象にこれを実現するものである。
【００３０】
本発明は、従来であれば後の分析用に大量のログ・データをローカルに保存することになる専用のロガー・アプリケーションによって生成されるデータに適用することができる。本発明は、ロガー・アプリケーションの想定する頻度よりも遥かに高い頻度でデータをキャプチャし、それらを繰り返しパブリッシュすることにより、膨大な量のログ・ファイルを発信元システム上に保存する必要を解消する。
【００３１】
第１の実施形態において、監視アプリケーション２１０は、それ自体が生成したログ・データを監視装置２００のローカル揮発性ＲＡＭ内の「循環型（ｃｉｒｃｕｌａｒ）」データ・ファイル２２０に保存する。固定サイズのファイルをログ・ファイルとして使用し、その後当該ログ・ファイルを「循環」式に使用する、即ち、ファイルがそれ自体の固定サイズの限界に達した時点で当該ファイルを最初から上書きする形で使用するいくつかのアプリケーションが知られている。これには、ファイル・サイズが指定サイズを超えることがなくなり、ファイル・システムが埋め尽くされる恐れもなくなる利点がある。また、アプリケーションが異常終了した場合には、最近書き込まれたデータを利用して点検を行うことができる。既知のシステムでは、このような能力は、不揮発性ディスク・ストレージ内のログ・ファイルを作成することによって達成される。一方、本発明の一実施形態によれば、循環型ログ・ファイル２２０は、ディスク・ストレージではなく揮発性メモリ内で保持され、パブリッシング・プログラム２３０（参照の便宜上、以下「Ｐｕｂｔａｉｌ」と呼ぶ）によって監視される。
【００３２】
監視アプリケーション２１０の循環型ログ・ファイルのファイル名がＰｕｂｔａｉｌ  ２３０に指定された後、Ｐｕｂｔａｉｌ  ２３０は、ＥｎｄＯｆＦｉｌｅ状態に陥ることなく、適切なファイル・アクセス・コマンド（「ｓｅｅｋ」）を使用して末尾のファイル書き込み部分を常時監視することが可能となる。
【００３３】
別法として、ログ・ファイル２２０が刻々と内容が変化するファイル（ｅｖｅｒ−ｅｘｐａｎｄｉｎｇ  ｆｉｌｅ）である場合は、例えば以下のコマンドを使用してファイルの末尾をテーリングすることにより、最近書き込まれたデータを実時間でキャプチャすることができる。
ｔａｉｌ  ‐ｆ  ｌｏｇ．ｆｉｌｅ  ｜  ｐｕｂｔａｉｌ
【００３４】
別法として、以下のコマンドを使用すれば、Ｐｕｂｔａｉｌの標準的な入力ストリームに関するログ・エントリを該当するＰｕｂｔａｉｌに提供（アプリケーションからＰｕｂｔａｉｌに直接パイピング）することもできる。
ａｐｐｌｉｃａｔｉｏｎ  ｜  ｐｕｂｔａｉｌ
【００３５】
次に、Ｐｕｂｔａｉｌは、後述するようにパブリッシュ対象データを処理することができる。
【００３６】
当業界では、いくつかのファイル・テーリング用ユーティリティ（「ｔａｉｌ  −ｆ」を使用するユーティリティ）が知られている。例えば、各ログ・ファイルが記憶されているファイル・システムへの直接アクセスが利用可能である場合は、ＪＬｏｇＴａｉｌｅｒ（Ｊａｖａ（登録商標）のログ・テーリング・ツール）等のツールを使用することができる。この例については、他のインターネット／ファイル・ツールと併せてＷｅｂサイトｗｗｗ．ｊｉｂｂｌｅ．ｏｒｇに記載されている。本発明のパブリッシャ機能と統合されるデータ・キャプチャ・ステップでは、既知のテーリング・ツールと同様の機能を使用することができる。
【００３７】
本発明のＰｕｂｔａｉｌプログラムの一実装形態は、既知のテーリング・プログラムと同様のデータ・キャプチャ機能に加えて、抽出された出力データ・チャンクを繰り返しパブリッシュするパブリッシュ機能を含む。本解決策では、Ｐｕｂｔａｉｌプログラムのデータ・キャプチャ・コンポーネント２３０が軽量なメッセージング・クライアント２４０とのインターフェイスをとることにより、最近キャプチャされたデータ及びトピック名をパブリッシュ／サブスクライブ・メッセージ・ブローカのサブスクリプション・マッチング・コンポーネントに送信する。Ｐｕｂｔａｉｌのデータ・キャプチャ・コンポーネント２３０及びメッセージング・クライアント２４０は、単一のコンピュータ・プログラムの２つの統合コンポーネントを含むことも２つの別個のプログラムを含むこともできる。
【００３８】
本実施形態では、ＩＢＭコーポレーションの開発したＷｅｂＳｐｈｅｒｅ  ＭＱ  Ｔｅｌｅｍｅｔｒｙ  Ｔｒａｎｓｐｏｒｔ（ＭＱＴＴ）プロトコルがメッセージング・クライアント２４０に実装される。ＭＱＴＴプロトコルは、ＴＣＰ／ＩＰを介したパブリッシュ／サブスクライブ・メッセージングを送達保証レベルに関する様々なオプションとともに提供するものであり、テレメトリ統合アプリケーションで発見される専用クライアント・デバイス及びネットワーク・タイプ向けに設計されたものである。ＭＱＴＴでは、メッセージのデータ・コンテンツに関連するヘッダー・オーバーヘッドとして２バイトのデータしか必要とされず、ネットワーク帯域幅が最小限に抑えられる。
【００３９】
Ｐｕｂｔａｉｌのパブリッシャ機能は、当該データが発信元システムから消失する前にパブリッシュされることを保証するために、アプリケーション・プログラムの出力の性質に応じて異なる以下の２つのモードで動作することができる。
１）Ｎ行毎（例えば１行毎）の出力をパブリッシュする。この場合、Ｐｕｂｔａｉｌ  ２３０は、新しい行が区切り文字で区切られた（ｎｅｗ−ｌｉｎｅ−ｄｅｌｉｍｉｔｅｄ）指定行数分のコンソール出力を監視アプリケーション２１０からキャプチャするまで待つ。次に、Ｐｕｂｔａｉｌ  ２３０は、当該指定行数分の情報と、予め割り当てられたトピック識別子とを含むメッセージをパブリッシュする。当該メッセージは、メッセージ・ブローカ・システム３００に送信される。
２）Ｍバイト毎の出力をパブリッシュする。この場合、Ｐｕｂｔａｉｌは、Ｍバイト（例えば１ＫＢ）のデータが得られるまで改行を無視しながら監視アプリケーション・プログラムの出力に由来するデータを消費した後、当該データを含むメッセージをブローカにパブリッシュする。
【００４０】
上記の２つのモードには任意選択のタイムアウトが存在する。タイムアウトが設定されていな場合には、Ｐｕｂｔａｉｌは規定のバイト数又は行数がキャプチャされるまで待つ。タイムアウトが設定されており、かつ、Ｐｕｂｔａｉｌが指定の時間までに規定のバイト数又は行数をキャプチャしていない場合には、Ｐｕｂｔａｉｌは、それ自体が行った最後のメッセージ・パブリケーション以降にキャプチャしたあらゆるデータを含むメッセージをパブリッシュ／サブスクライブ・ブローカ・システムに送信する。これによって、Ｐｕｂｔａｉｌが不適切な遅延をシステムに持ち込むことが回避される。Ｐｕｂｔａｉｌは、ログ内に現れる特定のキーワード又はフレーズに対応するように構成することもできる。
【００４１】
監視アプリケーションから出力されるログ・データをメモリ内のログ・ファイルに書き込み、その後当該ファイルをテーリングする上述の解決策だけでなく、他の実施形態も本発明の範囲に含まれる。ＵＮＩＸ（登録商標）システム（Ｌｉｎｕｘ（商標）システム等）では、あるアプリケーションの出力を別のアプリケーションの入力に直接パイピングすることができ、例えば、第１のアプリケーションの標準的な出力ストリームをパブリッシャ・プログラムの標準的な入力ストリームにコピーすることによってこれを実現することができる。別法として、ログ・データは、ファイル・システムではファイル名を用いて確認されるメモリ・ベースのキューに相当する「名前付きパイプ（ｎａｍｅｄ  ｐｉｐｅ）」に保存することもできる。このキューが第１のアプリケーション・プログラムに関する名前付き出力ファイルである場合には、当該第１のアプリケーションによってキューに書き込まれたデータは、別のアプリケーション・プログラムが入力対象の名前付きパイプをオープンしてキューの読み出しを行うことによって検索することができる。
【００４２】
パブリッシャ・アプリケーション用のメモリ内に入力キューを作成し、当該入力キューを監視アプリケーションがデータを出力する名前付き出力ファイルとして指定することによって、監視アプリケーションから出力されるデータがパブリッシャ・アプリケーションに「パイピング」される。パブリッシャ・アプリケーションは、データ処理システムのネットワークを介して当該データをパブリッシュ／サブスクライブ・ブローカに向けて送信し、パブリッシュ／サブスクライブ・ブローカは、当該データを１つ又は複数のサブスクライバ・アプリケーションに非同期転送する。このようにして、ディスク・ストレージが殆ど存在しないあるいはまったく存在しないデバイス上で監視アプリケーションを使用することができ、その結果、監視アプリケーションの出力データによってファイル・システムが埋め尽くされる潜在的な問題が回避されることになる。
【００４３】
図３は、監視アプリケーション２１０がデータを名前付きパイプ３２０に出力するシステムの概略図である。データは、パブリッシャ・アプリケーションのデータ・キャプチャ・コンポーネント２３０によってキャプチャされ、当該パブリッシャ・アプリケーションのメッセージング・クライアント２４０を介してパブリッシュされる。パブリッシャ・アプリケーションは、出力データが発生した時点で監視アプリケーション２１０からの入力を行単位で受信する。このようにして、パブリッシャ・アプリケーションは、人間のユーザが監視アプリケーションの出力の送信先となるコンソール・モニタを観察することが可能かどうかを確認する場合と同様のデータを受信する。以下の説明はパブリッシャ・アプリケーションに関して上述したどの実装形態にも適用可能であるため、以下では参照の便宜上、パブリッシャ・アプリケーション３３０も「Ｐｕｂｔａｉｌ」と呼ぶこととする。
【００４４】
Ｐｕｂｔａｉｌは、問題の診断に役立つ可能性がある追加的な機能を含む。監視対象のアプリケーションが何らかの理由で（通常は異常終了を発生させる障害によって）終了した場合には、Ｐｕｂｔａｉｌは、メッセージをパブリッシュ／サブスクライブ・ブローカ・システムにパブリッシュすることになる。当該メッセージはアプリケーションの出力の最後のメッセージを含むが、このメッセージが問題の診断に最も重要なデータとなる可能性がある。例えば、Ｐｕｂｔａｉｌが１００行毎にパブリッシュを行うように設定されているときに、アプリケーション側で新しいバッチに入る前の５０行分の処理に失敗した場合には、Ｐｕｂｔａｉｌは当該アプリケーションの終了時にそれらの５０行を送信する。Ｐｕｂｔａｉｌは、それ自体の入力ストリーム上でＥｎｄＯｆＦｉｌｅメッセージを受信し、当該メッセージを用いて終了したアプリケーションを特定し、その後、最後のバッファ・データをパブリッシュする。ＥｎｄＯｆＦｉｌｅマーカは、アプリケーションの終了時にオペレーティング・システムによって入力ストリーム内に配置される。Ｐｕｂｔａｉｌは、この時点で（即ち、ＥｎｄＯｆＦｉｌｅによってアプリケーションの終了イベントが認識されたことに応じて）終了するように構成することができ、その場合には、パブリッシュ／サブスクライブ・ブローカ・システムに送信すべきステータス・メッセージが自動的に生成されることになる。当該ステータス・メッセージは、リモート・システムのオペレータ又は管理者に対するアラートの働きをすることができる。当該ステータス・メッセージは、Ｐｕｂｔａｉｌが単に１又は０（アクティブ又は終了）をステータス・トピックに送信する場合と同じくらい簡単な構成とすることができる。それ故、パブリッシュ／サブスクライブ・ブローカは、アプリケーションが終了する前に当該アプリケーションの最後の出力データだけでなくステータス・アラートも受信する。その後、アラートを受け取ったオペレータ／管理者は、ブローカ側の出力ログに関して保持されているパブリケーション（以下を参照）を確認することによって最終的な出力データを分析することができる。
【００４５】
Ｐｕｂｔａｉｌの動作を制御するために２つの追加フラグを設定することができる。これらの２つの追加フラグは、「保持（ｒｅｔａｉｎ）」フラグと、送達「保証」要件を示す「サービス品質（ｑｕａｌｉｔｙ  ｏｆ  ｓｅｒｖｉｃｅ）」フラグの２つであり、これらのフラグは上述のどの動作モードでも使用することができる。
【００４６】
「保持」フラグは、既知のＷｅｂＳｐｈｅｒｅ  ＭＱ  Ｔｅｌｅｍｅｔｒｙ  Ｔｒａｎｓｐｏｒｔ（ＭＱＴＴ）プロトコルの一機能であり、ＷｅｂＳｐｈｅｒｅ  ＭＱのパブリッシュ／サブスクライブ・メッセージ・ブローカからは、ブローカに送信される特定のトピックに関する最後のメッセージをブローカに記憶すべきことを意味するものとして解釈される。したがって、Ｐｕｂｔａｉｌのキャプチャ・コンポーネントがＭＱＴＴメッセージング・クライアントとインターフェイスをとってパブリケーションをＷｅｂＳｐｈｅｒｅ  ＭＱメッセージ・ブローカに送信するときは、Ｐｕｂｔａｉｌによってパブリッシュされた最後のメッセージがブローカに記憶される。それ以前に当該トピックに関して保持されていたメッセージは、新たに保持されるメッセージによって上書きされる。この機能の１つの利点は、通常はメッセージ・ブローカと接続されないサブスクライバであってもＰｕｂｔａｉｌからブローカを介して専用のログ・トピックにサブスクライブすることができ、当該トピックに対してパブリッシュされた最新のメッセージを直ちに受信することになる点である。監視対象のアプリケーションに障害が発生した場合は、最後に保持されたメッセージが障害発生前の最後の数行分のアプリケーション出力を含んでいることから、当該メッセージが問題の診断に非常に重要なメッセージとなる傾向がある。
【００４７】
「保証（Ａｓｓｕｒｅｄ）」フラグは、Ｐｕｂｔａｉｌによってパブリッシュされ、ＭＱＴＴを使用してメッセージ・ブローカに送信されるメッセージのエンド・ツー・エンド配信に必要となる「サービス品質」オプションを指定する。「保証」フラグは、ＭＱＴＴによって提供される以下のオプションから適切なサービス品質（一般にはＱｏＳ２）が選択されたときに最も有益である。
●ＱｏＳ０：「Ｓｅｎｄ  ａｎｄ  Ｆｏｒｇｅｔ」。大部分のメッセージは無事配信されるが、いくつかのメッセージは欠如する可能性がある。
●ＱｏＳ１：「Ａｔ  Ｌｅａｓｔ  Ｏｎｃｅ  Ｄｅｌｉｖｅｒｙ」。簡易な肯定応答を使用して、ネットワーク障害が発生した場合にも各メッセージが最終的に配信されることを保証するが、肯定応答メッセージが欠如した場合は、クライアント・アプリケーションがメッセージを２回以上送信することになる可能性がある。
●ＱｏＳ２：「Ａｓｓｕｒｅｄ  Ｏｎｃｅ−Ｏｎｌｙ  Ｄｅｌｉｖｅｒｙ」。クライアントとメッセージ・ブローカとの間の会話のメッセージ・フローを増加させて繰り返しのない１回限りのメッセージ配信（ｏｎｃｅ−ａｎｄ−ｏｎｃｅ−ｏｎｌｙ  ｍｅｓｓａｇｅ  ｄｅｌｉｖｅｒｙ）を実現する。
【００４８】
Ｐｕｂｔａｉｌ及びＭＱＴＴを介してＱｏＳ２（「保証」）フラグがセットされたメッセージが送信された場合は、ブローカは、（パブリケーションの時点でそれが接続されていなければ）サブスクライバ（１つ又は複数）が接続されるまで当該メッセージを保持するよう命令される。このようにすれば、サブスクライバが常に接続されるわけではない場合にも、すべてのログ・メッセージが適切なサブスクライバ・プログラムによって確実に受信される。このため、ストレージ制限付き普及デバイスから、必要とされている量のデータをより良い形で記憶することが可能なデータ処理システム（この例では、パブリッシュ／サブスクライブ・ブローカ・システム）へのログの移動が効果的に行われることになる。
【００４９】
メッセージング・クライアント２４０は、ＭＱＴＴ通信プロトコルを介して、特定された新しいデータをネットワーク内のどこかにあるメッセージ・ブローカ・システム１３０に送信する。パブリッシュ／サブスクライブ・メッセージ・ブローカ・システム１３０上で実行されているＭＱＴＴ対応型メッセージング・プログラム２５０は、パブリケーションをパブリッシュ／サブスクライブ・メッセージ・ブローカ・システム１３０に引き渡す。メッセージ・ブローカのパブリッシュ／サブスクライブ・マッチング・エンジン５０は、受信されたパブリケーション内のトピック識別子と、それ自体に記憶されているトピックと特定のサブスクライバとの関連付けを行うサブスクリプション・リストとを比較する。その結果、各パブリケーション毎に１つ又は複数のサブスクライバが特定され、あるいはサブスクライバが特定されないこともある。メッセージ・ブローカ・システム１３０は、ネットワークを介して当該パブリケーションを特定された各サブスクライバに送信する。
【００５０】
図４は、本発明の一実施形態に係る監視装置２００で実行される一連のステップを示している。上述のように、監視装置上で実行されている監視アプリケーション２１０は、それ自体のログ・データ（診断情報を含む）をメモリ内データ・ファイル２２０に保存する（４００）。監視装置２００上ではパブリッシャ・プログラムも実行されており、当該パブリッシャ・プログラムは、コマンド・ライン・フラグの判定を行ってどのような動作モードが必要とされるか見極める。ブローカとの永続的な接続を使用すべき場合には、パブリッシャ・プログラムは、ＭＱＴＴのメッセージング・クライアント２４０のＣＯＮＮＥＣＴメソッドを呼び出して接続を確立する。次に、パブリッシャ・アプリケーションは、それ自体のメイン処理ループを開始する。
【００５１】
監視対象のアプリケーションが実行されている間に、パブリッシャは、それ自体の入力ストリームを介してログ・レコードが受信されるのを待つ（４１０）。受信されるログ・データは、メモリ内ログ・ファイル２２０に直前に保存され、例えばログ・ファイルのテーリングによって抽出されたログ・データに相当する。一代替実装形態では、メモリ内データ・ファイルは、アプリケーション・プログラム２１０とパブリッシャ・プログラム２３０との間の「名前付きパイプ」に相当し、これは、アプリケーション・プログラム２１０の出力キューとパブリッシャ・プログラム２３０の入力キューとの両方の役割を果たす。
【００５２】
パブリッシャ・プログラム２３０は、パブリケーション・サイズ基準を満足するのに必要なバイト数又は行数の出力データが蓄積されたことを判定（４３０）するまで、それ自体にパイピングされたデータ又はメモリ内ログ・ファイル２２０からテーリングされたデータを収集する。この時点で、上述のメッセージ・ブローカとの接続が確立されていない場合には、パブリッシャ・プログラムは、ＣＯＮＮＥＣＴメソッドを呼び出してメッセージ・ブローカとの接続を確立した後、ＭＱＴＴメッセージング・クライアントに実装されたＰＵＢＬＩＳＨメソッドを呼び出してパブリケーション・メッセージを生成する（４４０）。生成されるメッセージは、パブリッシャによる最後のパブリケーション・メッセージ生成及び送信以降にパブリッシャによってキャプチャされる新しいデータ（メッセージ・ペイロード）と、事前定義されたトピックとを含む（更に、コマンド・ライン・フラグによって指定された動作モードでそれが必要となる場合には、保持フラグ又はサービス品質フラグあるいはその両方をパラメータとして含む）。パブリッシャが永続接続モード（ｐｅｒｍａｎｅｎｔｌｙ−ｃｏｎｎｅｃｔｅｄ  ｍｏｄｅ）で動作していない場合には、パブリッシャは、ＤＩＳＣＯＮＮＥＣＴメソッドを呼び出してリモートのメッセージ・ブローカとの接続を解除する。
【００５３】
閾値のデータ量がパブリッシャ・アプリケーション２３０によって蓄積される前にタイムアウトが発生した場合には（４５０）、パブリッシャ２３０は、現時点でそれ自体の入力バッファ内に所在するデータとともにパブリケーションを生成する（４４０）。アプリケーションが終了した場合には、パブリッシャ２３０は、それ自体の入力ストリーム上でＥｎｄＯｆＦｉｌｅメッセージを受信し、それ自体の入力バッファの内容をパブリッシュすべきことを判定する（４２０）。パブリッシャ・プログラムのデータ・キャプチャ・コンポーネントと統合されたローカルのメッセージング・クライアント２４０から、新しいパブリケーションが送信される（４６０）。メッセージング・クライアント２４０にはＭＱＴＴプロトコルが実装されており、メッセージング・クライアント２４０は、メッセージをパブリッシュ／サブスクライブ・メッセージ・ブローカ・システムで実行されているＭＱＴＴ対応型メッセージング・プログラム２５０に送信する。
【００５４】
その後、メッセージ・ブローカ・システムは、パブリケーション内のトピックと、各トピックを個々のサブスクライバにマッピングするサブスクリプション・リストとの比較を実行する。パブリッシュ／サブスクライブ・マッチング・プロセスでは、各パブリケーション毎に１つ又は複数のサブスクライバが特定されることも、サブスクライバが特定されないこともあり、それに従ってパブリケーションが転送されることになる。
【００５５】
オープン・サービス・ゲートウェイ・イニシアチブ（ＯＳＧｉ）のようないくつかのアプリケーション実行環境を用いると、複数のアプリケーションをそれぞれの環境で実行することが可能となり、通常であれば各アプリケーション毎に複製する必要が生じる共通のファシリティを共有することが可能となる。そのようなサービスの一般的な例としては、ロギング及びトレーシングが挙げられる。そのような環境では、ユーザがデフォルトのロギング及びトレーシング機能をカスタム・モジュールで置き換える機能が提供されることが多い。デフォルト機能は、典型的には（前述したような）コンソール出力又はログ・ファイルへのリダイレクトである。本発明の一実施形態では、そのような環境において上述の各Ｐｕｂｔａｉｌ機能をカスタム・ログ又はトレース・ファシリティとして実装することができる。その後、当該環境で実行されるすべてのアプリケーションをリモート監視のためにＰｕｂｔａｉｌと自動的に統合することができる。
【００５６】
名前付きパイプの具体的なの用途は、例えば各Ｗｅｂサイト上の「ヒット」が記録されたＷｅｂログに由来するデータを出力することである。Ｐｕｂｔａｉｌを使用すれば、Ｗｅｂログに送信されるすべてのデータを特定しパブリッシュすることが可能となり、また、ある期間内のヒット数のカウント、Ｗｅｂサイトへのユニーク・ビジタの特定、ヒットではなく「ページ・ビュー」のカウント等、追加的なフィルタリングを追加することが可能となる。例示的な一実装形態では、Ｐｕｂｔａｉｌは、様々な統計情報を様々なトピックと結び付けて複数のトピックに対してパブリッシュを実行することができる（この場合も任意選択で保持フラグ又は保証フラグが利用され得る）。これによって監視時の柔軟性が高まる（ただし、Ｗｅｂログ・アナライザは当業界で周知であるが、「ライブ」方式のＷｅｂログ・アナライザは新規性はないにせよ一般的なものではない）。
【００５７】
本発明の一実施形態において、Ｐｕｂｔａｉｌプログラムは、入力ストリームの構文解析を行って個々のログ・エントリを特定する。この処理はアプリケーション特有であるが、ＨＴＴＰサーバ・ログの場合では各エントリが改行文字で区切られ、典型的には標準的な「共通ログ・ローマット（Ｃｏｍｍｏｎ  Ｌｏｇ  Ｆｏｒｍａｔ）」である。他の区切り文字及び固定長のエントリも知られている。次に、Ｐｕｂｔａｉｌは、パブリッシュを行う前にログ・エントリのカスタム・ロジックを実行することができる。例えば、Ｐｕｂｔａｉｌは、入力データからいくつかのフィールドを抽出し、それらのフィールドがデータを異なる形で表現するように再フォーマット設定することができる。Ｐｕｂｔａｉｌは、「ｒｅｐｏｒｔ−ｂｙ−ｅｘｃｅｐｔｉｏｎ（例外時レポート）」処理を実行して、閾値量を超えるパラメータの変化があったときにだけメッセージをパブリッシュすることもできる。Ｐｕｂｔａｉｌは、例えばＨＴＴＰサーバによってロギングされる毎分のＷｅｂヒット数や、特定のイベントのパブリケーションを必要とする特定のトリガに応じて、アグリゲーションを実装することができる。Ｐｕｂｔａｉｌの処理に関する上記のすべてのカスタム・オプションによって、１つ又は複数のトピックに関する１つ又は複数のメッセージがパブリッシュされることになる（必ずしもログ・エントリ毎に１回のパブリケーションが行われるわけではない）。その後、各メッセージ・ストリームがメッセージ・ブローカに送信される。各メッセージは、アプリケーション・プログラムによって経験されるいくつかのイベント又は一連のイベントに対応しており、各イベントは、アプリケーションによってそれ自体のログ・ファイル又はＰｕｂｔａｉｌに対する名前付きパイプを介してのみ外部化される。以下では、ログ・ファイルのテーリング及びデータのフィルタリング及びパブリッシュについてより詳細に説明する。
【００５８】
Ｐｕｂｔａｉｌプログラムは、ブローカ・アドレス／ポートを用いて構成されるが、通常は「ルート」トピックを用いて構成される（様々なイベントによって複数のトピックを生成することができるが、これらのトピックにはトピック・プレフィックスを有する「コンテキスト」を与える必要がある）。ログ・ファイルのテーリングに由来する入力ログ・データの構文解析が行われ、それによって個々のログ・レコードが作成された後、必要な情報を生成するたにアプリケーション特有の追加的な処理が実施される。その後、このように生成されたデータは適切なトピックに対してパブリッシュされる。様々なイベントが様々なトピックに対してパブリッシュされる可能性があり、また、単一のログ・レコードは、０を生成することも１を生成することもあり、また、１つ又は複数のトピックに対して複数のパブリケーションを行うこともある。
【００５９】
ここでは一例として、「４０４  ｎｏｔ  ｆｏｕｎｄ」エラーのようなエラー・メッセージが示されたＷｅｂヒット等を特定するために、Ｗｅｂサーバのログに関するログ・モニタが実装されている。それらのエラー・メッセージは、トピック・ツリーに基づいてブローカに対するメッセージとしてパブリッシュされる。
【００６０】
生データは、例えば以下のような形をとることができる。
１２７．０．０．１  −  −  ［２４／Ｊｕｎ／２００４：２２：０９：１５  ＋０１００］  “ＧＥＴ  ／ｃａｌｌｅｒＩＤ／ｂｌａｎｋ．ｊｐｇ  ＨＴＴＰ／１．１”  ４０４  ２９０
１２７．０．０．１  −  −  ［２４／Ｊｕｎ／２００４：２２：０９：１５  ＋０１００］  “ＧＥＴ  ／ｃａｌｌｅｒＩＤ／ｕｒｌａｐｐｌｅｔ．ｈｔｍｌ  ＨＴＴＰ／１．１”  ２００  ５５２
１２７．０．０．１  −  −  ［２４／Ｊｕｎ／２００４：２２：０９：１５  ＋０１００］  “ＧＥＴ  ／ｃａｌｌｅｒＩＤ／ｂｌａｎｋ．ｈｔｍｌ  ＨＴＴＰ／１．１”  ４０４  ２９１
【００６１】
Ｐｕｂｔａｉｌに実装されたログ・モニタによってパブリッシュされるデータは、以下のとおりとなる。
ｗｅｂｌｏｇ／｛ｒｅｓｐｏｎｓｅ  ｃｏｄｅ｝／｛ｔｈｅ  ｐａｔｈ  ｏｆ  ｔｈｅ  ｒｅｑｕｅｓｔｅｄ  ＵＲＬ｝
【００６２】
上記の例でパブリッシュされるデータとしては、以下のものが挙げられる。
ｗｅｂｌｏｇ／４０４／ｃａｌｌｅｒＩＤ／ｂｌａｎｋ．ｊｐｇ
ｗｅｂｌｏｇ／２００／ｃａｌｌｅｒＩＤ／ｕｒｌａｐｐｌｅｔ．ｈｔｍｌ
ｗｅｂｌｏｇ／４０４／ｃａｌｌｅｒＩＤ／ｂｌａｎｋ．ｈｔｍｌ
【００６３】
後続のトピック空間が図５に示したような適切な手法で可視化される場合には、当該サイトの問題となる領域を描写したビューが速やかに現れるようにすることができる。また、上記の処理は、パブリケーション内の「参照者（ｒｅｆｅｒｒｅｒ）」を特定すること、即ち、誤リンクの存在するページを特定することによっても機能拡張される。これによって有益な診断ツールを提供することができる。ログ・ファイルから選択されたイベントの表現に関する上記の処理及び生成手法は、通常の出力データに関するログ・ファイル、及びエラー情報のようなアラートをトリガする出力に限定されるログを含めた他の多くの応用例に適用可能である。単一のアプリケーションからの複数の異なる出力を様々なトピックに関してパブリッシュすることができ、その後、様々なトピックに対してパブリッシュ／サブスクライブ・ブローカから各サブスクライバに転送することができる。
【００６４】
保存されているログ・データをキャプチャし、ログ・データが生成されると同時に繰り返しパブリッシュすることができる。即ち、ログ分析ツールが「過去に遡る（ｒｅｔｒｏｓｐｅｃｔｉｖｅｌｙ）」形で使用される場合に付きものの大幅な遅延を伴うことなく、そのようなログ・データを繰り返しパブリッシュすることができる。
【００６５】
それ故、上述の実施形態を含む本発明の様々な実装形態は、アプリケーション・プログラムに関連するログ・ファイルを有することの利益を享受することができる。本発明は、ログ・データが生成される装置の記憶容量制限を克服ことができる。また、本発明は、ローカル・システムがヘッドレスである場合にもアプリケーションに関する診断情報を見ることができる利益を享受することができ、更に、送信物が送信された時点で当事者同士がネットワークに接続されているかどうかに関わらず、デバイスの最後の送信（又はすべての送信）の配信が保証される利益を享受することもできる。
【図面の簡単な説明】
【００６６】
【図１】パブリッシャ・アプリケーション及びサブスクライバ・アプリケーションがリモート・システム上で実行され、各アプリケーションが当業界で知られるような中間のパブリッシュ／サブスクライブ・ブローカを介して相互通信する、分散ネットワークの概略図である。
【図２】本発明の一実施形態に係る１組のコンピュータ・プログラムとストレージ・コンポーネントを示す２つのリモート・データ処理システムの概略図である。
【図３】本発明の第２の実施形態に係るシステムの図である。
【図４】図２のデータ処理システムによって実行される一連の動作を示すフロー図である。
【図５】Ｗｅｂログに由来するデータの処理及びパブリッシュの結果を示す例示的な図である。
【図１】
2009519509.tif 000003
【図２】
2009519509.tif 000004
【図３】
2009519509.tif 000005
【図４】
2009519509.tif 000006
【図５】
2009519509.tif 000007
【国際調査報告】
2009519509.tif 000008
2009519509.tif 000009