JP2014182561A - 計算機システム、プロセス及びスレッドの監視方法 - Google Patents

Abstract

【課題】ソースコードの変更や再コンパイルを行わずに誤ってスレッドを異常と判定する可能性を低減させる。
【解決手段】プロセスを構成する１以上のスレッドを実行する計算機システムで、前記プロセスは、第１のプロセスと、第１のプロセスを監視する監視プロセスと、第１のプロセスの監視条件を設定する監視設定部と、を含み、第１のプロセスは、第１のプロセスの処理を実行する第１のスレッドと、第１のスレッドを監視する監視スレッドと、第１のスレッドがライブラリから所定の関数を呼び出すと所定の処理を実行する関数フック部と、を含み、関数フック部は、第１のスレッドが、ライブラリから所定のフック対象関数を呼び出したときには、第１のスレッドの正常状態を示す第１の生存情報を更新し、監視スレッドは、第１の生存情報が更新されていない場合には、第１のスレッドに異常が発生したことを示す異常スレッド情報を記憶部に書き込む。
【選択図】図２

Description

本発明は、プロセスとスレッドの監視を行う計算機システムに関する。

高信頼性を要求される計算機システムは、システムを構成するプロセス及びスレッドが障害を起こした場合でも、システム全体を止めずに、縮退運転を行い、提供するサービスを継続する必要がある。従って、このような計算機システムは、プロセス及びスレッドが正常に稼働しているかを監視し、プロセス及びスレッドが異常な状態に陥った場合は、この異常を検出する必要がある。この異常の検出機能を、死活監視機能と呼ぶ。

ここで、プロセスとはプログラムの実行単位である。プロセスは、プログラム内で利用される変数と状態を保持し、一つ以上のスレッドから構成される。

ここで、スレッドとはプログラムが含む処理の実行単位である。ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）が、各スレッドにＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）時間（またはタイムスライス時間）を割り当てる。

スレッドの死活監視方法の一つとして特許文献１に記載の方法は、スレッドを監視するという特別な役割を持った監視スレッドが、他のスレッドに対して、正常に稼働しているか否かを、指定された監視周期で周期的に問い合わせ、スレッドはこの問い合わせに対して応答するというものである。

また、近年、計算機システムに占めるソフトウェアの割合と規模が拡大し、システムに占めるＯＳやサードパーティ製など外部調達するソフトウェアの割合が増加している。

自社開発のプログラムには、ソースコードを修正することにより、死活監視機能を実装することができるが、ソースコードがないプログラム、あるいはソースコードがあってもライセンス条項等の理由からソースコードを修正することが出来ないプログラムには、死活監視機能を実装できない。こういったプログラムに当てはまるのは、前記の外部調達するソフトウェアである。従って、計算機システムの信頼性を上げるには、このようなプログラムのプロセス及びスレッドに対しても死活監視機能を適用しなければならない。然しながら、特許文献１に記載の方法のように、ソースコードの修正が必要な死活監視方式ではこの問題を解決できない。

この問題を解決する技術として、特許文献２に記載の、スレッドの異常状態を引き起こす一つの原因であるデッドロックを検知する方法がある。これは、排他制御を行うためのリソース占有（ロック）及びリソース解放（アンロック命令）を行う関数をフック（関数フック）し、排他制御の情報を取得する処理を実行し、本来行うべきロック及びアンロック命令を実行する。そして、取得した排他制御情報を基に、スレッド間のデッドロックを検出するものである。

ここでデッドロックとは、複数のプロセスまたはスレッドがリソースを共有する場合に、お互いがお互いの取得したリソースの解放を待つ状況に陥り、双方のスレッドの処理が進まないことを意味する。

ここで関数フックとは、任意の関数が呼び出されたとき、その関数の呼び出し前に、前記の処理とは別な処理を行う関数を呼び出し、この処理を実施することを意味する。

また、特許文献２で記載の関数フックを利用し、特許文献１に記載の死活監視方法を実施することができる。この場合、特許文献１が抱える問題（ソースコードの修正が必要であること）を解決することができる。解決例として、スレッドが特定の関数を実行した際に、関数フックを実行し、スレッドが正常に稼働していることを監視スレッドに伝える生存報告処理を行う方法が考えられる。この方法によれば、スレッドのソースコードに、生存報告処理を行う命令を記述する必要がなくなる。

特開平１１−２３２１４３号公報 特開２００９−２７１８５８号公報

前述の特許文献１には以下の問題点が存在する。

特許文献１における第一の問題点は、死活監視の対象となるプログラムのソースコードを修正しなければならないため、ソースコードが入手できないプログラムに適用できないことである。

特許文献１における第二の問題点は、監視対象のスレッドが大量の処理を行わなければならない状態に陥った場合、監視スレッドが発行する周期的に問い合わせに応答ができず、監視スレッドが、そのスレッドを誤って異常と判定する場合があることである。

特許文献２に記載の関数フックを利用し、特許文献１に記載の死活監視方法を実行する場合に以下の三つの問題点が存在する。

第一の問題点は、スレッドがいつ関数フック対象の関数を呼び出すかが予め分からず、監視スレッドの監視周期内にスレッドが生存報告処理を行えず、監視スレッドが誤って前記スレッドを異常と判定される場合があることである。

監視スレッドが、予め指定された監視周期内に、スレッドが生存報告を行わない場合、そのスレッドを異常と判定する。スレッドは、関数フックの対象とした関数（以後、フック対象関数）を呼び出した際、生存報告処理をする。

ソースコードが入手できないプログラムの場合、スレッドのソースコードにはどのような命令が記述されているか不明であり、従って、いつ生存報告がなされるかが不明である。よって、監視周期内に生存報告を行わない場合があった。

ソースコードが入手できるプログラムの場合、スレッドのソースコードに記述された関数から、関数フック対象にする関数を選択することができる。しかしながら、指定された監視周期内に必ず選択した関数を実行する保証がない。よって、監視周期内に生存報告を行わない場合があった。

第二点の問題点は、スレッドがいつ関数フック対象の関数を呼び出すかが予め分からず、一定時間内に関数呼出しが集中し、それらの呼出しに伴う関数フック処理と生存報告の処理の分、関数の応答が遅延し、ＣＰＵ時間を消費してしまうことであった。従って、計算機システムが提供するサービスの性能の劣化を招く恐れがある。

監視スレッドが、予め指定された監視周期内に、スレッドが生存報告を一回でも行えば、そのスレッドを正常と判定する。

ソースコードが入手できないプログラムの場合、スレッドのソースコードにはどのような命令が記述されているか不明であり、従って、いつ生存報告がなされるかが不明である。よって、監視周期内に関数フック対象の関数を大量に呼び出す場合があり、本来一回行えば十分である生存報告処理を大量に行う場合があった。

ソースコードが入手できるプログラムの場合、スレッドのソースコードに記述された関数から、フック対象関数を選択することができる。しかしながら、指定された監視周期内に必ず選択した関数を実行する保証がない。よって、監視周期内にフック対象関数を大量に呼び出す場合があり、本来一回行えば十分である生存報告処理を大量に行う場合がある。このため、計算機システムの処理能力を浪費する恐れがあった。

第三点の問題点は、システムの稼働状態の変化に伴い、スレッドによる関数の呼び出しパターンが変化した場合、その変化に応じて死活監視の設定（フック対象関数と監視周期）を変えられないことであった。

フック対象関数の呼び出し頻度が下がった場合、前述の第一の問題点にあるように、スレッドが誤って異常と判定されることがある。フック対象関数の呼び出し頻度が上がった場合、前述の第二の問題点にあるように、システムのサービスの性能劣化を招くことがあった。

従って、本発明の目的は前述の六点の問題点を解決する方法を提供することである。

具体的には、本発明の目的は、ＯＳのカーネルの変更や、ソースコードの変更及び再コンパイルを行わず、計算機システムの稼働状態の変化に対応し、誤ってスレッドを異常と判定する可能性を低減させ、かつＣＰＵ時間の消費が低い死活監視方法を提供することにある。

本発明は、１以上のプロセスと、前記プロセスを構成する１以上のスレッドを実行する計算機システムであって、前記計算機システムは、前記プロセス、スレッド及びライブラリを保持する記憶部と、前記プロセス及びスレッドを実行する１以上のプロセッサと、を備え、前記ライブラリは、前記スレッドが呼び出す関数を有し、前記プロセスは、第１のプロセスと、前記第１のプロセスを監視する監視プロセスと、前記第１のプロセスの監視条件を設定する監視設定部と、を含み、前記第１のプロセスは、前記第１のプロセスの処理を実行する１以上の第１のスレッドと、前記第１のスレッドを監視する監視スレッドと、前記第１のスレッドが前記ライブラリから所定の関数を呼び出すと、当該関数をフックして所定の処理を実行する関数フック部と、を含み、前記監視設定部は、前記関数フック部に、前記第１のスレッドが前記ライブラリから呼び出す関数の内、前記フックする対象の関数をフック対象関数として設定し、前記関数フック部は、前記第１のスレッドが、前記ライブラリから前記フック対象関数を呼び出したときには、前記記憶部に保持されて前記第１のスレッドが正常であることを示す第１の生存情報を更新し、前記監視スレッドは、第１の監視周期となるたびに、前記記憶部に保持されて前記第１のプロセスが正常であることを示す第２の生存情報を更新し、前記第１の監視周期となるたびに、前記記憶部から前記第１の生存情報を読み込んで、前記生存情報が更新されたか否かを判定し、前記生存情報が更新されていない場合には、前記第１のスレッドに異常が発生したことを示す異常スレッド情報を前記記憶部に書き込み、前記監視プロセスは、第２の監視周期となるたびに、前記記憶部から前記第２の生存情報を読み込んで、前記生存情報が更新されたか否かを判定し、前記生存情報が更新されていない場合には、前記第１のプロセスに異常が発生したことを判定し、前記第２の監視周期となるたびに、前記記憶部から異常スレッド情報を読み込んで、異常スレッド情報の有無を判定し、異常スレッド情報が存在する場合には、前記第１のスレッドに異常が発生した情報を出力する。

本発明によれば、関数フックを利用した第１のスレッドの生存情報により、ソースコードの有無にかかわらず、第１のスレッドに対する死活監視が可能になり、かつ第１のスレッドの異常を、計算機システムの性能劣化を招くことなく、高い確率で検出することが可能になる。また、計算機システムの稼働状態の変化により、フック対象関数の呼出パターンが変化した場合にも、計算機システムを停止させることなく、フック対象関数と第１の監視周期を再計算してプロセス及びスレッドの監視を継続できる。

本発明の第一の実施例を示し、計算機システムのハードウェア構成を示すブロック図である。 本発明の第一の実施例を示し、プロセス及びスレッドの死活監視方法の概要を示す説明図である。 本発明の第一の実施例を示し、監視プロセスが保持するプロセス監視設定情報の一例を示す説明図である。 本発明の第一の実施例を示し、プロセスが共有するプロセス・スレッド監視情報及び異常スレッド情報の一例を示す説明図である。 本発明の第一の実施例を示し、監視スレッドが保持するスレッド監視設定情報の一例を示す説明図である。 本発明の第一の実施例を示し、スレッドが共有するスレッド監視情報の一例を示す説明図である。 本発明の第一の実施例を示し、プロセス及びスレッドの監視処理のシーケンス図である。 本発明の第一の実施例を示し、スレッドの異常判定と、監視プロセスへの状態通知、監視プロセスへの生存報告の処理の一例を示すフローチャートである。 本発明の第一の実施例を示し、プロセスの異常判定と、異常スレッドの状態取得処理の一例を示すフローチャートである。 本発明の第一の実施例を示し、関数フック処理のソフトウェア構成の一例を示すブロック図である。 本発明の第一の実施例を示し、関数呼出統計情報の一例を示す説明図である。 従来例を示し、関数フックを利用した死活監視方法において、誤検出の発生を示す説明図である。 従来例を示し、関数フックを利用した死活監視方法において、生存報告の多重実行を示す説明図である。 本発明の第一の実施例を示し、関数フック対象集合の決定方法を示す説明図である。 本発明の第一の実施例を示し、関数フック対象集合を決定する基準である呼出確率の確率密度の一例を示すグラフである。 本発明の第一の実施例を示し、関数フック対象集合と監視周期を決定する処理の一例を示すフローチャートである。 本発明の第二の実施例を示し、関数フック処理のソフトウェア構成の一例を示すブロック図である。 本発明の第二の実施例を示し、関数フック対象集合の呼出頻度の増加の検知を示す説明図である。 本発明の第二の実施例を示し、関数フック対象集合の呼出頻度の減少の検知を示す説明図である。 本発明の第二の実施例を示し、関数フック対象集合の呼出頻度の振動の検知を示す説明図である。 本発明の第二の実施例を示し 関数呼出変化検知の処理の一例を示すフローチャートである。

以下、本発明の一実施例を添付図面に基づいて説明する。

第一の実施例では、プロセス及びスレッドが正常に稼働しているか否かを監視する装置として、通信システムを構成するゲートウェイの機能を有する計算機を例に説明する。

なお、本実施例における関数フック処理とは、任意のライブラリとして提供される関数に対し、ライブラリの利用者が独自の処理を追加または関数本来の処理内容を変更することである。また、ライブラリとは、特定の処理及び機能を行うための再利用可能なプログラムを含む、データの集まりである。プロセス及びスレッドとは、計算機による処理の分割単位である。計算機による実行主体はスレッドである。計算機が実施する処理であるタスクは、複数の単位（プロセス）に分割され、プロセスを構成するスレッドにより実行される。なお、プロセスは、少なくとも一つ以上のスレッドから構成される。

図１は、本発明を適用する計算機システム１０のハードウェア構成を示すブロック図である。計算機システム１０は、少なくとも一つのＣＰＵ２０、メモリ３０、ストレージ４０、ネットワークインターフェース（ＮＷＩＦ）５０、ユーザーＩＦ（インターフェース）６０、これらを物理的に接続するバス（またはリンク）７０から構成される。

メモリ３０には、オペレーティングシステム（以下、ＯＳ）８０と、アプリケーションやサービスを構成するプロセス１２０と、プロセス１２０を監視する監視プロセス１００と、監視条件などを設定する監視設定プログラム１８０が読み込まれて、ＣＰＵ２０によって実行される。なお、ＯＳ８０は、関数を格納した標準ライブラリ８００を有する。また、監視設定プログラム１８０は、監視設定プロセスとしてＣＰＵ２０に実行される。

ＣＰＵ２０は、各機能部のプログラムに従って処理することによって、所定の機能を実現する機能部として機能する。例えば、ＣＰＵ２０は、監視設定プログラム１８０に従って処理することで監視設定部として機能し、監視プログラムに従って処理することで監視部（監視プロセス１００）として機能する。他のプログラムについても同様である。さらに、ＣＰＵ２０は、各プログラムが実行する複数の処理のそれぞれを実現する機能部としても処理する。計算機及び計算機システムは、これらの機能部を含む装置及びシステムである。

なお、上記の例では、監視プロセス１００や監視設定プログラム１８０等のひとつのプロセスでひとつの処理を実行するプログラムは、ひとつのスレッドとしてＣＰＵ２０に実行される。なお、計算機システム１０が実行するＯＳ８０の種類によっては、ＣＰＵ２０がプロセスを実行することができる。

計算機システム１０の各機能を実現するプログラム、テーブル等の情報は、ストレージ４０や不揮発性半導体メモリ、ハードディスクドライブ、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記憶デバイス、または、ＩＣカード、ＳＤカード、ＤＶＤ等の計算機読み取り可能な非一時的データ記憶媒体に格納することができる。

図２は計算機システム１０において、プロセス及びスレッドの死活監視を行うソフトウェアの概要を示す説明図である。

監視プロセス１００は、メモリ３０内の自身（１００）以外のプロセスである１以上のプロセス１２０が正常に稼働しているか否かの判定と、プロセス１２０を構成する１以上のスレッド１３０の中に異常なスレッドが存在するか否かの判定を、プロセス・スレッド監視情報１５０の内容を基に行う。各プロセス１２０にはそれぞれ１つの監視スレッド１４０と、関数フック部（関数フックスレッド）８１０が含まれる。また、メモリ３０には監視設定プログラム１８０が読み込まれ、スレッド１３０の死活判定を行う条件を決定し、関数フック部８１０及び監視スレッド１４０に設定する。

プロセス１２０内の監視スレッド１４０は、プロセス１２０内の自身（監視スレッド）以外のスレッドであるスレッド１３０が正常に稼働しているか否かの判定を、スレッド監視情報１６０を基に行う。監視スレッド１４０は、プロセス１２０が正常に稼働していることを示す情報と、検出した異常なスレッド１３０の情報を、プロセス・スレッド監視情報１５０に記録する。

監視プロセス１００以外のプロセスは一つ以上存在するが、図２では例としてその中の一つであるプロセス１２０を記載する。

プロセス１２０内の関数フック部８１０は、監視設定プログラム１８０によって設定されたフック対象の関数がスレッド１３０によって呼び出された際に、関数フック処理を実施し、スレッド監視情報１６０にスレッド１３０が正常に稼働していることを示す情報を記録する。また、関数フック部８１０は、呼び出された関数の記録を関数呼出統計情報１７０に記録する。

プロセス１２０内の監視スレッド１４０以外のスレッドは一つ以上存在するが、図２では例としてその中の一つであるスレッド１３０を記載する。

監視設定プログラム１８０は、関数呼出統計情報１７０に記録された関数の情報を基に、関数フック部８１０が関数フックの対象にする関数（以後、フック対象関数群）と、監視スレッド１４０がスレッド１３０の死活監視を行う監視周期を決定する。また、監視設定プログラム１８０は、関数呼出統計情報１７０に記録されたスレッド１３０による関数呼出のパターンの変化を検出し、変化後のパターンに適合するフック対象関数群と監視周期を更新する。

各プロセスまたはスレッドの処理の概要を以下に説明する。計算機システム１０のメモリ３０には、監視プロセス１００と監視設定プログラム１８０が実行されている。

まず、監視プロセス１００は、プロセス１２０の実行が開始されると、当該プロセス１２０に監視スレッド１４０と関数フック部８１０を組み込む。この処理は、監視スレッド１４０と関数フック部８１０のプロセスＩＤを、プロセス１２０と同一に設定すればよい。監視設定プログラム１８０は、関数フック部８１０にスレッド１３０がライブラリ８００から関数を呼び出すときに、フックする関数（フック対象関数８１２）を後述するように設定する。

監視プロセス１００は、処理が開始されると（１１０）、所定の監視周期となる度に（１１１）、死活判定を実行する（１１２）。この死活判定は、後述するように、プロセス・スレッド監視情報１５０に書き込まれた情報に基づいて行われる。

プロセス１２０のスレッド１３０は、処理が開始されると（１３１）、メッセージや命令等のイベントがキュー１３５に入力されるのを待機し（１３２）、キュー１３５にメッセージや命令等が入力される度にイベントとして所定の処理を実行する（１３３）。このとき、スレッド１３０がＯＳ８０の標準ライブラリ８００の関数のうち所定の関数を呼び出すと（１３４）、関数フック部８１０が生存報告処理８６０を実行する。

関数フック部８１０は、スレッド１３０が所定の関数を呼び出すと、スレッド１３０が正常に実行されていることを示す生存報告処置８６０を実行し、後述する関数呼出統計情報１７０に呼び出された関数の情報を記録し、スレッド監視情報１６０にスレッド１３０が生存していることを示す情報を記録する。

監視スレッド１４０は、処理が開始されると（１４１）、所定の監視周期となる度に（１４２）、スレッド１３０の死活判定を後述するようにスレッド監視情報１６０を読み込んで実行し（１４３）、スレッド１３０の実行状態を生存報告としてプロセス・スレッド監視情報１５０に記録する。

ここで、監視プロセス１００の監視周期（１１１）と、監視スレッド１４０の監視周期（１４２）は、異なる周期を設定することができるが、好ましくは同じ周期に設定する。なお、監視スレッド１４０の監視周期は、監視設定プログラム１８０がスレッド監視設定情報４００に設定した値を用いることができる。

監視プロセス１００は、プロセス１２０の死活監視を行う際に利用する情報を保持する。これを図３に示す。

図３は、監視プロセス１００が保持するプロセス監視設定情報２００の一例を示す説明図である。

監視プロセス１００は、プロセス死活監視を行う際に利用する情報として、プロセス監視設定情報２００を保持する。プロセス監視設定情報２００は、監視周期２１０、プロセスＩＤ２２０、保護回数２３０、異常検出時アクション２４０から構成される。

監視周期２１０は、監視プロセス１００が、プロセス・スレッド監視情報１５０を参照し、プロセス１２０の死活監視を実行する周期である。この周期は、例えば、秒で設定される。プロセスＩＤ２２０は、監視プロセス１００がプロセス１２０の死活監視を実行する対象のプロセスの識別子である。保護回数２３０は、監視プロセス１００が、監視対象のプロセス１２０が異常であると判定する際の基準に使用する情報である。保護回数２３０は、プロセス１２０の異常が連続して判定された回数を示し、図示の例ではプロセス１２０の異常が連続して３回検出されると、当該プロセス１２０に異常が発生したと判定する。異常検出時アクション２４０は、監視プロセス１００が、監視対象プロセスが異常であると判定した際に実行する処理である。なお、プロセスＩＤ２２０〜異常検出時アクション２４０は、監視対象のプロセス１２０毎にエントリが設定される。

プロセス監視設定情報２００は、計算機システム１０の起動前に使用者等が予め設定しても良いし、計算機システム１０の起動中に使用者が設定しても良い。また、計算機システム１０の稼働中に、メモリ３０に読み込まれたプロセスが実施する処理でプロセス監視設定情報２００の情報を設定しても良い。

プロセス・スレッド監視情報１５０は、プロセスが正常稼働しているか否かを示す情報と、異常と判定されたスレッドの情報を保持する。これを図４に示す。

図４は、複数のプロセス１２０が共有するプロセス・スレッド監視情報１５０及びスレッド監視情報１６０の一例を示す説明図である。

プロセス・スレッド監視情報１５０はプロセス１２０が正常に稼働しているか否かを示す情報であるプロセス監視情報３００と、異常と判定されたスレッド１３０の情報である異常スレッド情報３１０から構成される。プロセス・スレッド監視情報１５０は、監視スレッド１４０によって更新され、監視プロセス１００によって参照される。

プロセス監視情報３００は、プロセスＩＤ３０１、生存カウンタ３０２、生存カウンタ前回値３０３、連続無応答回数３０４、スレッド監視情報ポインタ３０５から構成される。

プロセスＩＤ３０１とは、監視プロセス１００がプロセス死活監視を実行する対象のプロセスの識別子である。

生存カウンタ３０２とは、プロセスＩＤ３０１で識別されるプロセス１２０が正常に稼働していることを示すために使用されるカウンタ値である。プロセスＩＤ３０１で識別されるプロセス１２０は、この生存カウンタ３０２に“１”を加算して更新することで、自身が正常に稼働していることを表す。

生存カウンタ前回値３０３とは、プロセスＩＤ３０１で識別されるプロセス１２０が正常に稼働していることを示すために使用される生存カウンタ３０２の前回の値である。監視プロセス１００は、生存カウンタ前回値３０３の値と生存カウンタ３０２の値が異なっている場合、プロセスＩＤ３０１で識別されるプロセス１２０が正常に稼働していると判定する。監視プロセス１００は、プロセスＩＤ３０１で識別されるプロセスが正常稼働していると判定した後、生存カウンタ前回値３０３に現在の生存カウンタ３０２の値を代入して更新する。

連続無応答回数３０４とは、プロセスＩＤ３０１で識別されるプロセス１２０が、監視周期２１０の間に、連続して生存カウンタ３０２の更新がなされなかった回数を示す。監視プロセス１００は、プロセスＩＤ３０１で識別されるプロセス１２０の連続無応答回数３０４が、保護回数２３０以上であった場合、このプロセス１２０を異常と判定する。

スレッド監視情報ポインタ３０５は、プロセスＩＤ３０１で識別されるプロセス１２０を構成するスレッド１３０の内、異常と判定されたスレッド１３０の情報を示す異常スレッド情報３１０へのポインタを示す。監視プロセス１００は、プロセスＩＤ３０１で識別されるプロセス１２０を構成するスレッド１３０の状態を判定するために、スレッド監視情報ポインタ３０５を参照する。

異常スレッド情報３１０とは、異常スレッドＩＤ３１１と異常検出時刻３１２から構成される。

異常スレッドＩＤ３１１は、監視スレッド１４０が異常と判定したスレッドの識別子である。

異常検出時刻３１２とは、監視スレッド１４０が異常スレッドＩＤ３１１で識別されるスレッド１３０が、異常と判定された時刻を示す。

監視スレッド１４０は、スレッド１３０の死活監視を行う際に利用する情報を保持する。これを図５に示す。

図５は、監視スレッド１４０が保持するスレッド監視設定情報４００の一例を示す説明図である。監視スレッド１４０は、スレッド１３０の死活監視を行う際に利用する情報として、スレッド監視設定情報４００を保持する。スレッド監視設定情報４００は、監視周期４１０、スレッドＩＤ４２０、保護回数４３０、異常検出時アクション４４０から構成される。なお、ひとつの監視スレッド１４０についてひとつの監視周期４１０が設定される。また、スレッドＩＤ４２０、保護回数４３０、異常検出時アクション４４０からなるエントリは、ひとつの監視スレッド１４０について監視対象のスレッド１３０の数に応じて設定される。

監視周期４１０とは、監視スレッド１４０が、スレッド監視情報１６０を参照し、スレッド１３０の死活監視を実行する周期である。図示の例では、１０秒の周期でスレッド１３０の死活監視を行う例を示す。この監視周期４１０は、後述するように設定される。スレッドＩＤ４２０とは、監視スレッド１４０がスレッド１３０の死活監視を実行する対象のスレッドの識別子である。保護回数４３０とは、監視スレッド１４０が、監視対象のスレッド１３０が異常であると判定する際の基準として使用する情報（閾値）である。異常を検出された回数が保護回数４３０を超えるまで、監視スレッド１４０はスレッド１３０を異常と判定しない。これは、計算機システム１０の負荷が大きいときなどで、応答が遅延したときに監視スレッド１４０が異常と誤判定するのを防ぐためである。

異常検出時アクション４４０とは、監視スレッド１４０が、監視対象のスレッド１３０が異常であると判定した際に実行する処理である。

スレッド監視設定情報４００は、計算機システム１０の起動前に使用者が設定しても良いし、計算機システム１０の起動中に使用者が設定しても良い。また、計算機システム１０の稼働中に、メモリ３０に保持されたプロセス１２０が実施する処理で設定しても良い。

スレッド監視情報１６０は、スレッド１３０が正常稼働しているか否かを示す情報であるスレッド監視情報を保持する。これを図６に示す。

図６は、監視スレッド１４０と複数のスレッド１３０が共有するスレッド監視情報１６０の一例を示す説明図である。

スレッド監視情報１６０は、プロセスＩＤ５０１、生存カウンタ５０２、生存カウンタ前回値５０３、連続無応答回数５０４、スレッド監視情報ポインタ５０５から一つのエントリが構成される。

スレッドＩＤ５０１とは、監視スレッド１４０がスレッド１３０の死活監視を実行する対象のスレッドの識別子である。

生存カウンタ５０２とは、スレッドＩＤ５０１で識別されるスレッド１３０が正常に稼働していることを示すために使用されるカウンタ値である。スレッドＩＤ５０１で識別されるスレッド１３０は、この生存カウンタ５０２に“１”を加算して更新することで、自身が正常に稼働していることを表す。

生存カウンタ前回値５０３とは、スレッドＩＤ５０１で識別されるスレッドが正常に稼働していることを示すために使用されるカウンタ値である。監視スレッド１４０は、この生存カウンタ前回値５０３の値と、生存カウンタ５０２の値が異なっている場合、スレッドＩＤ５０１で識別されるスレッド１３０が正常に稼働していると判定することができる。監視スレッド１４０は、スレッドＩＤ５０１で識別されるスレッド１３０が正常に稼働していると判定した後、生存カウンタ前回値５０３に生存カウンタ５０２の値を代入して更新する。

連続無応答回数５０４とは、スレッドＩＤ５０１で識別されるスレッド１３０が、監視周期４１０の間に、連続して生存カウンタ５０２の更新がなされなかった回数を示す。監視スレッド１４０は、前記スレッドの連続無応答回数５０４が、保護回数４３０以上であった場合、このスレッドを異常と判定する。

監視プロセス１００、監視スレッド１４０によるスレッド１３０の死活監視のシーケンスを図７に示す。

図７は、プロセス及びスレッドの監視処理のシーケンス図である。プロセス１２０内で実行される関数フック部８１０は、スレッド１３０が処理の実行中に予め設定されたフック対象関数を呼び出した際に、生存報告処理８６０を行う。生存報告処理８６０とは、スレッド監視情報１６０の生存カウンタ５０２に“１”を加算することで、前記スレッド１３０が正常に稼働していることを示すものである。前記スレッド１３０によるフック対象関数の呼び出しは不定期であり、周期的に行われるものではない。

監視スレッド１４０は、所定の監視周期４１０毎に各スレッド１３０が正常に稼働しているか否かを判定する死活判定処理１４３を実施する。この判定は、監視スレッド１４０がスレッド監視情報１６０のスレッドＩＤ８０１毎に、生存カウンタ５０２の値と生存カウンタ前回値５０３の値を比較する。そして、これらの値が一致しなければ、監視スレッド１４０は当該スレッド１３０が正常に稼働していると判定する。一方、生存カウンタ５０２の値と生存カウンタ前回値５０３の値が一致する場合、監視スレッド１４０は該当スレッド１３０に障害が発生したと判定し、所定の処理（異常検出時アクション２４０）を実行する。なお、監視スレッド１４０の監視条件は、監視設定プログラム１８０によって予めスレッド監視設定情報４００が設定されているものとする。

監視スレッド１４０は、死活判定処理１４３の後に、スレッド状態通知と生存報告処理１４４を実行する。監視スレッド１４０は、監視プロセス１００に対して、スレッド１３０の状態を通知して、監視スレッド１４０及びスレッド１３０が所属するプロセス１２０の生存報告処理１４４を行う。生存報告処理１４４では、監視スレッド１４０が、自身が所属するプロセスＩＤ３０１の生存カウンタ３０２と生存カウンタ前回値３０３を更新する。さらに、スレッド１３０に異常が発生した場合には、監視スレッド１４０が異常のあったスレッド１３０の識別子３１１と、異常を検出した異常検出時刻３１２のエントリを異常スレッド情報３１０に追加する。そして、監視スレッド１４０は異常スレッド情報３１０に加えたエントリへのスレッド監視情報ポインタ３０５をプロセス監視情報３００に設定する。

監視プロセス１００は、監視周期２１０毎にプロセス１２０が正常に稼働しているか否かを判定する死活判定処理１１２を実行する。また、監視プロセス１００は、プロセス１２０のスレッド１３０の状態を取得する。死活判定処理１１２は、監視プロセス１００が、プロセス監視情報３００のプロセスＩＤ３０１毎に、生存カウンタ３０２の値と生存カウンタ前回値３０３の値が異なるか否かを判定する。生存カウンタ３０２の値と生存カウンタ前回値３０３の値が異なる場合は、監視プロセス１００は当該プロセス１２０が正常に稼働していると判定する。一方、生存カウンタ３０２の値と生存カウンタ前回値３０３の値が等しい場合、監視プロセス１００は当該プロセス１２０に異常が発生したと判定する。また、監視プロセス１００は、スレッド監視情報ポインタ３０５から異常スレッド情報３１０を参照し、異常が発生したスレッド１３０を特定する。

なお、監視プロセス１００の監視周期２１０と、監視周期４１０は同じ値であることが好ましい。

監視スレッド１４０によるスレッド１３０の死活判定処理１４３と、監視プロセス１００へのスレッド１３０の状態通知、監視スレッド１４０及びスレッド１３０が所属するプロセス１２０の生存報告処理１４４の処理フローを図８に示す。

図８は、監視スレッド１４０で行われるスレッド１３０の異常判定と、監視プロセス１００への状態通知、監視プロセス１００への生存報告処理１４４の一例を示すフローチャートである。この処理は、所定の監視周期４１０となる度に監視スレッド１４０で実行される。

ステップ６１０において、監視スレッド１４０は、スレッド監視情報１６０を参照し、スレッドＩＤ５０１で識別されるスレッド１３０の生存カウンタ５０２の値と生存カウンタ前回値５０３の値を比較する。比較の結果、生存カウンタ５０２と生存カウンタ前回値５０３の値が一致していない場合は、前記関数フック部８１０が生存報告処理８６０を行ったとみなし、ステップ６１１において、前記スレッド１３０を正常と判定する。

その後、監視スレッド１４０は、ステップ６１２において、スレッド監視情報１６０の前記スレッド１３０の生存カウンタ前回値５０３に、生存カウンタ５０２の値を代入する。その後、監視スレッド１４０は、ステップ６１３において、連続無応答回数５０４に０を代入する。

その後、監視スレッド１４０は、ステップ６４０において、プロセス監視情報３００の生存カウンタ３０２に“１”を加算することで、監視スレッド１４０が属するプロセス１２０が正常に稼働していることを示す。

ステップ６１０において、監視スレッド１４０が、スレッド監視情報１６０のスレッドＩＤ５０１で識別されるスレッドの、生存カウンタ５０２と生存カウンタ前回値５０３の値を比較した結果、一致した場合は、連続無応答回数５０４に“１”を加算する。その後、監視スレッド１４０は、ステップ６２１において、連続無応答回数５０４が保護回数４３０を超過しているか否かを判定する。超過している場合、前記スレッド１３０が、監視周期４１０×保護回数４３０の間、全く生存報告がないことから、ステップ６２２において、前記スレッド１３０を異常と判定する。

その後、ステップ６２３において、監視スレッド１４０は前記スレッドの識別子を、プロセス・スレッド監視情報１５０の異常スレッドＩＤ３１１に記録する。その後、ステップ６２４において、現在時刻をプロセス・スレッド監視情報１５０の異常検出時刻３１２に記録する。その後、監視スレッド１４０は、ステップ６２５において、前記スレッド１３０が異常と判定された場合に実施する異常検出時アクション４４０を実行する。その後、ステップ６４０にて、監視スレッド１４０は、プロセス監視情報３００の生存カウンタ３０２に“１”を加算することで、監視スレッド１４０が属するプロセス１２０が正常に稼働していることを示す。

ステップ６２１において、監視スレッド１４０が、連続無応答回数５０４が保護回数４３０を超過しているか否かを判定した結果、超過していない場合は、スレッドＩＤ５０１で識別されるスレッド１３０が生存報告を行っていない期間が、監視周期４１０×保護回数４３０まで達していない。このため、監視スレッド１４０は、ステップ６３０において、前記スレッド１３０を異常疑診と判定する。異常疑診とは、前記スレッド１３０から生存報告がないものの、生存報告のない期間が、異常と判定する閾値（監視周期４１０×保護回数４３０）を超えていないため、異常ではないが異常である可能性があることを示す状態である。その後、ステップ６４０にて、監視スレッド１４０はプロセス監視情報３００の生存カウンタ３０２に“１”を加算することで、監視スレッド１４０が属するプロセス１２０が正常に稼働していることを示す。

図８に示される前記処理は、監視スレッド１４０が、スレッド監視設定情報４００に存在するスレッドの全てについて順次実施する。

監視プロセス１００によるプロセス１２０の死活判定と、プロセス１２０を構成するスレッドの状態確認処理フローを図９に示す。

図９は、監視プロセス１００で行われるプロセス１２０の異常判定と、異常スレッドの状態取得処理の一例を示すフローチャートである。この処理は、プロセス監視設定情報２００の監視周期２１０となる度に監視プロセス１００する。

ステップ７１０において、監視プロセス１００は、プロセス監視情報３００を参照し、プロセスＩＤ３０１で識別されるスレッド１３０の、生存カウンタ３０２と生存カウンタ前回値３０３の値を比較する。比較の結果、一致していない場合は、前記プロセス１２０の監視スレッド１４０が生存報告処理１４４を行ったとみなし、ステップ７１１において、前記スレッドを正常と判定する。その後、ステップ７１２において、前記プロセスの生存カウンタ前回値３０３に、生存カウンタ３０２の値を代入する。その後、ステップ７１３において、連続無応答回数３０４に“０”を代入する。

ステップ７１０において、監視プロセス１００が、プロセスＩＤ３０１で識別されるプロセス１２０の、生存カウンタ３０２と生存カウンタ前回値３０３の値を比較した結果、一致した場合は、ステップ７２０へ進んで連続無応答回数３０４に“１”を加算する。その後、ステップ７２１において、連続無応答回数３０４が保護回数２３０を超過しているか否かを判定する。連続無応答回数３０４が保護回数２３０を超過している場合、前記プロセス１２０が、監視周期２１０×保護回数２３０の間、全く生存報告がない。このため監視プロセス１００は、ステップ７２２に進んで、前記プロセス１２０を異常と判定する。その後、監視プロセス１００はステップ７２３において、前記プロセス１２０が異常と判定された場合に実施する異常検出時アクション２４０を実行する。

ステップ７２１において、監視プロセス１００が、連続無応答回数３０４が保護回数２３０を超過しているか否かを判定した結果、超過していない場合は、プロセスＩＤ３０１で識別されるプロセスが生存報告を行っていない期間が、監視周期２１０×保護回数２３０まで達していないことから、ステップ７３０において、前記プロセスを異常疑診と判定する。異常疑診とは、前記プロセスから生存報告がないものの、生存報告のない期間が、異常とまで判断するほどではないため、異常ではないが異常である可能性があることを示す状態である。

その後、ステップ７４０で、異常スレッド情報３１０を参照し、異常スレッドＩＤ３１１が存在する場合、異常スレッドＩＤ３１１と異常検出時刻３１２を、ユーザーＩＦ６０を介して通知する。通知処理は、異常スレッド情報３１０に存在する全てのスレッドに対して行う。なお、異常スレッドの発生を通知する警報の出力は、新たに異常スレッド情報３１０に書き込まれた異常スレッドＩＤ３１１と異常検出時刻３１２について行うようにしても良い。

図９に示される前記処理は、プロセス監視設定情報２００に存在するプロセス１２０の全てについて順次実施する。

スレッド１３０がフック対象関数を呼び出すと、関数フック部８１０が生存報告処理８６０を行う。そのため、フック対象関数を決定する必要がある。監視設定プログラム１８０がこの処理を行う。監視設定プログラム１８０の構成と、関数フック処理を行う関数フック部の構成を図１０に示す。

図１０は、関数フック処理の一例を示すブロック図である。フックの対象となる関数は、任意のものを使用できるが、図１０では例として、ＯＳ８０が有するＣ言語の標準ライブラリ８００に含まれる関数を用いる例を示す。

関数フック処理を行う関数フック部８１０は、フック対象関数群８１１と、呼出統計記録処理８１３と、生存報告処理８６０から構成される。

フック対象関数群８１１は、フック対象関数８１２の集合である。呼出統計記録処理８１３は、スレッド１３０が呼び出したフック対象関数８１２の呼出情報を、関数フック部８１０が関数呼出統計情報１７０に記録する。

例として、スレッド１３０がＣ言語の標準ライブラリ８００のライブラリ関数ｅｐｏｌｌ＿ｗａｉｔを呼び出した際、関数フック部８１０がこの関数をフックし、呼出統計記録処理８１３と、生存報告処理８６０を実行する。その後、スレッド１３０は、Ｃ言語の標準ライブラリ８００に存在するｅｐｏｌｌ＿ｗａｉｔを呼び出し、本来の処理を実行する。

例として、スレッド１３０がＣ言語の標準ライブラリのライブラリ関数ｐｒｉｎｔｆを呼び出した場合、この関数は、フック対象関数群８１１に存在しないため、Ｃ言語の標準ライブラリ８００に存在するｐｒｉｎｔｆが直ぐに実行される。

フックを行う具体的な方法の一つとして、Ｌｉｎｕｘ（登録商標）のローダの機能であるＬＤ＿ＰＲＥＬＯＡＤ環境変数オプションを利用する方法が知られている。

監視設定プログラム１８０は、フック対象関数群８１１と、監視スレッド１４０の監視周期４１０を決定する。監視設定プログラム１８０は、監視設定値計算部８２０と、監視設定部８２１と、監視制御パラメタ８３０から構成される。

監視設定値計算部８２０は、監視制御パラメタ８３０と、関数呼出統計情報１７０を基に、フック対象関数群８１１と、監視スレッド１４０の監視周期４１０を決定し、監視設定部８２１に通知する。

監視設定部８２１は、監視設定値計算部８２０で決定された、フック対象関数群８１１と、監視スレッド１４０の監視周期４１０を設定する。

フック対象関数群８１１で新たに含まれるフック対象関数８１２や、フック対象関数群８１１から新たに外されたフック対象関数８１２の設定方法の一つとして、ＥＬＦフォーマットの．ＧＯＴセクションに存在する関数のアドレスが記載された箇所を書き直す方法が知られている。

監視制御パラメタ８３０は、目標呼出確率８３１と、目標監視周期８３２と、監視周期上限８３３と、計測時間上限８３４から構成される。

目標呼出確率８３１とは、スレッド１３０が、目標監視周期８３２内に、少なくとも一回は、フック対象関数群８１１に含まれる任意のフック対象関数８１２を呼び出す確率の目標値を示す。監視設定値計算部８２０は、この目標呼出確率８３１を達成できるように、フック対象関数群８１１と監視周期４１０を決定する。

監視周期上限８３３とは、監視設定値計算部８２０が決定する監視周期４１０の上限を示す。監視設定値計算部８２０の計算により算出された監視周期４１０が、監視周期上限８３３を超えていた場合、計算機システム１０の使用者に、ユーザーＩＦ６０を介して警告する。

計測時間上限８３４とは、呼出統計記録処理８１３による、関数呼出統計情報１７０への関数呼出記録の計測期間を示す。計測期間がこの計測時間上限８３４を超えると、呼出統計記録処理８１３は関数呼出の記録を停止し、監視設定値計算部８２０がその時点の関数呼出統計情報１７０を基に、フック対象関数群８１１と監視周期４１０を決定するための計算を始める。

なお、監視設定部８２１は、プロセス１２０が起動した直後では、関数フック部８１０が関数呼出統計情報１７０に関数を書き込んでいないので、予め設定された１以上のフック対象関数８１２をフック対象関数群８１１に設定しておく。同様に、監視設定部８２１は、プロセス１２０が起動した直後では、関数フック部８１０が関数呼出統計情報１７０に関数を書き込んでいないので、予め設定された監視周期４１０を監視スレッド１４０に設定しておく。

図１１に、関数呼出統計情報１７０が保持する情報を示す。関数呼出統計情報１７０は、関数呼出統計テーブル９００と、計測経過時間９１０と、平均呼出率９２０と、呼出確率９３０と、呼出率偏差９４０から構成される。

関数呼出統計テーブル９００は、関数名９０１と、呼出回数９０２と、呼出率９０３から一つのエントリが構成される。

関数名９０１とは、フック対象関数８１２の候補になる任意の関数の名前を表わす。呼出回数９０２とは、スレッド１３０が関数名９０１で識別される関数を計測経過時間９１０内で呼び出した回数を表わす。

呼出率９０３とは、計測経過時間９１０の単位時間内に、スレッド１３０が関数名９０１で識別される関数を呼び出す平均回数を表わす。呼出率９０３は、呼出回数９０２を計測経過時間９１０で割ることで計算する。関数呼出統計テーブル９００には、フック対象関数８１２の候補になる関数全ての情報が記録される。

計測経過時間９１０とは、呼出統計記録処理８１３が開始されてから経過した時間を示す。時間単位は、１秒や１マイクロ秒など任意の時間単位を取ることが出来る。

平均呼出率９２０とは、スレッド１３０が、単位時間内に、関数呼出統計テーブル９００にある、フック対象関数８１２の候補になる任意の関数を呼び出す平均回数を示す。平均呼出率９２０は、関数呼出統計テーブル９００内の、呼出率９０３の総和として計算される。

呼出確率９３０とは、スレッド１３０が、監視周期４１０内に、フック対象関数群８１１に含まれる任意のフック対象関数８１２を少なくとも一回は呼び出す確率を表わす。呼出確率９３０は、監視設定値計算部８２０による処理が実行される度に計算される。監視設定値計算部８２０による処理は、所定の周期で実行してもよいし、計算機システム１０の使用者が明示的に実行してもよいし、計算機システム１０の特定のイベントが発生した際に自動的に実行されてもよい。

呼出率偏差９４０とは、呼出確率９３０の標本標準偏差を表わす。呼出率偏差９４０は、監視設定値計算部８２０の処理により、呼出確率９３０を計算する際に逐次計算される。

図１２は、従来例を示し、関数フックを利用した死活監視方法において、誤検出の発生を示す説明図である。

関数フックを利用したスレッド１３０の死活監視を行う従来例では、図１２に示されるように、監視周期４１０（図中監視周期３）内で、スレッド１３０が、フック対象関数群８１１に含まれる任意のフック対象関数８１２を一度も呼び出すことがない場合に、監視スレッド１４０が前記スレッド１３０を異常と誤判定するという問題があった。

例として、関数呼出統計テーブル９００にある、フック対象関数８１２の候補になる関数を、関数１、関数２、関数３、関数４とする。スレッド１３０は、これらの関数を呼び出すたびに、関数フック部８１０の生存報告処理８６０を行う。スレッド１３０は、少なくとも一回は監視周期４１０の間に生存報告処理８６０を行えば、監視スレッド１４０は前記スレッドを異常と誤判断することはない。

しかしながら、スレッド１３０が実行する処理を記述したコード（プログラム）に前記フック対象関数８１２が含まれているか否かが不明であり、フック対象関数８１２が含まれていたとしても、スレッド１３０の処理の実行は、計算機システム１０の稼働状態に依存するため、スレッド１３０がいつこれらフック対象関数８１２を呼び出すかが不定である。従って、監視周期４１０の間に一回もフック対象関数８１２を呼び出すことがなく、監視スレッド１４０が誤ってスレッド１３０を異常であると判断してしまう。

図１３は、従来例を示し、関数フックを利用した死活監視方法において、生存報告の多重実行を示す説明図である。

また、図１３に示されるように、監視周期４１０内に、スレッド１３０が、フック対象関数群８１１に含まれる任意のフック対象関数８１２を大量に呼び出す場合に、計算機システム１０のＣＰＵ２０のＣＰＵ時間を大量に消費するという問題があった。

前述のとおり、スレッド１３０がいつこれらフック対象関数８１２を呼び出すかが不定である。従って、監視周期４１０の間に何回もフック対象関数８１２を呼び出し、関数フック処理によるＣＰＵ２０のＣＰＵ使用時間を大量に消費してしまう。

これは、関数フック部８１０に含まれる呼出統計記録処理８１３の実行と、生存報告処理８６０に加え、フック対象関数８１２を呼び出した際の関数呼び出し処理が一回分増えるためである。また、ＣＰＵ使用時間の増加は、計算機システム１０のＣＰＵ２０のＣＰＵ使用率が１００％に近い場合に、計算機システム１０のサービスを提供する処理を行うスレッド１３０のＣＰＵ２０の単位時間におけるＣＰＵ使用時間が短くなるため、計算機システム１０の提供するサービスの性能劣化を招く恐れがある。計算機システム１０のＣＰＵ２０のＣＰＵ使用率が低い場合には、前記のＣＰＵ使用時間の短縮は発生しないものの、前記の関数フック部８１０の処理を行う時間がかかるため、スレッド１３０が行う処理が遅延する。そのため、計算機システム１０の処理の応答時間が遅れる。

監視設定値計算部８２０は、前記のような問題が生じないように、フック対象関数群８１１と監視周期４１０を決定する。これを図１４に示す。

図１４は、関数フック対象集合の決定方法を示す説明図である。スレッド１３０は、これらの関数３、４を呼び出すたびに、関数フック部８１０の生存報告処理８６０を行う。スレッド１３０は、少なくとも一回は監視周期４１０の間に生存報告処理８６０を行えば、監視スレッド１４０は前記スレッド１３０を異常と誤判断することはない。従って、監視周期４１０の間に少なくとも一回は生存報告処理８６０を行い、かつ生存報告処理８６０の回数が少なくなるような関数を、フック対象関数８１２に決定するのが好ましい。

然しながら、前述の通りスレッド１３０がフック対象関数８１２の呼出は不定であり、確実に前記の条件を満たすことはできない。そこで、関数呼出統計情報１７０を基に、高い確率で前記の条件を満たすフック対象関数８１２を決定する。この確率は、監視制御パラメタ８３０の目標呼出確率８３１で与える。これを図１５で示す。

図１５は、関数フック対象集合を決定する基準とする呼出確率の確率密度の一例を示すグラフである。

関数呼出統計情報１７０の平均呼出率９２０から、スレッド１３０が、フック対象関数群８１１に含まれる任意のフック対象関数８１２を呼び出した後、次に任意のフック対象関数８１２を呼び出すまでの時間間隔の確率密度関数を図１５のように算出する。この確率密度関数の０から監視周期４１０までの定積分は、監視周期４１０の間に、任意のフック対象関数８１２を呼び出す確率であり、これを呼出確率９３０とする。

この呼出確率９３０が目標呼出確率８３１を上回れば、計算機システム１０の使用者が指定した目標呼出確率８３１で、監視周期４１０内に、スレッド１３０がフック対象関数群８１１に含まれるフック対象関数８１２を呼び出すことで、生存報告処理８６０を呼び出すように、計算機システム１０の死活監視機能の設定を行うことができる。

前記の通り、平均呼出率９２０、は関数名９０１で識別される関数の呼出率９０３の和で算出される。監視設定値計算部８２０は、この呼出確率９３０が目標呼出確率８３１を上回るような平均呼出率９２０を逆に算出し、その平均呼出率９２０を達成するように関数名９０１で識別される関数をフック対象関数８２０として、フック対象関数群８１１に含めることで、フック対象関数群８１１を決定する。

監視設定プログラム１８０がフック対象関数群８１１を決定する際、監視周期４１０が監視周期上限８３３を上回る場合、計算機システム１０のユーザーＩＦ６０を介して使用者に警告する。この警告は、監視周期４１０が長くなりすぎると、監視スレッド１４０が、スレッド１３０の異常を検出する時間が遅れ、計算機システム１０の異常時の処理が迅速に行えなくなるのを避けるために出力される。

関数呼出統計情報１７０は、計算機システム１０の稼働状態を基に構築してもよいし、計算機システム１０を稼働する前に、予め所定の値をプリセットしても良いものとする。

死活監視のパラメタとして設定される、目標呼出確率８３１と、目標監視周期８３２と、監視周期上限８３３から、フック対象関数群８１１と、監視周期４１０を決定する処理を図１６に示す。

図１６は、関数フック対象集合と監視周期を決定する処理の一例を示すフローチャートである。

ステップ１００１において、監視設定値計算部８２０は、計測経過時間９１０が計測時間上限８３４を上回っているか否かを判定する。計測経過時間９１０が計測時間上限８３４を上回っていない場合は、関数呼出統計情報１７０に十分な関数呼出情報が蓄積されていないとみなし、一定の時間をおいて（１０３１）再度ステップ１００１を実行する。計測経過時間９１０が計測時間上限８３４を上回っていた場合は、関数呼出統計情報１７０に十分な関数呼出情報が蓄積されているとみなし、フック対象関数群８１１と監視周期４１０の計算処理に進む。

その後、ステップ１００２において、監視設定値計算部８２０は、関数呼出統計テーブル９００に含まれる、関数名９０１で識別される関数の、呼出率９０３を全て下記の（１）式により計算する。

上記（１）式のｆは、関数名９０１で識別される関数であり、Ｔｃは計測経過時間９１０であり、Ｃ（ｆ）は関数ｆの呼出回数９０２であり、λ（ｆ）は関数ｆの呼出率９０３である。

その後、ステップ１００３において、監視設定値計算部８２０は、呼出率９０３の大きい順に、関数名９０１で識別される関数のエントリを並び替える。これにより、スレッド１３０が呼び出した回数が多い順に、関数名９０１で識別される関数のエントリが並ぶ。

その後、ステップ１００４において、監視設定値計算部８２０は、呼出確率９３０を０に設定し、呼出確率９３０を初期化する。

その後、ステップ１００５において、監視設定値計算部８２０は、関数呼出統計テーブル９００から、関数名９０１で識別される関数ｆを選択する。これは、スレッド１３０が呼び出した回数が多い関数ｆを順に選択することを意味する。

その後、ステップ１００６において、監視設定値計算部８２０は、関数ｆが選択できたか否かを判定する。関数ｆを選択できた場合、ステップ１０１０において、関数ｆをフック対象関数８１２としてフック対象関数群８１１に追加する。これは、スレッド１３０が呼び出した回数が多い順に、関数ｆをフック対象関数群８１１に追加していくことを意味する。

その後、ステップ１０１１において、関数ｆ平均呼出率９２０を次の（２）式により計算して、更新する。

上記（２）式のλは、平均呼出率９２０である。これは、スレッド１３０が、単位時間内に、これまでフック対象関数群８１１に追加された任意のフック対象関数８１２を呼び出す平均回数を意味する。

その後、ステップ１０１２において、監視設定値計算部８２０は、呼出確率９３０を次の（３）式により計算して、更新する。

上記（３）式のＴは目標監視周期８３２であり、ｐは呼出確率９３０である。これは、スレッド１３０が、目標監視周期８３２内に、これまでフック対象関数群８１１に追加された任意のフック対象関数８１２を呼び出す確率を意味する。

その後、ステップ１０１３において、監視設定値計算部８２０は、呼出確率９３０（ｐ）が、目標呼出確率８３１を上回るか否かを判定する。呼出確率９３０（ｐ）が、目標呼出確率８３１を上回っている場合、それまでにフック対象関数群８１１に追加されたフック対象関数８１２の集合をフック対象関数群８１１と決定し、目標監視周期８３２を監視周期４１０と決定する。

これは、スレッド１３０が、それまでにフック対象関数群８１１に追加された任意のフック対象関数８１２を呼び出し、目標監視周期８３２内に生存報告処理８６０を行う確率である呼出確率９３０が、目標呼出確率８３１を上回ることを意味する。

ステップ１０１３において、監視設定値計算部８２０は、呼出確率９３０が、目標呼出確率８３１以下である場合、ステップ１００５に戻り、フック対象関数群８１１へのフック対象関数８１２の追加を継続して行う。

ステップ１００６において、関数ｆが選択できなかった場合、フック対象関数群８１１に追加する関数が残っておらず、ステップ１０１０以下の、フック対象関数群８１１への関数の追加が行えない。

その後、ステップ１０２０において、監視設定値計算部８２０は、呼出確率９３０が目標呼出確率８３１を下回っているか否かを判定する。呼出確率９３０が目標呼出確率８３１を下回っていた場合、関数呼出統計テーブル９００にある関数の全てをフック対象関数８１２としてフック対象関数群８１１に追加しても、目標監視周期８３２内に、フック対象関数群８１１に含まれる任意のフック対象関数８１２を呼び出す確率である呼出確率９３０が、目標呼出確率８３１に届かない。

そのため、監視周期４１０を次の（４）式により計算し、決定することで、呼出確率９３０が目標呼出確率８３１を上回るようにする。

上記（４）式のＴは監視周期４１０である。これは、目標監視周期８３２内にスレッド１３０がフック対象関数群８１１に含まれる任意のフック対象関数８１２を呼び出す可能性が低いため、監視周期４１０の方を伸ばすことで、前記の可能性を高めることを意味する。

その後、ステップ１０２２において、監視設定値計算部８２０は、（４）式で計算した監視周期４１０が、監視周期上限８３３を上回っているか否かを判定する。監視周期４１０が、監視周期上限８３３を上回っていた場合は、ユーザーＩＦ６０を介して、計算機システム１０の使用者に警告を出力する。これは、（４）式で計算された監視周期４１０が長くなりすぎ、監視スレッド１４０でスレッド１３０の異常を検出するのが遅れ、計算機システム１０の使用者がスレッド１３０の異常を検知して適切な処理を施すまでに時間がかかりすぎることになるため、その旨を使用者に知らせるためである。

前述の処理により、監視設定値計算部８２０が、フック対象関数群８１１と監視周期４１０が決定した後、監視設定部８２１がフック対象関数群８１１と監視周期４１０を設定する。

監視周期４１０の設定の具体例として、監視スレッド１４０が監視周期４１０の値を設定するインタフェース関数を用意し、監視設定部８２１がこの関数を呼び出す方法がある。

フック対象関数群８１１の設定の具体例として、フック対象関数群８１１に新たに追加されるフック対象関数８１２の設定を行う場合、監視スレッド１４０とスレッド１３０が属するプロセス１２０のＥＬＦフォーマットの．ＧＯＴセクションにある、関数呼出統計テーブル９００内の関数名９０１で識別される関数のエントリのアドレスを、ＯＳ８０の標準ライブラリ８００内にある前記関数のアドレスから、フック対象関数群８１１のフック対象関数８１２のアドレスに書き換える方法がある。

フック対象関数群８１１の設定の具体例として、フック対象関数群８１１からフック対象関数８１２を外す設定を行う場合、監視スレッド１４０とスレッド１３０が属するプロセス１２０のＥＬＦフォーマットの．ＧＯＴセクションにある、関数呼出統計テーブル９００内の関数名９０１で識別される関数のエントリのアドレスを、フック対象関数群８１１のフック対象関数８１２のアドレスから、標準ライブラリ８００内にある前記関数のアドレスに書き換える方法がある。

上記第一の実施例によれば、実行するプロセス１２０のソースコードの変更や、ＯＳ８０のカーネルの変更の必要がないために、ソースコードの入手ができないプログラムに対してもスレッド１３０単位の死活監視を実現可能である。関数フックによるプロセス１２０とスレッド１３０の死活監視において、計算機システム１０の使用者が設定することができる関数の目標呼出確率８３１で、監視スレッド１４０が、スレッド１３０の異常状態を正しく検知できる。

また、スレッド１３０が生存報告処理８６０を行うのに使用するフック対象関数群８１１と、監視スレッド１４０の監視周期４１０を、監視設定プログラム１８０の監視設定値計算部８２０が自動的に決定し、監視設定部８１２が自動的に設定するため、計算機システム１０の使用者が、計算機システム１０の稼働後、死活監視の設定を一切行う必要がない。

第二の実施例では、第一の実施例の構成に加えて、計算機システム１０の稼働状態の変化等により、スレッド１３０による関数の呼出パターンが変化した場合にこの変化を自動的に検知し、再度、フック対象関数群８１１と監視周期４１０を計算し直して、設定を変更するものである。これにより、第二の実施例では、計算機システム１０の稼働状態の如何に関わらず、常に目標呼出確率８３１で、監視スレッド１４０が、スレッド１３０の異常状態を正しく検知できるのである。

図１７に、スレッド１３０がフック対象関数群８１１に含まれる任意のフック対象関数８１２の呼出パターンが変化した場合に、この変化を検知する監視設定プログラム１８０を示す。図１７は、関数フック処理のソフトウェア構成の一例を示すブロック図である。

監視設定プログラム１８０は、スレッド１３０によるフック対象関数群８１１に含まれるフック対象関数８１２の呼出パターンが変化した場合に、この変化を自動的に検知して、フック対象関数群８１１を更新する。監視設定プログラム１８０は、監視設定値計算部８２０と、監視設定部８２１と、関数呼出変化検知部８２２と、監視制御パラメタ８３０と、変化検知パラメタ８４０と、変化検知情報８５０から構成される。

この第二実施例の構成は、前記第一の実施例の図１０に示した監視設定プログラム１８０に、関数呼出変化検知部８２２と、変化検知パラメタ８４０と、変化検知情報８５０を加えたものであり、その他の構成は前記第一実施例と同様である。

関数呼出変化検知部８２２は、変化検知パラメタ８４０と、変化検知情報８５０を基に、スレッド１３０によるフック対象関数８１２の呼出パターンの変化を検知する。

関数呼出変化検知部８２２は、前記呼出パターンの変化をスレッド１３０によるフック対象関数８１２の呼出頻度と、前記呼出頻度の時間変動を示す呼出頻度の標準偏差を基に、検知する。

変化検知パラメタ８４０は、検知閾値８４１と、検知周期８４２と、保護回数８４３から構成される。

検知閾値８４１とは、スレッド１３０によるフック対象関数８１２の呼出頻度の変化を判定する値域である予測範囲を計算する際に用いる値を示す。検知周期８４２とは、スレッド１３０によるフック対象関数８１２の呼出の変化を検知する処理を行う周期を示す。保護回数８４３とは、スレッド１３０によるフック対象関数８１２の呼出頻度の変化の判定に用いる値を示す。

変化検知情報８５０は、呼出率予測値８５１と、呼出率偏差値８５２と、連続疑診回数８５３から構成される。

呼出率予測値８５１とは、スレッド１３０によるフック対象関数８１２の呼出頻度の予測値を示す。呼出率偏差値８５２とは、スレッド１３０によるフック対象関数８１２の呼出頻度の標準偏差を示す。連続疑診回数８５３とは、スレッド１３０によるフック対象関数８１２の呼出頻度が、前記予測範囲を連続して逸脱した回数を示す。

関数呼出変化検知部８２２は、所定の周期で、スレッド１３０によるフック対象関数８１２の呼出頻度の予測値である呼出率予測値８５１と、呼出率予測値８５１の変動を表わす呼出率偏差値８５２と、検知周期８４２から、前記呼出頻度の予測範囲を計算し、平均呼出率９２０が予測範囲内であれば、スレッド１３０によるフック対象関数８１２の呼出パターンに変化がないと判定する。一方、関数呼出変化検知部８２２は、平均呼出率９２０が予測範囲外であれば、スレッド１３０によるフック対象関数８１２の呼出パターンに変化した疑いがあることを示す変化疑診と判定する。

そして、関数呼出変化検知部８２２は、変化疑診が連続して判定された回数が保護回数８４３を超えた場合、スレッド１３０によるフック対象関数８１２の呼出パターンが変化したと判定する。変化疑診の判定が連続して保護回数８４３を超えるまで、呼出パターンが変化したことを保留することで、関数呼出変化検知部８２２は、呼出パターンの変化が頻繁に判定されるのを防止できる。

スレッド１３０によるフック対象関数８１２の呼出頻度が増加した場合、図１３で示したように、スレッド１３０が監視周期４１０内にフック対象関数８１２の呼出を大量に行うことで、生存報告処理８６０等が頻発してＣＰＵ２０のＣＰＵ使用時間を増大させ、計算機システム１０の性能劣化を招く恐れがある。

図１８は、関数呼出変化検知部８２２が、スレッド１３０によるフック対象関数８１２の呼出頻度が増加した状態を検知する場合の説明図である。なお、図１８における保護回数８４３は“２”とする。

関数呼出変化検知部８２２は、図中時刻ｔ１〜ｔ５で平均呼出率９２０（λ（ｔ））の予測分布を更新する。平均呼出率９２０が、前述の予測範囲内であれば、前述のスレッド１３０によるフック対象関数８１２の呼出パターンは変化していないと判定する（時刻ｔ１、ｔ２）。その後、平均呼出率９２０と呼出率偏差９４０から、スレッド１３０によるフック対象関数８１２の呼出頻度の予測値である呼出率予測値８５１と、予測値の変動を表わす呼出率偏差値８５２を計算し、予測分布の平均と偏差を更新する。

平均呼出率９２０が、前述の予測範囲を上回った場合は、関数呼出変化検知部８２２は変化疑診と判定する（時刻ｔ３、ｔ４）。変化疑診の判定が保護回数８４３の値である“２”を超え、３回になった場合、関数呼出変化検知部８２２はスレッド１３０によるフック対象関数８１２の呼出頻度が上昇し、呼出パターンが変化したと判定する（時刻ｔ５）。

図１９は、関数呼出変化検知部８２２が、スレッド１３０によるフック対象関数８１２の呼出頻度が減少した状態を検知する場合の説明図である。なお、図１９における保護回数８４３は“２”とする。

関数呼出変化検知部８２２は、上記図１８と同様に、図中時刻ｔ１〜ｔ５で平均呼出率９２０の予測分布を更新する。平均呼出率９２０が、前述の予測範囲内ならば、図１８と同様に、前述のスレッド１３０によるフック対象関数８１２の呼出パターンは変化していないと判定する（時刻ｔ１、ｔ２）。その後、平均呼出率９２０と呼出率偏差９４０から、スレッド１３０によるフック対象関数８１２の呼出頻度の予測値である呼出率予測値８５１と、予測値の変動を表わす呼出率偏差値８５２を計算し、予測分布の平均と偏差を更新する。

平均呼出率９２０が、前述の予測範囲を下回った場合は、図１８と同様に、関数呼出変化検知部８２２は変化疑診と判定する（時刻ｔ３、ｔ４）。変化疑診の判定が保護回数８４３の値である２を超え、３回になった場合、関数呼出変化検知部８２２はスレッド１３０によるフック対象関数８１２の呼出頻度が減少し、呼出パターンが変化したと判定する（時刻ｔ５）。

上記図１８のように平均呼出率９２０が増大する場合や、上記図１９のように平均呼出率９２０が減少する場合では、スレッド１３０の関数の呼び出しパターンが変化しているため、関数呼出統計情報１７０を平均呼出率９２０の変化方向に応じたプリセット値に切り替えるようにしても良い。図１８のように平均呼出率９２０が増大する場合では、監視設定部８２１は、この増大に応じた値の関数呼出統計情報１７０に切り替える。また、図１９のように平均呼出率９２０が減少する場合では、監視設定部８２１は、この減少に応じた値の関数呼出統計情報１７０に切り替える。

図２０は、スレッド１３０によるフック対象関数８１２の呼出頻度が短時間に増減を繰り返し振動する場合に、関数呼出変化検知部８２２が、その都度変化の検出を行わず、フック対象関数群８１１と監視周期４１０の無用な再計算を防ぐ場合の説明図である。なお、図２０における保護回数８４３は２とする。

関数呼出変化検知部８２２は、上記図１８と同様に、図中時刻ｔ１〜ｔ５で平均呼出率９２０の予測分布を更新する。平均呼出率９２０が、前述の予測範囲内あれば、図１９と同様に、前述のスレッド１３０によるフック対象関数８１２の呼出パターンは変化していないと判定する（時刻ｔ１）。その後、平均呼出率９２０と呼出率偏差９４０から、スレッド１３０によるフック対象関数８１２の呼出頻度の予測値である呼出率予測値８５１と、予測値の変動を表わす呼出率偏差値８５２を計算し、予測分布の平均と偏差を更新する。

平均呼出率９２０が、前述の予測範囲を下回った場合は、図１９と同様に、関数呼出変化検知部８２２は変化疑診と判定し、連続疑診回数８５３に１を加算する（時刻ｔ２）。その後、平均呼出率９２０が前述の予測範囲内に戻った場合、前述の変化疑診判定を取り消し、連続疑診回数８５３を０に戻す（時刻ｔ３）。その後、平均呼出率９２０が、前述の予測範囲を上回った場合は、図１８と同様に、関数呼出変化検知部８２２は変化疑診と判定し、連続疑診回数８５３に１を加算する（時刻ｔ４）。その後、平均呼出率９２０が前述の予測範囲内に戻った場合、前述の変化疑診判定を取り消し、連続疑診回数８５３を０に戻す（時刻ｔ５）。

このように、関数呼出変化検知部８２２は、保護回数８４３の値を超えて、連続して変化疑診判定が行われない限り、スレッド１３０によるフック対象関数８１２の呼出頻度が変化したとは判定しないため、フック対象関数群８１１と監視周期４１０が監視設定値計算部８２０による再計算が頻繁に行われ、生存報告処理８６０等が頻発してＣＰＵ２０のＣＰＵ使用時間を大量に消費することを防ぐことができる。換言すれば、監視設定プログラム１８０は、フック対象関数８１２の関数の呼び出しパターンの変化が振動した場合には、フック対象関数８１２及び監視周期４１０の再計算を禁止して、計算機システム１０のリソースを無駄に消費するのを防止する。

関数呼出変化検知部８２２が、スレッド１３０によるフック対象関数８１２の呼出頻度の変化を検出する処理を図２１に示す。図２１は、関数呼出変化検知部８２２で行われる処理の一例を示すフローチャートである。

ステップ１１０１において、関数呼出変化検知部８２２は、平均呼出率９２０の予測分布が構築済みであるか否かを判定する。前記の予測分布とは、平均が呼出率予測値８５１であり、標準偏差が呼出率偏差値８５２である正規分布である。したがって、予測分布は、呼出率予測値８５１と呼出率偏差値８５２が計算済みであれば、構築済みであると云える。予測分布が構築されていない、すなわち呼出率予測値８５１と呼出率偏差値８５２が計算されていない場合、ステップ１１０２において、関数呼出変化検知部８２２は、平均呼出率９２０を呼出率予測値８５１に代入し、呼出率偏差値８５２に呼出率偏差９４０を代入することで、予測分布を構築する。予測分布は次の（５）式で表される。

上記（５）式で、Ｘは予測分布に従う確率変数であり、λ（０）は平均呼出率９２０であり、σは呼出率偏差９４０である。

ステップ１１０３において、平均呼出率９２０が、前述の予測分布から計算される予測範囲内であるか否かを判定する。前記の予測範囲は、次の（６）式で計算される範囲である。

上記（６）式で、ｎは関数呼出変化検知部８２２が実施した、スレッド１３０によるフック対象関数８１２の呼出頻度の変化の検出処理の回数である。また、μ（ｎ）は呼出率予測値８５１であり、τ（ｎ）は呼出率偏差値８５２であり、δは検知閾値８４１である。すなわち、前記の予測範囲は、呼出率偏差値８５２を中心とした検知閾値８４１×呼出率偏差値８５２の範囲である。

例として、検知閾値８４１が“１”であると、予測分布は正規分布であるため、平均呼出率９２０が前記の予測範囲に入る確率は、約６８％であり、検知閾値８４１が“２”であると、前記の確率は約９５％になる。

ステップ１１０３において、平均呼出率９２０（λ）が、前述の予測分布から計算される予測範囲内を判定し、予測範囲内である場合、関数呼出変化検知部８２２は、以後のステップ１１１０、ステップ１１１１、ステップ１１１２において、平均呼出率９２０の予測分布を更新する。予測分布の更新は、既存の予測分布に対し、平均呼出率９２０の最新の値の情報を、ベイズ更新により反映させ、将来の平均呼出率９２０を予測する。なお、ベイズ更新とは、“ベイズ統計入門”（繁枡算男著、東京大学出版会、1985年4月発行）等に開示される周知の統計手法である。

予測分布の更新処理として、ステップ１１１０において、関数呼出変化検知部８２２は、連続疑診回数８５３を０に戻し、ステップ１１１１において、呼出率予測値１２５１を、次の（７）式により更新する。

そして、ステップ１１１２において、関数呼出変化検知部８２２は、呼出率偏差値１２５２を次の（８）式により更新する。

上記ステップ１１０３において、関数呼出変化検知部８２２は、平均呼出率９２０が、前述の予測分布から計算される予測範囲内を判定し、予測範囲を外れた場合、変化疑診と判定し、ステップ１１２０にて連続疑診回数８５３に“１”を加算する。

ステップ１１２１において、関数呼出変化検知部８２２は、連続疑診回数８５３が、保護回数８４３を超過しているか否かを判定する。連続疑診回数８５３が保護回数８４３を超過している場合、関数呼出変化検知部８２２は、スレッド１３０によるフック対象関数８１２の呼出頻度が変化したと判定し、フック対象関数群８１１が最早有効に機能しなくなったと判定する。

ステップ１１２２にて、関数呼出変化検知部８２２は、フック対象関数群８１１を含む関数呼出統計情報１７０を全て初期状態に戻し、ステップ１３０が呼び出す関数の統計情報を取得し直す。その後、ステップ１１２３で、呼出率予測値１２５１と呼出率偏差値１２５２を初期状態に戻し、これまで使用していた予測分布を破棄する。

第二の実施例によれば、計算機システム１０の稼働状態に変化により、スレッド１３０がフック対象関数群８１１に含まれる任意のフック対象関数８１２の呼出パターンが変化した場合に、関数呼出変化検知部８２２がこの変化を検知する。そして、監視設定プログラム１８０では、再度フック対象関数群８１１と監視周期４１０を計算し設定し直すことで、計算機システム１０の稼働状態の如何に関わらず、常に目標呼出確率８３１で、監視スレッド１４０が、スレッド１３０の異常状態を正しく検知できる。

また、スレッド１３０がフック対象関数群８１１に含まれるフック対象関数８１２の呼出パターンの変化を、関数呼出変化検知部８２２が自動的に検出するため、計算機システム１０の使用者または管理者が、計算機システム１０の稼働後に、死活監視の設定を一切行う必要がない。これにより、死活監視のメインテナンスを不要にして、死活監視の運用に関するコストを低減できる。

なお、上記では関数フック部８１０が書き込んだ関数呼出統計情報１７０を監視設定プログラム１８０が利用する例を示したが、過去に生成した関数呼出統計情報１７０を監視設定プログラム１８０で利用するようにしても良い。この場合、アプリケーションやＯＳに応じて生成しておいた関数呼出統計情報１７０を選択して利用するようにしても良い。

また、各プロセスやデータ（情報）はメモリ３０に保持される例を示したが、メモリ３０またはストレージ４０の双方に保持されていても良い。この場合、メモリ３０とストレージ４０を併せて記憶部として、記憶部に各プロセスやデータ（情報）を保持するようにしても良い。

なお、本発明において説明した計算機等の構成、処理部及び処理手段等は、それらの一部又は全部を、専用のハードウェアによって実現してもよい。

また、本実施例で例示した種々のソフトウェアは、電磁的、電子的及び光学式等の種々の記録媒体（例えば、非一時的な記憶媒体）に格納可能であり、インターネット等の通信網を通じて、コンピュータにダウンロード可能である。

また、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明をわかりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。

１０ 計算機システム
２０ ＣＰＵ
３０ メモリ
１００ 監視プロセス
１２０ プロセス
１３０ スレッド
１４０ 監視スレッド
１５０ プロセス・スレッド監視情報
１６０ スレッド監視情報
１７０ 関数呼出統計情報
１８０ 監視設定プログラム
８００ 標準ライブラリ
８１０ 関数フック部
８２０ 監視設定値計算部
８２１ 監視設定部
８２２ 関数呼出変化検知部

Claims (10)

1. １以上のプロセスと、前記プロセスを構成する１以上のスレッドを実行する計算機システムであって、
   前記計算機システムは、
   前記プロセス、スレッド及びライブラリを保持する記憶部と、
   前記プロセス及びスレッドを実行する１以上のプロセッサと、を備え、
   前記ライブラリは、
   前記スレッドが呼び出す関数を有し、
   前記プロセスは、
   第１のプロセスと、前記第１のプロセスを監視する監視プロセスと、前記第１のプロセスの監視条件を設定する監視設定部と、を含み、
   前記第１のプロセスは、
   前記第１のプロセスの処理を実行する１以上の第１のスレッドと、
   前記第１のスレッドを監視する監視スレッドと、
   前記第１のスレッドが前記ライブラリから所定の関数を呼び出すと、当該関数をフックして所定の処理を実行する関数フック部と、を含み、
   前記監視設定部は、
   前記関数フック部に、前記第１のスレッドが前記ライブラリから呼び出す関数の内、前記フックする対象の関数をフック対象関数として設定し、
   前記関数フック部は、
   前記第１のスレッドが、前記ライブラリから前記フック対象関数を呼び出したときには、前記記憶部に保持されて前記第１のスレッドが正常であることを示す第１の生存情報を更新し、
   前記監視スレッドは、
   第１の監視周期となるたびに、前記記憶部に保持されて前記第１のプロセスが正常であることを示す第２の生存情報を更新し、
   前記第１の監視周期となるたびに、前記記憶部から前記第１の生存情報を読み込んで、前記第１の生存情報が更新されたか否かを判定し、前記第１の生存情報が更新されていない場合には、前記第１のスレッドに異常が発生したことを示す異常スレッド情報を前記記憶部に書き込み、
   前記監視プロセスは、
   第２の監視周期となるたびに、前記記憶部から前記第２の生存情報を読み込んで、前記第２の生存情報が更新されたか否かを判定し、前記第２の生存情報が更新されていない場合には、前記第１のプロセスに異常が発生したことを判定し、
   前記第２の監視周期となるたびに、前記記憶部から異常スレッド情報を読み込んで、異常スレッド情報の有無を判定し、異常スレッド情報が存在する場合には、前記第１のスレッドに異常が発生した情報を出力することを特徴とする計算機システム。
2. 請求項１に記載の計算機システムであって、
   前記関数フック部は、
   前記第１のスレッドが前記ライブラリから呼び出した関数を、前記記憶部に保持された関数呼出統計情報に蓄積し、
   前記監視設定部は、
   前記第１の監視周期内に、前記第１のスレッドがフック対象関数を呼び出す呼出確率の目標値である目標呼出確率と、前記第１の監視周期の上限である監視周期上限とを前記記憶部に保持し、
   前記関数呼出統計情報に蓄積された関数のうち、前記第１の監視周期内に前記第１のスレッドが、前記フック対象関数の関数を呼び出す呼出確率が前記目標呼出確率以上となる条件を満たす関数を前記フック対象関数として設定し、前記監視周期上限以内で前記呼出確率が前記目標呼出確率以上となる第１の監視周期を設定することを特徴とする計算機システム。
3. 請求項２に記載の計算機システムであって、
   前記監視設定部は、
   前記フック対象関数の関数を呼び出す頻度である呼出率を検出し、前記呼出率を予測する予測分布を構築するための呼出率予測値と呼出率偏差値を算出し、前記呼出率予測値と前記呼出率偏差値とから、前記呼出率が取り得る予測範囲を算出し、前記フック対象関数に含まれる関数の呼び出しパターンの変化を検知したときには、前記フック対象関数と、前記第１の監視周期とを再計算することを特徴とする計算機システム。
4. 請求項３に記載の計算機システムであって、
   前記監視設定部は、
   前記フック対象関数に含まれる関数の呼び出しパターンの変化を検知したときには、前記パターンの変化方向に応じて、前記関数呼出統計情報をプリセット値に切り替えることを特徴とする計算機システム。
5. 請求項３に記載の計算機システムであって、
   前記監視設定部は、
   前記フック対象関数に含まれる関数の呼び出しパターンの変化が振動した場合には、前記フック対象関数及び前記第１の監視周期の再計算を禁止することを特徴とする計算機システム。
6. １以上のプロセッサと記憶部を備えた計算機で、１以上のプロセスと、前記プロセスを構成する１以上のスレッドを監視するプロセス及びスレッドの監視方法であって、
   前記記憶部は、
   前記プロセス、スレッド及びライブラリを保持し、
   前記プロセッサは、
   前記プロセス及びスレッドを実行し、
   前記ライブラリは、
   前記スレッドが呼び出す関数を有し、
   前記プロセスは、
   第１のプロセスと、前記第１のプロセスを監視する監視プロセスと、前記第１のプロセスの監視条件を設定する監視設定部と、を含み、
   前記第１のプロセスは、
   前記第１のプロセスの処理を実行する１以上の第１のスレッドと、
   前記第１のスレッドを監視する監視スレッドと、
   前記第１のスレッドが前記ライブラリから所定の関数を呼び出すと、当該関数をフックして所定の処理を実行する関数フック部と、を含み、
   前記方法は、
   前記監視設定部が、前記関数フック部に、前記第１のスレッドが前記ライブラリから呼び出す関数の内、前記フックする対象の関数をフック対象関数として設定する第１のステップと、
   前記関数フック部は、前記第１のスレッドが、前記ライブラリから前記フック対象関数を呼び出したときには、前記記憶部に保持されて前記第１のスレッドが正常であることを示す第１の生存情報を更新する第２のステップと、
   前記監視スレッドは、第１の監視周期となるたびに、前記記憶部に保持されて前記第１のプロセスが正常であることを示す第２の生存情報を更新する第３のステップと、
   前記監視スレッドは、前記第１の監視周期となるたびに、前記記憶部から前記第１の生存情報を読み込んで、前記第１の生存情報が更新されたか否かを判定し、前記第１の生存情報が更新されていない場合には、前記第１のスレッドに異常が発生したことを示す異常スレッド情報を前記記憶部に書き込む第４のステップと、
   前記監視プロセスは、第２の監視周期となるたびに、前記記憶部から前記第２の生存情報を読み込んで、前記第２の生存情報が更新されたか否かを判定し、前記第２の生存情報が更新されていない場合には、前記第１のプロセスに異常が発生したことを判定する第５のステップと、
   前記監視プロセスは、前記第２の監視周期となるたびに、前記記憶部から異常スレッド情報を読み込んで、異常スレッド情報の有無を判定し、異常スレッド情報が存在する場合には、前記第１のスレッドに異常が発生した情報を出力する第６のステップと、
   を含むことを特徴とするプロセス及びスレッドの監視方法。
7. 請求項６に記載のプロセス及びスレッドの監視方法であって、
   前記第１のステップは、
   前記関数フック部が、前記第１のスレッドが前記ライブラリから呼び出した関数を、前記記憶部に保持された関数呼出統計情報に蓄積するステップと、
   前記監視設定部が、前記第１の監視周期内に、前記第１のスレッドがフック対象関数を呼び出す呼出確率の目標値である目標呼出確率と、前記第１の監視周期の上限である監視周期上限とを前記記憶部に保持するステップと、
   前記監視設定部が、前記関数呼出統計情報に蓄積された関数のうち、前記第１の監視周期内に前記第１のスレッドが、前記フック対象関数の関数を呼び出す呼出確率が前記目標呼出確率以上となる条件を満たす関数を前記フック対象関数として設定し、前記監視周期上限以内で前記呼出確率が前記目標呼出確率以上となる第１の監視周期を設定するステップと、
   を含むことを特徴とするプロセス及びスレッドの監視方法。
8. 請求項７に記載のプロセス及びスレッドの監視方法であって、
   前記監視設定部は、前記フック対象関数の関数を呼び出す頻度である呼出率を検出し、前記呼出率を予測する予測分布を構築するための呼出率予測値と呼出率偏差値を算出し、前記呼出率予測値と前記呼出率偏差値とから、前記呼出率が取り得る予測範囲を算出し、前記フック対象関数に含まれる関数の呼び出しパターンの変化を検知したときには、前記フック対象関数と、前記第１の監視周期とを再計算することを特徴とするプロセス及びスレッドの監視方法。
9. 請求項８に記載のプロセス及びスレッドの監視方法であって、
   前記監視設定部は、前記フック対象関数に含まれる関数の呼び出しパターンの変化を検知したときには、前記パターンの変化方向に応じて、前記関数呼出統計情報をプリセット値に切り替えることを特徴とするプロセス及びスレッドの監視方法。
10. 請求項８に記載のプロセス及びスレッドの監視方法であって、
    前記監視設定部は、前記フック対象関数に含まれる関数の呼び出しパターンの変化が振動した場合には、前記フック対象関数及び前記第１の監視周期の再計算を禁止することを特徴とするプロセス及びスレッドの監視方法。

Images