JP2009181494A - ジョブ処理システムおよびジョブ情報取得方法 - Google Patents
ジョブ処理システムおよびジョブ情報取得方法 Download PDFInfo
- Publication number
- JP2009181494A JP2009181494A JP2008021956A JP2008021956A JP2009181494A JP 2009181494 A JP2009181494 A JP 2009181494A JP 2008021956 A JP2008021956 A JP 2008021956A JP 2008021956 A JP2008021956 A JP 2008021956A JP 2009181494 A JP2009181494 A JP 2009181494A
- Authority
- JP
- Japan
- Prior art keywords
- job
- processing
- information
- internal information
- server
- 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.)
- Pending
Links
Images
Landscapes
- Debugging And Monitoring (AREA)
Abstract
【課題】ジョブの処理内容が明確でない場合、障害復旧などに不都合が発生することが多い。
【解決手段】まず実機または開発機において、処理内容を特定したいジョブを処理する(S70)。そして各種ログなど、ジョブの進捗に応じたジョブ処理システムの内部の変化を記録した内部情報のうち獲得したい情報に応じた内部情報を、所定の複数のタイミングで取得する(S72)。次に、取得した内部情報から、取得する情報に応じたタイミングの内部情報を2つ抽出し、それらの差分をとる(S74)。2つのタイミングの内部情報の差分から、2つの内部情報を取得した時刻の間隔Tにおけるジョブの処理内容を特定する(S76)。
【選択図】図6
【解決手段】まず実機または開発機において、処理内容を特定したいジョブを処理する(S70)。そして各種ログなど、ジョブの進捗に応じたジョブ処理システムの内部の変化を記録した内部情報のうち獲得したい情報に応じた内部情報を、所定の複数のタイミングで取得する(S72)。次に、取得した内部情報から、取得する情報に応じたタイミングの内部情報を2つ抽出し、それらの差分をとる(S74)。2つのタイミングの内部情報の差分から、2つの内部情報を取得した時刻の間隔Tにおけるジョブの処理内容を特定する(S76)。
【選択図】図6
Description
本発明は情報処理技術に関し、特にバッチ処理されるジョブの情報を取得するジョブ情報取得方法、および当該方法を適用したジョブ処理システムに関する。
近年の情報処理技術の発展およびネットワーク環境の充実化に伴い、様々な情報がネットワークを行き来し、企業、社内の部門など端末に入力された個々のデータを統括管理する組織には、入力された膨大なデータおよび用いるシステムを厳密に管理する技術が必要不可欠となっている。データバックアップ、各種数値算出などデータを管理するための処理やシステムメンテナンスなどは一般的に、毎日、毎月、など定期的に行われるルーチン処理である。そのため、あらかじめ指定した複数のジョブをバッチで処理するように設定しておくことにより、夜間などに自動で行われることが多い。
ジョブをバッチ処理する場合、システムの処理能力、効率性、ジョブ同士の依存関係、優先順位などに基づき、ジョブの処理順序をあらかじめ決定しておく。そして各ジョブの処理内容、すなわちジョブフローとその実行順序とをシステムに登録しておくことにより、基本的には所望の時間に所望の処理が自動で終了していることになる。これにより人件費を削減しつつ、各種処理の効率化が望める(例えば特許文献1)。
特開平5−12037号公報
ジョブのバッチ処理は業種を問わず広く普及しているが、ジョブの設計者とそれを動作させ監視するオペレータや運用者は一般的には異なり、後者にとって、最終的な出力結果を得るために各ジョブがいかなる処理を行っているのかわからないことが多い。また長期間運用をし続けているジョブや多段階でマイナーチェンジを施したジョブなどは、正確なソースコードや設計図が失われていたりして、その詳細な処理内容を把握するのがさらに困難となる。
しかし、異なるOSで動作する新規のシステムで既存のジョブを動作させようとした場合や、ハードディスクやデータベースなどハードウェアの一部を新たにインストールした場合など、ジョブの処理内容が把握できないと作業に支障をきたすことも多い。また、リソースの障害に起因してジョブが正常に動作しなかった場合でも、当該ジョブがそのリソースにアクセスしていることを容易に認識できなければ、ジョブの異常の原因を特定することが難しくなる。
本発明はこうした状況に鑑みてなされたものであり、その目的は、ジョブの処理内容の把握や障害原因の究明を支援することのできるジョブ情報取得技術を提供することにある。
本発明のある態様は、ジョブ処理システムに関する。このジョブ処理システムは、ジョブをバッチ処理するジョブ処理システムであって、ユーザの設定にしたがいジョブを処理するジョブ処理部と、ジョブ処理部におけるジョブの処理期間を含む所定期間中の少なくとも2つの時刻で、ジョブ処理システムの内部情報を取得する内部情報取得部と、内部情報取得部が取得した、2つの時刻における内部情報を比較し、当該内部情報の変化から2つの時刻の間に行われた処理内容を特定する処理内容特定部と、ジョブ処理部において処理されている各ジョブの識別子と、処理内容特定部が特定した各ジョブの処理内容とを対応づけて記憶するジョブ情報記憶部と、を備えたことを特徴とする。
ここで「内部情報」とは、ハードウェアの状態、ファイルの状態、変数の状態、プログラムの進捗度合い、などジョブの処理に応じて変化するジョブ処理システム内のあらゆる構成に係る情報のいずれでもよい。一般的に記録される各種ログの情報でもよい。また「処理内容」とはアクセスしたハードウェア、ハードウェアの空間的、時間的占有率、ファイルやデータベースに対する操作内容など、ジョブがなしたアクションまたはそのアクセス先であればよく、具体的なものでもそれらを統括した概念的なものでもよい。
本発明の別の態様は、ジョブ情報取得方法に関する。このジョブ情報取得方法は、ユーザの設定に従いジョブをバッチ処理するステップと、ジョブの処理期間を含む所定期間中の少なくとも2つの時刻で、ジョブを処理するシステムの内部情報を取得するステップと、2つの時刻における内部情報を比較し、当該内部情報の変化から2つの時刻の間に行われた処理内容を特定するステップと、バッチ処理される各ジョブの識別子と、各ジョブの処理内容とを対応づけて記憶するステップと、を含むことを特徴とする。
なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システムなどの間で変換したものもまた、本発明の態様として有効である。
本発明によれば、ジョブの処理内容の把握や障害原因の究明を効果的に支援することができる。
図1は本実施の形態を適用できるシステムの構成例を示している。同図においてジョブ処理システム10は第1サーバ12、第2サーバ14、第3サーバ16、第4サーバ18の4つのサーバを含む。また第1サーバ12はデータベース20に接続している。ユーザは各サーバの端末などを操作し設定、登録を行うことにより、所望のジョブを所望の時間に処理させる。なお、サーバやデータベースの数、データベースの接続先は図1に示したものに限らず、ジョブを処理できるシステムであればいかなる構成においても本実施の形態を適用できる。また各サーバにさらにクライアント端末などが接続していてもよい。
第1サーバ12、第2サーバ14、第3サーバ16、第4サーバ18はそれぞれ、一以上のCPUとメモリ、記憶装置、入出力装置、表示装置など、あるいはそのいずれかの組み合わせを備えた一般的な情報処理装置であればよく、パーソナルコンピュータ、汎用大型コンピュータなどその規模は限定されない。同図は一例として第1サーバ12がハードディスク13を、第2サーバ14がハードディスク15をそれぞれ備えた構成を示している。また第1サーバ12〜第4サーバ18はネットワーク22に接続され、互いにデータを送受することができる。
ユーザは第1サーバ12、第2サーバ14、第3サーバ16、第4サーバ18のいずれかに対しジョブフロー、バッチ処理時の処理の順序、処理開始時間などの設定を行うことにより、ジョブ処理システム10にジョブを処理させる。ひとつのジョブを第1サーバ12、第2サーバ14、第3サーバ16、第4サーバ18のいずれかひとつのサーバで処理するようにしてもよいし、複数のサーバで処理するようにしてもよい。各ジョブをどのサーバでどのような順序で処理させるか、また、並列に複数のジョブを処理させるかどうかなどは、CPUの処理能力やネットワークの帯域など利用可能なリソースや、データベースへのアクセス順といった処理内容などに鑑み、ユーザが設定を行う。これらの手続きは、ジョブの処理に際し行われる 一般的な手法を用いることができる。
このような構成にあっては、複数のサーバ、データベースなどのハードウェアと、複数のジョブが複雑に連携しあって処理が進捗する。このときあるサーバ、例えば第1サーバ12で処理していたジョブが何らかの障害により停止してしまった場合、その原因が、停止したジョブ自体にある場合もあれば、全く別のところにある場合もある。例えば、停止したジョブの前のジョブが出力した誤ったデータを読み込んだ場合、第2サーバ14におけるジョブ処理でハードディスク15のドライブEの空き容量が不足し書き込みを行えない場合、並列で処理しているジョブとの競合でネットワーク接続にタイムアウトが発生した場合、ハードウェアの故障が生じた場合、などその原因は様々考えられる。一般的には人手によってそれらの要因を逐一検証し、原因を突き止めて問題点を克服し、もう一度ジョブの処理をやり直す必要がある。
原因究明に時間を要すると、予定していた全てのジョブを予定時間に終了させることができなくなり、場合によっては翌日の営業、作業に支障をきたすこともあり得る。このことはシステムの規模が大きくなるほど大きなリスクを生む。例えば第1サーバ12と第2サーバ14とが別の部門で管理されていたり、異なる場所に備えられていたりすると、第1サーバ12が処理していたジョブの異常終了の原因が第2サーバ14の内部にあったとしてもそれを見いだすことは容易でない。原因を究明しているうちに第2サーバ14における問題がそれを管理する部門によって克服されてしまうと、第1サーバ12では結局何が原因でジョブが異常終了したのかがうやむやになってしまう。
益々加速する様々な業務のオンライン化、自動化に伴い、処理するデータの量が膨大となり、システムの規模も大きくなるにつれ、上記のような問題が深刻化し、システム開発者、障害担当者などの負担が増している。そこで本実施の形態では、障害が発生したジョブと関連性のあるジョブを自動で検出し、障害発生の原因の絞り込みを自動化することにより、復旧作業の効率的な支援を行う。このとき関連性の拠り所として、ジョブが利用するリソースに着目する。
処理内容の見地からはジョブ同士に直接的なつながりはなくとも、障害発生の見地からは偶発的に関連性が生じることも多い。そのようなジョブの障害上の関連性は、ジョブの処理順序や処理するデータ量など様々な要因で発生しうるため、あらかじめ予測することが難しい。また障害が発生した後でも対象となるサーバやジョブのログのみでは関連性を見出しにくい。そこで本実施の形態では、リソースを媒介としてジョブ同士を紐づけ、障害上の関連性を見出す。
図2は第1サーバ12の構成をより詳細に示している。第2サーバ14、第3サーバ16、第4サーバ18も同様の構成としてよい。第1サーバ12は、ユーザがジョブフローなどを登録するジョブ登録部32、各ジョブが利用するリソースの情報を抽出する利用リソース情報取得部34、ジョブフローや利用リソース情報を記憶するジョブ情報記憶部42、登録されたジョブを処理するジョブ処理部36、障害発生時にその原因を検出する障害原因検出部38、検出した原因に係る情報を出力する出力部40を含む。
図2において、様々な処理を行う機能ブロックとして記載される各要素は、ハードウェア的には、CPU、メモリ、その他のLSIで構成することができ、ソフトウェア的には、演算やファイル操作、データベースへのアクセスを行うプログラムなどによって実現される。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろな形で実現できることは当業者には理解されるところであり、いずれかに限定されるものではない。
ジョブ登録部32は、ジョブフロー、すなわち各ジョブにおいてなされる処理内容や、バッチ処理における複数のジョブの処理の順序など、ジョブの処理に必要な情報をユーザが登録するためのインターフェースである。ジョブ登録部32は、登録画面を表示した表示装置と、キーボード、ポインティングデバイスなど登録画面に対して入力を行う入力装置との組み合わせなどでよく、ジョブを処理する一般的なシステムで用いられる装置を適用することができる。登録された情報はジョブ情報記憶部42に格納する。
利用リソース情報取得部34は、ジョブ登録部32が登録を受け付けたジョブフローから各ジョブが利用するリソースなどを抽出して、利用リソース情報のテーブルを作成する。利用リソース情報のテーブルは、バッチで処理される各ジョブの名前とそれが利用するリソース、サーバなどを対応づけたテーブルである。ジョブ登録部32がジョブフローのデータを、入出力を行うハードディスク、アクセスするサーバなどのフィールドを有する所定のフォーマットでジョブ情報記憶部42に格納することにより、利用リソース情報取得部34は、当該データの所定のフィールドからサーバ名、利用リソースなどを抽出する。
抽出不能なフォーマットでジョブフローが登録済みの場合やマシンコード化されていてジョブフローが明らかでない場合など、利用リソースの抽出が困難な場合は、各ジョブを実際に処理しながらジョブ処理システム10の各種内部情報を取得することにより利用リソースおよび処理内容を特定する。詳細な手法については後述する。作成した利用リソース情報のテーブルもジョブ情報記憶部42に格納する。
本実施の形態では、各ジョブが利用するリソースに基づき、サーバを超えて障害原因の検出を行う。従って利用リソース情報は、どのサーバでどのジョブが処理されているかに関わらず、ジョブ処理システム10でバッチ処理している全てのジョブについての情報を第1サーバ12、第2サーバ14、第3サーバ16、第4サーバ18間で共有する。そのために、あるサーバで利用リソース情報のテーブルが更新されるたびに、その更新情報を他のサーバに送信して各自が保持する利用リソース情報のテーブルを更新する。あるいは、あるサーバのジョブ情報記憶部42を他のサーバからアクセス可能とすることにより同一の利用リソース情報のテーブルを参照する。
ジョブ処理部36は、ユーザが登録したジョブフロー、ジョブの処理順序などの情報をジョブ情報記憶部42から読み出し、実行する。これはジョブを処理する一般的なシステムで用いられる手法を適用することができる。
障害原因検出部38は障害発生時に、利用リソース情報取得部34が作成した利用リソース情報のテーブルをジョブ情報記憶部42から読み出し、異常となったジョブが利用しているリソース、および当該リソースを利用している他のジョブを抽出する。そして抽出したリソースを備えたサーバや抽出した他のジョブを処理していたサーバの各種ログをもとに障害原因の絞り込みを行う。このとき、原因として複数の現象を検出した場合は、あらかじめ設定した基準により原因である確率も取得する。詳細な手法は後述する。
出力部40は一般的な表示装置やプリンタなどの出力装置でよく、障害原因検出部38が検出した障害原因、あるいは検出した現象とその原因たる確率を出力する。さらに、後述するように利用リソース情報取得部34が、具体的な処理内容が不明のジョブの処理内容を特定した場合に、特定した情報に基づき新たなジョブフローの図を出力する。
次に上記の構成によるジョブ処理システム10の動作について説明する。図3はジョブフローの登録からジョブの処理までの手順を示すフローチャートである。同図は前提として、処理するジョブの利用リソース情報が作成されていない場合を示している。まずユーザは、新規ジョブを処理する場合(S10のY)、第1サーバ12などのジョブ登録部32に対しジョブフローの登録を行う(S12)。このとき必要に応じてジョブの処理順序や処理開始時間などについても登録を行う。
すると利用リソース情報取得部34は、登録されジョブ情報記憶部42に記憶されたジョブフローの情報を参照して利用リソース情報を作成する(S14)。このとき、すでに他のジョブの利用リソース情報のテーブルがジョブ情報記憶部42に格納済みであれば、当該テーブルに追加で書き込む。格納済みでなければ新たにテーブルを作成してジョブ情報記憶部42に格納する。利用リソース情報のテーブルの具体例は後に詳述する。
一方、既にジョブ処理が可能な既存のシステムに本実施の形態を導入した際など、新規のジョブを登録する必要がない場合(S10のN)において、利用リソース情報取得部34が対応できるフォーマットにてジョブフローが登録済みであれば(S18のY)、利用リソース情報取得部34は同様に利用リソース情報を作成する(S14)。一方、登録済みのジョブフローフォーマットが利用リソース情報取得部34の対応可能フォーマットと異なる場合は(S18のN)、そのままでは利用リソース情報を作成できないため、少なくとも1度ジョブを処理してジョブの前後を含む所定のタイミングでジョブ処理システム10の内部情報を取得することによりジョブの処理内容を特定する(S20)。この際のジョブ処理は、開発機でテスト処理として行ってもよいし、実際の運用における処理を利用してもよい。
そして得られた処理内容から利用リソース情報を作成する(S14)。ここで作成したジョブフローは、ジョブの詳細な処理内容が失われている場合などにおいてもそれを確認する手だてとなるとともに、適宜フォーマットの変換を行い別のシステムに当該ジョブを移植することも可能となる。S20の処理内容の特定手法については後に詳述する。
利用リソース情報が作成されたら、S12で登録したジョブ処理の順序や処理の開始時間などに則り、ジョブ処理部36が実機におけるジョブ処理を実行する(S16)。S16のジョブ処理は複数のジョブのバッチ処理でよい。また同図においてS16のジョブ処理には、障害発生によるジョブの異常終了があった際の、障害原因検出部38による原因の検出、出力部40への原因の表示、ユーザによる復旧なども含まれてよい。障害発生時の障害原因検出部38の動作については後に詳述する。
図4は図3のS12において登録されるジョブフローの図の一例を示している。この例のジョブフローは、第1ステップ50および第2ステップ52の2段階の処理によって構成されている。第1ステップ50は、第1サーバ12のハードディスク13のドライブDに格納されたファイルを、シェル54によって同じくドライブDに別名で保存する処理である。同図の例は、前日に作成された入出金明細のファイル「aaa.txt」を、作成された年月日を表す数列「yyyymmdd」を含むファイル名「aaa.txt.yyyymmdd」を有するファイルとして保存する。すなわち入出金明細のバックアップファイルを作成する。
第2ステップは、プログラム56により、第1サーバ12に接続したデータベース20から新たな入出金明細のデータを作成し、第1サーバ12のハードディスク13のドライブDにそのファイルを格納する処理である。同図の例では、第1ステップ50でバックアップを作成しておいたファイル「aaa.txt」を当日分のデータで上書きする。以上の処理を含むジョブを例えば毎日所定の時間に処理することにより、ドライブDには日々の入出金明細のデータがファイル名に日付を含む形で蓄積されていくことになる。
第1ステップにおいて入出金明細のファイル「aaa.txt」をバックアップファイル「aaa.txt.yyyymmdd」として保存するためのシェル54は、ユーザ自身が作成してジョブ情報記憶部42に登録してもよいし、対話式の登録手段を用いてジョブ登録部32が自動で作成してジョブ情報記憶部42に格納してもよい。第2ステップにおいて新たな入出金明細ファイルを作成するプログラム56は、あらかじめ作成しておいたものをジョブ情報記憶部42に格納しておいてもよいし、図示しない他の記憶装置から呼び出してロードするようにしてもよい。
ユーザはジョブ登録部32に対し、図4のようなジョブフローを対話形式で、あるいはスクリプトファイルを自作するなどしてジョブの名前とともに登録する。ジョブ登録部32は登録されたジョブの名前などをファイル名として、各ジョブフローをジョブ情報記憶部42に格納する。以下の説明では、図4で示したジョブの名前を「ジョブA」とする。
図5は利用リソース情報取得部34が作成する利用リソース情報のデータ構造の例を示している。利用リソース情報テーブル100は、ジョブ名欄102、利用サーバ欄104、利用リソース種類欄106、リソース詳細欄108、および備考欄110を含む。前述の通り利用リソース情報取得部34は、新たなジョブフローが登録されるたびに、利用リソース情報テーブル100にエントリを追加していく。また、ジョブフローがない場合はスナップショットの差分により利用リソース情報を取得してエントリを追加する。
ジョブ名欄102には、ユーザが登録を行ったジョブの名前を記載する。利用サーバ欄104にはそれぞれのジョブが利用するリソースが属するサーバの名前を記載する。利用リソース種類欄106には利用するリソースの種類、例えばハードディスク、データベース、LANカードなどを識別する情報を記載する。リソース詳細欄108には、具体的なリソースの識別情報を記載する。備考欄110には当該リソースを利用する際の処理の概要を記載する。
図4で示した「ジョブA」の場合、第1ステップ50では第1サーバ12のハードディスク13のドライブDにアクセスし、入出金明細ファイルのバックアップを作成しているため、図5に示した利用リソース情報テーブル100の3行目において、利用サーバ欄104には「第1サーバ」、利用リソース種類欄106にはハードディスクを示す「DISK」、リソース詳細欄108には「ドライブD」、備考欄110には「バックアップ」と記載されている。また同ジョブは、第2ステップ52において新たに作成した入出金ファイルを同ドライブDに格納しているため、備考欄110にはさらに「入出金明細作成」と記載されている。
また「ジョブA」は、第2ステップ52において新たなファイルを作成する際、第1サーバ12に接続したデータベース20を参照しているため、利用リソース情報テーブル100の2行目において、利用サーバ欄104には「第1サーバ」、利用リソース種類欄106にはデータベースへのアクセスを示す「DBMS」、リソース詳細欄108には「データベース」、備考欄110には「データ参照」と記載されている。図5に示された「ジョブB」、「ジョブZ」も同様の記載がなされている。
利用リソース情報のデータ構造は図5に示したものに限らない。例えばCPU使用率、ハードディスクの利用率、データベースを参照するのみか更新するかを識別する情報などを記録してもよい。さらに、利用するリソースごとに利用頻度を記録してもよい。CPU使用率やハードディスクの利用率など、ジョブフローから特定が困難なパラメータは、開発機や実機において実際にジョブを処理した際の各パラメータの変化量や実績を取得することによって得ることができる。このような詳細な記録を利用リソース情報に含めるほど原因検出の精度が向上する。
次に、図3のS20においてジョブの処理内容を特定する手法について説明する。図6は、利用リソース情報取得部34が実際のジョブ処理によって処理内容を特定する処理手順を示すフローチャートである。まず実機または開発機において対象となるジョブを処理する(S70)。これは利用リソース情報取得部34がジョブ処理部36を制御して処理を開始させてもよいし、通常の運用ベースで当該ジョブの処理が開始したことを利用リソース情報取得部34が検知するようにしてもよい。
そして、ドライブログ、ジョブログ、OSのauditログ、Oracle(登録商標)のRedoログなど、ジョブの進捗に応じたジョブ処理システム10の内部の変化を記録した内部情報のうち獲得したい情報に応じた内部情報を、所定の複数のタイミングで取得する(S72)。これにはOracleのスナップショットなどの機能を利用することができる。取得するタイミングは、ジョブ処理の開始直前、開始直後、ログに何らかの書き込みが行われた時点、ジョブ処理の終了直前、終了直後などから、取得する情報に応じて適宜設定しておく。また所定の時間間隔で取得するようにしてもよい。
次に、取得した内部情報から、取得する情報に応じたタイミングの内部情報を2つ抽出し、それらの差分をとる(S74)。2つの内部情報を取得した時刻の間隔をTとすると、先に取得した内部情報に時間Tの間の処理を加えたものが後の内部情報になっている。これを利用して、2つのタイミングの内部情報の差分から、時間Tにおけるジョブの処理内容を特定する(S76)。具体的には、データベースやファイルが作成されたか読み出されたか更新されたか削除されたか、を示すCRUD(Create, Read, Update, Delete)などを取得する。
図7は図4で示したジョブA処理時の3つのタイミングにおけるジョブログの例を示している。同図では時刻の早い順に、時刻t=t0におけるジョブログ60、時刻t=t1におけるジョブログ62、時刻t=t2におけるジョブログ64を並べて示している。例えばこれらを内部情報として取得すると、ジョブログ62とジョブログ60との差分から、時刻t0からt1の間に1つのファイルがコピーされていることがわかる。またジョブログ64とジョブログ62との差分から、時刻t1から時刻t2の間に入出金明細のファイルが作成されていることがわかる。
さらに、ジョブログに何らかの書き込みが行われた都度、ドライブDやデータベース20のログを取得するようにすれば、その差分から時刻t0からt1の間にファイル「aaa.txt.yyyymmdd」が生成されていることがわかり、当該ファイルが第1ステップのコピー先であることが判明する。同様に、時刻t1からt2の間にファイル「aaa.txt」が更新されていることがわかり、当該ファイルが生成された入出金明細であることがわかる。同時にデータベース20が参照されていることがわかる。
さらに、ファイル読み出しや書き込みなどの処理に対するタイムスタンプ、ファイルのサイズ、誤り検出で一般的に用いられるチェックサムなどのファイルの付加情報を取得することにより、2つのファイルの同一性等を判定すれば、ファイルの関係を把握することもできる。例えばファイル「aaa.txt」およびファイル「aaa.txt.yyyymmdd」のサイズやチェックサムが同一であれば、これらのファイルは同一のファイルのコピー元、コピー先であると判定でき、時刻t0からt1の間で「aaa.txt」バックアップ処理がなされたことを特定できる。
あるいは、一般的に用いられるファイルの名付けルールに基づき、ファイル名に含まれやすい文字列、数列をあらかじめ用意しておき、処理されたファイルの名前にそれらの文字列、数列が含まれているか否かを解析するようにしてもよい。例えば「aaa.txt.yyyymmdd」に含まれる「yyyymmdd」は、実際には「20071107」などという数字が充てられるが、これが日付であることを数列の構成から判断する。日付の他に、追い番などでも同様である。すると、ファイル名「aaa.txt」とファイル名「aaa.txt.yyyymmdd」とを比較したとき、後者は前者のファイル名に日付を付加したものであるため、後者が前者をコピーしたファイルである確率が高くなる。
このように、スナップショットの差分、ファイルの付加情報、ファイル名の特徴などにより多角的に判断を行うことにより、各ジョブがどのリソース、ファイルに対しどのような操作を行ったかを特定できるため、それをもとに図4で示したようなジョブフローおよび図5で示したような利用リソース情報を作成することができる。ジョブフローの図はあらかじめ規定したフォーマットに得られた情報を代入していくことで、ユーザの出力指示に従い出力部40が出力する。
運用ベースでジョブの処理を行う場合、複数のジョブが並列に処理されており、かつジョブログに更新内容が出力されないことが考えられる。このような状況でのジョブの処理を利用してジョブフロー、利用リソース情報を作成する場合、必要な情報が得られにくい場合がある。例えばCPU使用率などは、並列で処理されているジョブがある場合にはどのジョブでCPUを使用しているのか区別が困難となる。このように、どのジョブがどのようにリソースを利用したか特定が困難な場合は、対象のジョブが処理される別の機会に情報の取得を何度か試みることによりサンプリング回数を増加させる。
その結果、対象のジョブが単独で処理されるタイミングが発生すれば、当該ジョブについての情報を取得することができる。またあらかじめサンプリング回数に上限を設定しおき、上限に達するまで利用リソース情報を作成することができない場合は、ユーザにその旨を通知してもよい。これによりユーザは当該ジョブを単独で処理して、ジョブ処理システム10に利用リソース情報を作成させるなどの方策を立てることができる。
またサンプリング回数の上限に達した際は、利用リソース情報取得部34がジョブ処理部36を制御して、対象のジョブ以外のジョブを一旦停止させ、その間に対象のジョブのスナップショット等を取得するようにしてもよい。この場合、停止時間をジョブの処理時間の一部の時間とし、停止時間を徐々にずらして何度もサンプリングを行うことにより、最終的に対象ジョブの全貌を把握できるようにする。これにより他のジョブの処理完了が遅延するなど運用上の影響を最小限にすることができる。
上述のとおり、本実施の形態では実際にジョブを処理することにより、その処理内容をジョブフローの形式で自動的に取得することができる。これにより、利用リソース情報の作成が可能となるほか、ジョブフローが明確でなかったり設計書やソースコードが現存しないジョブの処理内容の詳細を特定することができる。このようなことを目的とする場合、利用リソース情報が必要でなければ図3の利用リソース情報作成処理(S14)やその後のジョブ処理(S16)を省略してよい。そして特定した処理内容を、図4で示したようなジョブフロー図に適宜落とし込み、出力部40において出力することにより、処理内容をユーザが把握できるようにする。
次に利用リソース情報を利用して障害原因を検出する手法について説明する。図8は本実施の形態における障害発生時の処理手順を示す。同図は、第1サーバ12において「ジョブB」の処理を行い、第2サーバ14において「ジョブZ」の処理を行った場合を示している。ここで「ジョブB」は図5の利用リソース情報テーブル100における「ジョブB」に対応し、「ジョブZ」は同利用リソース情報テーブル100における「ジョブZ」に対応している。すなわち「ジョブB」は第1サーバ12のハードディスク13のドライブDを参照し、第2サーバ14のドライブEへファイルの送信を行う。また「ジョブZ」は第2サーバ14のハードディスク15のドライブEにファイルの書き込みを行う。
第1サーバ12のジョブ処理部36および第2サーバ14のジョブ処理部36においてこのようなジョブの処理をそれぞれ開始した状態で(S30、S32)、第2サーバ14のハードディスク15のドライブEの格納データがディスクの容量に達した「フル」の状態になり、エラーログに出力されたとする(S34)。一方、その後のあるタイミングで第1サーバ12の「ジョブB」が異常終了したとする(S36)。このとき第1サーバ12の障害原因検出部38は原因検出処理を次のように実行する。まず、ジョブ情報記憶部42に格納した利用リソース情報テーブル100を参照して、ジョブBが利用するリソースを特定する(S38)。その結果、ジョブBは第1サーバ12のハードディスク13のドライブDを参照し、第2サーバ14のハードディスク15のドライブEにデータ送信を行っていることが判明する。
次に障害原因検出部38は、第1サーバ12、第2サーバ14、第3サーバ16、第4サーバ18の全サーバのエラーログを参照する(S40)。エラーログは第1サーバ12〜第4サーバ18で常時共有できるようにそれらのシステムがアクセス可能なメモリ(図示せず)などに格納するようにしてもよいし、必要に応じて他のサーバに要求信号を送信することにより取得してもよい。その結果、第2サーバ14のドライブEのディスクが「フル」の状態であることを検出する。そして利用リソース情報およびエラーログに基づき障害原因を検出する(S42)。上記の例ではジョブBがドライブEにデータ送信を行うこと、ドライブEが「フル」の状態であることに基づき、ドライブEを障害原因として検出する。
利用リソース情報を参照すれば、まずドライブD、ドライブEに原因を求めることができるため、S40の処理は該当するサーバあるいはハードディスクのエラーログのみを取得して参照するようにしてもよい。またエラーの収集方法は、エラーログ以外のログを利用してもよいし、ジョブ処理部36で動作しているジョブスケジューラが直接取得するようにしてもよい。障害原因はジョブBの異常終了が発生した時点より前にあるため、リソースによる紐づけを利用して、その時点から時間を遡るようにエラーログを逆読みしていくことにより、効率のよい原因検出を実現できる。
次に出力部40は、障害原因検出部38が検出した原因についての情報を取得し、表示装置に表示したりプリンタに出力したりすることにより、運用オペレータへ通知する(S44)。あるいはネットワークを介して接続した表示装置に表示して障害担当者に通知したり、電子メールを自動送信したりする。
上記のようなシンプルな例ではドライブEの「フル」状態が原因であると推定できるが、実際には細かい異変を含めエラーが記録されているリソースが複数あり、それらをジョブBが利用しているために、複数のエラーが障害原因として検出される場合も考えられる。そのような場合に備え、エラーの内容ごとにジョブの障害原因である確率をあらかじめ設定しておく。確率として設定する数値は、それまでの経験値や開発機によるテスト結果などに基づき決定してもよいし、そのエラーが影響する範囲などを考慮して理論的に決定してもよい。具体例は後述する。
そして障害原因検出部38は、障害原因として検出された全エラーの、原因である確率の設定値を取得し、出力部40は、それらを一覧として出力するようにしてもよい。また、過去の障害事例のデータを蓄積しておき、今回障害原因として検出された全エラーのうち、過去にもジョブBの異常終了と同時期に発生しているエラーを抽出し、その発生頻度からジョブBの異常終了との関連性を推測してもよい。この場合も、検出されたエラーと、その関連の強さを示す指数とを対応づけて一覧として出力する。
上述の例では、ジョブの利用リソース情報とリソースのエラーとを関連づけて、障害の直接的な原因となっているリソースを検出したが、ドライブの監視を行っていない場合など、リソースのエラーログに直接的な原因が記録されていない場合もある。このような場合に備え、障害原因検出部38は、他のジョブの異常についての情報をさらに取得してもよい。そして利用リソース情報テーブル100を参照し、同じリソースを利用しているジョブに異常が発生している場合は、当該リソースに原因がある可能性ありと判断し、原因である確率を、あらかじめ設定した値、例えば「50%」などと表示してもよい。
また、異常となったジョブと同一のリソースAを利用しているジョブが別のリソースBも利用しており、リソースBが根本の障害原因である可能性もある。さらにリソースBを利用しているまた別のジョブがさらに別のリソースCを利用しており当該リソースCが根本の障害原因である可能性もある。本実施の形態では、利用リソース情報によってそのようなリソースを介したジョブ同士のつながりを順次辿り、ログとの突き合わせをおこなうことにより、そのような間接的な障害原因を全て検出することが可能となる。
運用オペレータや障害担当者は、出力部40が出力した障害の原因に基づき障害対応を適宜行う(S46)。例えば原因である確率が高いエラーの順に、そのエラーとジョブBの異常終了との因果関係を検証していき、原因を絞ったところでその復旧作業を行う。それによりジョブBの処理が再開される(S48)。
図8のような状態においては一般的には、第2サーバ14で発生した障害と第1サーバ12で発生した障害とを紐づける手段をもたないことから、第1サーバ12の運用オペレータは第1サーバ12で発生したジョブBの異常終了のみを障害担当者に連絡する。それにより第1サーバ12で発生した障害の原因究明に手間取ることが多い。また、原因を究明しているうちに第2サーバ14においてハードディスク15のドライブEが復旧し(S50)、ジョブZの処理が再開してしまうと(S52)、障害担当者は原因を把握することができない。さらに各システムの障害担当者が、基盤障害担当者とアプリケーション障害担当者に別れている場合、ディスクフルの障害は基盤障害担当者に通知され、ジョブBの障害はアプリケーション障害担当者に通知されてしまい、それらの連携が益々困難となることも多い。
一方、本実施の形態では、第1サーバ12で処理するジョブBと、第2サーバ14におけるリソースであるドライブEとを自動的に紐づけ、障害発生時にはその紐づけをたどって自動的に障害原因を検出することができる。これにより、障害対応において頻繁に発生している上記のような問題を容易に克服することができる。
利用リソース情報とエラーログとから、異常終了したジョブが利用するリソースがエラーを発生させていたとしても、利用の仕方がそのエラーの影響の及ぶ範囲外であれば障害原因から除外することができる。図9はこのような点を考慮したうえで、各エラーに対して設定される障害原因である確率の例を示している。原因確率テーブル120は、エラー内容欄122、影響欄124、および確率欄126を含む。エラー内容欄122に記載された各エラー内容に対し、それによる影響が影響欄124に、そのエラーが原因である確率が確率欄126に記録される。原因確率テーブル120は、あらかじめジョブ情報記憶部42に格納しておく。障害原因検出部38は図8のS42において障害原因となりうるエラーを検出したあと、原因確率テーブル120を参照して、検出したエラーの障害原因である確率を取得する。
例えばエラー内容が、あるドライブの「ディスクフル」の場合、その影響として当該ドライブへの書き込みが不可となる。このようなエラーが記録されているドライブへの書き込みを行っているジョブが異常終了した場合、障害原因検出部38はまず影響欄124に記録されている影響と異常終了したジョブが当該ドライブに対し行っている処理内容とが合致することを確認し、確率欄126から当該エラーが原因である確率を「80%」と特定する。
ジョブの処理内容は、利用リソース情報テーブル100の備考欄110における記載を参照できる。あるいは原因確率テーブル120の影響欄124における記載と対応がとれるように、利用リソース情報テーブル100に詳細な処理内容を記載する欄を別に設けてもよい。異常終了したジョブが、「ディスクフル」のエラーが発生しているドライブにアクセスするジョブであっても、図9に示すようにそのエラーが及ぼす影響が当該ドライブへの書き込み不可のみであるなら、当該ドライブを参照するのみのジョブの障害原因からは除外することができる。このように、利用リソース情報テーブル100に、各ジョブのリソースに対する処理内容を詳細に記録するほど、障害原因の絞り込みの精度が向上する。
エラー内容が「LANカード不調」の場合は、例えば当該LANカードを備えたサーバ内の全リソースを、他のサーバから利用することができなくなる。また当該LANカードを備えたサーバからデータベースサーバへのアクセスが不可となる。従って、異常終了したジョブがそのようなリソースへのアクセスを行っているか否かを利用リソース情報テーブル100を参照して確認したうえ、行っている場合は当該エラーが原因である確率をそれぞれ「70%」とする。エラー内容が「ネットワーク輻輳」の場合も同様に、当該エラーが原因である確率をそれぞれ「40%」とする。
確率欄126に設定する、各エラーが原因である確率は、理論的に算出してもよいし、開発機でのテスト結果や実機での経験値を採用してもよい。図9において「LANカード不調」のエラーより「ネットワーク輻輳」のエラーの方が原因となる確率が低いのは、TCP/IPの機能により通信が自動的にリトライされることにより、エラー状態の持続時間が短いためである。また図9に示した影響欄124の記載は、実際にはさらに詳細化し、処理によって細分化してもよい。例えば、利用リソース情報に各ジョブのCPU使用率、ハードディスクの利用率、データベースを参照するのみか更新するかを識別する情報、リソースを利用する頻度などを記録した場合、それらの値に応じて設定する確率を変化させるようにしてもよい。原因確率テーブル120は、まず各サーバに共通の汎用的なものを用意しておき、個々の運用形態によってユーザがカスタマイズできるようにしてもよい。
上述した、「各エラーが原因である確率」は、「そのエラーがジョブの処理に影響を及ぼす確率」と捉えることもできる。すなわち、確率欄126に記録された数値が高いエラーが起きた場合、そのエラーが後のジョブに異常をもたらす確率が高いと考えられる。この性質を利用して、障害原因検出部38は、エラー内容欄122に記載されるようなエラーが発生する都度、原因確率テーブル120を参照し、対応する確率欄126に記録された数値が高ければ、関連するジョブを前もって停止させるようにしてもよい。具体的には、エラーが発生したリソースを利用するジョブを利用リソース情報テーブル100から抽出し、抽出したジョブのいずれかが開始される予定であればジョブ処理部36に通知しそれを停止させる。あるいは処理中のジョブを中断する。図8の例では、S34において第2サーバ14にディスクフルのエラーが発生しているため、第1サーバ12のジョブBをその段階で中断する。
以上述べた本実施の形態によれば、ユーザが登録したジョブフローから、ジョブ処理システムにおてい処理されるジョブとそのジョブが利用するリソースとを対応づけた利用リソース情報を自動で取得し記憶しておく。そしてジョブ処理時に、あるジョブに異常が発生した場合、利用リソース情報を参照して当該ジョブが利用しているリソース、および同リソースを利用している他のジョブなど、リソースに基づく関連性を取得し、関連性のあるリソースやジョブなどのログを参照することにより、障害原因を効率的に検出できる。
また利用リソース情報は、実際にジョブを処理した際の各ログのスナップショットなど内部情報の差分によっても取得する。このとき、データサイズ、タイムスタンプ、チェックサムなどファイルの付加情報も多角的に考慮することにより、各ジョブがどのリソースを利用してどのようなファイル操作を行ったのかを特定する。これにより、ジョブフローの登録フォーマットが異なる装置へ本実施の形態を容易に適用することができるとともに、ジョブのソースコードや設計図が失われている場合でもジョブフローの形式で処理内容を把握でき、当該ジョブ自体を異なる開発言語の別のシステムへ移植することも可能となる。例えば、ホストのJCL(Job Control Language)を、UNIX(登録商標)のシェルに自動変換することも可能となる。
障害原因の検出にあたっては、ジョブが異常となった時刻から、利用するリソースに基づきログを遡るように参照していくことにより、原因検出の効率性が増す。また、あらかじめエラーとして記録され得る要因ごとに、当該要因が障害原因となる確率を設定しておくことにより、例えば複数の要因が障害原因として検出された場合でもその確率をユーザに提示することができ、ユーザによる原因検証の作業、ひいては障害復旧の作業を効率化できる。
本実施の形態は、このように検出した障害原因、あるいはその候補を、明確に出力するため、障害原因究明のスキルを持たないオペレータも、その後の対処が容易となる。また別の部署、場所のサーバに因果関係があったとしても、当該関係を即座に把握することができる。結果として、分業が進み個々人で全貌を把握することが困難な昨今の巨大化したシステムにおいても、サーバ、部署、担当などの垣根を越えて自動で障害原因を検出することができ、復旧までの時間短縮、効率化を実現できる。
さらに本実施の形態は、スナップショットやログ取得など、情報処理装置やデータベースで一般的に提供されている機能をそのまま利用して実現することができるため、新たなハードウェアを導入するなどのコストを必要とせず、容易に実現することができる。
以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
例えば、本実施の形態ではあるジョブが異常終了した場合に、利用リソース情報に基づき、そのジョブと他のリソースまたはジョブとの関連性を取得し、障害原因を検出したが、同様の処理により、ジョブ処理完了が遅延した際にその因果関係を検出することができる。例えば、あるジョブAの完了が予定時刻より遅延した場合、ジョブAより前に処理された別のジョブBの処理が遅れ、結果としてジョブAの開始時刻が遅延したことで完了時刻も遅延する場合がある。ジョブAが、直接的、あるいは間接的にジョブBの出力結果を受けてなされる処理である場合などがこれにあたる。
このような場合、ジョブAとジョブBとが異なるサーバで処理される場合などは特に、ジョブAの完了遅延の原因をジョブBに求めることは、一般的には困難である。障害原因の究明と同様に、ジョブ処理システムに含まれるサーバの数が増大するほど原因の究明が難しくなる。これはジョブ同士の依存関係や前後関係を、全サーバを網羅して把握することが困難になることに起因する。そこで本実施の形態と同様に、ジョブの処理の完了が遅延した際、利用リソース情報を参照して同一のリソースを利用しているジョブを検出することによりジョブ同士の関連性を見出す。
そして関連性のあるジョブのうち以前に処理されていてかつ処理完了が遅延しているジョブを各サーバのログから検出する。場合によってはこの操作を繰り返すことにより、利用リソースによって紐づけられたジョブを順次辿っていき、最終的に根本の原因となったジョブを特定する。あるいは逆に、処理完了が遅延した際、利用リソース情報を参照し、これから処理されるジョブのうち、遅延の影響を受けるであろうジョブを利用リソースに基づき抽出し、前もって警告するようにしてもよい。
これらの処理も、本実施の形態における各サーバの障害原因検出部38が、各サーバのログやジョブ情報記憶部42に記憶されたジョブの処理順序などを参照して該当ジョブを抽出していく。そして原因と考えられるジョブや、影響を受けるジョブの情報を出力部40が出力する。出力手法はウェブ画面表示や電子メール送信など一般的な手法を用いることができる。
これによりユーザは、遅延の影響の及ぶ範囲が最小限となるようにジョブ処理の順序を最適化したり、影響を受けると予測されるジョブを手動で動作させたり、といった対策をとることができる。ジョブのバッチ処理は一般的に、営業開始時刻より前に完了していなければならないなど、全体的な完了時刻の厳守が求められる場合が多く、ジョブ処理遅延に対するこのような効果は特に有意義である。所定時刻に必ず完了していなければならないジョブをあらかじめ設定しておき、該当ジョブが遅延すると予測される場合は特に重大な警告としてその他のジョブと区別するように出力してもよい。
10 ジョブ処理システム、12 第1サーバ、 13 ハードディスク、 14 第2サーバ、 20 データベース、 32 ジョブ登録部、 34 利用リソース情報取得部、 36 ジョブ処理部、 38 障害原因検出部、 40 出力部、 42 ジョブ情報記憶部。
Claims (9)
- ジョブをバッチ処理するジョブ処理システムであって、
ユーザの設定にしたがいジョブを処理するジョブ処理部と、
前記ジョブ処理部におけるジョブの処理期間を含む所定期間中の少なくとも2つの時刻で、前記ジョブ処理システムの内部情報を取得する内部情報取得部と、
前記内部情報取得部が取得した、2つの時刻における内部情報を比較し、当該内部情報の変化から前記2つの時刻の間に行われた処理内容を特定する処理内容特定部と、
前記ジョブ処理部において処理されている各ジョブの識別子と、前記処理内容特定部が特定した各ジョブの処理内容とを対応づけて記憶するジョブ情報記憶部と、
を備えたことを特徴とするジョブ処理システム。 - 前記内部情報取得部は、ジョブの処理前および処理後における、前記ジョブ処理システムに備えられたハードディスクの状態を示す情報、ジョブログ、監査ログの少なくともいずれかを取得することを特徴とする請求項1に記載のジョブ処理システム。
- 前記処理内容特定部は、前記処理内容として、各ジョブが利用する前記ジョブ処理システム内のリソースに係る情報を特定することを特徴とする請求項1または2に記載のジョブ処理システム。
- 前記処理内容特定部は、前記処理内容として、各ジョブがアクセスするハードディスクおよびデータベースの識別情報、ファイルおよびデータベースが作成されたか読み出されたか更新されたか削除されたか、を示すCRUDの少なくともいずれかを特定することを特徴とする請求項1または2に記載のジョブ処理システム。
- 前記ジョブ処理部が並列に複数のジョブを処理しているとき、前記内部情報取得部は、前記ジョブ処理部に、一のジョブ以外のジョブを所定時間停止させ、その間に少なくとも1つの時刻における内部情報を取得し、
前記処理内容特定部は、当該1つの時刻における内部情報を含む2つの時刻における内部情報に基づき、前記一のジョブの処理内容を特定することを特徴とする請求項1から3のいずれかに記載のジョブ処理システム。 - 前記内部情報取得部は、前記ジョブ処理システムにおいて記録される所定のログに書き込みが行われる都度、前記内部情報を取得することを特徴とする請求項1に記載のジョブ処理システム。
- 前記処理内容特定部が特定した各ジョブの処理内容をジョブフロー図として出力する出力部をさらに備えたことを特徴とする請求項1に記載のジョブ処理システム。
- ユーザの設定に従いジョブをバッチ処理するステップと、
ジョブの処理期間を含む所定期間中の少なくとも2つの時刻で、ジョブを処理するシステムの内部情報を取得するステップと、
2つの時刻における内部情報を比較し、当該内部情報の変化から前記2つの時刻の間に行われた処理内容を特定するステップと、
バッチ処理される各ジョブの識別子と、各ジョブの処理内容とを対応づけて記憶するステップと、
を含むことを特徴とするジョブ情報取得方法。 - 特定した各ジョブの処理内容をジョブフロー図として出力するステップをさらに含むことを特徴とする請求項8に記載のジョブ情報取得方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2008021956A JP2009181494A (ja) | 2008-01-31 | 2008-01-31 | ジョブ処理システムおよびジョブ情報取得方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2008021956A JP2009181494A (ja) | 2008-01-31 | 2008-01-31 | ジョブ処理システムおよびジョブ情報取得方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2009181494A true JP2009181494A (ja) | 2009-08-13 |
Family
ID=41035396
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2008021956A Pending JP2009181494A (ja) | 2008-01-31 | 2008-01-31 | ジョブ処理システムおよびジョブ情報取得方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2009181494A (ja) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2015145652A1 (ja) * | 2014-03-27 | 2015-10-01 | 株式会社日立製作所 | 管理装置および管理方法 |
JP2016051422A (ja) * | 2014-09-02 | 2016-04-11 | ルネサスエレクトロニクス株式会社 | 自己診断方法、コンパイル装置及びコンパイラ |
US10042671B2 (en) | 2015-12-15 | 2018-08-07 | Fujitsu Limited | Non-transitory computer-readable storage medium, control device, and control method |
-
2008
- 2008-01-31 JP JP2008021956A patent/JP2009181494A/ja active Pending
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2015145652A1 (ja) * | 2014-03-27 | 2015-10-01 | 株式会社日立製作所 | 管理装置および管理方法 |
US9697049B2 (en) | 2014-03-27 | 2017-07-04 | Hitachi, Ltd. | Job scheduling apparatus and method based on island execution time |
JP2016051422A (ja) * | 2014-09-02 | 2016-04-11 | ルネサスエレクトロニクス株式会社 | 自己診断方法、コンパイル装置及びコンパイラ |
US10042671B2 (en) | 2015-12-15 | 2018-08-07 | Fujitsu Limited | Non-transitory computer-readable storage medium, control device, and control method |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10419546B2 (en) | Migration assessment for cloud computing platforms | |
US10810074B2 (en) | Unified error monitoring, alerting, and debugging of distributed systems | |
US11514317B2 (en) | Machine learning based resource availability prediction | |
US11669507B2 (en) | Indexing and relaying data to hot storage | |
CN107818431B (zh) | 一种提供订单轨迹数据的方法和系统 | |
JP6260130B2 (ja) | ジョブ遅延検知方法、情報処理装置、およびプログラム | |
US20160224400A1 (en) | Automatic root cause analysis for distributed business transaction | |
US20150142764A1 (en) | Language tag management on international data storage | |
US10528456B2 (en) | Determining idle testing periods | |
US10977108B2 (en) | Influence range specifying method, influence range specifying apparatus, and storage medium | |
JP5007247B2 (ja) | ジョブ処理システムおよびジョブ管理方法 | |
JP5989194B1 (ja) | テスト管理システムおよびプログラム | |
JP4928480B2 (ja) | ジョブ処理システムおよびジョブ管理方法 | |
JP6252309B2 (ja) | 監視漏れ特定処理プログラム,監視漏れ特定処理方法及び監視漏れ特定処理装置 | |
US5826104A (en) | Batch program status via tape data set information for dynamically determining the real time status of a batch program running in a main frame computer system | |
CN112559525B (zh) | 数据检查系统、方法、装置和服务器 | |
JP2009181494A (ja) | ジョブ処理システムおよびジョブ情報取得方法 | |
US20220164703A1 (en) | Model acceptance determination support system and model acceptance determination support method | |
CN115982049A (zh) | 性能测试中的异常检测方法、装置和计算机设备 | |
JP5231035B2 (ja) | ジョブ処理システムおよびジョブ処理方法 | |
JP2003345628A (ja) | 障害調査資料採取方法及びその実施システム並びにその処理プログラム | |
CN117421337B (zh) | 数据采集方法、装置、设备及计算机可读介质 | |
CN116069770A (zh) | 针对检核对象的检核方法、设备以及计算机可读存储介质 | |
CN115756575A (zh) | 一种提交记录获取方法、装置、设备及存储介质 | |
JP2016091429A (ja) | 情報処理システムおよび制御方法 |