JP5625621B2 - 検出装置、方法、及びプログラム - Google Patents

検出装置、方法、及びプログラム Download PDF

Info

Publication number
JP5625621B2
JP5625621B2 JP2010188794A JP2010188794A JP5625621B2 JP 5625621 B2 JP5625621 B2 JP 5625621B2 JP 2010188794 A JP2010188794 A JP 2010188794A JP 2010188794 A JP2010188794 A JP 2010188794A JP 5625621 B2 JP5625621 B2 JP 5625621B2
Authority
JP
Japan
Prior art keywords
application
information
name
multiplexed
applications
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2010188794A
Other languages
English (en)
Other versions
JP2012048408A (ja
Inventor
有起 多田
有起 多田
靖 小林
靖 小林
酒井 和行
和行 酒井
一樹 ▲高▼橋
一樹 ▲高▼橋
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2010188794A priority Critical patent/JP5625621B2/ja
Priority to US13/094,269 priority patent/US8554908B2/en
Publication of JP2012048408A publication Critical patent/JP2012048408A/ja
Application granted granted Critical
Publication of JP5625621B2 publication Critical patent/JP5625621B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/66Arrangements for connecting between networks having differing types of switching systems, e.g. gateways

Description

本発明は、分散コンピューティング環境におけるアプリケーション多重関係を検出する装置、方法、およびプログラムに関する。
IT(Information Technology)システムで、構成情報とトランザクションを監視することによりシステム上で実行されるアプリケーションを管理する技術では、システム内のコンピュータがどのように連携してITサービスを実現しているかを動的に検出することが求められる。このような技術により、運用管理者はITシステムをITサービスの観点で運用管理・トラブルシュートできる。
例えば、Web(ウェブ)サーバとアプリケーションサーバとデータベースサーバが連携して動作しているITサービスで、利用者が見ているWebページでの指示が動作しなくなったとき、そのサービスを実現するサーバ間のどこで問題が発生したかを把握する必要がある。
このような監視機能を実現する従来技術としては、監視対象となるITシステム内のウェブサーバやアプリケーションサーバ、データベースサーバ間を流れるトランザクションを収集、分析する技術が知られている。
また、ITシステム内の各コンピュータの構成情報やアプリケーションの情報を収集する技術が知られている。
更に、アプリケーションプログラムが複数のコンピュータ上で同時に実行される多重コンピュータシステムのアーキテクチャを開示した技術が知られている(例えば特許文献1)。
加えて、アプリケーションソフトウェア内等で許可されたユーザの特定のトランザクションアクセスパターンについてのユーザ行動プロフィールを構築し異例のトランザクション活動を検知する技術が知られている(例えば特許文献2に記載の技術)。
企業が構築するITシステムでは、負荷分散やリスク回避のために、ITサービスを構成するアプリケーションを多重化して、分散コンピューティング環境で運用することが行なわれる。
特表2007−534066号公報 特表2006−519439号公報
しかし、従来技術では、ITシステム内に多重化されたアプリケーションがあるかどうかを検出できないため、多重化されたアプリケーションがあっても、それぞれを別々のアプリケーションと判断してしまう。
そのため、従来技術は、負荷分散のために多重化されているアプリケーションの一方でトラブルが発生しITサービスの一部が停止した場合と、多重化されていないアプリケーションでトラブルが発生しITサービス全体が停止した場合の違いを検出できない。
そこで、1つの側面では、本発明は、ITシステムのアプリケーション管理において、多重化されたアプリケーションを検出可能とすることを目的とする。
態様の一例では、情報システムの構成情報収集する収集手段と、収集した前記構成情報基づいて、前記情報システム内のいずれかの監視対象装置に導入される、情報サービスの提供に用いられる第1のアプリケーションと該第1のアプリケーションにデプロイされる第2のアプリケーションとの組み合わせについて、該第1のアプリケーションのアプリケーション名が一致し、且つ、第2のアプリケーションのアプリケーション名が一致する複数の組み合わせが存在する場合に、多重化されているアプリケーションが存在することを検出する検出手段とを備えることを特徴とする検出装置を提供する。
多重化されたアプリケーションを検出することが可能となる。
一般的なITシステム監視によるトラブルシュートの例を示す図である。 ITシステム監視を使用しない場合の例を示す図である。 一般的なITシステムの全体構成図である。 運用状態に合った適切なアラートの発生の説明図である。 ロードバランサを使わないクラスタリングの例を示す図である。 ロードバランサを使わないクラウド環境の例を示す図である。 本発明の第1の実施形態の各手法の組み合わせ一覧を示す図である。 トランザクションコンテキストあるいはトランザクション情報を用いたアプリケーション多重化検出の説明図である。 アプリ名が部分一致である例を示す図である。 トランザクションコンテキストによる部分一致アプリの検出を用いたアプリケーション多重化検出の説明図である。 トランザクション情報による部分一致アプリの検出の説明図である。 アプリ名が包含関係である例を示す図である。 トランザクションコンテキストによる包含アプリの検出の説明図である。 トランザクション情報による包含アプリの検出を用いたアプリケーション多重化検出の説明図である。 実施形態の機能構成図である。 実施形態のシステム構成図である。 実施形態の全体処理を示すフローチャートである。 アラートの通知方法の違いの説明図である。 本発明の実施形態の第1の実施形態の全体処理を示すフローチャートである。 多重化アプリ候補のデータ構成例を示す図である。 サブネットによる篩い分け処理であるサブフロー1を示す図である。 サブネットによる篩い分けの説明図である。 トランザクションコンテキストによる篩い分け処理であるサブフロー2を示す図である。 トランザクションコンテキストのデータ構成例を示す図である。 トランザクション情報による篩い分け処理であるサブフロー3を示す図である。 トランザクション情報のデータ構成例を示す図である。 トランザクション情報による多重化アプリの特定の説明図である。 部分一致または包含を用いた篩い分け処理であるフローチャートを示す図である。 アプリ名が部分一致する多重化アプリの検出用データの例を示す図である。 アプリ名が包含関係の多重化アプリ検出用データの例を示す図である。 アプリ名が部分一致する多重化アプリの検出動作の説明図である。 アプリ名が包含関係の多重化アプリの検出動作の説明図である。 トランザクションコンテキストによる部分一致アプリ、包含アプリの検出処理を示すサブフロー4である。 トランザクション情報による部分一致アプリ、包含アプリの検出処理を示すサブフロー5である。 本発明の第2の実施形態の処理を示すフローチャートである。 本発明の第2の実施形態の説明図である。 本発明の第3の実施形態の処理を示すフローチャートである。 アラート表示例を示す図である。 CMDBからのコンテナアプリ名一覧取得データ例を示す図である。 CMDBからのサブネットアドレス取得データ例を示す図である。 (1)CMDBからのトランザクションコンテキスト取得データ例を示す図である。 (2)CMDBからのトランザクションコンテキスト取得データ例を示す図である。 CMDBから取得したトランザクション情報のデータ例を示す図である。 CMDBから取得したITサービスのデータ例を示す図である。 本実施形態のシステムを実現可能なハードウェアシステムの構成図である。
以下、本発明を実施するための形態について図面を参照しながら詳細に説明する。
まず、一般的なITシステムのアプリケーション管理技術について説明する。
例えば図1のように、一般的なITシステムの運用管理では、例えば、利用者が見ているWebページでの指示が動作しなくなったとき、そのサービスを実現するサーバA,B,C間の繋がりが分かり、例えば、サーバBとCの間で問題が起こっているようだということを把握できる。これに対して、図2のように、サーバ間がどのように連携しているのかを把握できていなければ、トラブルへの対処が遅れることになる。
そこで、一般的なITシステムでは、図3のように、監視対象となるITシステム内のウェブサーバやアプリケーションサーバ、データベースサーバ間を流れるトランザクション情報をトランザクション収集装置に記憶する。トランザクション収集装置は、トランザクションの内容を分析する。また、トランザクション収集装置は、ITシステム内の各コンピュータの構成情報やコンテナアプリ、コンテナアプリ上にデプロイされているアプリケーションの情報を収集する。トランザクション収集装置が収集したデータは、構成管理データベース(CMDB)に登録される。そして、収集した情報を、管理コンソールを通じて閲覧可能にしている。監視対象となっているITサービスが定義されたサービスレベルを違反すると、アラートを発生させ、運用管理者に問題を報告する。
ここで、以降の説明において使用する各種用語について、以下のように定義する。

□ITシステム:
企業活動を実現するために構築された情報処理システム。
□ITサービス:
サーバやストレージ、アプリケーションの集合体であり、それらがお互いに連携することで、ユーザに価値を与える。
□構成情報:
ITシステムのサーバハードウェアやソフトウェア、プロセス、アプリケーションなどの情報のことをいう。後述するコンテナアプリ、デプロイドアプリも含まれる。
□CMDB:
Configuration Management Databaseの略。構成管理データベースのこと。ITシステムを構成するすべての構成アイテムの情報を一元的に管理するもの。各構成アイテムを関連付けて管理できる。
□トランザクション情報:
ITシステム内のコンピュータがネットワークケーブルを通じて他のコンピュータに対して送信する信号の情報、すなわち通信データ。トランザクション送信元のIPアドレス、トランザクションを受信する宛て先のIPアドレス、そのトランザクションの要求メッセージ、要求メッセージに対する応答メッセージが含まれる。
□コンテナアプリ:
ウェブサーバやアプリケーションサーバ、データベースサーバなど、ITサービスを構成するための機能を提供する基盤ソフトウェア。例えば、Apache HTTP Server,IIS等のウェブサーバがある。また、Interstage,Tomcat,JBoss,WebLogic等のアプリケーションサーバがある。さらに、Symfoware,Oracle Database Server,MySQL等のデータベースサーバがある。「Apache」は、Apache Software Foundationの登録商標である。「Interstage」「Symfoware」は、富士通株式会社の登録商標である。「IIS」は、Microsoft Corporationの登録商標である。「MySQL」は、Sun Microsystemsの登録商標である。
□デプロイドアプリ:
コンテナアプリにデプロイされた、プログラムやデータ。このアプリがITサービスの処理を担当している。例:ウェブサーバの設定情報、Javaサーブレット、JSP、データベースのテーブル等。
□ディープディスカバリ機能:
コンテナアプリ、デプロイドアプリを検出・監視するための機能。コンテナアプリやデプロイドアプリのアプリケーション名(以下、アプリ名)、稼動状態、設定情報などを抽出する。
□SNMP:
Simple Network Management Protocolの略。ネットワーク機器の監視・制御のための情報を通信するためのプロトコル。
□多重化:
コンピュータの性能向上や負荷分散して可用性を向上するため、同じ機能を持った複数のコンテナアプリ(またはデプロイドアプリ)を同一、または複数のサーバにデプロイ(インストール)し、コンテナアプリのときはインストールといい、デプロイドアプリのときはデプロイというが、一般的にインストールともいう。
□多重化アプリ:
多重化しているアプリを、ここでは多重化アプリと呼ぶ。
□トランザクションコンテキスト:
ITサービスを実現するために実行されるデプロイドアプリの前後関係データ。例えば、後述する図4中でITサービスAがWeb2,App3,DB1という順序で実行されているとき、Web2からApp3のデプロイドアプリAを実行し、デプロイドアプリAはDB1のテーブルAの情報を参照しているというトランザクションの順序情報。トランザクション収集装置の情報を分析して得る。
□サービスレベル:
ITサービスの範囲と品質に関する尺度。
ここで、図1から図3で説明したような一般的なアプリケーション管理では、以下のような問題がある。
まず、ITサービスが多重化されているとき、間違ったアラートを発生させることがある。例えば企業が構築するITシステムでは、負荷分散やリスク回避のためにITサービスを構成するコンテナアプリを多重化して運用することが行なわれる。しかし、一般的なアプリケーション管理技術では、トランザクション同士の関係を判断するための十分な情報を検出できない。一般的なアプリケーション管理技術では、ネットワーク機器を通過するコンピュータ間のトランザクションを記憶して、トランザクション収集装置で収集・分析する。また、その通信の中に特定の識別子があると、それが何というコンテナアプリであるかを判断できる定義をもっている。そのため、あるトランザクションがどのコンピュータ間でのやりとりかを把握することと、その通信が何というコンテナアプリによるものかを判断することができる。しかし、各トランザクション同士がどういう関係かを判断するための情報が十分ではない。例えば、同じロードバランサに繋がっていれば多重化アプリであるというような定義を十分に揃えれば、多重化アプリを検出できるが、その場合はITシステムの構築方法毎に無数の定義が必要になる。このため一般的なアプリケーション管理技術では、ITシステム内に多重化アプリがあるかどうかを簡単には検出できないため、多重化アプリがあっても、それぞれを別々のアプリと判断してしまう。そのため、負荷分散のために多重化されているアプリのうちの一方でトラブルが発生してITサービスの一部が停止した場合と、多重化されていないアプリでトラブルが発生してITサービス全体が停止した場合の違いを検出できない。さらに、ITサービスの一部が停止したが、実際にはITサービスが継続できている状態でも、ITサービスが停止したという間違ったアラートを発生させてしまう。
ITサービスが停止した場合、企業にとってユーザの信頼を失うなどの重大な損失が発生するリスクがあるため、多くの人員を導入するなどの対処が必要となり、問題解決にかかるコストが高い。一方、ITサービスの一部が停止しただけならば、問題解決のために導入する人員を少なくでき、コストを抑えられる。そのため、管理コンソールでは、複数検出されたITサービスのうち、多重化されているものは束ねて一つのITサービスだと分かるようにした方が適切と言える。
また、例えば図4において、ウェブサーバ、ロードバランサLB1に接続されたWeb1,Web2、Web3あるいはロードバランサLB2に接続されたアプリケーションサーバApp1、App2,App3は、それぞれ同じものが複数個あるので、多重化されている。ロードバランサLB1によってWeb1、Web2、Web3が多重化されていることを検出できればWeb1がシステムダウンしても、ITサービスAは稼動していることを示すことができる。ITサービスを構成するサーバやソフトの一部でトラブルが発生した場合、多重関係にあるITサービスを含めて表示できたほうが良い。また、サービスの一部が停止しただけで、他の多重関係にあるサービスによって業務が継続できる状態の場合は、アラートのレベルを業務が停止した場合よりも下げ、運用管理者がリスクに見合った措置を取れるようにする必要がある。一方、多重関係にあるITサービスが複数、または全て停止していることが検出される場合、通常よりもインパクトの強いトラブルと言えるため、アラートレベルを上げる必要がある。
さらに、ITサービスが多重化されているとき、多重化アプリを検出できる環境が制限される。例えば、一般的なアプリケーション管理技術では、SNMPによって監視対象の構成情報を監視しているのである。SNMPによってネットワーク上のロードバランサから構成情報を取得すると、どのサーバがロードバランサによって多重化されているかを検出できる。しかし、例えば図5のような構成を有するクラスタリング環境や、図6のような構成を有するクラウド環境のように、ロードバランサ以外の機器を利用して多重化している場合はこの方法が使えない。
クラスタリング環境とは、複数のコンピュータを結合し、クラスタとしてひとまとまりのシステムにしたものであり、それらを実現するためのソフトウェアやハードウェア、更には実現されたシステムを指す。クラスタ内の複数のコンピュータは何らかのネットワークを介して相互に接続され、ひとつのコンピュータシステムとして扱えるように制御されている。その結果、一台のコンピュータでは得られない、性能や可用性などを得ることができる。図5において、例えばInterstageとSymfowareはクラスタ化され、その中で2つのInterstageは多重化されている。クラスタはロードバランサで対応できないため、この多重化を検出できない。
また、クラウド(cloud)環境とは、ネットワーク、例えば、インターネットをベースとしたコンピュータの利用環境をいう。図6において、ユーザはインターネットに接続されたコンピュータリソース全体をクラウドとして利用し、ネットワーク経由で、ITサービスを利用する。クラウドにおいては、日々多重化関係が変化することもあるが、この多重化も検出できない。
クラスタリング環境により性能向上や可用性向上を図ったり、クラウド環境によりシステム構築コストを削減することは企業が構築するITシステムでは一般的に利用されている手法である。このため、SNMPを利用するシステム監視方法だけでは、対応できるITシステムが限られてしまう。そのため、多くの環境に対応できる多重化アプリ検出方法が必要となる。
そこで、後述する実施形態では、以下の手段A,B,C,D,Eの機能を実装する。図7は本発明の実施態様の各手段A,B,C,Dを示す。尚、手段Eは、図示を省略した。
<手段A(多重化アプリ検出部)>
ITシステム上の監視対象にデプロイされているアプリのアプリ名(コンテナアプリ名やデプロイドアプリ名)が一致するかを評価することで多重化アプリを検出し、その情報に基づき適切なアラートを出す。
<手段B(多重化アプリ検出部)>
手段Aにサブネットのチェック手順を加えたもの。
アプリ名とサブネットが一致するかどうかを評価する。これにより、多重化アプリの誤検出を軽減する。検出した多重化アプリの情報に基づき適切なアラートを出す。
一般的に異なるサブネットで多重化が行われることはない、という知見に基づく。
<手段C(多重化アプリ検出部)>
手段Aにトランザクションコンテキストのチェック手順を加えたもの。
アプリ名とトランザクションコンテキストを分析することで多重化アプリを検出し、その情報に基づき適切なアラートを出す。
<手段D(多重化アプリ検出部)>
手段Aにトランザクション情報のチェック手順を加えたもの。
アプリ名とトランザクション情報を分析することで多重化アプリを検出し、その情報に基づき適切なアラートを出す。
<手段E(多重化アプリ検出部)>
手段Cのトランザクションコンテキストの分析または手段Dのトランザクション情報の分析において、部分一致関係または包含関係にあるアプリケーションを手段Aに加えて検出することにより、多重化アプリの検出をする。
さらに、上記手段は必要に応じて、図7に示されるように組み合わせることができる。手段Aが最も基本的な方法である。手段B以降は、表の縦方向の下になるほど、複雑な検出手法となっている。尚、手段Eは、図示を省略化した。監視システムの性能の観点から、できるだけ簡単な検出手法を選択できたほうがよいと思われるため、まず手段Aを試してみて、運用管理者が把握している多重化アプリが検出されなかった場合、もしくは、後述する誤検出や検出漏れ条件に当てはまる場合、手段B、手段C、手段Dを段階的に使っていくことで消費するリソースを少なくできる。すなわち、手段A,B,C,Dを手段B+C、B+D、C+D、B+C+Dあるいは手段Eのいずれかを使用して、多重化アプリを検出する。また、初めから手段B+C+Dの方法を使い、運用管理者が多重化されていることを把握していなかった多重化アプリを検出するなどの使い方もありうる。
以下、各手法について説明する。
(A)手段Aでは、多重化アプリを検出するために、ディープディスカバリ機能により収集したアプリ名を使用する。この情報を使うことで同一の目的でデプロイされたアプリの組み合わせが検出できる。例えば、図4のアプリケーションサーバ(App1,App2,App3)は、負荷分散のために多重化されている。これらのアプリケーションサーバには同一のコンテナアプリ、デプロイドアプリがデプロイされていると考えられる。そのため、これらのアプリ名は一致するはずである。したがって、アプリ名を評価することで多重化アプリを検出することが可能となる。
ただし、手段Aのみでは、以下のようなケースでは、誤検出することや検出漏れが発生することがある。
(1)多重化されていないがアプリ名(コンテナアプリ名またはデプロイドアプリ名)が一致するケース(誤検出)
・初期状態
アプリケーションサーバなどをインストールした直後の状態。どのアプリケーションサーバにも予め標準のアプリがデプロイされている可能性がある。これらはまだ多重化されている訳ではない。
・開発マシンと運用マシン
開発マシンは運用マシンと同名のアプリがデプロイされている可能性がある。開発マシンはITシステム内に置かれていても、多重化されている訳ではない。しかし、アプリ名が一致するかどうかだけで評価すると誤検出してしまう。
・偶然アプリ名が一致した場合
異なる開発者が偶然同じアプリ名を使う可能性がある。
・故意にアプリ名を一致させた場合
テスト等の目的で同名の異なる機能を実装したアプリがデプロイされる可能性がある。
(2)多重化されているがアプリ名が一致しないケース(検出漏れ)
・アプリ名が部分一致、包含関係にある場合
アプリケーションを多重化しつつ、一部のマシンのみ別のデプロイドアプリもデプロイしている場合、アプリ名の一致のみでは多重化されているマシンを検出できない。
以上の問題により、アプリ名の一致を評価するだけでは誤検出する場合や検出できない場合がある。そこで、サブネットが一致するかを評価する(手段B)。さらに、トランザクションコンテキスト(手段C)、トランザクション情報(手段D)も合わせて利用する。
(B)まず、手段Bにより、多くの誤検出を防ぐことができる。例えば、開発マシンと運用マシンは同一サブネット内に置かれることは一般的にはあまり無いため、サブネットが異なると考えられる。そのため、サブネットの不一致を検出することで、多重化アプリの候補から外すことができる。この他の誤検出する可能性があるケースも、運用環境と同一のサブネットに置かれる可能性は低いという理由から、多重化アプリの候補から外すことができる。
そこで、手段Cまたは、手段Dも選択できるようにする。
(C)手段Cでは、アプリ名と共に、トランザクションコンテキストを利用する。この手段は、「前後のアプリは何か」が、評価する対象となる。トランザクションコンテキストを参照することで、多重化アプリの前に呼び出されるアプリと後に呼び出されるアプリが分かる。同じITサービスとして機能するアプリなら、前に呼び出されるアプリと後に呼び出されるアプリが(前後が多重化されていなければ)一致する。
比較する内容として、コンテナアプリ名のみを利用する方法やコンテナアプリ名とデプロイドアプリ名を合わせて利用する方法、デプロイドアプリ名のみを利用する方法がある。デプロイドアプリ名まで深く評価するほど精度の向上が見込める。また、直前直後のみに限らず、前は1台、後ろは3台を比較対象に加えるなど、比較対象を柔軟に拡張できる。
例えば、図8の例では、トランザクションコンテキストCon1,Con2があり、Con1はアプリ名がBというアプリがデプロイされているサーバを通り、Con2はアプリB'がデプロイされているサーバを通る。この例では、前アプリは1つ、次に、例として、コンテナアプリ名を比較して多重化アプリを検出する方法を示す。図8のアプリB、B'は共にアプリAから要求メッセージを受信し、アプリCに要求メッセージを送信する。そのため、BとB'は多重化アプリである。これを検出するには、Con1から、Bの前アプリと後アプリがA、Cであることと、Con2からB'の前アプリと後アプリがA、Cであることを検出し、前後のアプリ名が一致することから多重化アプリと判断する。
手段Cにより、「初期状態」ではトランザクションが流れていないことから多重化アプリの候補から除外でき、「開発マシンと運用マシン」、「偶然アプリ名が一致した場合」、「故意にアプリ名を一致させた場合」は、前後のアプリ名が異なることから多重化アプリの候補から除外できる。前後のアプリ名が偶然一致する可能性もあるが、ほぼ無視できる割合しか存在しないと思われる。
(D)手段Dは、手段Cとはトランザクション情報を利用する点が異なる。この手段は、アプリに流れ込む要求メッセージと応答メッセージ、アプリから流れ出す要求メッセージと応答メッセージが評価する対象となる。同じ機能を提供するアプリであれば、トランザクション情報の要求メッセージと応答メッセージが一致する。
例えば、図8のBとB'がAから要求を受け、Cへ要求メッセージを送信するならば、AからBとB'に向けて送信されるトランザクションには、宛て先IPは異なるが、送信元IPと要求メッセージ、応答メッセージが一致するものが流れる。また、BとB'からCに送信されるトランザクションは、送信元IPが異なるが、宛て先IPと要求メッセージ、応答メッセージが一致するものが流れる。
BとB'のアプリ名が一致し、トランザクション情報が一致する(BかB'が受信するトランザクションの場合は宛て先IP以外、BとB'が送信するトランザクションの場合は送信元IP以外)という条件を評価する。これにより、「初期状態」の場合はトランザクションが流れない。また、「開発マシンと運用マシン」、「偶然アプリ名が一致した場合」、「故意にアプリ名を一致させた場合」は、トランザクション情報が異なる。これらにより、多重化候補から除外できる。
手段Dでは要求メッセージ、応答メッセージのみを評価する方法が採用されてもよい。これにより、例えば図4のアプリケーションサーバの前にウェブサーバが多重化されている場合などのように、前後のアプリが多重化されている場合に、検出率を高くできる。
一方、手段Cまたは手段Dにおいて、複数種類のトランザクションコンテキストまたはトランザクション情報すべてに一致していれば多重化と判断する方法や、どれか一つのトランザクションコンテキストまたはトランザクション情報が一致していれば多重化と判断する方法などを環境に合わせて選択できるようにしてもよい。これにより、データベースサーバのように、前後のアプリとの間に複数種類のトランザクションが流れる場合に対応することができる。すべてのトランザクションコンテキストまたはトランザクション情報が一致しているか確認する方法は、計算コストは高いが正確に多重化アプリを検出できる。一方、どれか一つのトランザクションコンテキストまたはトランザクション情報が一致しているか確認する方法では、一致を検出したら計算を終了でき、計算コストが少なくて済む。
(E)多重化されているがアプリ名が一致しない場合は、手段Eを適用できる。手段Eでは、手段Cのトランザクションコンテキストの分析または手段Dのトランザクション情報の分析において、包含関係または部分一致関係にあるアプリケーションを手段Aのアプリ名に加えて検出することにより、多重化アプリの検出漏れを防げる。
例として、アプリケーションが部分一致関係にある場合を図9に示す。図9では、アプリケーションサーバApp1とApp2があり、App1にインストールされているコンテナアプリInterstageには、デプロイドアプリAppAとAppBがデプロイされている。また、App2にインストールされているコンテナアプリInterstageには、デプロイドアプリAppAとAppCがデプロイされている。App1のInterstegeとApp2のInterstageはコンテナアプリ名が一致しているから多重化アプリである。そして、App1ではAppBが別の目的のためにデプロイされており、App2ではAppCが別の目的のためにデプロイされている。この状態で、デプロイドアプリ名に基づき多重化アプリを検出する手法を使うと、デプロイドアプリ名が一致しないため、App1のInterstageとApp2のInterstageを多重化アプリとして検出できない。しかし、図10、図11で説明するようにApp1とApp2のトランザクションコンテキストまたはトランザクション情報から、AppAのみが多重化されているデプロイドアプリであることを検出することができる。
図10は、手段Eにおけるトランザクションコンテキストによる部分一致アプリの検出の説明図である。前アプリが顧客ページを持つコンテナアプリApacheで後アプリが顧客テーブルを持つコンテナアプリSymfowareである、コンテナアプリInterstageが複数見つかる。これらのInterstageは前アプリと後アプリが同じだから多重化アプリであることが分かる。そこで、多重化アプリと判定された全てのInterstageに共通してデプロイされているデプロイドアプリAppAが多重化アプリであり、その他のデプロイドアプリAppBとAppCは別の目的のアプリであることが検出できる。
図11は、手段Eにおけるトランザクション情報による部分一致アプリの検出の説明図である。App1とApp2のInterstageは、共にindex.htmlを持つApacheから要求を受け、Symfowareの顧客テーブルを参照する。そのため、トランザクションコンテキストからApp1のInterstageとApp2のInterstageは多重化アプリであることが分かる。さらに、App1とApp2に共通してデプロイされているデプロイドアプリAppAから多重化アプリが検出され、デプロイドアプリAppBとAppCは別の目的のアプリであることが検出できる。
次に、アプリケーションが包含関係にある場合を図12に示す。図12では、アプリケーションサーバApp1とApp2があり、App1にインストールされているコンテナアプリInterstageには、デプロイドアプリAppAとAppBがデプロイされている。また、App2にインストールされているコンテナアプリInterstageには、デプロイドアプリAppAのみがデプロイされている。図9の場合と同様に、App1のInterstegeとApp2のInterstageは多重化アプリであるが、App1のみ、AppBが別の目的のためにデプロイされている。この状態で、デプロイドアプリ名に基づき多重化アプリを検出する手法を使うと、図9の場合と同様に、デプロイドアプリ名が一致しないため、App1のInterstageとApp2のInterstageを多重化アプリとして検出できない。しかし、App1とApp2のトランザクションコンテキストまたはトランザクション情報から、AppAのみが多重化されているデプロイドアプリであることを検出することができる。
図13は、手段Eにおけるトランザクションコンテキストによる包含アプリの検出の説明図である。図11の場合と同様に、図11前アプリが顧客ページを持つコンテナアプリApacheで後アプリが顧客テーブルを持つコンテナアプリSymfowareである、コンテナアプリInterstageが複数見つかる。これにより、これらのInterstageは多重化アプリであることが分かる。そこで、多重化アプリと判定された全てのInterstageに共通してデプロイされているデプロイドアプリAppAが多重化アプリであり、その他のデプロイドアプリAppBは別の目的のアプリであることが検出できる。
図14は、手段Eにおけるトランザクション情報による包含アプリの検出の説明図である。App1とApp2のInterstageは、共にindex.htmlを持つApacheから要求を受け、Symfowareの顧客テーブルを参照する。そのため、App1のInterstageとApp2のInterstageは多重化アプリであることが分かる。さらに、App1とApp2に共通してデプロイされているデプロイドアプリAppAのみ多重化アプリとし、デプロイドアプリAppBは別の目的のアプリであることが検出できる。
上述の部分一致アプリと包含アプリの場合以外に、三つ巴の場合が考えられる。例えば、App1にAppA、AppB、App2にAppB、AppC、App3にAppC、AppAがデプロイされている場合である。この場合、AppA、AppB、AppCがそれぞれ別々の多重化アプリとなる。この場合には、手段Eにおいて、トランザクションコンテキストかトランザクション情報が一致しており、アプリ名が一致するものを組み合わせることで、多重化アプリを検出できる。
実施例を実現するための以上の基本的な考え方により、トランザクション間の関係をアプリ名、サブネット、トランザクションコンテキスト、トランザクション情報を組み合わせて自動的に検出することが可能となる。
この結果、多重化アプリの一部が停止した際に、その状況に合ったアラートを発生させるように設定できるため、運用管理者が障害の重大性に合った措置を選択できるようになる。
また、多くの多重化手法に対応できるため、既存のITシステムにすでに多重化手法を導入していても、多重化アプリを検出する製品を利用できるようになる。
以上説明した手段AからEまでの機能を実装した実施形態について、以下に説明する。
図15は、ITシステムアプリケーション管理システムの実施形態の機能構成図である。このシステムは、ITシステムを構成する監視対象サーバ群1505に対して、多重化アプリ検出部1501、構成情報収集部1502、トランザクション収集部1503、CMDB1504、および管理コンソール1506を備える。
構成情報収集部1502は、監視対象サーバ群1505の構成情報を収集し、CMDB1504に登録する。
トランザクション収集部1503は、監視対象サーバ群1505上で通信されるトランザクション情報をコピーして収集し、CMDB1504に登録する。
多重化アプリ検出部1501は、本実施形態による新機能を実装し、CMDB1504に登録されたトランザクション情報と構成情報を参照して、多重化アプリを検出する。
管理コンソール1506は、CMDB1504の登録内容を任意に参照可能はほか、多重化アプリ検出部1501が検出した多重化アプリの情報に基づき、適切なアラートを表示等する。
図16は、図15の機能構成を実装するITシステムアプリケーション管理システムの実施形態のシステム構成図である。このシステムは、トランザクション管理/構成情報管理装置1601、トランザクション分析/構成情報収集装置1602、トランザクション収集装置1603、スイッチ1604、およびファイアーウォール1605を実装する。
トランザクション管理/構成情報管理装置1601は、図15のCMDB1504の機能を実装するほか、図15の多重化アプリ検出部1501の機能を実装する。
トランザクション分析/構成情報収集装置1602は、図15の構成情報収集部1502の機能を実装する。
トランザクション収集装置1603は、図15のトランザクション収集部1503の機能を実装する。
監視対象サーバ群1505(図15参照)は、スイッチ1604およびファイアーウォール1605を介して、インターネット1606に接続される。
なお、図16のシステム構成は一例であり、例えば図15の多重化アプリ検出部1501の機能は、トランザクション分析/構成情報収集装置1602やトランザクション収集装置1603に実装されてもよい。
図17は、図16のシステム構成のもとで実装される図15の機能構成をコンピュタによる実現する全体処理を示すフローチャートである。
まず、構成情報収集部1502の機能として、ITシステム上の監視対象サーバ群1505から構成情報が収集され、CMDB1504に登録される(ステップS1701)。
次に、トランザクション収集部1503の機能として、監視対象サーバ群1505上を通信されるトランザクション情報が収集され、CMDB1504に登録される(ステップS1702)。
次に、多重化アプリ検出部1501の機能として、CMDB1504内のコンテナアプリ、デプロイドアプリ、トランザクション情報、トランザクションコンテキストから、多重化アプリが検出される(ステップS1703)。これは、実施形態による新機能1を実現する。
次に、多重化アプリ検出部1501の機能として、多重化アプリを含んだ、多重関係にあるITサービスが、一つに束ねられる(ステップS1704)。これは、第2の実施形態(多重関係情報サービス検出部)を実現する。
次に、管理コンソール1506の機能として、構成情報、トランザクション、多重化アプリの状態を含むITサービスの稼働状態が、管理コンソール1506上のディスプレイ装置等に表示される(ステップS1705)。
更に、多重化アプリ検出部1501の機能として、収集したデータが分析され、予め設定されたSLA(Service Level Agreement)に違反している場合はアラートが発生させられる。ただし、ITサービスが継続できるレベルのトラブルが発生した場合は、アラートのレベルを下げる等の制御が実施される(ステップS1706)。これは、第3の実施形態(多重関係に基づくアラート出力部)を実現する。
以上のステップS1701からS1706の処理が繰り返し実行される(ステップS1706→S1701)。
以上により、以下の効果を奏する。
アプリケーションの多重化関係を例えば、アプリ名、サブネット、トランザクションコンテキスト、トランザクション情報を組み合わせて自動的に検出することが可能となる。
多重化アプリの一部が停止した際に、その状況に合ったアラートを発生させるように設定できるため、運用管理者が障害の重大性に合った措置を選択することが可能となる。
多くの多重化手法に対応できるため、既存のITシステムにすでに多重化手法を導入していても、多重化アプリを検出する製品を利用することが可能となる。
図18は、従来のアラート通知例と、本実施形態で多重化アプリを検出している場合のアラート通知例の違いの説明図である。従来、Webサービス利用者からの要求に対して、Webサーバ,アプリケーションサーバ,データベースサーバが連携して、利用者へ応答するまでを一つのITサービス(または業務)と捉え、管理コンソールでITサービスの稼動状態を表示できる。図中のServiceAとServiceBはそれぞれITサービスを表し、互いに多重関係になっており、ServiceAとServiceBを構成するアプリの中の一部が多重化アプリになっているとする。このとき、この環境ではServiceBが停止してもServiceAが稼動していれば、ITサービスは継続できる。
従来製品の管理コンソールでは、図18(a)に示されるように、ServiceB(ITサービスB)が停止すると、多重化されているServiceAが稼動中でもサービスがストップしたというアラートを通知してしまう。
それに対し、本実施形態の新機能で多重化アプリが検出されている場合、図18(b)に示されるように、ITサービスがグルーピングされて表示でき、その中の一部分だけが停止した場合は、警告レベルの通知に止めることができる。さらに、どこが問題なのかを掘り下げて調べることができ、ServiceBが停止し、ServiceAが稼動していることが確認できる。 図19は、図17のステップS1703の第1の実施形態のコンピュータによる全体処理を示すフローチャートである。
図19のうち、ステップS1903、S1905、S1907、S1909で手段B,C,D,Eのどの機能を利用するかは、ITサービスを監視する人が判断し、システムに設定する。ITシステムの構成を変更した際は、利用する手段を変更する。
図15または図16の監視対象サーバ群1505の例として図4のようなITシステムを監視中の場合について、図19のフローチャートを詳細に説明する。
まず、CMDB1504から、コンテナアプリ名とデプロイドアプリ名が一致するアプリケーションの組み合わせ(多重化アプリ候補群)が参照される(ステップS1901)。図20は、多重化アプリ候補のデータ構成例を示す。多重化アプリ候補は、コンテナアプリ名とデプロイドアプリ名が一致するものごとに複数ある。なお、CMDB1504では、各コンテナアプリをInstanceCIというデータ単位で管理している。CIは、ConfigurationItemの略である。各InstanceCIには、識別子としてInstanceIDが付与される。図20において、Ins1,Ins2,Ins3,Ins4の各InstanceIDで示されるエントリは、コンテナアプリ名とデプロイドアプリ名が一致するため、多重化アプリ候補と判断される。 次に、手段B,手段C,手段D,手段Eのうちどの手段を利用するかを、特には図示しない設定情報から読み取る(ステップS1902)。
次に、手段Bを使うか否かを判定する(ステップS1903)。
手段Bを使うと判定した場合には、ステップS1901で得られた多重化アプリ候補群のうち、サブネットが一致しないものは除外する(ステップS1904)。ステップS1904の詳細処理であるサブフロー1は、図21、図22を使って後述する。
ステップS1903で手段Bを使わないと判定した場合またはステップS1904の後、手段Cを使うか否かを判定する(ステップS1905)。
手段Cを使うと判定した場合には、ステップS1901で得られた多重化アプリ候補群のうち、トランザクションコンテキストが一致しないものは除外する(ステップS1906)。ステップS1906の詳細処理であるサブフロー2は、図23、図24を使って後述する。
ステップS1905で手段Cを使わないと判定した場合またはステップS1906の後、手段Dを使うか否かを判定する(ステップS1907)。
手段Dを使うと判定した場合には、ステップS1901で得られた多重化アプリ候補群のうち、トランザクション情報が一致しないものは除外する(ステップS1908)。ステップS1908の詳細処理であるサブフロー3は、図25から図27を使って後述する。
ステップS1907で手段Dを使わないと判定した場合またはステップS1908の後、手段Eを使うか否かを判定する(ステップS1909)。
手段Eを使うと判定した場合には、アプリ名が部分一致、包含関係にある多重化アプリを検出する(ステップS1910)。ステップS1910の詳細処理である補助手順フローおよびサブフロー4,5は、図28から図38を使って後述する。
ステップS1909で手段Eを使わないと判定した場合またはステップS1910の後、検出した多重化アプリをCMDB1504に登録する(ステップS1911)。登録の仕方としては、互いに多重関係にあるデプロイドアプリまたはコンテナアプリのエントリに、共通の値として生成された多重識別用のIDを付与する等が考えられる。その後、図19のフローチャートの処理、すなわち図17のステップS1703の処理を終了する。
次に、図19のステップS1904のサブネットによる篩い分けの処理の詳細について、図21のサブフロー1により説明する。
ここでは、図19のステップS1901で得られた多重化アプリ候補群について、ステップS2101からS2104までのループ処理によって、以下の判定が繰り返し実行される。すなわち、ステップS2102にて、サブネットが一致する候補があるか否かが判定される。
そして、ステップS2102の繰返しにおいて、サブネットが一致する候補がないと判定される毎に、不一致のエントリが多重化アプリ候補から除外される(ステップS2103)。
今、例えば前述した図20の多重化アプリ候補の場合を考える。
処理1(ステップS2102):リストの上から順番に各候補のサブネットアドレスを、各候補のIPアドレスとサブネットマスクの論理積から求める。具体例として、Ins1のサブネットアドレス=192.168.0.0 && 255.255.255.0=192.168.0.0となる。同様に、Ins2およびIns3=192.168.0.0,Ins4=192.168.1.0となる。
処理2(ステップS2102):他の候補を上から順番にサブネットアドレスが一致する候補が見つかるまで比較する。一致する候補が見つかれば、ステップS2104に移って次のループへ移動する。一つも見つからなければステップS2103へ進む。具体例として、Ins1の場合、まずIns2とサブネットアドレスを比較し、共にサブネットアドレスが192.168.0.0のため、次のループへ移動する。Ins2,Ins3のときは上から順番に比較すると最初のIns1とサブネットアドレスが一致するため、次のループへ進む。一方、Ins4,Ins1,Ins2,Ins3とサブネットアドレスが一致しないため、ステップS2103へ進む。
処理3(ステップS2103):該当する候補を除外する。具体例として、Ins4を多重化アプリ候補から除外し、ステップS2104へ進む。
処理4(ステップS2104):全ての候補について処理が完了したら終了する。
以上の処理の結果、図20では、図22に示されるように、Ins4のみサブネットが192.168.1.0のため、多重化アプリの候補から除外される。
これにより、これ以降の処理をする対象を減らせる。後の手順でのCMDB1504へのアクセスが縮小でき、データ量が多い際の性能劣化を防げる。
次に、図19のステップS1906のトランザクションコンテキストによる篩い分け処理の詳細について、図23のサブフロー2により説明する。
ここでは、図19のステップS1901で得られた多重化アプリ候補群について、ステップS2301からS2304までのループ処理によって、以下の判定が繰り返し実行される。すなわち、ステップS2302にて、他の候補と前アプリ名、後アプリ名が一致する候補があるか否かが判定される。
そして、ステップS2302の繰返しにおいて、一致する候補がないと判定される毎に、不一致のエントリが多重化アプリ候補から除外される(ステップS2303)。
今、例えば前述した図20の多重化アプリ候補について、トランザクションコンテキストが図24のデータ構成例のようにして得られる。
処理1(ステップS2302):トランザクションコンテキストのデータにおいて、リストの上から順番に前アプリ名、後アプリ名を読み込む。具体例として、Ins1,Ins2では、前アプリがApache、後アプリがSymfowareである。また、Ins3は、前アプリがIIS、後アプリがMySQLである。
処理2(ステップS2302):他の候補と前アプリ名、後アプリ名が一致するかどうかを評価する。一致する候補が見つかれば、ステップS2304に移って次のループへ移動する。一つも見つからなければステップS2303へ進む。具体例として、Ins1とIns2は、前アプリと後アプリがそれぞれ一致しているため、次のループへ進む。Ins3は、前アプリ名と後アプリ名が一致する候補が見つからないため、ステップS2303へ進む。
処理3(ステップS2303):該当する候補を除外する。具体例として、Ins3を多重化アプリ候補から除外し、ステップS2304へ進む。
処理4(ステップS2304):全ての候補について処理が完了したら終了する。
以上の処理により、図24では、Ins3は前アプリがIIS、後アプリがMySQLのため前後アプリが他の候補と一致せずに、除外される。
ここで、アプリ名には、コンテナアプリ名かデプロイドアプリ名、コンテナアプリ名とデプロイドアプリ名両方が使える。監視対象サーバ内に、多重化アプリ以外にコンテナアプリ名が一致するアプリが無ければ、コンテナアプリ名のみで多重化アプリを検出できる。そのため、通常はコンテナアプリ名だけを使えばよい。しかし、コンテナアプリ名が一致しているアプリがあるような環境の場合は、デプロイドアプリ名も使う必要がある。さらに、コンテナアプリは別々だが、その中のデプロイドアプリのみ多重化しているような、特殊な運用形態では、デプロイドアプリのみを使う方法を選択する必要がある。図24ではコンテナアプリ名のみの例を示したが、さらに、デプロイドアプリ名を比較に使えば、より詳しい比較が行える。
次に、図19のステップS1908のトランザクション情報による篩い分け処理であるサブフロー3の詳細について、図25のサブフロー3により説明する。
ここでは、図19のステップS1901で得られた多重化アプリ候補群について、ステップS2501からS2504までのループ処理によって、以下の判定が繰り返し実行される。すなわち、ステップS2502にて、他の候補と受信トランザクションの要求メッセージと応答メッセージ、送信トランザクションの要求メッセージと応答メッセージが一致する候補があるか否かが判定される。
そして、ステップS2502の繰返しにおいて、一致する候補がないと判定される毎に、不一致のエントリが多重化アプリ候補から除外される(ステップS2503)。
今、例えば前述した図20の多重化アプリ候補について、トランザクション情報が図26のデータ構成例のようにして得られる。
処理1(ステップS2502):トランザクション情報のデータにおいて、リストの上から順番に要求メッセージ、応答メッセージを読み込む。具体例として、図26(a)において、Ins1,Ins2は、要求メッセージが、受信トランザクションではAppAを実行、送信トランザクションでは顧客データを参照となっている。また、応答メッセージが、受信トランザクションでは顧客ページ、送信トランザクションでは顧客データとなっている。Ins3は、要求メッセージが、受信トランザクションではAppBを実行、送信トランザクションでは社員データ参照となっている。また、応答メッセージが、受信トランザクションでは社員ページ、送信トランザクションでは社員データとなっている。
処理2(ステップS2502):他の候補とトランザクション情報が一致するかどうかを評価する。一致する候補が見つかれば、ステップS2504に移って次のループへ移動する。一つも見つからなければステップS2503へ進む。具体例として、図26(b)は、図26(a)の要求メッセージの詳細である。図26(b)において、「REQUEST」の後ろに書かれている文字列が要求メッセージで、「RESPONSE」の後ろに書かれている文字列が応答メッセージとなる。トランザクションは、実行時に毎回変化するため、"AppAを実行"や"AppBを実行"のようにパラメータの部分は変数名だけを見て、値は比較対象に含めない。トランザクション情報が一致するかどうかは、要求メッセージ、応答メッセージそれぞれについて、文字列比較を行い判定する。例えば、Ins1とIns2は、要求メッセージと応答メッセージが一致するため、次のループへ進む。Ins3は、要求メッセージと応答メッセージが一致する候補が見つからないため、ステップS2503へ進む。
処理3(ステップS2503):該当する候補を除外する。具体例として、Ins3を多重化アプリ候補から除外し、ステップS2504へ進む。
処理4(ステップS2504):全ての候補について処理が完了したら終了する。
図27は、トランザクション情報による多重化アプリの特定の説明図である。以上の処理により、例えば図27のアプリケーションサーバApp1とApp2について、受信トランザクションは宛て先IP以外が一致しており、送信トランザクションは送信元IP以外が一致しているため(違うのは自ホストのIPアドレスだけ)、多重化アプリとする。一方、アプリケーションサーバApp3は、受信トランザクション、送信トランザクションともに他の候補と一致しないため、多重化アプリ候補から除外する。
次に、図19のステップS1910のアプリ名が部分一致、包含関係にある多重化アプリを検出する処理の詳細について、図28のフローチャートにより説明する。
この補助手順は、アプリ名の一致では検出できない多重化アプリを検出するために実施される。通常、多重化するには、コンピュータの構成やネットワークの構成、アプリケーションの構成は均一化される。このため、本手順は、特殊なケースを検出する場合に行う。
図28のうち、ステップS2803、S2805で手段E−1,E−2のどちらの機能を利用するかは、ITサービスを監視する人が判断し、システムに設定する。ITシステムの構成を変更した際は、利用する手段を変更する。
まず、CMDB1504から、コンテナアプリ名が一致するアプリケーションの組み合わせが参照される(ステップS2801)。
次に、手段E−1,手段E−2のうちどちらの手段を利用するかを、特には図示しない設定情報から読み取る(ステップS2802)。
次に、手段E−1を使うか否かを判定する(ステップS2803)。
手段E−1を使うと判定した場合には、ステップS2801で得られたコンテナアプリ名が一致するアプリケーションの組み合わせのうち、トランザクションコンテキストが一致し、かつデプロイドアプリ名が部分一致または包含するものを検出する(ステップS2804)。
ステップS2803で手段E−1を使わないと判定した場合またはステップS2804の後、手段E−2を使うか否かを判定する(ステップS2805)。
手段E−2を使うと判定した場合には、ステップS2801で得られたコンテナアプリ名が一致するアプリケーションの組み合わせのうち、トランザクション情報が一致し、かつデプロイドアプリ名が部分一致または包含するものを検出する(ステップS2806)。
ステップS2805で手段Eを使わないと判定した場合またはステップS2806の後、部分一致または包含関係にあるアプリケーションを多重化アプリとして検出する(ステップS2807)。その後、図28のフローチャートの処理、すなわち図19のステップS1910の処理を終了する。
図29は、アプリ名が部分一致する多重化アプリの検出動作を模式的に表す説明図である。図29に対応して、ステップS2801(図28)で参照される多重化アプリ候補データ(InstanceCI)、トランザクションコンテキストデータ、およびトランザクション情報データは、それぞれ図30の(a)、(b)、および(c)で示される。これらはそれぞれ、前述した図20、図24、図26の各データに対応している。図29において、Web1、App1、DB1というホスト名のサーバを通るトランザクションとWeb1、App2、DB1を通るトランザクションがある。この中で、間にあるApp1とApp2はAppAのみ多重化しており、AppBは他の目的のためにデプロイされている。図29は、前述した図9、図10、および図11に対応する。図28に示されるフローチャートにより、トランザクションコンテキスト、または、トランザクション情報により、この環境から多重化アプリを検出する。
図31は、アプリ名が包含関係の多重化アプリの検出動作を模式的に表す説明図である。図31に対応して、ステップS2801(図28)で参照される多重化アプリ候補データ(InstanceCI)、トランザクションコンテキストデータ、およびトランザクション情報データは、それぞれ図32の(a)、(b)、および(c)で示される。図30の場合と同様に、これらはそれぞれ、前述した図20、図24、図26の各データに対応している。図31において、図29の場合と同様に、Web1、App1、DB1というホスト名のサーバを通るトランザクションとWeb1、App2、DB1を通るトランザクションがある。この中で、間にあるApp1とApp2はAppAのみ多重化しており、AppBおよびAppCは他の目的のためにデプロイされている。図31は、前述した図12、図13、および図14に対応する。図28に示される補助手順のフローチャートにより、トランザクションコンテキスト、または、トランザクション情報により、この環境から多重化アプリを検出する。
次に、図28のステップS2804のトランザクションコンテキストを用いた手段E−1の処理の詳細について、図33のサブフロー4により説明する。
ここでは、図28のステップS2801で得られたデータについて、まず、ステップS3301からS3304までのループ処理によって、以下の判定が繰り返し実行される。すなわち、ステップS3302にて、コンテナアプリの前アプリと後アプリが他のコンテナアプリと一致する候補があるか否かが判定される。
そして、ステップS3302の繰返しにおいて、一致する候補があると判定される毎に、一致のエントリが多重化アプリ候補に加えられる(ステップS3303)。
続いて、上述のループ処理によって生成された全ての多重化アプリ候補群に対して、ステップS3305からS3308までのループ処理によって、以下の判定が繰り返し実行される。すなわち、ステップS3306にて、デプロイドアプリが他のデプロイドアプリと部分一致または包含関係にあるか否かが判定される。
そして、ステップS3306の繰返しにおいて、部分一致または包含関係が検出される毎に、それらの関係を有するアプリケーションが多重化アプリとして検出される(ステップS3307)。
今、例えば図29の部分一致関係を有する図30(a)のInstanceCI、および図30(b)のトランザクションコンテキストのデータ構成例を考える。
処理1(ステップS3302):InstanceCI、およびトランザクションコンテキストのリストの項目を上から順番に読み込む。具体例として、Ins1,Ins2ともに、前アプリがApache、前アプリのデプロイドアプリが顧客ページ、コンテナアプリ名がInterstage、後アプリがSymfoware、後アプリのデプロイドアプリが顧客データというデータが得られる。デプロイドアプリ名のみIns1はAppAとAppB、Ins2はAppAとAppCというデータが得られる。
処理2(ステップS3302):コンテナアプリ、前アプリ、後アプリが一致する候補があるかどうか評価する。一致する候補が見つからなければ、ステップS3304に移って次のループへ移動する。一致する候補が見つかればステップS3303へ進む。具体例として、Ins1について一致する候補を探すと、Ins2がコンテナアプリ、前アプリ、後アプリが一致するため、ステップS3303へ進む。
処理3(ステップS3303):該当した候補を多重化アプリ候補群に加える。具体例として、Ins1を同じコンテナアプリ、前アプリ、後アプリを持つグループに加える。グループが無ければ作成する。その後、ステップS3304へ進む。
処理4(ステップS3305→S3306):これまでの手順で判明した多重化アプリ候補群を上から順に読み出す。具体例として、Ins1とIns2が含まれたグループが一つ作成されている。このグループの一つ目のIns1から順に読み出す。もし、別のグループがある場合は、前のグループが処理4を終えてから別のグループの処理4を実行する。
処理5(ステップS3306):他の候補とデプロイドアプリが部分一致または包含関係にあるかを評価する。該当する候補が見つからなければ、ステップS3308に移って次のループへ移動する。該当する候補が見つかればステップS3307へ進む。具体例として、Ins1は、デプロイドアプリAppAとAppBを持つ。ここで、他の候補と比較を行うと、Ins2がデプロイドアプリAppAとAppCを持ち、AppAのみが一致する部分一致の関係であることが検出できる。部分一致する候補が見つかったため、ステップS3307へ進む。Ins2についても同様に部分一致が検出できるため、ステップS3307へ進む。
処理6(ステップS3307):該当する候補を多重化アプリとする。具体例として、Ins1,Ins2を多重化アプリとして登録する。
処理7(ステップS3308):全ての候補について処理が完了したら終了する。
以上の処理により、例えば図30(a)のInstanceCI、および図30(b)のトランザクションコンテキストを考える。この場合、前アプリはコンテナアプリ名がApacheでデプロイドアプリ名が顧客ページ、後アプリはコンテナアプリ名がSymfowareでデプロイドアプリ名が顧客データのため、前アプリ名、後アプリ名は一致している。App1とApp2を比較すると、コンテナアプリ名はどちらもInterstageで、デプロイドアプリ名はAppAはどちらもあるが、AppBはApp1のみ、AppCはApp2のみしかない。以上から、AppAは多重化アプリの要素で、AppBとAppCは他の目的のためのアプリと分かる。
次に、例えば図31の包含関係を有する図32(a)のInstanceCI、および図32(b)のトランザクションコンテキストのデータ構成例を考える。
処理1(ステップS3302):InstanceCI、およびトランザクションコンテキストのリストの項目を上から順番に読み込む。具体例として、Ins1,Ins2ともに、前アプリがApache、前アプリのデプロイドアプリが顧客ページ、コンテナアプリ名がInterstage、後アプリがSymfoware、後アプリのデプロイドアプリが顧客データというデータが得られる。デプロイドアプリ名のみIns1はAppAとAppB、Ins2はAppAというデータが得られる。
処理2(ステップS3302):コンテナアプリ、前アプリ、後アプリが一致する候補があるかどうか評価する。一致する候補が見つからなければ、ステップS3304に移って次のループへ移動する。一致する候補が見つかればステップS3303へ進む。具体例として、Ins1について一致する候補を探すと、Ins2がコンテナアプリ、前アプリ、後アプリが一致するため、ステップS3303へ進む。
処理3(ステップS3303):該当した候補を多重化アプリ候補群に加える。具体例として、Ins1を同じコンテナアプリ、前アプリ、後アプリを持つグループに加える。グループが無ければ作成する。その後、ステップS3304へ進む。
処理4(ステップS3305→S3306):これまでの手順で判明した多重化アプリ候補群を上から順に読み出す。具体例として、Ins1とIns2が含まれたグループが一つ作成されている。このグループの一つ目のIns1から順に読み出す。もし、別のグループがある場合は、前のグループが処理4を終えてから別のグループの処理4を実行する。
処理5(ステップS3306):他の候補とデプロイドアプリが部分一致または包含関係にあるかを評価する。該当する候補が見つからなければ、ステップS3308に移って次のループへ移動する。該当する候補が見つかればステップS3307へ進む。具体例として、Ins1は、デプロイドアプリAppAとAppBを持つ。ここで、他の候補と比較を行うと、Ins2がデプロイドアプリAppAを持ち、AppAのみが一致する部分一致の関係であることが検出できる。部分一致する候補が見つかったため、ステップS3307へ進む。Ins2についても同様に部分一致が検出できるため、ステップS3307へ進む。
処理6(ステップS3307):該当する候補を多重化アプリとする。具体例として、Ins1,Ins2を多重化アプリとして登録する。
処理7(ステップS3308):全ての候補について処理が完了したら終了する。
以上の処理により、例えば図32(a)のInstanceCI、および図32(b)のトランザクションコンテキストを考える。この場合、前アプリはコンテナアプリ名がApacheでデプロイドアプリ名が顧客ページ、後アプリはコンテナアプリ名がSymfowareでデプロイドアプリ名が顧客データのため、前アプリ名、後アプリ名は一致している。App1とApp2を比較すると、コンテナアプリ名はどちらもInterstageで、デプロイドアプリ名はAppAはどちらもあるが、AppBはApp1のみしかない。以上から、AppAは多重化アプリの要素で、AppBは他の目的のためのアプリと分かる。
次に、図28のステップS2806のトランザクション情報を用いた手段E−2の処理の詳細について、図34のサブフロー4により説明する。
ここでは、図28のステップS2801で得られたデータについて、まず、ステップS3401からS3404までのループ処理によって、以下の判定が繰り返し実行される。すなわち、ステップS3402にて、他の候補と受信トランザクションの要求メッセージと応答メッセージ、送信トランザクションの要求メッセージと応答メッセージが一致する候補があるか否かが判定される。
そして、ステップS3402の繰返しにおいて、一致する候補があると判定される毎に、一致のエントリが多重化アプリ候補に加えられる(ステップS3403)。
続いて、上述のループ処理によって生成された全ての多重化アプリ候補群に対して、ステップS3405からS3408までのループ処理によって、以下の判定が繰り返し実行される。すなわち、ステップS3406にて、デプロイドアプリが他のデプロイドアプリと部分一致または包含関係にあるか否かが判定される。
そして、ステップS3406の繰返しにおいて、部分一致または包含関係が検出される毎に、それらの関係を有するアプリケーションが多重化アプリとして検出される(ステップS3407)。
今、例えば図29の部分一致関係を有する図30(a)のInstanceCI、および図30(c)のトランザクション情報のデータ構成例を考える。
処理1(ステップS3402):InstanceCI、およびトランザクション情報のリストの項目を上から順番に読み込む。具体例として、Ins1,Ins2ともに、コンテナアプリ名がInterstageというデータが取り出せる。また、要求メッセージの受信トランザクションがAppAを実行、送信トランザクションが顧客データ参照、応答メッセージが受信トランザクションは顧客ページ、送信トランザクションが顧客データというデータが取り出せる。デプロイドアプリ名のみIns1はAppAとAppB、Ins2はAppAとAppCというデータが得られる。
処理2(ステップS3402):要求メッセージと応答メッセージが一致する候補があるかどうか評価する。一致する候補が見つからなければ、ステップS3404に移って次のループへ移動する。一致する候補が見つかればステップS3403へ進む。具体例として、Ins1について一致する候補を探すと、Ins2が要求メッセージと応答メッセージが一致するため、ステップS3403へ進む。
処理3(ステップS3403):該当した候補を多重化アプリ候補群に加える。具体例として、Ins1を同じ要求メッセージ、応答メッセージを持つグループに加える。グループが無ければ作成する。その後、ステップS3404へ進む。
処理4(ステップS3405→S3406):これまでの手順で判明した多重化アプリ候補群を上から順に読み出す。具体例として、Ins1とIns2が含まれたグループが一つ作成されている。このグループの一つ目のIns1から順に読み出す。もし、別のグループがある場合は、前のグループが処理4を終えてから別のグループの処理4を実行する。
処理5(ステップS3406):他の候補とデプロイドアプリが部分一致または包含関係にあるかを評価する。該当する候補が見つからなければ、ステップS3408に移って次のループへ移動する。該当する候補が見つかればステップS3407へ進む。具体例として、Ins1は、デプロイドアプリAppAとAppBを持つ。ここで、他の候補と比較を行うと、Ins2がデプロイドアプリAppAとAppCを持ち、AppAのみが一致する部分一致の関係であることが検出できる。部分一致する候補が見つかったため、ステップS3407へ進む。Ins2についても同様に部分一致が検出できるため、ステップS3407へ進む。
処理6(ステップS3407):該当する候補を多重化アプリとする。具体例として、Ins1,Ins2を多重化アプリとして登録する。
処理7(ステップS3408):全ての候補について処理が完了したら終了する。
以上の処理により、例えば図30(a)のInstanceCI、および図30(c)のトランザクションコンテキストを考える。この場合、トランザクション情報でIns1とIns2は同じIPアドレスから要求を受け、同じ宛て先IPのテーブルを参照しており、要求メッセージと応答メッセージが一致するため多重化アプリと分かる。そこで、Ins1とIns2のInstanceCIを比較すると、AppAは共通してデプロイされているため多重化アプリと分かり、AppBやAppCは多重化アプリでは無いと分かる。
次に、例えば図31の部分一致関係を有する図32(a)のInstanceCI、および図32(c)のトランザクション情報のデータ構成例を考える。
処理1(ステップS3402):InstanceCI、およびトランザクション情報のリストの項目を上から順番に読み込む。具体例として、Ins1,Ins2ともに、コンテナアプリ名がInterstageというデータが取り出せる。また、要求メッセージの受信トランザクションがAppAを実行、送信トランザクションが顧客データ参照、応答メッセージが受信トランザクションは顧客ページ、送信トランザクションが顧客データというデータが取り出せる。デプロイドアプリ名のみIns1はAppAとAppB、Ins2はAppAというデータが得られる。
処理2(ステップS3402):要求メッセージと応答メッセージが一致する候補があるかどうか評価する。一致する候補が見つからなければ、ステップS3404に移って次のループへ移動する。一致する候補が見つかればステップS3403へ進む。具体例として、Ins1について一致する候補を探すと、Ins2が要求メッセージと応答メッセージが一致するため、ステップS3403へ進む。
処理3(ステップS3403):該当した候補を多重化アプリ候補群に加える。具体例として、Ins1を同じ要求メッセージ、応答メッセージを持つグループに加える。グループが無ければ作成する。その後、ステップS3404へ進む。
処理4(ステップS3405→S3406):これまでの手順で判明した多重化アプリ候補群を上から順に読み出す。具体例として、Ins1とIns2が含まれたグループが一つ作成されている。このグループの一つ目のIns1から順に読み出す。もし、別のグループがある場合は、前のグループが処理4を終えてから別のグループの処理4を実行する。
処理5(ステップS3406):他の候補とデプロイドアプリが部分一致または包含関係にあるかを評価する。該当する候補が見つからなければ、ステップS3408に移って次のループへ移動する。該当する候補が見つかればステップS3407へ進む。具体例として、Ins1は、デプロイドアプリAppAとAppBを持つ。ここで、他の候補と比較を行うと、Ins2がデプロイドアプリAppAを持ち、AppAのみが一致する部分一致の関係であることが検出できる。包含関係の候補が見つかったため、ステップS3407へ進む。Ins2についても同様に包含関係が検出できるため、ステップS3407へ進む。
処理6(ステップS3407):該当する候補を多重化アプリとする。具体例として、Ins1,Ins2を多重化アプリとして登録する。
処理7(ステップS3408):全ての候補について処理が完了したら終了する。
以上の処理により、例えば図32(a)のInstanceCI、および図32(c)のトランザクションコンテキストを考える。この場合、トランザクション情報でIns1とIns2は同じIPアドレスから要求を受け、同じ宛て先IPのテーブルを参照しており、要求メッセージと応答メッセージが一致するため多重化アプリと分かる。そこで、Ins1とIns2のInstanceCIを比較すると、AppAは共通してデプロイされているため多重化アプリと分かり、AppBは多重化アプリでは無いと分かる。
以上の方法で、デプロイドアプリが部分一致する場合や包含関係にある多重化アプリを検出することができる。
図35は、図17のステップS1704の第2の実施態様のコンピュータによる処理を示すフローチャートである。
まず、CMDB1504に登録されている全てのITサービスが参照される(ステップS3501)。
次に、ステップS3501で得られた全てのITサービスについて、まず、ステップS3502からS3505までのループ処理によって、以下の判定が繰り返し実行される。すなわち、ステップS3503にて、処理対象のITサービスについて、他のITサービスとInstanceID(図20)が比較される。これにより、多重化アプリ以外のアプリケーションが一致するITサービスがあるかどうかが評価される。今、ステップS3501で得られる各ITサービスでは、図36に示されるように、サービスを構成するアプリケーションの連鎖が、各アプリケーションに対応するInstanceIDのリストとして表現されている(後述の図44参照)。更に、CMDB1504には、例えば図20として示されるように、上記各InstanceIDをキーとする各アプリケーションのレコード情報が登録されている。そして、各アプリケーションのレコード情報には、それが多重化アプリであるか否かを示す情報および多重化アプリを識別する情報が、図17のステップS1703の第1の実施形態における図19のステップS1911によって登録されている。ステップS3503では、このレコード情報が参照されながら、処理対象のITサービスを構成するInstanceIDのリストのうち、多重化アプリに対応するInstanceID以外のIDが、他のITサービスと一致するか否かが評価される。
この結果、一致するITサービスがあると判定された場合には、ステップS3504にて、処理対象のITサービスが、一致したITサービスが属するITサービスグループ候補と同じITサービスグループ候補に加えられる。ITサービスグループ候補が無ければ新しく作成され、処理対象ITサービス、および一致したITサービスが、新規のITサービスグループ候補に加えられる。今、例えば図36に示されるように、ServiceA,ServiceB,ServiceCというようなITサービスを考える。上述のループ処理の結果、ServiceAとServiceBは、多重化アプリB1,B2以外の前後のアプリケーションAおよびCが、互いに一致する。したがって、まず、ServiceAが、ServiceBが属するITサービスグループ候補に加えられる。ServiceB,ServiceCについても同様に比較が行われる。
続いて、上述のループ処理で得られたITサービスグループ候補毎に、ステップS3506からS3510までのループ処理によって、以下の判定が繰り返し実行される。すなわち、ステップS3507にて、他のITサービスグループ候補の多重化アプリ部と互いに多重関係になっているものがあるか否かが判定される。
この結果、多重関係になっているものがあると判定された場合には、多重関係にあるものと同じITサービスグループに、処理対象のITサービスグループ候補が加えられる(ステップS3508)。
一方、多重関係になっているものがないと判定された場合には、ITサービスグループ候補から除外される(ステップS3509)。
以上の処理により、多重化アプリを含んだ、多重関係にあるITサービスが、一つに束ねられる。この結果、図17のステップS1705にて、前述した図18に示されるようなアラート表示が実現される。
図37は、図17のステップS1706の第3の実施形態のコンピュータによる処理を示すフローチャートである。
まず、通常のITシステムの監視の結果、ITサービスのダウンが検出される(ステップS3701)。
次に、CMDB1504が参照されることにより、ダウンが検出されたITサービスについて、多重関係にあるITサービスが稼働しているか否かが判定される。多重関係にあるか否かは、前述した図35のフローチャートで示される第2の実施形態によってITサービスグループとして検出されている。
この判定の結果、多重関係にあるITサービスが稼働していると判定された場合には、通常よりもインパクトが小さいレベルのアラートを発生させる(ステップS3703)。例えば図36に示されるようなServiceA,ServiceB,ServiceCというようなITサービスが稼働しており、ServiceAとServiceBが多重関係にあることが検出されている。ここで、ServiceBのITサービスのみがダウンした場合には、ステップS3703によって、図38(c)に示されるような、通常よりもインパクトが小さいウォーニングレベルのアラートが発生されることになる。
一方、多重関係にある他のITサービスも稼働していないと判定された場合には、通常よりもインパクトが大きいレベルのアラートを発生させる(ステップS3704)。上述の例で、ServiceBがダウンしたときにServiceAも既にダウンしている場合には、図38(b)に示されるような、通常よりもインパクトが大きいレベルのアラートが発生されることになる。
更に、多重関係にあるITサービスが存在しないと判定された場合には、従来通りのアラートを発生させる(ステップS3705)。上述の例で、ServiceAがダウンしたときにServiceBはもともと存在しない場合には、図38(a)に示される通常表示がなされる。 以上のようにして、第3の実施形態によって、多重状態に応じて適切なアラートを発することが可能となる。 上述した実施形態では、CMDB1504から必要に応じてコンテナアプリ名やデプロイドアプリ名が参照される。データを参照するためには、CMDB1504へデータ取得用のコマンドを送信し、XMLデータを受信する。以下にCMDBから取得されるデータの例を示す。なお、ここに載せてあるデータは、本実施形態の説明のために簡略化してある。
図39は、CMDB1504コンテナアプリの一覧を取得するコマンドの実行結果である。ns:Instanceというタグの中のtype="Interstage"となっているデータが2件あり、ここから、コンテナアプリであるInterstageが2件検出されていることが分かる。さらに、それぞれ、192.168.1.3と192.168.1.4のIPアドレスが割り振られているサーバにデプロイされていることが分かる。
図40は、CMDB1504からのサブネットアドレス取得データ例を示す図であり、CMDB1504から参照した構成情報の例になっている。このデータのIPアドレスと、コンテナアプリがデプロイされているサーバのIPアドレスをマッピングすることで、コンテナアプリのサブネットアドレスを特定できる。
図41と図42は、CMDB1504から取得したトランザクションコンテキストの例で、TransactionContextFromが前アプリ、TransactionContextLocalが間のコンテナアプリ、TransactionContextToが後アプリの情報になっている。TransactionContextLocalのidとコンテナアプリのidをマッピングすることで、コンテナアプリのトランザクションコンテキストを取得できる。前アプリ、後アプリのさらに前や後のアプリを追跡するには、前アプリ、後アプリ自身のTransactionContextを検出し、その中の前アプリか後アプリを取得する。例では、cmdb:itというタグのidの値が33のデータは、DB1のアプリのトランザクションコンテキストとなっている。このデータから、DB1の後アプリはDB2であることがわかる。
図43は、CMDB1504から取得したトランザクション情報の例で、このデータのns:TransactionInformation内のfromかtoの値と、コンテナアプリのIDとでマッピングを取り、コンテナアプリのトランザクション情報を見つける。
図44は、CMDB1504から取得したITサービスの例を示す図であり、ITサービスを構成するアプリケーションの連鎖が、各アプリケーションに対応するInstanceIDのリストとして表現されている。
図45は、上記実施形態のシステムを実現できるコンピュータのハードウェア構成の一例を示す図である。
図45に示されるコンピュータは、CPU4501、メモリ4502、入出力装置4503、外部記憶装置4505、可搬記録媒体4509が挿入される可搬記録媒体駆動装置4506、および通信ネットワーク4507を有し、これらがバス4508によって相互に接続された構成を有する。同図に示される構成は上記システムを実現できるコンピュータの一例であり、そのようなコンピュータはこの構成に限定されるものではない。
CPU4501は、当該コンピュータ全体の制御を行う。メモリ4502は、プログラムの実行、データ更新等の際に、外部記憶装置4505(或いは可搬記録媒体4509)に記憶されているプログラムまたはデータを一時的に格納するRAM等のメモリである。CUP4501は、プログラムをメモリ4502に読み出して実行することにより、全体の制御を行う。
入出力装置4503は、ユーザによるキーボードやマウス等による入力操作を検出し、その検出結果をCPU4501に通知し、CPU4501の制御によって送られてくるデータを表示装置や印刷装置に出力する。
外部記憶装置4505は、例えばハードディスク記憶装置である。主に各種データやプログラムの保存に用いられる。
可搬記録媒体駆動装置4506は、光ディスクやSDRAM、コンパクトフラッシュ(登録商標)等の可搬記録媒体4509を収容するもので、外部記憶装置4505の補助の役割を有する。
通信インターフェース4507は、例えばLAN(ローカルエリアネットワーク)またはWAN(ワイドエリアネットワーク)の通信回線を接続するための装置である。
本実施形態によるシステムは、本実施形態の機能を実現する各動作フローチャートに対応する各制御プログラムを、CPU4501が実行することで実現される。そのプログラムは、例えば外部記憶装置4505や可搬記録媒体4509に記録して配布してもよく、或いは通信インターフェース4507によりネットワークから取得できるようにしてもよい。各データは、例えば外部記憶装置4505またはメモリ4502上に記憶して運用される。また、メモリ4502上には、必要に応じて各制御プログラムを実行するためのワーク領域が展開される。
以上の実施形態に関して、更に以下の付記を開示する。
(付記1)
情報システムの構成情報と前記情報システム内で伝送される通信データとを含む情報を収集する手段と、
収集した前記構成情報と前記通信データとに基づいて、前記情報システム内のいずれかの監視対象装置にデプロイされているアプリケーションであって、アプリケーション名が一致するアプリケーションが複数存在すると判定した場合に、多重化されているアプリケーションが存在することを検出する多重化アプリ検出部と、
を備えることを特徴とするアプリケーションの多重関係を検出する装置。
(付記2)
前記収集手段は、前記監視対象装置から前記構成情報を収集する構成情報収集部と、
前記通信データを収集するトランザクション収集部と、からなり、さらに前記構成情報と前記通信データを格納する構成情報管理データベース、
を備えることを特徴とする付記1に記載のアプリケーションの多重関係を検出する装置。
(付記3)
前記多重化アプリ検出部は、
前記収集情報から、情報サービスを構成するための機能を提供する基盤ソフトウェアであるコンテナアプリの名称であるコンテナアプリ名、または前記コンテナアプリにデプロイされたプログラムやデータからなるデプロイドアプリの名称であるデプロイドアプリ名が一致するアプリケーションの組み合わせを、前記アプリケーション名が一致するアプリケーションとして抽出する、
ことを特徴とする付記1に記載のアプリケーションの多重関係を検出する装置。
(付記4)
前記多重化アプリ検出部は、
前記複数存在すると判定したアプリケーションについて、前記収集情報に含まれるインターネットプロトコルアドレスとサブネットマスクとに基づいてサブネットアドレスを算出し、
前記サブネットアドレスが一致するアプリケーションを、前記多重化されているアプリケーションとして検出する、
ことを特徴とする付記1に記載のアプリケーションの多重関係を検出する装置。
(付記5)
前記多重化アプリ検出部は、
前記複数存在すると判定したアプリケーションについて、前記収集情報から前記アプリケーションの前後に実行されるアプリケーションのアプリケーション名である前アプリ名と後アプリ名とを含むトランザクションコンテキストを抽出し、
前記トランザクションコンテキストを構成する前アプリ名と後アプリ名が一致するアプリケーションを、前記多重化されているアプリケーションとして検出する、
ことを特徴とする付記1に記載のアプリケーションの多重関係を検出する装置。
(付記6)
前記多重化アプリ検出部は、
前記複数存在すると判定したアプリケーションについて、前記収集情報からアプリケーションの送受信データである要求メッセージと応答メッセージを含むトランザクション情報を抽出し、
前記トランザクション情報を構成する前記要求メッセージと前記応答メッセージが一致するアプリケーションを、前記多重化されているアプリケーションとして検出する、
ことを特徴とする付記1に記載のアプリケーションの多重関係を検出する装置。
(付記7)
前記多重化アプリ検出部は、
前記収集情報から、情報サービスを構成するための機能を提供する基盤ソフトウェアであるコンテナアプリのコンテナアプリ名が一致するアプリケーションを抽出し、
前記コンテナアプリ名が一致するアプリケーションについて、前記収集情報から前記アプリケーションの前後に実行されるアプリケーションのコンテナアプリ名である前アプリ名と後アプリ名とを含むトランザクションコンテキストを抽出し、
前記コンテナアプリ名が一致するアプリケーションについて、前記収集情報から、前記コンテナアプリ名が一致するコンテナアプリにデプロイされたプログラムまたはデータであるデプロイドアプリのデプロイドアプリ名を抽出し、
前記コンテナアプリ名が一致するアプリケーション群について、前記トランザクションコンテキストを構成する前アプリ名と後アプリ名が一致するアプリケーションであって、かつ前記アプリケーション群に含まれる一つのアプリケーションのコンテナアプリ名に対応するデプロイドアプリ名の一部と前記アプリケーション群に含まれる他のアプリケーションのコンテナアプリ名に対応するデプロイドアプリ名の一部が一致する部分一致の関係、または前記アプリケーション群に含まれる一つのアプリケーションのコンテナアプリ名に対応するデプロイドアプリ名に前記アプリケーション群に含まれる他のアプリケーションのコンテナアプリ名に対応するデプロイドアプリ名が含まれる包含関係にあるアプリケーションを、前記多重化されているアプリケーションとして検出する、
ことを特徴とする付記1に記載のアプリケーションの多重関係を検出する装置。
(付記8)
前記多重化アプリ検出部は、
前記収集情報から、情報サービスを構成するための機能を提供する基盤ソフトウェアであるコンテナアプリのコンテナアプリ名が一致するアプリケーションを抽出し、
前記コンテナアプリ名が一致するアプリケーションについて、前記収集情報から前記アプリケーションの送受信データである要求メッセージと応答メッセージを含むトランザクション情報を抽出し、
前記コンテナアプリ名が一致するアプリケーションについて、前記収集情報から、前記コンテナアプリ名が一致するコンテナアプリにデプロイされたプログラムまたはデータであるデプロイドアプリのデプロイドアプリ名を抽出し、
前記コンテナアプリ名が一致するアプリケーション群について、前記トランザクションコンテキストを構成する前アプリ名と後アプリ名が一致するアプリケーションであって、、かつ前記アプリケーション群に含まれる一つのアプリケーションのコンテナアプリ名に対応するデプロイドアプリ名の一部と前記アプリケーション群に含まれる他のアプリケーションのコンテナアプリ名に対応するデプロイドアプリ名の一部が一致する部分一致の関係、または前記アプリケーション群に含まれる一つのアプリケーションのコンテナアプリ名に対応するデプロイドアプリ名に前記アプリケーション群に含まれる他のアプリケーションのコンテナアプリ名に対応するデプロイドアプリ名が含まれる包含関係にあるアプリケーションを、前記多重化されているアプリケーションとして検出する、
ことを特徴とする付記1に記載のアプリケーションの多重関係を検出する装置。
(付記9)
前記多重化アプリ検出部は、
前記複数存在すると判定したアプリケーションについて、前記収集情報に含まれるインターネットプロトコルアドレスとサブネットマスクとに基づいてサブネットアドレスを算出し、または前記収集情報から前記アプリケーションの前後に実行されるアプリケーションのアプリケーション名である前アプリ名と後アプリ名とを含むトランザクションコンテキストを抽出し、または前記収集情報からアプリケーションの送受信データである要求メッセージと応答メッセージを含むトランザクション情報を抽出し、
前記複数存在すると判定したアプリケーションにおいて、前記サブネットアドレスの一致、前記トランザクションコンテキストを構成する前アプリ名と後アプリ名の一致、または前記トランザクション情報を構成する前記要求メッセージと前記応答メッセージの一致の何れか1つ以上の一致の組合せにより、前記多重化されているアプリケーションを検出する、
ことを特徴とする付記1に記載のアプリケーションの多重関係を検出する装置。
(付記10)
前記多重化アプリ検出部は、
多重化アプリが実行されるサブネット、前記多重化アプリの前後に実行されるアプリケーション名に関するデータであるトランザクションコンテキスト、または前記多重化アプリの送受信データであるトランザクション情報のいずれか一つ以上の評価項目について一致するか否かを評価すること、
を特徴とする付記1記載のアプリケーションの多重関係を検出する装置。
(付記11)
前記収集情報に含まれる情報サービスを抽出し、前記抽出された情報サービスのうち、前記多重化アプリ検出部にて検出された多重化されているアプリケーション以外が一致する情報サービス同士を、情報サービスグループ候補として抽出し、前記抽出された情報サービスグループ候補のうち、同じ多重化されたアプリケーションを含む情報サービスグループ候補同士を、情報サービスグループとして抽出する多重関係情報サービス検出部をさらに備える、
ことを特徴とする付記1に記載のアプリケーションの多重関係を検出する装置。
(付記12)
前記情報サービスのサービスレベルの違反が検出されたときに、前記違反が検出された情報サービスが含まれる情報サービスグループに属する他の情報サービスの稼動状態に応じたレベルのアラートを出力する多重関係に基づくアラート出力部をさらに備える、
ことを特徴とする付記11に記載のアプリケーションの多重関係を検出する装置。
(付記13)
コンピュータが情報システムで実行されるアプリケーションの稼動状態を管理する方法において、
前記情報システムの構成情報と前記情報システム内で伝送される通信データとを含む情報を収集し、
収集した前記構成情報と前記通信データとに基づいて、前記情報システム内のいずれかの監視対象装置にデプロイされているアプリケーションであって、アプリケーション名が一致するアプリケーションが複数存在すると判定した場合に、多重化されているアプリケーションが存在することを検出する、
ことを特徴とするアプリケーションの多重関係を検出する方法。
(付記14)
情報システムで実行されるアプリケーションの稼動状態を管理するコンピュータに、
前記情報システムの構成情報と前記情報システム内で伝送される通信データとを含む情報を収集し、
収集した前記構成情報と前記通信データとに基づいて、前記情報システム内のいずれかの監視対象装置にデプロイされているアプリケーションであって、アプリケーション名が一致するアプリケーションが複数存在すると判定した場合に、多重化されているアプリケーションが存在することを検出する、
機能を実行させるためのプログラム。
(付記15)
情報システムで実行されるアプリケーションを管理するコンピュータに、
前記情報システムの構成情報と前記情報システム内で伝送される通信データとを含む情報を収集し、
収集した前記構成情報と前記通信データとに基づいて、前記情報システム内のいずれかの監視対象装置にデプロイされているアプリケーションであって、アプリケーション名が一致するアプリケーションが複数存在すると判定した場合に、多重化されているアプリケーションが存在することを検出する、
機能を実現させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。
1501 多重化アプリ検出部
1502 構成情報収集部
1503 トランザクション収集部
1504 CMDB
1505 監視対象サーバ群
1506 管理コンソール
1601 トランザクション管理/構成情報管理装置
1602 トランザクション分析/構成情報収集装置
1603 トランザクション収集装置
1604 スイッチ
1605 ファイアーウォール
1606 インターネット

Claims (16)

  1. 情報システムの構成情報を収集する収集手段と、
    収集した前記構成情報基づいて、前記情報システム内のいずれかの監視対象装置に導入される、情報サービスの提供に用いられる第1のアプリケーションと該第1のアプリケーションにデプロイされる第2のアプリケーションとの組み合わせについて、該第1のアプリケーションのアプリケーション名が一致し、且つ、第2のアプリケーションのアプリケーション名が一致する複数の組み合わせが存在する場合に、多重化されているアプリケーションが存在することを検出する検出手段と、
    を備えることを特徴とする検出装置。
  2. 情報システムの構成情報と前記情報システム内で伝送される通信データとを含む情報を収集する収集手段と、
    収集した前記構成情報と前記通信データとに基づいて、前記情報システム内のいずれかの監視対象装置にデプロイされるアプリケーションにアプリケーション名が一致するアプリケーションが複数存在する場合に、該複数存在すアプリケーションサブネットアドレスが一致するアプリケーションを、多重化されているアプリケーションとして検出する検出手段と
    を備えることを特徴とする検出装置。
  3. 前記検出手段は、前記複数存在すると判定したアプリケーションについて、収集した前記構成情報に含まれるインターネットプロトコルアドレスとサブネットマスクとに基づいてサブネットアドレスを算出して、算出した前記サブネットアドレスが一致するアプリケーションを、前記多重化されているアプリケーションとして検出する、
    ことを特徴とする請求項2記載の検出装置。
  4. 情報システムの構成情報と前記情報システム内で伝送される通信データとを含む情報を収集する収集手段と、
    収集した前記構成情報と前記通信データとに基づいて、前記情報システム内のいずれかの監視対象装置にデプロイされるアプリケーションにアプリケーション名が一致するアプリケーションが複数存在する場合に、該複数存在すアプリケーションについて、前記収集した情報からアプリケーションの前後に実行されるアプリケーションのアプリケーション名である前アプリ名と後アプリ名とを含むトランザクションコンテキストを抽出し、抽出したトランザクションコンテキストを構成する前アプリ名と後アプリ名が一致するアプリケーションを、多重化されているアプリケーションとして検出する検出手段と
    を備えることを特徴とする検出装置。
  5. 情報システムの構成情報と前記情報システム内で伝送される通信データとを含む情報を収集する収集手段と、
    収集した前記構成情報と前記通信データとに基づいて、前記情報システム内のいずれかの監視対象装置にデプロイされるアプリケーションにアプリケーション名が一致するアプリケーションが複数存在する場合に、該複数存在すアプリケーションについて、前記収集した情報からアプリケーションの送受信データである要求メッセージと応答メッセージを含むトランザクション情報を抽出し、抽出したトランザクション情報に含まれる該要求メッセージと応答メッセージが一致するアプリケーションを、多重化されているアプリケーションとして検出する検出手段と
    を備えることを特徴とする検出装置。
  6. 情報システムの構成情報と前記情報システム内で伝送される通信データとを含む情報を収集する収集手段と、
    前記収集した情報から、情報サービスを構成するための機能を提供する第1のアプリケーションのうちでアプリケーション名が一致する第1のアプリケーションを抽出し、該抽出した第1のアプリケーションについて、前記収集した情報から該抽出した第1のアプリケーションの前後に実行されるアプリケーションのアプリケーション名である前アプリ名と後アプリ名とを含むトランザクションコンテキストを抽出し、該抽出した第1のアプリケーションについて、前記収集した情報から、アプリケーション名が一致する第1のアプリケーションにデプロイされた第2のアプリケーションのアプリケーション名を抽出し、該抽出した第1のアプリケーションからなるアプリケーション群について、該抽出したトランザクションコンテキストを構成する前アプリ名と後アプリ名が一致する第1のアプリケーションであって、かつアプリケーション群に含まれる一つの第1のアプリケーションのアプリケーション名に対応する該第2のアプリケーションのアプリケーション名の一部とアプリケーション群に含まれる他の第1のアプリケーションのアプリケーション名に対応する該第2のアプリケーションのアプリケーション名の一部が一致する部分一致の関係、またはアプリケーション群に含まれる一つの第1のアプリケーションのアプリケーション名に対応する該第2のアプリケーションのアプリケーション名にアプリケーション群に含まれる他の第1のアプリケーションのアプリケーション名に対応する該第2のアプリケーションのアプリケーション名が含まれる包含関係にある第1のアプリケーションを、多重化されているアプリケーションとして検出する検出手段と
    を備えることを特徴とする検出装置。
  7. コンピュータが情報システムで実行されるアプリケーションの稼動状態を管理する方法において、
    前記情報システムの構成情報収集し、
    収集した前記構成情報基づいて、前記情報システム内のいずれかの監視対象装置に導入される、情報サービスの提供に用いられる第1のアプリケーションと該第1のアプリケーションにデプロイされる第2のアプリケーションとの組み合わせについて、該第1のアプリケーションのアプリケーション名が一致し、且つ、第2のアプリケーションのアプリケーション名が一致する複数の組み合わせが存在する場合に、多重化されているアプリケーションが存在することを検出する、
    ことを特徴とする検出方法。
  8. コンピュータが情報システムで実行されるアプリケーションの稼動状態を管理する方法において、
    前記情報システムの構成情報と前記情報システム内で伝送される通信データとを含む情報を収集し、
    収集した前記構成情報と前記通信データとに基づいて、前記情報システム内のいずれかの監視対象装置にデプロイされるアプリケーションにアプリケーション名が一致するアプリケーションが複数存在する場合に、該複数存在するアプリケーションのサブネットアドレスを算出し、算出したサブネットアドレスが一致するアプリケーションを、多重化されているアプリケーションとして検出する、
    ことを特徴とする検出方法。
  9. コンピュータが情報システムで実行されるアプリケーションの稼動状態を管理する方法において、
    前記情報システムの構成情報と前記情報システム内で伝送される通信データとを含む情報を収集し、
    収集した前記構成情報と前記通信データとに基づいて、前記情報システム内のいずれかの監視対象装置にデプロイされるアプリケーションにアプリケーション名が一致するアプリケーションが複数存在する場合に、該複数存在するアプリケーションについて、前記収集した情報から該アプリケーションの前後に実行されるアプリケーションのアプリケーション名である前アプリ名と後アプリ名とを含むトランザクションコンテキストを抽出し、抽出したトランザクションコンテキストを構成する前アプリ名と後アプリ名が一致するアプリケーションを、多重化されているアプリケーションとして検出する、
    ことを特徴とする検出方法。
  10. コンピュータが情報システムで実行されるアプリケーションの稼動状態を管理する方法において、
    前記情報システムの構成情報と前記情報システム内で伝送される通信データとを含む情報を収集し、
    収集した前記構成情報と前記通信データとに基づいて、前記情報システム内のいずれかの監視対象装置にデプロイされるアプリケーションにアプリケーション名が一致するアプリケーションが複数存在する場合に、該複数存在するアプリケーションについて、前記収集した情報から該アプリケーションの送受信データである要求メッセージと応答メッセージを含むトランザクション情報を抽出し、抽出したトランザクション情報に含まれる該要求メッセージと該応答メッセージが一致するアプリケーションを、多重化されているアプリケーションとして検出する、
    ことを特徴とする検出方法。
  11. コンピュータが情報システムで実行されるアプリケーションの稼動状態を管理する方法において、
    前記情報システムの構成情報と前記情報システム内で伝送される通信データとを含む情報を収集し、
    前記収集した情報から、情報サービスを構成するための機能を提供する第1のアプリケーションのうちでアプリケーション名が一致する第1のアプリケーションを抽出し、
    前記抽出した第1のアプリケーションについて、前記収集した情報から前記抽出した第1のアプリケーションの前後に実行されるアプリケーションのアプリケーション名である前アプリ名と後アプリ名とを含むトランザクションコンテキストを抽出し、
    前記抽出した第1のアプリケーションについて、前記収集した情報から、アプリケーション名が一致する第1のアプリケーションにデプロイされた第2のアプリケーションのアプリケーション名を抽出し、
    前記抽出した第1のアプリケーションからなるアプリケーション群について、前記抽出したトランザクションコンテキストを構成する前アプリ名と後アプリ名が一致する第1のアプリケーションであって、かつ該アプリケーション群に含まれる一つの第1のアプリケーションのアプリケーション名に対応する前記第2のアプリケーションのアプリケーション名の一部と該アプリケーション群に含まれる他の第1のアプリケーションのアプリケーション名に対応する前記第2のアプリケーションのアプリケーション名の一部が一致する部分一致の関係、または該アプリケーション群に含まれる一つの第1のアプリケーションのアプリケーション名に対応する前記第2のアプリケーションのアプリケーション名に該アプリケーション群に含まれる他の第1のアプリケーションのアプリケーション名に対応する前記第2のアプリケーションのアプリケーション名が含まれる包含関係にある第1のアプリケーションを、多重化されているアプリケーションとして検出する、
    ことを特徴とする検出方法。
  12. 情報システムで実行されるアプリケーションの稼動状態を管理するコンピュータに、
    前記情報システムの構成情報収集し、
    収集した前記構成情報基づいて、前記情報システム内のいずれかの監視対象装置に導入される、情報サービスの提供に用いられる第1のアプリケーションと該第1のアプリケーションにデプロイされる第2のアプリケーションとの組み合わせについて、該第1のアプリケーションのアプリケーション名が一致し、且つ、第2のアプリケーションのアプリケーション名が一致する複数の組み合わせが存在する場合に、多重化されているアプリケーションが存在することを検出する、
    機能を実行させるためのプログラム。
  13. 情報システムで実行されるアプリケーションの稼動状態を管理するコンピュータに、
    前記情報システムの構成情報と前記情報システム内で伝送される通信データとを含む情報を収集し、
    収集した前記構成情報と前記通信データとに基づいて、前記情報システム内のいずれかの監視対象装置にデプロイされるアプリケーションにアプリケーション名が一致するアプリケーションが複数存在する場合に、該複数存在するアプリケーションのサブネットアドレスを算出し、算出したサブネットアドレスが一致するアプリケーションを、多重化されているアプリケーションとして検出する、
    機能を実行させるためのプログラム。
  14. 情報システムで実行されるアプリケーションの稼動状態を管理するコンピュータに、
    前記情報システムの構成情報と前記情報システム内で伝送される通信データとを含む情報を収集し、
    収集した前記構成情報と前記通信データとに基づいて、前記情報システム内のいずれかの監視対象装置にデプロイされるアプリケーションにアプリケーション名が一致するアプリケーションが複数存在する場合に、該複数存在するアプリケーションについて、前記収集した情報から該アプリケーションの前後に実行されるアプリケーションのアプリケーション名である前アプリ名と後アプリ名とを含むトランザクションコンテキストを抽出し、抽出したトランザクションコンテキストを構成する前アプリ名と後アプリ名が一致するアプリケーションを、多重化されているアプリケーションとして検出する、
    機能を実行させるためのプログラム。
  15. 情報システムで実行されるアプリケーションの稼動状態を管理するコンピュータに、
    前記情報システムの構成情報と前記情報システム内で伝送される通信データとを含む情報を収集し、
    収集した前記構成情報と前記通信データとに基づいて、前記情報システム内のいずれかの監視対象装置にデプロイされるアプリケーションにアプリケーション名が一致するアプリケーションが複数存在する場合に、該複数存在するアプリケーションについて、前記収集した情報から該アプリケーションの送受信データである要求メッセージと応答メッセージを含むトランザクション情報を抽出し、抽出したトランザクション情報に含まれる該要求メッセージと該応答メッセージが一致するアプリケーションを、多重化されているアプリケーションとして検出する、
    機能を実行させるためのプログラム。
  16. 情報システムで実行されるアプリケーションの稼動状態を管理するコンピュータに、
    前記情報システムの構成情報と前記情報システム内で伝送される通信データとを含む情報を収集し、
    前記収集した情報から、情報サービスを構成するための機能を提供する第1のアプリケーションのうちでアプリケーション名が一致する第1のアプリケーションを抽出し、
    前記抽出した第1のアプリケーションについて、前記収集した情報から前記抽出した第1のアプリケーションの前後に実行されるアプリケーションのアプリケーション名である前アプリ名と後アプリ名とを含むトランザクションコンテキストを抽出し、
    前記抽出した第1のアプリケーションについて、前記収集した情報から、アプリケーション名が一致する第1のアプリケーションにデプロイされた第2のアプリケーションのアプリケーション名を抽出し、
    前記抽出した第1のアプリケーションからなるアプリケーション群について、前記抽出したトランザクションコンテキストを構成する前アプリ名と後アプリ名が一致する第1のアプリケーションであって、かつ該アプリケーション群に含まれる一つの第1のアプリケーションのアプリケーション名に対応する前記第2のアプリケーションのアプリケーション名の一部と該アプリケーション群に含まれる他の第1のアプリケーションのアプリケーション名に対応する前記第2のアプリケーションのアプリケーション名の一部が一致する部分一致の関係、または該アプリケーション群に含まれる一つの第1のアプリケーションのアプリケーション名に対応する前記第2のアプリケーションのアプリケーション名に該アプリケーション群に含まれる他の第1のアプリケーションのアプリケーション名に対応する前記第2のアプリケーションのアプリケーション名が含まれる包含関係にある第1のアプリケーションを、多重化されているアプリケーションとして検出する、
    機能を実行させるためのプログラム。
JP2010188794A 2010-08-25 2010-08-25 検出装置、方法、及びプログラム Expired - Fee Related JP5625621B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2010188794A JP5625621B2 (ja) 2010-08-25 2010-08-25 検出装置、方法、及びプログラム
US13/094,269 US8554908B2 (en) 2010-08-25 2011-04-26 Device, method, and storage medium for detecting multiplexed relation of applications

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2010188794A JP5625621B2 (ja) 2010-08-25 2010-08-25 検出装置、方法、及びプログラム

Publications (2)

Publication Number Publication Date
JP2012048408A JP2012048408A (ja) 2012-03-08
JP5625621B2 true JP5625621B2 (ja) 2014-11-19

Family

ID=45698600

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2010188794A Expired - Fee Related JP5625621B2 (ja) 2010-08-25 2010-08-25 検出装置、方法、及びプログラム

Country Status (2)

Country Link
US (1) US8554908B2 (ja)
JP (1) JP5625621B2 (ja)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5290359B2 (ja) * 2011-06-27 2013-09-18 アンリツ株式会社 移動体通信端末の試験装置及び試験方法
US9276819B2 (en) * 2012-05-29 2016-03-01 Hewlett Packard Enterprise Development Lp Network traffic monitoring
US10652313B2 (en) * 2015-11-08 2020-05-12 Vmware, Inc. Deploying an application in a hybrid cloud computing environment
US10795706B2 (en) 2016-06-06 2020-10-06 Vmware, Inc. Multitier application blueprint representation in open virtualization format package
CN106802807B (zh) * 2017-02-20 2020-07-24 深圳市冬泉谷信息技术有限公司 基于容器平台的应用交付方法、容器平台及应用交付系统
JP7135018B2 (ja) * 2020-02-17 2022-09-12 アンリツ株式会社 移動端末測定システム、及び通信管理情報表示方法

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040162781A1 (en) 2003-02-14 2004-08-19 Kennsco, Inc. Monitoring and alert systems and methods
EP1717703A1 (en) * 2004-02-09 2006-11-02 Matsushita Electric Industries Co., Ltd. Electronic device for automatically continuing to provide service
US7555547B2 (en) * 2004-02-26 2009-06-30 Oracle International Corp. System and method for identifying network communications of a priority service among a plurality of services
US7774456B1 (en) * 2004-02-27 2010-08-10 Packeteer, Inc. Methods, apparatuses and systems facilitating classification of web services network traffic
ZA200608766B (en) 2004-04-22 2008-08-27 Waratek Pty Ltd Modified computer architecture with coordinated objects
JP4669487B2 (ja) * 2007-03-02 2011-04-13 株式会社日立製作所 情報処理システムの運用管理装置および運用管理方法
JP5268589B2 (ja) * 2008-11-25 2013-08-21 株式会社日立製作所 情報処理装置及び情報処理装置の運用方法
JP2013178592A (ja) * 2010-05-06 2013-09-09 Hitachi Ltd 情報処理システムの運用管理装置および運用管理方法

Also Published As

Publication number Publication date
US8554908B2 (en) 2013-10-08
US20120054324A1 (en) 2012-03-01
JP2012048408A (ja) 2012-03-08

Similar Documents

Publication Publication Date Title
US11500757B2 (en) Method and system for automatic real-time causality analysis of end user impacting system anomalies using causality rules and topological understanding of the system to effectively filter relevant monitoring data
JP5625621B2 (ja) 検出装置、方法、及びプログラム
US8429748B2 (en) Network traffic analysis using a dynamically updating ontological network description
US9256412B2 (en) Scheduled and quarantined software deployment based on dependency analysis
EP2871574A1 (en) Analytics for application programming interfaces
Pina et al. Nonintrusive monitoring of microservice-based systems
US20150254969A1 (en) Method and system for providing aggregated network alarms
US11349909B2 (en) Microservice manager and optimizer
Mariani et al. Predicting failures in multi-tier distributed systems
US20160210215A1 (en) Tracing source code for end user monitoring
US11675682B2 (en) Agent profiler to monitor activities and performance of software agents
EP4196896A1 (en) Opentelemetry security extensions
US10452459B2 (en) Device driver telemetry
CN113452607A (zh) 分布式链路采集的方法、装置、计算设备和存储介质
US11635972B2 (en) Multi-tenant java agent instrumentation system
KR101770066B1 (ko) 분산시스템에서 애플리케이션 호출 로그를 이용한 비즈니스 트랜잭션의 실시간 추적 및 분석 방법, 그리고 그 시스템
El-Kassabi et al. Trust enforcement through self-adapting cloud workflow orchestration
Jha et al. Holistic measurement-driven system assessment
US10467082B2 (en) Device driver verification
Stankovic et al. A survey on online monitoring approaches of computer-based systems
US20230409568A1 (en) Monitoring metadata synchronization and aggregation
Benetti et al. Design and Implementation of a Software Vulnerabilities and Application Research Tool
Ramakrishna et al. A platform for end-to-end mobile application infrastructure analytics using system log correlation
WO2024027384A1 (zh) 一种故障检测方法、装置、电子设备及存储介质
US11853330B1 (en) Data structure navigator

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20130604

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20140218

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20140221

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20140421

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20140902

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20140915

R150 Certificate of patent or registration of utility model

Ref document number: 5625621

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees