(57)【要約】【課題】  資料を採取する際、システム全体の処理に悪影響を与えずに、資料採取までの待ち時間を短縮することができる資料採取サーバ等を提供する。【解決手段】  資料採取サーバ２００は、資料に関する資料情報および資料採取サーバ２００が実行する業務アプリケーションに関する情報を含む基準情報を記憶する基準情報記憶部２０２と、基準情報および資料採取サーバ２００の業務アプリケーション稼動状況を取得し、基準情報および業務アプリケーションの稼動状況に基づいて、資料採取処理の実行可否および資料採取処理の最短開始タイミングを判断する制御部２０１と、制御部２０１の判断に従って、資料採取処理の実行を開始する採取部２０３とを備える。【選択図】      図８
2019139566.tif 000002
【特許請求の範囲】
【請求項１】
外部からの指示に基づき、自らが有する資料を採取する処理の実行を制御する資料採取サーバであって、
前記資料に関する資料情報および前記資料採取サーバが実行する業務アプリケーションに関する情報を含む基準情報を記憶する基準情報記憶手段と、
前記基準情報および前記資料採取サーバの業務アプリケーション稼動状況を取得し、前記基準情報および前記業務アプリケーションの稼動状況に基づいて、前記処理の実行可否および前記処理の最短開始タイミングを判断する制御手段と、
前記制御手段の前記判断に従って、前記資料採取処理の実行を開始する採取手段と、
を備える資料採取サーバ。
【請求項２】
前記制御手段は、前記業務アプリケーションが稼動中である場合、前記基準情報に含まれる優先度を基に、前記業務アプリケーションを中止するか否かを判断する
請求項１記載の資料採取サーバ。
【請求項３】
前記制御手段は、前記業務アプリケーションが稼動中である場合、前記基準情報に含まれる、前記処理に必要なハードウェア負荷が前記資料採取サーバのハードウェア許容負荷以下の場合に、前記業務アプリケーションを中止させて前記処理を実行することを判断する
請求項１記載の資料採取サーバ。
【請求項４】
前記制御手段は、前記業務アプリケーションが稼動中であり、前記基準情報に含まれる、前記処理に必要なハードウェア負荷が前記資料採取サーバのハードウェア許容負荷以下の場合に、実行中の少なくとも１つの前記業務アプリケーションを中止させて前記ハードウェア許容負荷を増加させ、当該増加の結果、前記処理に必要なハードウェア負荷が前記資料採取サーバのハードウェア許容負荷以下となった場合に、前記業務アプリケーションを中止させて前記処理を実行することを判断する
請求項１または請求項３に記載の資料採取サーバ。
【請求項５】
請求項１乃至請求項４のいずれか一項に記載の資料採取サーバと、
前記基準情報の設定を行い、前記資料サーバの前記基準情報記憶手段に記憶させる、前記外部であるクライアント端末
とを備える資料採取システム。
【請求項６】
外部からの指示に基づき、資料採取サーバが有する資料を採取する処理の実行を制御する資料採取方法であって、
前記資料に関する資料情報および前記資料採取サーバが実行する業務アプリケーションに関する情報を含む基準情報を記憶する基準情報記憶手段から、前記基準情報を取得し、前記資料採取サーバの業務アプリケーション稼動状況を取得し、前記基準情報および前記業務アプリケーションの稼動状況に基づいて、前記処理の実行可否および前記処理の最短開始タイミングを判断し、
前記判断に従って、前記処理の実行を開始する
資料採取方法。
【請求項７】
外部からの指示に基づき、資料採取サーバが有する資料を採取する処理の実行を制御することをコンピュータに実行させるための資料採取プログラムであって、
前記資料に関する資料情報および前記資料採取サーバが実行する業務アプリケーションに関する情報を含む基準情報を記憶する基準情報記憶手段から、前記基準情報を取得し、前記資料採取サーバの業務アプリケーション稼動状況を取得し、前記基準情報および前記業務アプリケーションの稼動状況に基づいて、前記処理の実行可否および前記処理の最短開始タイミングを判断し、
前記判断に従って、前記処理の実行を開始する
資料採取プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、業務に関連する資料等の情報を採取するための資料採取サーバ等に関する。
【背景技術】
【０００２】
一般的に、サーバの稼働状況や障害内容等に関する様々な情報を収集するため、監視用のクライアント端末により、そのサーバからイベントログやエラーログ等のログデータを含む様々な資料を採取することが行われている。
【０００３】
例えば、ユーザが人手操作によって資料採取対象のサーバを指定すると、指定サーバから自動的に所定の資料を採取し、採取した資料を所定のフォーマットに変換して、サポートセンタに自動送信する技術がある。
【０００４】
資料の採取は、クライアントからのリクエストに応じて、サーバ上で動作する資料採取用プログラムが、資料の収集及び転送等の資料採取処理を行うことによって実現される。この資料採取用プログラムが動作すると、サーバのＣＰＵ、ハードディスク及びネットワーク等には、一定の負荷がかかる。このため、サーバが提供するサービスの提供時間外、例えば週末や深夜までユーザが待機し、その時間に資料採取を指示せざるを得ないという問題があった。
【０００５】
この問題を解決するために、ユーザによって資料採取が指示されたとき、当該資料採取がサーバの安定運用の支障とならないように、障害情報を採取する対象であるサーバ（以下、対象サーバとも称呼する）の負荷状況をクライアント端末側で判定して、採取のタイミングを計る技術が開示されている（特許文献１参照）。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１４−０５９６１７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
特許文献１に記載の技術では、資料採取のタイミングを計るための所定の待機時間をオペレータが任意に設定する。よって、クライアント端末側は、短い待機時間で資料採取できる場合もあれば、負荷状況が採取可能になるまで長時間待機せねばならぬ場合も有る。このため、資料採取の取得タイミングが計りかね、障害の分析に想定外の時間を要する場合がある。
【０００８】
本発明は、上記問題点に鑑みてなされたものであり、サーバから資料を採取する際、システム全体の処理に悪影響を与えずに、資料採取までの待ち時間を短縮することができる資料採取システム等を提供することを目的とする。
【課題を解決するための手段】
【０００９】
上記の課題を解決するために、本発明の第１の観点に係る資料採取サーバは、
外部からの指示に基づき、自らが有する資料を採取する処理の実行を制御する資料採取サーバであって、
前記資料に関する資料情報および前記資料採取サーバが実行する業務アプリケーションに関する情報を含む基準情報を記憶する基準情報記憶手段と、
前記基準情報および前記資料採取サーバの業務アプリケーション稼動状況を取得し、前記基準情報および前記業務アプリケーションの稼動状況に基づいて、前記処理の実行可否および前記処理の最短開始タイミングを判断する制御手段と、
前記制御手段の前記判断に従って、前記資料採取処理の実行を開始する採取手段と、を備える。
【００１０】
本発明の第２の観点に係る資料採取方法は、
外部からの指示に基づき、資料採取サーバが有する資料を採取する処理の実行を制御する資料採取方法であって、
前記資料に関する資料情報および前記資料採取サーバが実行する業務アプリケーションに関する情報を含む基準情報を記憶する基準情報記憶手段から、前記基準情報を取得し、前記資料採取サーバの業務アプリケーション稼動状況を取得し、前記基準情報および前記業務アプリケーションの稼動状況に基づいて、前記処理の実行可否および前記処理の最短開始タイミングを判断し、
前記判断に従って、前記処理の実行を開始する
ことを備える。
【００１１】
本発明の第３の観点に係る課題推定プログラムは、
外部からの指示に基づき、資料採取サーバが有する資料を採取する処理の実行を制御することをコンピュータに実行させるための資料採取プログラムであって、
前記資料に関する資料情報および前記資料採取サーバが実行する業務アプリケーションに関する情報を含む基準情報を記憶する基準情報記憶手段から、前記基準情報を取得し、前記資料採取サーバの業務アプリケーション稼動状況を取得し、前記基準情報および前記業務アプリケーションの稼動状況に基づいて、前記処理の実行可否および前記処理の最短開始タイミングを判断し、
前記判断に従って、前記処理の実行を開始する
ことを備える。尚、プログラムは非一時的な記録媒体に格納されていてもよい。
【発明の効果】
【００１２】
本発明によると、サーバから資料を採取する際、システム全体の処理に悪影響を与えずに、資料採取までの待ち時間を短縮することができる資料採取システム等を提供することができる。
【図面の簡単な説明】
【００１３】
【図１】本発明の第１の実施形態にかかる資料採取システムの構成を示す図である。
【図２】基準情報記憶部に格納される資料情報の一例を示す図である。
【図３】基準情報記憶部に格納される業務情報の一例を示す図である。
【図４】本発明の実施の形態における資料採取システムの事前に基準情報を設定又は変更する動作を示すフローチャートである。
【図５】本発明の実施の形態における資料採取システムの業務中止の可否に従い、資料を採取又は採取しない動作を示すフローチャートである。
【図６】本発明の実施の形態における資料採取システムの業務抑制の可否に従い、資料を採取又は採取しない動作を示すフローチャートである。
【図７】本発明の実施の形態における資料採取システムの業務優先度等に従い、資料を採取または採取しない動作を示すフローチャートである。
【図８】本発明の第２の実施形態にかかる資料採取サーバの構成を示す図である。
【図９】各実施形態において適用可能な情報処理装置の構成例を示すブロック図である。
【発明を実施するための形態】
【００１４】
特許文献１に記載の技術では、障害調査を実施する技術者が、障害調査に必要なログ情報や障害に関するデータを含む資料を、顧客または顧客システムを担当する保守員から素早く提出してもらえない場合があり、それが障害の復旧完了までに時間を要する原因となることがあった。資料採取は資料の取得とも言う。これは、顧客側システムの稼働中には、保守員が資料採取の作業ができないことなどが原因であった。即ち、特許文献１の技術では、資料採取の条件さえ揃えば素早く自動的に資料採取が実行されるが、その反面、条件が揃うまでの間は資料採取の実行までの待ち時間が長くなるという問題がある。
【００１５】
そこで本発明の各実施形態においては、資料採取の即時性（最短開始タイミング）又は待ち時間短縮を追求した。顧客システムの対象サーバ（顧客サーバ）において業務のためのアプリケーション（以下、業務アプリケーションとも称呼する）が動作していても、一時停止しても構わない業務アプリケーションであり、かつ、資料採取が短時間で完了するのであれば、一時的に業務アプリケーションの動作を停めても、顧客のシステム全体として大きな支障はない。また、特許文献１に記載の技術においては、資料採取の対象サーバの負荷が高い場合は、資料採取をすぐに実行できない。しかし、これも業務アプリケーションの優先度によっては（例えば、優先度が低い場合は）、当該業務アプリケーションに対するＣＰＵ等のハードウェアリソースの割り当てを一時的に制限することで資料採取の対象サーバの負荷を意図的に一定期間下げ、その間に資料採取を完了させることができる。尚、業務アプリケーションのうち、動作を継続させるべき優先度の高い業務アプリケーションや、更には、最優先させるべき業務アプリケーションが動作中のときは、資料採取を実行してはならない場合もある。そのような場合は、その業務アプリケーションが動作停止するまで資料採取を待つようにする。
【００１６】
上記を具体的に説明すると、３つの案にまとめられる。第一に、顧客サーバ側において一定時間業務を停めて、資料採取を先に実行してしまう方法である。これは、資料採取が短時間で完了する場合と判断される場合に有効である。事前準備として、クライアントや顧客システムのオペレータに資料の種類を予めリスト化させ、更にこれらリスト化された資料のうち、どの資料の採取であれば一旦業務を中止し資料採取を実施させてもよいかを予め設定させる。実際に資料採取が必要になった時は、当該設定により、一定時間業務を中止してもよい設定されていた場合には、作業員は対象サーバにより資料採取を実行する。この際、対象サーバ（以下、対象サーバＡとも記載する）は、一定期間業務を中止する旨をクライアントやオペレータの端末のモニタ等に表示させ、更に、この表示において一定時間業務を停止することの許可をクライアントから再度得ても良い。尚、資料採取完了後、業務アプリケーションは自動的に再開される。
【００１７】
第二に、顧客システムの負荷があがらないように実行中の業務アプリケーションのハードウェアリソースを制御（抑制）する方法である。即ち、対象サーバにおける業務アプリケーション実行のためのハードウェア負荷が高ければ、対象サーバＡは資料採取の間は当該負荷を意図的に下げ、業務アプリケーション実行と平行して、資料採取を行う。事前準備として、実行を制御しても構わない業務アプリケーションをクライアントやオペレータの操作により予め選択させておく。実際に資料採取が必要になった際は、対象サーバＡは稼働中の業務アプリケーションの負荷が閾値より高いか否かを判断し、高いと判断された場合には、クライアントやオペレータ等のモニタに業務アプリケーション実行の制御を行う旨を表示する。この表示の際に、対象サーバＡはアプリケーション実行の制御を行うことへの許可を再度クライアントから得ても良い。表示後または許可を得られた場合には、対象サーバＡは当該業務アプリケーションの実行を抑制して、システムのハードウェア負荷を下げ、資料採取を実行する。尚、資料採取完了後、業務アプリケーションのハードウェア負荷は自動的に基に戻される。
【００１８】
第三に、顧客システムの対象サーバ上で動いている業務アプリケーションのうち、どの業務アプリケーションが実行中かにより、資料採取を実行するかしないかを指定する方法である。これは、クライアント毎に業務の重要度が異なる場合があるからである。このように対象サーバＡはクライアントに応じて、業務アプリケーションに含まれる業務アプリケーション毎に優先順位付けした上で、資料採取が実行可か否かを指定可能に設計される。即ち、対象サーバＡは、ハードウェアリソースのみに注目して負荷状況の判断をするのではなく、業務アプリケーションごとに優先順位を付ける。また、顧客の業務アプリケーションに限らず、他のアプリケーションソフトウェアを、資料採取を実行するか否かを判断するための基準として加えてもよい。事前準備として、資料採取を実行したくない業務アプリケーションを予めクライアントに指定させておく。資料採取が必要になった時、資料採取を実施してはいけない業務アプリケーションの動作中は、対象サーバＡは資料採取を実行せずに当該業務アプリケーションの終了まで待機し、それ以外の業務タスクの動作中は、資料採取を直ちに実施する。
【００１９】
以下、図面を参照して、本発明の各実施形態を説明する。以下の図面の記載において、同一又は類似の部分には同一又は類似の符号を付している。ただし、図面は本発明の実施形態における構成を概略的に表している。更に以下に記載される本発明の実施形態は一例であり、その本質を同一とする範囲において適宜変更可能である。
【００２０】
以下、本発明を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。
＜第１の実施形態＞
（資料採取システム）
本発明の第１の実施形態に係る資料採取システム１００の構成について、図１を参照して説明する。
【００２１】
資料採取システム１００は、対象サーバ１およびクライアント端末２を備える。対象サーバ１は、障害発生時等において資料採取の対象となるサーバである。クライアント端末２は、当該資料採取に関する様々な命令を、対象サーバ１に対して送信し、対象サーバ１がこの命令を実行する。対象サーバ１とクライアント端末２とは、有線又は無線の通信線によって通信可能に接続される。
【００２２】
ここで、対象サーバ１、クライアント端末２は、それぞれ、プログラムを格納した図示しない記憶装置と、記憶装置からプログラムを読み出して実行する中央制御装置とを少なくとも有するコンピュータである。詳細については後述する。
【００２３】
（対象サーバ）
対象サーバ１は、図１に示すように、制御部１１、基準情報記憶部１２、採取部１３、実行部１４および資料記憶部１５を含む。
【００２４】
資料記憶部１５は、障害発生時、資料更新時等に取得すべき資料を格納する。資料とは、典型的には対象サーバ１のイベントログやエラーログ等のログ情報、及び対象サーバ１の稼働状況や障害内容等の調査に資する様々なデータである。また、資料は、調査目的以外の様々な目的のために採取される、いかなるデータであっても良い。
【００２５】
基準情報記憶部１２は、資料に関する資料情報および対象サーバが実行する業務アプリケーションに関する業務情報を含む基準情報を記憶する。基準情報は、例えば、資料情報１２ａ（図２参照）、業務情報１２ｂ（図３参照）、および、業務アプリケーションの停止又は抑制等を判断するための閾値を含む。閾値はハードウェア許容負荷を含んでも良い。
【００２６】
資料情報１２ａは、各資料とそのＣＰＵ使用率を紐付けた情報である。この情報に、業務アプリケーションの停止又は抑制等を判断するための閾値を加えたり、業務アプリケーションの停止又は抑制を示すフラグ（記号）を加えても良い。
【００２７】
業務情報１２ｂは、各業務に関連する情報の集合であり、例えば図３に示すように、「業務ＩＤ (IDentifier)」、「業務優先度」、「最低保障ＣＰＵ使用率」、「１時間の平均ＣＰＵ使用率」を項目とするレコードを備える。「業務ＩＤ」とは、各業務アプリケーションを一意に特定可能な識別子である。「業務優先度」とは、その業務アプリケーションの優先度を表わす情報である。「最低保証ＣＰＵ使用率」とは、ある業務アプリケーションを実行するにあたり最低限必要なＣＰＵの使用率である。「１時間の平均ＣＰＵ使用率」とは、ある業務アプリケーションを実行するに際し、一時間あたり平均して使用されているＣＰＵの使用率である。
【００２８】
制御部１１は、基準情報および対象サーバの業務アプリケーション稼動状況を取得し、基準情報および業務アプリケーションの稼動状況に基づいて、資料採取のための処理の実行可否および処理の最短開始タイミングを判断する。
【００２９】
更に、制御部１１は、業務アプリケーションが稼動中である場合、基準情報に含まれる優先度を基に、業務アプリケーションを中止するか否かを判断する。更に、制御部１１は、業務アプリケーションが稼動中である場合、基準情報に含まれる、資料採取処理に必要なハードウェア負荷が対象サーバ１のハードウェア許容負荷（アイドル使用量）以下の場合に、前記業務アプリケーションを中止させて資料採取処理を実行することを判断する。更に、制御部１１は、業務アプリケーションが稼動中であり、基準情報に含まれる、資料採取処理に必要なハードウェア負荷が対象サーバ１のハードウェア許容負荷以下の場合に、実行中の少なくとも１つの業務アプリケーションを中止させてハードウェア許容負荷（アイドル使用量）を増加させ、当該増加の結果、資料採取処理に必要なハードウェア負荷が対象サーバ１のハードウェア許容負荷以下となった場合に、業務アプリケーションを中止させて資料採取処理を実行することを判断する。
【００３０】
具体的に、制御部１１は、基準情報を基に、業務中止の可否、業務抑制の可否、および、業務の中止又は抑制が可能な業務アプリケーションであるかを判断し、資料採取を実行する。
【００３１】
業務中止の可否とは、対象サーバ１が行う業務のうち、資料採取のために一旦業務を中止してもよい資料であるか否かという意味である。逆に、業務を中止してはならない資料を特定しても良い。
【００３２】
業務抑制の可否とは、対象サーバ１が行う業務のうち、資料採取のために一定期間業務を抑制してもよい資料であるか否かという意味である。逆に、業務を抑制してはならない資料を特定しても良い。ここで抑制とは、例えば、ある業務アプリケーションの実行に必要なハードウェアリソースの使用率を下げることを指す。
【００３３】
業務の中止又は抑制が可能な業務アプリケーションとは、対象サーバ１が実行する業務アプリケーションのうち、資料採取のために一時実行を中止または抑制してもよい業務アプリケーションであるかという意味である。逆に、中止または抑制ができない業務アプリケーションを特定してもよい。
【００３４】
基準情報は、各業務または各資料に紐付けられて予め基準情報記憶部１２に格納されている。基準情報の設定に際しては、例えば、クライアント端末２の指示部２１を介し、クライアントに、全資料の基準情報を予め決定させる。または、設計エンジニア、保守員側の端末からの指示で予め基準情報記憶部１２に初期値を設定しておき、必要に応じて、クライアントが、クライアント端末２の指示部２１を介し、基準情報を調整可能に構成してもよい。
【００３５】
資料採取が必要になった時には、クライアント等が、クライアント端末２の指示部２１を介し、資料採取のリクエストを制御部１１に送信する。
【００３６】
制御部１１は、資料採取のリクエストを受けると、業務中止の可否を判断する。具体的に、制御部１１は、業務情報１２ｂ内のアイドルのリソース量（図３の１時間の平均ＣＰＵ使用率）を参照する。制御部１１は、採取する資料のＣＰＵ使用率がアイドル（未使用中）のリソース量以下であれば、業務中止せずとも資料採取可能と判断し、即時に資料を採取する。例えば、図３に示す業務情報１２ｂによるとアイドル５％である。よって、制御部１１は、図２に示す資料情報１２ａ中ＣＰＵ使用率５％以下の資料（即ち、資料ａ、資料ｃ）は業務中止せずとも資料採取可能と判断する。
【００３７】
採取する資料のＣＰＵ使用率がアイドルのリソース量より大きなＣＰＵ使用率である（業務中止が必要な）場合について考える。クライアント等がクライアント端末２の指示部２１を介し、図２中の資料ｂを採取するよう制御部１１に指示する。制御部１１は図２中の資料ｂのＣＰＵ使用率と、図３の業務情報１２ｂ内の業務ＩＤ「アイドル」の１時間の平均ＣＰＵ使用率を比較する。この場合、資料ｂのＣＰＵ使用率（１０％）より、アイドルの１時間の平均ＣＰＵ使用率（５％）のほうが大きい。よって、制御部１１は、業務中止が必要と判断し、業務情報１２ｂに含まれる業務毎の業務優先度をチェックする。チェックの結果、制御部１１は、優先度の低い業務から順に実行を中止して、採取に必要なＣＰＵリソースを確保する。例えば、業務情報１２ｂ内の業務Ｄは業務優先度が「低」、かつ、一時間の平均ＣＰＵ使用率が「１５％」であるため、業務Ｄの使用を停止し、資料採取を実行する。
【００３８】
尚、業務Ｄの一時間の平均ＣＰＵ使用率は「１５％」であり、資料ｂの採取に必要なＣＰＵ使用率は、１０％−５％（アイドル）＝５％であるため、業務Ｄを中止せずとも、ハードウェアリソースの使用を抑制することで、資料ｂを採取するのに必要なＣＰＵ使用率を得ることもできる。この場合、制御部１１は、業務Ｄの一時間の平均ＣＰＵ使用率を５％程度抑制し、１０％の空きＣＰＵリソースを確保する。ＣＰＵリソースの確保後、制御部１１は、採取部１３に、資料記憶部１５から資料ｂを採取するように指示する。
【００３９】
業務情報１２ｂ中の業務優先度が同じだった場合、例えば、業務優先度「低」の業務が複数ある場合は、先ず最低保証ＣＰＵ使用率の値同士を比較して、当該値が小さいものからからＣＰＵ使用率を抑制するようにする。即ち、最初の抑制で採取に必要なＣＰＵリソースが確保できれば、資料採取を実行し、これでもなお採取に必要なＣＰＵリソースが不足する場合は、最低保証ＣＰＵ使用率の値が次に小さいもののＣＰＵ使用率（１時間の平均ＣＰＵ使用率）を抑制する。このようにして、必要なＣＰＵリソースが確保できた時点で、制御部１１は、資料採取を実行する。
【００４０】
次に、業務アプリケーションの抑制が可能か否かの判断について説明する。事前準備として、制御部１１は、基準情報として、抑制したくない業務に対しては、実際に必要なＣＰＵ利用率よりも大きな最低保証ＣＰＵ利用率を、抑制してもよい業務に対しては、実際に必要なＣＰＵ利用率よりも小さな最低保証ＣＰＵ利用率を予め設定しておく。制御部１１は、図３に示す業務情報１２ｂ中の業務Ｄ（業務ＩＤ＝Ｄ）は、最低保証ＣＰＵ使用率が０％であるため、該当業務の抑制が可能であると判断する。制御部１１は、業務Ｂ（業務ＩＤ＝Ｂ）は、最低保証ＣＰＵ使用率が４０％であるため、該当業務の抑制は不可能であると判断する。最低保証ＣＰＵ使用率に所定の閾値を予め設定し、制御部１１は、当該閾値以上の最低保証ＣＰＵ使用率であれば業務の抑制は不可能、それ以下の最低保証ＣＰＵ使用率であれば業務の抑制は可能と判断してもよい。または、制御部１１は、業務優先度に従って、業務の抑制が可能か否かを判断しても良い（例えば、業務優先度「高」なら抑制不可能、それ以外の業務優先度であれば抑制可能）。尚、業務の抑制のみならず、業務の中止においても同様に所定の閾値を設け、制御部１１が、当該閾値を超えるか否かで中止すべきか否かを判断してもよい。
【００４１】
より厳格に、業務を「抑制させない」ことを実行したい場合は、業務情報１２ｂ内の業務優先度に性能抑制の可否の項目（例えば、「抑制可」、「抑制不可」）や、各業務アプリケーションの稼働状態（例えば、「稼動中」、「非稼働中」）を示す項目を追加する。これにより、性能抑制「抑制不可」かつ稼動状態「稼働中」の場合には、制御部１１が業務アプリケーションを抑制しないように設定する。
【００４２】
制御部１１は、業務の中止又は抑制が可能な業務アプリケーションか否かを判断する際に、業務情報１２ｂ内の業務優先度を参照し、業務優先度が高い業務アプリケーションは、資料採取のための業務中止又は抑制をしてはならないと判断してもよい。
【００４３】
尚、各業務の性能を外から抑制するための手段は、ＡＰＩ（アプリケーションプログラミングインタフェース）として準備しておく。ＡＰＩには、例えば次のようなものが考えられる。
（イ）実行中業務アプリケーション一時停止関数
実行中の業務アプリケーションを一時停止する機能を有する。
（ロ）実行中業務アプリケーション再開関数
上記の実行中業務アプリケーションを一時停止させたときに、再開させる機能を有する。
（ハ）実行中業務アプリケーション抑制関数
ここでいう抑制する対象は、様々なものが考えられるが、例えばＣＰＵ使用率、メモリ使用量、ディスク転送帯域、ネットワーク帯域など、他の指標であってもよいし、それらを組み合わせてもよい。当該関数において指定した指標をOS（オペレーティングシステム）の機能により抑制してもよい。
（ニ）実行中業務アプリケーション抑制解除関数
上記の実行中業務アプリケーション抑制関数において、抑制を行ったとき、業務を元に戻し再開させる機能を有する。
【００４４】
（クライアント端末）
クライアント端末２は、指示部２１を含む。
【００４５】
指示部２１は、対象サーバ１の制御部１１と通信して、現在の基準情報を取得する処理、基準情報の設定又は変更を指示する処理、及び資料採取処理の実行又は中止を指示する処理を行う。また、指示部２１は、ユーザによる上記指示の入力を受け付ける処理も行う。
【００４６】
（資料採取システムの動作）
本発明の第１の実施形態に係る資料採取システム１００の動作について説明する。
【００４７】
資料採取システム１００の動作としては、大まかに、（１）事前に基準情報を設定又は変更する動作と、（２）基準情報に基づいて資料採取処理を実行する動作とに分けられる。更に（２）の動作は、１）業務中止の可否に従い、資料を採取又は採取しない動作と、２）業務抑制の可否に従い、資料を採取又は採取しない動作と、３）業務優先度等に従い、資料を採取または採取しない動作とを備える。以下、これらの機能についてフローチャートを参照しつつ順に説明する。尚、（２）の１）、２）、３）の動作は、所定に順序に従い時間差で実行しても良いし、全ての動作を並列的に実行してもよい。
【００４８】
（１）基準情報を設定又は変更する動作
図２のフローチャートは、指示部２１と制御部１１とが通信して、基準情報記憶部１２に基準情報を設定又は設定された基準情報を変更する処理を示している。
【００４９】
まず、ステップＳ１０１において、クライアント端末２の指示部２１は、現在の基準情報をユーザに対して表示する。具体的には、クライアント端末２において指示部２１が起動されると、指示部２１は、現在の基準情報を取得し、クライアント端末２の図示しない表示装置上に表示する。基準情報が複数ある場合は、それら複数の基準情報を表示できる。ユーザは、図示しない入出力装置により、この基準情報を編集することができる。
【００５０】
ここで、現在の基準情報は、前回の本機能の実行時に設定又は変更された基準情報を指示部２１が記憶している場合、記憶している基準情報を取得して表示できる。また、初回起動時など前回設定又は変更された基準情報を記憶していない場合は、制御部１１に対して現在の基準情報の送信を要求し、制御部１１から受信した基準情報を表示できる。後者の場合、制御部１１は、指示部２１からの要求に応じ、基準情報記憶部１２から現在の基準情報を全て取得し、指示部２１に対し送信できる。
【００５１】
ステップＳ１０２において、指示部２１は、現在の基準情報を設定又は変更するための入力を、図示しないユーザ側の入力装置を介して、受け付ける。ここで入力装置とは、キーボード、マウス、ボタン、音声入力等を指す。
【００５２】
例えば、指示部２１は、ユーザによる入力に応じ、基準情報を変更することができる。基準情報は資料採取処理（詳細は後述する）の実行又は中止の判断に使用される。
【００５３】
また、指示部２１は、ユーザによる入力に応じ、リスト等として表示される資料の追加、更新、削除を行うことができるように設定されていても良い。
【００５４】
ステップＳ１０３において、指示部２１は、基準情報の設定又は変更を決定する。具体的に、指示部２１は、所定のトリガ、例えばユーザによる「決定」ボタンの押下等に応じて、ステップＳ１０２における設定又は変更の内容を確定する。すなわち、基準情報の設定又は変更内容をＳ１０４の処理に引き渡す。
【００５５】
ステップＳ１０４において、指示部２１は、基準情報を対象サーバ１に対し送信する。具体的に、指示部２１は、ステップＳ１０３において確定した基準情報の設定又は変更内容を、対象サーバ１の制御部１１に対して送信する。ここで、指示部２１は、基準情報の設定又は変更内容として、設定または変更された基準情報のみを送信しても良く、その基準情報の設定又は変更された部分だけを送信しても良く、又は全ての基準情報を送信しても良い。
【００５６】
ステップＳ１０５において、対象サーバ１の制御部１１は、上記基準情報を受信する。上記基準情報とは、基準情報の設定又は変更内容を指す。
【００５７】
ステップＳ１０６において、制御部１１は、基準情報を登録する。具体的に、制御部１１は、ステップＳ１０５において受信した基準情報の設定又は変更内容を、基準情報記憶部１２に登録する。これにより、基準情報記憶部１２が保持する基準情報が更新される。
【００５８】
（２）基準情報に基づいて資料採取処理を実行する動作
以下、図５、図６、図７のフローチャートを参照して、１）業務優先度等に従い資料を採取または採取しない動作、２）業務中止の可否に従い資料を採取又は採取しない動作、および、３）業務抑制の可否に従い資料を採取又は採取しない動作について説明する。
【００５９】
先ず、１）業務優先度等に従い資料を採取又は採取しない動作について、図５のフローチャートを参照して説明する。
【００６０】
ステップＳ２０１において、制御部１１は、クライアント端末２より、１つまたは複数の資料を採取したいとのリクエストを受けると、基準情報記憶部１２から基準情報（資料情報１２ａおよび業務情報１２ｂ）を取得する。
【００６１】
ステップＳ２０２において、制御部１１は、稼働中の業務アプリケーションが有るかを判断する。具体的に、制御部１１は、実行部１４に稼動中の業務アプリケーションについて問い合わせる。または、業務情報１２ｂ内に、各業務アプリケーションが稼動中か否かのフラグを立てても良い。稼働中の業務アプリケーションが有る場合処理はステップＳ２０３に進められ、稼働中の業務アプリケーションが無い場合には処理はステップＳ２０５に進められる。
【００６２】
ステップＳ２０３において、制御部１１は、稼働中の業務アプリケーションを確認する。具体的には、当該業務アプリケーションのＩＤ等を実行部１４から取得する。または、業務情報１２ｂ内の各業務アプリケーションが稼動中か否かのフラグを参照し、稼働中の業務アプリケーションを確認する。
【００６３】
ステップＳ２０４において、制御部１１は、稼動中の業務アプリケーションが、資料採取のために中止しても良いものか否かを判断する。具体的に、制御部１１は、実行中の業務アプリケーションが優先度「高」（図３参照）のものである場合、資料採取のため業務中止は行わないと判断し、それ以外の優先度である場合、資料採取のため業務中止をすると判断する。業務中止を行うと判断されると処理はステップＳ２０５に進められ、業務中止は行わないと判断されると本処理は終了する。尚、終了した場合、資料採取は、実行中の業務アプリケーションが終了するまで待機となる。
【００６４】
ステップＳ２０５において、制御部１１は採取部１３に資料記憶部１５から対象となる資料を採取するよう指示する。採取部１３はこの指示に従い、資料記憶部１５から対象となる資料を採取し、制御部１１に引き渡す。
【００６５】
以上で１）業務優先度等に従い資料を採取又は採取しない動作を終了する。
【００６６】
次に、２）業務中止の可否に従い資料を採取又は採取しない動作について、図６のフローチャートを参照して説明する。
【００６７】
まずステップＳ３０１〜ステップＳ３０３については、図５のＳ２０１〜ステップＳ２０３と同様である。尚、ステップＳ３０２で稼働中の業務アプリケーション無しと判断された場合、処理はステップＳ３１１の資料採取処理に進められる。
【００６８】
ステップＳ３０４において、制御部１１は、ステップＳ３０１で取得した採取をリクエストされた１つまたは複数の資料および基準情報（資料情報１２ａおよび業務情報１２ｂ）を基に、対象となる資料取得のために現在実行中の業務アプリケーションを中止するべきか否かを判断する。具体的に、制御部１１は、業務情報１２ｂ内のアイドルのリソース量（図３の１時間の平均ＣＰＵ使用率）を参照し、採取する資料のＣＰＵ使用率がアイドルのリソース量以下であれば、資料採取できると判断し、これに該当しなければ資料を採取できないと判断する。資料採取できると判断されると処理はステップＳ３０５に進められ、資料を採取できないと判断されると本処理は終了する。
【００６９】
ステップＳ３０５においては、制御部１１は、中止する業務を確認する。例えば図２の例では、資料ａおよび資料ｃを中止すると確認する。
【００７０】
ステップＳ３０６において、制御部１１は実行中の業務アプリケーションを中止するよう実行部１４に指示する。実行部１４は当該指示に従い、当該業務を一時中止する。
【００７１】
ステップＳ３０７において、制御部１１は、採取すべき資料が資料記憶部１５にあるか確認するよう採取部１３に指示する。採取部１３は当該指示に従い、採取すべき資料（資料ａおよび資料ｃ）が資料記憶部１５に格納されていることを確認する。
【００７２】
ステップＳ３０８において、制御部１１は、当該資料を資料記憶部１５から取得するように採取部１３に指示する。採取部１３は当該指示に従い、当該資料を資料記憶部１５から取得する。
【００７３】
ステップＳ３０９において、制御部１１は、当該資料の全てが資料記憶部１５から取得されたかを採取部１３に確認する。
【００７４】
当該資料の全てが資料記憶部１５から取得されたと確認されると、ステップＳ３１０において、制御部１１は、実行部１４に、一時停止していた業務を再開するように指示する。実行部１４は、この指示に従い、一時停止していた業務を再開する。
【００７５】
以上で２）業務中止の可否に従い資料を採取又は採取しない動作を終了する。
【００７６】
最後に、３）業務抑制の可否に従い資料を採取または採取しない動作について、図７のフローチャートを参照して説明する。
【００７７】
まずステップＳ４０１〜ステップＳ４０３については、図５のＳ２０１〜ステップＳ２０３と同様である。
【００７８】
ステップＳ４０４において、制御部１１は、ステップＳ４０１で取得した採取をリクエストされた１つまたは複数の資料および基準情報を基に、対象となる資料取得のために業務を抑制するべきか否かを判断する。具体的に、制御部１１は、図２の資料情報１２ａ内の資料ｂのＣＰＵ使用率と、図３の業務情報１２ｂ内の業務ＩＤ「アイドル」の１時間の平均ＣＰＵ使用率を比較する。この場合、資料ｂのＣＰＵ使用率（１０％）より、アイドルの１時間の平均ＣＰＵ使用率（５％）のほうが大きいので、制御部１１は、対象となる資料取得のために業務を抑制するべきと判断する。尚、資料ｂのＣＰＵ使用率より、アイドルの１時間の平均ＣＰＵ使用率のほうが小さければ、対象となる資料取得のために業務を抑制する必要はないと判断する。対象となる資料取得のために業務を抑制するべきと判断された場合、処理はステップＳ４０５に進められ、対象となる資料取得のために業務を抑制する必要はないと判断された場合、処理はステップＳ４１２に進められ、対象となる資料を採取部１３が資料記憶部１５から取得し、制御部１１に引き渡す。
【００７９】
ステップＳ４０５において、制御部１１は、対象となる資料のＣＰＵ使用率（図２参照）と、対象となる業務の最低保証ＣＰＵ使用率（図３参照）とを比較し、負荷状況を確認する。即ち、制御部１１は、対象となる資料のＣＰＵ使用率が、対象となる業務の最低保証ＣＰＵ使用率よりも大きいか否かを判断する。尚、対象となる資料のＣＰＵ使用率が、対象となる業務の最低保証ＣＰＵ使用率よりも大きい場合は負荷が少ない、その逆は負荷が高いと判断する。
【００８０】
負荷が高いと判断されると、ステップＳ４０６において、処理はステップＳ４０７に進められる。負荷が低いと判断されると、ステップＳ４０６において、処理はステップＳ４１２に進められ、資料取得処理が行われる。
【００８１】
ステップＳ４０７において、制御部１１は、実行状況を抑制してもよい業務かを確認する。具体的に、制御部１１は、業務情報１２ｂに含まれる業務毎の業務優先度をチェックし、優先度の低いものから順にＣＰＵ使用率を抑制して、採取に必要なＣＰＵリソースを確保する。例えば、業務情報１２ｂ内の業務Ｄは業務優先度が「低」、かつ、一時間の平均ＣＰＵ使用率が「１５％」であるため、業務ＤのＣＰＵ使用率を５％程度抑制する。これにより、アイドル（５％）と業務Ｄを抑制した結果得た５％とを合わせて１０％のＣＰＵリソースを確保可能であることが確認される。
【００８２】
ステップＳ４０８において、制御部１１は、ステップＳ４０７に記載のＣＰＵリソースを確保する処理を実行するよう、実行部１４に指示する。実行部１４はこの指示に従い、業務を抑制する。
【００８３】
ステップＳ４０９において、制御部１１は、ステップＳ４０８の抑制により、実際に業務が抑制されＣＰＵリソースが確保できたかを確認する。
【００８４】
ステップＳ４１０において、ＣＰＵリソースの確保の確認後、制御部１１は、採取部１３に、資料記憶部１５から対象となる資料を採取するように指示する。採取部１３は、この指示に従い、資料記憶部１５から対象となる資料を採取し、制御部１１に引き渡す。
【００８５】
ステップＳ４１１において、制御部１１は、ステップＳ４０７に記載のＣＰＵリソースを確保する処理を停止するよう、実行部１４に指示する。実行部１４はこの指示に従い、リソースを確保の抑制を停止し、業務を通常の実効状態に戻す。これで、３）業務抑制の可否に従い資料を採取または採取しない動作を終了する。
【００８６】
（第１の実施形態の効果）
本発明の第１の実施形態によると、対象サーバ１から資料を採取する際、システム全体の処理に悪影響を与えずに、資料採取までの待ち時間を短縮することができる。これは、制御部１１が、基準情報記憶部１２に格納される基準情報を基に、システム全体に負荷をかけず、短時間で採取可能な資料であれば、業務実行中であってもそれを一時中止して資料を採取するよう指示するからである。
【００８７】
＜第２の実施形態＞
本発明の第２の実施形態にかかる資料採取サーバ２００は、外部のクライアント端末等からの指示に基づき、自らが有する資料を採取する処理の実行を制御するサーバであり、図８に示す様に、制御部２０１、基準情報記憶部２０２、および、採取部２０３を備える。
【００８８】
基準情報記憶部２０２は、資料に関する資料情報および資料採取サーバ２００が実行する業務アプリケーションに関する情報を含む基準情報を記憶する。
【００８９】
制御部２０１は、基準情報および資料採取サーバ２００の業務アプリケーション稼動状況を取得し、基準情報および業務アプリケーションの稼動状況に基づいて、資料採取処理の実行可否および資料採取処理の最短開始タイミングを判断する。
【００９０】
採取部２０３は、制御部２０１の判断に従って、資料採取処理の実行を開始する。
【００９１】
本発明の第２の実施形態にかかる資料採取サーバ２００によると、資料採取サーバ２００から資料を採取する際、システム全体の処理に悪影響を与えずに、資料採取までの待ち時間を短縮することができる。これは、資料採取サーバ２００の制御部２０１が、基準情報記憶部２０２に格納される基準情報を基に、システム全体に負荷をかけず、短時間で採取可能な資料であれば、業務実行中であってもそれを一時中止して資料を採取するよう指示するからである。
【００９２】
（情報処理装置）
上述した本発明の各実施形態において、図１等に示す資料採取システム１００内の対象サーバ１（資料採取サーバ２００）およびクライアント端末２の各構成要素の一部又は全部は、例えば図９に示すような情報処理装置５００とプログラムとの任意の組み合わせを用いて実現することも可能である。情報処理装置５００は、一例として、以下のような構成を含む。
【００９３】
・ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）５０１
・ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）５０２
・ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）５０３
・プログラム５０４および他のデータを格納する記憶装置５０５
・記録媒体５０６の読み書きを行うドライブ装置５０７
・通信ネットワーク５０９と接続する通信インターフェース５０８
・データの入出力を行う入出力インターフェース５１０
・各構成要素を接続するバス５１１
本願の各実施形態における資料採取システム１００の各構成要素は、これらの機能を実現するプログラム５０４をＣＰＵ５０１が取得して実行することで実現される。資料採取システム１００の各構成要素の機能を実現するプログラム５０４は、例えば、予め記憶装置５０５やＲＡＭ５０３に格納されており、必要に応じてＣＰＵ５０１が読み出す。なお、プログラム５０４は、通信ネットワーク５０９を介してＣＰＵ５０１に供給されてもよいし、予め記録媒体５０６に格納されており、ドライブ装置５０７が当該プログラムを読み出してＣＰＵ５０１に供給してもよい。
【００９４】
各装置の実現方法には、様々な変形例がある。例えば、資料採取システム１００は、構成要素毎にそれぞれ別個の情報処理装置とプログラムとの任意の組み合わせにより実現されてもよい。また、資料採取システム１００が備える複数の構成要素が、一つの情報処理装置５００とプログラムとの任意の組み合わせにより実現されてもよい。
【００９５】
また、資料採取システム１００の各構成要素の一部又は全部は、その他の汎用または専用の回路、プロセッサ等やこれらの組み合わせによって実現される。これらは、単一のチップによって構成されてもよいし、バスを介して接続される複数のチップによって構成されてもよい。
【００９６】
資料採取システム１００の各構成要素の一部又は全部は、上述した回路等とプログラムとの組み合わせによって実現されてもよい。
【００９７】
資料採取システム１００の各構成要素の一部又は全部が複数の情報処理装置や回路等により実現される場合には、複数の情報処理装置や回路等は、集中配置されてもよいし、分散配置されてもよい。例えば、情報処理装置や回路等は、クライアントアンドサーバシステム、クラウドコンピューティングシステム等、各々が通信ネットワークを介して接続される形態として実現されてもよい。
【００９８】
以上、本実施形態を参照して本願発明を説明したが、本願発明は上記実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
【符号の説明】
【００９９】
１００  資料採取システム
１      対象サーバ
１１    制御部
１２    基準情報記憶部
１３    採取部
１４    実行部
２      クライアント端末
２１    指示部
２００  資料採取サーバ
５００    情報処理装置
５０１    ＣＰＵ
５０３    ＲＡＭ
５０４    プログラム
５０５    記憶装置
５０６    記録媒体
５０７    ドライブ装置
５０８    通信インターフェース
５０９    通信ネットワーク
５１０    入出力インターフェース
５１１    バス
【図１】
2019139566.tif 000003
【図２】
2019139566.tif 000004
【図３】
2019139566.tif 000005
【図４】
2019139566.tif 000006
【図５】
2019139566.tif 000007
【図６】
2019139566.tif 000008
【図７】
2019139566.tif 000009
【図８】
2019139566.tif 000010
【図９】
2019139566.tif 000011