JP2011090512A - 監視装置、監視方法及び監視プログラム - Google Patents

Abstract

【課題】被監視装置上に監視プログラムを導入することなく、被監視装置上で稼働している被監視アプリケーションの状況を容易に監視できる監視装置、監視方法及び監視プログラムを提供することを目的とする。
【解決手段】監視装置１００であって、複数種類の調査用パケットを生成して被監視装置上の各通信ポートに送信する送信手段１０２と、各通信ポートから調査用パケット応答を受信する受信手段１０３と、調査用パケット応答の内容を分析して、被監視装置上で稼働するアプリを監視対象のアプリとして解析する解析手段１０５とを有することにより上記課題を解決する。
【選択図】 図８

Description

本発明は、被監視装置上で稼動している被監視アプリケーションの状況を監視する監視装置、監視方法及び監視プログラムに関する。

近年、インターネット等のネットワークは各種ＩＴサービスを提供している。このようなＩＴサービスはネットワークで接続された複数のサーバ上で動作するアプリケーションにより実現されている。

図１はＩＴサービスが動作するＩＴシステムの一例の構成図である。図１のＩＴシステムはＷｅｂ３階層モデルである。図１のＩＴシステムは複数のＷｅｂサーバ２，複数のアプリケーションサーバ３，データベースサーバ４，ロードバランサー５を有する。利用者はクライアント１からＷｅｂサーバ２に接続してＩＴシステムを利用する。図１のＩＴシステムは負荷分散をするためにＷｅｂサーバ２，アプリケーションサーバ３が多重化されている。Ｗｅｂサーバ２，アプリケーションサーバ３への要求はロードバランサー５により振り分けられる。

図２は、ＩＴサービスが動作するＩＴシステム（Ｗｅｂ３階層モデル）における各サーバ構成を表した構成図である。Ｗｅｂサーバ２，アプリケーションサーバ３及びデータベースサーバ４はそれぞれハードウェア１１を有し、ハードウェア１１上でＯＳ１２が動作し、ＯＳ１２上でアプリケーション１３が動作している。例えば図１及び図２に示したＩＴシステムは、複数のサーバ上で動作するアプリケーションがネットワークを経由して通信し、ＩＴサービスの価値を提供している。

図３はＩＴサービスが動作するＩＴシステムの他の例の構成図である。図３のＩＴシステムはクラスタ／二重化システムである。図３のＩＴシステムはクラスタシステム２０を有する。クラスタシステム２０は運用系のプライマリノード２１，待機系のセカンダリノード２２，共有ディスク２３を有する。

利用者はクライアント１からプライマリノード２１上の業務アプリケーション２４に接続してＩＴシステムを利用する。また、ＩＴサービスを利用する通信プログラムはプライマリノード２１上の業務アプリケーション２４に接続してＩＴシステムを利用する。図３のＩＴシステムはプライマリノード２１に故障が発生した場合、セカンダリノード２２にフェールオーバすることによりＩＴサービスを継続して提供できる。プライマリノード２１及びセカンダリノード２２はそれぞれハードウェアを有し、ハードウェア上でＯＳが動作し、ＯＳ上で業務アプリケーション２４又は２５が動作している。例えば図３に示したＩＴシステムは、複数のサーバ上で動作するアプリケーションがネットワークを経由して通信し、ＩＴサービスの価値を提供している。

図４はＩＴサービスが動作するＩＴシステムの他の例の構成図である。図４のＩＴシステムは仮想化システムである。図４のＩＴシステムは、ホストサーバ３０を有する。ホストサーバ３０は仮想化技術を用いて複数の仮想サーバ３３を稼働させる形態である。

利用者はクライアント１から仮想サーバ３３上の業務アプリケーション３５に接続してＩＴシステムを利用する。また、ＩＴサービスを利用する通信プログラムは仮想サーバ３３上の業務アプリケーション３５に接続してＩＴシステムを利用する。

ホストサーバ３０はハードウェアを有し、ハードウェア上でＯＳ３１が動作し、ＯＳ３１上で仮想化プログラム３２が動作している。ホストサーバ３０上では仮想化プログラム３２によって複数の仮想サーバ３３が稼働し、複数の仮想サーバ３３上でＯＳ３４が稼働し、ＯＳ３４上で業務アプリケーション３５が動作している。例えば図４に示したＩＴシステムは、複数の仮想サーバ上で動作するアプリケーションがネットワークを経由して通信し、ＩＴサービスの価値を提供している。

なお、ＩＴサービスが動作するＩＴシステムには、図１〜図４に示したＩＴシステムを、それぞれ組み合わせた構成も含まれる。各ＩＴシステムにて提供されるＩＴサービスとは、ＩＴを利用する利用者のビジネスを支援する機能の集合体であり、利用者の要求に対して価値を提供できることを期待されている。

よって、ＩＴサービスが期待通りに価値を提供していること、すなわち、想定した価値を提供するように作られたものが想定通りに動作していることを監視することは、ビジネスとしてＩＴサービスを提供している者または利用している者にとって重要である。

ＩＴサービスを提供する業務アプリケーションは、個々のプログラム（プロセス）が組み合わさることによって成る。ここでは監視対象とする業務アプリケーションを以下の３種類とする。

図５は業務アプリケーションの一例の構成図である。図５（Ａ）は単独で動作する、業務アプリケーション４１を表している。図５（Ａ）に示す業務アプリケーション４１としてはＴｅｌｎｅｔサーバ，ＦＴＰサーバ，お客様毎の会計や購買などの業務システムを構成するアプリケーション，ユーザ作成アプリや市販パッケージ等がある。

図５（Ｂ）は基盤となる基盤アプリケーション４３上で動作する、業務アプリケーション４２を表している。図５（Ｂ）に示す業務アプリケーション４２としてはアプリケーションサーバ上で動作するものや、Ｗｅｂサーバ上で動作するＷｉｋｉ等がある。なお、基盤アプリケーション４３上で動作するものはインスタンスと呼ばれる。

その他、業務アプリケーションとしては、アプリケーションサーバ，Ｗｅｂサーバ，データベースサーバなど、実際にＩＴサービスを提供するものの基盤となる基盤アプリケーション４３も含まれる。

従来、ＩＴサービスの業務アプリケーションを監視する方法は以下の２つがあった。図６はＩＴサービスの業務アプリケーションを監視する方法の一例の説明図である。図６の方法は、業務アプリケーション５５が稼働する監視対象のサーバ（被監視サーバ）５２に監視のためのソフトウェア（監視ソフトウェア）５４を導入すると共に、被監視サーバ５２の業務アプリケーション５５を監視するサーバ（監視サーバ）５１に監視のための監視ソフトウェア５３を導入するものである。

なお、監視サーバ５１の監視ソフトウェア５３はマネージャである。被監視サーバ５２の監視ソフトウェア５４はエージェントである。監視ソフトウェア５３，５４は、業務アプリケーション５５を構成するプロセスやインスタンスを検出／監視する。

また、図７はＩＴサービスの業務アプリケーションを監視する方法の他の例の説明図である。図７の方法は、被監視サーバ５２に監視ソフトウェア５４を導入せず、監視サーバ５１側からリモートで業務アプリケーション５５を構成するプロセスやインスタンスを検出／監視するものである。監視サーバ５１側からリモートで業務アプリケーション５５を構成するプロセスやインスタンスを検出／監視する為、監視サーバ５１及び被監視サーバ５２ではｔｅｌｎｅｔ５６，５７が利用される。

また、従来複数のサーバ上で動作するアプリケーションはレスポンス遅延などの障害の発生が監視されていた（例えば特許文献１参照）。

特開２００６−６５６１９号公報

従来、上記したＩＴサービスの業務アプリケーションを監視する方法には、以下のような課題が存在していた。

図６の被監視サーバ５２に監視ソフトウェア５４を導入し、監視ソフトウェア５４を動作させることにより業務アプリケーション５５を構成するプロセスやインスタンスを検出／監視する方法は、全ての被監視サーバ５２に監視ソフトウェア５４の導入が必要という問題があった。

なお、図３のクラスタシステム２０では、運用系のプライマリノード２１及び待機系のセカンダリノード２２のそれぞれに、監視ソフトウェア５４の導入が必要である。図４の仮想化システムでは、仮想サーバ３３のそれぞれに、監視ソフトウェア５４の導入が必要である。

また、図６の被監視サーバ５２に監視ソフトウェア５４を導入し、監視ソフトウェア５４を動作させることにより業務アプリケーション５５を構成するプロセスやインスタンスを検出／監視する方法は、監視ソフトウェア５４の導入および保守に対し、運用と無関係なＩＴシステム停止を伴うケースが発生するという問題があった。

また、図７の被監視サーバ５２に監視ソフトウェア５４を導入せず、監視サーバ５１側からリモートで業務アプリケーション５５を構成するプロセスやインスタンスを検出／監視する方法は、リモート操作を行うために必要な事前設定が必要である。リモート操作を行うために必要な事前設定は、ｔｅｌｎｅｔ，ｓｓｈ等のリモートコマンドで使用するポートの通過設定がある。また、リモート操作を行うために必要な事前設定は、リモート操作のための（エージェント一律の）アクセスアカウント設定がある。そのため、セキュリティリスクが存在するという問題があった。

また上記したＩＴサービスの業務アプリケーションを監視する方法は、予め定義されたプロセスの存在を定期的に確認することによりＩＴサービスの業務アプリケーションを監視するため、システム管理者がＩＴサービスの業務アプリケーションを構成するプロセスを事前に定義する必要があった。

ＩＴサービスの構成をシステム管理者が細部まで把握している場合、ＩＴサービスの業務アプリケーションを構成するプロセスは人手で定義できる。また、業務アプリケーションが状況に応じてサーバに固定的に割り当てられる場合も、その割り当てをシステム管理者は把握しているはずなので、業務アプリケーションを構成するプロセスを人手で定義できる。

しかし、図１，図３及び図４のＩＴシステムのケースではＩＴサービスの構成（業務アプリケーションとプロセスとの関連性、業務アプリケーションとサーバとの関連性）が動的に変更となる。そのため、ＩＴシステムが大規模化した環境や、複数のＩＴシステムが組み合わされた環境において、人手によるプロセスの定義は非常に困難という問題があった。

従来、ＩＴサービスの業務アプリケーションを監視する方法は、容易にＩＴサービスの業務アプリケーションを監視できないという問題があった。

本発明の一実施形態は、被監視装置上に監視プログラムを導入することなく、被監視装置上で稼働している被監視アプリケーションの状況を容易に監視できる監視装置、監視方法及び監視プログラムを提供することを目的とする。

上記課題を解決するため、本発明の一実施形態は、被監視装置上で稼働するアプリケーションを監視する監視装置であって、複数種類の調査用パケットを生成し、前記複数種類の調査用パケットを被監視装置上の各通信ポートに順次送信する調査用パケット生成／送信手段と、前記被監視装置上の通信ポートから返信された前記複数種類の調査用パケットに対する調査用パケット応答を受信する調査用パケット応答受信手段と、前記複数種類の調査用パケットに対する調査用パケット応答の内容を分析し、前記被監視装置上で稼働するアプリケーションを監視対象のアプリケーションとして解析するアプリケーション解析手段とを有する。

なお、本発明の一実施形態の構成要素、表現又は構成要素の任意の組合せを、方法、装置、システム、コンピュータプログラム、記録媒体、データ構造などに適用したものも本発明の態様として有効である。

本発明の一実施形態によれば、被監視装置上に監視プログラムを導入することなく、被監視装置上で稼働している被監視アプリケーションの状況を容易に監視できる。

ＩＴサービスが動作するＩＴシステムの一例の構成図である。 ＩＴサービスが動作するＩＴシステム（Ｗｅｂ３階層モデル）における各サーバ構成を表した構成図である。 ＩＴサービスが動作するＩＴシステムの他の例の構成図である。 ＩＴサービスが動作するＩＴシステムの他の例の構成図である。 業務アプリケーションの一例の構成図である。 ＩＴサービスの業務アプリケーションを監視する方法の一例の説明図である。 ＩＴサービスの業務アプリケーションを監視する方法の他の例の説明図である。 本実施例の監視サーバを含むＩＴシステムの一例の構成図である。 監視サーバを実現するコンピュータシステムの一例のハードウェア構成図である。 被監視アプリケーションテーブルの生成フェーズの処理手順を表した一例のフローチャートである。 アプリケーション稼働監視フェーズの処理手順を表した一例のフローチャートである。 被監視アプリケーションテーブルの生成フェーズの処理手順の詳細を表した一例のフローチャート（１／２）である。 被監視アプリケーションテーブルの生成フェーズの処理手順の詳細を表した一例のフローチャート（２／２）である。 下位レイヤのネットワークプロトコルの調査用パケットを表したデータ構造図である。 調査用パケット応答を表した構成図である。 第１の調査用パケットを送信したときの被監視アプリケーションテーブルの生成手順を表した一例の構成図である。 調査用パケットのデータ部の内容をネットワークプロトコル毎に示す表の一例である。 調査用パケット応答の内容を、調査用パケットのネットワークプロトコル及び対象アプリケーション（ポート番号を利用するアプリケーション）の組み合わせ毎に示した表の一例である。 第２，第３の調査用パケットを送信したときの被監視アプリケーションテーブルの生成手順を表した一例の構成図である。 被監視アプリケーションテーブルの一例である。 アプリケーション稼働監視フェーズの処理手順の詳細を表した一例のフローチャートである。 監視ソフトウェアが管理する管理テーブルの一例の構成図を示している。 被監視サーバＡの稼働アプリケーションテーブル及びスナップショットが変化していく様子を表した一例の遷移図である。 被監視サーバのグループ化を表した一例のイメージ図である。 アプリケーションの稼働異常通知の為の一例の画面イメージである。

次に、本発明を実施するための形態を、以下の実施例に基づき図面を参照しつつ説明していく。なお、本実施例では監視装置の一例として監視サーバを例に説明する。

（システム構成）
図８は本実施例の監視サーバを含むＩＴシステムの一例の構成図である。図８のＩＴシステムは監視サーバ１００と、被監視装置としてのサーバ（運用サーバ）Ａ〜Ｅとが、インターネットやＬＡＮなどのネットワーク経由でデータ通信可能に接続されている。

監視サーバ１００は監視ソフトウェア（マネージャ）１０１を有する。なお、監視ソフトウェア１０１は監視プログラムの一例である。また、監視ソフトウェア１０１は、調査用パケット生成／送信部１０２，調査用パケット応答受信部１０３，調査用パケット応答データベース１０４，アプリケーション解析（稼働アプリケーション検出）部１０５，アプリケーション構成（接続関係）分析部１０６を有する。なお、監視ソフトウェア１０１のアプリケーション構成分析部１０６は既存機能である。

調査用パケット生成／送信部１０２は後述の調査用パケットを生成し、調査用パケットをサーバＡ〜Ｅに送信する。調査用パケット応答受信部１０３はサーバＡ〜Ｅから調査用パケットに対する応答（調査用パケット応答）を受信する。調査用パケット応答受信部１０３は受信した調査用パケット応答を調査用パケット応答データベース１０４の被監視アプリケーションテーブルに記録する。なお、調査用パケット応答データベース１０４は後述のスナップショットも記録している。

アプリケーション解析部１０５は調査用パケット応答データベース１０４を利用することで、サーバＡ〜Ｅ上で稼働しているアプリケーションを後述のように解析する。アプリケーション構成分析部１０６はアプリケーション構成を分析するサーバが利用者により指定されると、調査用パケット応答データベース１０４を利用し、指定されたサーバ上で稼働しているアプリケーションの構成を分析して監視画面１１０に表示する。

（監視サーバ１００のハードウェア構成）
監視サーバ１００は本実施例の監視プログラムを図９のようなコンピュータシステムで実行することで実現される。図９は監視サーバを実現するコンピュータシステムの一例のハードウェア構成図である。

図９の監視サーバ１００は、それぞれバスＢで相互に接続された入力装置６１，出力装置６２，ドライブ装置６３，補助記憶装置６４，主記憶装置６５，演算処理装置６６，インターフェース装置６７を有する。

入力装置６１はキーボードやマウスなどである。入力装置６１は各種信号を入力するために用いられる。出力装置６２はディスプレイ装置などである。出力装置６２は各種ウインドウやデータ等を表示するために用いられる。インターフェース装置６７はモデム，ＬＡＮカードなどである。インターフェース装置６７はネットワークに接続する為に用いられる。

本実施例に掛かる監視プログラムは監視サーバ１００を制御する各種プログラムの少なくとも一部である。監視プログラムは例えば記録媒体６８の配布やネットワークからのダウンロードなどによって提供される。

監視プログラムを記録した記録媒体６８はＣＤ−ＲＯＭ、フレキシブルディスク、光磁気ディスク等の様に情報を光学的，電気的或いは磁気的に記録する記録媒体、ＲＯＭ、フラッシュメモリ等の様に情報を電気的に記録する半導体メモリ等、様々なタイプの記録媒体を用いることができる。

監視プログラムを記録した記録媒体６８がドライブ装置６３にセットされると、監視プログラムは記録媒体６８からドライブ装置６３を介して補助記憶装置６４にインストールされる。ネットワークからダウンロードされた監視プログラムはインターフェース装置６７を介して補助記憶装置６４にインストールされる。

また、補助記憶装置６４はインストールされた監視プログラムを格納すると共に、必要なファイル，データ等を格納する。主記憶装置６５は、補助記憶装置６４から監視プログラムを読み出して格納する。そして、演算処理装置６６は主記憶装置６５に格納された監視プログラムに従って、図８に示した監視ソフトウェア１０１の各種処理ブロックを実現している。

監視ソフトウェア１０１による業務アプリケーションの監視は被監視アプリケーションテーブルの生成フェーズ及びアプリケーション稼働監視フェーズの２フェーズを含んでいる。以下では、被監視アプリケーションテーブルの生成フェーズ，アプリケーション稼働監視フェーズについて説明していく。

（被監視アプリケーションテーブルの生成フェーズの概要）
図１０は被監視アプリケーションテーブルの生成フェーズの処理手順を表した一例のフローチャートである。ステップＳ１において、調査用パケット生成／送信部１０２は後述の調査用パケットを生成し、調査用パケットをサーバＡ〜Ｅに送信する。調査用パケット生成／送信部１０２は、調査用パケットを送信するサーバＡ〜Ｅの情報を後述のサーバリストテーブルから得る。調査用パケットは後述のようにサーバＡ〜Ｅの各通信ポートへ網羅的に送信される。

ステップＳ２に進み、調査用パケット応答受信部１０３は、被監視サーバであるサーバＡ〜Ｅの各通信ポートからの調査用パケット応答を受信する。調査用パケット応答には正常応答，異常応答（メッセージなし，応答なし，エラー）の内容がある。調査用パケット応答受信部１０３は、受信した調査用パケット応答から被監視アプリケーションテーブルを自動生成し、調査用パケット応答データベース１０４に記録する。

ステップＳ３に進み、アプリケーション解析部１０５はサーバＡ〜Ｅ上で稼働しているアプリケーションを調査用パケット応答から特定できるかを判定する。調査用パケット応答からアプリケーションを特定する内容については後述する。もし、調査用パケット応答からアプリケーションを特定できなかったサーバＡ〜Ｅの各通信ポートがあれば、アプリケーション解析部１０５は調査用パケット生成／送信部１０２に対し、アプリケーションを特定できなかったサーバＡ〜Ｅの各通信ポートへ次の調査用パケットを送信するように要求する。

ステップＳ１に戻り、調査用パケット生成／送信部１０２は次の調査用パケットを生成して、アプリケーションを特定できなかったサーバＡ〜Ｅの各通信ポートへ、次の調査用パケットを送信する。ステップＳ１〜Ｓ３の処理は受信した調査用パケット応答からアプリケーションを特定できるまで繰り返される。

受信した全ての調査用パケット応答からアプリケーションを特定できると、ステップＳ４に進み、アプリケーション解析部１０５は調査用パケット応答が同一のときに、同一もしくは同種類のアプリケーションが稼働していると判断し、調査用パケット応答の返信元サーバをアプリケーションと関連付けてグループとして管理する。

（アプリケーション稼働監視フェーズの概要）
図１１はアプリケーション稼働監視フェーズの処理手順を表した一例のフローチャートである。アプリケーション稼働監視フェーズは所定時間毎に行われる。ステップＳ１１において、アプリケーション解析部１０５は被監視アプリケーションテーブルで管理されたサーバＡ〜Ｅ上で稼働しているアプリケーションが特定可能となる調査用パケットを、該当するサーバＡ〜Ｅの通信ポートへ送信するように調査用パケット生成／送信部１０２へ要求する。調査用パケット生成／送信部１０２はアプリケーション解析部１０５からの要求に基づき調査用パケットを送信する。

ステップＳ１２に進み、調査用パケット応答受信部１０３はサーバＡ〜Ｅの通信ポートからの調査用パケット応答を受信する。調査用パケット応答受信部１０３は受信した調査用パケット応答を調査用パケット応答データベース１０４に記録する。アプリケーション解析部１０５は調査用パケット応答データベース１０４に記録された調査用パケット応答に応じてサーバＡ〜Ｅ上のアプリケーションの存在有無を確認する。調査用パケット応答からアプリケーションの存在有無を確認する内容については後述する。アプリケーション解析部１０５は、その時点でのサーバＡ〜Ｅ上のアプリケーションの存在有無を後述の稼働アプリケーションテーブルとして記録（スナップショット）しておく。

ステップＳ１３に進み、アプリケーション解析部１０５は調査用パケット応答受信部１０３が受信した調査用パケット応答を、前回採取したスナップショットと比較して、調査用パケット応答に変化があるかを判定する。調査用パケット応答に変化があれば、アプリケーション解析部１０５はステップＳ１５に進む。

調査用パケット応答に変化がなければ、アプリケーション解析部１０５は、ステップＳ１４に進み、アプリケーション毎に対応付けられたサーバグループ内で差異があるかを判定する。アプリケーション毎に対応付けられたサーバグループ内で差異があれば、アプリケーション解析部１０５はステップＳ１５に進む。アプリケーション毎に対応付けられたサーバグループ内で差異がなければ、アプリケーション解析部１０５はステップＳ１１に戻る。

ステップＳ１５では、アプリケーション解析部１０５がアプリケーションの稼働異常を検出する。アプリケーション解析部１０５は監視画面１１０へのメッセージ／画面出力などによりアプリケーションの稼働異常をＩＴサービスの管理者へ通知する。ＩＴサービスの管理者は、メッセージ／画面出力結果から異常対処を判断し、異常内容に応じた処置を行うことができる。

（被監視アプリケーションテーブルの生成フェーズの詳細）
図１２及び図１３は被監視アプリケーションテーブルの生成フェーズの処理手順の詳細を表した一例のフローチャートである。図１２及び図１３のフローチャートの処理は全ての被監視サーバについて行われる。

ステップＳ２１において、調査用パケット生成／送信部１０２は図１４に示すような下位（トランスポート層）レイヤのネットワークプロトコルの調査用パケット（第１の調査用パケット）を生成する。図１４は下位レイヤのネットワークプロトコルの調査用パケットを表したデータ構造図である。なお、図１４の調査用パケットはＴＣＰ／ＩＰの例を表している。

調査用パケット生成／送信部１０２は生成した調査用パケットを被監視サーバ上の通信ポートに対して網羅的に送信する。ステップＳ２２に進み、調査用パケット応答受信部１０３は被監視サーバ上の通信ポートを利用するアプリケーションから、図１５に示すような調査用パケット応答を受信する。図１５の調査用パケット応答はサーバ（ＩＰアドレス：１０．１０．１０．１０）のポート２２（ＳＳＨ）に対して、図１４の調査用パケットを送信した場合の例である。

図１５の調査用パケット応答は、レスポンスタイム，メッセージ長，応答メッセージを含む正常応答である。なお、調査用パケット応答には、正常応答，異常応答（メッセージなし，応答なし，エラー）の内容がある。

調査用パケット応答受信部１０３は、正常応答の調査用パケット応答を受信した被監視サーバ上の通信ポートについて接続できたと判定し、接続できた通信ポートの通信ポート番号を被監視アプリケーションテーブルに追加する。調査用パケット応答受信部１０３は受信したＴＣＰプロトコルの調査用パケット応答の内容として通信ポート毎に、被監視アプリケーションテーブルへ「ＣＯＮＮＥＣＴ」もしくは「メッセージなし」を記録する。

図１６は第１の調査用パケットを送信したときの被監視アプリケーションテーブルの生成手順を表した一例の構成図である。図１６では調査用パケット生成／送信部１０２が被監視サーバＡ，被監視サーバＢ，被監視サーバＣの各通信ポートに第１の調査用パケットを送信し、被監視サーバＡの通信ポート「１００」，被監視サーバＢの通信ポート「２００」，被監視サーバＣの通信ポート「３００」から、調査用パケット応答受信部１０３が調査用パケット応答を受信する例を表している。

図１２のステップＳ２３以降の処理は被監視アプリケーションテーブルに追加した全てのポート番号について行われる。ステップＳ２３に進み、アプリケーション解析部１０５は調査用パケット生成／送信部１０２に対し、ＴＥＬＮＥＴの調査用パケット（第２の調査用パケット）及びＨＴＴＰの調査用パケット（第３の調査用パケット）を送信するように要求する。

なお、調査用パケット生成／送信部１０２は後述する被監視アプリケーションテーブルの「調査用パケット応答」の欄の左から右の順（ＴＣＰ→ＴＥＬＮＥＴ→ＨＴＴＰ→ＦＴＰ→ＭｙＳＱＬ）に第１〜第５の調査用パケットのネットワークプロトコルを決める。

調査用パケット生成／送信部１０２は、図１７に示す表から読み出した第２の調査用パケットのネットワークプロトコル（ＴＥＬＮＥＴ）に応じた内容をデータ部に有する第２の調査用パケットを生成する。また、調査用パケット生成／送信部１０２は図１７に示す表から読み出した第３の調査用パケットのネットワークプロトコル（ＨＴＴＰ）に応じた内容をデータ部に有する第３の調査用パケットを生成する。

図１７は調査用パケットのデータ部の内容をネットワークプロトコル毎に示す表の一例である。調査用パケット生成／送信部１０２は生成した第２及び第３の調査用パケットを被監視アプリケーションテーブルのポート番号に送信する。ステップＳ２４に進み、調査用パケット応答受信部１０３は被監視アプリケーションテーブルのポート番号を利用するアプリケーションから、図１８に示すような調査用パケット応答を受信する。

図１８は、調査用パケット応答の内容を、調査用パケットのネットワークプロトコル及び対象アプリケーション（ポート番号を利用するアプリケーション）の組み合わせ毎に示した表の一例である。なお、調査用パケットのネットワークプロトコルがＨＴＴＰであるとき、ＨＴＴＰのヘッダーは調査用パケット応答に日付やサイズなどの可変データを含んでいる。

そこで、図１８の表はアプリケーションの特徴がでる行を限定して格納している。例えば調査用パケットのネットワークプロトコルがＨＴＴＰであるとき、図１８の表は１行目と、「Ｓｅｒｖｅｒ」，「Ｘ−Ｐｏｗｅｒｅｄ−Ｂｙ」の行とを格納する。また、図１８の表は斜線部分がエラーの調査用パケット応答を表している。

調査用パケット応答受信部１０３は被監視サーバ上の通信ポートと対応付けて、受信した調査用パケット応答を被監視アプリケーションテーブルに格納する。

図１９は第２，第３の調査用パケットを送信したときの被監視アプリケーションテーブルの生成手順を表した一例の構成図である。図１９では調査用パケット生成／送信部１０２が被監視サーバＡの通信ポート「１００」，被監視サーバＢの通信ポート「２００」，被監視サーバＣの通信ポート「３００」に第２及び第３の調査用パケットを送信し、被監視サーバＡの通信ポート「１００」，被監視サーバＢの通信ポート「２００」，被監視サーバＣの通信ポート「３００」から、調査用パケット応答受信部１０３が調査用パケット応答を受信する例を表している。ステップＳ２５に進み、アプリケーション解析部１０５は被監視アプリケーションテーブルを参照し、第２及び第３の調査用パケットの片方だけに調査用パケット応答があるかを判定する。

ステップＳ２５の処理は、的外れな調査用パケットに対して応答をまったく返さないアプリケーションがある為に行うものである。例えば第２及び第３の調査用パケットの片方だけに調査用パケット応答があるとき、アプリケーション解析部１０５は応答があった第２又は第３の調査用パケットの種別のアプリケーションであると判定できる。

アプリケーション解析部１０５は、第２及び第３の調査用パケットの片方だけに調査用パケット応答があるとき、ステップＳ２６に進み、応答があった第２又は第３の調査用パケットの種別のアプリケーションであると判定する。

ステップＳ２７に進み、アプリケーション解析部１０５はステップＳ２６で特定したアプリケーションが他のポート番号のアプリケーションと同じか否かを判定する。ステップＳ２６で特定したアプリケーションが他のポート番号のアプリケーションと同じであると判定すると、アプリケーション解析部１０５はステップＳ２８に進み、同じであると判定したアプリケーションのレコードを１つのアプリケーショングループにまとめ、ステップＳ２９に進む。なお、ステップＳ２６で特定したアプリケーションが他のポート番号のアプリケーションと同じでないと判定すると、アプリケーション解析部１０５はステップＳ２７からステップＳ２９に進む。

ステップＳ２９において、アプリケーション解析部１０５は、被監視アプリケーションテーブルのレコードにサーバ名を追加することにより、ステップＳ２６で特定したアプリケーションと、被監視サーバとを関連付けたあと、ステップＳ２３に戻る。

なお、ステップＳ２５において、アプリケーション解析部１０５は第２及び第３の調査用パケットの片方だけに調査用パケット応答があるとき以外、ステップＳ３０〜Ｓ３３の処理を行う。

ステップＳ３０に進み、アプリケーション解析部１０５は調査用パケット生成／送信部１０２に対し、ＦＴＰの調査用パケット（第４の調査用パケット）を送信するように要求する。

調査用パケット生成／送信部１０２は、図１７に示す表から読み出した第４の調査用パケットのネットワークプロトコル（ＦＴＰ）に応じた内容をデータ部に有する第４の調査用パケットを生成する。ステップＳ３１に進み、調査用パケット応答受信部１０３は被監視アプリケーションテーブルのポート番号を利用するアプリケーションから、図１８に示すような調査用パケット応答を受信する。

調査用パケット応答受信部１０３は被監視サーバ上の通信ポートと対応付けて、受信した調査用パケット応答を被監視アプリケーションテーブルに格納する。ステップＳ３２に進み、アプリケーション解析部１０５は被監視アプリケーションテーブルを参照し、第２の調査用パケット以降の調査用パケット応答のうち、一つだけ異なる調査用パケット応答があるかを判定する。

ステップＳ３２の処理はエラーの調査用パケット応答が同じであるため、一つだけ異なる調査用パケット応答があるとき、一つだけ異なる応答があった調査用パケットの種別のアプリケーションであると判定する。アプリケーション解析部１０５は、一つだけ異なる調査用パケット応答があるときに、ステップＳ３３に進み、一つだけ異なる応答があった調査用パケットの種別のアプリケーションであると判定し、ステップＳ２７に進む。アプリケーション解析部１０５は、一つだけ異なる調査用パケット応答がないとき、ステップＳ２３に戻る。

上記した被監視アプリケーションテーブルの生成フェーズにより、監視ソフトウェア１０１は図２０に示すような被監視アプリケーションテーブルを生成し、調査用パケット応答データベース１０４に記録する。図２０は、被監視アプリケーションテーブルの一例である。被監視アプリケーションテーブルは通信ポート毎にアプリケーション識別ＩＤが割り付けられる。

ただし、被監視アプリケーションテーブルは通信ポートが同一でも調査用パケット応答の送信元の被監視サーバが異なる場合、別のアプリケーションＩＤを割り付ける。例えば図２０の例では、同一の通信ポート「４００」に別々のアプリケーションＩＤ「Ａ００２」，「Ａ００３」が割り付けられている。また、被監視アプリケーションテーブルは調査用パケット応答の内容によってアプリケーションをグループ化する為のアプリケーショングループＩＤが割り付けられている。

例えば図２０の例は、通信ポートが異なるが同一のアプリケーション「ａｐｐｌｉｃａｔｉｏｎＡ」であるアプリケーションＩＤ「Ａ００１」，「Ａ００４」にアプリケーショングループＩＤ「Ｇ００１」を割り付けてグループ化している。

なお、図２０の被監視アプリケーションテーブルでは新たにアプリケーションが追加となるケースも想定して、単一のアプリケーションＩＤにもアプリケーショングループＩＤを割り付けている。図１６の被監視アプリケーションテーブルでは、網掛けの部分が各アプリケーションを特定できる調査用パケットとなる。例えばアプリケーションＩＤ「Ａ００１」のアプリケーションは調査用パケット（ＨＴＴＰ）で特定できる。

監視ソフトウェア１０１は、調査用パケットのあて先（送信先）の通信ポートと、調査用パケット応答の内容及びレスポンスタイムを自動的に表形式で管理する。また、監視ソフトウェア１０１は通信ポート毎に一意のアプリケーションＩＤを割り付け、更に調査用パケット応答が異なる場合に別のアプリケーションＩＤを割り付けて管理を行う。

（アプリケーション稼働監視フェーズの詳細）
図２１はアプリケーション稼働監視フェーズの処理手順の詳細を表した一例のフローチャートである。アプリケーション稼働監視フェーズは所定時間毎に行われる。ステップＳ４１において、アプリケーション解析部１０５は被監視アプリケーションテーブルで管理されたサーバＡ〜Ｅ上で稼働しているアプリケーションが特定可能となる調査用パケットを運用中のすべての被監視サーバの通信ポートへ送信するように調査用パケット生成／送信部１０２へ要求する。調査用パケット生成／送信部１０２はアプリケーション解析部１０５からの要求に基づき調査用パケットを送信する。なお、調査用パケット生成／送信部１０２は運用中の被監視サーバを被監視サーバがリスト化されたサーバリストテーブルから検出できる。サーバリストテーブルは例えば後述の図２２の管理テーブル構成に含まれている。

ステップＳ４２に進み、調査用パケット応答受信部１０３は被監視サーバの通信ポートからの調査用パケット応答を受信する。調査用パケット応答受信部１０３は受信した調査用パケット応答を調査用パケット応答データベース１０４に記録する。アプリケーション解析部１０５は調査用パケット応答データベース１０４に記録された調査用パケット応答に応じて被監視サーバ上のアプリケーションの存在有無を確認し、図２２の管理テーブル構成に含まれる被監視サーバ毎の稼働アプリケーションテーブルを生成する。図２２は監視ソフトウェアが管理する管理テーブルの一例の構成図を示している。

その時点での被監視サーバ毎の稼働アプリケーションテーブルをアプリケーション解析部１０５は図２３に示すように被監視サーバ毎に採取（記録）しておく。図２３は被監視サーバＡの稼働アプリケーションテーブル及びスナップショットが変化していく様子を表した一例の遷移図である。図２３の例において、アプリケーション解析部１０５は時間ｔ０における稼働アプリケーションテーブルのスナップショットを記録している。

ステップＳ４３に進み、アプリケーション解析部１０５は調査用パケット応答受信部１０３が受信した調査用パケット応答を、ステップＳ４２で前回採取したスナップショットと比較し、調査用パケット応答に変化があるかを判定する。

例えば図２３の例では時間ｔ１において時間ｔ１の調査用パケット応答と時間ｔ０における稼働アプリケーションテーブルのスナップショットとを比較する。また、時間ｔ２において時間ｔ２の調査用パケット応答と時間ｔ１における稼働アプリケーションテーブルのスナップショットとを比較する。

時間ｔ１における比較の結果、アプリケーション解析部１０５はアプリケーションＩＤが「Ａ００２」のアプリケーションの停止を検出すると共に、新たにアプリケーションＩＤが「Ａ００５」のアプリケーションの稼働を検出する。

また、時間ｔ２における比較の結果、アプリケーション解析部１０５はアプリケーションＩＤが「Ａ００２」のアプリケーションの再稼働を検出すると共に、アプリケーションＩＤが「Ａ００４」のアプリケーションの性能劣化を検出する。なお、アプリケーションの性能劣化は調査用パケットに対する調査用パケット応答のレスポンスタイムを比較することにより検出できる。

調査用パケット応答に変化があれば、アプリケーション解析部１０５はステップＳ４５に進む。調査用パケット応答に変化がなければ、アプリケーション解析部１０５は、ステップＳ４４に進み、アプリケーション毎に対応付けられたサーバグループ内で比較結果に差異があるかを判定する。なお、アプリケーション毎に対応付けられたサーバグループは図２２の管理テーブル構成に含まれるサーバグルーピングテーブルから得られる。サーバグルーピングテーブルは調査用パケット応答の返信元サーバをアプリケーションと関連付けてグループ化して管理するためのものである。

図２４は被監視サーバのグループ化を表した一例のイメージ図である。図２４はサーバＡ及びＢがＷｅｂアプリグループとしてグループ化され、サーバＢ，Ｃ及びＤがＪａｖａＥＥグループとしてグループ化され、サーバＥがデータベースグループとしてグループ化された様子を表している。

アプリケーション毎に対応付けられたサーバグループ内で比較結果に差異があれば、アプリケーション解析部１０５はステップＳ４５に進む。アプリケーション毎に対応付けられたサーバグループ内で比較結果に差異がなければ、アプリケーション解析部１０５はステップＳ４１に戻る。

ステップＳ４５では、アプリケーション解析部１０５がアプリケーションの稼働異常としてアプリケーションの停止や性能劣化等を検出する。アプリケーション解析部１０５は図２５のような監視画面２００へのメッセージ／画面出力などによりアプリケーションの稼働異常をＩＴサービスの管理者へ通知する。

図２５はアプリケーションの稼働異常通知の為の一例の画面イメージである。図２５では被監視サーバＣがサーバダウンしたため、アプリケーションＩＤが「Ａ００１」のアプリケーションのうち被監視サーバＣ上で稼働していたものが停止していることを例えば視覚的変化（色を変化させる等）により表すと共に、被監視サーバＣの応答がない旨を表すメッセージを表示した画面イメージを表している。

ＩＴサービスの管理者は、メッセージ／画面出力結果から異常対処を判断し、異常内容に応じた処置を行うことができる。

以上、説明してきたように、本実施例の監視サーバ１００は、被監視サーバに監視ソフトウェアを導入せずに、業務アプリケーションを特定するための定義情報として被監視アプリケーションテーブルを自動生成する手段と、被監視アプリケーションテーブルを利用して被監視サーバ上で稼働するアプリケーションの存在有無を検出する手段と、検出した時点で稼働していたアプリケーションを稼働アプリケーションテーブルとして記憶し、定期的なポーリング結果と、先に記憶しておいた稼働アプリケーションテーブルのスナップショットと、を比較することによりアプリケーションの稼働状況を把握する手段とを有している。

したがって、本実施例の監視サーバ１００は監視ソフトウェア１０１からの操作でＩＴサービスを実現する業務アプリケーションの被監視アプリケーションテーブルを自動的に作成することができると共に、被監視サーバ上のＩＴサービスを容易に監視できる。

（効果）
本実施例の監視サーバ１００によれば、業務アプリケーションが稼働する被監視サーバへの監視ソフトウェアの導入と、導入に伴うサーバ停止などが不要となる。また、本実施例の監視サーバ１００によれば、被監視サーバへの監視ソフトウェアの導入なしに、業務アプリケーションの稼働状況を検出／監視できる。

また、本実施例の監視サーバ１００によれば、被監視サーバへのリモート操作を行う必要が無く、リモート操作に予め必要となるアクセスアカウント設定、ファイアウォール設定変更などの作業が不要となる。本実施例の監視サーバ１００によれば、被監視サーバへのリモート操作を行う必要が無いため、第三者からのリモート操作などのセキュリティリスクを回避できる。

また、本実施例の監視サーバ１００によれば、業務アプリケーションの検出を自動で行うため、事前に検索対象の業務アプリケーションを定義する必要が無くなる。本実施例の監視サーバ１００によれば、同一の業務アプリケーション（使用する通信ポートが異なるものも含む）が導入された被監視サーバをグループ化して管理することにより、グループ化された被監視サーバ間、業務アプリケーション間を比較して差異の有無を確認でき、いち早く被監視サーバや業務アプリケーションの異常兆候を見つけ出すことができる。

また、本実施例の監視サーバ１００によれば、業務アプリケーションからのレスポンスタイム（反応時間）を監視（前回と今回との比較、又は、前回以前の平均と今回との比較など）することで、業務アプリケーションの性能状況を確認できる。

その他、本実施例の監視サーバ１００では、従来技術の監視ソフトウェアやリモートコマンドの動作による運用システムのリソースの消費が不要となる（ＣＰＵ、メモリ、Ｄｉｓｋ、Ｉ／Ｏなど）。

以上、本実施例によれば、ＩＴサービスを実現するアプリケーションが稼働するシステムに監視ソフトウェアを導入せず、間接的にＩＴサービスの監視システムからリモートでアプリケーションの監視ができるようになる。

本発明は、以下に記載する付記のような構成が考えられる。
（付記１）
被監視装置上で稼働するアプリケーションを監視する監視装置であって、
複数種類の調査用パケットを生成し、前記複数種類の調査用パケットを被監視装置上の各通信ポートに順次送信する調査用パケット生成／送信手段と、
前記被監視装置上の通信ポートから返信された前記複数種類の調査用パケットに対する調査用パケット応答を受信する調査用パケット応答受信手段と、
前記複数種類の調査用パケットに対する調査用パケット応答の内容を分析し、前記被監視装置上で稼働するアプリケーションを監視対象のアプリケーションとして解析するアプリケーション解析手段と
を有する監視装置。
（付記２）
前記調査用パケット生成／送信手段は、下位レイヤのネットワークプロトコルの調査用パケットを第１の調査用パケットとして生成し、該第１の調査用パケットを被監視装置上の各通信ポートに送信した後、前記第１の調査用パケットに対する第１の調査用パケット応答を返信してきた前記被監視装置上の通信ポートに対し、前記被監視装置上で稼働しているアプリケーションを解析できるまで、順次、前記第１の調査用パケットよりも上位レイヤの第２の調査用パケットを生成して送信する付記１記載の監視装置。
（付記３）
前記アプリケーション解析手段は、前記調査用パケット応答の内容を分析した結果に基づいて、同一のアプリケーションが稼働している前記被監視装置をアプリケーション毎にグループ化してグルーピングテーブルに記録しておき、グループ化した前記被監視装置上の通信ポートから返信された前記調査用パケット応答の差異の有無を、前記被監視装置上で稼働しているアプリケーションの状況の監視に利用する付記１又は２記載の監視装置。
（付記４）
前記アプリケーション解析手段は前記調査用パケット生成／送信手段に指示し、前記被監視装置上で稼働しているアプリケーションを解析した前記調査用パケットを所定時間毎に前記被監視装置上の通信ポートに送信させて、前記調査用パケット応答受信手段が新たに受信した前記調査用パケットに対する調査用パケット応答の内容を分析し、前記被監視装置上で稼働するアプリケーションを監視対象のアプリケーションとして解析して、前回の解析結果と比較することにより、前記被監視装置上で稼働しているアプリケーションの状況を監視する付記１乃至３何れか一項記載の監視装置。
（付記５）
前記アプリケーション解析手段は、前記複数種類の調査用パケットに対する前記調査用パケット応答の有無、前記調査用パケット応答に含まれるメッセージの内容、前記調査用パケット応答のエラーに応じて、前記被監視装置上で稼働しているアプリケーションを解析する付記１乃至４何れか一項記載の監視装置。
（付記６）
コンピュータによって実行される監視方法であって、
前記コンピュータが、
複数種類の調査用パケットを生成し、前記複数種類の調査用パケットを被監視装置上の各通信ポートに順次送信する調査用パケット生成／送信ステップと、
前記被監視装置上の通信ポートから返信された前記複数種類の調査用パケットに対する調査用パケット応答を受信する調査用パケット応答受信ステップと、
前記複数種類の調査用パケットに対する調査用パケット応答の内容を分析し、前記被監視装置上で稼働するアプリケーションを監視対象のアプリケーションとして解析するアプリケーション解析ステップと
を実行する監視方法。
（付記７）
被監視装置上で稼働するアプリケーションを監視するコンピュータを、
複数種類の調査用パケットを生成し、前記複数種類の調査用パケットを被監視装置上の各通信ポートに順次送信する調査用パケット生成／送信手段と、
前記被監視装置上の通信ポートから返信された前記複数種類の調査用パケットに対する調査用パケット応答を受信する調査用パケット応答受信手段と、
前記複数種類の調査用パケットに対する調査用パケット応答の内容を分析し、前記被監視装置上で稼働するアプリケーションを監視対象のアプリケーションとして解析するアプリケーション解析手段と
して動作させる為の監視プログラム。

本発明は、具体的に開示された実施例に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。なお、実施例において処理の主体がプログラムのように記載されている箇所は、演算処理装置６６がプログラムを実行することにより処理することを表している。

１ クライアント
２ Ｗｅｂサーバ
３ アプリケーションサーバ
４ データベースサーバ
５ ロードバランサー
１１ ハードウェア
１２，３１，３４ ＯＳ
１３ アプリケーション
２０ クラスタシステム
２１ 運用系のプライマリノード
２２ 待機系のセカンダリノード
２３ 共有ディスク
２４，２５，３５，４１，４２，５５ 業務アプリケーション
３０ ホストサーバ
３２ 仮想化プログラム
３３ 仮想サーバ
４３ 基盤アプリケーション
５１，１００ 監視サーバ
５２ 被監視サーバ
５３，５４，１０１ 監視ソフトウェア
５６，５７ ｔｅｌｎｅｔ
６１ 入力装置
６２ 出力装置
６３ ドライブ装置
６４ 補助記憶装置
６５ 主記憶装置
６６ 演算処理装置
６７ インターフェース装置
６８ 記録媒体
１０２ 調査用パケット生成／送信部
１０３ 調査用パケット応答受信部
１０４ 調査用パケット応答データベース
１０５ アプリケーション解析（稼働アプリケーション検出）部
１０６ アプリケーション構成（接続関係）分析部
１１０，２００ 監視画面
Ｂ バス

Claims (6)

1. 被監視装置上で稼働するアプリケーションを監視する監視装置であって、
   複数種類の調査用パケットを生成し、前記複数種類の調査用パケットを被監視装置上の各通信ポートに順次送信する調査用パケット生成／送信手段と、
   前記被監視装置上の通信ポートから返信された前記複数種類の調査用パケットに対する調査用パケット応答を受信する調査用パケット応答受信手段と、
   前記複数種類の調査用パケットに対する調査用パケット応答の内容を分析し、前記被監視装置上で稼働するアプリケーションを監視対象のアプリケーションとして解析するアプリケーション解析手段と
   を有する監視装置。
2. 前記調査用パケット生成／送信手段は、下位レイヤのネットワークプロトコルの調査用パケットを第１の調査用パケットとして生成し、該第１の調査用パケットを被監視装置上の各通信ポートに送信した後、前記第１の調査用パケットに対する第１の調査用パケット応答を返信してきた前記被監視装置上の通信ポートに対し、前記被監視装置上で稼働しているアプリケーションを解析できるまで、順次、前記第１の調査用パケットよりも上位レイヤの第２の調査用パケットを生成して送信する請求項１記載の監視装置。
3. 前記アプリケーション解析手段は、前記調査用パケット応答の内容を分析した結果に基づいて、同一のアプリケーションが稼働している前記被監視装置をアプリケーション毎にグループ化してグルーピングテーブルに記録しておき、グループ化した前記被監視装置上の通信ポートから返信された前記調査用パケット応答の差異の有無を、前記被監視装置上で稼働しているアプリケーションの状況の監視に利用する請求項１又は２記載の監視装置。
4. 前記アプリケーション解析手段は前記調査用パケット生成／送信手段に指示し、前記被監視装置上で稼働しているアプリケーションを解析した前記調査用パケットを所定時間毎に前記被監視装置上の通信ポートに送信させて、前記調査用パケット応答受信手段が新たに受信した前記調査用パケットに対する調査用パケット応答の内容を分析し、前記被監視装置上で稼働するアプリケーションを監視対象のアプリケーションとして解析して、前回の解析結果と比較することにより、前記被監視装置上で稼働しているアプリケーションの状況を監視する請求項１乃至３何れか一項記載の監視装置。
5. コンピュータによって実行される監視方法であって、
   前記コンピュータが、
   複数種類の調査用パケットを生成し、前記複数種類の調査用パケットを被監視装置上の各通信ポートに順次送信する調査用パケット生成／送信ステップと、
   前記被監視装置上の通信ポートから返信された前記複数種類の調査用パケットに対する調査用パケット応答を受信する調査用パケット応答受信ステップと、
   前記複数種類の調査用パケットに対する調査用パケット応答の内容を分析し、前記被監視装置上で稼働するアプリケーションを監視対象のアプリケーションとして解析するアプリケーション解析ステップと
   を実行する監視方法。
6. 被監視装置上で稼働するアプリケーションを監視するコンピュータを、
   複数種類の調査用パケットを生成し、前記複数種類の調査用パケットを被監視装置上の各通信ポートに順次送信する調査用パケット生成／送信手段と、
   前記被監視装置上の通信ポートから返信された前記複数種類の調査用パケットに対する調査用パケット応答を受信する調査用パケット応答受信手段と、
   前記複数種類の調査用パケットに対する調査用パケット応答の内容を分析し、前記被監視装置上で稼働するアプリケーションを監視対象のアプリケーションとして解析するアプリケーション解析手段と
   して動作させる為の監視プログラム。

Images