(57)【要約】【課題】端末を効率的に各コンポーネントの実行ログの記録に割り振り、端末がそれに応じて効率的に実行ログを記録することができる装置、システム及びその方法を提供する。【解決手段】診断ログ記録クライアント２００と通信可能に構成される診断情報配布サーバ１００であって、コンポーネントの実行時に障害が発生したことを特定する障害情報１０を受信する情報受信部１１０と、診断情報３０を生成する診断情報生成部１２０と、障害情報１０に基づいて障害処理情報４０を生成する障害情報処理部１３０と、障害処理情報４０に基づいて、診断情報３０を配布する診断ログ記録クライアント２００を特定する情報である記録ポリシー５０を生成する記録ポリシー生成部１４０と、記録ポリシー５０に従い診断情報を診断ログ記録クライアント２００に配布する情報送信部１５０と、を備える。【選択図】図６
2010117934.tif 000002
【特許請求の範囲】
【請求項１】
コンポーネントの障害を診断するための診断ログを記録する診断ログ記録端末を含む配属端末と通信可能に構成される診断情報配布サーバであって、
少なくとも前記診断ログ記録端末において前記コンポーネントの実行時に障害が発生したことを特定する障害情報を、前記診断ログ記録端末から受信するサーバ側受信手段と、
前記診断ログの記録対象となる前記コンポーネントを特定するコンポーネント情報、及び前記コンポーネントごとに前記診断ログの記録箇所を特定する記録箇所特定情報を含む診断情報を生成する診断情報生成手段と、
前記配属端末から受信した前記障害情報に基づいて、障害発生回数に関する障害処理情報を生成する障害情報処理手段と、
前記障害処理情報に基づいて、前記診断情報の配布対象の前記診断ログ記録端末を特定する情報である端末特定情報を生成する端末特定情報生成手段と、
前記端末特定情報に従い前記診断情報を前記診断ログ記録端末に配布するサーバ側送信手段と、
を備える診断情報配布サーバ。
【請求項２】
前記診断ログが記録されるまでに要する時間である診断ログ記録期間の期待値が与えられた場合には、
前記障害情報処理手段は、前記配属端末それぞれにおいて前記コンポーネント実行時に発生する単位時間当たりの平均障害発生回数を導出し、
前記端末特定情報生成手段は、前記単位時間当たりの平均障害発生回数に基づいて、前記診断ログ記録期間の平均値が前記期待値と同値となるように前記端末特定情報を生成すること、
を特徴とする請求項１に記載の診断情報配布サーバ。
【請求項３】
前記診断ログが記録されるまでに発生する障害回数の期待値が与えられた場合には、
前記障害情報処理手段は、前記配属端末それぞれにおいて前記コンポーネント実行時に発生する単位時間当たりの平均障害発生回数を導出するとともに前記単位時間当たりの平均障害発生回数の合計を導出し、
前記端末特定情報生成手段は、前記単位時間当たりの平均障害発生回数及び前記単位時間当たりの平均障害発生回数の合計に基づいて、前記診断ログが記録されるまでに発生する障害の回数の平均値が前記期待値と同値となるように前記端末特定情報を生成すること、
を特徴とする請求項１に記載の診断情報配布サーバ。
【請求項４】
前記障害情報には、障害の深刻度を特定する障害深刻度特定情報が含まれており、
前記端末特定情報生成手段は、前記深刻度に応じて前記端末特定情報を生成すること、
を特徴とする請求項１に記載の診断情報配布サーバ。
【請求項５】
前記障害情報処理手段は、前記配属端末から受信した前記障害情報を蓄積し、所定期間経過後に前記障害処理情報を導出する処理を行うこと、
を特徴とする請求項１〜３の何れか一項に記載の診断情報配布サーバ。
【請求項６】
前記診断ログを解析して、前記診断ログの記録対象となるコンポーネントの箇所を特定した診断結果を送信する診断ログ解析サーバと通信可能に構成され、
前記診断情報生成手段は、前記診断結果に基づいて前記記録箇所特定情報を含む診断情報を更新し、
前記サーバ側送信手段は、前記診断情報生成手段により更新された前記診断情報を前記診断ログ記録端末に送信すること、
を特徴とする請求項１に記載の診断情報配布サーバ。
【請求項７】
診断情報配布サーバと通信可能に構成され、コンポーネントを実行可能に構成されるとともに前記コンポーネントの障害を診断するための診断ログを記録する診断ログ記録端末であって、
前記診断情報配布サーバから前記診断ログの記録対象となる前記コンポーネントを特定するコンポーネント情報、及び前記コンポーネントごとに前記診断ログの記録箇所を特定する記録箇所特定情報を含む診断情報を受信する端末側受信手段と、
実行した前記コンポーネントに障害が発生した場合には、少なくとも当該診断ログ記録端末において前記コンポーネントの実行時に障害が発生したことを特定する障害情報を生成する障害情報生成手段と、
前記コンポーネント情報により特定される前記コンポーネントに障害が発生した場合には、前記記録箇所特定情報に基づいて前記診断ログを記録する診断ログ記録手段と、
前記障害情報を前記診断情報配布サーバへ送信する端末側送信手段と、
を備える診断ログ記録端末。
【請求項８】
前記端末側送信手段は、前記診断ログを解析し診断結果を前記診断情報配布サーバへ送信する診断ログ解析サーバに対して、前記診断ログを送信すること、
を特徴とする請求項７に記載の診断ログ記録端末。
【請求項９】
前記診断ログ記録手段は、前記コンポーネント特定情報により特定されるコンポーネントの実行開始を検知した後に前記コンポーネントの前記診断ログを記録すること、
を特徴とする請求項７又は８に記載の診断ログ記録端末。
【請求項１０】
前記記録箇所特定情報は、記録対象となる前記コンポーネント上の実行命令を特定する情報を含み、
前記診断ログ記録手段は、前記実行命令が発生するアドレスを特定し、前記コンポーネントの実行が前記アドレスに至った際に、前記診断ログを記録することを特徴とする請求項７〜９の何れか一項に記載の診断ログ記録端末。
【請求項１１】
コンポーネントを実行可能に構成されるとともに前記コンポーネントの障害を診断するための診断ログを記録する診断ログ記録端末と、前記診断ログ記録端末を含む配属端末と通信可能な診断情報配布サーバとを有する診断ログ記録システムであって、
前記診断情報配布サーバは、
少なくとも前記診断ログ記録端末において前記コンポーネントの実行時に障害が発生したことを特定する障害情報を、前記診断ログ記録端末から受信するサーバ側受信手段と、
前記診断ログの記録対象となる前記コンポーネントを特定するコンポーネント情報、及び前記コンポーネントごとに前記診断ログの記録箇所を特定する記録箇所特定情報を含む診断情報を生成する診断情報生成手段と、
前記配属端末から受信した前記障害情報に基づいて障害処理情報を生成する障害情報処理手段と、
前記障害処理情報に基づいて、前記診断情報の配布対象の前記診断ログ記録端末を特定する情報である端末特定情報を生成する端末特定情報生成手段と、
前記端末特定情報に従い前記診断情報を前記診断ログ記録端末に配布するサーバ側送信手段と、
を備え、
前記診断ログ記録端末は、
前記診断情報配布サーバから前記診断情報を受信する端末側受信手段と、
実行した前記コンポーネントに障害が発生した場合には、前記障害情報を生成する障害情報生成手段と、
前記コンポーネント情報により特定される前記コンポーネントに障害が発生した場合には、前記記録箇所特定情報に基づいて前記診断ログを記録する診断ログ記録手段と、
前記障害情報を前記診断情報配布サーバへ送信する端末側送信手段と、
を備えること、
を特徴とする診断ログ記録システム。
【請求項１２】
前記診断ログ記録端末及び前記診断情報配布サーバと通信可能な診断ログ解析サーバを有し、
前記診断ログ記録端末の前記端末側送信手段は、前記診断ログを前記診断ログ解析サーバへ送信し、
前記診断ログ解析サーバは、
受信した前記診断ログを解析して前記診断ログの記録対象となる前記コンポーネントの箇所を特定する解析手段と、
前記解析手段による診断結果を前記診断情報配布サーバに送信する解析サーバ側送信手段と、
を備え、
前記診断情報配布サーバの前記診断情報生成手段は、前記診断結果に基づいて、前記記録箇所特定情報を含む診断情報を更新し、
前記診断情報配布サーバの前記サーバ側送信手段は、前記診断情報生成手段により更新された前記診断情報を前記診断ログ記録端末に送信すること、
を特徴とする請求項１０に記載の診断ログ記録システム。
【請求項１３】
コンポーネントの障害を診断するための診断ログを記録する診断ログ記録端末を含む配属端末と通信可能な診断情報配布サーバにより実行される診断ログ記録方法であって、
少なくとも前記診断ログ記録端末において前記コンポーネントの実行時に障害が発生したことを特定する障害情報を、前記診断ログ記録端末から受信するサーバ側受信ステップと、
前記診断ログの記録対象となる前記コンポーネントを特定するコンポーネント情報、及び前記コンポーネントごとに前記診断ログの記録箇所を特定する記録箇所特定情報を含む診断情報を生成する診断情報生成ステップと、
前記配属端末から受信した前記障害情報に基づいて障害処理情報を生成する障害処理情報生成ステップと、
前記障害処理情報に基づいて、前記診断情報の配布対象の前記診断ログ記録端末を特定する情報である端末特定情報を生成する端末特定情報生成ステップと、
前記端末特定情報に従い前記診断情報を前記診断ログ記録端末に配布するサーバ側送信ステップと、
を備える診断ログ記録方法。
【請求項１４】
診断情報配布サーバと通信可能に構成され、コンポーネントを実行可能に構成されるとともに前記コンポーネントの障害を診断するための診断ログを記録する診断ログ記録端末により実行される診断ログ記録方法であって、
前記診断情報配布サーバから前記診断ログの記録対象となる前記コンポーネントを特定するコンポーネント情報、及び前記コンポーネントごとに前記診断ログの記録箇所を特定する記録箇所特定情報を含む診断情報を受信する端末側受信ステップと、
実行した前記コンポーネントに障害が発生した場合には、少なくとも当該診断ログ記録端末において前記コンポーネントの実行時に障害が発生したことを特定する障害情報を生成する障害情報生成ステップと、
前記コンポーネント情報により特定される前記コンポーネントに障害が発生した場合には、前記記録箇所特定情報に基づいて前記診断ログを記録する診断ログ記録ステップと、
前記障害情報を前記診断情報配布サーバへ送信する端末側送信ステップと、
を備える診断ログ記録方法。
【請求項１５】
コンポーネントを実行可能に構成されるとともに前記コンポーネントの障害を診断するための診断ログを記録する診断ログ記録端末、及び、前記診断ログ記録端末を含む配属端末と通信可能な診断情報配布サーバにより実行される診断ログ記録方法であって、
前記診断情報配布サーバは、
少なくとも前記診断ログ記録端末において前記コンポーネントの実行時に障害が発生したことを特定する障害情報を、前記診断ログ記録端末から受信するサーバ側受信ステップと、
前記診断ログの記録対象となる前記コンポーネントを特定するコンポーネント情報、及び前記コンポーネントごとに前記診断ログの記録箇所を特定する記録箇所特定情報を含む診断情報を生成する診断情報生成ステップと、
前記配属端末から受信した前記障害情報に基づいて障害処理情報を生成する障害処理情報生成ステップと、
前記障害処理情報に基づいて、前記診断情報の配布対象の前記診断ログ記録端末を特定する情報である端末特定情報を生成する端末特定情報生成ステップと、
前記端末特定情報に従い前記診断情報を前記診断ログ記録端末に配布するサーバ側送信ステップと、
を備え、
前記診断ログ記録端末は、
前記診断情報配布サーバから前記診断情報を受信する端末側受信ステップと、
実行した前記コンポーネントに障害が発生した場合には、前記障害情報を生成する障害情報生成ステップと、
前記コンポーネント情報により特定される前記コンポーネントに障害が発生した場合には、前記記録箇所特定情報に基づいて前記診断ログを記録する診断ログ記録ステップと、
前記障害情報を前記診断情報配布サーバへ送信する端末側送信ステップと、
を備えること、
を特徴とする診断ログ記録方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、診断情報配布サーバ、診断ログ記録端末、診断ログ記録システム及びその方法に関するものである。
【背景技術】
【０００２】
近年、携帯電話等の組み込みシステムにおいて、アプリケーションに発生する障害の件数が増加傾向にある。特に携帯電話は、ハードウェアや周辺デバイスの高機能化が著しく、これに伴い携帯電話上で動作するアプリケーション自身も、急激に高機能化、開発規模増大化の傾向にある。このため、アプリケーションの想定外の障害が出荷後に発生する場合がある。
【０００３】
障害が発生した場合、アプリケーションの復旧のためには、その障害が発生するに至った原因を特定する必要がある。このため、障害原因を知るための障害診断情報が必要となる。
【０００４】
アプリケーションに対する障害診断情報の一例として、アプリケーションクラッシュ時のメモリのスナップショット（メモリダンプ）がある。例えば、Microsoft社が提供するWindows（登録商標）OSは、アプリケーションに障害が発生した際のメモリダンプを記録して、これをアプリケーション開発者に提供することで、当該障害の診断をサポートする。
【０００５】
しかし、メモリダンプを解析した場合、障害箇所を特定することができるが、障害の根本原因を解析することが困難な場合がある（例えば、非特許文献１参照。）。非特許文献１に記載のように、メモリダンプに保持されているのは、障害発生時のメモリ状態だけである。そのため、例えば、障害発生以前に発生した入出力が原因でアプリケーションがクラッシュした場合には、メモリダンプに障害の根本原因が含まれない場合がある。
【０００６】
上述した問題を解決するために、障害発生時のスナップショットだけではなく、アプリケーションの実行をトレースすることでアプリケーションの動作を把握して、障害状況の再現や障害診断に生かす装置等がある（例えば、特許文献１，２参照。）。特許文献１記載の装置等は、アプリケーションの実行コードにチェックポイントを挿入し、チェックポイント通過時の実行ログを随時記録するものである。また、特許文献２記載の装置等は、アプリケーションコード中に、予め実行プログラムの流れを意味づける指標を含んだログ出力コードを組み込むことにより、アプリケーションの実行後にその動作過程を記録するものである。特許文献１，２記載のアプリケーション実行ログを記録する装置等は、関数の実行履歴やデータの入出力といった障害発生に至るまでの様々な情報を時系列で記録可能であるため、メモリダンプの解析では得られなかった障害の根本原因に関する情報や、非クラッシュ時の障害情報を得ることができる。
【非特許文献１】C. Hopher, M. Denker, and S. Ducasse, “Design and Implementation ofa Backward-In-Time Debugger”, In Proc. of NODe Conference, May 2006.
【特許文献１】特開２００１−３１８８０９号公報
【特許文献２】特開２００７−６５７１８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
上述した実行ログの解析を行うことで、メモリダンプを解析する場合に比べて障害の再現や原因解析を非常に効果的に行うことができる。しかし、実行ログの記録に係るオーバヘッドは、メモリダンプの記録に係るオーバヘッドと比べて非常に大きくなる。実行ログは、アプリケーションの実行系列に介入して時系列で記録される。このため、アプリケーションの実行に対して実行ログを記録すると、慢性的に処理速度のオーバヘッドが発生する。また、実行ログは、常に記録され続けるため、アプリケーションの実行時間に応じて、記録されるデータ量が増加していく。このようなオーバヘッドの発生やデータ量の増大という問題は、メモリダンプの記録では発生しない問題であり、実行ログの記録に発生する独特の問題である。特に、メモリ領域や処理能力が限られる携帯電話では、これらは重大な問題となるが、携帯電話分野においては有効な実行ログの記録手段が未だ確立されていないのが現状である。
【０００８】
オーバヘッドの発生やデータ量の増大という問題を解決するためには、実行ログの記録を抑制することが考えられる。実行ログの記録を制御する装置等の例として、実行ログを記録する際に、過去に記録された実行ログとの類似度を算出し、類似度が低い場合にのみ記録を行うことで、同じ障害に対する実行ログが重複して記録されることを防止するものがある（例えば、特開２００６−２０２０７６号公報参照。）。また、例えば、ログを記録する条件を、予めシステムや障害状態によって決定し、これに合致した場合にのみログを記録するものがある（例えば、特開２００６−１６３９３１号公報参照。）。
【０００９】
上述したアプローチは、ある特定のアプリケーションに対して、有用なもののみをログとして記録するように、記録する対象を絞るというアプローチである。しかし、複数のアプリケーションが動作するシステムにおいて、例えば全てのアプリケーションの実行ログを記録しようとした場合には、十分にオーバヘッドの問題が解決できない場合がある。なぜなら、一つ一つのアプリケーションに対して実行ログの記録対象を絞ることで、当該アプリケーションにおける実行ログ記録に係るオーバヘッドを削減した場合であっても、各アプリケーションのオーバヘッドの合計が大きなオーバヘッドとなる可能性があるためである。
【００１０】
上述した課題を解決するために、各アプリケーションにおける実行ログ記録を抑制するとともに、さらに、実行ログの記録対象となるアプリケーションを限定することが考えられる。しかし、実行ログの記録対象でないアプリケーションについては、実行ログを全く記録することができなくなるため、もし当該アプリケーションにおいて障害が発生した場合には、障害の診断等を行うことができない。
【００１１】
ここで、携帯電話の場合を例において、各端末において実行ログの記録対象となるアプリケーションを絞ることを考える。携帯電話は、PCとは異なり、同一構成の端末が大量に出荷されるという特徴を持つ。同一構成の端末では、同一機能、同一デバイスを備え、同一のアプリケーションが導入されている。そのため、ある端末で特定のアプリケーションについてのみ実行ログを記録し、その他の端末では別のアプリケーションの実行ログを記録して、各端末が記録した全ての実行ログをサーバ側に集約すれば、結果的に全てのアプリケーションに対して、実行ログを記録することが可能となる。携帯電話の数万から数十万に及ぶ出荷台数と比較すれば、導入されているアプリケーションは極めて少ないため、全ての携帯電話においてごく少数のアプリケーションの実行ログを記録したとしても、全体で見れば、全てのアプリケーションに対する実行ログを十分に記録することは可能である。すなわち、対象となるアプリケーションを上述したように絞ることにより、あるアプリケーションの実行ログを全く記録できないという問題を回避することが可能となる。
【００１２】
上記の通り、分散して実行ログを記録することで、各端末では、システム上の全アプリケーションの実行ログを網羅的に記録する場合と比較して、オーバヘッドを大きく削減することが可能である。しかし、この場合にも問題がある。例えば、実際の動作として、各端末において適当なアプリケーションの実行ログを記録し、所定のアプリケーションで障害が発生した際には、記録した実行ログを利用して当該障害に対応することが考えられる。しかし、ある端末においてアプリケーションに障害が発生した際に、当該端末が障害となったアプリケーションの実行ログを記録しているとは限らない。すなわち、実行ログを取得しているアプリケーション以外のアプリケーションで障害が発生した場合には、当該障害を診断するための実行ログを記録できないこととなる。
【００１３】
障害発生時に実行ログを記録できないといったケースを少なくするためには、全てのアプリケーションの実行ログを十分に記録可能となるように、各端末に対して実行ログの記録を割り振るというアプローチが考えられる。しかし、各アプリケーションに対して端末を均等に割り振ったとしても、各アプリケーションにおいて障害が発生する確率や各アプリケーションの実行確率等が異なる場合には、実行ログが記録される障害が偏るおそれがある。このため、障害の発生確率や実行確率が低いアプリケーションに対しては、障害発生時に実行ログを記録することができない場合がある。
【００１４】
そこで、本発明は上記に鑑みてなされたもので、端末を効率的に各コンポーネントの実行ログの記録に割り振り、端末がそれに応じて効率的に実行ログを記録することができる装置、システム及びその方法を提供することを目的とする。
【課題を解決するための手段】
【００１５】
すなわち、本発明に係る診断情報配布サーバは、コンポーネントの障害を診断するための診断ログを記録する診断ログ記録端末を含む配属端末と通信可能に構成される診断情報配布サーバであって、少なくとも前記診断ログ記録端末において前記コンポーネントの実行時に障害が発生したことを特定する障害情報を、前記診断ログ記録端末から受信するサーバ側受信手段と、前記診断ログの記録対象となる前記コンポーネントを特定するコンポーネント情報、及び前記コンポーネントごとに前記診断ログの記録箇所を特定する記録箇所特定情報を含む診断情報を生成する診断情報生成手段と、前記配属端末から受信した前記障害情報に基づいて、障害発生回数に関する障害処理情報を生成する障害情報処理手段と、前記障害処理情報に基づいて、前記診断情報の配布対象の前記診断ログ記録端末を特定する情報である端末特定情報を生成する端末特定情報生成手段と、前記端末特定情報に従い前記診断情報を前記診断ログ記録端末に配布するサーバ側送信手段と、を備えて構成される。
【００１６】
本発明に係る診断情報配布サーバによれば、例えば複数のコンポーネントを実行可能に構成された診断ログ記録端末が複数存在する場合には、各コンポーネントに対応する診断ログを記録する診断ログ記録端末を、端末特定情報により設定することができる。このため、診断ログ記録端末それぞれが分散して診断ログを記録し、診断ログの記録に係るオーバヘッドを削減することが可能となる。ここで、診断ログとは、コンポーネントの実行ログのうち、障害の診断に必要な実行ログをいう。また、診断情報には、コンポーネント特定情報に加えて、記録箇所特定情報を含むことができるので、コンポーネント実行時の実行ログのうち、取得する範囲を限定し、特定の箇所のみを診断ログとして収集することが可能となる。これにより、処理負荷の軽減を図ることができる。さらに、端末特定情報は、各コンポーネントの障害発生回数に関する障害情報によって決定することができるため、例えば、コンポーネントの障害発生頻度等に応じて、診断ログを記録する診断ログ記録端末を柔軟に設定することが可能となる。これにより、障害に対する修正に至るまでの時間等が障害の発生確率やコンポーネントの実行確率等によってばらつくことを回避することができたり、障害に対応する修正がなされるまでの見込みを立てたりすることが可能となる。
【００１７】
ここで、前記診断ログが記録されるまでに要する時間である診断ログ記録期間の期待値が与えられた場合には、前記障害情報処理手段は、前記配属端末それぞれにおいて前記コンポーネント実行時に発生する単位時間当たりの平均障害発生回数を導出し、前記端末特定情報生成手段は、前記単位時間当たりの平均障害発生回数に基づいて、前記診断ログ記録期間の平均値が前記期待値と同値となるように前記端末特定情報を生成することが好適である。
【００１８】
このように構成することで、診断情報配布サーバが、診断ログ記録期間がある期待値を満たすように、端末特定情報を生成することができる。よって、どのようなコンポーネントに発生する障害についても、例えば管理者が要求する一定の期間内に診断ログを取得することができる。
【００１９】
また、前記診断ログが記録されるまでに発生する障害回数の期待値が与えられた場合には、前記障害情報処理手段は、前記配属端末それぞれにおいて前記コンポーネント実行時に発生する単位時間当たりの平均障害発生回数を導出するとともに前記単位時間当たりの平均障害発生回数の合計を導出し、前記端末特定情報生成手段は、前記単位時間当たりの平均障害発生回数及び前記単位時間当たりの平均障害発生回数の合計に基づいて、前記診断ログが記録されるまでに発生する障害の回数の平均値が前記期待値と同値となるように前記端末特定情報を生成することが好適である。
【００２０】
このように構成することで、診断情報配布サーバが、診断ログが記録されるまでに発生する障害の回数がある期待値を満たすように、端末特定情報を生成することができる。よって、どのようなコンポーネントに発生する障害についても、例えば管理者が要求する一定の発生回数内に診断ログを取得することができる。
【００２１】
また、前記障害情報には、障害の深刻度を特定する障害深刻度特定情報が含まれており、前記端末特定情報生成手段は、前記深刻度に応じて前記端末特定情報を生成することが好適である。
【００２２】
このように構成することで、診断情報配布サーバが、障害の深刻度を考慮して端末特定情報を生成することができる。例えば、端末特定情報生成手段は、深刻度が高い障害が発生したコンポーネントに対しては、多くの診断ログ記録端末が診断ログを記録するように、端末特定情報を生成する。これにより、当該コンポーネントに障害が発生した際の診断ログ記録確率が高くなるので、障害に対する修正を迅速に行うことができる。
【００２３】
また、前記障害情報処理手段は、前記配属端末から受信した前記障害情報を蓄積し、所定期間経過後に前記障害処理情報を導出する処理を行うことが好適である。
【００２４】
このように構成することで、ある一定期間は障害情報を蓄積し、ある程度情報が蓄積された時点で障害処理情報を導出することができる。これにより、所外処理情報の導出、端末特定情報の生成、診断情報の配布等の実行頻度を抑えることができるので、診断情報配布サーバや診断ログ記録端末における処理負荷の低減を図ることが可能となる。
【００２５】
また、前記診断ログを解析して、前記診断ログの記録対象となるコンポーネントの箇所を特定した診断結果を送信する診断ログ解析サーバと通信可能に構成され、前記診断情報生成手段は、前記診断結果に基づいて前記記録箇所特定情報を含む診断情報を更新し、前記サーバ側送信手段は、前記診断情報生成手段により更新された前記診断情報を前記診断ログ記録端末に送信することが好適である。
【００２６】
このように構成することで、診断情報の記録箇所特定情報に、ある更新がされた場合には、診断情報配布サーバが直ちに当該診断情報を対応する診断ログ記録端末のみに配布することができるので、診断ログ記録端末は、記録する診断情報を更新することが可能となる。よって、以降の障害の診断を効率的に行うことができる。
【００２７】
また、本発明に係る診断ログ記録端末は、診断情報配布サーバと通信可能に構成され、コンポーネントを実行可能に構成されるとともに前記コンポーネントの障害を診断するための診断ログを記録する診断ログ記録端末であって、前記診断情報配布サーバから前記診断ログの記録対象となる前記コンポーネントを特定するコンポーネント情報、及び前記コンポーネントごとに前記診断ログの記録箇所を特定する記録箇所特定情報を含む診断情報を受信する端末側受信手段と、実行した前記コンポーネントに障害が発生した場合には、少なくとも当該診断ログ記録端末において前記コンポーネントの実行時に障害が発生したことを特定する障害情報を生成する障害情報生成手段と、前記コンポーネント情報により特定される前記コンポーネントに障害が発生した場合には、前記記録箇所特定情報に基づいて前記診断ログを記録する診断ログ記録手段と、を備えて構成される。
【００２８】
本発明に係る診断ログ記録端末によれば、診断情報配布サーバによって指定されたコンポーネントに対してのみ診断ログを記録することができるので、全てのコンポーネントから実行ログを記録する場合と比較して、大幅にオーバヘッドを削減することが可能となる。また、配属端末が、コンポーネントの障害情報を診断情報配布サーバへ送信するため、診断ログ記録端末が効率的に診断ログを記録することができるように、診断情報配布サーバに対して、診断情報を適切に配布させることが可能となる。
【００２９】
ここで、前記端末側送信手段は、前記診断ログを解析し診断結果を前記診断情報配布サーバへ送信する診断ログ解析サーバに対して、前記診断ログを送信することが好適である。このように構成することで、診断ログを診断ログ解析サーバに集約して解析させることができる。
【００３０】
また、前記診断ログ記録手段は、前記コンポーネント特定情報により特定される前記コンポーネントの実行開始を検知した後に前記コンポーネントの前記診断ログを記録することが好適である。
【００３１】
このように構成することで、診断ログ記録端末は、診断情報のコンポーネント特定情報により特定される特定のコンポーネントに対する診断ログのみを記録することができる。また、診断ログ記録手段は、当該コンポーネントの実行開始を検知して診断ログの記録を開始することができる。これにより、診断ログの記録対象コンポーネントから、確実に診断ログを記録することが可能となるとともに、当該コンポーネントの非実行時には、一切のオーバヘッドが発生しないため、処理負荷の軽減を図ることができる。
【００３２】
また、前記記録箇所特定情報は、記録対象となる前記コンポーネント上の実行命令を特定する情報を含み、前記診断ログ記録手段は、前記実行命令が発生するアドレスを特定し、前記コンポーネントの実行が前記アドレスに至った際に、前記診断ログを記録することが好適である。
【００３３】
このように構成することで、例えば、特に障害が発生すると想定される箇所、あるいは障害発生時の影響が大きいと思われる箇所で実行ログを記録すべく、コンポーネント上の実行命令を特定することができる。そして、診断ログ記録手段は、当該実行命令が発生するアドレスを特定して当該アドレスにおける実行ログを記録することができる。これにより、診断情報によって特定される特定時にのみ実行ログを診断ログとして記録することが可能となるので、必要な診断ログを確実に記録することが可能となる。さらに、余分な実行ログを記録することによるオーバヘッドを削減することが可能となる。また、診断情報によって、実行ログを記録する箇所をアドレスではなく実行命令で特定することができるため、各診断ログ記録端末上で、実行ログの記録対象となるアドレスが異なる場合でも、共通の診断情報で、共通の診断ログを記録することが可能となる。
【００３４】
また、本発明に係る診断ログ記録システムは、コンポーネントを実行可能に構成されるとともに前記コンポーネントの障害を診断するための診断ログを記録する診断ログ記録端末と、前記診断ログ記録端末を含む配属端末と通信可能な診断情報配布サーバとを有する診断ログ記録システムであって、前記診断情報配布サーバは、少なくとも前記診断ログ記録端末において前記コンポーネントの実行時に障害が発生したことを特定する障害情報を、前記診断ログ記録端末から受信するサーバ側受信手段と、前記診断ログの記録対象となる前記コンポーネントを特定するコンポーネント情報、及び前記コンポーネントごとに前記診断ログの記録箇所を特定する記録箇所特定情報を含む診断情報を生成する診断情報生成手段と、前記配属端末から受信した前記障害情報に基づいて障害処理情報を生成する障害情報処理手段と、前記障害処理情報に基づいて、前記診断情報の配布対象の前記診断ログ記録端末を特定する情報である端末特定情報を生成する端末特定情報生成手段と、前記端末特定情報に従い前記診断情報を前記診断ログ記録端末に配布するサーバ側送信手段と、を備え、前記診断ログ記録端末は、前記診断情報配布サーバから前記診断情報を受信する端末側受信手段と、実行した前記コンポーネントに障害が発生した場合には、前記障害情報を生成する障害情報生成手段と、前記コンポーネント情報により特定される前記コンポーネントに障害が発生した場合には、前記記録箇所特定情報に基づいて前記診断ログを記録する診断ログ記録手段と、前記障害情報を前記診断情報配布サーバへ送信する端末側送信手段と、を備えること、を特徴として構成される。
【００３５】
本発明に係る診断ログ記録システムによれば、上述した診断ログ記録端末及び診断情報配布サーバを有するため、診断ログ記録端末を効率的に各コンポーネントの実行ログの記録に割り振り、診断ログ記録端末がそれに応じて効率的に実行ログを記録することができる。
【００３６】
ここで、前記診断ログ記録端末及び前記診断情報配布サーバと通信可能な診断ログ解析サーバを有し、前記診断ログ記録端末の前記端末側送信手段は、前記診断ログを前記診断ログ解析サーバへ送信し、前記診断ログ解析サーバは、受信した前記診断ログを解析して前記診断ログの記録対象となる前記コンポーネントの箇所を特定する解析手段と、前記解析手段による診断結果を前記診断情報配布サーバに送信する解析サーバ側送信手段と、を備え、前記診断情報配布サーバの前記診断情報生成手段は、前記診断結果に基づいて、前記記録箇所特定情報を含む診断情報を更新し、前記診断情報配布サーバの前記サーバ側送信手段は、前記診断情報生成手段により更新された前記診断情報を前記診断ログ記録端末に送信することが好適である。
【００３７】
このように構成することで、診断ログ記録端末が診断ログを診断ログ解析サーバへ送信し、診断ログ解析サーバが診断ログに基づいて診断した結果を診断情報配布サーバへ送信し、診断情報配布サーバが前記診断情報を更新して診断ログ記録端末へ送信することができる。これにより、診断情報の記録箇所特定情報に、ある更新がされた場合には、診断情報配布サーバが直ちに当該診断情報を対応する診断ログ記録端末のみに配布することができるので、診断ログ記録端末は、記録する診断情報を更新することが可能となる。よって、以降の障害の診断を効率的に行うことができる。
【００３８】
また、本発明に係る診断ログ記録方法は、コンポーネントの障害を診断するための診断ログを記録する診断ログ記録端末を含む配属端末と通信可能な診断情報配布サーバにより実行される診断ログ記録方法であって、少なくとも前記診断ログ記録端末において前記コンポーネントの実行時に障害が発生したことを特定する障害情報を、前記診断ログ記録端末から受信するサーバ側受信ステップと、前記診断ログの記録対象となる前記コンポーネントを特定するコンポーネント情報、及び前記コンポーネントごとに前記診断ログの記録箇所を特定する記録箇所特定情報を含む診断情報を生成する診断情報生成ステップと、前記配属端末から受信した前記障害情報に基づいて障害処理情報を生成する障害処理情報生成ステップと、前記障害処理情報に基づいて、前記診断情報の配布対象の前記診断ログ記録端末を特定する情報である端末特定情報を生成する端末特定情報生成ステップと、前記端末特定情報に従い前記診断情報を前記診断ログ記録端末に配布するサーバ側送信ステップと、を備えて構成される。
【００３９】
本発明に係る診断ログ記録方法によれば、障害情報を配属端末から受信し、受信した障害情報に基づいて障害処理情報を生成し、障害処理情報に基づいて端末特定情報を生成し、診断情報を生成し、生成した診断情報を端末特定情報に従って診断ログ記録端末に配布することができる。これにより、診断ログ記録端末を効率的に各コンポーネントの実行ログの記録に割り振り、診断ログ記録端末がそれに応じて効率的に実行ログを記録することができる。
【００４０】
また、本発明に係る診断ログ記録方法は、診断情報配布サーバと通信可能に構成され、コンポーネントを実行可能に構成されるとともに前記コンポーネントの障害を診断するための診断ログを記録する診断ログ記録端末により実行される診断ログ記録方法であって、前記診断情報配布サーバから前記診断ログの記録対象となる前記コンポーネントを特定するコンポーネント情報、及び前記コンポーネントごとに前記診断ログの記録箇所を特定する記録箇所特定情報を含む診断情報を受信する端末側受信ステップと、実行した前記コンポーネントに障害が発生した場合には、少なくとも当該診断ログ記録端末において前記コンポーネントの実行時に障害が発生したことを特定する障害情報を生成する障害情報生成ステップと、前記コンポーネント情報により特定される前記コンポーネントに障害が発生した場合には、前記記録箇所特定情報に基づいて前記診断ログを記録する診断ログ記録ステップと、前記障害情報を前記診断情報配布サーバへ送信する端末側送信ステップと、を備えて構成される。
【００４１】
本発明に係る診断ログ記録方法によれば、診断情報配布サーバから診断ログの記録対象を特定する診断情報を受信し、実行したコンポーネントに障害が発生した場合には、診断ログ記録端末においてコンポーネントの実行時に障害が発生したことを特定する障害情報を生成し、診断情報により特定されるコンポーネントに障害が発生した場合には、診断情報に基づいて診断ログを記録して、生成した障害情報を診断情報配布サーバへ送信することができる。よって、診断ログ記録端末を効率的に各コンポーネントの実行ログの記録に割り振り、診断ログ記録端末がそれに応じて効率的に実行ログを記録することができる。
【００４２】
また、本発明に係る診断ログ記録方法は、コンポーネントを実行可能に構成されるとともに前記コンポーネントの障害を診断するための診断ログを記録する診断ログ記録端末、及び、前記診断ログ記録端末を含む配属端末と通信可能な診断情報配布サーバにより実行される診断ログ記録方法であって、前記診断情報配布サーバは、少なくとも前記診断ログ記録端末において前記コンポーネントの実行時に障害が発生したことを特定する障害情報を、前記診断ログ記録端末から受信するサーバ側受信ステップと、前記診断ログの記録対象となる前記コンポーネントを特定するコンポーネント情報、及び前記コンポーネントごとに前記診断ログの記録箇所を特定する記録箇所特定情報を含む診断情報を生成する診断情報生成ステップと、前記配属端末から受信した前記障害情報に基づいて障害処理情報を生成する障害処理情報生成ステップと、前記障害処理情報に基づいて、前記診断情報の配布対象の前記診断ログ記録端末を特定する情報である端末特定情報を生成する端末特定情報生成ステップと、前記端末特定情報に従い前記診断情報を前記診断ログ記録端末に配布するサーバ側送信ステップと、を備え、前記診断ログ記録端末は、前記診断情報配布サーバから前記診断情報を受信する端末側受信ステップと、実行した前記コンポーネントに障害が発生した場合には、前記障害情報を生成する障害情報生成ステップと、前記コンポーネント情報により特定される前記コンポーネントに障害が発生した場合には、前記記録箇所特定情報に基づいて前記診断ログを記録する診断ログ記録ステップと、前記障害情報を前記診断情報配布サーバへ送信する端末側送信ステップと、を備えることを特徴として構成される。
【００４３】
本発明に係る診断ログ記録方法によれば、上述したように、診断情報配布サーバと診断ログ記録端末とが協調して、診断ログ記録端末を効率的に各コンポーネントの実行ログの記録に割り振り、診断ログ記録端末がそれに応じて効率的に実行ログを記録することができる。
【発明の効果】
【００４４】
本発明によれば、診断ログ記録端末を効率的にコンポーネントの実行ログの記録に割り振り、診断ログ記録端末がそれに応じて効率的に実行ログを記録することが可能な診断情報配布サーバ、診断ログ記録端末、診断ログ記録システム及びその方法を提供することができる。
【発明を実施するための最良の形態】
【００４５】
以下、添付図面を参照して本発明に係る診断情報配布サーバ、診断ログ記録端末、診断ログ記録システム及びその方法の好適な実施形態を詳細に説明する。なお、図面の説明において同一の要素には同一の符号を付し、重複する説明を省略する。
【００４６】
（第１実施形態）
本実施形態に係る診断ログ記録端末は、例えば、コンポーネントの診断ログを記録する携帯電話として好適に採用されるものである。診断ログは、障害を診断するために必要となる実行ログのことである。
【００４７】
まず、本実施形態に係る診断ログ記録クライアント（診断ログ記録端末）２００を有する診断ログ記録システム１の構成について、図１を参照して説明する。図１は、診断ログ記録システム１の構成概要図である。図１に示すように、診断ログ記録システム１は、診断ログ記録クライアント２００、診断情報配布サーバ１００、及び診断ログ解析サーバ３００を備えて構成される。診断ログ記録クライアント２００、診断情報配布サーバ１００、及び診断ログ解析サーバ３００は、通信ネットワークにより互いに接続されており、診断ログ記録クライアント２００の診断ログを効率良く記録するために通信する。
【００４８】
最初に、診断ログ記録クライアント２００について詳細に説明する。図２は、診断ログ記録クライアント２００のハードウェア構成図である。図２に示すように、診断ログ記録クライアント２００は、物理的には、ＣＰＵ２１、ＲＯＭ２２及びＲＡＭ２３等の主記憶装置、キーボード及びマウス等の入力デバイス２４、ディスプレイ等の出力デバイス２５、診断情報配布サーバ１００又は診断ログ解析サーバ３００との間でデータの送受信を行うためのネットワークカード等の通信モジュール２６、ハードディスク等の補助記憶装置２７などを含む通常のコンピュータシステムとして構成される。後述する診断ログ記録クライアント２００の各機能は、ＣＰＵ２１、ＲＯＭ２２、ＲＡＭ２３等のハードウェア上に所定のコンピュータソフトウェアを読み込ませることにより、ＣＰＵ２１の制御の元で入力デバイス２４、出力デバイス２５、通信モジュール２６を動作させるとともに、主記憶装置２２、２３や補助記憶装置２７におけるデータの読み出し及び書き込みを行うことで実現される。また、診断ログ記録クライアント２００は、上述したソフトウェアを含む少なくとも１つのコンポーネントを動作可能に構成されている。コンポーネントとは、例えば実行されるアプリケーションを示すものである。
【００４９】
図１に戻り、診断ログ記録クライアント２００は、機能的には、情報受信部（端末側受信手段）２１０、障害情報生成部（障害情報生成手段）２２０、診断ログ記録部（診断ログ記録手段）２３０及び情報送信部（端末側送信手段）２４０を備えて構成される。
【００５０】
情報受信部２１０は、診断情報配布サーバ１００が送信した診断情報３０を受信する機能を有している。また、情報受信部２１０は、受信した診断情報３０を診断ログ記録部２３０へ出力する機能を有している。
【００５１】
ここで、情報受信部２１０により受信される診断情報３０について説明する。診断情報３０は、診断ログ２０として記録する内容を特定するための情報である。診断情報３０は、少なくとも、コンポーネント特定情報３１及び記録箇所特定情報３２を含んでいる。コンポーネント特定情報３１は、当該診断ログ記録クライアント２００上で実行されるアプリケーションのうち、どのアプリケーションを対象として診断ログ２０を記録するのかを特定する情報である。すなわち、一のコンポーネント特定情報３１により、一のアプリケーションが特定されるように構成されている。コンポーネント特定情報３１として、例えば、アプリケーション名が用いられる。また、記録箇所特定情報３２は、コンポーネント特定情報３１により特定されたアプリケーションのうち、どの箇所について記録するかを特定する情報である。この記録箇所特定情報３２は、アプリケーションごとに与えられる。例えば、記録箇所特定情報３２として、特に障害が発生すると想定される箇所、あるいは障害発生時の影響が大きいと思われる箇所を示すものが用いられる。具体的には、アプリケーションの入出力が発生する箇所などである。そして、記録箇所特定情報３２として、例えば、アドレスや実行命令などを用いて当該箇所を表したものが用いられる。この記録箇所特定情報３２は、例えば後述するフックポイントを特定するために用いられる。
【００５２】
また、診断ログ記録部２３０は、情報受信部２１０により出力された診断情報３０に基づいて、診断ログ２０を記録する機能を有している。診断ログ記録部２３０は、例えば、診断情報３０のコンポーネント特定情報３１により特定されるアプリケーションの診断ログ２０のみを記録する機能を有している。また、診断情報に複数のコンポーネント特定情報３１が含まれている場合には、含まれる全てのコンポーネント特定情報３１により特定されるアプリケーションの全てについて診断ログを記録する機能を有している。また、診断ログ記録部２３０は、例えば、記録箇所特定情報３２により実行命令が特定されている場合には、特定されている実行命令が発生するアドレスを特定し、特定したアドレスにおける診断ログ２０を記録する機能を有している。また、診断ログ記録部２３０は記録した診断ログ２０を情報送信部２４０に出力する機能を有している。
【００５３】
ここで、診断ログ記録部２３０が有する診断ログ記録機能について、図３を用いて詳細を説明する。図３は、診断ログ記録部２３０が有する診断ログ２０の記録機能を説明するための概要図である。診断ログ記録部２３０は、図３に示すように、アプリケーションの実行コード中で、診断ログ２０を記録する箇所をフックポイントＦＰｎ（ｎ：整数）とし、当該フックポイントＦＰｎにフックコードＦＣｎ（ｎ：整数）を挿入し、当該フックポイントＦＰｎへ実行が到達するごとに、フックコードＦＣｎが、実行ログを記録する診断コードＳＣを呼び出す構成とすることで診断ログを記録する機能を有している。フックポイントＦＰｎとして、例えば、アプリケーション実行時のデータの入出力箇所が用いられる（例えばY. Saito, “Jockey: A User-space Library for Record-replayDebugging”, In 6th International Conference on Automated analysis-drivendebugging, 2005  参照）。アプリケーション実行時のデータの入出力箇所をフックポイントＦＰｎとして設定し、データの入出力履歴を記録した診断ログ２０は、障害診断に有効である。入力されたデータによって障害が引き起こされることは、比較的多いためである。また、入出力の履歴を記録しておくことにより、アプリケーション動作を高い精度で再現が可能となり、障害診断時の障害解析にも効果的となるためである。また、フックポイントＦＰｎとして、関数呼び出し命令が用いられてもよい。関数呼び出し命令をフックし、アプリケーションの制御移動履歴を記録した診断ログ２０は、障害診断に有効である。制御移動履歴を記録しておくことにより、障害発生時には、アプリケーションの動作の流れをトレースすることが可能となり、障害の再現が容易となる。また、特に重要なＡＰＩの呼び出しを行うアプリケーションが存在した場合には、当該制御移動履歴を記録しておくことで、当該ＡＰＩが実行されたか否かといった、障害の切り分けを行うことが可能となる。
【００５４】
また、障害情報生成部２２０は、診断ログ記録クライアント２００上で動作する全てのアプリケーションについて、障害の発生を検知して障害情報１０を生成する機能を有している。障害情報生成部２２０は、アプリケーションの障害発生時にのみ一度だけ障害情報１０を記録する機能を有している。また、障害情報生成部２２０は、生成した障害情報１０を情報送信部２４０へ出力する機能を有している。
【００５５】
ここで、障害情報生成部２２０により生成される障害情報１０について説明する。障害情報１０は、例えば、少なくとも、障害が発生したアプリケーションを特定する情報であるとともに、当該アプリケーションを実行した診断ログ記録クライアント２００を特定する情報である。障害情報１０として、例えば、メモリダンプが用いられる。すなわち、障害情報１０は、実行ログに比べてデータ量が小さいものとなる。また、障害情報１０には、当該障害の深刻度を示す障害深刻度特定情報を含んでも良い。障害の深刻度は、例えば、当該障害によって発生する被害の大きさによって決定される。例えば、深刻度を３段階の設定とした場合において、１番軽い深刻度１の場合は、障害によりアプリケーションが強制終了した場合であり、深刻度２の場合は、障害によりシステムがフリーズした場合であり、深刻度３の場合は、障害によりユーザデータが破壊された場合である。なお、詳細については第３実施形態において後述するが、障害情報１０は、診断情報配布サーバ１００に集約され、診断情報３０を配布する診断ログ記録クライアントを決定する記録ポリシー（端末特定情報）を導出するために用いられる。
【００５６】
また、情報送信部２４０は、障害情報生成部２２０が出力した障害情報１０を入力し、診断情報配布サーバ１００へ障害情報１０を送信する機能を有している。また、情報送信部２４０は、障害情報１０の入力ごとに送信する機能を有していても良いし、障害情報１０を所定のデータ量蓄積した後に一括して送信する機能を有していても良い。また、情報送信部２４０は、診断ログ記録部２３０が出力した診断ログ２０を入力し、診断ログ解析サーバ３００へ出力する機能を有している。
【００５７】
次に、診断ログ解析サーバ３００について説明する。図２は、診断ログ解析サーバ３００のハードウェア構成図である。図２に示すように、診断ログ解析サーバ３００は、物理的には、ＣＰＵ３１、主記憶装置であるＲＯＭ３２及びＲＡＭ３３、操作ボタンなどの入力デバイス３４、ＬＣＤや有機ＥＬディスプレイなどの出力デバイス３５、診断ログ記録クライアント２００又は診断情報配布サーバ１００との間でデータの送受信を行う通信モジュール３６、メモリディバイス等の補助記憶装置３７を備えて構成される。後述する診断ログ解析サーバ３００の各機能は、ＣＰＵ３１、ＲＯＭ３２、ＲＡＭ３３等のハードウェア上に所定のソフトウェアを読み込ませることにより、ＣＰＵ３１の制御の元で入力デバイス３４、出力デバイス３５、通信モジュール３６を動作させると共に、主記憶装置３２、３３や補助記憶装置３７におけるデータの読み出し及び書き込みを行うことで実現される。
【００５８】
図１に戻り、診断ログ解析サーバ３００は、機能的には、受信部、解析部（解析手段）、送信部（解析サーバ側送信手段）を備えている（不図示）。そして、診断ログ記録クライアント２００から送信された診断ログ２０を受信する機能を有している。また、診断ログ解析サーバ３００は、受信した診断ログ２０を解析する機能を有している。また、診断ログ解析サーバ３００は、解析した結果（診断結果６０）を診断情報配布サーバ１００へ送信する機能を有している。なお、診断ログ解析サーバ３００は、当該障害の再現や当該障害に対する修正を行う機能を有していてもよい。
【００５９】
次に、診断情報配布サーバ１００について説明する。図２は診断情報配布サーバ１００のハードウェア構成図である。図２に示すように、診断情報配布サーバ１００は、物理的には、ＣＰＵ１１、主記憶装置であるＲＯＭ１２及びＲＡＭ１３、操作ボタンなどの入力デバイス１４、ＬＣＤや有機ＥＬディスプレイなどの出力デバイス１５、診断ログ記録クライアント２００又は診断ログ解析サーバ３００との間でデータの送受信を行う通信モジュール１６、メモリディバイス等の補助記憶装置１７を備えて構成される。後述する診断ログ解析サーバ３００の各機能は、ＣＰＵ１１、ＲＯＭ１２、ＲＡＭ１３等のハードウェア上に所定のソフトウェアを読み込ませることにより、ＣＰＵ３１の制御の元で入力デバイス１４、出力デバイス１５、通信モジュール１６を動作させると共に、主記憶装置１２、１３や補助記憶装置１７におけるデータの読み出し及び書き込みを行うことで実現される。
【００６０】
図１に戻り、診断情報配布サーバ１００は、機能的には、診断ログ記録クライアント２００に対して、診断情報３０を配布する機能を有している。また、診断情報配布サーバ１００は、診断ログ記録クライアント２００が送信した障害情報１０を受信する機能を有している。また、診断情報配布サーバ１００は、障害情報１０に基づいて、記録ポリシー５０を作成する機能を有している。また、診断情報配布サーバ１００は、診断ログ解析サーバ３００が送信した診断結果６０を受信する機能を有している。また、診断情報配布サーバ１００は、診断結果６０に基づいて診断情報３０を更新し、診断ログ記録クライアント２００に対して、更新した診断情報３０を配布する機能を有している。
【００６１】
次に、本実施形態に係る診断ログ記録クライアント２００の診断ログ記録動作について詳細を説明する。図４は、本実施形態に係る診断ログ記録クライアント２００の診断ログ記録動作を示すフローチャート、図５は、実行コードを説明するための概要図である。なお、以下では説明理解の容易性を考慮して、診断ログ記録クライアント２００が診断情報配布サーバ１００から一つの診断情報３０のみを受信したものとする。また、受信した診断情報３０の内容として、コンポーネント特定情報３１は、アプリケーション１であり、記録箇所特定情報３２は、全入出力命令及びＡＰＩ“API_1”の呼び出し命令であるとする。
【００６２】
図４に示すように、最初に、診断ログ記録部２３０は、アプリケーションの実行を検知する（Ｓ１）。そして、実行中のアプリケーションと、診断ログ記録クライアント２００が受信したコンポーネント特定情報３１により特定される診断ログ記録対象のアプリケーションとが同一か否かを判定する（Ｓ２）。ここでは、コンポーネント特定情報３１により特定される診断ログ記録対象のアプリケーションは、アプリケーション１である。よって、診断ログ記録部２３０は、実行中のアプリケーションが、アプリケーション１であるか否かを判別する（Ｓ２）。Ｓ２の処理において、実行中のアプリケーションが記録対象のアプリケーション１でない場合には、図４に示す制御処理を終了する。
【００６３】
一方、Ｓ２の処理において、実行中のアプリケーションがアプリケーション１であると判定した場合、診断ログ記録部２３０は、フックコードＦＣｎが呼び出す診断コードＳＣを、アプリケーション１のプロセス空間へロードする（Ｓ３）。例えば、アプリケーション１実行時に、診断ログ記録部２３０が、当該アプリケーションのプロセス空間へ、外部ライブラリとしてロードする（例えば、Y. Saito, “Jockey: A User-space Library for Record-replayDebugging”, In 6th International Conference on Automated analysis-drivendebugging, 2005参照）。図５（ａ）に示すように、実行コードとして、アプリケーション１のアプリケーションコードがロードされているとすると、図５（ｂ）に示すように、診断コードＳＣは、診断ログ２０を記録するアプリケーションコードとは独立に用意される。このため、コンポーネント特定情報３１によって、どのアプリケーションが診断ログ２０の記録対象となった場合でも、当該アプリケーションからのみ診断ログ２０を記録することが可能となる。
【００６４】
次に、診断ログ記録部２３０は、フックコードＦＣｎを挿入するフックポイントＦＰｎを、記録箇所特定情報３２を用いて特定する（Ｓ４）。ここでは、記録箇所特定情報３２により特定される記録対象の箇所は、アプリケーション１に係る全入出力命令及びAPI_1の呼び出し命令である。よって、入出力に係る実行命令アドレスをフックポイントＦＰｎとする。具体的には、入出力に係る実行命令は、入出力に係るシステムコール命令に等しい。アプリケーションの実行コードが、インストラクション列で表される場合には、入出力に係る実行命令は、ＣＰＵアーキテクチャに依存する。例えば、ＡＲＭアーキテクチャの場合は、swi命令が相当する。あるいは、ＡＰＩ呼び出し命令の場合は、bl命令が相当する。診断ログ記録部２３０は、例えば図５（ｃ）に示すように、上述した実行命令を、アプリケーションの実行コード中から検出することにより、フックポイントＦＰｎを特定する。
【００６５】
次に、診断ログ記録部２３０は、上記特定された全てのフックポイントＦＰｎにフックコードＦＣｎを挿入する（Ｓ５）。フックコードＦＣｎは具体的には、診断コードＳＣを呼び出すための分岐命令である。フックポイントＦＰｎ検出時と同様にインストラクションレベルで挿入するとして、例えばＡＲＭアーキテクチャの場合は、b命令（brunch命令）により記述可能である。例えば、図５（ｄ）に示すように、診断コードＳＣをロード後、API_1を呼び出す命令（bl API_1）、入出力に係る命令（swi read/write）をフックポイントＦＰｎとする。そして、フックポイントＦＰｎにフックコードＦＣｎを挿入することで、挿入したフックコードＦＣｎから診断コードＳＣを呼び出し可能な構成とすることができる。
【００６６】
診断ログ記録部２３０が全てのフックコードＦＣｎを挿入した後、ＣＰＵ２１等が当該アプリケーションを実行する（Ｓ６）。API_1の呼び出し命令が実行されるアドレス（フックポイントＦＰｎ）において、それぞれフックコードＦＣｎを実行することで診断コードＳＣが呼び出される。そして、入出力履歴やＡＰＩ呼び出し履歴が記録される。
【００６７】
次に、診断ログ記録部２３０は、アプリケーションの終了状態を判定して障害の発生を判定する（Ｓ７）。診断ログ記録部２３０は、アプリケーションの終了状態を判定し、実行が正常に終了したと判定した場合には、記録した診断ログ２０を破棄する（Ｓ８）。一方、障害が発生したと判定した場合には、当該診断ログ２０を情報送信部２４０へ出力する（Ｓ９）。Ｓ９の処理が終了すると、図４に示す制御処理を終了する。
【００６８】
図４に示す制御処理を実行することにより、診断情報３０により特定されたアプリケーションの実行ログを、障害発生時に診断情報３０により特定された箇所のみ記録して診断ログとすることができる。
【００６９】
次に、本実施形態に係る診断ログ記録クライアント２００の障害情報１０の生成動作及び送信動作について詳細を説明する。まず、障害情報生成部２２０は、診断ログ記録クライアント２００上で動作する全てのアプリケーションを監視し、障害が発生したことを検知する。障害情報生成部２２０は、障害が発生したことを検知した場合には、障害情報１０を生成する。例えば、障害情報生成部２２０は、障害情報１０として、障害が発生したアプリケーションと、当該アプリケーションを実行した診断ログ記録クライアント２００とを特定することができるメモリダンプ等を生成する。障害情報１０の生成処理は、診断ログ記録部２３０が診断ログ２０を記録する処理と比較して処理負荷が小さいものとなる。また、障害情報１０のデータ量は、診断ログ２０のデータ量に比べて極めて小さいものとなる。また、障害情報生成部２２０は、障害の深刻度を設定してもよい。例えば、障害時に当該アプリケーションの強制終了を検知した場合には、当該障害の深刻度を１と設定し、設定した深刻度を含めた障害情報１０を生成する。また、例えば、障害情報生成部２２０は、障害時にシステムのフリーズを検知した場合には、当該障害の深刻度を２と設定し、設定した深刻度を含めた障害情報１０を生成する。また、例えば、障害情報生成部２２０は、障害時にユーザデータの破壊を検知した場合には、当該障害の深刻度を３と設定し、設定した深刻度を含めた障害情報１０を生成する。障害情報生成部２２０は、生成した障害情報１０を情報送信部２４０へ出力する。情報送信部２４０は、例えば、入力した障害情報１０を蓄積し、障害情報が所定容量となった場合には、診断情報配布サーバ１００へ送信する。診断情報配布サーバ１００は、障害情報１０に基づいて、障害が発生したアプリケーション及び当該障害が発生した診断ログ記録クライアント２００を特定することができる。
【００７０】
次に、本実施形態に係る診断ログ記録クライアント２００の診断ログ記録動作が終了した後の動作、診断ログ解析サーバ３００の動作、及び診断情報配布サーバ１００の動作について説明する。情報送信部２４０は、図４の制御処理を終了すると、診断ログ２０を診断ログ解析サーバ３００へ送信する。診断ログ解析サーバ３００は、診断ログ２０を利用して、当該障害の再現や原因解析を行う。そして、解析した結果（診断結果６０）を診断情報配布サーバ１００へ送信する。一方、診断情報配布サーバ１００は、診断情報配布サーバ１００から受信した診断結果６０に基づいて、診断情報３０を更新する。
【００７１】
以下では、診断結果６０により、診断情報３０の記録箇所特定情報３２が更新される場合について、一例を述べる。診断ログ解析サーバ３００は、診断ログ２０を受け取り、解析することで、発生した障害の再現による原因解析、及びその原因に対する修正を実行する。例えば、上述した例において、API_1呼び出し時に障害が発生していたとする。上記示した記録箇所特定情報３２の例によれば、API_1の呼び出し命令を診断ログ２０として記録する。ここで、首尾よく当該障害原因が除去され、API_1に障害原因が残留する可能性が著しく低くなったとする。この場合、最早、診断ログとしてAPI_1の呼び出し履歴を記録しても効果は薄い。そのため、診断ログ解析サーバ３００は、診断結果６０を診断情報配布サーバ１００へ送信し、診断情報配布サーバ１００は、診断結果６０により、診断情報３０の記録箇所特定情報３２を更新する。この場合、API_1の呼び出しをフックポイントとして特定していたが、これを消去する。こうして更新された診断情報３０を、情報受信部２１０が受信し、図４の制御処理を実行することにより、以降のアプリケーション１の実行では、API_1の呼び出し履歴は記録されないこととなる。
【００７２】
このように、診断ログ記録クライアント２００、診断ログ解析サーバ３００、及び診断情報配布サーバ１００が通信することで、更新済みの診断情報３０により特定されたアプリケーションの診断ログ２０を、障害発生時に更新済みの診断情報３０により特定された箇所のみ記録することが可能となる。
【００７３】
以上、第１実施形態に係る診断ログ記録クライアント２００によれば、診断情報配布サーバ１００によって指定されたアプリケーションに対してのみ診断ログ２０を記録することができる。診断ログ記録クライアント２００は、コンポーネント特定情報３１により、診断ログを記録する対象のアプリケーションを絞り、さらに、記録箇所特定情報３２により、記録する対象のアプリケーションの中でも、記録する箇所を必要な部分のみに限定して、診断ログを記録することができる。このため、メモリダンプ等に比べて詳細な障害診断を行うことができる実行ログを取得しても、大きなオーバヘッドが発生してしまうことを回避することが可能となる。よって、全てのアプリケーションから診断ログ２０を記録する場合と比較して、大幅にオーバヘッドを削減することができる。また、各診断ログ記録クライアント２００が、アプリケーションの障害情報１０を診断情報配布サーバ１００へ送信することにより、診断情報配布サーバ１００において、障害情報１０に基づいて記録ポリシー５０を更新させることができる。よって、診断情報配布サーバ１００に対して、診断ログ記録クライアント２００が効率的に診断ログを記録することができるように、診断情報３０を適切に配布させることができる。
【００７４】
また、第１実施形態に係る診断ログ記録クライアント２００によれば、情報送信部２４０は、診断ログ解析サーバ３００に診断ログ２０を送信することができるので、診断ログ２０を診断ログ解析サーバ３００に集約して解析させることができる。
【００７５】
また、第１実施形態に係る診断ログ記録クライアント２００によれば、診断ログ記録部２３０が、コンポーネント特定情報により特定されるアプリケーションの実行開始を検知した後にアプリケーションの診断ログを記録することができるので、診断ログ記録クライアント２００は、診断情報３０のコンポーネント特定情報により特定される特定のアプリケーションに対する診断ログ２０のみを記録することができる。また、診断ログ記録部２３０は、当該アプリケーションの実行開始を検知することで、診断ログ２０の記録を開始することができる。これにより、記録対象となっているアプリケーションの診断ログ２０を確実に記録することが可能となるとともに、当該アプリケーションの非実行時には、一切のオーバヘッドが発生しないため、処理負荷の軽減を図ることができる。
【００７６】
また、第１実施形態に係る診断ログ記録クライアント２００によれば、記録対象となるアプリケーション上の実行命令を特定する情報を記録箇所特定情報３２に含み、診断ログ記録部２３０は、実行命令が発生するアドレスを特定し、アプリケーションの実行がアドレスに至った際に、診断ログ２０を記録することができる。これにより、例えば、特に障害が発生すると想定される箇所、あるいは障害発生時の影響が大きいと思われる箇所で実行ログを記録するように、アプリケーション上の実行命令を特定することができる。そして、診断ログ記録部２３０は、当該実行命令が発生するアドレスを特定して当該アドレスにおける実行ログを記録することができる。これにより、診断情報によって特定される特定時にのみ実行ログを診断ログ２０として記録することが可能となるので、必要な実行ログを確実に記録することができるとともに、余分な実行ログを記録することによるオーバヘッドを削減することが可能となる。また、診断情報３０によって、診断ログ２０を記録する箇所をアドレスではなく実行命令で特定することができる。実行ログの記録対象となる実行命令が存在するアドレスは、診断ログ記録クライアントの実行環境に依存するため、診断ログ記録クライアントごとに異なる可能性が高い。しかし、本実施形態に係る診断ログ記録クライアント２００によれば、格診断ログ記録クライアント上で、診断ログ２０の記録対象となるアドレスが異なる場合でも、共通の診断情報３０を用いて、共通の診断ログ２０を記録することが可能となる。
【００７７】
さらに、第１実施形態に係る診断ログ記録クライアント２００によれば、情報送信部２４０が、障害情報をある程度蓄積してから診断情報配布サーバ１００に送信することができるため、送信に係るオーバヘッドを削減することができる。
【００７８】
（第２実施形態）
第２実施形態に係る診断情報配布サーバは、例えば、携帯電話のアプリケーションの診断ログを効率的に記録するために採用されるものであって、第１実施形態の診断情報配布サーバと同様に構成されるものである。なお、第２実施形態においては、第１実施形態と同一箇所については説明を省略し、異なる箇所を中心に説明する。
【００７９】
まず、本実施形態に係る診断情報配布サーバ１００を有する診断ログ記録システム１の構成について、図６を参照して説明する。図６は、診断ログ記録システム１の構成概要図である。図６に示すように、診断ログ記録システム１は、第１実施形態と同様に、診断ログ記録クライアント２００、診断情報配布サーバ１００及び診断ログ解析サーバ３００を備えて構成される。診断ログ記録クライアント２００、診断情報配布サーバ１００及び診断ログ解析サーバ３００の構成は第１実施形態と同様である。なお、説明理解の容易性を考慮して、第２実施形態においては、診断ログ記録クライアント２００が複数存在するものとし、各診断ログ記録クライアント２００は、複数のコンポーネントをそれぞれ実行可能に構成されているものとする。また、ここでは、これらの診断ログ記録クライアント２００によって配属端末が構成されているものとする。配属端末とは、診断情報配布サーバ１００と通信可能に構成された端末である。また、各診断ログ記録クライアント２００がそれぞれ実行可能な複数のコンポーネントは、全診断ログ記録クライアント２００に共通したものとする。さらに、診断ログ記録クライアント２００が実行可能な複数のコンポーネントの数は、診断ログ記録クライアント２００の数に比べて極めて少ないものとする。上述した仮定を満たす例として、診断ログ記録クライアント２００が携帯電話である場合を説明する。すなわち、コンポーネントは、携帯電話で実行されるアプリケーションとなる。
【００８０】
次に、診断情報配布サーバ１００の詳細な機能について説明する。図６に示すように、診断情報配布サーバ１００は、機能的には、情報受信部（サーバ側受信手段）１１０、診断情報生成部（診断情報生成手段）１２０、障害情報処理部（障害情報処理手段）１３０、記録ポリシー生成部（端末特定情報生成手段）１４０及び情報送信部（サーバ側送信手段）１５０を備えて構成される。
【００８１】
情報受信部１１０は、配属端末から障害情報１０を受信する機能を有している。また、情報受信部１１０は、受信した障害情報１０を、障害情報処理部１３０へ出力する機能を有している。また、情報受信部１１０は、診断ログ解析サーバ３００から診断結果６０を受信する機能を有している。情報受信部１１０は、受信した診断結果６０を、診断情報生成部１２０へ出力する機能を有している。ここで、情報受信部１１０が受信する障害情報１０は、第１実施形態において説明した障害情報１０と同様であって、メモリダンプ等の障害を特定する情報が含まれており、障害深刻度特定情報が含まれても良い。また、情報受信部１１０が受信する診断結果６０は、第１実施形態において説明した診断結果６０と同様の情報である。
【００８２】
診断情報生成部１２０は、診断情報３０を生成する機能を有している。また、診断情報生成部１２０は、予め診断ログ記録クライアント２００上で動作する全てのアプリケーションを把握可能に構成されている。このため、診断情報生成部１２０は、コンポーネント特定情報３１を容易に作成することが可能に構成されている。また、診断情報生成部１２０は、診断ログ解析サーバ３００から受信した診断結果６０に基づいて、診断情報３０を更新する機能を有している。また、診断情報生成部１２０は、生成又は更新した診断情報３０を、情報送信部１５０へ出力する機能を有している。ここで、診断情報生成部１２０が生成又は更新する診断情報３０は、第１実施形態において説明した診断情報３０と同様であって、各アプリケーションに対応して生成され、少なくともコンポーネント特定情報３１及び記録箇所特定情報３２を含むものである。また、記録箇所特定情報３２は、第１実施形態と同様に、アプリケーションごとに決定され、例えばアプリケーション開発者によって用意されるものである。
【００８３】
障害情報処理部１３０は、障害情報１０を処理し、障害処理情報４０を導出する機能を有している。障害情報処理部１３０は、記録ポリシー生成部１４０がどのような方針で記録ポリシー５０を生成するかによって、どのような障害処理情報４０を導出するかを決定する機能を有している。また、障害情報処理部１３０は、導出した障害処理情報４０を記録ポリシー生成部１４０へ出力する機能を有している。障害情報処理部１３０が導出する障害処理情報４０は、記録ポリシー生成部１４０がどのような方針で記録ポリシー５０を生成するかに依存するため、詳しくは第３実施形態で述べる。
【００８４】
記録ポリシー生成部１４０は、どの診断ログ記録クライアント２００がどのアプリケーションの診断ログ２０を記録すべきかを決定する機能を有している。例えば、記録ポリシー生成部１４０は、全ての障害について、「ある一定の障害回数程度で診断ログを記録したい」などといった、障害に対する対応方針（記録ポリシー５０）により、対象となる診断ログ記録クライアント２００及び対象となるアプリケーションを決定する機能を有している。記録ポリシー５０は、各アプリケーションの障害情報によって決定され、全ての診断ログ記録クライアント２００について、診断情報３０を関連付けるものである。なお、記録ポリシー生成部１４０の機能の詳細については第３実施形態で述べる。
【００８５】
一つの診断ログ記録クライアント２００に対しては、必ず一つ以上のアプリケーションが対応する。各アプリケーションに対応する診断情報３０は、コンポーネント特定情報３１により特定することができるため、記録ポリシー生成部１４０によって診断ログ記録クライアント２００とアプリケーションとが対応付けされれば、各診断ログ記録クライアント２００に対応する診断情報３０を特定することができる。
【００８６】
情報送信部１５０は、記録ポリシー５０を参照し、適切な診断ログ記録クライアント２００へ、診断情報３０を配信する機能を有している。情報送信部１５０は、記録ポリシー５０が更新される度に診断情報３０を配信する機能を有している。また、第１実施形態と同様に、診断結果６０を受信して、診断情報３０の記録箇所特定情報３２を更新した場合には、更新した診断情報３０に対応する診断ログ記録クライアント２００へ、当該診断情報３０を配布する機能を有している。
【００８７】
次に、本実施形態に係る診断情報配布サーバ１００の動作について説明する。まず、診断情報配布サーバ１００において、診断情報生成部１２０が診断情報３０を生成する。診断情報生成部１２０は、予め診断ログ記録クライアント２００上で動作する全てのアプリケーションを把握可能に構成されているので、例えば、予め把握してあるアプリケーションの中から１つを選択して、選択したアプリケーション名を診断情報３０のコンポーネント特定情報３１とする。また、例えば選択したアプリケーションの開発者から提供された記録箇所に基づいて、当該アプリケーションの記録箇所特定情報３２を生成する。診断情報生成部１２０は、生成した診断情報３０を、情報送信部１５０に出力する。情報送信部１５０は、入力した診断情報３０を、記録ポリシー５０によって設定された診断ログ記録クライアント２００へ送信する。
【００８８】
ここで、診断ログ解析サーバ３００から診断結果６０を受信した場合には、診断情報生成部１２０は、診断結果６０に基づいて診断情報３０を更新し、更新した診断情報３０を情報送信部１５０に出力する。診断情報３０に含まれる記録箇所特定情報３２は、アプリケーションの診断ログ２０を記録するための情報であるが、不具合が解決されることによりその内容が変わる場合も考えられる。例えば、診断情報３０により、より不具合が発生すると思われるアドレスの実行ログを記録するように指定されていたとする。そして、想定していた不具合に関する診断ログ２０が記録され、無事に障害に対する修正がなされたとする。このような場合、当該箇所に関する実行ログは必要ないのであれば、その部分の実行ログを記録しないように、診断結果６０により記録箇所特定情報３２を修正する。そして、情報送信部１５０は、更新された診断情報３０を入力し、記録ポリシー５０によって設定された診断ログ記録クライアント２００へ送信する。これにより、以降の診断ログ２０の記録に係るオーバヘッドを削減することができる。
【００８９】
また、診断ログ記録クライアント２００から障害情報１０を受信した場合には、障害情報処理部１３０が障害情報１０に基づいて障害処理情報４０を導出し、障害処理情報４０を記録ポリシー生成部１４０へ出力する。記録ポリシー生成部１４０は、障害処理情報４０を入力すると、記録ポリシー５０を生成する。記録ポリシー生成部１４０は、障害処理情報４０が変更される度に記録ポリシー５０を生成し、診断情報３０の送信対象となる診断ログ記録クライアント２００を見直して、変更が必要な場合には追加、削除等を行う。記録ポリシー生成部１４０が記録ポリシー５０を生成又は更新した場合には、その生成又は更新の度に情報送信部１５０が送信対象の診断ログ記録クライアント２００を設定して、診断情報３０を送信する。
【００９０】
以上、第２実施形態に係る診断情報配布サーバ１００によれば、例えば複数のアプリケーションを実行可能に構成された診断ログ記録クライアント２００が複数存在する場合には、各アプリケーションに対応する診断ログ２０を記録する診断ログ記録クライアント２００を、記録ポリシー５０により設定することができる。このため、各診断ログ記録クライアント２００が分散して診断ログ２０を記録するように制御することができるので、診断ログ２０の記録に係るオーバヘッドを削減することが可能となる。また、診断情報３０には、コンポーネント特定情報３１に加えて、記録箇所特定情報３２を含むことができるので、アプリケーション実行時の実行ログのうち、取得する範囲を限定し、特定の箇所のみを診断ログ２０として収集することが可能となる。これにより、処理負荷の軽減を図ることができる。さらに、記録ポリシー５０を、各アプリケーションの障害情報１０によって決定することができるため、例えば、アプリケーションの障害発生頻度等に応じて、収集する診断ログ２０を柔軟に設定することが可能となる。これにより、障害に対する修正に至るまでの時間等が障害の発生確率やアプリケーションの実行確率等によってばらつくことを回避することができたり、各障害に対する修正がなされるまでの見込みを立てたりすることが可能となる。
【００９１】
また、第２実施形態に係る診断情報配布サーバ１００によれば、診断情報３０の記録箇所特定情報３２が更新された場合には、診断情報配布サーバ１００が直ちに当該診断情報３０を対応する診断ログ記録クライアント２００のみに配布することができるので、診断ログ記録クライアント２００は、記録する診断結果６０を更新することが可能となる。よって、以降の障害の診断を効率的に行うことができる。
【００９２】
（第３実施形態）
第３実施形態に係る診断情報配布サーバは、第１、２実施形態の診断情報配布サーバと同様に構成されるものである。なお、第３実施形態においては、第１、２実施形態と同一箇所については説明を省略し、異なる箇所を中心に説明する。
【００９３】
本実施形態に係る診断情報配布サーバ１００を有する診断ログ記録システム１の構成は、第２実施形態と同様である。
【００９４】
次に、本実施形態に係る診断情報配布サーバ１００の障害情報処理部１３０及び記録ポリシー生成部１４０の動作について詳細を述べる。以下では、説明理解の容易性を考慮して、配属端末（診断情報配布サーバ配下のクライアント）それぞれに１〜ｎまでの整数をＩＤとして割り振り、アプリケーション（コンポーネント）には、１〜ｍまでの整数をＩＤとして割り振る。また、全ての配属端末は診断ログ記録クライアント２００と同一構成とする。また、単位時間当たりに、クライアントｉ（ｉ=1,2,…,ｎ）において、アプリケーションｊ（ｊ=1,2,…,ｍ）に発生する平均障害発生回数をｅｉｊとする。また、アプリケーションｊから診断ログ２０を記録する診断ログ記録クライアントのＩＤをｃｊｋ（ｋ=1,2,…,ｌ）とする。ただし、１≦ｃｊｋ≦ｎである。上記のように設定した場合、記録ポリシー５０を生成する際には、このｃｊｋを導出すれば良い。なぜなら、これにより、アプリケーションｊの診断ログ２０を記録する全ての診断ログ記録クライアント２００が決定されることとなり、アプリケーションｊに対応する記録ポリシー５０が決定されるためである。同様に、全てのアプリケーションに対して、ｃｊｋを決定することで、記録ポリシー５０が生成される。
【００９５】
ここで、例えば、システム管理者の方針により、全てのアプリケーションについて、診断ログ２０が記録されるまでに要する期間（診断ログ記録期間）の期待値を一定値Ｔ１以下にするという方針がある場合を説明する。
【００９６】
障害情報処理部１３０は、配属端末から受信した障害情報１０を、一定期間、蓄積する。これにより、各アプリケーションについて、配属端末であるクライアント上で一定期間に発生した障害回数が分かるため、単位時間当たりにクライアントｉにおいて、アプリケーションｊに発生する平均の障害回数ｅｉｊが分かる。ここで、診断ログ２０が記録されるということは、クライアントｃｊｋで表される何れかの診断ログ記録クライアント２００で、アプリケーションｊが実行されることである。そこで、アプリケーションｊの診断ログ２０が単位時間当たりに記録される確率ｒｊは、以下の式１で表すことができる。
【数１】
2010117934.tif 000003
【００９７】
診断ログ２０が記録されるまでの期間の期待値Ｔ１は、単位時間当たりに診断ログ２０が記録される確率ｒｊの逆数であるため、以下の式２を満たせばよい。
【数２】
2010117934.tif 000004
また、式２は以下の式３に変形することができる。
【数３】
2010117934.tif 000005
【００９８】
ここで、式３を不等式Ａｊとおく。右辺は既知であるため、これを満たすように、適当にクライアントｉをｃｊｋに割り当てれば、診断ログ２０が記録されるまでに要する期間の期待値を一定値Ｔ１以下にするというシステム管理者の方針は達成できる。 
【００９９】
次に、全てのアプリケーションｊが、不等式Ａｊを満たすように、クライアントｉをｃｊｋに割り当てる方法について述べる。全てのｉについて、アプリケーションｊの平均の障害回数ｅｉｊは既知であるため、クライアントｉをｃｊｋに割り当てることで、左辺の和算の値は求まる。そこで、診断ログ２０の記録に係わる負荷を最小限とするため、あるアプリケーションについて、クライアントｉをｃｊｋに割り当てることで左辺を計算していき、左辺が右辺を超えたところで、割り当てを終了すれば良い。ただし、適当にクライアントを割り当てた場合、一部のクライアントが数多くのアプリケーションの診断ログを記録するクライアントとして割り当てられることで、クライアント間に負荷の差が発生する可能性がある。そこで、「全てのクライアントは、必ず同じ数のコンポーネントの診断ログ２０を記録する」ものとする。すなわち、不等式Ａｊは、例えば下記のように解く。
【０１００】
まず不等式Ａ１について、アプリケーション１の平均の障害回数ｅ１ｉが最大値をとるクライアントｉをｃ１１とする。次に当該クライアントｃ１１を除いた全てのクライアントの中で、アプリケーション１の平均の障害回数ｅ１ｉが最大値をとるクライアントをｃ１２とする。このようにして、不等式Ａ１を満たすまで、クライアントｉをｅ１ｋに割り当てていく。同様に不等式Ａ２についても、未だ一度も割り当てられていないクライアントについて、アプリケーション２の平均の障害回数ｅ２ｉが最大値をとるクライアントｉをｃ２ｋとして割り当てていく。もし、全てのクライアントが一通り割り当てられた場合には、次の割り当ては全てのクライアントを候補として行う。このようにして、不等式Ａmまでクライアントｉをｃｊｋに割り当てていくことで、全ての診断ログ記録クライアント２００は、同一数か、それより一つ少ない数のアプリケーションに対する診断ログ２０の記録に割り当てられることとなるために、公平性がある程度保たれることとなる。
【０１０１】
また、アプリケーションｊの平均の障害回数ｅｉｊが大きい診断ログ記録クライアント２００から割り当てていく例を説明したが、これは以下の理由による。各診断ログ記録クライアント２００が、単位時間当たりの実行回数が多いアプリケーションの診断ログ２０の記録を受け持つこととなるため、全体的に、各診断ログ記録クライアント２００の記録対象となるアプリケーション数の合計値が少なくなる。実施形態１で述べた通り、診断ログ記録クライアント２００は、実行されるアプリケーションが記録対象であるか否かを検知する必要があるが、検知するアプリケーション数が削減されることで、この検知処理を軽減することが可能となる。
【０１０２】
次に、別の例として、管理者の方針により、全てのアプリケーションについて、診断ログ２０が記録されるまでに発生する障害の回数を一定値Ｔ２以下にするという方針がある場合を説明する。
【０１０３】
障害情報処理部１３０は、配属端末受信した障害情報１０を、一定期間、蓄積する。上述した例と同様に、アプリケーションｊの平均の障害回数ｅｉｊが分かる。また、配属端末において、アプリケーションｊにおける単位時間あたりに発生する障害回数の合計をＥｊとすると、Ｅｊは以下の式４で表すことができる。
【数４】
2010117934.tif 000006
【０１０４】
ここで、アプリケーションｊの診断ログ２０が単位時間当たりに記録される確率ｒｊをＥｊで割ることにより、障害発生時に、それが診断ログ２０を記録するクライアント、すなわちクライアントｃｊｋで発生する確率ｑｊが導出される。確率ｑｊは、以下の式５により表される。
【数５】
2010117934.tif 000007
【０１０５】
式５により表される確率ｑｊは、アプリケーションｊの障害発生時に診断ログ２０が記録される確率に等しい。診断ログ２０が記録されるまでに発生する障害回数の期待値は、障害発生時に診断ログが記録される確率の逆数であるため、以下の式６を満たせばよい。
【数６】
2010117934.tif 000008
また、式６は以下の式７に変形することができる。
【数７】
2010117934.tif 000009
【０１０６】
式７を不等式Ｂｊとおく。ここで、右辺は既知であるため、これを満たすように、適当にクライアントｉをｃｊｋに割り当てれば、上記で述べたシステム管理者の方針は達成できる。この不等式Ｂｊは、上述した不等式Ａｊと全く同様に解くことができるため、解き方については省略する。
【０１０７】
次に、障害情報１０が深刻度を含む場合を説明する。例えば、システム管理者がａ、ｂ、ｃ、ｄの４段階の障害深刻度を決定し、ａが最も深刻で、順にａ＞ｂ＞ｃ＞ｄの順で深刻度合いが決定されているものとする。例えば、携帯電話において、ユーザが利用するアプリケーションであった場合に、以下の通りに、障害の深刻度が決定されているものとする。
１  ａ：ユーザデータに影響が及ぶ障害（データ破壊等）
２  ｂ：アプリケーションがフリーズし、操作が効かなくなる障害
３  ｃ：アプリケーションが強制終了、あるいはリセットする障害
４  ｄ：その他の障害
【０１０８】
診断ログ記録クライアント２００は、障害発生時に、障害情報１０に、上記４つの何れかの深刻度に属する障害であったか特定するための、障害深刻度特定情報を含める。
【０１０９】
ここで、別の例として、システム管理者の方針により、深刻度の大きい障害を、より高い優先度で修正するという方針がある場合を説明する。このような方針に基づく記録ポリシーは、例えば以下の通りに決定することができる。
【０１１０】
診断ログ記録クライアントｉ、アプリケーションｊにおける、単位時間当たりの平均障害発生回数は、上述の通りｅｉｊで表される。ここで、診断ログ記録クライアントｉにおけるアプリケーションｊの平均障害深刻度をｓｉｊとする。平均障害深刻度ｓｉｊとは、当該コンポーネントに発生する障害の障害深刻度の平均値である。平均障害深刻度ｓｉｊは、深刻度特定情報により、容易に導出可能である。これらの積算値ｕｉｊ＝ｅｉｊ・ｓｉｊは、単位時間当たりに報告される障害深刻度となる。後は、単位時間当たりの平均障害発生回数ｅｉｊを障害深刻度ｕｉｊと置き換えて、既に述べた二つの方針の何れかと同様に、不等式を解けばよい。
【０１１１】
以上、第３実施形態に係る診断情報配布サーバ１００によれば、例えば複数のアプリケーションを実行可能に構成された診断ログ記録クライアント２００が複数存在する場合には、各アプリケーションに対応する診断ログ２０を記録する診断ログ記録クライアント２００を、記録ポリシー５０により設定することができる。このため、各診断ログ記録クライアント２００が分散して診断ログを記録し、診断ログ２０の記録に係るオーバヘッドを削減することが可能となる。また、診断情報３０には、コンポーネント特定情報に加えて、記録箇所特定情報を含むことができるので、コンポーネント実行時の実行ログのうち、取得する範囲を限定し、特定の箇所のみを診断ログ２０として収集することが可能となる。これにより、処理負荷の軽減を図ることができる。さらに、記録ポリシー５０は、各コンポーネントの障害情報１０によって決定することができるため、例えば、アプリケーションの障害発生頻度等に応じて、診断ログ２０を記録する診断ログ記録クライアントを柔軟に設定することが可能となる。これにより、障害に対する修正に至るまでの時間等が障害の発生確率やアプリケーションの実行確率等によってばらつくことを回避することができたり、障害に対する修正がなされるまでの見込みを立てたりすることが可能となる。
【０１１２】
また、第３実施形態に係る診断情報配布サーバ１００によれば、障害情報処理部１３０が、障害情報１０により、配属端末配下のクライアントｉにおける、アプリケーションｊの単位時間当たりの平均障害発生回数ｅｉｊ（第１障害発生確率）を導出することができる。これにより、アプリケーションｊの診断ログ２０を記録する診断ログ記録クライアントｉが決定されれば、診断ログ記録クライアントｉにおける、単位時間あたりのアプリケーションｊの平均障害発生回数ｅｉｊの合計（第２障害発生確率）を算出できる。これは、単位時間あたりに診断ログ２０が記録される確率ｒｊに等しいため、例えば、第２障害発生確率が与えられれば、アプリケーションｊを記録する診断ログ記録クライアントｉを決定することができ、それに基づき記録ポリシー５０を生成することが可能となる。また、診断ログ記録期間は、第２障害発生確率の逆数であるため、期待値が与えられれば、その期待値を満たす記録ポリシー５０を生成することができる。すなわち、診断ログ記録期間が例えばシステム管理者が指定した期待値Ｔ１を満たすように、記録ポリシー５０を生成することができる。よって、どのようなアプリケーションに発生する障害についても、例えばシステム管理者が要求する一定の期間内に診断ログ２０を取得することができる。
【０１１３】
また、第３実施形態に係る診断情報配布サーバ１００によれば、配属端末配下のクライアントについて、第１障害発生確率を合計することで、アプリケーションｊの全診断ログ記録クライアントｉにおける単位時間当たりの平均障害発生回数の合計（第３障害発生確率）を導出することができる。そして、第２障害発生確率を、第３障害発生確率で割ることにより、発生した障害が、アプリケーションｊの診断ログ２０を記録する診断ログ記録クライアント２００である確率を求めることができる。これは、障害発生時に診断ログ２０が記録される確率ｒｊと等しい。また、障害発生回数は、第２障害発生確率の逆数であるため、この期待値が与えられることで、それを満たす記録ポリシー５０を生成することが可能となる。すなわち、診断ログ２０が記録されるまでに発生する障害の回数が例えばシステム管理者が指定した期待値Ｔ２を満たすように、記録ポリシー５０を生成することができる。よって、どのようなアプリケーションに発生する障害についても、例えばシステム管理者が要求する一定の発生回数内に診断ログ２０を取得することができる。
【０１１４】
また、第３実施形態に係る診断情報配布サーバ１００によれば、障害の深刻度を考慮して記録ポリシー５０を生成することができる。例えば、記録ポリシー生成部１４０は、深刻度が高い障害が発生したアプリケーションに対しては、多くの診断ログ記録クライアント２００が診断ログ２０を記録するように、記録ポリシー５０を生成する。これにより、当該アプリケーションに障害が発生した際の診断ログ記録確率が高くなるので、障害に対する修正も迅速に行うことができる。
【０１１５】
また、第３実施形態に係る診断情報配布サーバ１００によれば、ある一定期間は障害情報１０を蓄積し、ある程度情報が蓄積された時点で障害処理情報４０を導出することができる。診断情報配布サーバ１００は、診断ログ記録クライアント２００から障害情報１０を非同期に受け取る。しかし、これらを受け取る度に、記録ポリシー５０を更新した場合、診断情報配布サーバ１００に処理コストが発生するだけではなく、診断ログ記録クライアント２００は、頻繁に診断ログ２０を記録するアプリケーションを変更する必要がある。そこで、ある一定期間の間は、障害情報処理部１３０は、これらの情報を蓄積し、ある程度情報が蓄積された時点で障害処理情報４０を導出し、記録ポリシー生成部１４０は記録ポリシー５０を生成し、その後、診断情報３０を診断ログ記録クライアント２００へ配布する。これにより、所外処理情報の導出、記録ポリシー５０の生成、診断情報の配布等の実行頻度を抑えることができるので、診断情報配布サーバ１００や診断ログ記録クライアント２００における処理負荷の低減を図ることが可能となる。
【０１１６】
以上、本発明の好適な実施形態について説明したが、本発明は上述した実施形態に限定されないことは言うまでもない。
【０１１７】
例えば、上述した上記実施形態においては、診断ログ記録システム１において、診断ログ解析サーバ３００が存在する例を説明したが、診断ログ解析サーバ３００は要求されるシステムの性能に応じて設ければよい。この場合、診断ログ記録クライアント２００は、診断ログ２０を診断ログ解析サーバ３００へ送信する機能を有さなくてもよく、また、診断情報配布サーバ１００は、診断結果６０を受信し、診断結果６０に基づいて診断情報３０を更新する機能を有さなくてもよい。
【図面の簡単な説明】
【０１１８】
【図１】実施形態に係る診断ログ記録クライアントを有する診断ログ記録システムの構成概要図である。
【図２】実施形態に係る診断情報配布サーバ、診断ログ記録クライアントおよび診断ログ解析サーバのハードウェア構成図である。
【図３】実施形態に係る診断ログ記録クライアントの診断ログの記録を説明する概要図である。
【図４】実施形態に係る診断ログ記録クライアントの動作を示すフローチャートである。
【図５】実施形態に係る診断ログ記録クライアントのアプリケーションコードを説明する概要図である。
【図６】実施形態に係る診断情報配布サーバを有する診断ログ記録システムの構成概要図である。
【符号の説明】
【０１１９】
１…診断ログ記録システム、１００…診断情報配布サーバ、１１０…情報受信部（サーバ側受信手段）、１２０…診断情報生成部（診断情報生成手段）、１３０…障害情報処理部（障害情報処理手段）、１４０…記録ポリシー生成部（端末特定情報生成手段）、１５０…情報送信部（サーバ側送信手段）、２００…診断ログ記録クライアント（診断ログ記録端末）、２１０…情報受信部（端末側受信手段）、２２０…障害情報生成部（障害情報生成手段）、２３０…診断ログ記録部（診断ログ記録手段）、２４０…情報送信部（端末側送信手段）、３００…診断ログ解析サーバ。
【図１】
2010117934.tif 000010
【図２】
2010117934.tif 000011
【図３】
2010117934.tif 000012
【図４】
2010117934.tif 000013
【図５】
2010117934.tif 000014
【図６】
2010117934.tif 000015