JP6780498B2 - 情報処理装置、情報処理装置の制御方法およびプログラム - Google Patents

Description

本件開示の技術は、情報処理システム内の障害に関するログを収集する情報処理装置、情報処理装置の制御方法およびプログラムに関する。

コンピュータなどのノードが互いに接続されている情報処理システムにおいて、複数のノードが連携して行う一連の処理に障害が発生したときに各ノードから動作に関するログが収集される。このような情報処理システムにおいて収集したログに基づく障害の評価の精度を高めるための技術が提案されている（特許文献１）。また、発生した障害の要因を過去に収集したログに基づいて推定する技術も提案されている（特許文献２）。

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

しかしながら、上記の技術を用いても、各ノードから収集したログを解析して障害に関連するログを特定する場合、障害とは関連のないログも収集される可能性がある。この場合、システムに設けられたログを格納するための記憶領域が圧迫される可能性がある。また、過去に収集したログに基づいて障害の要因を推定する場合も、あらかじめログを収集しないと障害を推定できないため、過去に発生した障害のログと現在発生している障害のログとが収集されることになる。すなわち、障害の推定のために、実質的に複数の障害のログが収集される。また、あらかじめ収集したログと関連した障害が発生する保証はないため、収集したログが障害の推定に使用されない可能性もある。

本件開示の技術は、上記の事情に鑑み、複数のノードによって実行される処理において発生する障害を解析するためのログを効率よく収集することが可能な情報処理装置を提供することを目的とする。

本件開示の技術の一側面によれば、情報処理装置は、複数のノードによって実行される処理に関するログを取得する情報処理装置であって、処理を示す識別情報を受信する受信部と、複数のノードから、受信した識別情報によって示される処理を実行した時刻と受信した識別情報によって示される処理において障害が発生した時刻とを含む情報を取得する情報取得部と、複数のノードから、識別情報によって示される処理を実行した時刻と識別情報によって示される処理において障害が発生した時刻とに基づいて定まる時間帯において生成された、識別情報によって示される処理とは異なる処理に関するログを取得するログ取得部とを有する。

本件開示の技術によれば、複数のノードによって実行される処理において発生する障害を解析するためのログを効率よく収集することが可能な情報処理装置を提供することができる。

図１は、一実施形態に係る情報処理システムの構成を例示する概略構成図である。 図２は、一実施形態に係る情報処理装置の構成を例示する概略構成図である。 図３は、一実施形態に係る情報処理システムにおいて出力されるログの一例を示す図である。 図４は、一実施形態に係る管理サーバが記憶するサーバ管理テーブルの一例を模式的に示す図である。 図５は、一実施形態に係る管理サーバが記憶するログ受信状況管理テーブルの一例を模式的に示す図である。 図６は、一実施形態に係るサーバｓｖ−１が記憶するログ管理テーブルの一例を模式的に示す図である。 図７は、一実施形態に係るサーバｓｖ−２が記憶するログ管理テーブルの一例を模式的に示す図である。 図８は、一実施形態に係るサーバｓｖ−３が記憶するログ管理テーブルの一例を模式的に示す図である。 図９は、一実施形態に係るサーバｓｖ−４が記憶するログ管理テーブルの一例を模式的に示す図である。 図１０は、一実施形態に係る管理サーバが記憶するログ管理テーブルの一例を模式的に示す図である。 図１１は、一実施形態に係るサーバが実行するエラーのログを検出する処理のフローチャートである。 図１２は、一実施形態に係る管理サーバが実行するエラーのログに関する情報を記憶する処理のフローチャートである。 図１３は、一実施形態に係る管理サーバが実行するエラーのログを取得および記憶する処理のフローチャートである。 図１４は、一実施形態に係るサーバが実行するエラーのログを送信する処理のフローチャートである。 図１５は、一実施形態に係る管理サーバが実行する所定の時間帯に出力されたログを取得および記憶する処理のフローチャートである。 図１６は、一実施形態に係る管理サーバが図１５の処理に続いて実行する処理のフローチャートである。 図１７は、一実施形態に係るサーバが実行するエラーのログのリクエストＩＤを送信する処理のフローチャートである。 図１８は、一実施形態に係る一事例を模式的に示す図である。 図１９は、一実施形態に係る管理サーバが実行するエラーに関連するリソースのログを取得および記憶する処理のフローチャートである。 図２０は、一実施形態に係る管理サーバが図１９の処理に続いて実行する処理のフローチャートである。 図２１は、一実施形態に係る図１８に示す事例とは別の一事例を模式的に示す図である。

以下、本件開示の技術に係る実施形態について図面を参照しながら説明する。なお、以下の詳細な説明は例示的なものであり、実施形態の構成を限定するものではない。

図１に、一実施形態における情報処理システム１の概略構成の一例を示す。情報処理システム１は、管理サーバ２、サーバ３、４、ネットワーク５を有する。管理サーバ２、サーバ３、４は、ネットワーク５を経由して互いに接続されている。ネットワーク５は、有線あるいは無線の通信ネットワークである。また、情報処理システム１は、ネットワーク
５を経由してクライアント端末６と接続されている。なお、情報処理システム１内の各サーバがノードの一例である。

管理サーバ２、サーバ３、４は、それぞれデータベース２１、３１、４１を有する。本実施形態において、管理サーバ２、サーバ３、４は、自サーバ内で出力される各種ログをデータベース２１、３１、４１に記憶する。なお、管理サーバ２、サーバ３、４、ネットワーク５、クライアント端末６の数は、図１に示す数に限られない。

図２に、管理サーバ２の概略構成の一例を示す。管理サーバ２は、Central Processing
Unit（ＣＰＵ）２０１、Random Access Memory（ＲＡＭ）２０２、Hard Disk Drive（ＨＤＤ）２０３、Graphics Processing Unit（ＧＰＵ）２０４、入力インタフェース２０５、通信インタフェース２０６を有する。なお、ＨＤＤ２０３は、データベース２１としての役割を果たす。また、ＧＰＵ２０４、入力インタフェース２０５、通信インタフェース２０６は、モニタ２０７、入力装置２０８、ネットワーク５にそれぞれ接続されている。ＣＰＵ２０１、ＲＡＭ２０２、ＨＤＤ２０３、ＧＰＵ２０４、入力インタフェース２０５、通信インタフェース２０６は、バス２０９を介して互いに接続されている。

本実施形態において、ＣＰＵ２０１は、ＨＤＤ２０３に記憶されている各種プログラムをＲＡＭ２０２に展開して実行することで、以下に説明する種々の処理を実行する。

本実施形態においては、一例として、クライアント端末６が情報処理システム１内のサーバに対して処理を指示した場合に、クライアント端末６からの指示を受けたサーバは、当該指示に基づいて実行する一連の処理に対して他の処理から識別可能となる一意なリクエストＩＤを付与する。リクエストＩＤの一例としてはUniversally Unique Identifier
（ＵＵＩＤ）が挙げられる。情報処理システム１内の各サーバは、当該一連の処理についての要求や応答などを送受信する際に、付与されたリクエストＩＤを引き継ぐ。例えば、クラウド管理ソフトウェアであるＯＰＥＮＳＴＡＣＫ（登録商標）では、情報処理システム内において、インスタンスの作成後にネットワークを構築するときに、ネットワークの構築に関連する一連の処理に同じリクエストＩＤが付与される。例えば、情報処理システム内にノードＡ、Ｂ、Ｃがあり、ノードＡがクライアント端末からインスタンスの作成指示を受けた場合、ノードＡがノードＢにネットワーク構築処理を依頼する。さらにノードＢがノードＣにネットワーク作成処理を依頼する。そして、これらの処理には同じリクエストＩＤが付与される。

また、本実施形態においては、情報処理システム１内の各リソースにはリソースＩＤが割り当てられているものとする。リソースＩＤの一例としてはＵＵＩＤが挙げられる。例えば、ＯＰＥＮＳＴＡＣＫの場合、情報処理システム内のサーバやディスクなど、クラウド上の各リソースにリソースＩＤが割り当てられている。例えば、情報処理システム内に管理サーバ、サーバＡ、サーバＡに接続されたディスクがある場合に、管理サーバがクライアント端末からディスクの取り外し依頼を受けたとする。このとき、管理サーバがクライアント端末から受けるディスク取り外し依頼、管理サーバがサーバＡに対して行うディスク取り外し処理依頼、サーバＡがディスクに対して行うディスク取り外し処理に関する各ログが生成される。そして、各ログには、サーバＡ、ディスクの各リソースＩＤが出力される。

図３に、情報処理システム１において、ある一連の処理について生成されたログの一部を例示する。図３に示すように、ログには、付与されたリクエストＩＤおよび処理に関連するリソースのリソースＩＤが含まれる。リクエストＩＤは、西暦や日時に基づいて情報処理システム内で実行される処理が一意に特定できるＵＵＩＤとして生成される。また、リソースＩＤは、情報処理システム内のリソースが一意に特定できるＵＵＩＤとして生成
される。また、以下の説明において、ログとは、ログの内容を示すメッセージ（図３の場合は「Starting instance ...」）、ログの出力日時、リクエストＩＤ、リソースＩＤな
どの情報が組になったものを指す。したがって、１つのログによって、ログの内容、ログが出力された日時、当該ログに対応する一連の処理のリクエストＩＤ、当該処理に係るリソースのリソースＩＤがわかる。

図４に、管理サーバ２のデータベース２１に記憶されるサーバ管理テーブルの一例を示す。本実施形態においては、情報処理システム１内の各サーバにはそれぞれ異なるＩＰアドレスが割り当てられる。図４に示すサーバ管理テーブルの「ｓｅｒｖｅｒ」欄には、情報処理システム１内の各サーバが記憶され、「ｉｐ」欄には、各サーバに割り当てられているＩＰアドレスが記憶される。本実施形態において、管理サーバ２は、サーバ管理テーブルに記憶されているＩＰアドレスを使用して、情報処理システム内の各サーバに対するログの要求などの処理を実行する。なお、図４の例では、情報処理システム１内に７つのサーバがあり、各サーバの名称はそれぞれｓｖ−１〜ｓｖ−７である。

図５に、管理サーバ２のデータベース２１に記憶されるログ受信状況管理テーブルの一例を示す。本実施形態においては、管理サーバ２は、情報処理システム１内のサーバからのログの受信状況に関連する情報をログ受信状況管理テーブルに記憶する。テーブルのエントリはリクエストＩＤに対応し、各エントリは一例として「ｒｅｑｕｅｓｔ＿ｉｄ」欄、「ｔｉｍｅ」欄、「ｓｔａｔｕｓ」欄の各情報を有する。図５に示すログ受信状況管理テーブルの「ｒｅｑｕｅｓｔ＿ｉｄ」欄には、情報処理システム１内で実行される処理に付与されたリクエストＩＤが記憶される。また、「ｔｉｍｅ」欄には、エラーのログが出力された時刻が記憶される。また、「ｓｔａｔｕｓ」欄には、ログの受信状況を示すステータスが記憶される。本実施形態においてログの受信状況は、以下に説明する「ｓｔｅｐ１」、「ｓｔｅｐ２」、「ｃｏｍｐｌｅｔｅｄ」である。管理サーバ２は、ログ受信状況管理テーブルに記憶されている情報を使用して、各リクエストＩＤに対するログ受信処理を実行する。

図６〜９に、情報処理システム１内の各サーバのデータベースに記憶されるログ管理テーブルの一例を示す。なお、ここでは一例として、情報処理システム１の４つのサーバｓｖ−１、ｓｖ−２、ｓｖ−３、ｓｖ−４がログ管理テーブルに記憶する情報をそれぞれ図６〜９に示す。図６〜９のログ管理テーブルの「ｒｅｑｕｅｓｔ＿ｉｄ」欄には、ログ受信状況管理テーブルと同様、情報処理システム１内で実行される処理に付与されたリクエストＩＤが記憶される。また、「ｌｏｇ＿ｔｉｍｅ」欄には、ログが出力された時刻が記憶される。また、「ｒｅｓｏｕｒｃｅ＿ｉｄ」欄には、リクエストＩＤが示す一連の処理に関連するリソースのリソースＩＤが１つあるいは複数記憶される。また、「ｍｅｓｓａｇｅ」欄には、出力されるログのメッセージの内容が記憶される。

図１０に、管理サーバ２のデータベース２１に記憶されるログ管理テーブルの一例を示す。本実施形態において、管理サーバ２は、情報処理システム１内の各サーバからログを受信し、受信したログに含まれる各種情報をログ管理テーブルに記憶する。図１０のログ管理テーブルの「ｉｄ」欄には、各ログを識別するための識別番号が記憶される。「ｉｄ」欄に記憶される識別番号は、管理サーバ２によって各ログに割り当てられる。また、「ｓｅｒｖｅｒ」欄、「ｒｅｑｕｅｓｔ＿ｉｄ」欄、「ｌｏｇ＿ｔｉｍｅ」欄、「ｒｅｓｏｕｒｃｅ＿ｉｄ」欄、「ｍｅｓｓａｇｅ」欄に記憶される情報は、それぞれ上記で説明した欄と同じである。

以下に、本実施形態における管理サーバ２およびサーバ３、４が実行する処理についてフローチャートを参照しながら説明する。図１１に、サーバ３、４のＣＰＵが実行する処理のフローチャートの一例を示す。サーバ３、４は、一例として、電源が投入されると、
エージェントを起動して図１１に示すフローチャートの処理を開始する。ＯＰ１０１において、サーバ３、４で起動されたエージェントは、あらかじめ指定された文字列をキーワードとして、自サーバ内で生成されたログのいずれかのログを検索する。当該文字列の一例として、「ｅｒｒｏｒ」、「ｗａｒｎｉｎｇ」、「ｆａｉｌｕｒｅ」などエラーのログに含まれる可能性がある文字列が挙げられる。

次いで、ＯＰ１０２において、エージェントは、ＯＰ１０１においてログ内で指定された文字列を検出したか否かを判定する。ログにキーワードである文字列が含まれる場合は（ＯＰ１０２：Ｙｅｓ）、エージェントは、処理をＯＰ１０３に進める。ログにキーワードである文字列が含まれない場合は（ＯＰ１０２：Ｎｏ）、エージェントは、処理をＯＰ１０１に戻し、文字列の検索を実行していないログに対して文字列の検索を行う。

ＯＰ１０３では、エージェントは、キーワードの文字列を含むログに対応する処理のリクエストＩＤを管理サーバ２に送信する。エージェントは、ＯＰ１０３の処理を完了すると、処理をＯＰ１０１に戻し、文字列の検索を実行していないログに対して文字列の検索を行う。

図１２に、管理サーバ２のＣＰＵ２０１が実行する処理のフローチャートの一例を示す。管理サーバ２は、一例として、電源投入されると、図１２に示すフローチャートの処理を開始する。ＯＰ２０１において、ＣＰＵ２０１は、受信部として機能し、サーバ３または４から、上記のＯＰ１０３において送信されたリクエストＩＤを受信する。次いで、ＣＰＵ２０１は、処理をＯＰ２０２に進める。

ＯＰ２０２において、ＣＰＵ２０１は、受信したリクエストＩＤがログ受信状況管理テーブルに記憶されているか否かを判定する。受信したリクエストＩＤがログ受信状況管理テーブルに記憶されている場合は（ＯＰ２０２：Ｙｅｓ）、ＣＰＵ２０１は、処理をＯＰ２０１に戻し、サーバ３または４から新たなリクエストＩＤを受信する。また、受信したリクエストＩＤがログ受信状況管理テーブルに記憶されていない場合は（ＯＰ２０２：Ｎｏ）、ＣＰＵ２０１は処理をＯＰ２０３に進める。

ＯＰ２０３において、ＣＰＵ２０１は、受信したリクエストＩＤと現在時刻をログ受信状況管理テーブルに記憶する。ＣＰＵ２０１は、ＯＰ２０３の処理を完了すると、処理をＯＰ２０１に戻し、サーバ３または４から新たなリクエストＩＤを受信する。本実施形態では、管理サーバ２は、上記の処理を実行することで、情報処理システム１において実行される一連の処理において障害が発生した場合に、リクエストＩＤなどの障害が発生した処理に関する情報を取得することができる。

図１３に、管理サーバ２のＣＰＵ２０１が実行する処理のフローチャートの一例を示す。管理サーバ２は、図１２に示す処理とは別に図１３に示す処理を実行する。管理サーバ２は、図１２に示す処理と図１３に示す処理とを並行して実行してもよい。

ＯＰ３０１において、ＣＰＵ２０１は、ログ受信状況管理テーブルにおいて「ｓｔａｔｕｓ」欄が空であるエントリを検索する。ここで「ｓｔａｔｕｓ」欄が空であるとは、管理サーバ２が、図１２における処理によって障害が発生した処理のリクエストＩＤは取得したが、当該リクエストＩＤに対応するログなどその他の情報は取得していないことを意味する。次いで、ＯＰ３０２において、ＣＰＵ２０１は、上記の検索の結果から、ログ受信状況管理テーブルにおいて「ｓｔａｔｕｓ」欄が空であるエントリが存在するか否かを判定する。「ｓｔａｔｕｓ」欄が空であるエントリが存在する場合は（ＯＰ３０２：Ｙｅｓ）、ＣＰＵ２０１は処理をＯＰ３０４に進める。一方、「ｓｔａｔｕｓ」欄が空であるエントリが存在しない場合は（ＯＰ３０２：Ｎｏ）、ＣＰＵ２０１は処理をＯＰ３０３に
進める。

ＯＰ３０３において、ＣＰＵ２０１は、一定時間待機してから処理をＯＰ３０１に戻す。例えば、サーバ３、４が図１１の処理によって管理サーバ２に送信したリクエストＩＤの処理が、システムタイムアウトによるリトライ処理などである場合、サーバ３、４は、当該処理を実行する度にエラーとしてログに記憶する。このため、管理サーバ２はＯＰ２０１において、サーバ３、４から当該エラーが原因で同じリクエストＩＤを繰り返し受信する可能性がある。そこで、本実施形態では、ＣＰＵ２０１が一定時間待機してからＯＰ３０１を実行することで、管理サーバ２がサーバ３、４からシステムタイムアウトによるリトライ処理などが原因でＯＰ２０１において同じリクエストＩＤを繰り返し受信する可能性を抑える。ここで、一定時間の一例としては、情報処理システム１内の各サーバ３、４のシステムタイムアウト時間より長い時間が挙げられる。

ＯＰ３０４において、ＣＰＵ２０１は、ＯＰ３０２において「ｓｔａｔｕｓ」欄が空であると判定されたリクエストＩＤに対応するログを管理サーバ２に送信するようサーバ３、４に要求する。本実施形態では、一例として、管理サーバ２は当該要求をマルチキャストで情報処理システム１内のサーバに送信する。ただし、管理サーバ２がサーバ管理テーブルに記憶されている情報を用いて特定のサーバに当該要求を送信してもよい。

ここで、ＯＰ３０４において管理サーバ２からログの送信要求を受信したサーバ３、４のエージェントによって実行される処理について、図１４を参照しながら説明する。ＯＰ４０１において、サーバ３、４のエージェントは、ＯＰ３０４において管理サーバ２から送信されたログの送信要求を受信する。ＯＰ４０２において、サーバ３、４のエージェントは、それぞれデータベース３０１、４０１を検索して要求のあったリクエストＩＤに対応するログが存在するか否かを判定する。当該ログが存在する場合は（ＯＰ４０２：Ｙｅｓ）、サーバ３、４のエージェントは処理をＯＰ４０３に進める。当該ログが存在しない場合は（ＯＰ４０２：Ｎｏ）、サーバ３、４のエージェントは処理をＯＰ４０１に戻し、管理サーバ２から新たなログの送信要求を受信するまで待機する。ＯＰ４０３では、サーバ３、４のエージェントは、ＯＰ４０２において存在すると判定したログをデータベース３０１、４０１から取得し、管理サーバ２に送信する。

図１３に戻り、管理サーバ２のＣＰＵ２０１は、情報取得部として機能して、サーバ３、４からＯＰ３０４において要求したログを受信すると（ＯＰ３０５）、ＣＰＵ２０１は処理をＯＰ３０６に進める。ＯＰ３０６において、ＣＰＵ２０１は、受信したログに含まれるメッセージからハッシュ値を生成し、生成されたハッシュ値を受信したログのログＩＤとする。次いで、ＯＰ３０７において、ＣＰＵ２０１は、ＯＰ３０５において受信したログに含まれる情報とＯＰ３０６において生成したログＩＤとをログ管理テーブルに記憶する。図１０に示すログ管理テーブルの例の場合、ＣＰＵ２０１は、ＯＰ３０５において受信したログに含まれる情報を「ｓｅｒｖｅｒ」欄、「ｒｅｑｕｅｓｔ＿ｉｄ」欄、「ｌｏｇ＿ｔｉｍｅ」欄、「ｒｅｓｏｕｒｃｅ＿ｉｄ」欄、「ｍｅｓｓａｇｅ」欄にそれぞれ記憶する。また、ＣＰＵ２０１は、ＯＰ３０６において生成したログＩＤを「ｉｄ」欄に記憶する。なお、ＯＰ３０７において、ＣＰＵ２０１は、ログ管理テーブルに既に同じログＩＤのエントリが記憶されている場合は、上記の記憶処理をスキップして処理をＯＰ３０８に進める。

さらに、ＯＰ３０８において、ＣＰＵ２０１は、ログ受信状況管理テーブルのエントリのうち、ＯＰ３０２で「ｓｔａｔｕｓ」欄が空であると判定されたリクエストＩＤに対応するエントリの「ｓｔａｔｕｓ」欄を空の状態から「ｓｔｅｐ１」に変更する。ここで、「ｓｔｅｐ１」は、管理サーバ２が、図１１、１２の処理で受信したリクエストＩＤ、すなわち障害が発生した処理のリクエストＩＤに関連するログを情報処理システム１内のサ
ーバから取得したことを意味する。

次に、図１５、１６に、管理サーバ２のＣＰＵ２０１が実行する処理のフローチャートの一例を示す。管理サーバ２は、図１２、１３に示す処理とは別に図１５、１６に示す処理を実行する。管理サーバ２は、図１２、１３、１５、１６に示す処理を並行して実行してもよい。

ＯＰ５０１において、ＣＰＵ２０１は、ログ受信状況管理テーブルにおいて「ｓｔａｔｕｓ」欄が「ｓｔｅｐ１」であるエントリを検索する。次いで、ＯＰ５０２において、ＣＰＵ２０１は、ログ受信状況管理テーブルの「ｓｔａｔｕｓ」欄が「ｓｔｅｐ１」であるエントリが存在するか否かを判定する。「ｓｔａｔｕｓ」欄が「ｓｔｅｐ１」であるエントリが存在する場合は（ＯＰ５０２：Ｙｅｓ）、ＣＰＵ２０１は処理をＯＰ５０３に進める。一方、「ｓｔａｔｕｓ」欄が「ｓｔｅｐ１」であるエントリが存在しない場合は（ＯＰ５０２：Ｎｏ）、ＣＰＵ２０１は処理をＯＰ５０１に戻す。

ＯＰ５０３において、ＣＰＵ２０１は、ログ管理テーブルを検索し、ＯＰ５０２で「ｓｔａｔｕｓ」欄が「ｓｔｅｐ１」であると判定されたリクエストＩＤに対応するログを特定する。次いで、ＯＰ５０４において、ＣＰＵ２０１は、ＯＰ５０３で特定したログの情報から、当該ログの出力開始時刻とエラーのログが出力された時刻を特定する。ここで、ログの出力開始時刻とは、ＯＰ５０３において特定されたログの出力時刻、すなわちログ管理テーブルの「ｌｏｇ＿ｔｉｍｅ」欄の時刻のうち最先の時刻を指す。なお、ログの出力開始時刻は、「ｌｏｇ＿ｔｉｍｅ」欄の時刻のうち最先の時刻に限らず、最先の時刻付近の区切りのよい時刻など（１０分単位の時刻など）が採用されてもよい。また、エラーのログが出力された時刻とは、ログ管理テーブル「ｍｅｓｓａｇｅ」欄にＯＰ１０１においてサーバ３、４がエラーのログの検索に使用する文字列を含むログの「ｌｏｇ＿ｔｉｍｅ」欄の時刻を指す。

さらに、ＯＰ５０４において、ＣＰＵ２０１は、特定したログの出力開始時刻からエラーのログが出力された時刻までの時間帯を特定する。例えば、ログ管理テーブルに記憶されている情報が図１０に示す場合に、リクエストＩＤが「ｒｅｑ−０１」に対応するログの出力開始時刻とエラーのログが出力された時刻を特定すると想定する。また、一例として「ｉｄ」欄が「０５」であるログがエラーのログであると想定する。この場合、リクエストＩＤが「ｒｅｑ−０１」に対応するログのうち、「ｌｏｇ＿ｔｉｍｅ」欄の時刻で最先の時刻は、「ｉｄ」欄が「０１」であるログの時刻「１２：００」である。したがって、ログの出力開始時刻は「１２：００」となる。また、「ｉｄ」欄が「０５」であるログの「ｌｏｇ＿ｔｉｍｅ」欄の時刻は「１２：０３」である。したがって、エラーのログが出力された時刻は「１２：０３」である。この結果、１２：００〜１２：０３の時間帯が、ＯＰ５０４において特定される時間帯となる。

次いで、ＯＰ５０５において、ＣＰＵ２０１は、ＯＰ５０４において特定した時間帯に出力されたログのうち、当該時間帯の特定に用いたログのリクエストＩＤ以外のリクエストＩＤに対応するログを管理サーバ２に送信するようサーバ３、４に要求する。サーバ３、４のエージェントは、図１７に示すフローチャートの処理を実行する。ここでは、サーバ３、４のエージェントは、管理サーバ２からＯＰ５０４において特定された時間帯のログの要求を受信し（ＯＰ６０１）、要求された時間帯に出力されているログが存在するか否か判定する（ＯＰ６０２）。そして、要求された時間帯に出力されているログが存在する場合は、サーバ３、４のエージェントは、当該ログに対応するリクエストＩＤを管理サーバ２に送信する（ＯＰ６０３）。

そして、管理サーバ２のＣＰＵ２０１は、図１６に示すフローチャートに従いサーバ３
、４からＯＰ５０５において要求したログのリクエストＩＤを受信すると（ＯＰ５０６）、処理をＯＰ５０７に進める。ＯＰ５０７において、ＣＰＵ２０１は、受信したリクエストＩＤに対応するログを管理サーバ２に送信するようサーバ３、４に要求する。サーバ３、４のエージェントは、図１４に示すフローチャートの処理と同様の処理を実行する。ここでは、サーバ３、４のエージェントは、管理サーバ２からリクエストＩＤに対応するログの要求を受信し（ＯＰ４０１）、要求されたリクエストＩＤに対応するログが存在するか否か判定する（ＯＰ４０２）。そして、要求されたリクエストＩＤに対応するログが存在する場合は、サーバ３、４のエージェントは、当該ログを管理サーバ２に送信する（ＯＰ４０３）。

ここで、図１６に戻り、管理サーバ２のＣＰＵ２０１は、ログ取得部として機能して、サーバ３、４からＯＰ５０７において要求したログを受信すると（ＯＰ５０８）、ＣＰＵ２０１は処理をＯＰ５０９に進める。ＯＰ５０９において、ＣＰＵ２０１は、受信したログに含まれるメッセージからハッシュ値を生成し、生成されたハッシュ値を受信したログのログＩＤとする。次いで、ＯＰ５１０において、ＣＰＵ２０１は、ＯＰ３０７と同様、ＯＰ５０８において受信したログに含まれる情報とＯＰ５０９において生成したログＩＤとをログ管理テーブルに記憶する。

さらに、ＣＰＵ２０１は、ＯＰ５１１において、ログ受信状況管理テーブルにおいて、ＯＰ５０２で「ｓｔａｔｕｓ」欄が「ｓｔｅｐ１」であると判定されたリクエストＩＤの「ｓｔａｔｕｓ」欄を「ｓｔｅｐ１」から「ｓｔｅｐ２」に変更する。ここで、「ｓｔｅｐ２」は、管理サーバ２が、ＯＰ５０４において特定された時間帯に出力されたログを情報処理システム１内のサーバから取得したことを意味する。そして、ＯＰ５１２において、ＣＰＵ２０１は、ＯＰ５１０においてログ管理テーブルに記憶したログの情報をモニタ２０７に表示する。

図１８に、本実施形態において図１５〜１７に示す処理を実行する場合に管理サーバ２によってログが取得される一事例を示す。図１８に示す例では、情報処理システム１内にサーバＡ ８０１、サーバＢ ８０２、データベース８０３（残り容量：１０ＧＢ）、管理サーバ２（図示せず）がある。このとき、ユーザＡがクライアント端末を操作して、サーバＡ ８０１に対してデータベース８０３の残り容量のうち４ＧＢのディスク使用申請を行う。また、ユーザＢがクライアント端末を操作して、サーバＢ ８０２に対してデータベース８０３の残り容量のうち８ＧＢのディスク使用申請を行う。ここで、ユーザＡは、ユーザＢよりも早くディスク使用申請を行ったとする。

サーバＡ ８０１は、ユーザＡのディスク使用申請を受信して、時刻１０：００にディスク容量確認を行う。そして、サーバＡ ８０１はディスク容量確認処理のログを出力する。一方、サーバＢ ８０２は、ユーザＢのディスク使用申請を受信して、時刻１０：０１にディスク容量確認を行う。サーバＢ ８０２はディスク容量確認処理のログを出力する。

ここで、サーバＢ ８０２が、サーバＡ ８０１よりも早く時刻１０：０３にデータベース８０３のディスク使用処理を行ったとする。このとき、データベース８０３の残り容量は１０ＧＢであるため、ユーザＢによる８ＧＢのディスク使用申請に基づくディスク使用処理は正常に完了する。そして、サーバＢ ８０２は、当該ディスク使用処理のログを出力および記憶する。一方、時刻１０：０４におけるサーバＡ ８０１による４ＧＢのディスク使用処理は、データベース８０３の残り容量が２ＧＢであるためエラーとなり、サーバＡは当該エラーのログを出力および記憶する。

図１８の事例では、サーバＡ ８０１によるディスク容量確認処理とディスク使用処理
には同じリクエストＩＤが付与され、同様にサーバＢ ８０２によるディスク容量確認処理とディスク使用処理には同じリクエストＩＤが付与される。そして、上記の図１５〜１７の処理によれば、管理サーバ２は、サーバＡ ８０１から、時刻１０：０４にサーバＡ
８０１が出力したエラーのログと時刻１０：００にサーバＡ ８０１が出力したディスク容量確認処理のログを取得する。さらに、管理サーバ２は、サーバＢ８０２から、１０：００〜１０：０４の時間帯に出力されたディスク容量確認処理のログ（時刻１０：０１に出力）とディスク使用処理のログ（時刻１０：０３）を取得する。このように、本実施形態において図１８の事例では、サーバＡ ８０１による一連の処理において発生した障害について、当該処理と同じ時間帯に他のサーバＢ ８０２が実行していた処理に関するログを取得することができる。すなわち、管理サーバ２は、あるサーバで発生した障害と関連がある可能性が高いログ（関連ログ）を他のサーバから取得することができる。

次に、図１９、２０に、管理サーバ２のＣＰＵ２０１が実行する処理のフローチャートの一例を示す。管理サーバ２は、図１２、１３、１５、１６に示す処理とは別に図１９、２０に示す処理を実行する。管理サーバ２は、図１２、１３、１５、１６、１９、２０に示す処理を並行して実行してもよい。

ＯＰ７０１において、ＣＰＵ２０１は、ログ受信状況管理テーブルにおいて「ｓｔａｔｕｓ」欄が「ｓｔｅｐ２」であるエントリを検索する。次いで、ＯＰ７０２において、ＣＰＵ２０１は、ログ受信状況管理テーブルの「ｓｔａｔｕｓ」欄が「ｓｔｅｐ２」であるエントリが存在するか否かを判定する。「ｓｔａｔｕｓ」欄が「ｓｔｅｐ２」であるエントリが存在する場合は（ＯＰ７０２：Ｙｅｓ）、ＣＰＵ２０１は処理をＯＰ７０３に進める。一方、「ｓｔａｔｕｓ」欄が「ｓｔｅｐ２」であるエントリが存在しない場合は（ＯＰ７０２：Ｎｏ）、ＣＰＵ２０１は処理をＯＰ７０１に戻す。

ＯＰ７０３において、ＣＰＵ２０１は、ログ管理テーブルを検索し、ＯＰ７０２で「ｓｔａｔｕｓ」欄が「ｓｔｅｐ２」であると判定されたリクエストＩＤに対応するログを特定する。次いで、ＯＰ７０４において、ＣＰＵ２０１は、ＯＰ７０３で特定したログに含まれるリソースＩＤを特定する。本実施形態では、ＯＰ７０４で特定されるリソースＩＤに対応するリソースを、ＯＰ７０３で特定されるログに対応するリクエストＩＤが示す処理に関係があるリソースであるとみなすことができる。

次いで、ＯＰ７０５において、ＣＰＵ２０１は、ＯＰ７０４において特定したリソースＩＤを含むログをサーバ３、４に要求する。サーバ３、４のエージェントは、図１４に示すフローチャートの処理と同様の処理を実行する。ここでは、サーバ３、４のエージェントは、管理サーバ２からＯＰ７０４において特定されたリソースＩＤを含むログの要求を受信し（ＯＰ４０１）、要求されたリソースＩＤを含むログが存在するか否か判定する（ＯＰ４０２）。そして、要求されたリソースＩＤを含むログが存在する場合は、サーバ３、４のエージェントは、当該ログを管理サーバ２に送信する（ＯＰ４０３）。

そして、管理サーバ２のＣＰＵ２０１は、ログ取得部として機能して、サーバ３、４からＯＰ７０５において要求したログを受信すると（ＯＰ７０６）、ＣＰＵ２０１は処理をＯＰ７０７に進める。ＯＰ７０７において、ＣＰＵ２０１は、受信したログに含まれるメッセージからハッシュ値を生成し、生成されたハッシュ値を受信したログのログＩＤとする。次いで、ＯＰ７０８において、ＣＰＵ２０１は、ＯＰ３０７と同様、ＯＰ７０６において受信したログに含まれる情報とＯＰ７０７において生成したログＩＤとをログ管理テーブルに記憶する。

さらに、ＣＰＵ２０１は、ＯＰ７０９において、ログ受信状況管理テーブルにおいて、ＯＰ７０２で「ｓｔａｔｕｓ」欄が「ｓｔｅｐ２」であると判定されたリクエストＩＤに
対応するエントリの「ｓｔａｔｕｓ」欄を「ｓｔｅｐ２」から「ｃｏｍｐｌｅｔｅｄ」に変更する。ここで、「ｃｏｍｐｌｅｔｅｄ」は、管理サーバ２が、情報処理システム１で発生した特定の障害に関連するログを情報処理システム１内のサーバから取得したことを意味する。次いで、ＯＰ７１０において、ＣＰＵ２０１は、ＯＰ７０８においてログ管理テーブルに記憶したログの情報をモニタ２０７に表示する。

図２１に、本実施形態において図１４、１９、２０に示す処理を実行する場合に管理サーバ２によってログが取得される一事例を示す。図２１に示す例では、情報処理システム１内にサーバ９０１、ディスク９０２、管理サーバ２がある。また、サーバ９０１、ディスク９０２、管理サーバ２がリソースの一例であり、サーバ９０１、ディスク９０２、管理サーバ２にはそれぞれリソースＩＤが付与されている。

まず、ユーザＡが、時刻１０：００にディスク９０２をサーバ９０１から取り外す依頼を行う。しかし、当該依頼処理が正常に完了せず、ディスク９０２はサーバ９０１から取り外されなかったとする。さらに、ユーザＡは、ディスク９０２を使用する予定がないため、ディスク９０２がサーバ９０１から取り外されていない状態を放置し、管理サーバ２のシステム管理者にその状態を報告しなかったとする。ここでは、サーバ９０１が、ディスク９０２の取り外し状態を含む利用状況を管理するディスク利用管理テーブルを保持していると想定する。そして、上記の例では、サーバ９０１からのディスク９０２の取り外しには失敗しているが、ディスク利用管理テーブルではディスク９０２がサーバ９０１から取り外されたとして記憶されると想定する。

上記の状況において、ユーザＢが、サーバ９０１のディスク管理テーブルでディスク９０２が取り外されていることを確認し、時刻１２：００にサーバ９０１にディスク９０２の追加を依頼する。しかし、ディスク９０２はサーバ９０１から取り外されていないため、サーバ９０１は、ユーザＢのディスク追加依頼を処理する際に、「ディスク９０２は既にサーバ９０１追加されている」旨を示すエラーをログとして出力する。なお、ユーザＢは、時刻１２：００以前にサーバ９０１に対する処理は行っていないとする。

この事例において、上記の図１４、１９、２０の処理によれば、管理サーバ２は、サーバ９０１から、「ディスク９０２は既にサーバ９０１追加されている」旨を示すエラーのログを取得する。さらに、管理サーバ２は、サーバ９０１から、ディスク９０２のリソースＩＤを含むログ、すなわちユーザＡによるディスク取り外し依頼のログを取得する。このように、本実施形態において図２１の事例では、サーバ９０１において発生した障害について、当該処理に係るリソースに関連するログを取得することができる。すなわち、管理サーバ２は、ある障害に係るリソースと関連する他のログ（関連ログ）を取得することができる。

以上が本実施形態に関する説明であるが、上記のサーバなどの構成や処理は、上記の実施形態に限定されるものではなく、本発明の技術的思想と同一性を失わない範囲内において種々の変更が可能である。例えば、上記の実施形態においては、管理サーバ２、サーバ３、４は、図１３、１４に示す処理の後に、図１５〜１７に示す処理を実行し、さらに図１４、１９、２０に示す処理を実行することを想定している。しかし、管理サーバ２、サーバ３、４は、図１５〜１７に示す処理を実行した後に、図１４、１９、２０に示す処理を実行しなくてもよい。この場合、ＯＰ５１１の処理を、「ｓｔａｔｕｓ」欄を「ｓｔｅｐ１」から「ｃｏｍｐｌｅｔｅｄ」に変更する処理とする。

また、管理サーバ２、サーバ３、４は、図１３、１４に示す処理の後に、図１５〜１７に示す処理を実行せずに、図１４、１９、２０に示す処理を実行してもよい。この場合、ＯＰ３０８の処理を、「ｓｔａｔｕｓ」欄を空の状態から「ｓｔｅｐ２」に変更する処理
とする。

また、上記の実施形態において、上記の少なくとも一部の処理は、ＣＰＵ以外のプロセッサ、例えば、Digital Signal Processor（ＤＳＰ）、Graphics Processing Unit（ＧＰＵ）、数値演算プロセッサ、ベクトルプロセッサ、画像処理プロセッサ等の専用プロセッサで行われてもよい。また、上記の少なくとも一部の処理は、集積回路（ＩＣ）、その他のディジタル回路であってもよい。また、上記各部の少なくとも一部にアナログ回路が含まれてもよい。集積回路は、Large-scale Integration（ＬＳＩ）、Application Specific Integrated Circuit（ＡＳＩＣ）、プログラマブルロジックデバイス（ＰＬＤ）を含む。ＰＬＤは、例えば、Field-Programmable Gate Array(ＦＰＧＡ)を含む。上記各部は、
プロセッサと集積回路との組み合わせであってもよい。組み合わせは、例えば、マイクロコントローラ（ＭＣＵ）、System-on-a-Chip（ＳｏＣ）、システムＬＳＩ、チップセットなどと呼ばれる。

＜コンピュータが読み取り可能な記録媒体＞
コンピュータその他の機械、装置（以下、コンピュータ等）に上記起動制御装置の設定を行うための管理ツール、ＯＳその他を実現させるプログラムをコンピュータ等が読み取り可能な記録媒体に記録することができる。そして、コンピュータ等に、この記録媒体のプログラムを読み込ませて実行させることにより、その機能を提供させることができる。

ここで、コンピュータ等が読み取り可能な記録媒体とは、データやプログラム等の情報を電気的、磁気的、光学的、機械的、または化学的作用によって蓄積し、コンピュータ等から読み取ることができる記録媒体をいう。このような記録媒体のうちコンピュータ等から取り外し可能なものとしては、例えばフレキシブルディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ／Ｗ、ＤＶＤ、ブルーレイディスク、ＤＡＴ、８ｍｍテープ、フラッシュメモリ等のメモリカード等がある。また、コンピュータ等に固定された記録媒体としてハードディスクやＲＯＭ等がある。

以上の実施形態に関し、さらに以下の付記を開示する。

（付記１）
複数のノードによって実行される処理に関するログを取得する情報処理装置であって、
前記処理を示す識別情報を受信する受信部と、
前記複数のノードから、前記受信した識別情報によって示される処理を実行した時刻と前記受信した識別情報によって示される処理において障害が発生した時刻とを含む情報を取得する情報取得部と、
前記複数のノードから、前記識別情報によって示される処理を実行した時刻と前記識別情報によって示される処理において障害が発生した時刻とに基づいて定まる時間帯において生成された、前記識別情報によって示される処理とは異なる処理に関するログを取得するログ取得部と
を有する情報処理装置。

（付記２）
前記情報取得部はさらに、前記複数のノードから、前記受信した識別情報によって示される処理と関連するリソースの情報を取得し、
前記ログ取得部はさらに、前記複数のノードから、前記リソースを含むログであって、前記識別情報によって示される処理とは異なる処理に関するログを取得する
付記１に記載の情報処理装置。

（付記３）
前記情報取得部は、前記複数のノードが実行する処理のタイムアウト時間より長い時間待機した後に、前記複数のノードから、前記受信した識別情報によって示される処理を実行した時刻と前記受信した識別情報によって示される処理において障害が発生した時刻とを含む情報を取得する、付記１または２に記載の情報処理装置。

（付記４）
複数のノードによって実行される処理に関するログを取得する情報処理装置であって、
前記処理を示す識別情報を受信する受信部と、
前記複数のノードから、前記受信した識別情報によって示される処理と関連するリソースの情報を取得する情報取得部と、
前記複数のノードから、前記リソースを含むログであって、前記識別情報によって示される処理とは異なる処理に関するログを取得するログ取得部と
を有する情報処理装置。

（付記５）
前記情報取得部は、前記複数のノードが実行する処理のタイムアウト時間より長い時間待機した後に、前記複数のノードから、前記受信した識別情報によって示される処理と関連するリソースの情報を取得する、付記４に記載の情報処理装置。

（付記６）
複数のノードによって実行される処理に関するログを取得する情報処理装置に、
前記処理を示す識別情報を受信させ、
前記複数のノードから、前記受信した識別情報によって示される処理を実行した時刻と前記受信した識別情報によって示される処理において障害が発生した時刻とを含む情報を取得させ、
前記複数のノードから、前記識別情報によって示される処理を実行した時刻と前記識別情報によって示される処理において障害が発生した時刻とに基づいて定まる時間帯において生成された、前記識別情報によって示される処理とは異なる処理に関するログを取得させる
情報処理装置の制御方法。

（付記７）
前記情報処理装置にさらに、
前記複数のノードから、前記受信した識別情報によって示される処理と関連するリソースの情報を取得させ
前記複数のノードから、前記リソースを含むログであって、前記識別情報によって示される処理とは異なる処理に関するログを取得させる
付記６に記載の情報処理装置の制御方法。

（付記８）
前記情報処理装置にさらに、前記複数のノードが実行する処理のタイムアウト時間より長い時間待機した後に、前記複数のノードから、前記受信した識別情報によって示される処理を実行した時刻と前記受信した識別情報によって示される処理において障害が発生した時刻とを含む情報を取得させる、付記６または７に記載の情報処理装置の制御方法。

（付記９）
複数のノードによって実行される処理に関するログを取得する情報処理装置に、
前記処理を示す識別情報を受信させ、
前記複数のノードから、前記受信した識別情報によって示される処理と関連するリソースの情報を取得させ、
前記複数のノードから、前記リソースを含むログであって、前記識別情報によって示される処理とは異なる処理に関するログを取得させる
情報処理装置の制御方法。

（付記１０）
前記情報処理装置にさらに、前記複数のノードが実行する処理のタイムアウト時間より長い時間待機した後に、前記複数のノードから、前記受信した識別情報によって示される処理と関連するリソースの情報を取得させる、付記９に記載の情報処理装置の制御方法。

（付記１１）
コンピュータに、
複数のノードによって実行される処理の識別情報を受信させ、
前記複数のノードから、前記受信した識別情報によって示される処理を実行した時刻と前記受信した識別情報によって示される処理において障害が発生した時刻とを含む情報を取得させ、
前記複数のノードから、前記識別情報によって示される処理を実行した時刻と前記識別情報によって示される処理において障害が発生した時刻とに基づいて定まる時間帯において生成された、前記識別情報によって示される処理とは異なる処理に関するログを取得させる
プログラム。

（付記１２）
前記コンピュータにさらに、
前記複数のノードから、前記受信した識別情報によって示される処理と関連するリソースの情報を取得させ
前記複数のノードから、前記リソースを含むログであって、前記識別情報によって示される処理とは異なる処理に関するログを取得させる
プログラム。

（付記１３）
前記コンピュータにさらに、前記複数のノードが実行する処理のタイムアウト時間より長い時間待機した後に、前記複数のノードから、前記受信した識別情報によって示される処理を実行した時刻と前記受信した識別情報によって示される処理において障害が発生した時刻とを含む情報を取得させる、付記１１または１２に記載のプログラム。

（付記１４）
コンピュータに、
複数のノードによって実行される処理の識別情報を受信させ、
前記複数のノードから、前記受信した識別情報によって示される処理と関連するリソースの情報を取得させ、
前記複数のノードから、前記リソースを含むログであって、前記識別情報によって示される処理とは異なる処理に関するログを取得させる
プログラム。

（付記１５）
前記コンピュータにさらに、前記複数のノードが実行する処理のタイムアウト時間より長い時間待機した後に、前記複数のノードから、前記受信した識別情報によって示される処理と関連するリソースの情報を取得させる、付記１４に記載のプログラム。

１ 情報処理システム
２ 管理サーバ
２１、３１、４１ データベース
３、４ サーバ

Claims (9)

1. 複数のノードによって実行される処理に関するログを取得する情報処理装置であって、
   前記処理を示す識別情報を受信する受信部と、
   前記複数のノードから、前記受信した識別情報によって示される処理を実行した時刻と前記受信した識別情報によって示される処理において障害が発生した時刻とを含む情報を取得する情報取得部と、
   前記複数のノードから、前記識別情報によって示される処理を実行した時刻と前記識別情報によって示される処理において障害が発生した時刻とに基づいて定まる時間帯において生成された、前記識別情報によって示される処理とは異なる処理に関するログを取得するログ取得部と
   を有する情報処理装置。
2. 前記情報取得部はさらに、前記複数のノードから、前記受信した識別情報によって示される処理と関連するリソースの情報を取得し、
   前記ログ取得部はさらに、前記複数のノードから、前記リソースを含むログであって、前記識別情報によって示される処理とは異なる処理に関するログを取得する
   請求項１に記載の情報処理装置。
3. 前記情報取得部は、前記複数のノードが実行する処理のタイムアウト時間より長い時間待機した後に、前記複数のノードから、前記受信した識別情報によって示される処理を実行した時刻と前記受信した識別情報によって示される処理において障害が発生した時刻とを含む情報を取得する、請求項１または２に記載の情報処理装置。
4. 複数のノードによって実行される処理に関するログを取得する情報処理装置であって、
   前記処理を示す識別情報を受信する受信部と、
   前記複数のノードから、前記受信した識別情報によって示される処理と関連するリソースの情報を取得する情報取得部と、
   前記複数のノードから、前記リソースを含むログであって、前記識別情報によって示される処理とは異なる処理に関するログを取得するログ取得部と
   を有する情報処理装置。
5. 前記情報取得部は、前記複数のノードが実行する処理のタイムアウト時間より長い時間待機した後に、前記複数のノードから、前記受信した識別情報によって示される処理と関連するリソースの情報を取得する、請求項４に記載の情報処理装置。
6. 複数のノードによって実行される処理に関するログを取得する情報処理装置に、
   前記処理を示す識別情報を受信させ、
   前記複数のノードから、前記受信した識別情報によって示される処理を実行した時刻と前記受信した識別情報によって示される処理において障害が発生した時刻とを含む情報を取得させ、
   前記複数のノードから、前記識別情報によって示される処理を実行した時刻と前記識別情報によって示される処理において障害が発生した時刻とに基づいて定まる時間帯において生成された、前記識別情報によって示される処理とは異なる処理に関するログを取得させる
   情報処理装置の制御方法。
7. 複数のノードによって実行される処理に関するログを取得する情報処理装置に、
   前記処理を示す識別情報を受信させ、
   前記複数のノードから、前記受信した識別情報によって示される処理と関連するリソー
   スの情報を取得させ、
   前記複数のノードから、前記リソースを含むログであって、前記識別情報によって示される処理とは異なる処理に関するログを取得させる
   情報処理装置の制御方法。
8. コンピュータに、
   複数のノードによって実行される処理の識別情報を受信させ、
   前記複数のノードから、前記受信した識別情報によって示される処理を実行した時刻と前記受信した識別情報によって示される処理において障害が発生した時刻とを含む情報を取得させ、
   前記複数のノードから、前記識別情報によって示される処理を実行した時刻と前記識別情報によって示される処理において障害が発生した時刻とに基づいて定まる時間帯において生成された、前記識別情報によって示される処理とは異なる処理に関するログを取得させる
   プログラム。
9. コンピュータに、
   複数のノードによって実行される処理の識別情報を受信させ、
   前記複数のノードから、前記受信した識別情報によって示される処理と関連するリソースの情報を取得させ、
   前記複数のノードから、前記リソースを含むログであって、前記識別情報によって示される処理とは異なる処理に関するログを取得させる
   プログラム。

Images