JP4909870B2 - 障害ログ管理方法 - Google Patents

障害ログ管理方法 Download PDF

Info

Publication number
JP4909870B2
JP4909870B2 JP2007279018A JP2007279018A JP4909870B2 JP 4909870 B2 JP4909870 B2 JP 4909870B2 JP 2007279018 A JP2007279018 A JP 2007279018A JP 2007279018 A JP2007279018 A JP 2007279018A JP 4909870 B2 JP4909870 B2 JP 4909870B2
Authority
JP
Japan
Prior art keywords
service processor
log
load factor
failure
failure log
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2007279018A
Other languages
English (en)
Other versions
JP2009110078A (ja
Inventor
功 平塚
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2007279018A priority Critical patent/JP4909870B2/ja
Publication of JP2009110078A publication Critical patent/JP2009110078A/ja
Application granted granted Critical
Publication of JP4909870B2 publication Critical patent/JP4909870B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Description

本発明は障害ログ管理方法に係り、特にサービスプロセッサの監視下にある計算機に障害が発生した場合の障害ログの管理に関するものである。
データ処理を行う複数の計算機をサービスプロセッサによって管理するシステムが知られている。一般的に、サービスプロセッサは計算機の電源オン・オフ、フェイルオーバー等の制御や計算機の状態を定期的に監視し、ある計算機に障害が発生すると、その障害を検知する。更に、サービスプロセッサは、障害要因を特定するために、障害の発生した計算機から障害ログを取得して、サービスプロセッサが持つ記憶装置にそのログを保存する。
ところで、サービスプロセッサが複数の計算機の障害をほぼ同時に検知した場合、障害が検知された計算機の障害ログを一斉に取得するので、サービスプロセッサに過度な負荷がかかることがある。そのため、サービスプロセッサによる定期的な計算機の障害監視やフェイルオーバー等が正常に行われない可能性がある。その結果、システムの安定性が低下する。
斯かる問題を解決するものとして、特許文献1には、計算機システム上にサービスプロセッサに相当する統括管理計算機(SCC)を複数台設け、特定のSCCに障害が発生した場合や過度な負荷がかかった場合には、他の安定稼動しているSCCに計算機の制御・監視処理を代替依頼することで、システムを安定に稼動させる技術が開示されている。
特開平8-329024号公報
特許文献1に開示された技術は、過度な負荷のかかったSCCは他の安定稼動しているSCCに対して処理の全てを代替し、負荷分散は行なっていない。そのため、全てのSCCの処理能力が同程度である場合は、代替のSCCにもやはり過度な負荷がかかってしまう。その結果、SCCによる代替が頻発し、かえってシステムの安定性が低下する恐れがある。
本発明の目的は、監視対象の計算機に発生した障害の処理に際して、サービスプロセッサへの過度な負荷がかかることが防止することにある。
本発明は、好ましい例によれば、サービスプロセッサによって計算機を監視し、該計算機に発生した障害を検知してその障害のログを管理する障害ログ管理方法において、該計算機の障害ログを取得して、前記障害ログを取得した場合における自サービスプロセッサの負荷率を測定し、該負荷率が所定の範囲内にある場合、該障害ログを記憶装置に保存し、
測定した該負荷率が所定の範囲内にない場合、障害ログをキャッシュに一時的に保存し、
一定時間経過後、自サービスプロセッサの負荷率を再度測定して、該所定の範囲との関係を調べ、その結果、所定の範囲内になった時、該キャッシュに保存された該障害ログを該記憶装置に保存することを特徴とする障害ログ管理方法として構成される。
また、本発明は好ましくは、複数の計算機を複数のグループに分割し、グループ毎にサービスプロセッサを割り当てて、該サービスプロセッサをネットワークにより接続したシステムにおいて該計算機に発生した障害のログを管理する障害ログ管理方法であって、
該サービスプロセッサは、該計算機の障害ログを取得して、前記障害ログを取得した場合における自サービスプロセッサの負荷率を測定し、該負荷率が所定の範囲内にある場合、該障害ログを該記憶装置に保存し、測定した負荷率が該所定の範囲内にない場合、該障害ログをキャッシュに一時的に保存し、
該キャッシュに一時的に保存された障害ログを該記憶装置に保存する際に、該サービスプロセッサの負荷率が所定の範囲内にあるかを判定し、該負荷率が所定の範囲内にない場合、該ネットワークに接続されている他グループの他サービスプロセッサの中から負荷率が所定の範囲内にある他サービスプロセッサを選定し、
選定された他サービスプロセッサへ該ネットワークを介して障害ログを送信し、
他サービスプロセッサは、受信した該障害ログを自身の記憶装置に保存することを特徴とする障害ログ管理方法として構成される。
また、好ましい例では、該サービスプロセッサは自身のキャッシュに障害ログを保存する時、キャッシュの空き容量を測定し、
該キャッシュの空き容量が所定以上の場合は該キャッシュに障害ログを保存し、該キャッシュの空き容量が所定以上でない場合は、ネットワークに接続されている他グループの他サービスプロセッサの中から負荷率が所定の範囲内にある他のサービスプロセッサを選定して、選定された該他サービスプロセッサへ障害ログを送信する。
また、好ましい例では、各サービスプロセッサは、他サービスプロセッサへ障害ログの保存を要求する場合、複数の他サービスプロセッサへ該要求を送信する順番を登録した保存要求テーブルを参照して、該要求の送信先となるサービスプロセッサを決める。
また、好ましくは、測定した自サービスプロセッサの負荷率と、予め定められた負荷率の閾値と比較し、測定した負荷率が該閾値未満の場合、障害ログを記憶装置に保存し、測定した負荷率が該閾値以上の場合、障害ログをキャッシュに一時的に保存する。
本発明によれば、監視対象の計算機に障害が発生した場合でも、サービスプロセッサに過度な負荷がかかることを防止できる。これにより計算機の定期監視、フェイルオーバー等の処理を正常に行うことが可能となり、システムの高可用性が実現できる。
以下、図面を参照して本発明の実施形態について説明する。
図1は一実施形態における計算機システムの構成図を示す。
この計算機システムは、それぞれ複数の計算機105、205を制御、監視する複数のサービスプロセッサ10,20がネットワーク90を介して接続して構成される。
複数のサービスプロセッサ10、20は実質的に同じ構成を成している。特に断らない限り、以下、サービスプロセッサ10側を例に説明する。
サービスプロセッサ10は、記憶装置101、通信制御部102、状態管理部103、システム制御部104を有し、同じグループ内の複数の計算機105を制御、監視する。
システム制御部104は、キャッシュ106、保存要求テーブル107、カウンタ108、キャッシュテーブル109を有する。記憶装置101は障害ログを記憶する。また、キャッシュ106も障害ログを一時的に保存する。
通信制御部102は、システム制御部104をネットワーク30に接続して、他グループのサービスプロセッサ(以下、他サービスプロセッサ)20へ障害ログの保存要求、障害ログの保存要求応答、障害ログを送信する。また、他サービスプロセッサ20から障害ログ保存要求、障害ログ保存要求応答、障害ログを受信する。
ここで、障害ログ保存要求とは、監視対象の計算機の障害ログを取得したサービスプロセッサが、他サービスプロセッサへ障害ログの保存を要求する際に送信する信号である。障害ログ保存要求応答とは障害ログ保存要求を受信した他サービスプロセッサが応答の際に送信する信号である。なお、障害ログ、障害ログ保存要求及び障害ログ保存要求応答のデータ構成については、図5、図8を参照して後述する。
状態管理部103は、システム制御部104から負荷率測定要求を受信すると、サービスプロセッサ10の負荷率を測定し、その結果をシステム制御部104へ送信する。ここで、負荷率測定要求とはシステム制御部104が状態管理部103へサービスプロセッサ10の負荷率の測定を要求する際に送信する信号である。また、サービスプロセッサ10の負荷率とは、サービスプロセッサが有するCPUの使用率である。例えば、CPUが計算機105のデータ処理に占有されている場合には、使用率は高く、負荷率は大きいとする。
システム制御部104において、キャッシュ106は障害ログを一時的に保存する。保存要求テーブル107は、サービスプロセッサが障害ログ保存要求を他サービスプロセッサへ送信する順番を登録する。
カウンタ108は、システム制御部104がサービスプロセッサ10の負荷率と負荷率の閾値を比較した回数を記録する。キャッシュテーブル109は、キャッシュ内における計算機105の障害ログの保存状況を管理する。
また、キャッシュテーブル109は当該計算機のIDを保存して当該計算機の障害ログを管理する。なお、保存要求テーブル107、及びキャッシュテーブル109の構成例については、図6、図7を参照して後述する。
システム制御部104は、次の制御を行う。即ち、複数の計算機の制御及び監視すること、計算機105から障害ログを取得すること、取得した障害ログをキャッシュ106に保存すること、通信制御部102を介して他サービスプロセッサから送信された障害ログ、障害ログ保存要求、障害ログ保存要求応答を受信すること、通信制御部102を介して他サービスプロセッサへ障害ログ、障害ログ保存要求、障害ログ保存要求応答を送信すること、状態管理部103へ負荷率測定要求を送信すること、状態管理部103からサービスプロセッサ10の負荷率を受信すること、カウンタ108にサービスプロセッサの負荷率と負荷率の閾値を比較した回数を設定すること、カウンタ108からのサービスプロセッサの負荷率と負荷率の閾値を比較した回数を読み出すこと、保存要求テーブル107から障害ログ保存要求を送信する他サービスプロセッサの決定を行うこと、等の制御を行う。
図5は障害ログのデータパケットの構成例を示す。
データパケットは、通信用ヘッダ部501、計算機ID部502、詳細ログ部503から成る。
通信用ヘッダ部501は、送信先のIPアドレス等の通信に必要な管理情報を格納する。計算機ID部502は、障害が発生した計算機を識別するためのID(識別情報)を格納する。詳細ログ部503は、計算機の障害を特定するためのログを格納する。
例えば、サービスプロセッサ10を例にあげると、システム制御部104は、管轄下の計算機105から障害ログとして計算機ID部502および詳細ログ部503を取得し、同じサービスプロセッサ101内の記憶装置101に、計算機ID部502および詳細ログ部503を障害ログとして保存する。
他サービスプロセッサ20へ障害ログを送信する場合には、自サービスプロセッサ10の通信制御部102で、通信用ヘッダ部501を付加して他サービスプロセッサ20へ送信する。他サービスプロセッサ20の通信制御部202では、受信したデータパケットから通信用ヘッダ部501を取り除き、計算機ID部502および詳細ログ部503をシステム制御部204へ送信して、記憶装置201に保存する。記憶装置201に記憶された障害ログには計算機IDが含まれているので、その障害ログから障害が発生した計算機を容易に特定することができる。
図6は保存要求テーブルの構成例を示す。
保存要求テーブル107には、障害ログ保存要求を複数の他サービスプロセッサへ送信する順番が登録される。この順番は、所定の規則例えば自サービスプロセッサから論理ネットワーク的に近い他サービスプロセッサから順番にするという規則によって予め規定されている。“1”が登録されているサービスプロセッサをスタートとして、“2”、“3”と登録されている順番に、対応するサービスプロセッサへ障害ログ保存要求を送信する。なお、自サービスプロセッサは“0”が登録され、通信先の対象ではないとする。
図7はキャッシュテーブルの構成例を示す。
キャッシュテーブル109は、計算機105ごとにキャッシュ106に障害ログを保存しているか否かを管理する。そのために、計算機IDとフラグを用いて管理する。計算機IDはシステム制御部104が管理対象とする計算機の識別情報(ID)を示し、フラグは障害ログをキャッシュに保存済みか否かを示す。例えば、計算機ID:105−1に対応するフラグが“0”の場合には、当該計算機105−1の障害ログがキャッシュに未保存の状態を示し、計算機ID:105−2のフラグが“1”の場合には、計算機ID105−2の障害ログがキャッシュに保存済みであることを示す。
状態管理部103は、キャッシュテーブル109を参照することで、管轄下の複数の計算機105の障害ログのキャッシュにおける保存状況を知ることができる。
図8は障害ログ保存要求および障害ログ保存要求応答のデータを示す。
障害ログ保存要求および障害ログ保存要求応答のデータは、通信用ヘッダ部801、要求種別部802、データ部803から構成される。通信用ヘッダ部801には、送信元および送信先のIPアドレスが格納される。要求種別部802には、障害ログ保存要求か又は障害ログ保存要求応答かを示すフラグが格納される。例えば、障害ログ保存要求の場合は“0”、障害ログ保存要求応答の場合は“1”とする。データ部803には、障害ログ保存要求の場合は何も格納されておらず、障害ログ保存要求応答の場合は、要求承認または要求拒否を示すフラグが格納される。例えば、要求承認の場合は“0”、要求拒否の場合は“1”とする。
次に、図2A〜2Dのフローチャートを参照して、システム制御部104が計算機105の障害を検知した場合の障害ログを保存する処理動作について説明する。
まず、システム制御部104は、障害を検知した計算機105から障害ログを取得して(S01)、カウンタ108を“0”に設定する(S02)。
その後、状態管理部103へ負荷率測定要求を送信し、状態管理部103からサービスプロセッサ10の負荷率を受信する(S03)。そして、受信した負荷率と、予め設定した負荷率の閾値を比較する(S04)。
比較の結果、負荷率が負荷率の閾値未満の場合には、(図2Bへ移り)記憶装置101の空き容量を測定する(S05)。そして、予め設定した記憶装置101の空き容量の閾値と比較する(S06)。その結果、記憶装置101の空き容量が記憶装置101の空き容量の閾値以上の時には、障害ログを記憶装置101に保存して(S07)、システム制御部104の動作を終了する。一方、ステップS06における比較の結果、記憶装置101の空き容量が閾値未満の時には、S15(図2C)へ移行する。
説明を戻して、ステップS04における比較の結果、負荷率が負荷率の閾値以上の場合には、カウンタ108の値を読み込み、読み込んだ値に“1”を加えた値をカウンタ108に設定する(S08)。カウンタ108に設定した値は、サービスプロセッサの負荷率と負荷率の閾値を比較した回数を示す。
次に、カウンタ108の値と予め設定した比較回数上限値とを比較する(S09)。比較の結果、カウンタ108に設定した値が比較回数上限値と等しい場合はS15(図2C)へ移行する。
また、カウンタ108に設定した値が比較回数上限値未満で、かつカウンタ108に設定した値が“1”である場合には、ステップ10(図2C)へ移行して、キャッシュ106の空き容量を取得し(S10)、キャッシュ106の空き容量の閾値と比較する(S11)。
比較の結果、キャッシュ106の空き容量がキャッシュ106の空き容量の閾値未満の場合はS15へ移行する。一方、キャッシュ106の空き容量がキャッシュ106の空き容量の閾値以上の場合、キャッシュ106に障害ログを保存して(S12)、キャッシュテーブル109における計算機105のフラグを保存済みに設定する(S13)。
その後、予め設定した時間待機して(S14)、再びS03へ移行する。
S15では、保存要求テーブル107より障害ログ保存要求送信先の他サービスプロセッサを決定する。そして、他サービスプロセッサに障害ログ保存を要求するために通信制御部102およびネットワーク90を通して他サービスプロセッサへ障害ログ保存要求を送信する(S16)。その後、他サービスプロセッサから送信された障害ログ保存要求応答を受信する(S17)。
そして、受信した障害ログ保存要求応答を解析して、障害ログ保存の要求が承認されたか拒否されたかを判断する(S18)。判断の結果、障害ログ保存要求が承諾されたと判断した場合、障害ログを通信制御部12へ送信して(S19)、S20へ移行する。一方、要求が拒否されたと判断した場合には、再びS15を繰り返す。
その後、キャッシュテーブル109における計算機105のフラグの値の取得状況を判断する(S20)。その結果、取得したフラグの値が保存済みの場合にはキャッシュ106の障害ログを消去し(S21)、キャッシュテーブル109における計算機105のフラグを未保存に設定する(S22)。一方、取得したフラグの値が未保存の場合には、システム制御部14の動作を終了する。
以上説明した、サービスプロセッサ10のシステム制御部104における計算機105に対する状態監視、障害ログの取得、保存の動作に関して、図1に示すように、サービスプロセッサ10には複数の計算機が接続されているので、上記図2A〜2Dの動作は、サービスプロセッサ10に接続されている全ての計算機105に対して平行して実行される。
次に、図3A〜3Bを参照して、サービスプロセッサ10が他グループのサービスプロセッサ20から障害ログ保存要求を受信した時のシステム制御部104における動作について説明する。
通信制御部102から障害ログ保存要求を受信すると(S31)、状態管理部103へ負荷率測定要求を送信し、状態管理部103からサービスプロセッサ10の負荷率を受信する(S32)。
そして、受信した負荷率と予め設定した負荷率の閾値を比較する(S33)。比較の結果、負荷率が負荷率の閾値以上の場合、S40へ移行する。一方、受信した負荷率が負荷率の閾値未満の場合、記憶装置101の空き容量を測定する(S34)。
その後、測定されたその空き容量と、予め設定した記憶装置101の空き容量の閾値と比較する(S35)。比較の結果、記憶装置101の空き容量が記憶装置101の空き容量の閾値以上の場合、障害ログ保存要求応答のデータパケットにおけるデータ部に要求承諾を設定し(S36)、通信制御部102に障害ログ保存要求応答のデータパケットを送信する(S37)。そして、通信制御部102から障害ログを受信し(S38)、障害ログを記憶装置に保存して(S39)、システム制御部104の動作は終了する。
一方、上記S35の比較の結果、記憶装置101の空き容量が記憶装置101の空き容量の閾値未満の場合、障害ログ保存要求応答のデータパケットにおけるデータ部に要求拒否を設定し(S40)、通信制御部102に障害ログ保存要求応答のデータパケットを送信して(S41)、システム制御部104の動作を終了する。
図4は計算機システムにおける障害ログの保存経路の一例を示す。
複数台の計算機の障害をほぼ同時にサービスプロセッサが検知した場合における障害ログ保存の流れについて説明するものである。ここで、サービスプロセッサ10〜30は図1の構成と同じである。なお、説明の都合上、通信制御部102、202、状態管理部103,203、保存要求テーブル107,207、カウンタ108,208、キャッシュテーブル106,206の図示は省略してある。
今、サービスプロセッサ10が検知した計算機105の障害を検知し、サービスプロセッサ20が計算機205の障害を検知するとし、それらの障害をほぼ同時に検知したと想定する。
サービスプロセッサ10が計算機105−1の障害を検知してその障害ログ110-1を取得した時、サービスプロセッサ10の負荷率は負荷率の閾値未満であり、記憶装置101の空き容量も記憶装置101の閾値以上である場合、障害ログ110-1は障害ログ保存経路P1を通ってサービスプロセッサ10の記憶装置101に保存される。
サービスプロセッサ20が計算機205−1の障害を検知し、障害ログ210-1を取得した場合も同様である。すなわち、サービスプロセッサ20の負荷率が負荷率の閾値未満であり、記憶装置201の空き容量も空き容量の閾値以上であるため、障害ログ210-1は障害ログ保存経路P1を通って、サービスプロセッサ20の記憶装置201に保存される。
その直後に、サービスプロセッサ20が他の計算機205−2の障害を検知し障害ログを取得したとする。その場合、サービスプロセッサ20の負荷率が負荷率の閾値以上あるいは記憶装置201の空き容量が記憶装置201の空き容量の閾値未満であるため、サービスプロセッサ20が保存要求テーブル207に従って、送信先として決定したサービスプロセッサ10へ障害ログ保存要求を送信する。そして、サービスプロセッサ10から障害ログ保存要求応答を受信する。この場合、受信した障害ログ保存要求応答のデータ部は要求承認であるので、他の計算機205−2の障害ログ210-2は、障害ログ保存経路P3に従いサービスプロセッサ10へ送信され、記憶装置101に保存される。
サービスプロセッサ20が計算機205-3の障害を検知した場合も同様である。この場合、サービスプロセッサ10から受信した障害ログ保存要求応答のデータ部が要求拒否であるため、サービスプロセッサ20が新たな送信先として決定したサービスプロセッサ30へ障害ログ保存要求を送信し、サービスプロセッサ30から障害ログ保存要求応答を受信する。受信した障害ログ保存要求応答のデータ部は要求承認であるので、計算機205-3の障害ログ210-3は障害ログ保存経路211-3に従いサービスプロセッサ30へ送信され、記憶装置301に保存される。
サービスプロセッサ10が計算機105-2の障害を検知して障害ログを取得した際、サービスプロセッサ10の負荷率が負荷率の閾値以上であるため、障害ログ110-1は障害ログ保存経路P2を通ってキャッシュ106に保存される。
サービスプロセッサが持つCPUは、データを記憶装置に書き込み読み出しする時にその負荷率が上がることが知られている。本実施例によれば、計算機の障害ログを取得した時に、測定した自サービスプロセッサの負荷率が所定の範囲内(例えば予め定められた負荷率の閾値未満)の場合、(即ち当該サービスプロセッサの負荷率が低い場合)障害ログを自サービスプロセッサの記憶装置に保存し、一方、測定した負荷率が所定の範囲内にない(例えば該閾値以上の)場合(即ち当該サービスプロセッサの負荷率が高い場合)、障害ログをキャッシュに一時的に保存したので、当該サービスプロセッサの負荷を軽減できる。
また、自サービスプロセッサのキャッシュに一時的に保存された障害ログを記憶装置に保存する際に、自サービスプロセッサの負荷率が所定の範囲内にない(即ち高負荷率)場合、他サービスプロセッサの中から負荷率が所定の範囲内にある他サービスプロセッサを選定して、その他サービスプロセッサへ障害ログを送信して他サービスプロセッサ内の記憶装置に保存するようにしたので、自サービスプロセッサにかかる更なる負荷を避け、低負荷の他サービスプロセッサを障害ログの保存のために有効に利用することができる。
一実施例における計算機システムの構成を示す図。 システム制御部の障害監視及び障害ログ取得の動作フローを示す図。 システム制御部の障害監視及び障害ログ取得の動作フローを示す図。 システム制御部の障害監視及び障害ログ取得の動作フローを示す図。 システム制御部の障害監視及び障害ログ取得の動作フローを示す図。 障害ログ保存要求の受信時の動作フローを示す図。 障害ログ保存要求の受信時の動作フローを示す図。 計算機システムにおける障害ログの保存の例を示す図。 障害ログのデータパケットの構成例を示す図。 保存要求テーブルの構成例を示す図。 キャッシュテーブルの構成例を示す図。 障害ログ保存要求および障害ログ保存要求応答データの構成例を示す図。
符号の説明
10、20、30:サービスプロセッサ 90:ネットワーク
105、205、305:計算機
101、201、301:記憶装置 102、202:通信制御部
103、203:状態管理部 104、204:システム制御部
106、206、306:キャッシュ
107、207:保存要求テーブル
108、208:カウンタ
109、209:キャッシュテーブル
110、210:障害ログ
P1、P2,P3,P4:障害ログ保存経路。

Claims (5)

  1. サービスプロセッサによって計算機を監視し、該計算機に発生した障害を検知してその障害のログを管理する障害ログ管理方法において、
    該計算機の障害ログを取得して、前記障害ログを取得した場合における自サービスプロセッサの負荷率を測定し、該負荷率が所定の範囲内にある場合、該障害ログを記憶装置に保存し、
    測定した該負荷率が所定の範囲内にない場合、障害ログをキャッシュに一時的に保存し、
    一定時間経過後、自サービスプロセッサの負荷率を再度測定して、該所定の範囲との関係を調べ、その結果、所定の範囲内になった時、該キャッシュに保存された該障害ログを該記憶装置に保存することを特徴とする障害ログ管理方法。
  2. 複数の計算機を複数のグループに分割し、グループ毎にサービスプロセッサを割り当てて、該サービスプロセッサをネットワークにより接続したシステムにおいて該計算機に発生した障害のログを管理する障害ログ管理方法であって、
    該サービスプロセッサは、該計算機の障害ログを取得して、前記障害ログを取得した場合における自サービスプロセッサの負荷率を測定し、
    該負荷率が所定の範囲内にある場合、該障害ログを該記憶装置に保存し、
    測定した負荷率が該所定の範囲内にない場合、該障害ログをキャッシュに一時的に保存し、
    該キャッシュに一時的に保存された障害ログを該記憶装置に保存する際に、該サービスプロセッサの負荷率が所定の範囲内にあるかを判定し、
    該負荷率が所定の範囲内にない場合、該ネットワークに接続されている他グループの他サービスプロセッサの中から負荷率が所定の範囲内にある他サービスプロセッサを選定し、
    選定された他サービスプロセッサへ該ネットワークを介して障害ログを送信し、
    他サービスプロセッサは、受信した該障害ログを自身の記憶装置に保存することを特徴とする障害ログ管理方法。
  3. 該サービスプロセッサは自身のキャッシュに障害ログを保存する時、キャッシュの空き容量を測定し、
    該キャッシュの空き容量が所定以上の場合は該キャッシュに障害ログを保存し、
    該キャッシュの空き容量が所定以上でない場合は、ネットワークに接続されている他グループの他サービスプロセッサの中から負荷率が所定の範囲内にある他のサービスプロセッサを選定して、選定された該他サービスプロセッサへ障害ログを送信することを特徴とする請求項1又は2の障害ログ管理方法。
  4. 各サービスプロセッサは、他サービスプロセッサへ障害ログの保存を要求する場合、複数の他サービスプロセッサへ該要求を送信する順番を登録した保存要求テーブルを参照して、該要求の送信先となるサービスプロセッサを決めることを特徴とする請求項2又は3の障害ログ管理方法。
  5. 測定した自サービスプロセッサの負荷率と、予め定められた負荷率の閾値と比較し、測定した負荷率が該閾値未満の場合、障害ログを記憶装置に保存し、
    測定した負荷率が該閾値以上の場合、障害ログをキャッシュに一時的に保存することを特徴とする請求項1乃至4のいずれかの障害ログ管理方法。
JP2007279018A 2007-10-26 2007-10-26 障害ログ管理方法 Expired - Fee Related JP4909870B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2007279018A JP4909870B2 (ja) 2007-10-26 2007-10-26 障害ログ管理方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2007279018A JP4909870B2 (ja) 2007-10-26 2007-10-26 障害ログ管理方法

Publications (2)

Publication Number Publication Date
JP2009110078A JP2009110078A (ja) 2009-05-21
JP4909870B2 true JP4909870B2 (ja) 2012-04-04

Family

ID=40778540

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007279018A Expired - Fee Related JP4909870B2 (ja) 2007-10-26 2007-10-26 障害ログ管理方法

Country Status (1)

Country Link
JP (1) JP4909870B2 (ja)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5253353B2 (ja) * 2009-10-26 2013-07-31 株式会社日立製作所 情報処理システム、及びストレージ監視サーバの管理方法
JP5609730B2 (ja) * 2011-03-18 2014-10-22 富士通株式会社 情報処理プログラム及び方法、転送処理装置
JP5689783B2 (ja) * 2011-11-24 2015-03-25 株式会社東芝 コンピュータ、コンピュータシステム、および障害情報管理方法
JP6035909B2 (ja) * 2012-06-29 2016-11-30 富士通株式会社 ストレージシステムおよびストレージシステムの制御方法
JP6652464B2 (ja) * 2016-08-15 2020-02-26 富士通フロンテック株式会社 通信制御プログラム、通信制御装置及び通信制御方法

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4836408B2 (ja) * 2004-03-01 2011-12-14 コニカミノルタビジネステクノロジーズ株式会社 アクセスログ保存システムおよびデジタル複合機
JP4124374B2 (ja) * 2006-06-12 2008-07-23 株式会社日立製作所 記憶システム

Also Published As

Publication number Publication date
JP2009110078A (ja) 2009-05-21

Similar Documents

Publication Publication Date Title
CN109951576B (zh) 用于监视服务的方法、设备和存储介质
US7225356B2 (en) System for managing operational failure occurrences in processing devices
JP4909870B2 (ja) 障害ログ管理方法
US20080126831A1 (en) System and Method for Caching Client Requests to an Application Server Based on the Application Server's Reliability
EP3258653A1 (en) Message pushing method and device
CN107395458B (zh) 系统监控方法及装置
US20180101413A1 (en) Control device and control method
US8589441B1 (en) Information processing system and method for controlling the same
JPWO2008081844A1 (ja) システム障害を精度良く検出する技術
CN107566466A (zh) 负载均衡方法及装置
CN113067875B (zh) 基于微服务网关动态流控的访问方法和装置以及设备
US8555021B1 (en) Systems and methods for automating and tuning storage allocations
KR100823732B1 (ko) 스트리밍 서비스를 위한 컨텐츠 제공 시스템 및 그 방법
CN110661673B (zh) 一种心跳检测的方法及装置
CN108235800B (zh) 一种网络故障探测方法、控制中心设备及计算机存储介质
US9003005B2 (en) Monitoring apparatus, monitoring system, and information setting method
US10698758B2 (en) Data transfer device, data transfer method, and non-transitory computer readable medium
JP2017174038A (ja) 情報処理システム、情報処理方法およびプログラム
JP4595274B2 (ja) 負荷分散方法及び負荷分散装置
WO2015196769A1 (zh) Iptv系统中的数据处理方法及网元设备
CN110752939B (zh) 一种业务进程故障处理方法、通知方法和装置
CN111901421A (zh) 一种数据处理方法及相关设备
JP4002232B2 (ja) プログラム制御方法及び実施装置並びに実施システムと処理プログラム
CN113225225B (zh) 根镜像检测方法、装置、系统、电子设备及存储介质
JP2014197350A (ja) 情報処理装置、情報処理方法及びプログラム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20100119

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20110408

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110426

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110620

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20111220

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20120116

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20150120

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 4909870

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees