JP2019159474A - メッセージ監視サーバ、方法、プログラム - Google Patents

Abstract

【課題】データセンター側からのメッセージ内容を自動で精査することで、管理ユーザの負担を軽減することができる技術を提供する。【解決手段】保守運用センター２０において、メッセージ監視サーバ１０は、サーバ４０の異常の有無を監視するメッセージ監視サーバであって、サーバ４０から出力されたサーバ４０の装置等の異常に関する第１メッセージを格納する出力メッセージ格納部１１と、サーバ４０から出力されることが想定されるサーバ４０の設定変更に伴う第２メッセージを格納する想定メッセージ格納部１２と、過去にサーバ４０から出力されたサーバ４０の設定変更に伴う第３メッセージを格納するナレッジ１３と、第１、第２及び第３メッセージを比較して判定する判定部１４と、判定部１４による判定に基づき、管理ユーザに調査依頼の実施を促す表示制御部１５と、を備える。【選択図】図２

Description

データセンター内のサーバを監視する技術に関する。

銀行のＡＴＭを運用するシステムは、データセンターに設置された制御用のサーバが、各拠点におけるＡＴＭの取引処理の制御や、ホストサーバとの通信を実施する集中型のシステムを採用している。そのため、データセンターにおいて異常が発生した際には迅速に調査、復旧を行う必要がある。

従来、そのような異常の発生に対応する為に、データセンターのサーバを監視する監視装置が用いられている。データセンターのサーバにおいて異常が発生した際には、サーバから異常を示すメッセージが出力される。監視装置を扱うオペレータはそのメッセージの内容を読みとり、待機中のエンジニアへサーバの調査依頼を送ることで、エンジニアによってサーバの状況が調査され、復旧される。

特許文献１では、操作ログファイルを取得して、機器上での変更された監視項目の有無を判定し、システム管理者に対して設定変更を報知する処理が記載されている。

特開２０１３−０８０３８７号公報

一方で、データセンターのサーバがメッセージを出力するような状況としては、メンテナンス時においてサーバに設定変更が発生した場合も該当する。このような設定変更は、予め実施することが予定された設定変更であり、装置等の異常ではないため、オペレータがエンジニアに対して調査依頼を出す必要はない。

なお、メンテナンス時のサーバの設定変更にはアプリケーションの更新等も含まれる。

しかし、日々行われる監視業務では、オペレータが、メッセージの内容を確認してサーバに異常が生じたか予定された設定変更が行われたかを判別することは難しい。そのため、従来では予定された設定変更であっても、オペレータは異常が生じた可能性があるとしてエンジニアへ調査依頼を送っている。即ち、管理ユーザ（オペレータ、エンジニア）の作業量が必要以上に多くなり、負担が増加してしまっているという問題があった。

以上の実情を考慮し、本発明では、データセンター側からのメッセージ内容を自動で精査することで、管理ユーザの負担を軽減することができる技術を提供することを目的とする。

本発明の一態様におけるメッセージ監視サーバは、サーバの異常の有無を監視するメッセージ監視サーバであって、前記サーバから出力された第１メッセージを格納する出力メッセージ格納部と、前記サーバから出力されることが想定される第２メッセージを格納する想定メッセージ格納部と、過去に前記サーバから出力された第３メッセージを格納するナレッジと、前記第１、第２及び第３メッセージを比較して判定する判定部と、前記判定部による判定に基づき、管理ユーザに調査依頼または確認依頼の実施を促す報知手段と、を備え、前記判定部は、前記第１メッセージと前記第２メッセージとが一致するかどうかの第１判定処理を実行し、前記第１メッセージと前記第３メッセージとが一致するかどうかの第２判定処理を実行し、前記第２メッセージと前記第３メッセージとが一致するかどうかの第３判定処理を実行し、前記報知手段は、前記第１判定処理の結果として、前記第１メッセージと前記第２メッセージとが一致する場合には、前記管理ユーザに調査依頼の実施を促さず、前記第１メッセージと前記第２メッセージとが一致しない場合には、前記第２及び第３判定処理の結果に基づき、前記管理ユーザに前記調査依頼または前記確認依頼の実施を促し、前記ナレッジは、前記第１判定処理の結果として、前記第１メッセージと前記第２メッセージとが一致し、かつ前記第２判定処理の結果として、前記第１メッセージと前記第３メッセージとが一致せず、かつ前記第３判定処理の結果として、前記第２メッセージと前記第３メッセージとが一致しない場合に、前記第１メッセージを前記第３メッセージとして格納する。

本発明の一態様におけるメッセージ監視方法は、サーバから出力された第１メッセージを格納し、前記サーバから出力されることが想定される第２メッセージを格納し、過去に前記サーバから出力された第３メッセージを格納し、前記第１メッセージと前記第２メッセージとが一致するかどうかの第１判定処理を実行し、前記第１メッセージと前記第３メッセージとが一致するかどうかの第２判定処理を実行し、前記第２メッセージと前記第３メッセージとが一致するかどうかの第３判定処理を実行し、前記第１判定処理の結果として、前記第１メッセージと前記第２メッセージとが一致する場合には、管理ユーザに調査依頼の実施を促さず、前記第１メッセージと前記第２メッセージとが一致しない場合には、前記第２判定処理及び第３判定処理の結果に基づき、管理ユーザに前記調査依頼または確認依頼の実施を促し、前記第１判定処理の結果として、前記第１メッセージと前記第２メッセージとが一致し、かつ前記第２判定処理の結果として、前記第１メッセージと前記第３メッセージとが一致せず、かつ前記第３判定処理の結果として、前記第２メッセージと前記第３メッセージとが一致しない場合に、前記第１メッセージを前記第３メッセージとして格納する。

本発明の一態様におけるプログラムは、サーバから出力された第１メッセージを格納し、前記サーバから出力されることが想定される第２メッセージを格納し、過去に前記サーバから出力された第３メッセージを格納し、前記第１メッセージと前記第２メッセージとが一致するかどうかの第１判定処理を実行し、前記第１メッセージと前記第３メッセージとが一致するかどうかの第２判定処理を実行し、前記第２メッセージと前記第３メッセージとが一致するかどうかの第３判定処理を実行し、前記第１判定処理の結果として、前記第１メッセージと前記第２メッセージとが一致する場合には、管理ユーザに調査依頼の実施を促さず、前記第１メッセージと前記第２メッセージとが一致しない場合には、前記第２判定処理及び第３判定処理の結果に基づき、管理ユーザに前記調査依頼または確認依頼の実施を促し、前記第１判定処理の結果として、前記第１メッセージと前記第２メッセージとが一致し、かつ前記第２判定処理の結果として、前記第１メッセージと前記第３メッセージとが一致せず、かつ前記第３判定処理の結果として、前記第２メッセージと前記第３メッセージとが一致しない場合に、前記第１メッセージを前記第３メッセージとして格納する。

本発明によれば、データセンター側からのメッセージ内容を自動で精査することで、管理ユーザの負担を軽減することができる。

管理システムの概略を示す図である。 メッセージ監視サーバの機能構成を示す図である。 出力メッセージ格納部、想定メッセージ格納部、ナレッジがそれぞれ第１〜３メッセージを管理テーブル上に格納する場合の一例を示す図である。 判定部による判定処理の結果を管理するためのテーブルを示す図である。 メッセージ監視サーバのハードウェア構成図である。 メッセージの登録処理を示すフローチャートである。 サーバを監視する一連の制御を示すフローチャートである。 メッセージ確認処理を示すフローチャートである。 調査依頼内容を決定する処理を示すフローチャートである。 調査依頼内容を決定する処理を示すフローチャートである。 コンソールを介したオペレータへの指示処理を示すフローチャートである。 テーブル比較処理における共通のフローチャートである。 復帰値<1>既知の対応が設定される一例となる各テーブルを示す図である。 復帰値<2>記載ミス可能性有が設定される一例となる各テーブルを示す図である。 復帰値<3>記載ミス指摘が設定される一例となる各テーブルを示す図である。 復帰値<4>新規の対応が設定される一例となる各テーブルを示す図である。 復帰値<5>要調査が設定される一例となる各テーブルを示す図である。 復帰値<6>エラーが設定される一例となる各テーブルを示す図である。 復帰値<7>エラーが設定される一例となる各テーブルを示す図である。 復帰値<8>エラーが設定される一例となる各テーブルを示す図である。

以下、本発明の一実施の形態における管理システム１００について説明する。図１は、管理システム１００の概略を示す図である。管理システム１００は、オペレータが常駐し、メッセージ監視サーバ１０及びコンソール１７が設置された保守運用センター２０と、複数のサーバ４０が設置されたデータセンター５０と、エンジニア（ＳＥ、ＣＥを含む）が使用する通信端末であって、オペレータが操作するコンソール１７との間で通信を行う通信端末３０と、を含む。以降オペレータ等の管理システム１００を利用する立場のユーザを管理ユーザとも表記する。

管理システム１００では、データセンター５０のサーバ４０が各拠点におけるＡＴＭ６０の取引処理の制御や、ホストサーバ７０との通信を実施する。即ち、管理システム１００は、サーバ４０を主体とした銀行のＡＴＭの運用に関する集中型の管理システム等である。

保守運用センター２０は、データセンター５０に設置されたサーバ４０における装置等の異常を監視する場所である。サーバ４０における装置等の異常には、サーバ４０内のアプリケーションの更新やミドルウェアの変更等のメンテナンス時等において予め実施することが予定された設定変更に伴う異常も含まれる。

本発明の一実施形態における管理システム１００では、メッセージ監視サーバ１０が、サーバ４０における装置等の異常を監視するとともに、サーバ４０からの出力されるメッセージを自動で精査する。

以下、図１、２を用いて、メッセージ監視サーバ１０の機能を説明する。図２は、メッセージ監視サーバ１０の機能構成を示す図である。

メッセージ監視サーバ１０は、出力メッセージ格納部１１、想定メッセージ格納部１２、ナレッジ１３、判定部１４、表示制御部１５、通信部１６を含む（図２を参照）。

出力メッセージ格納部１１は、サーバ４０において装置等の異常があった場合に、サーバ４０から通信部１６を介して受信したメッセージ（第１メッセージとする）を格納する。

想定メッセージ格納部１２は、サーバ４０から出力されることが想定される設定変更に伴うメッセージ（第２メッセージとする）を格納する。想定される設定変更に伴うメッセージとは、メンテナンス時等において予め実施されることが判っているが、その設定変更を行うことにより装置等の異常として認識されてしまう設定変更に伴うメッセージである。例えば、エンジニア等のシステム担当者は、事前に想定メッセージ格納部１２へ第２メッセージとなり得るメッセージを格納しておく。

ナレッジ１３は、過去にサーバ４０から出力されたことのある設定変更に関するメッセージ（第３メッセージとする）を格納する。

判定部１４は、出力メッセージ格納部１１、想定メッセージ格納部１２、ナレッジ１３にそれぞれ格納された第１メッセージ、第２メッセージ、第３メッセージを比較し、合致するものがあるかどうかの判定処理を実行する。具体的には、判定部１４は、第１メッセージと第２メッセージとが一致するかどうかの第１判定処理を実行する。また、判定部１４は、第１メッセージと第３メッセージとが一致するかどうかの第２判定処理を実行する。また、判定部１４は、第２メッセージと第３メッセージとが一致するかどうかの第３判定処理を実行する。判定部１４が実行する上記の判定処理は、新たに第１メッセージが受信されて出力メッセージ格納部１１に格納された際に行われる。

また、想定メッセージ格納部１２において第２メッセージを格納する際、サーバ４０から第２メッセージが出力されることが想定される規定の条件を、格納した第２メッセージ毎に設定する。このようにすることで、複数の異なる条件においてサーバ４０から受信し得るメッセージを一括して格納しておいた場合でも、現在規定の条件となったメッセージのみを第２メッセージとして、判定部１４の判定処理の対象とすることができる。規定の条件とは、例えば日時であり、一例ではメッセージ監視サーバ１０内では、対象となる日時において、判定部１４が判定処理に用いることを可能とするようなフラグが設定される。

表示制御部１５は、判定部１４による第１〜第３判定処理の結果に基づき、管理ユーザであるオペレータへの指示をコンソール１７上へ表示する制御を実行する。具体的には、表示制御部１５は、サーバ４０における装置等の異常を受けて、エンジニアにサーバ４０の調査依頼を出す必要がある場合に、コンソール１７に表示させる表示画面を通してオペレータへ調査依頼の実施を促す。即ち、表示制御部１５は、報知手段として機能する。調査依頼の実施が必要な状況とは、メンテナンス時等における予定された設定変更に伴う装置等の異常がサーバ４０に発生したのではなく、エラー等による予期しない装置等の異常がサーバ４０に発生した可能性がある場合である。

詳しくは、判定部１４による第１の判定処理の結果として、出力メッセージ格納部１１内のメッセージと想定メッセージ格納部１２内のメッセージが一致しない場合には、想定されないメッセージがサーバ４０から出力されたとし、表示制御部１５が調査依頼または確認依頼の実施を促す画面を表示する。確認依頼については詳しくは後述するが、エンジニア等のシステム担当者が事前に格納した第２メッセージに誤りがある可能性が大きい場合に、システム担当者に第２メッセージに誤りがあるかどうかの確認を依頼するものである。逆に、判定部１４による第１の判定処理の結果として、出力メッセージ格納部１１と想定メッセージ格納部１２内でメッセージが一致した場合には、想定されたメッセージがサーバ４０から出力されたとし、調査依頼または確認依頼の実施を促さない。（調査依頼および確認依頼は不要の画面を表示してもよい）

通信部１６は、サーバ４０において設定変更が生じた場合に出力される第１メッセージを受信する。

コンソール１７は、オペレータが操作する制御盤であって、画像出力を行うモニター（不図示）、キーボード等の入出力装置（不図示）を有している。コンソール１７は、表示制御部からの指示をモニターに表示し、表示メッセージを確認したオペレータが電話やメール等を行うことで、エンジニアへ向けた調査依頼、確認依頼の実施を可能とする。異常の発生時に調査依頼を引き受けたエンジニアがサーバ４０の状況を調査し、復旧する。

図３は、出力メッセージ格納部１１、想定メッセージ格納部１２、ナレッジ１３によりそれぞれ管理テーブルに格納される第１〜３メッセージの一例である。

テーブルＡは、出力メッセージ格納部１１が記憶するテーブルであり、第１メッセージが含まれる。テーブルＡにおいて、”出力日時”は、第１メッセージが出力された日時を示す。”メッセージ出力サーバ”は、複数のサーバ４０のうち第１メッセージを出力したサーバを示す。”出力メッセージ”は、第１メッセージの内容を示す。

テーブルＢは、想定メッセージ格納部１２が記憶するテーブルであり、第２メッセージが含まれる。テーブルＢにおいて、”ＳＥ作業名”は、該当する第２メッセージが出力され得る状態であるエンジニアによる作業またはジョブ等の名称を示す。”メッセージ出力サーバ”は、この第２メッセージが出力され得るサーバ４０を示す。”出力メッセージ”は、第２メッセージの内容を示す。”作業開始日時”、”作業終了日時”は、該当する第２メッセージが出力され得るエンジニアの作業またはジョブ等が行われるまたは実行される時間帯の開始日時と終了日時を示す。”対象フラグ”は、現在該当するメッセージが出力され得る状態（即ち規定の条件である）であるかどうかを示す。対象フラグがＯＮのときには、該当する第２メッセージを判定部１４による判定処理の対象とする。対象フラグがＯＦＦのときには、該当する第２メッセージを判定部１４による判定処理の対象から除外する。対象フラグがＥＯＦ(Ｅｎｄ ｏｆ ｆｉｌｅ)となった場合、格納済みの第２メッセージのうち最後の第２メッセージの判定処理を終えた状態を示し、格納済みの全ての第２メッセージの判定処理が終わったものとする。”管理番号”とは、第２メッセージそれぞれを区別するための固有の番号であり、判定部１４における判定処理の結果を後述するテーブルＤにおいて管理するために用いられる。

テーブルＣは、ナレッジ１３が記憶するテーブルであり、第３メッセージが含まれる。テーブルＣにおいて、”ＳＥ作業名”は、該当する第３メッセージがサーバ４０から出力されたときのエンジニアによる作業またはジョブ等の名称を示す。”メッセージ出力サーバ”は、この第３メッセージが出力されたサーバ４０を示す。”出力メッセージ”は、第３メッセージの内容を示す。

図４は、判定部１４による判定処理の結果を管理するためのテーブルＤを示す。テーブルＤは、判定部１４による判定対象となるテーブルＢに記載の管理番号のメッセージに関する判定処理の結果を格納する。”メッセージ処理番号”には、テーブルＢに記載した管理番号が記載される。判定部１４による各種判定処理（第１〜３判定処理）の比較結果においては、比較対象のメッセージ間で一致するメッセージがあった場合に”Ｙ”が記載され、一致するメッセージがなかった場合には、”Ｎ”が記載される。

なお、”メッセージ処理番号”には初期値として“０”を、各種判定処理（第１〜３判定処理）には初期値として“−”を設定することが望ましい。

図５は、メッセージ監視サーバ１０のハードウェア構成図である。ハードウェア構成は、ＣＰＵ１１１、ＤＲＡＭ１１２、ＲＯＭ１１３、記憶部１１４、入出力ＩＦ１１５を備えている。

ＣＰＵ１１１は、ＲＯＭ１１３に格納される各種制御プログラムを読みこんで実行する。

ＤＲＡＭ１１２は、制御プログラムや各種データを一時的に格納するワーキングエリアを提供する。ＲＯＭ１１３は、各種制御プログラムを不揮発的に記憶する記憶媒体である。

記憶部１１４は、プログラムや各種処理に用いるデータを格納し、フラッシュメモリやハードディスク等により構成される。入出力ＩＦ１１５は、コンソール等の外部機器とデータの送受信を行うものである。通信ＩＦ１１７は、ホストサーバやＡＴＭとの通信を行うものである。尚、各構成は、バス１１６により接続される。判定部１４は、ＣＰＵ１１１、ＤＲＡＭ１１２、ＲＯＭ１１３により実現される。また、出力メッセージ格納部１１、想定メッセージ格納部１２及びナレッジ１３は、ＣＰＵ１１１、ＤＲＡＭ１１２、ＲＯＭ１１３、記憶部１１４により実現される。

以下、メッセージ監視サーバ１０によるサーバ４０の監視に係る制御を、図６〜図１１に示すフローチャートを用いて説明する。図６は、メッセージの登録処理を示すフローチャートである。図７は、サーバ４０を監視する一連の制御を示すフローチャートである。図８は、メッセージ確認処理を示すフローチャートである。図９、図１０は、調査依頼または確認依頼を決定する処理を示すフローチャートである。図１１は、コンソール１７を介したオペレータへの指示処理を示すフローチャートである。

図６に示す登録処理を説明する。ステップＳ１では、エンジニア等のシステム担当者からの入力に基づき、メッセージ監視サーバ１０は、想定メッセージ格納部１２に第２メッセージを登録する。このとき、図３のテーブルＢに示す各項目（ＳＥ作業名、メッセージ出力サーバ等）の登録を行う。尚、テーブルＢに示す管理番号については、メッセージ監視サーバ１０がテーブルＢ内で固有な番号を付与する。ステップＳ１が実行されると、登録処理を終了する。

以下、図７〜図１０を用いてサーバ４０を監視する一連の制御を説明する。

図７のステップＳ１１では、メッセージ監視サーバ１０は、ＯＳの終了等の割り込み処理等により監視処理が終了されたかを判定する。ステップＳ１１の判定がＹｅｓであれば、図７に示す処理を終了する。ステップＳ１１の判定がＮｏであれば、ステップＳ１２へ移行する。

ステップＳ１２では、メッセージ監視サーバ１０は、サーバ４０内のシステムログを監視する。ステップＳ１３において、新規のメッセージがあるか判定し、あった場合、ステップＳ１４へ移行する。ステップＳ１４において、メッセージ監視サーバ１０は、通信部１６を介してサーバ４０から該当する新規のメッセージを受信し、出力メッセージ格納部１１に第１メッセージとして格納する。ステップＳ１３において、新規のメッセージがない場合、ステップＳ１５へ移行する。

ステップＳ１５では、判定部１４がサーバ４０から出力された第１メッセージを確認するメッセージ確認処理を実行する。

以下、図８を用いてメッセージ確認処理を詳述する。

図８のステップＳ３１では、判定部１４は、想定メッセージ格納部１２に格納された第２メッセージを確認する。一例では、図３のテーブルＢに格納された第２メッセージを上の行から確認する。

ステップＳ３２では、判定部１４は、確認中のメッセージの”対象フラグ”の項目がＥＯＦであるかどうか判定する。即ち、テーブルＢのメッセージの最終項目まで確認が終わっている場合、ＥＯＦとなる。ステップＳ３２の判定がＮｏである場合、ステップＳ３３へ移行する。ステップＳ３２の判定がＹｅｓである場合、復帰値として対応不要を設定し、図８のメッセージ確認処理を終了する。

ステップＳ３３では、判定部１４は、確認中のメッセージの”対象フラグ”の項目がＯＮであるかどうかを判定する。ステップＳ３３の判定がＮｏ（即ち対象フラグがＯＦＦ）である場合、ステップＳ３１へ戻り処理を繰り返す。ステップＳ３３の判定がＹｅｓ（即ち対象フラグがＯＮ）である場合、ステップＳ３４へ移行し、次のメッセージを確認する。

ステップＳ３４では、判定部１４は、現在の時刻が確認中のメッセージの”作業開始日時”、”作業終了日時”の間の時刻であるかどうか、即ち予め想定された作業の実施またはジョブの実行が行われる時間内であるかどうかを判定する。ステップＳ３４の判定がＮｏである場合、ステップＳ３１へ移行し、次のメッセージを確認する。ステップＳ３４の判定がＹｅｓである場合、ステップＳ３５へ移行する。

ステップＳ３５〜Ｓ４０では、ステップＳ３１〜S３４の判定を経た図３のテーブルＢの該当する行の第２メッセージが、判定部１４における比較処理（第１、３判定処理）に用いられる。

ステップＳ３５では、判定部１４は、図４のテーブルＤのメッセージ処理番号に該当する第２メッセージの行の管理番号を設定する。テーブルＤを比較処理テーブルとも呼ぶ。

ステップＳ３６では、判定部１４は、テーブルＡに登録された第１メッセージと、ステップＳ３１〜Ｓ３４の判定を経た図３のテーブルＢの該当する行の第２メッセージを比較するテーブル比較処理（第１判定処理である）を実行する。

ステップＳ３７では、判定部１４は、テーブルＡに登録された第１メッセージと、テーブルＣに格納された第３メッセージを比較するテーブル比較処理（第２判定処理である）を実行する。

ステップＳ３８では、判定部１４は、ステップＳ３５でテーブルＢに設定された第２メッセージと、テーブルＣに格納された第３メッセージを比較するテーブル比較処理（第３判定処理である）を実行する。

図１２は、ステップＳ３６〜S３８の各テーブル比較処理における共通のフローチャート（関数等の処理）である。

ステップＳ１１１では、判定部１４は、以降のテーブル比較処理に用いる引数を設定する。詳しくは、テーブル(1),(2)にＡ〜Ｃのうち指定された引数Ａ、Ｂ、Ｃを設定する。例えば、ステップＳ３６であれば、引数Ａ、Ｂを(1),(2)へ設定する。

なお、テーブル(1),(2)は、図１２の共通のフローチャート（関数等の処理）へ因数を渡すテーブルであり、図示は省略する。

ステップＳ１１２では、判定部１４は、テーブル(1),(2)のそれぞれの”メッセージ出力サーバ”の欄を比較する。

ステップＳ１１３では、判定部１４は、メッセージ出力サーバ名が一致するかを判定する。言い換えると、複数のサーバ４０のうち同じサーバから出力されたメッセージであるかどうかを判定する。ステップＳ１１３の判定がＹｅｓである場合、ステップＳ１１４へ移行する。ステップＳ１１３の判定がＮｏである場合、ステップＳ１１７へ移行して復帰値に[Ｎ]を設定する。なお、復帰値の返し方は特に規定しない。

ステップＳ１１４では、判定部１４は、テーブル(1),(2)のそれぞれの”出力メッセージ”の欄を比較する。

ステップＳ１１５では、判定部１４は、出力メッセージ名が一致するかを判定する。ステップＳ１１５の判定がＮｏである場合、ステップＳ１１７へ移行して復帰値に[Ｎ]を設定する。ステップＳ１１５の判定がＹｅｓである場合、ステップＳ１１６へ移行して復帰値に[Ｙ]を設定する。

図８に戻る。ステップＳ３９では、判定部１４は、テーブルＤにステップＳ３６〜S３８の判定の結果を格納する。詳しくは、テーブルＤの各比較項目に図１２のテーブル比較処理において返された復帰値のＹまたはＮを格納する。そして、ステップＳ４０では、判定部１４は、復帰値として対応要と設定し、図８のメッセージ確認処理を終了する。

なお、復帰値の返し方は特に規定しない。

図７の処理に戻る。図７のステップＳ１６では、メッセージ監視サーバ１０は、復帰値として対応要と設定がされているかどうかを判定する。ステップＳ１６の判定がＹｅｓの場合、ステップＳ１７の調査依頼決定処理へ移行する。ステップＳ１６の判定がＮｏの場合、ステップＳ２２へ移行し、一定時間のＷａｉｔ処理の後ステップＳ１１へ戻り処理を繰り返す。

以下、図９、図１０を用いて調査依頼決定処理を詳述する。

ステップＳ４１では、メッセージ監視サーバ１０は、テーブルＡとテーブルＢの比較結果の項目（第１判定処理の結果）がＹ、即ち第１判定処理において第１メッセージと第２メッセージとが一致している状態、であるかを判定する。すなわち、メッセージ監視サーバ１０は、比較処理テーブル（テーブルＤ）の比較項目２であるＡとＢ比較結果を判定する。ステップＳ４１の判定がＹｅｓである場合ステップＳ４２へ移行する。ステップＳ４１の判定がＮｏである場合図１０のステップＳ４９へ移行する。

ステップＳ４２では、メッセージ監視サーバ１０は、テーブルＡとテーブルＣの比較結果の項目（第２判定処理の結果）がＹ、即ち第２判定処理において第１メッセージと第３メッセージとが一致している状態、であるかを判定する。すなわち、メッセージ監視サーバ１０は、比較処理テーブル（テーブルＤ）の比較項目３であるＡとＣ比較結果を判定する。ステップＳ４２の判定がＹｅｓである場合ステップＳ４３へ移行する。ステップＳ４２の判定がＮｏである場合ステップＳ４４へ移行する。

ステップＳ４３では、メッセージ監視サーバ１０は、テーブルＢとテーブルＣの比較結果の項目（第３判定処理の結果）がＹ、即ち第３判定処理において第２メッセージと第３メッセージとが一致している状態、であるかを判定する。すなわち、メッセージ監視サーバ１０は、比較処理テーブル（テーブルＤ）の比較項目４であるＢとＣ比較結果を判定する。ステップＳ４３の判定がＹｅｓである場合ステップＳ４５へ移行する。ステップＳ４３の判定がＮｏである場合ステップＳ４６へ移行する。

その他、図９のステップＳ４４は、ステップＳ４３の処理と同様である。また、図１０のステップＳ４９は、図９のステップＳ４２の処理と同様であり、図１０のステップＳ５０、Ｓ５１の処理は、図９のステップＳ４３の処理と同様である。各判定（ステップＳ４１〜S４４、Ｓ４９〜Ｓ５１）の結果ステップＳ４５〜S４８、Ｓ５２〜Ｓ５５のいずれかへ到達する。

ステップＳ４５では、第１〜第３判定処理の結果が全てＹである。つまり、想定されたメッセージがサーバ４０から出力されたことからサーバ４０に異常は発生しておらず、且つ、以前にサーバ４０から出力されたことのある既知のメッセージが出力された状態である。このとき、メッセージ監視サーバ１０は、復帰値<1>既知の対応を設定する。

なお、復帰値の返し方は特に規定しない。

図１３は、ステップＳ４５へ到達して復帰値<1>既知の対応が設定される一例となるテーブルＡ，Ｂ，Ｃ，Ｄを示す。

ステップＳ４６では、第１、第２判定処理の結果がＹであり、第３判定処理の結果がＮである。判定結果に矛盾があり、通常出力されない状態なので、ステップＳ４６へ到達した場合エラーとされる。このとき、メッセージ監視サーバ１０は、復帰値<7>エラーを設定する。

図１９は、ステップＳ４６へ到達して復帰値<7>エラーが設定される一例となるテーブルＡ，Ｂ，Ｃ，Ｄを示す。

ステップＳ４７では、第１、３判定処理の結果がＹであり、第２判定処理の結果がＮである。判定結果に矛盾があり、通常出力されない状態なので、ステップＳ４６へ到達した場合エラーとされる。このとき、メッセージ監視サーバ１０は、復帰値<6>エラーを設定する。

図１８は、ステップＳ４７へ到達して復帰値<6>エラーが設定される一例となるテーブルＡ，Ｂ，Ｃ，Ｄを示す。

ステップＳ４８では、第１判定処理の結果がＹであり、第２、３判定処理の結果がＮである。つまり、想定されたメッセージがサーバ４０から出力されたことからサーバ４０に異常は発生していないが、以前にサーバ４０から出力されたことのある既知メッセージではない新規のメッセージが出力された状態である。このとき、メッセージ監視サーバ１０は、復帰値<4>新規の対応を設定する。

図１６は、ステップＳ４８へ到達して復帰値<4>新規の対応が設定される一例となるテーブルＡ，Ｂ，Ｃ，Ｄを示す。

ステップＳ５２では、第１判定処理の結果がＮであり、第２、３判定処理の結果がＹである。判定結果に矛盾があり、通常出力されない状態なので、ステップＳ５２へ到達した場合エラーとされる。このとき、メッセージ監視サーバ１０は、復帰値<8>エラーを設定する。

図２０は、ステップＳ５２へ到達して復帰値<8>エラーが設定される一例となるテーブルＡ，Ｂ，Ｃ，Ｄを示す。

ステップＳ５３では、第１、３判定処理の結果がＮであり、第２判定処理の結果がＹである。つまり、想定されたメッセージがサーバ４０から出力されておらずサーバ４０に異常が発生した可能性がある。一方で、出力されたメッセージは、以前にサーバ４０から出力されたことのあるメッセージであり、システム担当者（エンジニア）がテーブルＢへ格納した今回判定対象になったメッセージに誤りがある可能性が比較的高い状況でもある。このとき、メッセージ監視サーバ１０は、復帰値<3>記載ミス指摘を設定する。

図１５は、ステップＳ５３へ到達して復帰値<3>記載ミス指摘が設定される一例となるテーブルＡ，Ｂ，Ｃ，Ｄを示す。

ステップＳ５４では、第１、２判定処理の結果がＮであり、第３判定処理の結果がＹである。つまり、想定されたメッセージがサーバ４０から出力されておらずサーバ４０に異常が発生した可能性がある。一方で、システム担当者（エンジニア）がテーブルＢへ格納した今回判定対象になったメッセージは、以前にサーバ４０から出力されたことのあるメッセージであり、例えば、想定されるメッセージは新規のものであるが、システム担当者（エンジニア）が誤って既知のメッセージをテーブルＢへ格納してしまった虞もある。このとき、メッセージ監視サーバ１０は、復帰値<2>記載ミス可能性有を設定する。

図１４は、ステップＳ５４へ到達して復帰値<2>記載ミス可能性有が設定される一例となるテーブルＡ，Ｂ，Ｃ，Ｄを示す。

ステップＳ５５では、第１〜第３判定処理の結果が全てＮである。つまり、想定されたメッセージがサーバ４０から出力されておらずサーバ４０に異常は発生した可能性がある。そして、実際にサーバ４０から出力されたメッセージは、システム担当者（エンジニア）がテーブルＢへ格納した今回判定対象になったメッセージとも、以前にサーバ４０から出力されたことのある既知のメッセージとも異なる状況であり、想定外のメッセージが出力された可能性が高い。このとき、メッセージ監視サーバ１０は、復帰値<5>要調査を設定する。

図１７は、ステップＳ５５へ到達して復帰値<5>要調査が設定される一例となるテーブルＡ，Ｂ，Ｃ，Ｄを示す。

図７において、ステップＳ１７が終了したあと、ステップＳ１８のオペレータ指示処理へ移行する。以下、図１１において、オペレータ指示処理を詳述する。

図１１のステップＳ６１では、表示制御部１５は、調査依頼決定処理の復帰値に応じて、コンソール１７へ指示画面を表示する。

ステップＳ６１の表示制御部１５による処理の概要を以下にまとめる。復帰値が<1>、<4>の場合には、エンジニアによる作業実施やジョブ実行に伴う予定された設定変更に基づいてサーバ４０からメッセージが出力された状態であるため、オペレータに対して調査依頼が不要である旨を伝達する。復帰値が<2>、<3>の場合には、サーバ４０において生じた装置等の異常が予定された設定変更に伴うものではないが、テーブルＢに設定されたメッセージに誤りがある可能性があることから、テーブルＢの第２メッセージの正誤の確認を含めたエンジニアへの確認依頼を伝達する。復帰値が<5>の場合には、出力されたメッセージが想定メッセージ格納部１２のテーブルＢ、ナレッジのテーブルＣのいずれにも無く、想定外のメッセージが出力された可能性が高いため、主に出力されたメッセージについての調査依頼を伝達する。尚、復帰値が<6>、<7>、<8>の場合には、判定結果に矛盾があり、通常出力されない状態なので、管理システム１００を管理するシステム管理者への問い合わせを要求することが望ましい。

一例として、復帰値が<1>、<4>の場合は「ＳＥ作業によるものですので、対応不要です」のような指示を表示する。復帰値が<2>の場合は、一例として、「事前に登録した”SE作業時出力メッセージ”に誤りの可能性もあります。ＳＥへ確認依頼してください」のような指示を表示する。復帰値が<3>の場合は、一例として、「事前に登録した”SE作業時出力メッセージ”に誤りがありますので、ＳＥへ確認依頼してください」のような指示を表示する。復帰値が<5>の場合は、一例として、「時刻○○にサーバ△△から出力されたメッセージについて、ＳＥへ調査依頼してください」のような指示を表示する。復帰値が<6>、<7>、<8>の場合は、「システム管理者へ連絡してください」のような指示を表示する。

図７の処理に戻る。図７のステップＳ１９では、復帰値が<4>新規の対応であるかどうかを判定する。ステップＳ１９の判定がＹｅｓの場合、ステップＳ２０において、ナレッジが該当する第１メッセージを第３メッセージとして格納する。

ステップＳ２１では、メッセージ監視サーバ１０は、後処理として、該当するテーブルＢの行における対象フラグをＯＦＦしたり、テーブルＤを初期化する、詳しくは、”メッセージ処理番号”には初期値として“０”を、各種判定処理（第１〜３判定処理）には初期値として“−”を設定する。ステップＳ２２で一定時間、例えば５秒のＷａｉｔ処理の後ステップＳ１１へ戻り処理を繰り返す。

以上のメッセージ監視サーバ１０によれば、図７のループ（ステップＳ１１〜S２２）を繰り返すことで、テーブルＢに格納された各第２メッセージに対し、サーバ４０からの第２メッセージの出力が想定される規定の条件となった際に、実際に出力された第１メッセージとの間で比較が行われる（テーブルＡ、Ｂの比較であり、第１判定処理である）。このような第１判定処理によって調査依頼の要否を判定し、オペレータへ伝達することができる。

従来、予定された設定変更であっても、オペレータは、サーバに異常が生じた可能性があるとしてエンジニアへ調査依頼を送っていた。一方、メッセージ監視サーバ１０によれば、サーバ４０からのメッセージ内容を自動で精査し、調査依頼の要否を判定することで、調査依頼不要なものについてはオペレータが調査依頼を出さなくてもよいことを報知するため、管理ユーザ（オペレータ）が行う作業負担が軽減される。

さらに、第１判定処理の結果、テーブルＡ、Ｂ間でメッセージが一致した場合において、第２、３判定処理によりテーブルＣのメッセージとも比較され、以前出力されたことのある既知のメッセージか、新規のメッセージかを判定することができる。例えば、新規のメッセージであった場合には、新規のメッセージをナレッジのテーブルＣへ格納する（図７のステップＳ１９、S２０参照）。このように、サーバ４０から出力されるメッセージが新規のものであった場合の管理（ナレッジへの格納）も自動で行うことで、管理ユーザの管理作業を肩代わりすることで負担を軽減する。

また、第１判定処理の結果、テーブルＡ、Ｂ間でメッセージが一致しない場合、予定されていない想定外のメッセージが出力された可能性があるため確認依頼を要する旨をオペレータへ伝達することになる。このときメッセージ監視サーバ１０によれば、第２、３判定処理によって、テーブルＣとの間においてもメッセージの比較がなされる。従って、想定外のメッセージが出力された状況かどうかということだけでなく、エンジニアがテーブルＢへ誤ったメッセージ（第２メッセージ）を登録した虞がある場合についても判別することができる。尚、エンジニア側のミスであれば、サーバ４０において異常が発生していないため、エンジニアがサーバ４０の調査を実行する必要がなくなる。このようにヒューマンエラーを判別可能な構成とすることで、システム担当者（エンジニア）の負担をより軽減することができる。

上述した実施形態は、発明の理解を容易にするために具体例を示したものであり、本発明はこれらの実施形態に限定されるものではない。上述した管理システム、メッセージ監視サーバ、方法、プログラムは、特許請求の範囲に記載した本発明を逸脱しない範囲において、さまざまな変形、変更が可能である。

１０ メッセージ監視サーバ
１１ 出力メッセージ格納部
１２ 想定メッセージ格納部
１３ ナレッジ
１４ 判定部
１５ 表示制御部
１６ 通信部
１７ コンソール
２０ 保守運用センター
３０ 通信端末
４０ サーバ
５０ データセンター
６０ ＡＴＭ
７０ ホストサーバ
１００ 管理システム
１１１ ＣＰＵ
１１２ ＤＲＡＭ
１１３ ＲＯＭ
１１４ 記憶部
１１５ 入出力ＩＦ
１１６ バス
１１７ 通信ＩＦ

Claims (6)

1. サーバの異常の有無を監視するメッセージ監視サーバであって、
   前記サーバから出力された第１メッセージを格納する出力メッセージ格納部と、
   前記サーバから出力されることが想定される第２メッセージを格納する想定メッセージ格納部と、
   過去に前記サーバから出力された第３メッセージを格納するナレッジと、
   前記第１、第２及び第３メッセージを比較して判定する判定部と、
   前記判定部による判定に基づき、管理ユーザに調査依頼または確認依頼の実施を促す報知手段と、を備え、
   前記判定部は、前記第１メッセージと前記第２メッセージとが一致するかどうかの第１判定処理を実行し、前記第１メッセージと前記第３メッセージとが一致するかどうかの第２判定処理を実行し、前記第２メッセージと前記第３メッセージとが一致するかどうかの第３判定処理を実行し、
   前記報知手段は、前記第１判定処理の結果として、前記第１メッセージと前記第２メッセージとが一致する場合には、前記管理ユーザに調査依頼の実施を促さず、前記第１メッセージと前記第２メッセージとが一致しない場合には、前記第２及び第３判定処理の結果に基づき、前記管理ユーザに前記調査依頼または前記確認依頼の実施を促し、
   前記ナレッジは、前記第１判定処理の結果として、前記第１メッセージと前記第２メッセージとが一致し、かつ前記第２判定処理の結果として、前記第１メッセージと前記第３メッセージとが一致せず、かつ前記第３判定処理の結果として、前記第２メッセージと前記第３メッセージとが一致しない場合に、前記第１メッセージを前記第３メッセージとして格納する
   ことを特徴とするメッセージ監視サーバ。
2. 前記第２メッセージが前記サーバから出力されることが想定される規定の条件を前記第２メッセージ毎に設定し、
   前記判定部は、前記第２メッセージのうち規定の条件となったメッセージを、前記第１及び第３判定処理に用いる
   ことを特徴とする請求項１に記載のメッセージ監視サーバ。
3. 前記規定の条件は、日時である
   ことを特徴とする請求項２に記載のメッセージ監視サーバ。
4. 前記報知手段は、前記第１判定処理の結果として、前記第１メッセージと前記第２メッセージとが一致しない場合であって、
   前記第２判定処理の結果として、前記第１メッセージと前記第３メッセージとが一致せず、前記第３判定処理の結果として、前記第２メッセージと前記第３メッセージとが一致する場合か、または、
   前記第２判定処理の結果として、前記第１メッセージと前記第３メッセージとが一致し、前記第３判定処理の結果として、前記第２メッセージと前記第３メッセージとが一致しない場合には、
   前記管理ユーザに前記第２メッセージの正誤を確認するための前記確認依頼を促す
   ことを特徴とする請求項１乃至請求項３のいずれか１項に記載のメッセージ監視サーバ。
5. サーバから出力された第１メッセージを格納し、
   前記サーバから出力されることが想定される第２メッセージを格納し、
   過去に前記サーバから出力された第３メッセージを格納し、
   前記第１メッセージと前記第２メッセージとが一致するかどうかの第１判定処理を実行し、
   前記第１メッセージと前記第３メッセージとが一致するかどうかの第２判定処理を実行し、
   前記第２メッセージと前記第３メッセージとが一致するかどうかの第３判定処理を実行し、
   前記第１判定処理の結果として、前記第１メッセージと前記第２メッセージとが一致する場合には、管理ユーザに調査依頼の実施を促さず、前記第１メッセージと前記第２メッセージとが一致しない場合には、前記第２判定処理及び第３判定処理の結果に基づき、管理ユーザに前記調査依頼または確認依頼の実施を促し、
   前記第１判定処理の結果として、前記第１メッセージと前記第２メッセージとが一致し、かつ前記第２判定処理の結果として、前記第１メッセージと前記第３メッセージとが一致せず、かつ前記第３判定処理の結果として、前記第２メッセージと前記第３メッセージとが一致しない場合に、前記第１メッセージを前記第３メッセージとして格納する
   ことを特徴とするメッセージ監視方法。
6. サーバから出力された第１メッセージを格納し、
   前記サーバから出力されることが想定される第２メッセージを格納し、
   過去に前記サーバから出力された第３メッセージを格納し、
   前記第１メッセージと前記第２メッセージとが一致するかどうかの第１判定処理を実行し、
   前記第１メッセージと前記第３メッセージとが一致するかどうかの第２判定処理を実行し、
   前記第２メッセージと前記第３メッセージとが一致するかどうかの第３判定処理を実行し、
   前記第１判定処理の結果として、前記第１メッセージと前記第２メッセージとが一致する場合には、管理ユーザに調査依頼の実施を促さず、前記第１メッセージと前記第２メッセージとが一致しない場合には、前記第２判定処理及び第３判定処理の結果に基づき、管理ユーザに前記調査依頼または確認依頼の実施を促し、
   前記第１判定処理の結果として、前記第１メッセージと前記第２メッセージとが一致し、かつ前記第２判定処理の結果として、前記第１メッセージと前記第３メッセージとが一致せず、かつ前記第３判定処理の結果として、前記第２メッセージと前記第３メッセージとが一致しない場合に、前記第１メッセージを前記第３メッセージとして格納する
   処理をコンピュータへ実行させることを特徴とするプログラム。