特許 7208505 判定方法、情報処理装置および判定プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-01-11

(45)【発行日】2023-01-19

(54)【発明の名称】判定方法、情報処理装置および判定プログラム

(51)【国際特許分類】

   G06F 11/07 20060101AFI20230112BHJP

【ＦＩ】

G06F11/07 193

G06F11/07 140A

【請求項の数】 9

(21)【出願番号】P 2019043537

(22)【出願日】2019-03-11

(65)【公開番号】P2020149090

(43)【公開日】2020-09-17

【審査請求日】2021-12-08

(73)【特許権者】

【識別番号】000005223

【氏名又は名称】富士通株式会社

(74)【代理人】

【識別番号】110002918

【氏名又は名称】弁理士法人扶桑国際特許事務所

(72)【発明者】

【氏名】下邨 正裕

(72)【発明者】

【氏名】高原 真幸

(72)【発明者】

【氏名】吉川 大貴

(72)【発明者】

【氏名】北山 亨

(72)【発明者】

【氏名】森 敏嗣

(72)【発明者】

【氏名】福田 雅広

(72)【発明者】

【氏名】梅澤 侑生

(72)【発明者】

【氏名】長谷尾 慎司

【審査官】金田 孝之

(56)【参考文献】

【文献】特開２０１２－２３４３８１（ＪＰ，Ａ）

【文献】特開２０１７－１１１６０１（ＪＰ，Ａ）

【文献】特開２０１２－０５９０６３（ＪＰ，Ａ）

【文献】特表平１０－５１０６５１（ＪＰ，Ａ）

【文献】特開２０１４－１０６８５１（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ １１／０７

Ｇ０６Ｆ １１／２８－１１／３６

(57)【特許請求の範囲】

【請求項1】

コンピュータが、
装置から出力されたメッセージにもとづき、前記メッセージが示す前記装置への対処要否を判定する第１の判定処理を行い、
前記第１の判定処理によって対処不要と判定した場合、前記メッセージの出力前の特定期間に前記装置により実行された処理内容を特定し、
特定した前記処理内容にもとづき、前記メッセージが示す前記装置への対処要否を判定する第２の判定処理を行う、
判定方法。

【請求項2】

前記第１の判定処理では、対処要とするメッセージパターンがあらかじめ登録されたフィルタ定義にもとづいて、前記メッセージを対処要メッセージか、対処不要メッセージかにフィルタリングして振り分けるメッセージ解析を行い、前記第２の判定処理では、前記メッセージ解析によって対処不要と判定された前記メッセージに対して判定する請求項１記載の判定方法。

【請求項3】

前記第２の判定処理では、前記装置に対して対処要となる変更操作内容を登録しておき、登録した前記変更操作内容のうちに、特定した前記処理内容が存在することを検出した場合、前記メッセージを対処要と判定する請求項１記載の判定方法。

【請求項4】

前記第２の判定処理では、前記装置のミドルウェア、ＯＳ（Operating System）およびファイルの少なくとも１つを変更する変更操作コマンドを登録しておき、登録した前記変更操作コマンドのうちに、特定した前記処理内容のコマンドが存在することを検出した場合、前記メッセージを対処要と判定する請求項３記載の判定方法。

【請求項5】

前記第２の判定処理では、特定した前記処理内容が前記装置の性能異常である場合、前記メッセージを対処要と判定する請求項１記載の判定方法。

【請求項6】

前記第２の判定処理では、前記装置のプロセッサの使用率エラー、前記装置の記憶デバイスの使用率エラーおよび前記装置の通信ネットワークの接続エラーの少なくとも１つの前記性能異常を検出した場合、前記メッセージを対処要と判定する請求項５記載の判定方法。

【請求項7】

前記コンピュータは、さらに、
前記装置に前記第２の判定処理を行って前記メッセージを対処不要と判定した場合、前記装置の運用に関連して使用される関連装置がある場合は前記関連装置に対して前記第２の判定処理を行う、
請求項１記載の判定方法。

【請求項8】

装置から出力されたメッセージにもとづき、前記メッセージが示す前記装置への対処要否を判定する第１の判定処理を行い、前記第１の判定処理によって対処不要と判定した場合、前記メッセージの出力前の特定期間に前記装置により実行された処理内容を特定し、特定した前記処理内容にもとづき、前記メッセージが示す前記装置への対処要否を判定する第２の判定処理を行う制御部、
を有する情報処理装置。

【請求項9】

コンピュータに、
装置から出力されたメッセージにもとづき、前記メッセージが示す前記装置への対処要否を判定する第１の判定処理を行い、
前記第１の判定処理によって対処不要と判定した場合、前記メッセージの出力前の特定期間に前記装置により実行された処理内容を特定し、
特定した前記処理内容にもとづき、前記メッセージが示す前記装置への対処要否を判定する第２の判定処理を行う、
処理を実行させる判定プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、判定方法、情報処理装置および判定プログラムに関する。

【背景技術】

【0002】

情報処理システムには、管理サーバが設けられて、管理サーバによってシステム全体の運用管理が行われる。また、情報処理システム内の各装置は、個々に何らかの事象を検出すると、その事象を知らせるためのメッセージを管理サーバへ送信する。管理サーバは、各装置から送信されたメッセージを受信するとメッセージ解析を行って、発生した事象の対処の要否を判定する。

【0003】

関連する技術としては、例えば、入手した障害メッセージに含まれる単語の出現確率から重大障害か非重大障害かを判定する技術が提案されている。また、メッセージのパターン照合時に定義に含まれない内容のイベントを抽出して、該イベントの発生を監視させる技術が提案されている。

【0004】

さらに、運転状況メッセージをパターンファイルの個々のパターンと比較して、障害メッセージとそれ以外のメッセージを区別して利用者に通知する技術が提案されている。さらにまた、情報文書を正例と負例に振り分けるテキストマイニングによって有用文書を抽出する技術が提案されている。

【先行技術文献】

【特許文献】

【0005】

【文献】特開２０１７－１４２５４９号公報

【文献】特開２０１２－２３４３８１号公報

【文献】特開２００１－２９２１４３号公報

【文献】特開２０１７－１０７３９１号公報

【発明の概要】

【発明が解決しようとする課題】

【0006】

上記の管理サーバは、受信したメッセージが対処を要するメッセージと判定した場合、そのメッセージを画面に出力して管理者へ通知する。これにより、管理者は、通知されたメッセージにもとづいて、システムに生じた不具合等の事象を解消するための保守作業を行うことができる。

【0007】

しかし、従前のメッセージ解析にもとづく判定処理では、管理サーバの配下の装置から送信されたメッセージが初めて受信する未知メッセージまたは未定義メッセージである場合、運用上対処を要する事象であるにもかかわらず対処不要と誤判定してしまう可能性がある。この場合、対処要のメッセージが管理者へ通知されず、対処すべき事象の発生の通知漏れが生じてしまう。

【0008】

１つの側面では、本発明は、対処すべき事象の発生の通知漏れの抑制を図った判定方法、情報処理装置および判定プログラムを提供することを目的とする。

【課題を解決するための手段】

【0009】

上記課題を解決するために、判定方法が提供される。判定方法は、コンピュータが、装置から出力されたメッセージにもとづき、メッセージが示す装置への対処要否を判定する第１の判定処理を行い、第１の判定処理によって対処不要と判定した場合、メッセージの出力前の特定期間に装置により実行された処理内容を特定し、特定した処理内容にもとづき、メッセージが示す装置への対処要否を判定する第２の判定処理を行う。

【0010】

また、上記課題を解決するために、上記判定方法と同様の制御を実行する情報処理装置が提供される。
さらに、上記課題を解決するために、コンピュータに上記判定方法と同様の制御を実行させる判定プログラムが提供される。

【発明の効果】

【0011】

１側面によれば、対処すべき事象の発生の通知漏れを抑制できる。

【図面の簡単な説明】

【0012】

【図1】情報処理装置の一例を説明するための図である。

【図2】情報処理システムの一構成例を示す図である。

【図3】運用管理サーバのハードウェアの一構成例を示す図である。

【図4】情報処理システムの機能ブロックの一例を示す図である。

【図5】構成管理ＤＢの格納情報の一例を示す図である。

【図6】ＭＷ変更操作コマンドＤＢの格納情報の一例を示す図である。

【図7】ＯＳ変更操作コマンドＤＢの格納情報の一例を示す図である。

【図8】ファイル変更操作コマンドＤＢの格納情報の一例を示す図である。

【図9】通知用ＤＢの格納情報の一例を示す図である。

【図10】運用管理サーバの全体動作の一例を示すフローチャートである。

【図11】変更操作の有無にもとづく対処要メッセージの検出処理の動作例を示すフローチャートである。

【図12】性能異常の有無にもとづく対処要メッセージの検出処理の動作例を示すフローチャートである。

【図13】関連サーバを監視対象としたときの動作例を示すフローチャートである。

【図14】通知用ＤＢの格納状態の一例を示す図である。

【図15】通知用ＤＢの格納状態の一例を示す図である。

【図16】メッセージ収集画面の一例を示す図である。

【図17】コマンドヒストリテーブルの一例を示す図である。

【図18】性能状態テーブルの一例を示す図である。

【発明を実施するための形態】

【0013】

以下、本実施の形態について図面を参照して説明する。
［第１の実施の形態］
第１の実施の形態について図１を用いて説明する。図１は、情報処理装置の一例を説明するための図である。情報処理装置１は、制御部１ａと、記憶部１ｂを備える。情報処理装置１には、装置２が接続されている。情報処理装置１は例えば、管理サーバに該当し、装置２は例えば、管理サーバ配下のサーバに該当する。

【0014】

装置２において何らかの事象が検出された場合、装置２から情報処理装置１へメッセージｍ１が送信される。制御部１ａは、装置２から出力されたメッセージｍ１を受信する。記憶部１ｂは、制御部１ａで受信されたメッセージを格納する。

【0015】

制御部１ａは、メッセージｍ１を受信すると、メッセージｍ１は装置２で検出された事象に対して対処を要することを示すメッセージなのか、または対処不要のメッセージなのかを判定するための判定処理を行う。

【0016】

この判定処理には、第１の判定処理と第２の判定処理の２段階の判定処理が含まれる。制御部１ａは、最初に第１の判定処理を行ってメッセージｍ１の対処要否を判定する。第１の判定処理でメッセージｍ１が対処要と判定された場合、対処要である旨が制御部１ａによって通知される。また、第１の判定処理で対処不要と判定された場合、第２の判定処理が行われる。

【0017】

制御部１ａは、第１の判定処理によってメッセージｍ１を対処不要と判定した場合、メッセージｍ１が装置２から出力される前の特定期間に装置２に実行された処理内容を特定し、特定した処理内容にもとづき、メッセージｍ１が示す装置２への対処要否を判定する第２の判定処理を行う。第２の判定処理でメッセージｍ１が対処要と判定された場合、対処要である旨が制御部１ａによって通知される。

【0018】

図１に示す例を用いて動作について説明する。
〔ステップＳ１〕装置２から情報処理装置１にメッセージｍ１が送信される。制御部１ａは、メッセージｍ１を受信し、記憶部１ｂにメッセージｍ１を格納する。

【0019】

〔ステップＳ２〕制御部１ａは、メッセージｍ１に対して第１の判定処理を実行する。第１の判定処理としては例えば、メッセージ解析が行われる。メッセージ解析では、対処要とするメッセージパターンがフィルタ定義にあらかじめ登録されており、このフィルタ定義にもとづいて、メッセージｍ１を対処要メッセージか、対処不要メッセージかにフィルタリングして振り分ける処理が行われる。

【0020】

〔ステップＳ３〕第１の判定処理によってメッセージｍ１が対処不要と判定された場合はステップＳ４へ処理が進み、対処要と判定された場合はステップＳ８へ処理が進む。
〔ステップＳ４〕制御部１ａは、第１の判定処理で対処不要と判定されたメッセージｍ１に対し、第２の判定処理を実行する。第２の判定処理では、メッセージｍ１が装置２から出力される前の（制御部１ａがメッセージｍ１を受信する前の）特定期間に装置２に実行された処理内容を特定し、特定した処理内容にもとづいてメッセージｍ１が示す装置２への対処要否を再判定する。また、第２の判定処理には、以下のステップＳ５、Ｓ６に示すような、変更操作および性能異常の有無にもとづく対処要メッセージの検出処理が含まれる。

【0021】

〔ステップＳ５〕制御部１ａは、装置２に対して対処要となる変更操作内容をあらかじめ登録しておき、登録した変更操作内容のうちに、特定した処理内容が存在するか否かの検出処理を行う。登録した変更操作内容のうちに、特定した処理内容が存在する場合はステップＳ８へ処理が進み、存在しない場合はステップＳ６へ処理が進む。

【0022】

〔ステップＳ６〕制御部１ａは、特定した処理内容が装置２の性能異常であるか否かの検出処理を行う。特定した処理内容が装置２の性能異常である場合はステップＳ８へ処理が進み、性能異常でない場合はステップＳ７へ処理が進む。

【0023】

〔ステップＳ７〕制御部１ａは、メッセージｍ１は対処不要と判定し、対処不要の判定結果を表示等によって通知する。
〔ステップＳ８〕制御部１ａは、メッセージｍ１は対処要と判定し、対処要の判定結果を表示等によって通知する。

【0024】

このように、情報処理装置１は、第１の判定処理によってメッセージｍ１を対処不要と判定した場合、メッセージｍ１の受信前の特定期間に装置２に実行された処理内容を特定し、特定した処理内容にもとづいてメッセージｍ１が示す装置２への対処要否を再判定する第２の判定処理を行う。

【0025】

これにより、第１の判定処理で対処不要と判定されたメッセージのうちから、第２の判定処理によって実際は運用上対処要であるメッセージを拾い上げることができる。したがって、フィルタ定義に未登録なメッセージが第１の判定処理をすり抜けても、フィルタ定義にもとづくメッセージ解析とは異なる第２の判定処理によって再判定が行われることにより、誤判定を防止することができ、また対処すべき事象の発生の通知漏れを抑制することが可能になる。

【0026】

［第２の実施の形態］
次に本発明の機能を情報処理システムに適用した第２の実施の形態について、以降詳しく説明する。図２は、情報処理システムの一構成例を示す図である。情報処理システム１－１は、運用管理サーバ１０、監視対象サーバ２０、関連サーバ３０－１、・・・、３０－ｎおよび保守端末４０を備える。運用管理サーバ１０は、ネットワーク１１０を介して、監視対象サーバ２０と関連サーバ３０－１、・・・、３０－ｎに接続されている。

【0027】

運用管理サーバ１０は、監視対象サーバ２０と関連サーバ３０－１、・・・、３０－ｎの運用管理を行う。監視対象サーバ２０は、運用管理サーバ１０の監視対象となったサーバであり、例えば、社内の業務データの管理を行う業務サーバに相当する。

【0028】

関連サーバ３０－１、・・・、３０－ｎは、監視対象サーバ２０の運用に関連して使用されるサーバである。例えば、関連サーバ３０－１、・・・、３０－ｎは、ＤＢ（Database）管理を行うＤＢサーバ、アプリケーションの実行管理を行うＡＰ（Application）サーバ、Ｗｅｂサイトの管理を行うＷｅｂサーバ等に相当する。

【0029】

情報処理システム１－１では、監視対象サーバ２０および関連サーバ３０－１、・・・、３０－ｎにおいて何らかの事象が検出されると、その事象を示すメッセージが運用管理サーバ１０に送信される。運用管理サーバ１０は、図１の情報処理装置１の機能を備えており、送信されたメッセージを受信すると、発生した事象が対処を要するのか、または対処が不要なのかの判定処理を行い、判定結果を保守端末４０へ送信する。

【0030】

＜ハードウェア＞
図３は、運用管理サーバのハードウェアの一構成例を示す図である。運用管理サーバ１０は、プロセッサ１０１によって装置全体が制御されている。すなわち、プロセッサ１０１は、運用管理サーバ１０の制御部として機能する。プロセッサ１０１には、バス１０９を介してメモリ１０２と複数の周辺機器が接続されている。プロセッサ１０１は、マルチプロセッサであってもよい。

【0031】

プロセッサ１０１は、例えばＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、またはＤＳＰ（Digital Signal Processor）である。プロセッサ１０１の機能の少なくとも一部を、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）等の電子回路で実現してもよい。

【0032】

メモリ１０２は、運用管理サーバ１０の主記憶装置として使用される。メモリ１０２には、プロセッサ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、メモリ１０２には、プロセッサ１０１による処理に必要な各種データが格納される。メモリ１０２としては、例えばＲＡＭ（Random Access Memory）等の揮発性の半導体記憶装置が使用される。

【0033】

バス１０９に接続されている周辺機器としては、ＨＤＤ（Hard Disk Drive）１０３、グラフィック処理装置１０４、入力インタフェース１０５、光学ドライブ装置１０６、機器接続インタフェース１０７およびネットワークインタフェース１０８がある。

【0034】

ＨＤＤ１０３は、内蔵したディスクに対して、磁気的にデータの書き込みおよび読み出しを行う。ＨＤＤ１０３は、運用管理サーバ１０の補助記憶装置として使用される。ＨＤＤ１０３には、ＯＳのプログラム、アプリケーションプログラム、および各種データが格納される。なお補助記憶装置としては、フラッシュメモリ等の不揮発性の半導体記憶装置を使用することもできる。

【0035】

グラフィック処理装置１０４には、モニタ２０１が接続されている。グラフィック処理装置１０４は、プロセッサ１０１からの命令に従って、画像をモニタ２０１の画面に表示させる。モニタ２０１としては、ＣＲＴ（Cathode Ray Tube）を用いた表示装置や液晶表示装置等がある。

【0036】

入力インタフェース１０５には、キーボード２０２とマウス２０３とが接続されている。入力インタフェース１０５は、キーボード２０２やマウス２０３から送られてくる信号をプロセッサ１０１に送信する。

【0037】

なお、マウス２０３はポインティングデバイスの一例であり、他のポインティングデバイスを使用することもできる。他のポインティングデバイスとしては、タッチパネル、タブレット、タッチパッド、トラックボール等がある。

【0038】

光学ドライブ装置１０６は、レーザ光等を利用して、光ディスク２０４に記録されたデータの読み取りを行う。光ディスク２０４は、光の反射によって読み取り可能なようにデータが記録された可搬型の記録媒体である。光ディスク２０４には、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ－ＲＡＭ、ＣＤ－ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ－Ｒ（Recordable）／ＲＷ（Re Writable）等がある。

【0039】

機器接続インタフェース１０７は、運用管理サーバ１０に周辺機器を接続するための通信インタフェースである。例えば機器接続インタフェース１０７には、メモリ装置２０５やメモリリーダライタ２０６を接続することができる。メモリ装置２０５は、機器接続インタフェース１０７との通信機能を搭載した記録媒体である。メモリリーダライタ２０６は、メモリカード２０７へのデータの書き込み、またはメモリカード２０７からのデータの読み出しを行う装置である。メモリカード２０７は、カード型の記録媒体である。

【0040】

ネットワークインタフェース１０８は、ネットワーク１１０に接続されている。ネットワークインタフェース１０８は、ネットワーク１１０を介して、監視対象サーバ２０や関連サーバ３０－１、・・・、３０－ｎ、または他のコンピュータや通信機器との間でデータの送受信を行う。

【0041】

以上のようなハードウェア構成によって、第２の実施の形態の処理機能を実現することができる。なお、第１の実施の形態に示した情報処理装置１も、図３に示した運用管理サーバ１０と同様のハードウェアにより実現することができる。

【0042】

運用管理サーバ１０は、例えばコンピュータ読み取り可能な記録媒体に記録されたプログラムを実行することにより、第２の実施の形態の処理機能を実現する。運用管理サーバ１０に実行させる処理内容を記述したプログラムは、様々な記録媒体に記録しておくことができる。

【0043】

例えば、運用管理サーバ１０に実行させるプログラムをＨＤＤ１０３に格納しておくことができる。プロセッサ１０１は、ＨＤＤ１０３内のプログラムの少なくとも一部をメモリ１０２にロードし、プログラムを実行する。また運用管理サーバ１０に実行させるプログラムを、光ディスク２０４、メモリ装置２０５、メモリカード２０７等の可搬型記録媒体に記録しておくこともできる。

【0044】

可搬型記録媒体に格納されたプログラムは、例えばプロセッサ１０１からの制御により、ＨＤＤ１０３にインストールされた後、実行可能となる。またプロセッサ１０１が、可搬型記録媒体から直接プログラムを読み出して実行することもできる。

【0045】

＜機能ブロック＞
図４は、情報処理システムの機能ブロックの一例を示す図である。ネットワーク１１０の図示は省略している。また、以降では、関連サーバ３０－１、・・・、３０－ｎを総称する場合、関連サーバ３０と呼ぶ。

【0046】

監視対象サーバ２０は、ログ管理部２１とメッセージ送信部２２を有する。ログ管理部２１は、監視対象サーバ２０の動作のログ（記録情報）を管理する。ログ管理部２１は例えば、システムログ２１ａ、アプリログ２１ｂ、ＭＷ（Middleware）ログ２１ｃおよび性能ログ２１ｄを管理する。

【0047】

システムログ２１ａは、監視対象サーバ２０のＯＳにもとづくログであり、例えば、プログラムの起動や終了、管理者のログオン／ログオフ、ハードウェアまたはソフトウェアで発生したエラー等がある。アプリログ２１ｂは、アプリケーションの動作中の挙動に関するログであり、例えば、アプリケーションを実行したときのプロセスの起動や終了、アプリケーションの実行状態およびファイルの操作状態等がある。

【0048】

ＭＷログ２１ｃは、監視対象サーバ２０で実行されるミドルウェアに関するログであり、例えば、ミドルウェアのコマンド実行結果やミドルウェアのエラー等がある。性能ログ２１ｄは、監視対象サーバ２０の性能に関するログであり、例えば、ＣＰＵや記憶デバイスの使用率、監視対象サーバ２０が通信するネットワークの接続状態、単位時間当たりのＣＰＵアクセス数およびレスポンスタイム等がある。

【0049】

メッセージ送信部２２は、ログ管理部２１で管理されている各種ログから何らかの事象の発生を検知した場合、検知した事象を示すメッセージを生成して、上位の運用管理サーバ１０にメッセージを送信する。

【0050】

関連サーバ３０は、ログ管理部３１とメッセージ送信部３２を有する。ログ管理部３１は例えば、関連サーバ３０内のシステムログ３１ａ、アプリログ３１ｂ、ＭＷログ３１ｃおよび性能ログ３１ｄを管理する。なお、ログ管理部３１で管理される各種ログおよびメッセージ送信部３２の動作は、監視対象サーバ２０の上記の構成要素と同じなので説明は省略する。

【0051】

運用管理サーバ１０は、制御部１１、記憶部１２、メッセージ受信部１３および出力表示部１４を有する。メッセージ受信部１３は、監視対象サーバ２０や関連サーバ３０から送信されたメッセージの受信処理を行い、受信したメッセージを制御部１１へ送信する。

【0052】

制御部１１は、受信したメッセージの属性等を記憶部１２内の通知用ＤＢ１２ａに格納する。また、制御部１１は、受信したメッセージに対して判定処理ｐ１（第１の判定処理）を行い、対処の要否を通知用ＤＢ１２ａに登録する。さらに、制御部１１は、判定処理ｐ１で対処要と判定したメッセージを出力表示部１４へ送信する。

【0053】

判定処理ｐ１ではメッセージ解析が行われる。メッセージ解析では、対処要となるメッセージパターンがあらかじめ登録されたフィルタ定義にもとづき、フィルタ定義にマッチングしたメッセージを対処要とし、マッチングしなかったメッセージを対処不要と判定する処理が行われる。

【0054】

なお、上記のメッセージ解析を機械学習で行うこともできる。すなわち、受信したメッセージから対処要否の規則性を見つけ、その規則性を自動化する機械学習にもとづくメッセージ解析によって、メッセージの対処要否を判定するといった処理を行ってもよい。

【0055】

一方、制御部１１は、判定処理ｐ１によって通知用ＤＢ１２ａに対処不要と登録されたメッセージに対しては判定処理ｐ２（第２の判定処理）を行う。判定処理ｐ２では、判定処理ｐ１によって対処不要と判定されたメッセージに対して、メッセージの受信前の特定期間に監視対象サーバ２０または関連サーバ３０に実行された処理内容を特定し、特定した処理内容にもとづいてメッセージの対処要否の再判定を行う。

【0056】

また、判定処理ｐ２には、変更操作の有無にもとづく対処要メッセージの検出処理ｐ２１および性能異常の有無にもとづく対処要メッセージの検出処理ｐ２２が含まれる（判定処理ｐ２の詳細は後述）。そして、制御部１１は、対処の要否を通知用ＤＢ１２ａに登録し、判定処理ｐ２で対処要と判定したメッセージを検出した場合、そのメッセージを出力表示部１４へ送信する。

【0057】

出力表示部１４は、システム全体の運用状態やメッセージの対処要否を保守端末４０に出力表示する。例えば、出力表示部１４は、制御部１１から送信されたメッセージを保守端末４０のコンソール画面に出力する表示制御を行って、対処要のメッセージを管理者に通知する。

【0058】

このように、運用管理サーバ１０に上がってきたメッセージに対して、制御部１１が２段階の判定処理を行って、対処要のメッセージの通知漏れの抑制を図る。なお、制御部１１は、メッセージを受信したことを契機に判定処理ｐ１、ｐ２を実行してもよいし、保守端末４０からの実行指示を受けてから判定処理ｐ１、ｐ２を実行してもよい。

【0059】

記憶部１２は、通知用ＤＢ１２ａと参照用ＤＢ１２ｂを有する。参照ＤＢ１２ｂは、構成管理ＤＢ１２ｂ１、ＭＷ変更操作コマンドＤＢ１２ｂ２、ＯＳ変更操作コマンドＤＢ１２ｂ３およびファイル変更操作コマンドＤＢ１２ｂ４を含む。

【0060】

通知用ＤＢ１２ａは、メッセージの属性として、メッセージ、該メッセージを受信した日時および該メッセージの発信元を格納する。また、通知用ＤＢ１２ａは、監視対象サーバ２０または関連サーバ３０に変更操作が行われたときのコマンド名や性能異常が生じた箇所、および対処の要否を格納する。

【0061】

構成管理ＤＢ１２ｂ１は、監視対象サーバ２０と関連サーバ３０間の関連性を格納する。ＭＷ変更操作コマンドＤＢ１２ｂ２は、ＭＷのコマンドのうち変更操作を伴うコマンド名を格納する。ＯＳ変更操作コマンドＤＢ１２ｂ３は、ＯＳのコマンドのうち変更操作を伴うコマンド名を格納する。ファイル変更操作コマンドＤＢ１２ｂ４は、ファイルの変更操作を伴うコマンド名およびファイルの変更操作の実行対象を格納する。各ＤＢの格納情報の例については図５から図９で後述する。

【0062】

なお、制御部１１は図３のプロセッサ１０１によって実現され、記憶部１２は図３のメモリ１０２によって実現される。また、メッセージ受信部１３は、図３のネットワークインタフェース１０８によって実現され、出力表示部１４は、図３のグラフィック処理装置１０４で実現される。

【0063】

＜ＤＢの格納情報＞
次に運用管理サーバ１０の記憶部１２内の各ＤＢの格納情報の例について、図５から図９を用いて説明する。図５は、構成管理ＤＢの格納情報の一例を示す図である。構成管理ＤＢ１２ｂ１は、監視対象サーバおよび関連サーバの項目を有し、運用管理サーバ１０で監視対象となるサーバの識別子と、そのサーバに関連するサーバの識別子とが対になった関連サーバ情報が格納されるＤＢである。

【0064】

図５の例では、監視対象サーバがサーバＳＶ０ならば、その関連サーバはサーバＳＶ１、ＳＶ２であることが示されている。また、監視対象サーバがサーバＳＶ１になった場合は、その関連サーバはサーバＳＶ０であり、監視対象サーバがサーバＳＶ２になった場合は、その関連サーバはサーバＳＶ０になることが示されている。

【0065】

図６は、ＭＷ変更操作コマンドＤＢの格納情報の一例を示す図である。ＭＷ変更操作コマンドＤＢ１２ｂ２は、ＭＷ変更操作コマンドの項目を有し、ミドルウェアの変更操作を伴うコマンドが事前に格納されるＤＢである。図６の例では、ＭＷ変更操作コマンドとして、／ｏｐｔ／ＦＪＳＶｆｗｓｅｃ／ｂｉｎ／ｍｐｓｅｔｍｅｍ＊＊＊が格納されている。

【0066】

図７は、ＯＳ変更操作コマンドＤＢの格納情報の一例を示す図である。ＯＳ変更操作コマンドＤＢ１２ｂ３は、ＯＳ変更操作コマンドの項目を有して、ＯＳの変更操作を伴うコマンドが事前に格納されるＤＢである。図７の例では、ＯＳ変更操作コマンドとして、／ｅｔｃ／ｒｃ．ｄ／ｉｎｉｔ．ｄ／ｉｐｔａｂｌｅｓｓｔａｒｔおよびｋｉｌｌ（実行しているプロセスを終了するコマンド）が格納されている。

【0067】

図８は、ファイル変更操作コマンドＤＢの格納情報の一例を示す図である。ファイル変更操作コマンドＤＢ１２ｂ４は、ファイル変更操作コマンドおよびファイル変更操作実行対象の項目を有して、ファイルの変更操作を伴うコマンドが事前に格納されるＤＢである。図８の例では、Ｌｉｎｕｘ(登録商標）のコマンドを示しており、ファイル変更操作コマンドとして、ｃｐ、ｍｖ、ｃｈｍｏｄ、ｒｍ、ｖｉのコマンドが格納されている。

【0068】

ｃｐはファイルをコピーするコマンド、ｍｖはファイルを移動するコマンド、ｃｈｍｏｄはファイルのパーミッションを変更するコマンドである。また、ｒｍはファイルを削除するコマンド、ｖｉはテキストエディタを起動するコマンドである。

【0069】

なお、ｃｐコマンドのファイル変更操作実行対象は、／ｅｔｃ／＊＊＊となっており、ｃｐコマンドの定義ファイルは、／ｅｔｃ／＊＊＊のディレクトリにあることが示されている。ｍｖコマンドのファイル変更操作実行対象は、／ｏｐｔ／＃＃＃となっており、ｍｖコマンドの定義ファイルは、／ｏｐｔ／＃＃＃のディレクトリにあることが示されている。ｃｈｍｏｄコマンドのファイル変更操作実行対象は、７５５となっており、ｃｈｍｏｄコマンドによって、７５５のファイルのパーミッションに変更されることが示されている。

【0070】

図９は、通知用ＤＢの格納情報の一例を示す図である。通知用ＤＢ１２ａは、日時、メッセージ、発信元、監視対象サーバ変更操作、監視対象サーバ性能異常、関連サーバ、関連サーバ変更操作、関連サーバ性能異常および対処の要否の項目を有する。

【0071】

欄ＣＬ１において、２０１８年１０月１２日の０９時３３分１２秒にメッセージａｂｃが運用管理サーバ１０で受信され、メッセージａｂｃの発信元は、監視対象サーバ２０内のミドルウェアＭｐＡｏｓｆｖになっている。また、監視対象サーバ２０にはｋｉｌｌ１２８のコマンドが入力されている。よって、監視対象サーバ２０は、コマンドによって変更操作が行われているため、メッセージａｂｃは、対処要と判定される。

【0072】

欄ＣＬ２において、２０１８年１０月１２日の１０時００分１２秒にメッセージｄｅｆが運用管理サーバ１０で受信され、メッセージｄｅｆの発信元は、監視対象サーバ２０内のミドルウェアＭｐＡｏｓｆｖになっている。また、監視対象サーバ２０のＣＰＵに性能異常が生じている。よって、監視対象サーバ２０は、性能異常が生じているため、メッセージｄｅｆは、対処要と判定される。

【0073】

欄ＣＬ３において、２０１８年１０月１２日の１０時３５分１２秒にメッセージｇｈｉが運用管理サーバ１０で受信され、メッセージｇｈｉの発信元は、関連サーバＳＶ１内のミドルウェアＡＰＰＭＧＲになっている。また、関連サーバＳＶ１にはｖｉ＊＊＊のコマンドが入力されている。よって、関連サーバＳＶ１は、コマンドによってファイル変更操作が行われているため、メッセージｇｈｉは、対処要と判定される。

【0074】

欄ＣＬ４において、２０１８年１０月１２日の１１時１５分１２秒にメッセージｊｋｌが運用管理サーバ１０で受信され、メッセージｊｋｌの発信元は、関連サーバＳＶ２内のミドルウェアＡＰＰＭＧＲになっている。また、関連サーバＳＶ２のＣＰＵに性能異常が生じている。よって、関連サーバＳＶ２は、性能異常が生じているため、メッセージｊｋｌは、対処要と判定される。

【0075】

欄ＣＬ５において、２０１８年１０月１２日の１２時２５分１２秒にメッセージｍｎｏが運用管理サーバ１０で受信され、メッセージｍｎｏの発信元は、監視対象サーバ２０内のミドルウェアＡＰＰＭＧＲになっている。また、監視対象サーバ２０には、変更操作が行われるコマンドの入力がなく、かつ性能異常の発生もない。よって、メッセージｍｎｏは、対処不要と判定される。

【0076】

＜フローチャート＞
次に運用管理サーバ１０の動作について、図１０から図１３のフローチャートを用いて説明する。図１０は、運用管理サーバの全体動作の一例を示すフローチャートである。

【0077】

〔ステップＳ１０〕制御部１１は、メッセージを受信すると、メッセージの属性として、メッセージ、該メッセージを受信した日時および該メッセージの発信元を通知用ＤＢ１２ａに格納する。

【0078】

〔ステップＳ１１〕制御部１１は、メッセージに対して判定処理ｐ１を実行する。
〔ステップＳ１２〕判定処理ｐ１によってメッセージが対処不要と判定された場合はステップＳ１３へ処理が進み、判定処理ｐ１によってメッセージが対処要と判定された場合はステップＳ１８へ処理が進む。

【0079】

〔ステップＳ１３〕制御部１１は、判定処理ｐ１で対処不要と判定されたメッセージに対し、ステップＳ１３からステップＳ１７を通じて判定処理ｐ２を実行する。制御部１１は、判定処理ｐ２のうちの変更操作の有無にもとづく対処要メッセージの検出処理ｐ２１を行う（詳細は図１１で後述）。

【0080】

〔ステップＳ１４〕制御部１１は、変更操作の有無にもとづく対処要メッセージの検出処理ｐ２１を実行することによって、通知用ＤＢ１２ａの監視対象サーバ変更操作の項目に変更操作コマンドが格納されたか否かを判断する。変更操作コマンドが格納されている場合はステップＳ１８へ処理が進み、変更操作コマンドが格納されていない場合はステップＳ１５へ処理が進む。

【0081】

〔ステップＳ１５〕制御部１１は、判定処理ｐ２のうちの性能異常の有無にもとづく対処要メッセージの検出処理ｐ２２を行う（詳細は図１２で後述）。
〔ステップＳ１６〕制御部１１は、性能異常の有無にもとづく対処要メッセージの検出処理ｐ２２を実行することによって、通知用ＤＢ１２ａの監視対象サーバ性能異常の項目に性能異常箇所が格納されたか否かを判断する。性能異常箇所が格納されている場合はステップＳ１８へ処理が進み、性能異常箇所が格納されていない場合はステップＳ１７へ処理が進む。

【0082】

〔ステップＳ１７〕制御部１１は、監視対象サーバ２０の処理内容からはメッセージが対処要となる状態を検出しなかったため、関連サーバ３０に対して判定処理ｐ２を実行する（図１３で後述）。

【0083】

〔ステップＳ１８〕制御部１１は、通知用ＤＢ１２ａにおけるメッセージの対処の要否の項目に対処要を登録する。
〔ステップＳ１９〕制御部１１は、通知用ＤＢ１２ａに対処要が登録されたメッセージを出力表示部１４へ送信する。対処要と判定されたメッセージは、出力表示部１４によって保守端末４０に送信されて表示される。

【0084】

図１１は、変更操作の有無にもとづく対処要メッセージの検出処理の動作例を示すフローチャートである。
〔ステップＳ１３ａ〕制御部１１は、監視対象サーバ２０に入力されたコマンドのヒストリ（履歴）を収集する。すなわち、制御部１１は、監視対象サーバ２０内のログ管理部２１で管理されているシステムログ２１ａ、アプリログ２１ｂおよびＭＷログ２１ｃのそれぞれからコマンドヒストリを収集する。

【0085】

〔ステップＳ１３ｂ〕制御部１１は、コマンドヒストリから、メッセージ受信前の特定期間（例えば、メッセージを受信する直前）に入力されたコマンドを取得する。
〔ステップＳ１３ｃ〕制御部１１は、取得したコマンドが１つ以上存在するか否かを判断する。コマンドを１つ以上取得した場合はステップＳ１３ｄへ処理が進み、コマンドを１つも取得できない場合は図１０のステップＳ１４へ処理が進む。

【0086】

〔ステップＳ１３ｄ〕制御部１１は、参照用ＤＢ１２ｂ内のＭＷ変更操作コマンドＤＢ１２ｂ２、ＯＳ変更操作コマンドＤＢ１２ｂ３およびファイル変更操作コマンドＤＢ１２ｂ４に事前に格納されているコマンドのうちに、ステップＳ１３ｂで取得したコマンドが存在するか否かを検索する。なお、取得したコマンドの数だけ、ステップＳ１３ｄ１からステップ１３ｄ５を含むステップＳ１３ｄの処理が繰り返し行われる。

【0087】

〔ステップＳ１３ｄ１〕制御部１１は、ＭＷ変更操作コマンドＤＢ１２ｂ２を参照し、ＭＷ変更操作コマンドＤＢ１２ｂ２に格納されているコマンドのうち、取得したコマンドが存在するか否かを検索する。取得したコマンドが存在する場合はステップＳ１３ｄ５へ処理が進み、存在しない場合はステップＳ１３ｄ２へ処理が進む。

【0088】

〔ステップＳ１３ｄ２〕制御部１１は、ＯＳ変更操作コマンドＤＢ１２ｂ３を参照し、ＯＳ変更操作コマンドＤＢ１２ｂ３に格納されているコマンドのうち、取得したコマンドが存在するか否かを判別する。取得したコマンドが存在する場合はステップＳ１３ｄ５へ処理が進み、存在しない場合はステップＳ１３ｄ３へ処理が進む。

【0089】

〔ステップＳ１３ｄ３〕制御部１１は、ファイル変更操作コマンドＤＢ１２ｂ４を参照し、ファイル変更操作コマンドＤＢ１２ｂ４に格納されているコマンドのうち、取得したコマンドが存在するか否かを判別する。取得したコマンドが存在する場合はステップＳ１３ｄ４へ処理が進み、存在しない場合は図１０のステップＳ１４の処理に進む。

【0090】

〔ステップＳ１３ｄ４〕制御部１１は、取得したコマンドに対して、ファイル変更操作コマンドＤＢ１２ｂ４のファイル変更操作実行対象が存在するか否かを判断する。ファイル変更操作実行対象が存在する場合はステップＳ１３ｄ５へ処理が進み、存在しない場合は図１０のステップＳ１４の処理に進む。

【0091】

〔ステップＳ１３ｄ５〕制御部１１は、ステップＳ１３ｂで取得したコマンドは、監視対象サーバ２０に対して変更操作が行われたコマンドであると認識して、通知用ＤＢ１２ａの監視対象サーバ変更操作の項目に、取得したコマンドを格納する。図１０のステップＳ１４へ処理が進む。

【0092】

図１２は、性能異常の有無にもとづく対処要メッセージの検出処理の動作例を示すフローチャートである。
〔ステップＳ１５ａ〕制御部１１は、メッセージ受信前の特定期間における、監視対象サーバ２０内のログ管理部２１で管理されている性能ログ２１ｄを取得する。

【0093】

〔ステップＳ１５ｂ〕制御部１１は、性能ログ２１ｄ内のＣＰＵ使用率を閾値と比較し、ＣＰＵ使用率が閾値を所定時間超えるＣＰＵ使用率エラーを発生しているか否かを検出する。ＣＰＵ使用率エラーを検出した場合はステップＳ１５ｆへ処理が進み、未検出の場合はステップＳ１５ｃへ処理が進む。

【0094】

〔ステップＳ１５ｃ〕制御部１１は、性能ログ２１ｄ内のディスク使用率を閾値と比較し、ディスク使用率が閾値を超えるディスク使用率エラーを発生しているか否かを検出する。ディスク使用率エラーを検出した場合はステップＳ１５ｆへ処理が進み、未検出の場合はステップＳ１５ｄへ処理が進む。

【0095】

〔ステップＳ１５ｄ〕制御部１１は、性能ログ２１ｄ内のメモリ使用率を閾値と比較し、メモリ使用率が閾値を超えるメモリ使用率エラーを発生しているか否かを検出する。メモリ使用率エラーを検出した場合はステップＳ１５ｆへ処理が進み、未検出の場合はステップＳ１５ｅへ処理が進む。

【0096】

〔ステップＳ１５ｅ〕制御部１１は、性能ログ２１ｄ内の通信ネットワーク接続状態からネットワークエラー（例えば、回線断等の接続エラー）を検出したか否かを判別する。ネットワークエラーを検出した場合はステップＳ１５ｆへ処理が進み、未検出の場合は図１０のステップＳ１６へ処理が進む。

【0097】

〔ステップＳ１５ｆ〕制御部１１は、監視対象サーバ２０に性能異常が発生していることを認識し、通知用ＤＢ１２ａの監視対象サーバ性能異常の項目に性能異常箇所を格納する。図１０のステップＳ１６へ処理が進む。

【0098】

なお、上記では、ＣＰＵ使用率エラー、ディスク使用率エラー、メモリ使用率エラーおよびネットワークエラーを性能異常の例として説明したが、その他の性能異常の検出を行ってもよい。

【0099】

図１３は、関連サーバを監視対象としたときの動作例を示すフローチャートである。
〔ステップＳ１７ａ〕制御部１１は、構成管理ＤＢ１２ｂ１を参照し、構成管理ＤＢ１２ｂ１から関連サーバ情報を取得する。

【0100】

〔ステップＳ１７ｂ〕制御部１１は、関連サーバ情報にもとづいて、監視対象サーバ２０に関連する関連サーバ３０が存在するか否かを判断する。関連サーバ３０が存在する場合はステップＳ１７ｃへ処理が進む。また、関連サーバ３０が存在しない場合は処理を終了する。関連サーバが存在しないと検出された場合、ステップＳ１０で受信したメッセージは対処不要と判定されることになる。

【0101】

〔ステップＳ１７ｃ〕制御部１１は、関連サーバ３０に対して判定処理を実行する。なお、関連サーバ３０の数だけ、ステップＳ１７ｃ１からステップ１７ｃ６を含むステップＳ１７ｃの処理が繰り返し行われる。

【0102】

〔ステップＳ１７ｃ１〕制御部１１は、判定処理ｐ２のうちの変更操作の有無にもとづく対処要メッセージの検出処理ｐ２１を行う（図１１に上述したので説明は省略する）。
〔ステップＳ１７ｃ２〕制御部１１は、変更操作の有無にもとづく対処要メッセージの検出処理ｐ２１を実行することによって、通知用ＤＢ１２ａの関連サーバ変更操作の項目に変更操作コマンドが格納されたか否かを判断する。変更操作コマンドが格納されている場合はステップＳ１７ｃ５へ処理が進み、変更操作コマンドが格納されていない場合はステップＳ１７ｃ３へ処理が進む。

【0103】

〔ステップＳ１７ｃ３〕制御部１１は、判定処理ｐ２のうちの性能異常の有無にもとづく対処要メッセージの検出処理ｐ２２を行う（図１２に上述したので説明は省略する）。
〔ステップＳ１７ｃ４〕制御部１１は、性能異常の有無にもとづく対処要メッセージの検出処理ｐ２２を実行することによって、通知用ＤＢ１２ａの関連サーバ性能異常の項目に性能異常箇所が格納されたか否かを判断する。性能異常箇所が格納されている場合はステップＳ１７ｃ５へ処理が進む。また、性能異常箇所が格納されていない場合は終了する。性能異常箇所が格納されていないことが検出された場合、ステップＳ１０で受信したメッセージは対処不要と判定されることになる。

【0104】

〔ステップＳ１７ｃ５〕制御部１１は、通知用ＤＢ１２ａにおけるメッセージの対処の要否の項目に対処要を登録する。
〔ステップＳ１７ｃ６〕制御部１１は、通知用ＤＢ１２ａに対処要が登録されたメッセージを出力表示部１４へ送信する。対処要と判定されたメッセージは、出力表示部１４によって保守端末４０に送信されて表示される。

【0105】

＜通知用ＤＢの格納状態＞
次に通知用ＤＢ１２ａの格納状態について、図１４、図１５を用いて説明する。図１４、図１５は、通知用ＤＢの格納状態の一例を示す図である。

【0106】

通知用ＤＢ１２ａ－１には、制御部１１でメッセージが受信されてメッセージの属性が登録されたときの格納状態の例が示されている。属性が登録された通知用ＤＢ１２ａ－１には、メッセージの受信日時２０１８年１０月１２日０９時３３分１２秒、メッセージａｂｃおよびメッセージの発信元ＭｐＡｏｓｆｖが格納されている。その他の項目は空欄になっている。

【0107】

通知用ＤＢ１２ａ－２には、制御部１１によって監視対象サーバ２０で変更操作が検出されたときの格納状態の例が示されている。制御部１１は、変更操作の有無にもとづく対処要メッセージの検出処理ｐ２１を行って変更操作に伴うコマンドを検出した場合、変更操作に伴うコマンドを登録する。

【0108】

変更操作に伴うコマンドが登録された通知用ＤＢ１２ａ－２には、メッセージの属性情報の他に、監視対象サーバ変更操作の項目にｋｉｌｌ１２８のコマンドが格納され、対処の要否の項目に対処要が格納されている。その他の項目は空欄になっている。

【0109】

通知用ＤＢ１２ａ－３には、制御部１１によって監視対象サーバ２０で性能異常が検出されたときの格納状態の例が示されている。制御部１１は、性能異常の有無にもとづく対処要メッセージの検出処理ｐ２２を行って性能異常を検出した場合、性能異常箇所を登録する。

【0110】

性能異常箇所が登録された通知用ＤＢ１２ａ－３には、メッセージの属性情報の他に、監視対象サーバ性能異常の項目にＣＰＵが格納され、対処の要否の項目に対処要が格納されている。その他の項目は空欄になっている。

【0111】

通知用ＤＢ１２ａ－４には、制御部１１によって関連サーバ３０で変更操作が検出されたときの格納状態の例が示されている。制御部１１は、変更操作の有無にもとづく対処要メッセージの検出処理ｐ２１を行って変更操作を検出した場合、変更操作のコマンドを登録する。

【0112】

変更操作が登録された通知用ＤＢ１２ａ－４には、メッセージの属性情報の他に、関連サーバの項目にＳＶ１、関連サーバ変更操作の項目にｖｉ／ｅｔｃ／＊＊＊のコマンドが格納され、対処の要否の項目に対処要が格納されている。その他の項目は空欄になっている。

【0113】

通知用ＤＢ１２ａ－５には、制御部１１によって関連サーバ３０で性能異常が検出されたときの格納状態の例が示されている。制御部１１は、性能異常の有無にもとづく対処要メッセージの検出処理ｐ２２を行って性能異常を検出した場合、性能異常箇所を登録する。

【0114】

性能異常箇所が登録された通知用ＤＢ１２ａ－５には、メッセージの属性情報の他に、関連サーバの項目にＳＶ２、関連サーバ性能異常の項目にＣＰＵが格納され、対処の要否の項目に対処要が格納されている。その他の項目は空欄になっている。

【0115】

通知用ＤＢ１２ａ－６には、制御部１１によって変更操作および性能異常が検出されなかったときの格納状態が示されている。変更操作および性能異常が検出されなかったとき、制御部１１は、受信メッセージは対処不要と判定する。したがって、通知用ＤＢ１２ａ－６には、メッセージの属性情報の他に、対処の要否の項目に対処不要が格納されている。その他の項目は空欄になっている。

【0116】

＜動作の具体例＞
次に動作の具体例について、図１６から図１８を用いて説明する。図１６は、メッセージ収集画面の一例を示す図である。保守端末４０には、メッセージ収集画面ｇ１が表示される。メッセージ収集画面ｇ１は、運用管理サーバ１０で判定処理ｐ１、ｐ２が行われる前に、運用管理サーバ１０で収集されたメッセージを表示する画面である。メッセージ収集画面ｇ１には、対処状態、番号、日時、表示名およびメッセージの項目がある。

【0117】

欄ＣＬ１１には、（対処状態、番号、日時、表示名、メッセージ）＝（対処済み、５、２０１９／０２／０４ １１：３０：００、運用管理サーバ１０、ログ収集は失敗しました サーバ名：業務サーバＳＶ０）と表示されている。

【0118】

欄ＣＬ１２には、（対処状態、番号、日時、表示名、メッセージ）＝（未対処、２０、２０１９／０２／０４ １３：００：１０、業務サーバＳＶ０、トランザクションタイムアウトが発生しました）と表示されている。

【0119】

欄ＣＬ１３には、（対処状態、番号、日時、表示名、メッセージ）＝（未対処、４６、２０１９／０２／０４ １５：００：２０、業務サーバＳＶ０、システムＡが停止しました）と表示されている。

【0120】

番号＝５のメッセージはすでに対処済みであるが、番号＝２０のメッセージと、番号＝４６のメッセージは未対処である。したがって、番号＝２０、４６のメッセージの対処要否の判定処理の実行指示が、保守端末４０から運用管理サーバ１０へ送信される。

【0121】

運用管理サーバ１０の制御部１１は、保守端末４０からの指示を受信すると、番号＝２０、４６のメッセージに対して最初に判定処理ｐ１を実行する。ここでは、番号＝２０、４６のメッセージ共に、判定処理ｐ１では対処不要と判定されたとする。

【0122】

図１７は、コマンドヒストリテーブルの一例を示す図である。コマンドヒストリテーブル５は、業務サーバＳＶ０において実行されたコマンドの履歴が登録されている。コマンドヒストリテーブル５は、業務サーバＳＶ０から収集したシステムログ、アプリログおよびＭＷログにもとづいて、制御部１１によって生成される。

【0123】

制御部１１は、番号＝２０のメッセージに対して、判定処理ｐ２のうちの変更操作の有無にもとづく対処要メッセージの検出処理ｐ２１を実行する。制御部１１は、コマンドヒストリテーブル５から、番号＝２０のメッセージの受信前の直前の時刻２０１９／０２／０４ １２：４０：００において、ｖｉコマンドで定義ファイルのタイムアウト値の書き替えが行われたことを検出する。なお、ｖｉコマンドおよび定義ファイルは、ファイル変更操作コマンドＤＢ１２ｂ４にあらかじめ格納されている。

【0124】

したがって、制御部１１は、検出したｖｉコマンドおよび実行対象はファイル変更操作コマンドＤＢ１２ｂ４に存在するため、業務サーバＳＶ０に対して変更操作有りと認識して、番号＝２０のメッセージを対処要と判定する。よって、番号＝２０のメッセージである“トランザクションタイムアウトが発生しました”は、対処要のメッセージとして保守端末４０に別途表示され管理者に通知される。

【0125】

図１８は、性能状態テーブルの一例を示す図である。性能状態テーブル６は、業務サーバＳＶ０の性能ログから検出された性能状態が登録されている。性能状態テーブル６は、業務サーバＳＶ０から収集した性能ログにもとづいて、制御部１１によって生成される。

【0126】

制御部１１は、番号＝４６のメッセージに対して、判定処理ｐ２のうちの変更操作の有無にもとづく対処要メッセージの検出処理ｐ２１を実行したが、対処不要と判定されたとする。したがって、制御部１１は、番号＝４６のメッセージに対して、判定処理ｐ２のうちの性能異常の有無にもとづく対処要メッセージの検出処理ｐ２２を実行する。

【0127】

性能状態テーブル６から、番号＝４６のメッセージの受信前の直前の時刻２０１９／０２／０４ １４：５９：００において、ＣＰＵ使用率エラーおよびディスク使用率エラーが発生していることが検出される。

【0128】

したがって、制御部１１は、業務サーバＳＶ０に対して性能異常有りと認識して、番号＝４６のメッセージを対処要と判定する。よって、番号＝４６のメッセージである“システムＡが停止しました”は、対処要のメッセージとして保守端末４０に別途表示され管理者に通知される。

【0129】

以上説明したように、本発明の運用管理サーバ１０によれば、配下のサーバから送信されたメッセージをフィルタ定義によって対処不要と判定した場合、メッセージ受信前の該サーバの変更操作や性能異常にもとづいて、対処要否を再判定する。

【0130】

これにより、フィルタ定義で対処要と判定されなかった未知メッセージや未定義メッセージから、運用上対処要のメッセージを精度よく拾い上げることができ、対処すべき事象の発生の通知漏れを抑制することが可能になる。また、通知漏れが抑制されることで保守作業にも抜けがなくなり、安全にシステムを運用することができる。

【0131】

さらに、判定処理ｐ１のメッセージ解析で対処要と判定されなかったメッセージに対して、メッセージ解析とは異なる判定方法の判定処理ｐ２で再判定が行われるので、メッセージ解析時に登録しておくべきフィルタ定義数を減らすことができる。このため、管理者の作業負担を軽減させることが可能になる。

【0132】

上記で説明した本発明の情報処理装置１および運用管理サーバ１０の処理機能は、コンピュータによって実現することができる。この場合、情報処理装置１および運用管理サーバ１０が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。

【0133】

処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記憶装置、光ディスク、光磁気記録媒体、半導体メモリ等がある。磁気記憶装置には、ハードディスク装置（ＨＤＤ）、フレキシブルディスク（ＦＤ）、磁気テープ等がある。光ディスクには、ＣＤ－ＲＯＭ／ＲＷ等がある。光磁気記録媒体には、ＭＯ（Magneto Optical disk）等がある。

【0134】

プログラムを流通させる場合、例えば、そのプログラムが記録されたＣＤ－ＲＯＭ等の可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

【0135】

プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。

【0136】

また、コンピュータは、ネットワークを介して接続されたサーバコンピュータからプログラムが転送される毎に、逐次、受け取ったプログラムに従った処理を実行することもできる。また、上記の処理機能の少なくとも一部を、ＤＳＰ、ＡＳＩＣ、ＰＬＤ等の電子回路で実現することもできる。

【0137】

以上、実施の形態を例示したが、実施の形態で示した各部の構成は同様の機能を有する他のものに置換することができる。また、他の任意の構成物や工程が付加されてもよい。さらに、前述した実施の形態のうちの任意の２以上の構成（特徴）を組み合わせたものであってもよい。

【符号の説明】

【0138】

１ 情報処理装置
１ａ 制御部
１ｂ 記憶部
２ 装置
ｍ１ メッセージ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】