JP7215340B2

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

Info

Publication number: JP7215340B2
Application number: JP2019102944A
Authority: JP
Inventors: 宏太板倉; 美和岡林; 久俊山岡; 英一高橋; 一樹松井; 達郎松本
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2019-05-31
Filing date: 2019-05-31
Publication date: 2023-01-31
Anticipated expiration: 2039-05-31
Also published as: US11449378B2; US20200379832A1; EP3745334A1; JP2020197853A

Description

本発明は、情報処理装置、ログ制御プログラム、およびログ制御方法に関する。

近年、ＩｏＴ（Internet of Things）機器の増加などにより、日々大量のデータが継続的に発生しており、これらの継続的に発生するデータを入力として処理を実行するストリーミング処理技術が開発されている。こうしたストリーミング処理を実行する分散ストリームデータ処理基盤では、複数のタスクが連結され、大量のデータが、それらタスクに次々と投入されて処理されていく。開発者は、例えば、各タスクの開発時に、ログを出力するコードを記述しておくことで、各タスクごとおよび処理経路ごとにログを出力させることができる。

これに関し、ログの出力に関連する技術が知られている（例えば、特許文献１および特許文献２）。

特開２００９－１１０１５６号公報特開２０１３－２０６１１７号公報特開２０１４－８１８１１号公報

しかしながら、開発者は、タスクのログをどの程度出力させるかを開発時に決定している。そのため、タスクの動作時の状態の予測が難しく、過剰にログを取得して分散ストリームデータ処理基盤の負荷を高めてしまったり、或いは十分なログを取得できず、後の検証が難しくなってしまったりすることがある。

１つの側面では、本発明は、効率的にログを収集することを目的とする。

本発明の一つの態様の情報処理装置は、分散ストリームデータ処理基盤において実行される複数のタスクのそれぞれのタスクごとに、障害の発生のし易さと関連する指標に基づいてログスコアを取得する取得部と、複数のタスクのうちのそれぞれのタスクについて、タスクのログスコアと、タスクの上流に位置する上流タスクおよびタスクの下流に位置する下流タスクの少なくとも一方のログスコアとに基づく出力頻度でタスクのログメッセージを出力する出力部と、を含む。

効率的にログを収集することができる。

例示的な分散ストリームデータ処理基盤を示す図である。実施形態に係るログの出力頻度の決定を例示する図である。実施形態に係る分散ストリームデータ処理基盤を例示する図である。実施形態に係る情報処理装置のブロック構成を例示する図である。実施形態に係るログの出力頻度の決定について更に例示する図である。実施形態に係る分散ストリームデータ処理基盤の全体のログ量の調整を例示する図である。実施形態に係るタスクの実行処理の動作フローを例示する図である。実施形態に係るタスク間のメッセージを例示する図である。実施形態に係るスコア情報を例示する図である。実施形態に係るタスク実行情報を例示する図である。実施形態に係るログ計数情報を例示する図である。実施形態に係るログスコア補正メッセージを例示する図である。実施形態に係る集計依頼応答メッセージを例示する図である。実施形態に係るログスコアの計算処理を例示する図である。実施形態に係るログ出力判定処理を例示する図である。実施形態に係るログ量の最適化処理の動作フローを例示する図である。実施形態に係る情報処理装置および管理装置を実現するためのコンピュータのハードウェア構成を例示する図である。

以下、図面を参照しながら、本発明のいくつかの実施形態について詳細に説明する。なお、複数の図面において対応する要素には同一の符号を付す。

上述のように、分散ストリームデータ処理基盤では、複数のタスクが連結され、それらタスクに大量のデータが投入されて次々と処理されていく。図１は、例示的な分散ストリームデータ処理基盤を示す図である。分散ストリームデータ処理基盤では、複数のタスク１０１が連結されており、センサなどで生成されたデータは、所定のルーティングに従ってタスク１０１に入力され処理されていく。

ここで、タスク１０１の開発者は、例えば、タスク１０１で実行する処理のプログラムを記述する際に、ログを出力するコードを記述しておくことで、各タスクごとおよび処理経路ごとにログを出力させることができる。そして、タスク１０１の処理に異常が発生した際などに、出力させたログのデータを利用して原因を追究することが可能である。

しかしながら、開発者は、例えば、タスク１０１にログをどの程度出力させるかを開発時に決定する。そのため、タスク１０１の動作時の状況の予測が難しく、過剰にログを取得して分散ストリームデータ処理基盤の負荷を高めてしまったり、或いは十分なログを取得できず、障害が発生した際などに原因の究明が難しくなってしまったりすることがある。そのため、ログの取得の効率化を図ることのできる技術の提供が求められている。

以下で述べる実施形態では、タスク１０１ごとに、そのタスク１０１の状態に基づきログスコアが算出される。なお、ログスコアは、例えば、タスク１０１が障害と関連する可能性を評価した値であってよい。ログスコアは、一例では、タスク１０１における障害の発生と関連する指標に基づいて算出されてよい。

そして、実施形態では、例えば、タスク１０１のログスコアと、そのタスク１０１の上流および下流の少なくとも一方のタスク１０１のログスコアとに基づいて、タスク１０１のログの出力頻度が決定される。図２は、実施形態に係るログの出力頻度の決定を例示する図である。図２に示すように、タスク１０１のログの出力頻度は、そのタスク１０１のログスコアと、そのタスク１０１の上流に位置する上流タスク１０１および下流に位置する下流タスク１０１の少なくとも一方のタスク１０１のログスコアとを考慮して求められてよい。上流および下流の少なくとも一方のタスク１０１のログスコアを考慮してログの出力頻度を決定することで、分散ストリームデータ処理基盤に含まれる複数のタスク１０１のログを効率的に収集することが可能である。なお、タスク１０１の上流タスク１０１とは、例えば、ルーティングにおいて、タスク１０１よりも先に配置されているタスク１０１であってよく、タスク１０１の処理で用いられるデータを入力してくるタスク１０１であってよい。また、タスク１０１の下流タスク１０１とは、例えば、タスク１０１の処理で得られたデータの出力先となるタスク１０１であってよく、下流タスク１０１は、タスク１０１の処理で得られたデータを用いて処理を実行してよい。以下、実施形態を更に詳細に説明する。

図３は、実施形態に係る分散ストリームデータ処理基盤３００を例示する図である。分散ストリームデータ処理基盤３００は、例えば、少なくとも１つの情報処理装置３０１、および少なくとも１つのセンサ３０２を含んでよい。情報処理装置３０１と、センサ３０２とは、例えば、ネットワーク３０５を介して通信可能に接続されている。センサ３０２は、例えば、ＩｏＴ機器などであってよく、宛先として指定されている所定の情報処理装置３０１に検出したセンシングデータを送信する。情報処理装置３０１には、分散ストリームデータ処理基盤３００に含まれる複数のタスク１０１のうちの少なくとも１つのタスク１０１が配備されていてよい。情報処理装置３０１は、例えば、センサ３０２から受信したセンシングデータを、配備されているタスク１０１に入力し、所定のルーティングに従って処理してよい。

図４は、実施形態に係る情報処理装置３０１のブロック構成を例示する図である。情報処理装置３０１は、例えば、制御部４０１、記憶部４０２、および通信部４０３を含む。制御部４０１は、例えば、情報処理装置３０１に配備されているタスク１０１を実行する。また、制御部４０１は、例えば取得部４１１、出力部４１２、および決定部４１３などとして動作してよい。記憶部４０２は、例えば、後述するスコア情報９００、タスク実行情報１０００、ログ計数情報１１００、およびログスコア補正メッセージ１２００などの情報を記憶してよい。また、例えば、情報処理装置３０１が、分散ストリームデータ処理基盤３００の管理を実行する後述の管理装置として動作する場合には、記憶部４０２は、ログスコア補正メッセージ１２００および集計依頼応答メッセージ１３００などの情報を記憶してよい。通信部４０３は、例えば、制御部４０１の指示に従って、ネットワーク３０５を介してセンサ３０２および他の情報処理装置３０１と通信する。これらの各部の詳細及び記憶部４０２に格納されている情報の詳細については後述する。

続いて、実施形態に係るログの出力頻度の決定について更に説明する。図５は、実施形態に係るログの出力頻度の決定について更に例示する図である。実施形態では情報処理装置３０１の制御部４０１は、まず、自装置に配備されているタスク１０１のそれぞれについて、ログスコアを計算する。ログスコアは、例えば、タスク１０１における障害の発生と関連する指標に基づいて算出することができる。一例ではタスク１０１における障害の発生と関連する指標は、ＣＰＵ（Central Processing Unit）にかかる負荷、およびメモリの使用量などであってよい。例えば、タスク１０１の実行にかかるＣＰＵの処理負荷が高かったり、メモリの使用量が多かったりする場合には、そのタスク１０１は障害の発生の可能性が高いことが推定できる。そのため、制御部４０１は、ＣＰＵの処理負荷が高かったり、メモリの使用量が多かったりするタスク１０１には、高いログスコアを算出してよい。

例えば、図５では、タスクＡからタスクＧの複数のタスク１０１が示されており、分散ストリームデータ処理基盤３００に含まれる情報処理装置３０１の制御部４０１は、これらのタスクＡからタスクＧのログスコアを算出してよい。なお、図５では、上段に示すように、ログの出力頻度が高いほど濃い色でタスク１０１を表している。例えば、図５は、タスクＤに最も高いログスコアが算出された場合を示している（図５の（１））。この場合、制御部４０１は、タスクＤのログの出力頻度を他のタスク１０１よりも高い値に設定してよい。

また、例えば、制御部４０１は、或るタスク１０１の下流のタスク１０１のログスコアが高い場合、そのタスク１０１のログスコアを高めてよい。例えば、図５では、タスクＢの下流のタスクＤのログスコアが高いため、制御部４０１は、タスクＢのログスコアを高めてよい（図５の（２））。そして、制御部４０１は、下流のタスクＤの影響で高められたログスコアに基づいてタスクＢのログの出力頻度を決定してよい。これは、タスクＤに障害が生じた場合、タスクＤは、タスクＢの下流のタスク１０１であり、タスクＢが障害の原因である可能性があるためである。

また、制御部４０１は、例えば、タスクＣのログの出力頻度を決定する際に、下流のタスクＤ、タスクＥ、およびタスクＦのログスコアを考慮する。この場合、タスクＤのログスコアが高いため、タスクＣのログスコアを高めてよいが、他の下流のタスクＥおよびタスクＦは、ログスコアが高くはないため、制御部４０１は、タスクＣのログスコアをそれほど高めなくてもよい（図５の（３））。そして、制御部４０１は、下流のタスクＤの影響で若干高められたログスコアに基づいてタスクＣのログの出力頻度を決定してよい。例えば、タスクＤに障害が生じた場合、タスクＤは、タスクＣの下流のタスク１０１であるため、タスクＣは障害の原因である可能性があり、ログスコアは高められてよい。しかしながら、タスクＣの３つの下流のタスク１０１のうち、タスクＤ以外のタスクＥおよびタスクＦは、正常に動作しているため、タスクＣが実際に障害の原因である可能性は低いと推定でき、そのため、ログスコアはそれほど高めないように設定されている。

また、制御部４０１は、例えば、タスクＧのログの出力頻度を決定する際に、上流のタスクＤのログスコアを考慮する。この場合、タスクＤのログスコアが高いため、タスクＧのログスコアを高めてよい（図５の（４））。そして、制御部４０１は、上流のタスクＤの影響で若干高められたログスコアに基づいてタスクＧのログの出力頻度を決定してよい。これは、タスクＤに障害が生じた場合、タスクＤの下流のタスクＧのログを調べることで、障害の波及の影響を調査し易くなるためである。

なお、図５に示す例では、タスクＢのログスコアを高めた結果、更に上流のタスクＡのログスコアも高められている。

以上で述べたように、実施形態では障害の発生する可能性が高いと推定されるタスク１０１があった場合に、その上流および下流のタスク１０１のログスコアも高められるように調整される。そして、高められたログスコアに基づいて、ログの出力頻度が決定される。そのため、例えば、障害の発生する可能性が高いと推定されるタスク１０１で実際に障害が起きたとする。この場合にも、その障害の起きたタスク１０１のログと、その上流および下流の少なくとも一方のタスク１０１のログの出力頻度が高められているため、障害の原因の追究や障害の波及する影響を効率的に調査することが可能になる。

続いて、分散ストリームデータ処理基盤３００で出力されるログの全体量の調整について述べる。分散ストリームデータ処理基盤３００の全体で出力されるログの量が多いと、分散ストリームデータ処理基盤３００にかかる負荷も高くなる。そのため、分散ストリームデータ処理基盤３００において出力されるログの量は、目標となる所定のログ数におおよそ近づくように調節されることが望ましい。そのため、以下で述べる実施形態では分散ストリームデータ処理基盤３００において所定期間に出力される全体のログ数が、所定のログ数に近づくように、各タスク１０１が出力するログ量を最適化する処理が実行される。なお、一実施形態において、ログ量の最適化の処理は、例えば、分散ストリームデータ処理基盤３００の管理を実行する管理装置が実行してよい。管理装置は、一例では、複数の情報処理装置３０１を代表する情報処理装置３０１であってよい。

図６は、実施形態に係る分散ストリームデータ処理基盤３００の全体のログ量の調節を例示する図である。管理装置の制御部４０１は、例えば、所定期間において分散ストリームデータ処理基盤３００に含まれるタスク１０１が出力したログの数を取得する（図６の（１））。なお、図６の例では、所定期間に出力されたログの総数は、１５００００００個であるものとする。

そして、管理装置の制御部４０１は、それぞれのタスク１０１に対して決定されているログスコアごとにログ数を集計する（図６の（２））。図６に示す例では、ログスコアを所定の範囲に区切り、各範囲に該当するログスコアを有するタスク１０１のログの数を集計してグラフにしている。

続いて、制御部４０１は、分散ストリームデータ処理基盤３００の全体のログ数が目標となる所定の値に近づくように、各タスク１０１におけるログの出力頻度を補正する（図６の（３））。図６の例では、所定期間に出力されたログの総数が１５００００００個であり、目標となるログ数が１０００００００個であるため、１０００００００／１５００００００＝２／３倍の出力頻度となるように、各タスク１０１のログの出力頻度を補正してよい。

以上で述べたようにすることで、分散ストリームデータ処理基盤３００で出力されるログの全体量を、分散ストリームデータ処理基盤３００に対して適切な量に調節することができる。そのため、分散ストリームデータ処理基盤３００にかかる処理負荷を抑えることができる。

以下、実施形態に係るログの出力をともなうタスク１０１の実行処理について説明する。図７は、実施形態に係るタスク１０１の実行処理の動作フローを例示する図である。例えば、情報処理装置３０１の制御部４０１は、情報処理装置３０１に配備されているタスク１０１の実行指示が入力されると、図７の動作フローを開始してよい。

ステップ７０１（以降、ステップを“Ｓ”と記載し、例えば、Ｓ７０１と表記する）において制御部４０１は、メッセージを受信するのを待機する。例えば、メッセージを受信すると、制御部４０１は、処理をＳ７０２に進めてよい。

Ｓ７０２において制御部４０１は、受信したメッセージの種別を判定する。メッセージ種別が情報処理装置３０１に配備されているタスク１０１に宛てたメッセージ８０１である場合、フローはＳ７０３に進む。

図８は、実施形態に係るタスク間のメッセージを例示する図である。図８（ａ）は、上流のタスク１０１から下流のタスク１０１へと送信されるメッセージ８０１を例示する図である。メッセージ８０１は、例えば、上流タスクＩＤ（identifier）、下流タスクＩＤ、上流タスクのログスコア、およびタスク処理用メッセージを含む。

上流タスクＩＤは、例えば、メッセージ８０１を送信した上流のタスク１０１を識別するための識別情報である。また、下流タスクＩＤは、例えば、メッセージ８０１の宛先である下流のタスク１０１を識別するための識別情報である。上流タスクのログスコアは、メッセージ８０１の送信時に上流タスクＩＤで識別される上流のタスク１０１に対して算出されているログスコアである。タスク処理用メッセージは、例えば、メッセージ８０１の宛先となる下流のタスク１０１の処理で利用される情報であってよい。タスク処理用メッセージは、例えば、上流のタスク１０１の実行結果として出力される情報であってよい。

Ｓ７０３において制御部４０１は、メッセージ８０１を受信すると、その応答として、応答メッセージ８０２を、メッセージ８０１の送信元のタスク１０１に返信する。

図８（ｂ）は、実施形態に係る応答メッセージ８０２を例示する図である。応答メッセージ８０２は、例えば、上流タスクＩＤ、下流タスクＩＤ、および下流タスクのログスコアの情報を含む。上流タスクＩＤは、例えば、メッセージ８０１を送信してきた上流のタスク１０１であって、応答メッセージ８０２の宛先となるタスク１０１を識別するための識別情報である。また、下流タスクＩＤは、例えば、メッセージ８０１の宛先であり、応答メッセージ８０２の送信元となる下流のタスク１０１を識別するための識別情報である。下流タスクのログスコアは、応答メッセージ８０２の送信時に下流のタスク１０１に対して算出されているログスコアである。例えば、情報処理装置３０１の記憶部４０２には、スコア情報９００が登録されていてよく、制御部４０１は、スコア情報９００から下流タスクのログスコアを取得してよい。

図９は、実施形態に係るスコア情報９００を例示する図である。図９の例では、スコア情報９００には、タスクＩＤと、ログスコアとが対応付けられたエントリが登録されている。スコア情報９００のタスクＩＤには、例えば、情報処理装置３０１に割り当てられているタスク１０１を識別するためのタスクＩＤが登録されていてよい。また、スコア情報９００のログスコアには、エントリのタスクＩＤで識別されるタスク１０１に対して求められたログスコアが登録されていてよい。なお、スコア情報９００は、例えば、後述する図１４の動作フローにおいて生成されて、情報処理装置３０１の記憶部４０２に記憶されてよい。そして、制御部４０１は、Ｓ７０３において、スコア情報９００を参照して、メッセージ８０１の下流タスクＩＤと一致するタスクＩＤのログスコアを、下流タスクのログスコアとして取得して応答メッセージ８０２を生成し、送信してよい。応答メッセージ８０２を送信することで、上流のタスク１０１に、下流のタスク１０１のログスコアを通知することができる。

続いて、Ｓ７０４において制御部４０１は、メッセージ８０１の送信先として指定されたタスク１０１を実行する。例えば、制御部４０１は、メッセージ８０１のタスク処理用メッセージに含まれる情報を用いて、メッセージ８０１の下流タスクＩＤに送信先として指定されたタスク１０１の処理を実行してよい。なお、制御部４０１は、例えば、タスク１０１の実行において出力依頼が出されたログメッセージを一時的に記憶部４０２に保存してよい。また、制御部４０１は、タスク１０１を実行すると、その実行に関する情報をタスク実行情報１０００に記録してよい。

図１０は、実施形態に係るタスク実行情報１０００を例示する図である。タスク実行情報１０００には、例えば、タスクＩＤ、タイムスタンプ、処理時間、およびＣＰＵ使用率を対応づけたエントリが登録されている。一例では、制御部４０１は、実行したタスク１０１のタスクＩＤおよび実行日時を表すタイムスタンプとともに、タスク１０１の処理にかかった処理時間と、タスク１０１に実行の際のＣＰＵの使用率の情報を対応づけてタスク実行情報１０００に登録してよい。

Ｓ７０５において制御部４０１は、例えば、実行したタスク１０１の下流のタスク１０１に対してメッセージ８０１を生成して、送信する。なお、制御部４０１は、例えば、実行したタスク１０１の識別情報をメッセージ８０１の上流タスクＩＤに設定してよい。また、制御部４０１は、実行したタスク１０１のタスクＩＤと対応するスコア情報９００のログスコアをメッセージ８０１の上流タスクのログスコアに設定し、およびタスク１０１の実行結果をメッセージ８０１のタスク処理用メッセージに設定してよい。制御部４０１は、下流のタスク１０１の識別情報をメッセージ８０１の下流タスクＩＤに設定してよい。そして、制御部４０１は、生成したメッセージ８０１を下流のタスク１０１に宛てて送信してよい。

Ｓ７０６において制御部４０１は、下流のタスク１０１から応答メッセージ８０２を受信する。なお、応答メッセージ８０２の上流タスクＩＤには、例えば、Ｓ７０５でメッセージ８０１を送信したタスク１０１のタスクＩＤが登録されている。また、応答メッセージ８０２の下流タスクＩＤおよび下流タスクのログスコアには、Ｓ７０５のメッセージ８０１の送信先であり、および、それに対する応答メッセージ８０２の送信元であるタスク１０１のタスクＩＤとログスコアがそれぞれ登録されている。

そして、Ｓ７０７において制御部４０１は、Ｓ７０４で実行したタスク１０１に対するログスコアを計算する。なお、ログスコアの計算の詳細については、図１４を参照して後述する。

Ｓ７０８において制御部４０１は、Ｓ７０７でタスク１０１に対して算出したログスコアに基づいて、ログメッセージを出力するか否かを判定する。例えば、タスク１０１は、実行の際にログの出力を依頼する出力依頼を出力する。そして、Ｓ７０８では制御部４０１は、出力依頼のあったログメッセージを記憶部４０２のログデータに出力するか否かを判定してよい。なお、ログメッセージを出力するか否かの判定処理の詳細については、例えば、図１５を参照して後述する。

Ｓ７０８の処理で出力すると判定された場合、Ｓ７０９において制御部４０１は、記憶部４０２に一時保存したログメッセージを記憶部４０２のログデータに出力して記録する。また、この場合、制御部４０１は、以下に述べるログ計数情報１１００において、実行したタスク１０１と対応する出力数に１を可算して値を更新し、フローはＳ７０１に戻る。

図１１は、実施形態に係るログ計数情報１１００を例示する図である。ログ計数情報１１００には、例えば、情報処理装置３０１に割り当てられているタスク１０１のタスクＩＤと対応づけて、ログメッセージの出力数が登録されている。図１１に登録されているログメッセージの出力数は、例えば、所定期間の間に、Ｓ７０９において実際に出力されたログメッセージの数であってよい。一例では、ログの出力数をカウントする所定期間は、以下に述べるＳ７１０の処理の最新の実行でログスコア補正メッセージ１２００が記憶部４０２に記憶されてから現在までの期間であってよい。

また、Ｓ７０２においてメッセージ種別がログスコア補正メッセージ１２００である場合、フローはＳ７１０に進む。

図１２は、実施形態に係るログスコア補正メッセージ１２００を例示する図である。ログスコア補正メッセージ１２００には、例えば、上述の図６で述べたように、分散ストリームデータ処理基盤３００に含まれる複数のタスク１０１のそれぞれのタスクＩＤと対応づけて、ログの出力頻度を調節するための補正値が登録されている。

Ｓ７１０において制御部４０１は、受信したログスコア補正メッセージ１２００を記憶部４０２に保存し、フローはＳ７０１に戻る。なお、記憶部４０２に既にログスコア補正メッセージ１２００が記憶されている場合、制御部４０１は、受信した新たなログスコア補正メッセージ１２００で、記憶部４０２に記憶されているログスコア補正メッセージ１２００を更新してよい。

また、Ｓ７０２においてメッセージ種別が集計依頼である場合、フローはＳ７１１に進む。なお、集計依頼は、上述の図６で述べたように、例えば、分散ストリームデータ処理基盤３００を管理する管理装置が、所定期間に分散ストリームデータ処理基盤３００で出力されるログの総数を集計するために送信するメッセージである。集計依頼は、例えば、メッセ―ジの種別が集計依頼であることを示す情報を含んでよく、制御部４０１は、この情報を参照してメッセージが集計依頼であることを特定してよい。

Ｓ７１１において制御部４０１は、集計依頼を受信すると、集計依頼応答メッセージ１３００を生成して集計依頼を送信してきた情報処理装置３０１に応答し、フローはＳ７０１に戻る。

図１３は、実施形態に係る集計依頼応答メッセージ１３００を例示する図である。集計依頼応答メッセージ１３００は、例えば、タスクＩＤ、ログスコア、および出力数が対応付けられたエントリを含む。情報処理装置３０１の制御部４０１は、例えば、管理装置から集計依頼を受信すると、自装置に配備されているそれぞれのタスク１０１のタスクＩＤと、ログスコアと、ログメッセージの出力数とを含む集計依頼応答メッセージ１３００を生成する。なお、集計依頼応答メッセージ１３００に登録されるログスコアは、例えば、スコア情報９００から取得することができる。また、集計依頼応答メッセージ１３００に登録される出力数は、例えば、ログ計数情報１１００から取得することができる。そして、情報処理装置３０１の制御部４０１は、例えば、Ｓ７１１において生成した集計依頼応答メッセージ１３００を管理装置として動作する情報処理装置３０１に送信する。

以上の図７の動作フローによれば、例えば、タスク１０１の実行の際にログスコアを計算し、ログスコアに基づいてログメッセージを出力することができる。また、図７の動作フローによれば、例えば、分散ストリームデータ処理基盤３００の全体でのログ量を調節するための補正値を取得したり、管理装置からの集計依頼に応じてタスク１０１に対するログスコアとログの出力数を管理装置に通知したりすることができる。

続いて、ログスコアの算出について更に詳細に説明する。図１４は、実施形態に係るログスコアの計算処理を例示する図である。制御部４０１は、例えば、図７のＳ７０７の処理に進むと、図１４の動作フローを開始してよい。

Ｓ１４０１において制御部４０１は、情報処理装置３０１に配備されている少なくとも１つのタスク１０１のそれぞれについて、ログスコアを計算する。例えば、制御部４０１は、タスク実行情報１０００に登録されている過去のタスク１０１の実行に関する情報に基づいて、タスク１０１のログスコアを計算してよい。以下では、タスク１０１の実行に関する情報として、タスク１０１の処理時間を用いてログスコアを計算する例を述べる。

例えば、タスク１０１の処理時間が、普段の処理時間よりも著しく長い場合、そのタスク１０１には障害が起こる可能性が高いと推定することができる。そのため、タスク１０１の普段の処理時間からの違いに基づいて、障害が発生する可能性を評価したログスコアを求めることができる。例えば、直近過去１０回のタスク１０１の処理時間の平均をＴ_ａｖｅとする。また、今回のタスク１０１の処理時間をＴ_ｃｕｒｒとする。この場合に、タスク１０１に対するログスコアＳ_ｔａｓｋは、例えば、以下の式１で計算することができる。なお、式１においてａｂｓは絶対値を表す。
Ｓ_ｔａｓｋ＝ａｂｓ_（Ｔ_{ｃｕｒｒ－}Ｔ_{ａｖｅ）／}Ｔ_ａｖｅ・・・式１

式１によれば、過去の処理時間からの違いによりログスコアを評価することができる。また、別の実施形態では、タスク１０１のエラーの発生頻度、タスク１０１が配備されてからの経過時間、タスク１０１がログの出力依頼のメッセージを出力する頻度などを用いてログスコアが評価されてもよい。

Ｓ１４０２において制御部４０１は、上流のタスク１０１から受信したメッセージ８０１に基づいて、上流のタスク１０１のログスコアを決定する。例えば、上流のタスク１０１が１つである場合には、制御部４０１は、その上流のタスク１０１から受信した最新のメッセージ８０１の上流タスクのログスコアをそのまま用いてよい。また、タスク１０１にデータを送信してくる上流のタスク１０１が複数ある場合、制御部４０１は、上流のタスク１０１のそれぞれから受信した最新のメッセージ８０１の上流タスクのログスコアを代表する値を上流のタスク１０１のログスコアとして決定してよい。例えば、制御部４０１は、以下の式２に示すように、複数の上流のタスク１０１のログスコアの平均を、上流のタスク１０１のログスコア：Ｓ_{ｕｐｐｅｒ}として用いてよい。なお、式２において、ａｖｅは平均を表し、また、Ｓ_ｕ１，Ｓ_ｕ２，Ｓ_ｕ３，・・・は、複数の上流のタスク１０１のそれぞれのログスコアを表している。
Ｓ_{ｕｐｐｅｒ}＝ａｖｅ（Ｓ_ｕ１，Ｓ_ｕ２，Ｓ_ｕ３，・・・）・・・式２

Ｓ１４０３において制御部４０１は、下流のタスク１０１から受信した応答メッセージ８０２に基づいて、下流のタスク１０１のログスコアを決定する。例えば、下流のタスク１０１が１つである場合には、制御部４０１は、その下流のタスク１０１から受信した最新の応答メッセージ８０２の下流タスクのログスコアをそのまま用いてよい。タスク１０１にデータを送信してくる下流のタスク１０１が複数ある場合、制御部４０１は、下流のタスク１０１のそれぞれから受信した最新の応答メッセージ８０２の下流タスクのログスコアを代表する値を下流のタスク１０１のログスコアとして決定してよい。例えば、制御部４０１は、以下の式３に示すように、複数の下流のタスク１０１のログスコアの平均を、下流のタスク１０１のログスコア：Ｓ_ｄｏｗｎとして用いてよい。なお、式３において、ａｖｅは平均を表し、また、Ｓ_ｄ１，Ｓ_ｄ２，Ｓ_ｄ３，・・・は、複数の下流のタスク１０１のそれぞれのログスコアを表している。
Ｓ_ｄｏｗｎ＝ａｖｅ（Ｓ_ｄ１，Ｓ_ｄ２，Ｓ_ｄ３，・・・）・・・式３

Ｓ１４０４において制御部４０１は、隣接するタスク１０１のログスコアを用いてログスコアを計算する。例えば、制御部４０１は、Ｓ１４０２で求めたタスク１０１の上流のタスク１０１のログスコアと、Ｓ１４０３で求めたタスク１０１の下流のタスク１０１のログスコアとを用いて、タスク１０１のログスコアを計算してよい。一例では、制御部４０１は、式４に示すように、Ｓ１４０１のタスク１０１のログスコアと、Ｓ１４０２の上流のタスク１０１のログスコアと、Ｓ１４０３の下流のタスク１０１のログスコアとを所定の比率で寄与させてログスコア：Ｓ_{ｃｕｒｒｅｎｔ}を計算する。
Ｓ_{ｃｕｒｒｅｎｔ}＝０．５×Ｓ_ｔａｓｋ＋０．１×Ｓ_{ｕｐｐｅｒ}＋０．４×Ｓ_ｄｏｗｎ・・・式４

例えば、以上の式４により、隣接するタスク１０１のログスコアを、タスク１０１のログスコアに寄与させることができる。それにより、例えば、或るタスク１０１に他のタスク１０１よりも高いログスコアが設定されている場合に、その値を隣接するタスク１０１のログスコアにも伝搬させることができる。なお、タスク１０１で障害が発生した場合、その原因は、そのタスク１０１の下流よりも上流のタスク１０１に存在する可能性が高い。そのため、式４では、下流のタスク１０１のログスコアＳ_ｄｏｗｎの係数を、上流のタスクのログスコアＳ_{ｕｐｐｅｒ}の係数よりも高く設定し、上流のタスク１０１よりも下流のタスク１０１のログスコアの影響をより受け易くしている。また、式４では、上流のタスク１０１と下流のタスク１０１との両方のログスコアを、タスク１０１のログスコアの計算に用いる例を示しているが、実施形態はこれに限定されるものではない。別の実施形態では、上流のタスク１０１と下流のタスク１０１との一方のみをタスク１０１のログスコアの計算に用いてもよい。

続いて、Ｓ１４０５において制御部４０１は、ログスコアの変化を抑えるように調整する。例えば、ログスコアの値が急激に下がり、ログをとる頻度を急激に下げてしまった場合に、障害の原因を追究するための十分なログを取り損ねてしまうことがある。そのため、Ｓ１４０５では、制御部４０１は、ログスコアの変化を緩やかにする調整を行っている。例えば、以下の式５に示すように、前回の図１４の動作フローの実行においてＳ１４０５で計算されたログスコア：Ｓ_{ｂａｓｅ－１}に、今回Ｓ１４０４で計算されたＳ_{ｃｕｒｒｅｎｔ}を所定の比率で寄与させることで、ログスコアの変化を抑える調整が可能である。
Ｓ_ｂａｓｅ＝０．５×Ｓ_{ｃｕｒｒｅｎｔ}＋０．５×Ｓ_{ｂａｓｅ－１} ・・・式５

式５では、前回の図１４の動作フローの実行においてＳ１４０５で計算されたログスコア：Ｓ_{ｂａｓｅ－１}と、今回Ｓ１４０４で計算されたＳ_{ｃｕｒｒｅｎｔ}とを５０％の割合で寄与させてログスコアＳ_ｂａｓｅを求めている。なお、制御部４０１は、Ｓ１４０５でタスク１０１に対して求めたログスコアＳ_ｂａｓｅを、タスク１０１のタスクＩＤと対応づけてスコア情報９００に登録してよい。スコア情報９００に、Ｓ１４０５でログスコアを求めたタスク１０１のタスクＩＤを含むエントリが既に登録されている場合には、Ｓ１４０５で求めた最新のログスコアでスコア情報９００のエントリのログスコアを更新してよい。

Ｓ１４０６において制御部４０１は、全体のログ数を最適化するように補正を行う。例えば、図１６を参照して後述するように、分散ストリームデータ処理基盤３００の管理を実行する管理装置は、全体のログ数を最適化するようにタスク１０１に対する補正値を求めて、その補正値をタスク１０１を実行する情報処理装置３０１に通知する。Ｓ１４０６の処理では制御部４０１は、タスク１０１に対する補正値が分散ストリームデータ処理基盤３００の管理を実行する管理装置から通知されている場合、通知された補正値でＳ１４０５のＳ_ｂａｓｅを補正して、最終的なログスコアＳを求めてよい。なお、分散ストリームデータ処理基盤３００の稼働初期など、まだ、タスク１０１に対する補正値が管理装置から通知されていない場合、Ｓ１４０６の処理は省略されてよい。式６は、Ｓ１４０６の処理で実行するタスク１０１のログスコアの補正を例示する式である。
Ｓ＝ｍｉｎ（１，ｍａｘ（０，Ｓ_ｂａｓｅ×Ｗ））・・・式６

なお、式６においてＷは、タスク１０１に対する補正値である。また、式６では、ｍｉｎ，ｍａｘの関数を用いてログスコアＳの値が０から１に収まるようにしている。Ｓ１４０６の処理が完了すると、図１４の動作フローは終了し、フローはＳ７０８に進む。以上の図１４の動作フローにより、制御部４０１は、タスク１０１のログスコアを取得することができる。

続いて、図７のＳ７０８で実行されるログ出力判定処理について説明する。図１５は、実施形態に係るログ出力判定処理を例示する図である。制御部４０１は、例えば、Ｓ７０８の処理に進むと、図１５の動作フローを開始してよい。

Ｓ１５０１において制御部４０１は、ログスコアに基づいて、ログの出力間隔を計算する。ログの出力間隔は、例えば、以下の式７により計算することができる。なお、式７においてｒｏｕｎｄは、小数点以下を四捨五入する関数であり、それによりＮ_{ｉｎｔｅｒｖａｌ}の値を整数化している。
Ｎ_{ｉｎｔｅｒｖａｌ}＝ｒｏｕｎｄ（１／Ｓ）・・・式７

そして、Ｓ１５０２で制御部４０１は、前回のログメッセージの出力以降に出力依頼が出されたログメッセージの数と、Ｓ１５０１で求めたログの出力間隔とを比較して、ログメッセージを出力するか否かを判定する。例えば、制御部４０１は、前回のログメッセージの出力以降に出力されたログの出力依頼のメッセージの数Ｎ_{ｂｅｆｏｒｅ}が、Ｎ_{ｉｎｔｅｒｖａｌ}よりも大きい場合（Ｎ_{ｂｅｆｏｒｅ}＞Ｎ_{ｉｎｔｅｒｖａｌ}）に、ログメッセージを出力すると判定してよい。Ｓ１５０２の処理が完了すると、図１５の動作フローは終了し、フローはＳ７０９に進む。以上の図１５の動作フローにより、制御部４０１は、図７の動作フローにおいて実行したタスク１０１で出力されたログの出力依頼に対して、ログメッセージを出力するか否かを判定することができる。それによって、ログスコアに基づいてタスク１０１のログメッセージの出力頻度が決定される。

続いて、全体のログ量の最適化について説明する。図１６は、分散ストリームデータ処理基盤３００の管理を実行する管理装置の制御部４０１が実行するログ量の最適化処理の動作フローを例示する図である。なお、分散ストリームデータ処理基盤３００の管理を実行する管理装置は、一例では、分散ストリームデータ処理基盤３００に含まれる複数の情報処理装置３０１を代表する情報処理装置３０１であってよい。管理装置の制御部４０１は、分散ストリームデータ処理基盤３００が起動すると図１６の動作フローを開始してよい。

Ｓ１６０１において管理装置の制御部４０１は、所定時間待機する。一例では、分散ストリームデータ処理基盤３００の管理者は、分散ストリームデータ処理基盤３００内でのログの出力の傾向を見ることが可能となる待ち時間を見積もって、所定時間として予め設定してよい。

Ｓ１６０２において管理装置の制御部４０１は、分散ストリームデータ処理基盤３００に含まれる情報処理装置３０１にログスコアの集約依頼を送信する。例えば、管理装置の制御部４０１は、分散ストリームデータ処理基盤３００においてタスク１０１の実行を担う複数の情報処理装置３０１のそれぞれに集約依頼を送信してよい。

Ｓ１６０３において管理装置の制御部４０１は、各情報処理装置３０１からの応答を待機する。なお、各情報処理装置３０１からの応答は、例えば、上述の集計依頼応答メッセージ１３００であってよい。

Ｓ１６０４において管理装置の制御部４０１は、各情報処理装置３０１からの集計依頼応答メッセージ１３００の受信が完了すると、受信した集計依頼応答メッセージ１３００を用いて、補正値を計算する。例えば、各タスク１０１のログメッセージの出力数をＮ_ｔ１，Ｎ_ｔ２，Ｎ_ｔ３，・・・とすると、以下の式８で補正値Ｗが求められてよい。なお、Ｚは、目標となるログメッセージ数であり、分散ストリームデータ処理基盤３００の管理者が予め設定することができる。
Ｗ＝Ｚ／（Ｎ_ｔ１＋Ｎ_ｔ２＋Ｎ_ｔ３＋・・・）・・・式８

Ｓ１６０５において管理装置の制御部４０１は、求めた補正値を含むログスコア補正メッセージ１２００を生成して、各情報処理装置３０１に送信し、本動作フローは終了する。

図１６の動作フローによれば、管理装置の制御部４０１は、分散ストリームデータ処理基盤３００の全体のログ量を最適化する補正値を、各情報処理装置３０１に通知することができる。

なお、図１６の動作フローでは、分散ストリームデータ処理基盤３００に含まれる全てのタスク１０１に対して一律の補正値Ｗを決定し、補正を行う例を述べているが、実施形態はこれに限定されるものではない。例えば、別の実施形態では、タスク１０１に応じて異なる値でログの出力頻度を補正するための補正値が定められてもよい。

例えば、集計依頼応答メッセージ１３００で通知されたログスコアが高いタスク１０１は、頻繁にログを出力していることが推定されるため、出力するログの量を他のタスクよりも大きく減らしても、障害の解析に十分なログが取得できる可能性が高い。そのため、例えば、式８で求められた補正値Ｗが、０．８であった場合に、ログスコアの高いタスク１０１にはより低い補正値（例えば、０．７）などを設定してもよい。一方で、集計依頼応答メッセージ１３００で通知されたログスコアが低いタスク１０１は、そもそも出力しているログの数が少ないため、それ以上少なくすると障害の発生時などに利用できるログが不十分になる可能性がある。そのため、例えば、式８で求められた補正値Ｗが、０．８であった場合に、ログスコアの低いタスク１０１にはより高い補正値（例えば、０．９）などを設定してもよい。このように、制御部４０１は、タスク１０１ごとに、ログスコアに基づいて補正値を調整してもよい。

以上で述べたように、上述の実施形態によれば、障害が発生する可能性の高いタスク１０１がある場合に、そのタスク１０１の周辺のタスク１０１のログの出力頻度も高められるため、トレースログなどを効果的に収集することが可能である。その結果、複数のタスク１０１が影響するような障害を効率的に発見することが可能である。

以上において、実施形態を例示したが、実施形態はこれに限定されるものではない。例えば、上述の動作フローは例示であり、実施形態はこれに限定されるものではない。可能な場合には、動作フローは、処理の順番を変更して実行されてもよく、別に更なる処理を含んでもよく、又は、一部の処理が省略されてもよい。例えば、図１４のＳ１４０２とＳ１４０３の処理は順序を入れ替えて実行してもよい。

また、上述の実施形態のログスコアの計算において、分散ストリームデータ処理基盤３００にタスク１０１が配備されてからの経過時間が考慮されてもよい。例えば、タスク１０１が配備されて間もない状況では、タスク１０１の開発者の予期していないバグなどが含まれている可能性が高い。そのため、制御部４０１は、このように配備されて間もないタスク１０１のログスコアを、より高い値に補正する処理を行ってもよい。

また、上述の実施形態では、ログスコアの値が数値として大きい値であるほど、ログの出力頻度が高くなる例を述べている。しかしながら、実施形態はこれに限定されるものではなく、例えば、ログスコアの値が小さいほど、ログの出力頻度が高くなるように、ログスコアが評価されてもよい。この場合、ログスコアの値が小さいことが、ログスコアが高いことを示してよい。

また、上述の実施形態では、複数の上流タスク１０１のログスコアを代表する値および複数の下流タスク１０１のログスコアを代表する値として、平均値を用いる例を示しているが、実施形態はこれに限定されるものではない。例えば、別の実施形態では、中央値などその他の統計値が代表値として用いられてもよい。

また、上述の実施形態において、図８に示すタスク間のメッセージは、例えば、宛先のタスク１０１が他の情報処理装置３０１に配置されている場合には、宛先のタスク１０１が配置されている情報処理装置３０１のアドレスなどの情報を更に含んでもよい。

また、上述の実施形態では、ログスコアを補正値で補正する例が示されているが、実施形態は、これに限定されるものではなく、補正値を、その他の値の補正に用いてタスク１０１のログの出力頻度が調節されてもよい。例えば、別の実施形態では、上述のＳ１４０６の処理の代わりに、Ｓ１５０１において、下記の式９でログの出力間隔Ｎ_{ｉｎｔｅｒｖａｌ}を補正値Ｗの逆数で補正する処理が実行されてもよい。この場合、制御部４０１は、得られたＮ_ｃをＮ_{ｉｎｔｅｒｖａｌ}の代わりに用いて、Ｓ１５０２の処理を実行してよい。
Ｎ_ｃ＝Ｎ_{ｉｎｔｅｒｖａｌ}×１／Ｗ・・・式９

なお、上述の実施形態において、Ｓ１４０１の処理では、情報処理装置３０１の制御部４０１は、例えば、取得部４１１として動作する。また、Ｓ７０９およびＳ１４０２からＳ１４０６の処理では、情報処理装置３０１の制御部４０１は、例えば、出力部４１２として動作する。図１６の動作フローの処理では、情報処理装置３０１の制御部４０１は、例えば、決定部４１３として動作する。

図１７は、実施形態に係る情報処理装置３０１および管理装置を実現するためのコンピュータ１７００のハードウェア構成を例示する図である。図１７の情報処理装置３０１および管理装置を実現するためのハードウェア構成は、例えば、プロセッサ１７０１、メモリ１７０２、記憶装置１７０３、読取装置１７０４、通信インタフェース１７０６、及び入出力インタフェース１７０７を備える。なお、プロセッサ１７０１、メモリ１７０２、記憶装置１７０３、読取装置１７０４、通信インタフェース１７０６、入出力インタフェース１７０７は、例えば、バス１７０８を介して互いに接続されている。

プロセッサ１７０１は、例えば、シングルプロセッサであっても、マルチプロセッサやマルチコアであってもよい。プロセッサ１７０１は、メモリ１７０２を利用して例えば上述の動作フローの手順を記述したプログラムを実行することにより、上述した制御部４０１の一部または全部の機能を提供する。例えば、情報処理装置３０１および管理装置のプロセッサ１７０１は、記憶装置１７０３に格納されているプログラムを読み出して実行することで、取得部４１１、出力部４１２、および決定部４１３として動作する。

メモリ１７０２は、例えば半導体メモリであり、ＲＡＭ領域及びＲＯＭ領域を含んでいてよい。記憶装置１７０３は、例えばハードディスク、フラッシュメモリ等の半導体メモリ、又は外部記憶装置である。なお、ＲＡＭは、Random Access Memoryの略称である。また、ＲＯＭは、Read Only Memoryの略称である。

読取装置１７０４は、プロセッサ１７０１の指示に従って着脱可能記憶媒体１７０５にアクセスする。着脱可能記憶媒体１７０５は、例えば、半導体デバイス（ＵＳＢメモリ等）、磁気的作用により情報が入出力される媒体（磁気ディスク等）、光学的作用により情報が入出力される媒体（ＣＤ－ＲＯＭ、ＤＶＤ等）などにより実現される。なお、ＵＳＢは、Universal Serial Busの略称である。ＣＤは、Compact Discの略称である。ＤＶＤは、Digital Versatile Diskの略称である。

なお、情報処理装置３０１および管理装置の記憶部４０２は、例えばメモリ１７０２、記憶装置１７０３、及び着脱可能記憶媒体１７０５を含んでよい。例えば、情報処理装置３０１の記憶装置１７０３には、スコア情報９００、タスク実行情報１０００、ログ計数情報１１００、およびログスコア補正メッセージ１２００が格納されてよい。また、例えば、管理装置の記憶装置１７０３には、ログスコア補正メッセージ１２００および集計依頼応答メッセージ１３００が格納されてよい。

通信インタフェース１７０６は、プロセッサ１７０１の指示に従ってネットワークを介してデータを送受信する。通信インタフェース１７０６は、上述の通信部４０３の一例である。入出力インタフェース１７０７は、例えば、入力装置及び出力装置との間のインタフェースであってよい。入力装置は、例えばユーザからの指示を受け付けるキーボードやマウスなどのデバイスである。出力装置は、例えばディスプレーなどの表示装置、及びプリンタなどの印刷装置である。

実施形態に係る各プログラムは、例えば、下記の形態で情報処理装置３０１および管理装置に提供される。
（１）記憶装置１７０３に予めインストールされている。
（２）着脱可能記憶媒体１７０５により提供される。
（３）プログラムサーバなどのサーバから提供される。

なお、図１７を参照して述べた情報処理装置３０１および管理装置を実現するためのコンピュータ１７００のハードウェア構成は例示であり、実施形態はこれに限定されるものではない。例えば、上述の制御部４０１の一部または全部の機能がＦＰＧＡ及びＳｏＣなどによるハードウェアとして実装されてもよい。なお、ＦＰＧＡは、Field Programmable Gate Arrayの略称である。ＳｏＣは、System-on-a-chipの略称である。

以上において、いくつかの実施形態が説明される。しかしながら、実施形態は上記の実施形態に限定されるものではなく、上述の実施形態の各種変形形態及び代替形態を包含するものとして理解されるべきである。例えば、各種実施形態は、その趣旨及び範囲を逸脱しない範囲で構成要素を変形して具体化できることが理解されよう。また、前述した実施形態に開示されている複数の構成要素を適宜組み合わせることにより、種々の実施形態が実施され得ることが理解されよう。更には、実施形態に示される全構成要素からいくつかの構成要素を削除して又は置換して、或いは実施形態に示される構成要素にいくつかの構成要素を追加して種々の実施形態が実施され得ることが当業者には理解されよう。

１０１：タスク
３００：分散ストリームデータ処理基盤
３０１：情報処理装置
３０２：センサ
３０５：ネットワーク
４０１：制御部
４０２：記憶部
４０３：通信部
４１１：取得部
４１２：出力部
４１３：決定部
１７００：コンピュータ
１７０１：プロセッサ
１７０２：メモリ
１７０３：記憶装置
１７０４：読取装置
１７０５：着脱可能記憶媒体
１７０６：通信インタフェース
１７０７：入出力インタフェース
１７０８：バス

Claims

分散ストリームデータ処理基盤において実行される複数のタスクのそれぞれのタスクごとに、障害の発生のし易さと関連する指標に基づいてログスコアを取得する取得部と、
前記複数のタスクのうちのそれぞれのタスクについて、前記タスクのログスコアと、前記タスクの上流に位置する上流タスクおよび前記タスクの下流に位置する下流タスクの少なくとも一方のログスコアとに基づく出力頻度で前記タスクのログメッセージを出力する出力部と、
を含む、情報処理装置。
前記複数のタスクにおいて、第１のタスクの下流には第１の下流タスクが配置されており、および第２のタスクの下流には、前記第１の下流タスクと第２の下流タスクが配置されており、
前記出力部は、前記第１の下流タスクのログスコアが前記第２の下流タスクよりも高い場合に、前記第１のタスクのログメッセージを、前記第２のタスクよりも高い出力頻度で出力する、ことを特徴とする請求項１に記載の情報処理装置。
前記複数のタスクにおいて、第３のタスクの上流には第１の上流タスクが配置されており、および第４のタスクの上流には、前記第１の上流タスクと第２の上流タスクが配置されており、
前記出力部は、前記第１の上流タスクのログスコアが前記第２の上流タスクよりも高い場合に、前記第３のタスクの前記ログメッセージを、前記第４のタスクよりも高い出力頻度で出力する、ことを特徴とする請求項１または２に記載の情報処理装置。
前記出力部は、前記分散ストリームデータ処理基盤において出力されるログメッセージの総数を所定の数に近づけるように設定されている補正値に基づいて、前記タスクのログメッセージの出力頻度を調節する、ことを特徴とする請求項１に記載の情報処理装置。
所定期間に、前記複数のタスクのそれぞれにおいて出力された前記ログメッセージの出力数に基づいて、前記補正値を決定する決定部を更に備える、請求項４に記載の情報処理装置。
分散ストリームデータ処理基盤において実行される複数のタスクのそれぞれのタスクごとに、障害の発生のし易さと関連する指標に基づいてログスコアを取得し、
前記複数のタスクのうちのそれぞれのタスクについて、前記タスクのログスコアと、前記タスクの上流に位置する上流タスクおよび前記タスクの下流に位置する下流タスクの少なくとも一方のログスコアとに基づく出力頻度で前記タスクのログメッセージを出力する、
ことを含む、情報処理装置が実行するログ制御方法。
分散ストリームデータ処理基盤において実行される複数のタスクのそれぞれのタスクごとに、障害の発生のし易さと関連する指標に基づいてログスコアを取得し、
前記複数のタスクのうちのそれぞれのタスクについて、前記タスクのログスコアと、前記タスクの上流に位置する上流タスクおよび前記タスクの下流に位置する下流タスクの少なくとも一方のログスコアとに基づく出力頻度で前記タスクのログメッセージを出力する、
処理を情報処理装置に実行させるためのログ制御プログラム。