JP2017156863A - 監視システム、プログラム - Google Patents

Abstract

【課題】発生したアラームをオペレータが確認できる監視システムを提供する。【解決手段】監視システム１０は、被監視システム４１の稼動状況を監視し障害が検出された場合にアラームを発報する。アラーム情報生成手段１４は、アラームが発報されるごとにアラームに関するアラーム情報を生成する。アラーム情報集約手段２１は、複数の前記同じアラーム情報を集約条件に基づいて１つの集約アラーム情報に集約する。アラーム情報表示手段１６は、アラーム情報生成手段が生成したアラーム情報及びアラーム情報集約手段により集約された集約アラーム情報を表示する。【選択図】図５

Description

本発明は監視システム及びプログラムに関する。

自社が提供するサービスや社内システムのサーバなどがデータセンターなどに設置される場合がある。データセンターは単にサーバやその設置場所などを提供する以外に、サーバなどの稼動状況を監視したり、サーバなどから障害を検出すると障害の内容を顧客の担当者に通知したりする管理システムを有している。

図１は、従来の運用管理システム１００の動作を説明する図の一例である。障害の発生時に運用管理システム１００のオペレータ９が行う行動を説明する。
（１）まず、データセンター４０の被監視システム４１に生じた障害を監視システム１０が検出してアラームを発報する。アラームの内容はオペレータ９が監視する画面に表示される。
（２）オペレータ９は予め定められた対応方法を参照する。対応方法には、障害の発生時にオペレータ９がどのように対応するかが障害の内容に応じて定められている。具体的には、障害の内容に応じた連絡方法や連絡先（顧客の担当者８の電話番号など）である。
（３）オペレータ９は対応方法にしたがって担当者８に連絡する。
（４）連絡が済んだら又は障害が解決されるとオペレータ９はインシデント管理システム３０に障害に対する対応結果を入力する。

このように、監視システム１０が被監視システム４１を監視して適切な対応を行うので、顧客は迅速に対処して復旧等を行うことができる。しかしながら、オペレータ人数が限られるため、対応困難な数のアラームが発生する場合がある。これは、重大な障害だけでなく通常とは異なるような軽微な事象もアラームの発報の対象となるためである。このため、オペレータ９がアラームの内容を確認して対応方法に基づく対応を所定の時間内に取ることが困難になる場合がある。アラームの全てについて個別の連絡などの対応が必要であるわけではないが、オペレータ９は全てのアラームについて少なくともアラームの内容を画面で確認する必要がある。また、同じアラーム（例えば同じサーバの障害に基づき発報されたアラームなど）については、オペレータ９が手動でアラームを集約させることができるが、集約を誤り適切な対応を取れない状況が発生するおそれがある。

そこで、従来から大量のアラームを効率よく処理するための技術が考案されている（例えば、特許文献１参照。）。特許文献１には、一定時間内に同一の監視対象サーバに発生した同一のアラートを一つのアラートにフィルタリングするコンピュータリモート監視システムが開示されている。

特開２０１０−０５５４７９号公報

しかしながら、アラームを単に集約するだけではオペレータ９が確認できなかったアラームが存在しうるという問題がある。すなわち、自動的な集約により監視システム１０の画面に表示されないアラームが存在するため、どのくらいの数のアラームが繰り返し発生しているかをオペレータ９は把握できない。一般に、重大な障害では数多くのアラームが発生され、また、長時間にわたって繰り返しアラームが発生される。したがって、集約される前のアラームが監視システム１０の画面に表示されることがオペレータ９にとって重要な情報となる場合がある。

また、従来のアラームは、オペレータの取るべき対応方法（連絡先・方法等）に合わせて表示されるわけではないので、オペレータが効率的に対応できないという問題がある。

本発明は、上記課題に鑑み、障害により発報されたアラームをオペレータが確認することができる監視システムを提供することを目的とする。

本発明は、被監視システムの稼動状況を監視し障害が検出された場合にアラームを発報する監視システムであって、前記アラームが発報されるごとに前記アラームに関するアラーム情報を生成するアラーム情報生成手段と、複数の前記同じアラーム情報を集約条件に基づいて１つの集約アラーム情報に集約するアラーム情報集約手段と、前記アラーム情報生成手段が生成した前記アラーム情報及び前記アラーム情報集約手段により集約された前記集約アラーム情報を表示するアラーム情報表示手段と、を有する。

発生したアラームをオペレータが確認することができる監視システムを提供することができる。

従来の運用管理システムの動作を説明する図の一例である。 監視システムが表示する画面を模式的に示す図の一例である。 保守サービスシステムのシステム構成図の一例である。 監視システムのハードウェア構成図の一例である。 保守サービスシステムの機能ブロック図の一例である。 監視システムがアラーム情報を表示する画面の表示制御の手順を示すフローチャート図の一例である。 集約処理を説明する図の一例である。 表示色フラグの制御手順を示すフローチャート図の一例である。 画面表示制御部がアラーム情報の表示色を制御する手順を示すフローチャート図の一例である。 表示色が制御されるアラーム情報の一例を示す図である。 画面の分割について説明する図の一例である。 スクロール速度の制御手順を示すフローチャート図の一例である。 アラーム情報が表示されるアラーム表示画面を示す図の一例である。 同じ障害に基づくアラームが再度、発報されたことを監視システムが画面に表示する手順を示すフローチャート図の一例である。 再発したアラームに関するアラーム情報を模式的に示す図の一例である。 発生頻度監視部がアラームを発報させていた障害が解決したと推定する手順を示すフローチャート図の一例である。 解決済みが表示されるアラーム情報を模式的に示す図の一例である。 監視システムがアラーム情報に関連したインシデントデータを表示する手順を示すフローチャート図の一例である。 集約されたアラーム情報と共に表示されるインシデントデータを模式的に示す図の一例である。 アラーム情報集約部が、作業に起因するアラーム情報を検出して画面を表示する手順を示すフローチャート図の一例である。 集約されたアラーム情報を模式的に示す図の一例である。 複数台の端末を利用した監視システムの適用例を説明する図の一例である。

以下、本発明を実施するための形態について図面を参照しながら説明する。
図２は、監視システム１０が表示する画面を模式的に示す図の一例である。図２（ａ）は監視システム１０がリアルタイムに表示する画面を示す。監視システム１０は障害の発生を検出すると障害の内容を表すアラーム情報をリアルタイムに１行に１つの形式で表示する。図２（ａ）では監視システム１０の顧客であるＡ社、Ｂ社、Ｃ社に関するアラーム情報が上から下方向に時系列に表示されている（上の行ほど新しい）。

監視システム１０は被監視システムなどに障害が発生するごとに１つのアラーム情報を上から追加して表示する。これに対し、１つ画面に表示可能なアラーム情報の数は有限である。このため、監視システム１０はアラーム情報が一番上の行に追加されるごとに、他のアラーム情報を１つずつ下の行に繰り下げて表示する処理を行う。このような表示態様をスクロールと称する。なお、スクロールには、停止表示（停止状態）、特定行フォーカス表示等も含まれる。

したがって、一番下にあるアラーム情報はスクロールにより表示されなくなる（このような現象を「画面からあふれる」と称する場合がある）。また、アラーム情報のスクロール速度はどのくらいの頻度で監視システム１０が障害を検出したかに依存する。つまり、監視システム１０が頻繁に障害を検出した場合にはスクロール速度が速くなる。この結果、オペレータ９がアラーム情報を確認するまでにアラーム情報が画面からあふれてしまう場合がある。

そこで、図２（ｂ）に示すように、本実施形態の監視システム１０はスクロール速度を一定以下に制御する。図２（ｂ）ではスクロール速度を矢印４０１，４０２の太さで表している。すなわち、Ａ社のアラーム情報が後述される分割条件を満たすと監視システム１０は画面を分割したりポップアップウィンドウ４０３を表示したりしてＡ社のアラーム情報のみを表示する。そして、Ａ社のアラーム情報だけ（同じアラーム情報だけ）を一定速度以下のスクロール速度で表示する。図２（ｂ）はＡ社又はあるサーバ等の機器単位のアラーム情報のみがポップアップ表示された例である。

この一定速度は、人間の目で追える程度の速さでありオペレータ９がアラームの内容を確認するまでに画面からあふれることがないように決定されている。

したがって、オペレータ９は、大量のアラームが発生してもほぼ全てのアラーム情報を確認でき、どのくらいの数のアラームが繰り返し発生しているかを把握できる。また、アラームの内容を確認できるので対応方法にしたがって障害に対する適切な対応を取ることができる。

＜用語について＞
障害…被監視システム４１において生じた通常と異なる事象である。本実施形態では予め定められた事象が検出されることを障害という。
アラーム…障害が検出されたことをオペレータ９等に通知すること、又は、通知そのものをいう。１つの障害で１つのアラームが発報されるが、障害が解決されないと同じ障害に基づいて繰り返しアラームが発報される。このような同じ障害に基づいて発報されるアラームを同じアラームという。あるいは、別途定めた集約条件により集約可能なアラームを同じアラームと称してよい。
担当者８…後述する被監視システム４１を構築し、維持し、保守し及び復帰等させる者である。このため、データセンター４０に入館したり又は遠隔地からログインしたりしてアラームに対する対応を行う。
オペレータ９…監視システム１０を操作する者をいう。オペレータ９が担当者８を兼任する場合がある。

＜構成例＞
図３は、保守サービスシステム２００のシステム構成図の一例を示す。保守サービスシステム２００では、主に運用管理システム１００と各社の被監視システム（例えば、Ａ社被監視システム４１ａ、Ｂ社被監視システム４１ｂ、Ｃ社被監視システム４１ｃ）４１がネットワークＮを介して通信可能に接続される。運用管理システム１００は監視システム１０及びインシデント管理システム３０を有し、顧客である各社の被監視システム４１はデータセンター４０内に設置されている。なお、被監視システム４１はデータセンター４０内になくてもよく、被監視システム４１の利用者である顧客の社内に被監視システム４１が設置されていてもよい。このような設置形式をオンプレミスという。また、運用管理システム１００がデータセンター４０内に設置されていてもよい。したがって、図３に図示する構成は一例である。

データセンター４０は、サーバ、ルータ、スイッチ及びハブなどのＩＴ機器を効率的に稼動させるための設備が整えられた施設をいう。例えば、ＩＴ機器に供給される十分な電力が確保されており、冗長化された通信回線が配備されている。また、年間を通して温度や湿度もほぼ一定になるように制御され、ＩＴ機器の温度の上昇が抑制されている。 さらに災害時など、電力の供給が完全に止まってしまっても、自家発電装置やＵＰＳ（無停電電源装置）により、一定時間は継続的に稼動できるようになっている。

データセンター４０には、サーバやネットワークを顧客に開放するホスティングサービスと顧客が所有するサーバなどの機器をデータセンター４０に預けるハウジングサービスがある。本実施形態の運用管理システム１００はどちらのサービス形態にも対応できる。すなわち、サーバなどの機器の所有権の所在は問われない。また、サーバは仮想サーバでもよく、クラウドサービスが提供される場合もある。

データセンター４０には、各社の被監視システム４１が設置されている。各社の被監視システム４１は、データセンター４０の顧客の企業が利用する社内の業務用のシステム、又は、顧客が外部にＷｅｂサイトなどで提供するシステムなどである。各社の被監視システム４１は、運用管理システム１００により監視される。具体的には、被監視システム４１は１つ以上のサーバ、及び、周辺装置（例えばＮＡＳ（Network Attached Storage）など）である。各被監視システム４１はそれぞれラック内に隔離して設置される。このため、被監視システム４１の担当者８は、原則的に自社の被監視システム４１のみしかメンテナンスできない（データセンター４０の技術者（ＳＥ）は複数社のシステムをメンテナンスする場合がある）。

また、データセンター４０にはセンサー４２が設置されている。センサー４２は例えばラックの開閉を検出する開閉センサー、ラックの温度を検出する温度センサー、ラックの振動を検出する震動センサー、煙などを検出する火災センサー、水の侵入を検出する浸水センサー等である。

各センサー４２が検出した検出データはセンサー情報管理装置４３が取得して運用管理システム１００に送信する。センサー情報管理装置４３はセンサー４２が検出した検出データを被監視システム４１と対応付けて監視システム１０に送信する。監視システム１０は、センサー４２の検出データにより被監視システム４１の環境を記録したり監視したりすることができる。

運用管理システム１００はデータセンター４０における被監視システム４１の各種の監視サービスやセキュリティーサービスを提供する。監視サービスとは障害の発生を検出して顧客に通知するなどのサービスをいい、セキュリティーサービスはマルウェアの侵入の排除などを行うサービスをいう。

監視システム１０は上記した監視サービスやセキュリティーサービスを提供する。監視サービスのため、監視システム１０は、例えば、機器のＰＩＮＧ疎通、サーバのサービス稼動状況、サーバや周辺装置のリソース等の監視などを行う。また、随時、ウィルスの検出、侵入検知又は攻撃検知などを行っている。

各社の被監視システム４１において何らかの障害が検出された場合、監視システム１０は障害発生を意味するアラームを発生させる（発報）する。なお、アラームの発報には、無人監視と有人監視がある。無人監視では障害発生時の状況をデータマイニングなどでフィルタリングして、通知の必要性が高いアラームのみが顧客の担当者８のＰＣ（Personal Computer）等に通知される。有人監視では、運用管理システム１００のオペレータ９がアラームにより障害発生を把握すると対応方法に基づいて必要であると判断した場合に顧客の担当者に電話や電子メールなどで通知する。本実施形態では主に有人監視を例にして説明するが、無人監視に適用されてもよいし、両方が適用されていてもよい。

また、監視システム１０から顧客の担当者へのアラームの通知方法にはいくつかの手段がある。例えば、有人監視の場合はオペレータ９による電話連絡でもよいし、電子メールによる通知でもよい。無人監視の場合も、電子メールによる通知又は自動音声を用いた電話連絡がある。有人監視と無人監視のいずれの場合もＦＡＸで通知してもよい。

インシデント管理システム３０は、障害が発生した場合に、障害の内容、対応結果等が記録されるシステムである。障害が発生するとオペレータ９は、顧客にいつどのように連絡したかという対応方法、障害が解決したかどうかなどの対応結果をインシデント管理システム３０に入力する。したがって、インシデント管理システム３０は過去の障害のデータベースとして活用され、類似した障害が発生した際にオペレータ９が過去の対応方法などを参照することができる。

＜ハードウェア構成例＞
図４は、監視システム１０のハードウェア構成図の一例である。監視システム１０は、バス３１０に接続されたＣＰＵ３０１、ＲＯＭ３０２、ＲＡＭ３０３、ＨＤＤ(Hard Disk Drive)３０５、ディスプレイ３０８、ネットワークＩ／Ｆ３０９、キーボード３１１、マウス３１２、メディアドライブ３０７、及び、光学ドライブ３１４を有する。ＣＰＵ３０１は、ＨＤ３０４に記憶されている監視プログラムを実行して、監視システム１０全体の動作を制御する。ＲＯＭ３０２はＩＰＬ（Initial Program Loader）等のＣＰＵ３０１の駆動に用いられるプログラムを記憶している。ＲＡＭ３０３はＣＰＵ３０１のワークエリアとして使用される。ＨＤ３０４は不揮発性メモリを搭載した記憶装置であり、監視プログラム、ＯＳ（Operating System）等を記憶している。

ＨＤＤ３０５はＣＰＵ３０１の制御にしたがってＨＤ３０４に対する各種データの読み出し又は書き込みを制御する。ディスプレイ３０８はカーソル、メニュー、ウィンドウ、文字、又は画像などの各種情報を表示する。ネットワークＩ／Ｆ３０９はＬＡＮやインターネットなどのネットワークＮとのインタフェースであり、ネットワークＮを介した通信を行う。キーボード３１１及びマウス３１２は入出力装置であり、キーボード３１１は文字、数値、各種指示などの入力のための複数のキーを備えこれらからの入力を受け付ける。マウス３１２はマウスポインターの移動及び各種指示の選択や実行、処理対象の選択などを受け付ける。

メディアドライブ３０７はフラッシュメモリ等のメディア３０６に対するデータの読み出し又は書き込み（記憶）を制御する。光学ドライブ３１４は着脱可能な記録媒体の一例としてのＣＤ−ＲＯＭ(Compact Disc Read Only Memory)３１３等に対する各種データの読み出し又は書き込みを制御する。

なお、上記監視プログラムは、インストール可能な形式又は実行可能な形式のファイルで、メディア３０６やＣＤ−ＲＯＭ３１３等のコンピュータで読み取り可能な記録媒体に記録して流通させるようにしてもよい。あるいは、監視プログラムは、任意のサーバ型の情報処理装置からダウンロードされる形態で配布されてもよい。

なお、監視システム１０は、クラウドコンピューティングにより構築されていてもよい。クラウドコンピューティングでは、監視システム１０の機能が搭載される情報処理装置が固定されていたり１つの筐体内に設置されていたりする必要はなく、物理的な構造は変動しうる。したがって、図示する監視システム１０のハードウェア構成は、監視システム１０が備えていることが好ましいハード的な要素を示す。

また、インシデント管理システム３０及び各社の被監視システム４１のハードウェア構成は図４と同様であるか、差異があっても本実施形態の説明には支障がないものとする。しかしながら、インシデント管理システム３０のＨＤ３０４にはインシデント管理システム３０のためのプログラムが記憶されている。

＜保守サービスシステムの機能について＞
続いて、図５を用いて保守サービスシステム２００の各機能について説明する。図５は、保守サービスシステム２００の機能ブロック図の一例を示す。なお、被監視システム４１は本実施形態では監視対象であるので、その機能は被監視システム４１によって異なる。

≪監視システム≫
監視システム１０は、送受信部１１、監視部１２、アラーム判定部１３、アラーム情報生成部１４、操作受付部１５、画面表示制御部１６、再発監視部２２、検索要求部２３、発生頻度監視部２４、及び、記憶・読出部１９を有する。これらの各機能は図４に示したＣＰＵ３０１が監視プログラムを実行して図４の各種のハードウェアと協働することで実現される機能又は手段である。これらの機能の一部又は全てがＩＣなどのハードウェア回路により実現されてもよい。

また、監視システム１０は、図４に示したＨＤ３０４又はＲＡＭ３０３により実現される記憶部１０００を有している。記憶部１０００には、顧客情報ＤＢ１００１、アラーム発報対象ＤＢ１００２、対応方法ＤＢ１００３、アラーム情報ＤＢ１００４、顧客作業情報ＤＢ１００５、及び、監視プログラム１０１０が構築されている。以下、これら各データベースについて説明する。

記憶部１０００には、表１に示されているような顧客情報によって構成されている顧客情報ＤＢ１００１が構築されている。顧客情報には、顧客ＩＤ、顧客名、サーバＩＤ、及び、担当者情報が対応づけて登録されている。顧客ＩＤは、データセンター４０の顧客を一意に識別するための識別情報である。識別情報とは、複数の対象からある特定の対象を一意的に区別するために用いられる名称、符号、文字列、数値又はこれらの組み合わせをいう。以下の識別情報においても同様である。顧客ＩＤは顧客に固有の情報なので顧客固有情報と称してもよい。

顧客名は顧客の通称名である。サーバＩＤは、各顧客がデータセンター４０内に保有するサーバを一意に識別するための識別情報である。サーバＩＤはサーバに固有の情報なのでサーバ固有情報と称してもよい。また、サーバＩＤに代えて又はサーバＩＤと共にホスト名が登録されていてもよい。

担当者情報は、各顧客の担当者８と連絡先などを含む。担当者情報は、一例としてサーバごとに構築されており、担当者情報には、担当者ＩＤ、氏名、ＴＥＬ、及び、Ｅ−Ｍａｉｌアドレス（電子メールアドレス）が対応づけて登録されている。担当者ＩＤは担当者８を一意に識別するための識別情報である。氏名は、担当者８の名称であるが戸籍上の氏名でもニックネームでもよい。TELはオペレータ９が担当者８に電話するための電話番号である。例えば、担当者８の携帯電話やスマートフォンの電話番号、担当者８の会社のデスクの電話番号、又は、自宅の電話番号である。E-Mailアドレスはオペレータ９が担当者８に電子メールを送信するためのアドレス情報である。電話番号が宛先になるいわゆるショートメッセージサービスで送信してもよい。

なお、監視システム１０は担当者情報を顧客ごとに作成してもよい。また、顧客の住所、代表者氏名、締め日などの情報は、別のデータベースに登録されている。

記憶部１０００には、表２に示されているようなアラーム発報対象情報によって構成されているアラーム発報対象ＤＢ１００２が構築されている。アラーム発報対象情報には、アラーム番号に対応づけて、監視システム１０がアラームを発報する障害、発報条件及び重要度が登録されている。アラーム発報対象情報には、アラームの基本的な発報対象として予め設定されている障害と（ARM001〜003）、顧客が任意に設定できる障害（ARM004,005）とがある。

例えば、アラーム番号がARM001の障害は「PING応答なし」である。これは、監視システム１０からのPINGコマンドに対しサーバ等が応答しない障害を意味する。アラーム番号がARM002の障害は「プログラム異常終了」である。これは、プログラムが想定されないタイミングで終了した障害を意味する。アラーム番号がARM003の障害は「温度異常」である。これは、センサー４２が検出する被監視システム４１のラックの温度が閾値を超えて上昇した障害を意味する。

アラーム番号がARM004、005の障害は顧客がＰＣ等を使用して定義できる（オペレータ９が顧客の要望を聞いてアラーム発報対象ＤＢ１００２に登録してもよい。）。例えば、ＣＰＵ使用率とアラーム発報の閾値、ＨＤＤ空き容量とアラーム発報の閾値などを顧客は登録できる。さらに、例えばＣＰＵ使用率の単位時間の上昇率、ＣＰＵ温度の上昇率など、監視情報の値の微分値や２回微分値をアラーム発報対象情報に用いてもよい。また、複数の監視情報の組み合わせをアラーム発報対象情報に用いてもよい。

したがって、オペレータ９及び顧客はアラーム番号によって障害の内容を把握できる。なお、顧客がアラームを発報する障害を定義しなければ、アラーム発報対象情報は顧客ごとに共通である。このように、アラームが発報される障害は顧客ごとに異なっていても、そうでなくてもよい。表２に記載されたアラーム発報対象情報はあくまで一例であり、この他にも多くの障害（アラームが発報される事象）が存在しうる。

各障害はおよその重要度が予め登録されている。したがって、監視システム１０は１つのアラームから少なくとも障害の重要度を決定できる。監視システム１０は、例えば同じサーバＩＤについて異なるアラーム番号のアラームが発報された場合、同じアラーム番号のアラームだけが発報されるよりも重要度を大きくすることができる。例えば、単純に重要度を加えたり、乗じたり、最も大きな重要度を定数倍することなどが考えられる。

記憶部１０００には、表３に示されているような対応方法によって構成されている対応方法ＤＢ１００３が構築されている。対応方法は、アラームの発生時にオペレータ９が取り得るべき具体的な処置である。対応方法は、サーバＩＤとアラーム番号に対応付けられている。例えば、サーバＩＤがＳ００１の場合で、アラーム番号がARM001であれば「佐藤さんに電話」することが対応方法となる。このように対応方法ＤＢ１００３には、サーバＩＤとアラーム番号に対応付けてオペレータ９が取り得るべき具体的な対応方法が登録されている。

顧客はＰＣ等を使用して障害（アラーム番号）に応じて任意の対応方法を登録できる。あるいは、オペレータ９が顧客の要望を聞いて対応方法ＤＢ１００３に登録してもよい。障害の内容（例えば、ソフト系とハード系の違い、重要度など）によって担当者８や連絡方法が異なっていたりする場合がある。本実施形態では表３のような対応方法ＤＢ１００３を備えることで、サーバＩＤとアラーム番号に応じてオペレータ９が適切な処置を取ることができる。

また、後述するように本実施形態では複数のアラーム情報が集約されるが、監視システム１０がアラームを集約して表示する場合、対応方法の一部又は全部が同じアラームを１つに集約することができる。

なお、電話や電子メールの他、Twitter（登録商標）、Facebook（登録商標）、Ｌｉｎｅ（登録商標）などのＳＮＳ（Social Network System）の通知先が登録されていてもよい。

記憶部１０００には、表４に示されているようなアラーム情報によって構成されているアラーム情報ＤＢ１００４が構築されている。アラーム情報は、アラームを発報させた障害の内容がまとめられたレコードである。アラーム情報は障害が検出されるごとに生成される。したがって、障害の原因が同じでも解決されるまでに複数の同じアラーム情報が生成されうる。なお、アラーム情報の具体例は図７等で説明される。

アラーム情報は、通番、顧客ＩＤ、顧客名、発生日時、サーバＩＤ、アラーム番号、対応方法、及び、拡張部を有している。通番とは、アラーム情報に付される重複しない連続した番号である。顧客ＩＤ、顧客名、サーバＩＤは顧客情報ＤＢ１００１と同じものである。発生日時は、アラームが発報された日時である（障害が検出された日時と称してもよい）。アラーム番号はアラーム発報対象情報と同じものである。対応方法には、対応方法ＤＢ１００３から抽出されたサーバＩＤとアラーム番号に対応した対応方法、及び、顧客情報ＤＢ１００１から抽出された顧客の連絡先（ＴＥＬやＥ−Ｍａｉｌ）が設定される。

拡張部は、本実施形態の監視システム１０の主に画面制御に使用される付加的な情報である。拡張部は集約された複数のアラーム情報について共通の情報となる。拡張部は、集約番号、経過時間、件数、集約フラグ、表示色フラグ、過去事例フラグ、分割フラグ、再発フラグ、及び、対応完了を有している。集約番号は集約条件を満たした複数のアラーム情報が集約された場合に、集約された各アラーム情報に共通に付与される識別情報である。すなわち、１つに集約された複数のアラーム情報には同じ集約番号が付与される。経過時間は同じ障害に起因する最初のアラームが発報されてからの時間である。件数は同じ障害に起因するアラーム情報の数である。集約フラグは集約条件を満たす場合にＯＮ，満たさない場合にＯＦＦが設定されるフラグである。表示色フラグは集約されたアラーム情報が色分けして表示されるか否か、及び、色分けされている場合の色を示すフラグである。過去事例フラグは過去に対応が完了しているインシデントデータと類似するアラーム情報である場合にＯＮとなり、そうでない場合にＯＦＦとなるフラグである。分割フラグは画面の分割条件を満たした場合にＯＮとなり満たさない場合にＯＦＦとなるフラグである。再発フラグは対応が完了した障害について再度、アラームが発報された場合にＯＮとなり、再発でない場合にＯＦＦとなるフラグである。再発フラグと過去事例フラグはタイムスケールが異なり、再発フラグは例えば１時間程度以内に同じアラームが発報された場合にＯＮとなる。過去事例フラグは例えば１時間以上前に発生してインシデントデータと類似した障害が発生した場合にＯＮとなる。対応完了は、後述する所定時間Ｔ２が経過するか又はオペレータ９が対応方法ＤＢ１００３の対応方法にしたがって対応したことが登録される。

記憶部１０００には、表５に示されているような顧客作業情報によって構成されている顧客作業情報ＤＢ１００５が構築されている。顧客作業情報は、顧客が作業する予定が登録された情報である。顧客作業情報は、顧客ＩＤ、サーバＩＤ、担当者ＩＤ、作業日時、及び、備考を有している。顧客ＩＤ、サーバＩＤ、担当者ＩＤは顧客情報ＤＢ１００１と同じものである。作業日時は、顧客の担当者８が作業する日時である。備考には、例えば作業内容が登録される。したがって、監視システム１０は、顧客作業情報を参照することで、どの顧客のどのサーバに対し誰がいつ作業するかを抽出することができる。なお、顧客作業情報は、顧客の担当者８がＰＣ等を使用して顧客作業情報ＤＢ１００５に登録しておいてもよいし、オペレータ９が顧客の要望を聞いて顧客作業情報ＤＢ１００５に登録してもよい。

（監視システム１０の機能について）
次に、監視システム１０が有する機能又は手段について説明する。送受信部１１は、図４に示されているＣＰＵ３０１からの命令、及びネットワークＩ／Ｆ３０９等によって実現され、ネットワークＮを介してインシデント管理システム３０や被監視システム４１等と各種データの送受信を行う。なお、以下では監視システム１０がデータを送受信する場合でも「送受信部１１を介して」という記載を省略する場合がある。

監視部１２は、図４に示されているＣＰＵ３０１からの命令等によって実現され、被監視システム４１を監視する。具体的には、定期的に被監視システム４１に問い合わせて監視に必要な情報を取得する。監視に必要な情報は、サーバＩＤなど障害が発生した被監視システム４１を特定するための情報とアラームの発報条件を満たすかどうかを判定するための情報である。具体的には、監視部１２はアラーム発報対象情報に設定されている障害を検出するため、ＰＩＮＧ応答、プログラム異常情報、及び、温度異常などを監視する。すなわち、定期的に被監視システム４１に対しＰＩＮＧコマンドを送信し応答時間を取得する。また、被監視システム４１のプログラムが異常終了した場合に残すログを被監視システム４１から取得する。また、温度センサーとしてのセンサー４２が検出した温度を取得する。監視部１２はこれらの監視結果を随時、アラーム判定部１３に送出する。なお、監視部１２はＳＮＭＰ（Simple Network Management Protocol）マネージャの機能を有していてもよい。この場合、被監視システム４１はＳＮＭＰエージェントの機能を有する。

アラーム判定部１３は、図４に示されているＣＰＵ３０１からの命令等によって実現され、監視部１２による監視結果がアラームの発報条件を満たすか否かを判定し、満たす場合にアラームを発報する。アラーム判定部１３は、アラーム発報対象ＤＢ１００２から障害と発報条件を読み出し、アラームの発報対象を満たす監視結果があるか否かを判定する。例えば、監視部１２から取得した監視結果に基づいて、ＰＩＮＧコマンドへの応答時間が閾値（表３の○○ミリ秒）を超えないかなどを判定する。また、被監視システム４１のプログラムが異常終了した場合に残すログにプログラム異常終了の有無が記録されているか否かを判定する。また、ラックの周囲の温度が基準（Ｔ度）より高くなっていないかを判定する。アラーム判定部１３はアラームを発報すべきであると判定すると発報条件を満たすアラーム番号を読み出し、アラーム情報生成部１４に通知する。

アラーム情報生成部１４は、図４に示されているＣＰＵ３０１からの命令等によって実現され、アラーム情報を生成する。アラーム情報生成部１４は、まず、アラーム情報ＤＢ１００４で最も新しいアラーム情報の通番より１つ大きい通番を採番する。そして、監視部１２が取得したサーバＩＤに基づいて顧客情報ＤＢ１００１から顧客ＩＤと顧客名を読み出す。これにより、拡張部を除いてアラーム情報を生成できる。拡張部の生成方法については後述する。

操作受付部１５は、図４に示されているＣＰＵ３０１からの命令、キーボード３１１及びマウス３１２等によって実現され、オペレータ９の各種の操作を受け付ける。

画面表示制御部１６は、図４に示されているＣＰＵ３０１からの命令及びディスプレイ３０８等によって実現され、ディスプレイ３０８にアラーム情報が表示される画面を作成し表示する。この画面については図７などで説明される。

画面表示制御部１６は、さらに、画面分割部１７、スクロール制御部１８及びアラーム情報集約部２１を有している。画面分割部１７は分割フラグがＯＮになるとアラーム情報が表示される画面を分割して新しい分割領域を生成したり、ポップアップウィンドウを表示したりする。スクロール制御部１８はアラーム情報のスクロール速度を一定以下に制御する。アラーム情報集約部２１は、集約フラグがＯＮの場合に複数のアラーム情報を集約する。集約条件については後述するが、例えば、サーバ名、アラーム番号又は対応方法の１つ以上が一致するアラーム情報を集約する。あるいは、アラーム情報の類似度を判定して集約してもよい。

再発監視部２２は、図４に示されているＣＰＵ３０１からの命令等により実現され、対応が完了した障害に関するアラームが再発したかどうかを監視する。

検索要求部２３は、図４に示されているＣＰＵ３０１からの命令等により実現され、インシデント管理システム３０にアラーム情報を送信して類似するインシデントデータの検索を要求する。

発生頻度監視部２４は、図４に示されているＣＰＵ３０１からの命令等により実現され、アラームの発生頻度の急な変化を検出する。

記憶・読出部１９は、図４に示されているＣＰＵ３０１からの命令、及びＨＤＤ３０５等によって実現され、記憶部１０００に各種データを記憶したり、記憶部１０００に記憶された各種データを読み出したりする処理を行う。なお、以下では監視システム１０が記憶部１０００にアクセスする場合でも「記憶・読出部１９を介して」という記載を省略する場合がある。

≪インシデント管理システム３０≫
インシデント管理システム３０は、送受信部３１、データ検索部３２、及び、記憶・読出部３９を有する。これらの各機能は図４に示したＣＰＵ３０１が監視プログラムを実行して図４の各種のハードウェアと協働することで実現される機能又は手段である。これらの機能の一部又は全てがＩＣなどのハードウェア回路により実現されてもよい。

また、インシデント管理システム３０は、図４に示したＨＤ３０４又はＲＡＭ３０３により実現される記憶部３０００を有している。記憶部３０００には、インシデントデータＤＢ３００１及びインシデント管理プログラム３０１０が構築されている。以下、これら各データベースについて説明する。

記憶部３０００には、表６に示されているようなインシデントデータによって構成されているインシデントデータＤＢ３００１が構築されている。インシデントデータには、インシデント番号、顧客ＩＤ、サーバＩＤ、アラーム番号、発生日時、対応方法、及び、対応結果が対応づけて登録されている。

インシデント番号は、オペレータ９が対応した障害を区別するための識別情報である。同じ被監視システム４１から同じ障害に起因するアラームが何度も発報される場合があるが、この場合、オペレータ９は１つのインシデントとして扱うことができる。インシデント番号は重複しないように付与される。顧客ＩＤ、サーバＩＤ、アラーム番号は上記の通りである。発生日時はアラームが発報された日時である。同じサーバから同じ障害に起因する複数のアラームが発報された場合は、最初のアラームが発報された日時である。対応方法は、オペレータ９が取った実際の対応である。対応方法には、「山田さんに電話」のような単なる連絡先と連絡方法が登録される。さらに、どのようにして障害が解決されたのかが登録されることが好ましい。対応結果には、対応(少なくとも担当者により障害を復旧させた「障害対応」とオペレータによる担当者への連絡などの一次対応の２つがある)による障害への対応内容が登録される。

集約されたアラーム情報はオペレータ９が対応すべきアラーム情報であると考えられるので、アラーム情報が集約されると同じ複数のアラーム情報のうち最初のアラーム情報がインシデントデータＤＢ３００１に自動的に登録される。したがって、オペレータ９は対応方法と対応結果を登録すればよい。集約されないアラーム情報の場合、オペレータ９が対応したアラーム情報だけをインシデントデータＤＢ３００１に登録すればよい。なお、集約されたアラーム情報の場合もオペレータ９が手動でアラーム情報をインシデントデータＤＢ３００１に登録してよい。

インシデントデータＤＢ３００１には、アラーム番号、対応方法、及び、対応結果が登録されるので、オペレータ９は過去の事例として活用することができる。

（インシデント管理システムの機能について）
次に、インシデント管理システム３０が有する機能又は手段について説明する。送受信部３１は、図４に示されているＣＰＵ３０１からの命令、及びネットワークＩ／Ｆ３０９等によって実現され、ネットワークＮを介して監視システム１０等と各種データの送受信を行う。

データ検索部３２は、図４に示されているＣＰＵ３０１からの命令等によって実現され、監視システム１０から要求された検索条件（アラーム情報の項目）でインシデントデータＤＢ３００１を検索する。検索結果は監視システム１０に送信される。

記憶・読出部３９は、図４に示されているＣＰＵ３０１からの命令、及びＨＤＤ３０５等によって実現され、記憶部３０００に各種データを記憶したり、記憶部３０００に記憶された各種データを読み出したりする処理を行う。

＜動作手順＞
まず、図６を用いて監視システム１０の全体的な動作手順を説明する。図６は、監視システム１０がアラーム情報を表示する画面の表示制御の手順を示すフローチャート図の一例である。図６の処理は例えばアラームが発報されるとスタートする。

画面表示制御部１６はアラームが新規であるか否かを判定する（Ｓ１０）。アラームが新規であるとは、過去の所定期間において同じアラームが発報されていないことをいう。例えば集約条件が「サーバＩＤが同じであること」であれば、過去の所定期間において同じサーバＩＤのアラームが発報されていないことをいう。したがって、同じアラームとは、集約条件に適合するアラーム情報が生成されるアラームをいう。集約条件に適合するアラーム情報が生成される複数のアラームを単に「同じアラーム」という。また、同じアラームに基づいて生成されるアラーム情報を「同じアラーム情報」という。アラームが同じかどうかの判断は分割条件と集約条件とで異なる場合が多いが、同じであってもよい。

過去の所定期間は、最後に検出された障害に基づくアラームと関係がないと推定される程度の時間であり、例えば数時間程度であるがこれに限られるものではない。顧客やオペレータ９、担当者８等はこの過去の所定時間の設定できる。

ステップＳ１０の判定がＮｏの場合、処理はステップＳ３２に進む。これにより、新規のアラームでない場合はステップＳ２０、Ｓ３０をスキップできる。

ステップＳ１０の判定がＹｅｓの場合、画面表示制御部１６は経過時間の測定を開始する（Ｓ２０）。この経過時間は、文字色の変更や画面分割の終了の判定に使用される。また、アラーム情報生成部１４はアラーム情報の拡張部の経過時間に、ここで測定を開始した経過時間を設定する。時間は変化するものであるため、例えば１分ごとに拡張部の経過時間を更新する。

次に、画面表示制御部１６は件数の測定を開始する（Ｓ３０）。この件数とは、同じアラームの数である。ステップＳ１０でＮｏと判定されたアラームは件数のカウント対象となる。また、アラーム情報生成部１４はアラーム情報の拡張部の件数に、ここで測定を開始した件数を設定する。例えば件数が増えるごとに拡張部の件数を更新する。

次に、監視システム１０は過去事例の有無を判定する（Ｓ３２）。過去事例の有無の判定とは、過去に類似のアラームが発生されているか否かを判定することをいう。具体的には検索要求部２３はインシデント管理システム３０にアラーム情報を送信して類似するアラーム情報の有無を問い合わせる。類似するかどうかは、集約条件に基づいて判定されてもよいし異なっていてもよい。異なっている場合、例えば別の顧客のインシデントデータを検索できる。

アラーム情報と類似するインシデントデータがある場合、インシデント管理システム３０は類似するインシデントデータを監視システム１０に送信する。これにより、アラーム情報生成部は過去事例フラグをＯＮに設定する。なお、類似するインシデントデータがあるアラーム情報は過去事例フラグのＯＮによりその旨が自動的に画面に表示される。また、オペレータの操作によりインシデントデータが表示されてもよい。インシデントデータの表示例については図１９にて説明することにする。

次に、監視システム１０は同じ障害が再発した場合の処理を行う（Ｓ３４）。すなわち、再発監視部２２はアラーム情報ＤＢ１００４をアラーム情報で検索して障害が再発したか否かを判定する。詳細は図１４にて説明される。

次に、画面表示制御部１６は新規のアラームが発報されてから所定時間Ｔ１が経過したか否かを判定する（Ｓ４０）。所定時間Ｔ１は大量のアラームが発報されるかどうかを予想するための時間である。この所定時間Ｔ１に多くのアラームが発報される場合は以降も大量のアラームが発報されると予想される。所定時間Ｔ１は例えば数十秒〜数分であるものとして説明するが、これには限られない。また、オペレータ９や担当者８が任意の所定時間Ｔ１を設定してもよい。

ステップＳ４０の判定がＹｅｓの場合、処理はステップＳ２０に戻る。これにより所定時間Ｔ１が経過したアラームは集約せず、新規アラームとして取り扱うことができる。

ステップＳ４０の判定がＮｏの場合、所定時間Ｔ１が経過していないので、同じアラームの件数をカウントしたり（Ｓ５２）、経過時間の測定を継続したりする。

次に、アラーム情報生成部１４はアラーム情報の件数が１より多いか否かを判定する（Ｓ６０）。この"１"は複数の同じアラーム情報を集約するか否かを判定するための閾値である。この閾値はオペレータ９が適宜設定でき"１"に限られない。

ステップＳ６０の判定がＹｅｓの場合、アラーム情報生成部１４はアラーム情報の拡張部の集約フラグをＯＮに設定する（Ｓ７０）。したがって、所定時間Ｔ１で収集された複数のアラームの件数が１より多い場合、アラーム情報が集約される。

次に、アラーム情報生成部１４は同じアラーム情報の件数が３０より多いか否かを判定する（Ｓ８０）。この"３０"は１つの画面に表示可能なアラーム情報が想定された閾値である。換言すると画面を分割した方が見やすいと考えられる同じアラームに基づくアラーム情報の数である。この閾値はオペレータ９が適宜設定でき"３０"に限られない。

ステップＳ８０の判定がＹｅｓの場合、アラーム情報生成部１４はアラーム情報の拡張部の分割フラグをＯＮに設定する（Ｓ９０）。

なお、同じアラームから生成されたアラーム情報の拡張部は共通になる（同じ情報を有する）ので、ステップＳ７０と９０において、アラーム情報生成部１４は同じアラームの最初のアラーム情報の拡張部だけ設定してもよいし、全てのアラーム情報の拡張部に設定してもよい。

次に、画面表示制御部１６は分割フラグがＯＮか否かを判定する（Ｓ１００）。分割フラグがＯＮである場合、画面分割部１７は後述するように画面を分割する（Ｓ１１０）。分割された画面の一例を図１３に示す。これにより、画面には新しく分割領域が生成される。スクロール制御部１８は分割で生成された分割領域内で表示されるアラーム情報のスクロール速度を一定以下に制御する。詳細は図１２にて説明される。

次に、画面表示制御部１６は集約フラグがＯＮか否かを判定する（Ｓ１２０）。集約フラグがＯＮである場合、アラーム情報集約部２１は同じアラームから生成された複数のアラーム情報を集約する（Ｓ１３０）。集約の例を図７にて説明する。なお、アラーム情報生成部１４は集約番号を付与して、アラーム情報の拡張部に設定する。また、ステップＳ１３０の集約よりも後にステップＳ１１０の画面の分割が行われてもよい。

次に、画面表示制御部１６はアラーム情報の表示色を制御する（Ｓ１４０）。表示色の制御とは、集約されたアラーム情報の色をアラームが発報されてからの時間、集約の件数、又は、重要度等によって変更することをいう。表示色は、表示色フラグにより制御される。詳細は図８，９にて説明される。

次に、発生頻度監視部２４は、障害の発生頻度の変化処理を行う（Ｓ１４２）。発生頻度の変化処理は、発生頻度が急に変化したことを検出して、その旨を表示する処理である。詳細は図１６にて説明される。

次に、画面表示制御部１６は、同じアラームの最初の発報から所定時間Ｔ２が経過したか、又は、オペレータ９の対応が完了したか否かを判定する（Ｓ１５０）。これにより、画面の分割、及び、集約されたアラーム情報の表示色の制御を解除するか否かが判定される。所定時間Ｔ２が経過したか、対応完了かによって若干、処理が異なっている。対応完了の場合、分割により生成された分割領域は、消去される。分割領域が多くなりすぎてオペレータ９にとって画面が見にくくなることを抑制できる。所定時間Ｔ２が経過した場合、分割領域が消去される場合も残される場合もある。

なお、所定時間Ｔ２はオペレータ９が障害に対応することができる時間、障害が解決することが想定される時間、又は、障害を解決すべき時間であり予め定められている。所定時間Ｔ２は例えば、１０分であるがこれに限られるものではなく、顧客や障害内容によって異なっていてもよい。

所定時間Ｔ２が経過した場合、アラーム情報生成部１４はアラーム情報の拡張部の対応完了に解決した旨を設定する。また、オペレータ９が対応を完了させた場合には、オペレータ９がアラーム情報の拡張部の対応完了に解決した旨を設定する。

ステップＳ１５０の判定がＮｏの場合、処理はステップＳ１００に戻り、ステップＳ１００以下の処理が繰り返し実行される。これにより、同じアラームが発生すれば分割領域に表示され、また、集約して表示される。

ステップＳ１５０の判定がＹｅｓの場合、画面表示制御部１６は分割フラグをＯＦＦに設定する（Ｓ１６０）。集約フラグがＯＮのままなのは、集約された状態でスクロールされてよいためである。

そして、分割フラグがＯＦＦなので、画面分割部１７は画面の分割を解除する（Ｓ１７０）。画面の分割を解除するとは、分割領域に表示されていた同じアラーム情報と分割領域を消去することをいう。

また、画面表示制御部１６は、表示色の制御を終了する（Ｓ１８０）。すなわち、障害が解決されたと推定されるので集約されたアラーム情報の色を元の色に戻す。ただし、画面の分割が解除されても、切り分け対応が未完で集約状態が残っているのであれば、アラーム情報の色は変更されたままでよい。

以上で、同じアラームに起因した画面の分割（スクロール速度の制御）と集約の処理が完了する。ステップＳ１５０の判定で分かるように、所定時間Ｔ２が経過することで図６の処理が終わった場合は、再度同じ、アラームが発生する可能性がある。また、オペレータ９が対応したが、再度同じ、アラームが発生する可能性はゼロでない。このような場合は、図１４にて後述するように、同じアラームが再発したことが画面に表示される。

＜集約処理＞
図７は、集約処理を説明する図の一例である。図７（ａ）はアラーム情報の一例を示す。図７（ａ）のアラーム情報はアラームが発報されることで時系列に生成されるリアルタイムのアラーム情報である。各項目の内容については表４と重複するため省略する。図７（ａ）では下から上に、発生した障害から生成されたアラーム情報が順番に表示されている。図７（ａ）のアラーム情報がディスプレイ３０８の画面に表示されるが、画面からあふれたアラーム情報は削除されてしまうか、又は、削除されずに欄外表示になり見えなくなる。

そこで、アラーム情報集約部２１は、集約条件を満たすアラーム情報を集約する。例えば、集約条件が「同一のサーバＩＤを有するアラーム情報を集約する」である場合、図６にて説明したように、新規のアラームが発生してから所定時間Ｔ１以内に１つより多い同じサーバＩＤを有するアラーム情報が生成されると、アラーム情報集約部２１はアラーム情報を集約する。

図７（ｂ）はサーバＩＤで集約されたアラーム情報の一例を示す。図７（ａ）でサーバＩＤがＳ００１のアラーム情報が４つあるが、通番１と４のアラーム情報が所定時間Ｔ１以内に生成されたものである場合、集約条件を満たす。また、図６で所定時間Ｔ２が経過したか、又は、オペレータ９の対応が完了する前に通番が６と７のアラーム情報が生成されたとする。この場合、４つのアラーム情報が集約される。したがって、図７（ｂ）ではサーバＩＤがＳ００１のアラーム情報は４つになる。アラーム情報生成部１４は集約されるアラーム情報を生成すると拡張部の件数を更新する。図７（ｂ）のサーバＩＤがＳ００１のアラーム情報では、４件のアラーム情報が集約されていることが分かる。同様に、サーバＩＤがＳ００２について、２つのアラーム情報が集約されている。なお、サーバＩＤがＳ００３のアラーム情報は集約の対象とならないが、後述する集約領域に表示される。これは、オペレータが集約領域を見ていれば適切な対応を可能とするためである。２回目のサーバＩＤがＳ００３のアラーム情報が生成された場合、集約条件を満たさなければ１件だけ表示される。

図７（ｂ）では、通番、顧客名、サーバＩＤ、発生時刻、アラーム番号、対応方法、及び、件数しか表示されないが、集約されたアラーム情報は拡張部（例えば集約番号）が同じになるので、集約された図７（ｂ）のアラーム情報と図７（ａ）のアラーム情報は対応付けられている。したがって、オペレータ９が図７（ｂ）のアラーム情報をマウスで右クリックするなどの操作を行うと、画面表示制御部１６は対応付けられているアラーム情報を画面に表示する。すなわち、図７（ａ）のアラーム情報がやがて画面からあふれてしまっても、画面表示制御部１６はアラーム情報ＤＢ１００４から集約番号で対応付けられているアラーム情報を読み出して図７（ｂ）の画面の横に表示したり重畳させて表示したりする。

また、例えば、集約条件が「同一の対応方法を有するアラーム情報を集約する」である場合、新規のアラームが発生してから所定時間Ｔ１以内に１つより多い同じ対応方法を有するアラーム情報が生成されると、アラーム情報集約部２１はアラーム情報を集約する。

図７（ｃ）はサーバＩＤと対応方法で集約されたアラーム情報の一例を示す。ここでは対応方法のうち同じ連絡方法のアラーム情報を同じ対応方法であると判定する。例えば、電話のよる連絡、電子メールによる連絡はそれぞれ同じ対応方法である。図７（ａ）でサーバＩＤがＳ００１で対応方法が電話のアラーム情報が３つあるが（佐藤さんに電話）、通番１、４、６のアラーム情報が所定時間Ｔ２以内に生成されたものである場合、３つのアラーム情報が集約される。また、サーバＩＤがＳ００２のアラーム情報についても同様で、対応方法が「Ａさんに電話」というアラーム情報が集約される。

したがって、図７（ｃ）では、通番が１、４、６の３つのアラーム情報が１つに集約される（件数が３）。通番が７のアラーム情報は対応方法が電子メールによる送信なので、サーバＩＤが同じ００１でも集約されないが、通番３のアラーム情報と同じ理由で集約領域に表示される。

このような集約は、対応の単位でアラーム情報を集約できるという利点がある。オペレータ９が画面を監視するのは適切なインシデント管理を行うため、すなわち適切な対応を迅速に行うためなので、対応方法が同じアラーム情報が集約されていれば、集約されたアラーム情報に対して１回の対応を行えばよいため対応しやすい。

なお、電話や電子メールという連絡方法を対応方法とするのは一例に過ぎず、電話番号又は電子メールのメールアドレス、で集約してもよい。また、連絡先となる担当者８で集約してもよい。また、対応方法の全体（担当者８と連絡先と連絡方法）で集約してもよい。

また、アラーム情報集約部２１は、所定時間Ｔ１の経過時にアラーム情報を集約した後に同じアラームが発報されると、所定時間Ｔ２が経過するか又は対応完了まで該アラームのアラーム情報も集約する。したがって、同じアラームは次々に集約されるためオペレータ９が対応しやすい。

また、アラーム情報の類似度でアラーム情報を集約してもよい。例えば、顧客名、サーバＩＤ、アラーム番号、及び、対応方法のそれぞれの項目で同じアラーム情報があれば、アラーム情報集約部２１は項目に応じた点数をアラーム情報に付与する。例えば、顧客名…６、サーバＩＤ…１０、アラーム番号…４、対応方法…３などのように予め定められた点数を新規のアラーム情報を基準にして時間的に後のアラーム情報に付与する。この点数は類似性が高いと推測される項目ほど高くなっている。アラーム情報集約部２１は閾値以上のアラーム情報は同じアラームであると判定し集約する。したがって、各項目別に集約する場合には集約されないアラーム情報を集約できる可能性があり、集約効率を向上させることができる。

また、図７（ｂ）（ｃ）では集約の際、最初のアラーム情報に集約されているが（最初のアラーム情報だけが表示されている）、最後のアラーム情報に集約されてもよい。すなわち、同じアラーム情報が生成されるたびに、最後のアラーム情報のみが表示される。あるいは、最初のアラーム情報と最後のアラーム情報の２つを集約の結果として表示してもよい。

＜表示色フラグの処理＞
図８は、表示色フラグの制御手順を示すフローチャート図の一例である。図８の処理は例えば１分間に１回など適当な時間間隔をもって繰り返し実行される。表示色フラグの初期値は０であり、１〜３の値を取る。表示色フラグの数が大きくなると集約して表示されたアラーム情報の色が変化する。すなわち、注意喚起性が高い色に変わっていく。

まず、画面表示制御部１６は、集約フラグがＯＮであるか否かを判定する（Ｓ２１０）。これは、表示色の制御は集約されたアラーム情報に対し行われるためである。

ステップＳ２１０の判定がＹｅｓの場合、画面表示制御部１６は、集約されたアラーム情報の拡張部を参照して経過時間が３０分以上か否かを判定する（Ｓ２２０）。この判定は、経過時間がアラーム情報を注意喚起性が高い色に変えるほどの時間を超えたか否かを判定するためのものである。したがって、３０分には限られない。

ステップＳ２２０の判定がＹｅｓの場合、画面表示制御部１６は表示色フラグを"３"に設定する（Ｓ２３０）。

ステップＳ２２０の判定がＮｏの場合、画面表示制御部１６は、集約されたアラーム情報の拡張部を参照して経過時間が１０分以上か否かを判定する（Ｓ２４０）。この判定は、経過時間がアラーム情報を注意喚起性が中程度の色に変えるほどの時間を超えたか否かを判定するためのものである。したがって、１０分には限られない。

ステップＳ２４０の判定がＹｅｓの場合、画面表示制御部１６は表示色フラグを"２"に設定する（Ｓ２５０）。

ステップＳ２４０の判定がＮｏの場合、画面表示制御部１６は表示色フラグを"１"に設定する（Ｓ２６０）。

以上のような処理を１分に１回程度行えば、経過時間に応じて表示色フラグが制御される。なお、表示色フラグの制御は画面に表示中の集約されたアラーム情報にだけ行えばよい。

次に、図９を用いて表示色フラグを用いたアラーム情報の表示色の制御について説明する。図９は、画面表示制御部１６がアラーム情報の表示色を制御する手順を示すフローチャート図の一例である。図９の処理は図６のフローチャート内で実行される。

画面表示制御部１６は、表示色フラグが"１"か否かを判定する（Ｓ３１０）。ステップＳ３１０の判定がＹｅｓの場合、画面表示制御部１６はアラーム情報をYellowで表示する（Ｓ３２０）。

ステップＳ３１０の判定がＮｏの場合、表示色フラグが"２"か否かを判定する（Ｓ３３０）。

ステップＳ３３０の判定がＹｅｓの場合、画面表示制御部１６はアラーム情報をOrangeで表示する（Ｓ３４０）。

ステップＳ３３０の判定がＮｏの場合、表示色フラグが"３"か否かを判定する（Ｓ３５０）。

ステップＳ３５０の判定がＹｅｓの場合、画面表示制御部１６はアラーム情報をRedで表示する（Ｓ３６０）。

ステップＳ３５０の判定がＮｏの場合、画面表示制御部１６はアラーム情報の表示色を制御しない。したがって、例えば白黒などの強調性の低い色で表示されたままとなる。

なお、経過時間による変更だけでなく、件数等よって表示色を変更してもよい。例えば、以下のように表示色を変更する。

１０件未満：黄色
１０件以上：赤色
また、経過時間、件数及び重要度の２つ以上を組み合わせて表示色を変更してもよい。

図１０は、表示色が制御されるアラーム情報の一例を示す図である。図１０（ａ）は集約された直後のＡ社とＢ社のアラーム情報を示す。経過時間はいずれも１０分未満であるため、図１０（ａ）のＡ社とＢ社のアラーム情報はYellowで表示されている。Ｃ社と通番７のＡ社のアラーム情報は集約されていないので文字色は通常のままである。なお、実際の画面ではYellowという文字が表示されるのでなく、文字が黄色で表示される。

図１０（ｂ）は図１０（ａ）の状態から１０分以上経過した状態のアラーム情報を示す。Ａ社とＢ社のアラーム情報はアラームの発生から１０分以上経過しているので、Ａ社とＢ社のアラーム情報はOrangeで表示されている。これに対し、Ｃ社と通番７のＡ社のアラーム情報は発生から１０分が経過していないので、Yellowで表示されている。

図１０（ｃ）は図１０（ｂ）の状態から２０分以上（最初のアラームの発報から３０分以上）経過した状態のアラーム情報を示す。新たな集約によりＤ社のアラーム情報が追加されている。Ａ社とＢ社のアラーム情報はアラームの発生から３０分以上経過しているので、Ａ社とＢ社のアラーム情報はRedで表示されている。Ｃ社と通番７のＡ社のアラーム情報はアラームの発生から１０分以上経過しているのでOrangeで表示されている。Ｄ社のアラーム情報は発生から１０分が経過していないので、Yellowで表示されている。

このような処理により、アラームの発報からの経過時間に応じてアラーム情報の表示色を変更できる。オペレータ９は表示色によってどのアラーム情報が長時間、解決されていないかを感覚的に把握できる。

表示色の変更には、文字色の変更の他、背景色の変更が含まれる。また、文字を点滅させたり、文字を拡大して表示してもよい。

＜画面分割処理＞
図１１は、画面の分割について説明する図の一例である。図１１（ａ）は図７（ａ）と同じものであり、アラーム情報がリアルタイムに表示される。したがって、アラームが発報される頻度によってはオペレータ９が確認する前にアラーム情報が画面からあふれてしまう場合がある。そこで、本実施形態の監視システム１０は、画面を分割して生成した分割領域に同じアラーム情報を表示し、さらに、スクロール速度を制御する。これにより、アラーム情報があふれる前にオペレータ９が確認しやすくなる。

図６にて説明したように画面の分割条件は件数を除いて集約条件と同じである。分割するかどうかと集約するかどうかで、所定時間Ｔ１における同じアラームの件数と比較される閾値が異なっている。この閾値が分割するかどうかと集約するかどうかで同じでもよい。この場合、アラーム情報が集約される場合は画面も分割される。また、分割条件と集約条件が互いに全く独立（互いに異なる）でもよい。

画面分割部１７は分割条件を満たす複数のアラーム情報を、画面を分割して生成した分割領域に表示する。例えば、分割条件が「同一のサーバＩＤを有するアラーム情報」である場合、図６にて説明したように、新規のアラームが発生してから所定時間Ｔ１以内に３０以上の同じサーバＩＤを有するアラーム情報が生成されると、画面分割部１７は画面を分割してアラーム情報を表示する。

図１１（ｂ）はサーバＩＤが同じため分割して表示されたアラーム情報の一例を示す。図１１（ａ）で説明の便宜上、サーバＩＤがＳ００１のアラーム情報が４つしかないが、不図示の部分を含めて３０以上あれば、図１１（ｂ）のアラーム情報が分割領域に表示される。

図１１（ｂ）では、図１１（ａ）と同じ項目のアラーム情報が表示されているが、画面分割部１７は分割して表示されるアラーム情報の項目を少なくしてもよい。この場合、オペレータ９が図１１（ｂ）のアラーム情報（例えば項目の部分）をマウスで右クリックするなどの操作を行うと、画面分割部１７は表示されていないアラーム情報の項目を表示する。したがって、限られた画面に発報件数が多いアラームのアラーム情報を、画面を分割して表示しておき、必要に応じて詳細な項目を表示できる。

なお、画面表示制御部１６は、所定時間Ｔ１の経過時に画面を分割した場合、分割後に同じアラームが発報されると、該アラームのアラーム情報を分割した場面に表示する。したがって、障害の発生頻度が高いと分割された画面からも、オペレータ９が確認する前にアラーム情報があふれてしまうおそれがある。そこで、以下のようにスクロール制御部１８が分割領域におけるアラーム情報のスクロール速度を制御する。

図１２は、スクロール速度の制御手順を示すフローチャート図の一例である。図１２の処理は、図６のフローチャート図の処理により画面が分割された場合に、定期的に実行される。画面の分割により、所定時間Ｔ１に発報されたアラームに関するアラーム情報は分割領域に表示されている。

スクロール制御部１８は、同じアラームが発報されたか否かを判定する（Ｓ４１０）。同じアラームが発報されない場合、スクロール制御部１８は待機する。同じアラームとは分割領域のアラーム情報と同じアラーム情報が生成されるアラームをいう。

ステップＳ４１０の判定がＹｅｓの場合、スクロール制御部１８はタイマーがオーバーフローしたか否かを判定する（Ｓ４２０）。タイマーとはステップＳ４４０でセットされるタイマーであり、このタイマーは最後にアラーム情報が追加して表示されてからの時間を測定する。

ステップＳ４２０の判定がＮｏの場合、スクロール制御部１８はアラーム情報を表示することなく待機する。

ステップＳ４２０の判定がＹｅｓの場合、スクロール制御部１８は、分割領域に表示されているアラーム情報の全体を１行ずつ下に移動した後、分割領域の最上部に新しいアラーム情報を追加して表示する（Ｓ４３０）。

そして、スクロール制御部１８はタイマーをセットする（Ｓ４４０）。これにより、タイマーは再度、時間の測定を開始する。したがって、タイマーのオーバーフロー値が適切に設定されていることで、スクロール速度を制御できる。スクロール速度が制御されることで、数多くのアラーム情報が生成され分割領域に表示されてもオペレータ９が確認する前にあふれてしまうことを抑制できる。また、分割領域に表示されるアラーム情報は同じアラームに関して生成されたアラーム情報なので、オペレータ９が確認しやすいという利点がある。また、分割領域で仮にアラーム情報があふれても、オペレータ９は過去に遡るようにアラーム情報をスクロールさせることで過去のアラーム情報を確認できる。異なるアラーム情報が混在している場合は、他のアラーム情報が次々と生成されるため過去のアラーム情報をスクロールさせると、アラームのリアルタイムの発報状況を確認しにくくなる。これに対し、本実施形態のように分割領域が生成されることで、オペレータ９は他のアラーム情報とは関係なく分割領域のアラーム情報を処理できる。

なお、画面分割部１７は同じアラーム情報の数に応じて画面に表示するアラーム情報の表示色を可変にしてもよい。例えば、画面が分割されてからの累計の件数が３０〜４９で黄色、５０以上で赤のように変更する。これにより、オペレータ９はアラームのおよその発報件数が分かるのでアラームの重要度を把握しやすくなる。あるいは、集約されたアラーム情報と同じ表示色に変更してもよい。

また、図１２ではスクロール速度を一定以下に制御する例を説明したが、アラーム発報対象情報から読み出された重要度に応じてスクロール速度を変化させてもよい。例えば、重要度が大きいほど早くスクロールさせる、又は、重要度が大きいほど遅くスクロールさせる。早くスクロールさせる場合、画面分割部１７は同じアラーム情報を何度も画面に表示させるので（最後のアラーム情報を表示したら最初のアラーム情報から再度、表示する）、オペレータがアラーム情報を補足できないということはない。これにより、集約されたアラーム情報のうち、緊急性の高いものに気づきやすくなる。また、単なる警告表示と異なり、アラームの傾向や個々のアラームについて認識が容易になる。オペレータがスクロール速度を操作により調整してもよい。

なお、スクロール制御部１８は分割領域のスクロール速度だけでなく、メイン領域及び集約領域のスクロール速度を制御してもよい。すなわち、分割領域、メイン領域及び集約領域の１つ以上のスクロール速度を同様な処理で制御できる。

＜画面例＞
図１３を用いて、画面の分割やアラーム情報の集約について説明する。図１３はアラーム情報が表示されるアラーム表示画面６００を示す図である。アラーム表示画面６００は、時系列に全てのアラーム情報が表示されるメイン領域６０１、集約されたアラーム情報が表示される集約領域６０２、及び、分割により生成された分割領域６０３を有する。メイン領域６０１にはリアルタイムに発報され生成されたアラーム情報が上から下に時系列に表示される。集約領域６０２には図７（ｂ）又は（ｃ）のように集約されたアラーム情報が表示される（図１３では図７（ｃ）が表示されている）。分割領域６０３には分割フラグがＯＮのアラーム情報が、同じ集約番号ごとに表示される。

各領域はウィンドウ形式なのでオペレータが各領域の場所を任意に変更できる。また、表示されるアラーム情報の項目をオペレータが取捨することもできる。

図１３の表示形式は一例に過ぎず、オペレータがタブを切り替えることで３つの領域のいずれかが画面を占有して表示されてもよい。この他、アラーム表示画面６００は図示される形式には限定されない。

また、メイン領域６０１、集約領域６０２、及び、分割領域６０３は同じディスプレイに表示される場合も異なるディスプレイに表示される場合もある。

<<同じ障害の再発>>
図６のステップＳ３４にて説明したように、集約されたアラーム情報や分割して表示されたアラーム情報は、障害の発生から所定時間Ｔ２が経過するか又は対応完了により、分割が解除される。

しかし、切り分け対応済みのアラーム情報と同じアラームが再度、現れる場合が生じうる。これは、所定時間Ｔ２が経過したがオペレータ９や顧客の担当者８が何ら対応しなかった場合や、対応完了がアラーム情報に登録されたが、同じアラームが再度発報された場合に生じる。この場合、すでに所定時間Ｔ２が経過しているか、又は、対応が困難な障害が発生した可能性があるため、早急な対応が必要である。

そこで、アラーム情報集約部２１は、集約されたアラーム情報及び過去に発生したアラーム情報等を用いて、同じアラームが再度、発報されたことをオペレータ９に知らせる。

図１４は、同じ障害に基づくアラームが再度、発報されたことを監視システム１０が画面に表示する手順を示すフローチャート図の一例である。図１４の処理は図６のステップＳ３２で実行される。

アラームが発報されると監視システム１０は、近い過去に発生し、対応されたアラームが再発したか否かを判定する（Ｓ６１０）。まず、再発監視部２２はアラーム情報ＤＢ１００４から過去のアラーム情報のうち、拡張部の対応完了に対処が完了した旨が登録されているアラーム情報を読み出す。どのくらい過去まで読み出すかは再発したと判定される程度の期間でよい。例えば、１時間程度であるがこれには限れられない。次に、発報されたアラーム情報と同じアラームかどうかを判定する。同じかどうかの判定は集約条件と同じでよい。このような判定により、過去に集約されたアラームが再発したか否かを判定できる。

ステップＳ６１０の判定がＹｅｓの場合、画面表示制御部１６は、アラーム情報の再発フラグをＯＮに設定する（Ｓ６２０）。再発したアラーム情報はマークなどで強調して表示される。なお、再発した時点のアラーム情報処理は１つであるが集約して表示してもよい。過去に集約されているためである。

図１５は、再発したアラームに関するアラーム情報を模式的に示す図の一例である。図１５（ａ）は再発前のアラームに関するアラーム情報を示し、図１５（ｂ）は所定時間Ｔ２が経過するか又は対応完了したアラーム情報を示す。図１５（ａ）ではＡ社、Ｂ社のアラーム情報が集約によりYellowで表示されている。図１５（ｂ）に示すように対応完了することで、Ａ社（通番１）、Ｂ社（通番２）のアラーム情報が非表示になる。所定時間Ｔ２が経過したが未対応のアラーム情報はYellowのまま表示される。なお、図１５（ｂ）では、Ｃ社のアラーム情報が追加されている。

図１５（ｃ）はＡ社のアラームが再度発報された場合のアラーム情報を示す。画面表示制御部１６は、再度発報されたアラーム情報が、過去に集約されていたアラーム情報と同じアラームに起因することを示すため★マークを表示している。これにより、オペレータ９は表示されたアラーム情報が過去に集約されたアラーム情報と同じアラームに基づき生成されたことを容易に把握できる。

なお、図１５の表示例は一例であり、過去に集約されていたアラーム情報と同じアラームが再度発報されたことを文字で表示してもよい。また、アラーム情報の輝度を上げたり、点滅させたり、文字を大きく表示したりしてもよい。

<<発生頻度の変化処理>>
同じ複数のアラームの発報が停止した場合、一般に、アラームを発報させていた障害が解決したと推定される。障害が解決したと推定される場合、オペレータ９は他のアラームを優先するなどの行動が可能になる。

図１６は、発生頻度監視部２４がアラームを発報させていた障害が解決したと推定する手順を示すフローチャート図の一例である。図１６の手順は、例えば図６のステップＳ１４２で実行される。

発生頻度監視部２４は、同じアラームが発報されたか否かを判定する（Ｓ７１０）。

ステップＳ７１０の判定がＹｅｓの場合、発生頻度監視部２４は、アラームが発報されるとタイマーの測定値が閾値１よりも小さいか否かを判定する（Ｓ７２０）。このタイマーは同じアラームの発報のたびにセットされるタイマーであり、同じアラームが発報されてからの時間を測定している。閾値１は、同じアラームが連続していると見なせる程度の時間である。

ステップＳ７２０の判定がＹｅｓの場合、発生頻度監視部２４は連続フラグを１つ大きくする（Ｓ７３０）。連続フラグは、同じアラームが連続して発報されていると見なせる程度の同じアラームの件数である。

ステップＳ７３０に続いて、又は、ステップＳ７２０の判定がＮｏの場合、発生頻度監視部２４はタイマーをセットする（Ｓ７４０）。すなわち、タイマーは同じアラームの発報のたびにセットされる。この後、処理はステップＳ７１０に進む。

ステップＳ７１０の判定がＮｏの場合、発生頻度監視部２４はタイマーの測定値が閾値２よりも小さいか否かを判定する（Ｓ７５０）。閾値２は、連続していた同じアラームが途切れたと見なせる程度の時間である。

ステップＳ７５０の判定がＮｏの場合、処理はステップＳ７１０に進む。

ステップＳ７５０の判定がＹｅｓの場合、発生頻度監視部２４は、連続フラグが閾値３よりも大きいか否かを判定する（Ｓ７６０）。ステップＳ７６０の判定がＮｏの場合、同じアラームは止まったが連続していたほどではないので、図１６の処理は終了する。

ステップＳ７６０の判定がＹｅｓの場合、画面表示制御部１６はアラーム情報に、障害が解決したと推定される旨みを表示する（Ｓ７７０）。

図１７は、解決済みが表示されるアラーム情報を模式的に示す図の一例である。図１７ではＡ社、Ｂ社のアラーム情報が集約によりYellowで表示されているが、Ａ社のアラーム情報に「解決？」という文字が表示されている。この文字は、障害が解決したと推定される旨を意味する。これにより、オペレータ９は表示されている障害が解決した可能性があると判断できる。

なお、図１７の表示例は一例であり、単なるマークにより障害が解決した可能性があることを表示してもよいし、アラーム情報の輝度を下げたり、文字を小さく表示したりしてもよい。

<<過去の事例の表示>>
図６にて説明したように、過去事例フラグがＯＮの場合、監視システム１０は、集約されたアラーム情報や分割領域で表示されるアラーム情報に過去に類似するインシデントデータがある旨を表示する。また、オペレータの操作によっても過去のインシデントデータを表示することができる。以下では、オペレータの操作によって表示されるインシデントデータについて説明する。

図１８は、監視システム１０がアラーム情報に関連したインシデントデータを表示する手順を示すフローチャート図の一例である。図１９は、集約されたアラーム情報と共に表示されるインシデントデータを模式的に示す図の一例である。図１８の説明では適宜、図１９を参照して説明する。図１９（ａ）の通番が１のアラーム情報には類似インシデントマーク５０３が表示されている。類似インシデントマーク５０３は過去事例フラグのＯＮにより表示される。

S1：オペレータ９は類似インシデントマーク５０３をみて、マウス３１２のカーソル５０２を例えば右クリックする。監視システム１０の操作受付部１５は集約されたアラーム情報の選択を受け付ける。図１９（ａ）に示すように、画面表示制御部１６が「過去事例の表示」というメニュー５０１を表示する。このメニュー５０１は、オペレータ９がマウス３１２で選択したアラーム情報と類似する過去のアラーム情報を、監視システム１０が表示するためのメニューである。オペレータ９がマウス３１２を例えば左クリックすることでメニュー５０１を押下する。監視システム１０の操作受付部１５はメニュー５０１の押下を受け付ける。

S2：監視システム１０はアラーム情報の項目をインシデント管理システム３０に送信する。この項目はインシデントデータＤＢ３００１を検索するための項目である。例えば、サーバＩＤとアラーム番号などである。

S3：インシデント管理システム３０はアラーム情報の項目を受信し、データ検索部３２がアラーム情報の項目でインシデントデータＤＢ３００１を検索する。すなわち、サーバＩＤとアラーム番号が同じインシデントデータをインシデントデータＤＢ３００１から検索する。

S4：インシデント管理システム３０の送受信部３１は検索に適合したインシデントデータを監視システム１０に送信する。

S5：監視システム１０はインシデントデータを受信して、画面表示制御部１６がディスプレイ３０８にインシデントデータを表示する。図１９（ｂ）では、サーバＩＤとアラーム番号が同じインシデントデータが表示されている。したがって、担当者は過去の類似したアラーム情報の対応方法を参照して対応することができる。

なお、検索に用いられるアラーム情報の項目はアラーム番号だけでもよい。この場合、セキュリティで許可されている場合にインシデント管理システム３０は異なる顧客のアラーム情報を検索できる。また、検索に用いられるアラーム情報の項目はサーバＩＤだけでもよい。この場合、インシデント管理システム３０は同じ顧客のアラーム情報だけを検索できる。このように検索に用いられるアラーム情報の項目によって得られるインシデントデータが異なるので、検索に用いられるアラーム情報の項目はオペレータ９が任意に選択できることが好ましい。

＜アラーム情報のその他の表示例＞
集約されたアラーム情報又は分割して表示されたアラーム情報のその他の表示例について説明する。

<<作業に起因するアラーム情報>>
顧客の担当者８が作業中の場合、アラームが頻繁に発報される場合がある。これは、作業により被監視システム４１のサーバがＰＩＮＧ応答しなくなったり、ラックが開放されたりするためである。しかし、作業に起因するアラーム情報は、オペレータ９が顧客に連絡する必要性がほとんどない。そこで、以下のように、作業に起因するアラーム情報を検出し、その旨を画面に表示してもよい。

図２０は、アラーム情報集約部２１が、作業に起因するアラーム情報を検出して画面を表示する手順を示すフローチャート図の一例である。図２０の処理は図６の集約処理の後、前後、又は並行して実行される。

まず、アラーム情報集約部２１は例えばアラーム情報のサーバＩＤをキーにして顧客作業情報ＤＢ１００５を参照する（Ｓ５１０）。これにより、アラーム情報と同じサーバＩＤが設定された顧客作業情報を読み出すことができる。

次に、アラーム情報集約部２１は集約されたアラーム情報が作業に起因するかどうかを判定する（Ｓ５２０）。アラーム情報集約部２１は、ステップＳ５１０で読み出した顧客作業情報のうち、アラーム情報の発生日時が作業時間と重複するかどうかを判定する。

ステップＳ５２０の判定がＮｏの場合、図２０の処理は終了する。

ステップＳ５２０の判定がＹｅｓの場合、アラーム情報集約部２１は集約されたアラーム情報に作業中である旨を表示する（Ｓ５３０）。

図２１は、集約されたアラーム情報を模式的に示す図の一例である。図２１のアラーム情報には、作業中の項目が表示されており、Ａ社のアラーム情報に「作業中」という文字が表示されている。したがって、オペレータ９は集約されたアラーム情報が顧客の担当者８の作業に起因するものかどうかを一目で把握でき、オペレータ９が顧客に連絡する必要性がない又は連絡はしても緊急度が低いことを把握できる。

なお、図２１の表示例は一例であり、顧客作業情報に含まれる情報であれば画面表示制御部１６が表示できる。例えば、作業時間、担当者８、備考などを表示してよい。また、「作業中」のように文字で表示するのでなく、作業に起因するアラーム情報の輝度を下げたり、白黒表示したり、文字を小さく表示したりしてもよい。

＜その他の適用例＞
以上、本発明を実施するための最良の形態について実施例を用いて説明したが、本発明はこうした実施例に何等限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変形及び置換を加えることができる。

図２２に示すように、複数台の端末を監視システムに接続することも有効である。図２２は、複数台の端末を利用した監視システム１０の適用例を説明する図の一例である。端末Ａをオペレータが使用し、端末Ｂをリーダー５が使用する。リーダー５とは複数のオペレータの統括者である。このようなシステムによれば、監視システムのアラームに対応するだけでなく、アラームに対応するオペレータのアラームにも対応できる。オペレータは主に集約領域を監視し、メイン領域を参考のために参照する。リーダーは主に分割領域を監視し、メイン領域を参考のために参照する。オペレータの端末Ａとリーダーの端末Ｂは異なる画面を表示できる。

例えば、監視システム１０のアラームのバースト（対応しきれないほどのアラームが大量に発生する状態）が起こっている際又はオペレータの対応が遅延している際、オペレータ又は監視システム１０が分割領域を表示してリーダー５にエスカレーション（緊急対応の要請）する。この場合、監視システム１０はオペレータ９から通知を受けるなどにより端末Ｂに画面の分割を要求する。リーダー５は画面が分割されたことで対応が必要であることを把握できる。リーダー５は必要に応じてメイン領域を参照するので個別のアラームを確認できる。また、分割領域又はメイン領域のスクロール速度を調整すると、見たいアラームを早期に見つけられる。例えば、分割領域の一連のアラームの先頭にフォーカスした状態で、メイン領域を表示する。

リーダーへの通知は以下のようなケースが考えられる。
（１） 緊急度が高い（何かしらの支援や対処が必要なもの）ケースの例
・対応が遅延しているケース（例：アラーム発生時刻から未対応が１０分を超えた場合）
・バーストが発生しているケース（例：同一ユーザでシステムアラームが１分間で６０回を超えた場合）
・アラームが同時多発しているケース（例：複数ユーザで同時に２０件以上のアラームが発生した場合）
（２） 重要度が高い（周知が必要でリーダーが状況を把握しておく必要があるもの) ケースの例
・重要システムからのアラーム（例：社会基盤システム、センター共通サービス基盤など）
・重要顧客からのアラーム（例:重要顧客に位置づけられるユーザ）
・繰り返しアラームが発生している（例：同一ユーザにて1時間以上連続してアラームが出続けている）
したがって、分割領域を利用することでエスカレーションが容易になる。また、端末Ａにおけるオペレータの実作業と端末Ｂにおけるリーダー５の全体統制作業について、役割等も明確に分けることができる。上記のように、オペレータ９の対応方法ごとにアラームが集約されることで効率的な運用を実現できる。

さらに、分割領域がポップアップ表示される場合、重要性に応じて、ポップアップ位置を変えてもよい。例えば、重要性が高い時は右上、低い時は右下などに表示位置を決定する。これにより、オペレータ９は重要性の判断が容易になり、また、集約領域やメイン領域の真ん中に重畳するよりも視認性が向上する。

また、リーダーの端末Ｂが分割領域を表示する態様は２パターンある。１つは、オペレータの端末Ａで分割された分割対象のアラーム情報（複数の分割が発生）を、１つのレコードに集約して、複数の端末Ａのアラーム情報をリスト状に表示するパターンである。もう１つは、オペレータの複数の端末Ａで分割されたアラーム情報を、端末Ｂの別々のテーブルに表示するパターンである。この場合、各テーブルのアラーム情報は集約されない。個別のアラーム情報が表示されるのでスクロール制御されている場合に有効である。

なお、リーダー５ではなく、サブオペレータや担当者が別端末で確認する事なども可能である。

また、監視システム１０は、アラームの過去の発報状況と対応方法の組を学習することができる。この学習結果により、対応方法が学習されていないアラームが発報された場合、監視システム１０がオペレータ９に警告してもよい。例えば、強調色で表示したり、音声を出力したりしてもよい。監視システム１０がバイブレータを振動させたりパトランプを点滅させたりしてもよい。

また、本実施形態では、上から下にアラーム情報がスクロールされる例を説明したが、下から上にスクロールされてもよい。

また、本実施形態では、監視システム１０にローカルに接続されたディスプレイ３０８に表示される画面を説明したが、監視システム１０はサーバクライアント方式でもよい。この場合、監視システム１０はＷｅｂサーバ又はＷｅｂアプリとして機能しＨＴＭＬやJavaScript（登録商標）で生成された画面情報をクライアントＰＣに送信する。この画面情報には、アラーム情報が集約されている。また、分割領域のスクロール速度が一定化になるように画面情報が生成されている。したがって、オペレータ９は遠隔地から被監視システム４１を監視できる。

また、監視システム１０の機能は複数のサーバに分散して搭載されていてもよいし、監視システム１０が複数あってもよい。

また、図５などの構成例は、監視システム１０による処理の理解を容易にするために、主な機能に応じて分割したものである。処理単位の分割の仕方や名称によって本願発明が制限されることはない。監視システム１０、データセンター４０、及び、インシデント管理システム３０の処理は、処理内容に応じてさらに多くの処理単位に分割することもできる。また、１つの処理単位がさらに多くの処理を含むように分割することもできる。

また、本実施形態では障害の発生時のアラームを例にして説明したが、災害の発生時に発報されるアラームに対しても適用できる。災害とは、例えば、水害、風害、砂嵐、塩害、土砂災害、雪害、雹、雷、震度やマグニチュードが閾値以上の地震、火山の噴火、隕石の落下、太陽活動、テロ、暴動、爆発などである。

なお、アラーム情報生成部１４はアラーム情報生成手段の一例であり、画面表示制御部１６はアラーム情報表示手段の一例であり、画面分割部１７は分割領域生成手段の一例であり、スクロール制御部１８はスクロール速度制御手段の一例である。アラーム情報集約部はアラーム情報集約手段の一例であり、顧客作業情報ＤＢ１００５は作業予定情報の一例であり、集約領域に表示されたアラーム情報は集約アラーム情報の一例である。

１０ 監視システム
１２ 監視部
１３ アラーム判定部
１４ アラーム情報生成部
１５ 操作受付部
１６ 画面表示制御部
１７ 画面分割部
１８ スクロール制御部
２１ アラーム情報集約部
２２ 再発監視部
２３ 検索要求部
２４ 発生頻度監視部
３０ インシデント管理システム
４０ データセンター
４１ 被監視システム
１００ 運用管理システム
２００ 保守サービスシステム

Claims (10)

1. 被監視システムの稼動状況を監視し障害が検出された場合にアラームを発報する監視システムであって、
   前記アラームが発報されるごとに前記アラームに関するアラーム情報を生成するアラーム情報生成手段と、
   複数の同じアラーム情報を集約条件に基づいて１つの集約アラーム情報に集約するアラーム情報集約手段と、
   前記アラーム情報生成手段が生成した前記アラーム情報及び前記アラーム情報集約手段により集約された前記集約アラーム情報を表示するアラーム情報表示手段と、
   を有する監視システム。
2. 前記アラーム情報は、前記障害に対しオペレータが取るべき対応方法を含んでおり、
   前記集約条件が、前記対応方法が同じ前記アラーム情報を集約するという条件である場合、
   前記アラーム情報集約手段は、前記対応方法が同じ複数の前記アラーム情報を前記集約アラーム情報に集約する請求項１に記載の監視システム。
3. さらに、複数の同じアラーム情報を分割して表示する分割条件が満たされる場合、前記アラーム情報が時系列に表示される領域とは別の分割領域を生成する分割領域生成手段と、
   前記分割領域に前記同じアラーム情報を、停止状態を含む一定以下のスクロール速度で表示するスクロール速度制御手段と、を有する請求項１又は２に記載の監視システム。
4. 前記対応方法は、電話による連絡、電話による連絡の場合の電話番号、電子メールによる連絡、電子メールによる連絡の場合の電子メールアドレス、又は、ＳＮＳ（Social Network System）の通知先のいずれか１つ以上を含み、
   前記アラーム情報集約手段は、電話による連絡、電子メールによる連絡、電話番号、及び、電子メールアドレスのいずれか１つ以上が一致する複数の前記アラーム情報を前記集約アラーム情報に集約する請求項２に記載の監視システム。
5. 前記アラーム情報は、前記障害が解決したか否か登録される項目を有し、
   前記アラームの発報により生成した前記アラーム情報が、前記項目に前記障害が解決した旨が登録された前記アラーム情報と同じ場合、
   前記アラーム情報表示手段は、前記集約アラーム情報に集約された前記アラーム情報を生成させた前記アラームが再発したおそれがある旨を表示する請求項２に記載の監視システム。
6. 連続して発報されていた同じ前記アラームが所定時間、発報されなくなった場合、
   前記アラーム情報表示手段は、連続した前記アラームに関し表示されている前記集約アラーム情報に、前記障害が解決した可能性がある旨を表示する請求項２に記載の監視システム。
7. 前記アラーム情報表示手段は、複数の前記同じアラーム情報のうち最初の前記アラーム情報が生成された時からの経過時間又は前記同じアラーム情報が集約された件数を測定し、
   前記アラーム情報表示手段は、前記経過時間又は前記件数に応じて前記集約アラーム情報の表示色を変更する請求項２〜６のいずれか１項に記載の監視システム。
8. 前記アラーム情報表示手段は、前記被監視システムの前記障害として検出されうる前記被監視システムに対する作業の作業日時が登録された作業予定情報から前記作業日時を読み出し、前記アラームを発報させた前記障害の発生時刻と比較して、
   前記発生時刻が前記作業日時と重複する場合、前記集約アラーム情報に前記作業に起因するアラームの可能性がある旨を表示する請求項２〜７のいずれか１項に記載の監視システム。
9. 前記アラーム情報は、オペレータにより前記障害が解決したか否か登録される項目を有し、前記項目に前記障害が解決した旨が登録されると、
   前記分割領域生成手段は、前記分割領域に表示されていた複数の前記同じアラーム情報と共に前記分割領域を消去する請求項３に記載の監視システム。
10. 被監視システムの稼動状況を監視し障害が検出された場合にアラームを発報する情報処理装置を、
    前記アラームが発報されるごとに前記アラームに関するアラーム情報を生成するアラーム情報生成手段と、
    前記アラーム情報生成手段が生成した前記アラーム情報を時系列に表示するアラーム情報表示手段と、
    複数の同じアラーム情報を分割して表示する分割条件が満たされる場合、前記アラーム情報が時系列に表示される領域とは別の分割領域を生成する分割領域生成手段と、
    前記分割領域に前記同じアラーム情報を一定以下のスクロール速度で表示するスクロール速度制御手段、として機能させるためのプログラム。