(57)【要約】【課題】コンポーネントの効果的な障害解析と、システム全体の動作データ出力量の抑制を両立させる。【解決手段】コンポーネント１０２が動作中に出力する動作データ１０４は、動作データ記憶機能部１０７によってデータ列１０８に記憶される。このデータ列１０８から通信相手記憶機能部１０９によってコンポーネント１０２の通信相手たるコンポーネント１０３が抽出され、記憶される。システムの動作中に、データ列１０８と、コンポーネント特定機能部１０６によって特定されたコンポーネント１０２の出力する動作データ１０４が動作データ比較機能部１１０によって比較される。そして、比較結果に応じて、コンポーネント１０２に対しては出力レベル制御機能部１１１が、コンポーネント１０３に対しては関連コンポーネント出力レベル制御機能部１１２が、動作データの出力レベルを制御する。【選択図】図１
2010286889.tif 000002
【特許請求の範囲】
【請求項１】
複数のコンポーネント間の通信を制御する通信制御装置において、
監視対象となる特定コンポーネントにおける、実行時の動作データを記憶しておく動作データ記憶手段と、
前記動作データ記憶手段に記憶されたデータ列から、前記特定コンポーネントの通信相手のコンポーネントを特定する通信相手特定手段と、
前記動作データ記憶手段に記憶された所定動作状態におけるデータ列と、前記特定コンポーネントが実行時に出力するデータとを比較する比較手段と、
前記比較手段による比較結果に応じて、前記特定コンポーネントと前記通信相手特定手段によって特定された通信相手のコンポーネントとに対して、動作データ出力の詳細レベルを制御する出力レベル制御手段と、
を備えることを特徴とする通信制御装置。
【請求項２】
システムのソフトウェア異常発生時に異常の発生したコンポーネントを前記特定コンポーネントとして特定するコンポーネント特定手段を有し、
前記動作データ記憶手段は、異常発生時の近傍の、異常発生コンポーネントにおける動作データを記憶し、
前記出力レベル制御手段は、前記比較手段によって異常発生時と現在実行中の出力が類似していると判定された場合には、異常発生コンポーネントと前記通信相手特定手段によって特定された通信相手のコンポーネントに対して動作データの出力の詳細レベルを上昇させ、前記比較手段によって異常発生時と現在実行中の出力が類似していないと判定された場合には、異常発生コンポーネントと前記通信相手特定手段によって記憶された通信相手のコンポーネントに対して動作データ出力の詳細レベルを下降させることを特徴とする請求項１記載の通信制御装置。
【請求項３】
前記動作データ記憶手段は、システムの正常動作時における動作データを記憶し、
前記出力レベル制御機能手段は、前記比較手段によって正常動作時と現在実行中の出力が異なると判定された場合には、異なる動作データを出力したコンポーネントと前記通信相手特定手段によって特定された通信相手のコンポーネントに対して動作データの出力の詳細レベルを上昇させ、前記比較手段によって現在実行中の実行状態が正常状態と等しくなったと判定された場合には、当該コンポーネントと前記通信相手特定手段によって特定された通信相手のコンポーネントに対して動作データ出力の詳細レベルを下降させることを特徴とする請求項１記載の通信制御装置。
【請求項４】
前記出力レベル制御手段は、特定コンポーネント及び特定コンポーネントの通信相手コンポーネント以外の事前に指定されたコンポーネントに対しても、前記特定コンポーネントの出力レベル上昇及び下降に連動して出力レベル制御を行うことを特徴とする請求項１記載の通信制御装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のソフトウェアコンポーネントが相互に通信しながら動作する通信制御装置に関する。特に、コンポーネントの動作状況を表す動作データの出力を効率的に行うことによって、定常運転時の動作データ出力量の抑制と、システム障害の原因調査に必要となる詳細な動作データの出力とを両立させることができる通信制御装置に関する。
【背景技術】
【０００２】
近年、ソフトウェアシステム開発においては、ソフトウェアを相互に依存度の低い部品（コンポーネント）単位に分割し、コンポーネント同士が相互に通信を行いながら動作するソフトウェアのコンポーネント化が推進されている。
【０００３】
さらに、コンポーネント間の通信では、通信制御を統一的に行う通信ミドルウェアを導入し、通信のインターフェイスを統一することによって、システムの保守性向上やコンポーネントの再利用による生産性向上が目指されている。
【０００４】
また、システムにソフトウェア障害が発生したときの原因究明手法としては、以下の手法が一般的である。即ち、各ソフトウェアコンポーネントがそれぞれ自身の動作状況を表すデータをメモリあるいはディスク装置に出力しておき、システムの管理者あるいは開発者が出力された動作データを精査・解析して障害の原因を推定する手法である。
【０００５】
出力された動作データからソフトウェア障害の原因を調査するためには一定以上詳細な動作データが必要になる。しかし、システムに異常が発生する前の定常運転時から詳細な動作データを出力していると、動作データの保存場所となるメモリやディスク装置の容量を圧迫し、システムの動作に支障をきたすこともある。そのため、通常は出力の詳細レベルを必要に応じて上下する制御を行う。
【０００６】
具体的には、重要な動作データのみを出力するモード、詳細な動作データを含めて出力するモードのように複数段階の出力の詳細レベルを制御できる機能を実装しておき、定常運転時には重要な動作データのみを出力するようにしておく。システムにソフトウェア障害が発生したら、詳細な動作データを出力する設定に変更した上で障害発生時と同様の操作を行い、ソフトウェア障害の再現を待って出力された詳細な動作データの解析を行う。
【０００７】
これらの背景技術に関しては、先行技術として特許文献１や特許文献２などが提案されている。
【０００８】
特許文献１には、システムの定常運転時にソフトウェアの動作データであるログの出力状況を監視し、繰り返しなどのパターンが現れたら適宜ログの圧縮処理を行うことで、ログ量を抑制する技術が開示されている。
【０００９】
特許文献２には、同様に、システムの定常運転時にＣＰＵ、メモリ、ディスク装置などのコンピュータ資源を監視し、資源の不足など障害が起きると思われる状況になると、システムを監視モードに切り替えて障害を早期に検知する技術が開示されている。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特開平１０−２７５１０１号公報
【特許文献２】特開２００８−５９１０２号公報
【発明の概要】
【発明が解決しようとする課題】
【００１１】
半導体露光装置などの大規模システムにおいては、システムを構成するコンポーネントは非常に多数に上り、またコンポーネントが複数のマシンノードに分散していることもある。同時に、半導体露光装置では、数週間〜数ヶ月に渡ってシステムが動作し続けることもある。また、このようなシステムにおいては、各コンポーネントが自身の動作データとしてログを主にディスク装置に出力している。
【００１２】
このような状況下では、システムにソフトウェア障害が発生し、原因の解析のために障害を再現させるとき、障害が再現するまでに長期間システムを動作させる必要がある場合が多い。その場合、多数のコンポーネントが長期間に渡ってログを出力することから解析対象となるログの出力量が膨大なものとなり、ログの保存場所となるメモリやディスク装置の領域を圧迫すると同時に、膨大なログの解析が困難になるという問題が生じる。
【００１３】
また、多数のコンポーネントが並列に動作して各々ログを出力することからシステム全体における単位時間当たりのログの出力量が非常に多くなる。結果として、ログ出力処理がシステムの計算資源を圧迫し、障害発生時とシステムの動作状況が変わってしまって障害の再現ができなくなることがある。
【００１４】
上記特許文献１では、保存されるログの総量を抑制することは可能であるが、詳細ログを出力して障害の再現を行う際には、システム全体に渡って詳細なログが出力されてしまい、ログ出力処理が計算資源を圧迫してしまう問題は解決できない。また、ログの圧縮処理を行うことでさらに計算資源を圧迫してしまう。
【００１５】
また、上記特許文献２では、出力ログも含むシステム状態を監視して、異常が起きると思われる状況になった場合のみ特別なモードに移行することで効率的にログを出力することが可能になる。しかし、監視モードに移行した際には、やはりシステム全体に渡って詳細なログが出力されてしまい、同様にログ出力処理が計算資源を圧迫してしまう。
【００１６】
本発明の目的は、コンポーネントの効果的な障害解析と、システム全体の動作データ出力量の抑制を両立させることができる通信制御装置を提供することにある。
【課題を解決するための手段】
【００１７】
上記目的を達成するために、請求項１記載の通信制御装置は、複数のコンポーネント間の通信を制御する通信制御装置において、監視対象となる特定コンポーネントにおける、実行時の動作データを記憶しておく動作データ記憶手段と、前記動作データ記憶手段に記憶されたデータ列から、前記特定コンポーネントの通信相手のコンポーネントを特定する通信相手特定手段と、前記動作データ記憶手段に記憶された所定動作状態におけるデータ列と、前記特定コンポーネントが実行時に出力するデータとを比較する比較手段と、前記比較手段による比較結果に応じて、前記特定コンポーネントと前記通信相手特定手段によって特定された通信相手のコンポーネントに対して、動作データ出力の詳細レベルを制御する出力レベル制御機能手段とを備えることを特徴とする。
【発明の効果】
【００１８】
本発明の通信制御装置によれば、コンポーネントの効果的な障害解析と、システム全体の動作データ出力量の抑制を両立させることができる。
【図面の簡単な説明】
【００１９】
【図１】本発明の実施の形態に係る通信制御装置のシステム構成を示すブロック図である。
【図２】図１の通信制御装置における同一マシン内の通信時のシステム構成図である。
【図３】図１の通信制御装置における異なるマシンに配置されたコンポーネント間の通信を行う際のシステム構成図である。
【図４】図１の通信制御装置における定常運転時の第１の実施の形態のシステム構成図である。
【図５】図１の通信制御装置における障害再現時の第１の実施の形態のシステム構成図である。
【図６】図１の通信制御装置におけるログ出力レベルの例を示す図表である。
【図７】図１の通信制御装置における定常運転時に、重要なログのみが出力されている状態のイメージ図である。
【図８】図１の通信制御装置における障害再現時に重要なログのみが詳細に出力され、その他のログは重要なものだけが出力されている状態のイメージ図である。
【図９】障害再現時に図５の通信ミドルウェアが行う障害再現実行処理の手順を示すフローチャートである。
【図１０】ログ配列の比較方法を示すイメージ図である。
【図１１】図１の通信制御装置における定常運転時の第２の実施の形態のシステム構成図である。
【図１２】図１の通信制御装置における障害再現時の第２の実施の形態のシステム構成図である。
【図１３】図１２の通信ミドルウェアが行うジョブ実行処理の手順を示すフローチャートである。
【発明を実施するための形態】
【００２０】
以下、本発明を図面を参照しながら詳細に説明する。
【００２１】
図１は、本発明の実施の形態に係る通信制御装置のシステム構成を示すブロック図である。
【００２２】
以下、その構成を動作と併せて説明する。
【００２３】
図１において、通信ミドルウェア１０１は、動作データ記憶機能部１０７、データ列１０８、通信相手記憶機能部（通信相手特定手段）１０９、動作データ比較機能部１１０、出力レベル制御機能部１１１、関連コンポーネント出力レベル制御機能部１１２を備える。出力レベル制御機能部１１１は、コンポーネントによる動作データの出力レベルをコンポーネント毎に任意に制御する。
【００２４】
通信ミドルウェア１０１上に複数のコンポーネント１０２、１０３が動作している。コンポーネント１０２は動作データ１０４を出力し、出力された動作データ１０４は動作データ保存機能部１０５によって任意の場所に保存される。
【００２５】
ここで、コンポーネント１０２は、動作しているコンポーネントのうち、コンポーネント特定機能部１０６により、実行時の動作データを監視する対象となるコンポーネントとして特定されたコンポーネントである。
【００２６】
コンポーネント１０２が動作中に出力する動作データ１０４は、動作データ記憶機能部１０７によってデータ列１０８に記憶される。このデータ列１０８から通信相手記憶機能部１０９によってコンポーネント１０２の通信相手たるコンポーネントが抽出され、記憶される。ここでコンポーネント（コンポーネント群）１０３は通信相手記憶機能部１０９によって記憶されたコンポーネントである。
【００２７】
システムの動作中においては、データ列１０８と、コンポーネント特定機能部１０６によって特定されたコンポーネント１０２の出力する動作データ１０４が動作データ比較機能部１１０によって比較される。
【００２８】
そして、比較結果に応じて、コンポーネント１０２に対しては出力レベル制御機能部１１１が、コンポーネント１０３に対しては関連コンポーネント出力レベル制御機能部１１２が、それぞれ動作データの出力レベル（動作データ出力の詳細レベル）を制御する。
【００２９】
また、コンポーネント特定機能部１０６は、システムのソフトウェア異常発生時に異常の発生したコンポーネントを特定コンポーネントとする。また、動作データ記憶機能部１０７は、異常発生時の近傍の、異常発生コンポーネントにおける動作データを記憶する。
【００３０】
また、関連コンポーネント出力レベル制御機能部１１２は、動作データ比較機能部１１０によって現在実行中の出力が異常発生時の出力と類似していると判定された場合には、以下のように制御する。即ち、関連コンポーネント出力レベル制御機能部１１２は、異常発生コンポーネントと通信相手記憶機能部１０９によって記憶された通信相手のコンポーネントに対して動作データの出力の詳細レベルを上昇させる。
【００３１】
また、動作データ比較機能部１１０によって現在実行中の出力が異常発生時の出力と類似していないと判定された場合には、関連コンポーネント出力レベル制御機能部１１２は、以下のように制御する。即ち、関連コンポーネント出力レベル制御機能部１１２は、異常発生コンポーネントと通信相手記憶機能部１０９によって記憶された通信相手のコンポーネントに対して動作データ出力の詳細レベルを下降させる。
【００３２】
また、関連コンポーネント出力レベル制御機能部１１２は、動作データ比較機能部１１０によって現在実行中の出力が正常動作時（所定動作状態）の出力と異なると判定された場合には、以下のように制御する。即ち、関連コンポーネント出力レベル制御機能部１１２は、異なる動作データを出力したコンポーネントと通信相手記憶機能部１０９によって記憶された通信相手のコンポーネントに対して動作データの出力の詳細レベルを上昇させる。
【００３３】
また、動作データ比較機能部１１０によって現在実行中の実行状態が正常状態と等しくなったと判定された場合には、関連コンポーネント出力レベル制御機能部１１２は、以下のように制御する。即ち、当該コンポーネントと通信相手記憶機能部１０９によって記憶された通信相手のコンポーネントに対して動作データ出力の詳細レベルを下降させる。
【００３４】
また、出力レベル制御機能部１１１は、特定コンポーネント、特定コンポーネントの通信相手コンポーネント以外の事前に指定されたコンポーネントに対しても、特定コンポーネントの出力レベル上昇及び下降に連動して出力レベル制御を行う。即ち、出力レベル制御機能部１１１は、個別指定出力レベル制御機能を有する。
【００３５】
図２は、図１の通信制御装置における同一マシン内の通信時のシステム構成図である。
【００３６】
尚、図２以下において、通信ミドルウェア、コンポーネントは、図番に対応した符号を付すものとする。
【００３７】
マシンＡ２０１上に通信ミドルウェア２０２が動作しており、通信ミドルウェア２０２上に配置されたコンポーネント２０３とコンポーネント２０４が通信を行っている。この通信は、具体的には共有メモリを用いたプロセス間通信や、ヒープ等を用いたプロセス内の通信に相当する。
【００３８】
図３は、図１の通信制御装置における異なるマシンに配置されたコンポーネント間の通信を行う際のシステム構成図である。
【００３９】
マシンＡ３０１とマシンＢ３０２が通信路３０３によって接続されており、このシステム上に通信ミドルウェア３０４が動作している。通信路３０３の具体例としては、ＴＣＰ／ＩＰによるネットワークや、ＰＣＩのようなローカルバスが考えられる。
【００４０】
このような状況下で、マシンＡ３０１上に配置されたコンポーネント３０５とマシンＢ３０２上に配置されたコンポーネント３０６が通信ミドルウェア３０４を介して通信を行っている。この通信は実際には通信路３０３を使って実現されている。
【００４１】
図４は、図１の通信制御装置における定常運転時の第１の実施の形態のシステム構成図である。
【００４２】
通信ミドルウェア４０１を介してソフトウェアコンポーネント４０２や４０３が相互に通信を行うことによって、本システムは動作している。
【００４３】
コンポーネント４０２は、動作時にはコンポーネントの動作状況を表すログ４０４をディスク装置上のファイルとして出力している。コンポーネント４０２にソフトウェア障害が発生すると、ログ記憶機能部４０５によって障害発生時点近傍のログは障害発生時ログ配列４０６として通信ミドルウェア４０１内に記憶される。障害の原因を調査するために、コンポーネント４０２を再び動作させて障害の原因を調査する。
【００４４】
図５は、図１の通信制御装置における障害再現時の第１の実施の形態のシステム構成図である。
【００４５】
コンポーネント５０２は、障害が発生したコンポーネントである。コンポーネント５０２は、通信ミドルウェア５０１を介してコンポーネント５０３と通信を行っている。ここでは、障害発生時近傍のログ配列中に存在する通信ログにおいて、コンポーネント５０２の通信相手として記録されているコンポーネントを、コンポーネント５０２と通信を行っているコンポーネントと定義している。同時にシステムには、コンポーネント５０２と直接通信は行わないコンポーネント（コンポーネント群）５０４も存在している。
【００４６】
再現動作時には、コンポーネント５０２及びコンポーネント５０３はログ５０５をそれぞれディスク装置上のファイルとして出力している。ここで、通信ミドルウェア５０１には、障害発生時の近傍における障害発生時ログ配列５０６が記憶されている。
【００４７】
システムが動作を開始したら、ログ比較機能部５０７は、障害が発生したコンポーネント５０２が出力するログ５０５と、障害発生時の近傍ログ配列５０６をリアルタイムに比較し、コンポーネント５０２が障害発生時の状態に近いかどうかを判定する。具体的な本実施の形態の動作アルゴリズムについては、図９で後述する。
【００４８】
判定の結果、現在出力中のログ５０５が障害発生時のログに近似していることが判明したら、ログレベル制御機能部５０８がコンポーネント５０２のログ出力レベルを上昇させ、詳細なログを出力するようにする。同時に、ログ比較機能部５０７は、ログレベル制御機能部５０８を用いてコンポーネント５０２の通信相手であるコンポーネント５０３のログ出力レベルを上昇させる。
【００４９】
同様に、判定の結果、現在出力中のログ５０５が障害発生時のログに近似していないことが判明したら、ログレベル制御機能部５０８がコンポーネント５０２のログ出力レベルを下降させ、重要なログのみを出力するようにする。同時に、ログレベル制御機能部５０８は、コンポーネント５０２の通信相手であるコンポーネント５０３のログ出力レベルを下降させる。
【００５０】
図６は、図１の通信制御装置におけるログ出力レベルの例を示す図表である。
【００５１】
詳細度レベル「ＬＯＧ」６０１は、最も重要なログであり、コンポーネント間の通信など、システム全体の動作状態を記録しておくためのログである。本発明において、異常時に近傍の通信相手記憶機能部１０９が通信相手を抽出するために使用する通信ログはこのレベルに含まれる。
【００５２】
詳細度レベル「ＦＡＴＡＬ」６０２は、次に重要なログであり、ＯＳのカーネル資源不足などに起因する、システムコールのエラーなどソフトウェアコンポーネントでは復帰不能なエラーを記録しておくログである。
【００５３】
詳細度レベル「ＥＲＲＯＲ」６０３は、３番目に重要なログであり、通信路のエラーなど、ソフトウェアコンポーネントで復帰処理を行わなければならない、異常系を表すログである。
【００５４】
詳細度レベル「ＷＡＲＮＩＮＧ」６０４は、４番目に重要なログであり、排他処理のタイムアウトなど、正常系の処理でも起こりうるエラーを記録しておくログである。
【００５５】
詳細度レベル「ＤＥＢＵＧ」６０５は、最も詳細なログであり、内部関数のエラーや、関数呼び出し時の引数の出力など、障害調査やデバッグを行う際の情報を出力するためのログである。
【００５６】
図７は、図１の通信制御装置における定常運転時に、重要なログのみが出力されている状態のイメージ図である。
【００５７】
通信ミドルウェア７０１上にはコンポーネントＡ７０２、コンポーネントＢ７０３、コンポーネントＣ７０４及びその他のコンポーネント（コンポーネント群）７０５が存在し、それぞれが自身の動作状態を表すログ７０６、７０７、７０８、７０９を出力している。
【００５８】
本実施の形態においては、コンポーネント特定機能として、障害が発生したコンポーネントを特定コンポーネントとして扱う。
【００５９】
図７においては、コンポーネントＡ７０２が障害の発生したコンポーネントである。コンポーネントＡ７０２においてソフトウェア障害が発生すると、図４のログ記憶機能部４０５によってコンポーネントＡ７０２の障害発生時近傍でのログ配列が障害発生時ログ配列４０６に記憶される。
【００６０】
ここで、コンポーネントＡ７０２が出力したログ７０６のうちコンポーネント間通信を行ったログに着目する。図７においては、コンポーネントＡ７０２からＢ７０３への通信を通信Ａ→Ｂ、コンポーネントＣ７０４からＡ７０２への通信を通信Ｃ→Ａと表記している。
【００６１】
この場合、障害発生時ログ配列におけるコンポーネントＡ７０２の通信相手はコンポーネントＢ７０３及びコンポーネントＣ７０４となる。これら２つのコンポーネントが図５における障害発生コンポーネント５０２の通信相手コンポーネント５０３に該当することになる。
【００６２】
図８は、図１の通信制御装置における障害再現時に重要なログのみが詳細に出力され、その他のログは重要なものだけが出力されている状態のイメージ図である。
【００６３】
図７と同様に、通信ミドルウェア８０１上にはコンポーネントＡ８０２、コンポーネントＢ８０３、コンポーネントＣ８０４及びその他のコンポーネント（コンポーネント群）８０５が存在する。そして、それぞれが自身の動作状態を表すログ８０６、８０７、８０８、８０９を出力している。
【００６４】
障害発生コンポーネントに当たるコンポーネントＡ８０２、及び通信相手コンポーネントに当たるコンポーネントＢ８０３、Ｃ８０４においては、障害発生時の近傍で詳細なログ８０６、８０７、８０８が出力される。その他のコンポーネント８０５では定常運転時と同じく重要なログ８０９のみが出力されている。
【００６５】
このように本実施の形態によって、障害再現後にログによる解析を行う際に重要な、障害発生コンポーネント及びその通信相手コンポーネントの障害発生時点近傍での詳細なログを取得することができる。
【００６６】
さらに、解析に重要でないと考えられる障害発生コンポーネントと通信を行わない多数のコンポーネント群に関しては、定常運転時と同様に重要なログのみを出力させることができる。従って、効果的な障害解析と、システム全体のログ出力量の抑制を両立させることができる。
【００６７】
図９は、障害再現時に図５の通信ミドルウェアが行う障害再現実行処理の手順をフローチャートである。以下、このフローチャートに沿って、実際の運用時の制御フローを説明する。
【００６８】
まず、障害の再現実行が開始されると（ステップＳ９０１）、この時点では障害発生コンポーネントは重要なログのみを出力している（ステップＳ９０２）。
【００６９】
ログが出力され始めると、ログ比較機能部５０７によって、障害発生コンポーネントが出力したログと通信ミドルウェア内に記憶されている障害発生時ログ配列５０６とが比較される（ステップＳ９０３）。
【００７０】
この比較では、ある閾値Ｘを予め設定しておき、障害発生コンポーネントが最近出力したログＸ個と、障害発生時ログ配列５０６の先頭Ｘ個のログを比較し、一致していたら近似していると判定する。
【００７１】
図１０は、図９のステップＳ９０３におけるログ配列の比較方法を示すイメージ図である。
【００７２】
図１０では、閾値Ｘを３とおき、障害発生コンポーネントから最近出力された３つのログ「ＡＢＣ」「ＤＥＦ」「ＧＨＩ」と障害発生時近傍ログの先頭３つのログ「ＡＢＣ」「ＤＥＦ」「ＧＨＩ」を比較している。これらのログが一致しているため、出力中のログが障害発生時のログに近似していると判定している例である。
【００７３】
図９の説明に戻る。ステップＳ９０３において、出力中のログが障害発生時のログと近似していないと判定されたら、ステップＳ９０２に戻って実行を継続する。近似していると判定されたなら、障害発生コンポーネントのログ出力レベルを上昇させ、詳細なログを出力するようにする（ステップＳ９０４）。同時に、障害発生時近傍ログに含まれる通信相手コンポーネントに対してログ出力レベルを上昇させる要求を行う（ステップＳ９０５）。
【００７４】
ログ出力レベルが上昇した状態では、コンポーネントは重要なログだけでなく詳細なログも出力する（ステップＳ９０６）。この状態では、ログが出力されるたびに、定常運転時と同じ障害が発生したかどうか障害発生コンポーネントを監視する（ステップＳ９０７）。障害が再現したならば、これまでに出力された詳細なログを解析して障害の原因を調査することになり、本処理は終了である。
【００７５】
障害が発生したことを判定する方法としては、前回障害発生時に障害発生のログが明確に出力されていた場合は同じ障害発生ログが出力されることで判定する方法がある。あるいは、システムが異常終了する、システムが停止してしまうなどの状況に陥ってしまい人間が障害再現を判定する場合も考えられる。
【００７６】
障害が発生しない間は、障害発生コンポーネントは変わらずログを出力し続ける（ステップＳ９０８）。フローチャートでは便宜上重要ログと記載してあるが、このタイミングで詳細ログが出力されることも当然ありうる。
【００７７】
ステップＳ９０８のように、障害が発生しない状態で重要ログが出力された場合、ステップＳ９０３と同様の比較を行い、出力中のログが障害発生時のログと近似しているかを判定する（ステップＳ９０９）。
【００７８】
ここで判定に使用する閾値Ｙは、事前に設定した閾値に、ログ出力レベル上昇中（ステップＳ９０３〜ステップＳ９０９）に出力された重要ログの数を足した値である。該区間において重要ログが３つ出力されていたならば、ステップＳ９０９における閾値ＹはＸ＋３に等しい。
【００７９】
ステップＳ９０９において、出力中のログが障害発生時のログと近似していると判定されたら、ログレベルを上昇させたまま実行を継続する。即ち、ステップＳ９０６に戻る。逆に、ステップＳ９０９において、出力中のログと障害発生時のログが近似していないと判定された場合は、障害発生コンポーネントのログ出力レベルを下降させ、重要なログのみを出力する状態に戻す（ステップＳ９１０）。
【００８０】
同時に、障害発生時近傍ログに含まれる通信相手コンポーネントに対しても、ログ出力レベルを下降させる要求を行い（ステップＳ９１１）、再びステップＳ９０２に戻って障害再現を続行する。
【００８１】
以上のように、障害が発生したコンポーネントの障害原因を解析するために、該当コンポーネント及びその通信相手のコンポーネントにおいて必要な期間のみ詳細なログを出力し、それ以外の期間・それ以外のコンポーネントでは重要なログのみを出力する。これにより、効果的な障害解析と、システム全体のログ出力量の抑制とを両立させることができる。
【００８２】
本実施の形態では、動作データとしてディスク装置上のファイルに出力されるログを仮定したが、本発明の実施については、揮発性メモリ上に出力されるログ、あるいは動作履歴などの出力手段を用いても構わない。
【００８３】
また、本実施の形態では、ステップＳ９０５及びステップＳ９１１において、通信相手コンポーネントに対してログ出力レベルの変更を要求していた。しかし、通信相手コンポーネント以外の、予め指定しておいた特定コンポーネントに対してもログ出力レベルの変更を要求しても構わない。これは、障害発生コンポーネントと直接通信を行ってはいないが、システムの動作にとって特に重要なコンポーネントが予めわかっている場合には有用である。
【００８４】
図１１は、図１の通信制御装置における定常運転時の第２の実施の形態のシステム構成図である。
【００８５】
図１１においては、ログ記憶機能として異常が発生した場合のログを記憶しておくのではなく、正常に動作している場合のログを記憶する。
【００８６】
通信ミドルウェア１１０１を介してソフトウェアコンポーネント１１０２や１１０３が相互に通信を行うことによって、本システムは動作している。
【００８７】
コンポーネント１１０２は、システム全体の動作にとって特に重要なコンポーネントであって、本発明による監視対象となる特定コンポーネントとして指定されているものとする。動作時にはコンポーネントの動作状況を表すログ１１０４をディスク装置上のファイルとして出力している。
【００８８】
まず、コンポーネント１１０２を一定期間に亘って動作させる。そこでシステムが正常に動作したと判定された場合は、出力されたログはログ記憶機能部１１０５によって正常動作時ログ配列１１０６として通信ミドルウェア１１０１内に記憶される。
【００８９】
図１２は、図１の通信制御装置における障害再現時の第２の実施の形態のシステム構成図である。
【００９０】
図１２においては、ログ比較機能は、ログ記憶機能によって記憶された障害発生時のログと比較するのではなく、正常動作時のログと比較を行う。
【００９１】
コンポーネント１２０２は、監視の対象となる特定コンポーネントである。コンポーネント１２０２は、通信ミドルウェア１２０１を介してコンポーネント１２０３と通信を行っている。
【００９２】
ここでは、正常動作時のログ配列中に存在する通信ログにおいて、コンポーネント１２０２の通信相手として記録されているコンポーネントを、コンポーネント１２０２と通信を行っているコンポーネントと定義している。システムには、コンポーネント１２０２と直接通信は行わないコンポーネント（コンポーネント群）１２０４も存在している。
【００９３】
再現動作時には、コンポーネント１２０２及びコンポーネント１２０３はログ１２０５をそれぞれディスク装置上のファイルとして出力している。ここで、通信ミドルウェア１２０１には正常動作時における正常動作時ログ配列１２０６が記憶されている。
【００９４】
システムが動作を開始したら、ログ比較機能部１２０７は特定のコンポーネント１２０２が出力するログ１２０５と、正常動作時ログ配列１２０６をリアルタイムに比較し、コンポーネント１２０２が正常動作時の状態と等しいかどうかを判定する。
【００９５】
判定の結果、現在出力中のログ１２０５が正常動作時のログと異なっていることが判明したら、ログレベル制御機能部１２０８がコンポーネント１２０２のログ出力レベルを上昇させ、詳細なログを出力するようにする。さらに、ログ比較機能部１２０７は、ログレベル制御機能部１２０８を用いてコンポーネント１２０２の通信相手であるコンポーネント１２０３のログ出力レベルを上昇させる。
【００９６】
同様に、判定の結果、現在出力中のログ１２０５が正常動作時のログに等しいことが判明したら、ログレベル制御機能部１２０８がコンポーネント１２０２のログ出力レベルを下降させ、重要なログのみを出力するようにする。さらに、ログレベル制御機能部１２０８は、コンポーネント１２０２の通信相手であるコンポーネント１２０３のログ出力レベルを下降させる。
【００９７】
図１３は、図１２の通信ミドルウェアが行うジョブ実行処理の手順を示すフローチャートである。以下、このフローチャートに沿って、実際の運用時の制御フローを説明する。
【００９８】
まず、ジョブの実行が開始されると（ステップＳ１３０１）、この時点では特定コンポーネントは重要なログのみを出力している（ステップＳ１３０２）。
【００９９】
この時点でジョブの実行が終了したら（ステップＳ１３０３）、本処理は終了である。
【０１００】
ログが出力され始めると、ログ比較機能部１２０７によって、特定コンポーネントが出力したログと通信ミドルウェア内に記憶されている正常動作時ログ配列１２０６とが比較される（ステップＳ１３０４）。この比較では、ある閾値Ｘを予め設定しておき、障害発生コンポーネントが最近出力したログＸ個と、正常動作時ログ配列１２０６の先頭Ｘ個のログを比較し、一致していたら近似していると判定する。
【０１０１】
ここで、出力中のログが正常動作時のログと一致していると判定されたら、ステップＳ１３０２に戻って実行を継続する。異なっていると判定されたなら、特定コンポーネントのログ出力レベルを上昇させ、詳細なログを出力するようにする（ステップＳ１３０５）。同時に、正常動作時ログ配列１２０６に含まれる通信相手コンポーネントに対してログ出力レベルを上昇させる要求を行う（ステップＳ１３０６）。
【０１０２】
ログ出力レベルが上昇した状態では、コンポーネントは重要なログだけでなく詳細なログも出力する（ステップＳ１３０７）。この状態では、ログが出力されるたびに、ソフトウェアに何らかの障害が発生したかどうかを監視する（ステップＳ１３０８）。
【０１０３】
障害が発生したならば、これまでに出力された詳細なログを解析して障害の原因を調査することになり、本処理は終了である。障害が発生したことを判定する方法としては、コンポーネントが出力するログ中に障害発生を表すログが明確に出力される、あるいはシステムが異常終了する、システムが停止してしまうなどの状況に陥ってしまい人間が障害再現を判定する方法などが考えられる。
【０１０４】
障害が発生しない間は、コンポーネントは変わらずログを出力し続ける（ステップＳ１３０９）。フローチャートでは便宜上重要ログと記載してあるが、このタイミングで詳細ログが出力されることも当然ありうる。
【０１０５】
ステップＳ１３０９のように障害が発生しない状態で重要ログが出力された場合、ステップＳ１３０４と同様の比較を行い、出力中のログが正常運転時のログと一致しているかを判定する（ステップＳ１３１０）。
【０１０６】
ステップＳ１３１０において、出力中のログが正常運転時のログと異なっていると判定されたらステップＳ１３０７に戻り、ログレベルを上昇させたまま実行を継続する。
【０１０７】
逆に、ステップＳ１３１０の判定の結果、出力中のログと正常時のログが一致していると判定された場合は、コンポーネントのログ出力レベルを下降させ、重要なログのみを出力する状態に戻す（ステップＳ１３１１）。同時に、正常動作時ログ配列１２０６に含まれる通信相手コンポーネントに対しても、ログ出力レベルを下降させる要求を行い（ステップＳ１３１２）、再びステップＳ１３０２に戻ってジョブの実行を続行する。
【０１０８】
以上のように、あるジョブの実行時においてソフトウェアの障害が発生した場合に、当該ジョブが正常に実行された場合のログ配列と異なったログが出力されている期間のみ詳細なログを出力し、それ以外の期間では重要なログのみを出力する。これにより、効果的な障害解析と、システム全体のログ出力量の抑制を両立させることができる。
【符号の説明】
【０１０９】
１０１  通信ミドルウェア
１０２  コンポーネント
１０３  コンポーネント群
１０４  動作データ
１０５  動作データ保存機能部
１０６  コンポーネント特定機能部
１０７  動作データ記憶機能部
１０８  データ列
【図１】
2010286889.tif 000003
【図２】
2010286889.tif 000004
【図３】
2010286889.tif 000005
【図４】
2010286889.tif 000006
【図５】
2010286889.tif 000007
【図６】
2010286889.tif 000008
【図７】
2010286889.tif 000009
【図８】
2010286889.tif 000010
【図９】
2010286889.tif 000011
【図１０】
2010286889.tif 000012
【図１１】
2010286889.tif 000013
【図１２】
2010286889.tif 000014
【図１３】
2010286889.tif 000015