JP2017156863A - 監視システム、プログラム - Google Patents
監視システム、プログラム Download PDFInfo
- Publication number
- JP2017156863A JP2017156863A JP2016037735A JP2016037735A JP2017156863A JP 2017156863 A JP2017156863 A JP 2017156863A JP 2016037735 A JP2016037735 A JP 2016037735A JP 2016037735 A JP2016037735 A JP 2016037735A JP 2017156863 A JP2017156863 A JP 2017156863A
- Authority
- JP
- Japan
- Prior art keywords
- alarm information
- alarm
- information
- same
- failure
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Landscapes
- Debugging And Monitoring (AREA)
Abstract
【課題】発生したアラームをオペレータが確認できる監視システムを提供する。【解決手段】監視システム10は、被監視システム41の稼動状況を監視し障害が検出された場合にアラームを発報する。アラーム情報生成手段14は、アラームが発報されるごとにアラームに関するアラーム情報を生成する。アラーム情報集約手段21は、複数の前記同じアラーム情報を集約条件に基づいて1つの集約アラーム情報に集約する。アラーム情報表示手段16は、アラーム情報生成手段が生成したアラーム情報及びアラーム情報集約手段により集約された集約アラーム情報を表示する。【選択図】図5
Description
本発明は監視システム及びプログラムに関する。
自社が提供するサービスや社内システムのサーバなどがデータセンターなどに設置される場合がある。データセンターは単にサーバやその設置場所などを提供する以外に、サーバなどの稼動状況を監視したり、サーバなどから障害を検出すると障害の内容を顧客の担当者に通知したりする管理システムを有している。
図1は、従来の運用管理システム100の動作を説明する図の一例である。障害の発生時に運用管理システム100のオペレータ9が行う行動を説明する。
(1)まず、データセンター40の被監視システム41に生じた障害を監視システム10が検出してアラームを発報する。アラームの内容はオペレータ9が監視する画面に表示される。
(2)オペレータ9は予め定められた対応方法を参照する。対応方法には、障害の発生時にオペレータ9がどのように対応するかが障害の内容に応じて定められている。具体的には、障害の内容に応じた連絡方法や連絡先(顧客の担当者8の電話番号など)である。
(3)オペレータ9は対応方法にしたがって担当者8に連絡する。
(4)連絡が済んだら又は障害が解決されるとオペレータ9はインシデント管理システム30に障害に対する対応結果を入力する。
(1)まず、データセンター40の被監視システム41に生じた障害を監視システム10が検出してアラームを発報する。アラームの内容はオペレータ9が監視する画面に表示される。
(2)オペレータ9は予め定められた対応方法を参照する。対応方法には、障害の発生時にオペレータ9がどのように対応するかが障害の内容に応じて定められている。具体的には、障害の内容に応じた連絡方法や連絡先(顧客の担当者8の電話番号など)である。
(3)オペレータ9は対応方法にしたがって担当者8に連絡する。
(4)連絡が済んだら又は障害が解決されるとオペレータ9はインシデント管理システム30に障害に対する対応結果を入力する。
このように、監視システム10が被監視システム41を監視して適切な対応を行うので、顧客は迅速に対処して復旧等を行うことができる。しかしながら、オペレータ人数が限られるため、対応困難な数のアラームが発生する場合がある。これは、重大な障害だけでなく通常とは異なるような軽微な事象もアラームの発報の対象となるためである。このため、オペレータ9がアラームの内容を確認して対応方法に基づく対応を所定の時間内に取ることが困難になる場合がある。アラームの全てについて個別の連絡などの対応が必要であるわけではないが、オペレータ9は全てのアラームについて少なくともアラームの内容を画面で確認する必要がある。また、同じアラーム(例えば同じサーバの障害に基づき発報されたアラームなど)については、オペレータ9が手動でアラームを集約させることができるが、集約を誤り適切な対応を取れない状況が発生するおそれがある。
そこで、従来から大量のアラームを効率よく処理するための技術が考案されている(例えば、特許文献1参照。)。特許文献1には、一定時間内に同一の監視対象サーバに発生した同一のアラートを一つのアラートにフィルタリングするコンピュータリモート監視システムが開示されている。
しかしながら、アラームを単に集約するだけではオペレータ9が確認できなかったアラームが存在しうるという問題がある。すなわち、自動的な集約により監視システム10の画面に表示されないアラームが存在するため、どのくらいの数のアラームが繰り返し発生しているかをオペレータ9は把握できない。一般に、重大な障害では数多くのアラームが発生され、また、長時間にわたって繰り返しアラームが発生される。したがって、集約される前のアラームが監視システム10の画面に表示されることがオペレータ9にとって重要な情報となる場合がある。
また、従来のアラームは、オペレータの取るべき対応方法(連絡先・方法等)に合わせて表示されるわけではないので、オペレータが効率的に対応できないという問題がある。
本発明は、上記課題に鑑み、障害により発報されたアラームをオペレータが確認することができる監視システムを提供することを目的とする。
本発明は、被監視システムの稼動状況を監視し障害が検出された場合にアラームを発報する監視システムであって、前記アラームが発報されるごとに前記アラームに関するアラーム情報を生成するアラーム情報生成手段と、複数の前記同じアラーム情報を集約条件に基づいて1つの集約アラーム情報に集約するアラーム情報集約手段と、前記アラーム情報生成手段が生成した前記アラーム情報及び前記アラーム情報集約手段により集約された前記集約アラーム情報を表示するアラーム情報表示手段と、を有する。
発生したアラームをオペレータが確認することができる監視システムを提供することができる。
以下、本発明を実施するための形態について図面を参照しながら説明する。
図2は、監視システム10が表示する画面を模式的に示す図の一例である。図2(a)は監視システム10がリアルタイムに表示する画面を示す。監視システム10は障害の発生を検出すると障害の内容を表すアラーム情報をリアルタイムに1行に1つの形式で表示する。図2(a)では監視システム10の顧客であるA社、B社、C社に関するアラーム情報が上から下方向に時系列に表示されている(上の行ほど新しい)。
図2は、監視システム10が表示する画面を模式的に示す図の一例である。図2(a)は監視システム10がリアルタイムに表示する画面を示す。監視システム10は障害の発生を検出すると障害の内容を表すアラーム情報をリアルタイムに1行に1つの形式で表示する。図2(a)では監視システム10の顧客であるA社、B社、C社に関するアラーム情報が上から下方向に時系列に表示されている(上の行ほど新しい)。
監視システム10は被監視システムなどに障害が発生するごとに1つのアラーム情報を上から追加して表示する。これに対し、1つ画面に表示可能なアラーム情報の数は有限である。このため、監視システム10はアラーム情報が一番上の行に追加されるごとに、他のアラーム情報を1つずつ下の行に繰り下げて表示する処理を行う。このような表示態様をスクロールと称する。なお、スクロールには、停止表示(停止状態)、特定行フォーカス表示等も含まれる。
したがって、一番下にあるアラーム情報はスクロールにより表示されなくなる(このような現象を「画面からあふれる」と称する場合がある)。また、アラーム情報のスクロール速度はどのくらいの頻度で監視システム10が障害を検出したかに依存する。つまり、監視システム10が頻繁に障害を検出した場合にはスクロール速度が速くなる。この結果、オペレータ9がアラーム情報を確認するまでにアラーム情報が画面からあふれてしまう場合がある。
そこで、図2(b)に示すように、本実施形態の監視システム10はスクロール速度を一定以下に制御する。図2(b)ではスクロール速度を矢印401,402の太さで表している。すなわち、A社のアラーム情報が後述される分割条件を満たすと監視システム10は画面を分割したりポップアップウィンドウ403を表示したりしてA社のアラーム情報のみを表示する。そして、A社のアラーム情報だけ(同じアラーム情報だけ)を一定速度以下のスクロール速度で表示する。図2(b)はA社又はあるサーバ等の機器単位のアラーム情報のみがポップアップ表示された例である。
この一定速度は、人間の目で追える程度の速さでありオペレータ9がアラームの内容を確認するまでに画面からあふれることがないように決定されている。
したがって、オペレータ9は、大量のアラームが発生してもほぼ全てのアラーム情報を確認でき、どのくらいの数のアラームが繰り返し発生しているかを把握できる。また、アラームの内容を確認できるので対応方法にしたがって障害に対する適切な対応を取ることができる。
<用語について>
障害…被監視システム41において生じた通常と異なる事象である。本実施形態では予め定められた事象が検出されることを障害という。
アラーム…障害が検出されたことをオペレータ9等に通知すること、又は、通知そのものをいう。1つの障害で1つのアラームが発報されるが、障害が解決されないと同じ障害に基づいて繰り返しアラームが発報される。このような同じ障害に基づいて発報されるアラームを同じアラームという。あるいは、別途定めた集約条件により集約可能なアラームを同じアラームと称してよい。
担当者8…後述する被監視システム41を構築し、維持し、保守し及び復帰等させる者である。このため、データセンター40に入館したり又は遠隔地からログインしたりしてアラームに対する対応を行う。
オペレータ9…監視システム10を操作する者をいう。オペレータ9が担当者8を兼任する場合がある。
障害…被監視システム41において生じた通常と異なる事象である。本実施形態では予め定められた事象が検出されることを障害という。
アラーム…障害が検出されたことをオペレータ9等に通知すること、又は、通知そのものをいう。1つの障害で1つのアラームが発報されるが、障害が解決されないと同じ障害に基づいて繰り返しアラームが発報される。このような同じ障害に基づいて発報されるアラームを同じアラームという。あるいは、別途定めた集約条件により集約可能なアラームを同じアラームと称してよい。
担当者8…後述する被監視システム41を構築し、維持し、保守し及び復帰等させる者である。このため、データセンター40に入館したり又は遠隔地からログインしたりしてアラームに対する対応を行う。
オペレータ9…監視システム10を操作する者をいう。オペレータ9が担当者8を兼任する場合がある。
<構成例>
図3は、保守サービスシステム200のシステム構成図の一例を示す。保守サービスシステム200では、主に運用管理システム100と各社の被監視システム(例えば、A社被監視システム41a、B社被監視システム41b、C社被監視システム41c)41がネットワークNを介して通信可能に接続される。運用管理システム100は監視システム10及びインシデント管理システム30を有し、顧客である各社の被監視システム41はデータセンター40内に設置されている。なお、被監視システム41はデータセンター40内になくてもよく、被監視システム41の利用者である顧客の社内に被監視システム41が設置されていてもよい。このような設置形式をオンプレミスという。また、運用管理システム100がデータセンター40内に設置されていてもよい。したがって、図3に図示する構成は一例である。
図3は、保守サービスシステム200のシステム構成図の一例を示す。保守サービスシステム200では、主に運用管理システム100と各社の被監視システム(例えば、A社被監視システム41a、B社被監視システム41b、C社被監視システム41c)41がネットワークNを介して通信可能に接続される。運用管理システム100は監視システム10及びインシデント管理システム30を有し、顧客である各社の被監視システム41はデータセンター40内に設置されている。なお、被監視システム41はデータセンター40内になくてもよく、被監視システム41の利用者である顧客の社内に被監視システム41が設置されていてもよい。このような設置形式をオンプレミスという。また、運用管理システム100がデータセンター40内に設置されていてもよい。したがって、図3に図示する構成は一例である。
データセンター40は、サーバ、ルータ、スイッチ及びハブなどのIT機器を効率的に稼動させるための設備が整えられた施設をいう。例えば、IT機器に供給される十分な電力が確保されており、冗長化された通信回線が配備されている。また、年間を通して温度や湿度もほぼ一定になるように制御され、IT機器の温度の上昇が抑制されている。 さらに災害時など、電力の供給が完全に止まってしまっても、自家発電装置やUPS(無停電電源装置)により、一定時間は継続的に稼動できるようになっている。
データセンター40には、サーバやネットワークを顧客に開放するホスティングサービスと顧客が所有するサーバなどの機器をデータセンター40に預けるハウジングサービスがある。本実施形態の運用管理システム100はどちらのサービス形態にも対応できる。すなわち、サーバなどの機器の所有権の所在は問われない。また、サーバは仮想サーバでもよく、クラウドサービスが提供される場合もある。
データセンター40には、各社の被監視システム41が設置されている。各社の被監視システム41は、データセンター40の顧客の企業が利用する社内の業務用のシステム、又は、顧客が外部にWebサイトなどで提供するシステムなどである。各社の被監視システム41は、運用管理システム100により監視される。具体的には、被監視システム41は1つ以上のサーバ、及び、周辺装置(例えばNAS(Network Attached Storage)など)である。各被監視システム41はそれぞれラック内に隔離して設置される。このため、被監視システム41の担当者8は、原則的に自社の被監視システム41のみしかメンテナンスできない(データセンター40の技術者(SE)は複数社のシステムをメンテナンスする場合がある)。
また、データセンター40にはセンサー42が設置されている。センサー42は例えばラックの開閉を検出する開閉センサー、ラックの温度を検出する温度センサー、ラックの振動を検出する震動センサー、煙などを検出する火災センサー、水の侵入を検出する浸水センサー等である。
各センサー42が検出した検出データはセンサー情報管理装置43が取得して運用管理システム100に送信する。センサー情報管理装置43はセンサー42が検出した検出データを被監視システム41と対応付けて監視システム10に送信する。監視システム10は、センサー42の検出データにより被監視システム41の環境を記録したり監視したりすることができる。
運用管理システム100はデータセンター40における被監視システム41の各種の監視サービスやセキュリティーサービスを提供する。監視サービスとは障害の発生を検出して顧客に通知するなどのサービスをいい、セキュリティーサービスはマルウェアの侵入の排除などを行うサービスをいう。
監視システム10は上記した監視サービスやセキュリティーサービスを提供する。監視サービスのため、監視システム10は、例えば、機器のPING疎通、サーバのサービス稼動状況、サーバや周辺装置のリソース等の監視などを行う。また、随時、ウィルスの検出、侵入検知又は攻撃検知などを行っている。
各社の被監視システム41において何らかの障害が検出された場合、監視システム10は障害発生を意味するアラームを発生させる(発報)する。なお、アラームの発報には、無人監視と有人監視がある。無人監視では障害発生時の状況をデータマイニングなどでフィルタリングして、通知の必要性が高いアラームのみが顧客の担当者8のPC(Personal Computer)等に通知される。有人監視では、運用管理システム100のオペレータ9がアラームにより障害発生を把握すると対応方法に基づいて必要であると判断した場合に顧客の担当者に電話や電子メールなどで通知する。本実施形態では主に有人監視を例にして説明するが、無人監視に適用されてもよいし、両方が適用されていてもよい。
また、監視システム10から顧客の担当者へのアラームの通知方法にはいくつかの手段がある。例えば、有人監視の場合はオペレータ9による電話連絡でもよいし、電子メールによる通知でもよい。無人監視の場合も、電子メールによる通知又は自動音声を用いた電話連絡がある。有人監視と無人監視のいずれの場合もFAXで通知してもよい。
インシデント管理システム30は、障害が発生した場合に、障害の内容、対応結果等が記録されるシステムである。障害が発生するとオペレータ9は、顧客にいつどのように連絡したかという対応方法、障害が解決したかどうかなどの対応結果をインシデント管理システム30に入力する。したがって、インシデント管理システム30は過去の障害のデータベースとして活用され、類似した障害が発生した際にオペレータ9が過去の対応方法などを参照することができる。
<ハードウェア構成例>
図4は、監視システム10のハードウェア構成図の一例である。監視システム10は、バス310に接続されたCPU301、ROM302、RAM303、HDD(Hard Disk Drive)305、ディスプレイ308、ネットワークI/F309、キーボード311、マウス312、メディアドライブ307、及び、光学ドライブ314を有する。CPU301は、HD304に記憶されている監視プログラムを実行して、監視システム10全体の動作を制御する。ROM302はIPL(Initial Program Loader)等のCPU301の駆動に用いられるプログラムを記憶している。RAM303はCPU301のワークエリアとして使用される。HD304は不揮発性メモリを搭載した記憶装置であり、監視プログラム、OS(Operating System)等を記憶している。
図4は、監視システム10のハードウェア構成図の一例である。監視システム10は、バス310に接続されたCPU301、ROM302、RAM303、HDD(Hard Disk Drive)305、ディスプレイ308、ネットワークI/F309、キーボード311、マウス312、メディアドライブ307、及び、光学ドライブ314を有する。CPU301は、HD304に記憶されている監視プログラムを実行して、監視システム10全体の動作を制御する。ROM302はIPL(Initial Program Loader)等のCPU301の駆動に用いられるプログラムを記憶している。RAM303はCPU301のワークエリアとして使用される。HD304は不揮発性メモリを搭載した記憶装置であり、監視プログラム、OS(Operating System)等を記憶している。
HDD305はCPU301の制御にしたがってHD304に対する各種データの読み出し又は書き込みを制御する。ディスプレイ308はカーソル、メニュー、ウィンドウ、文字、又は画像などの各種情報を表示する。ネットワークI/F309はLANやインターネットなどのネットワークNとのインタフェースであり、ネットワークNを介した通信を行う。キーボード311及びマウス312は入出力装置であり、キーボード311は文字、数値、各種指示などの入力のための複数のキーを備えこれらからの入力を受け付ける。マウス312はマウスポインターの移動及び各種指示の選択や実行、処理対象の選択などを受け付ける。
メディアドライブ307はフラッシュメモリ等のメディア306に対するデータの読み出し又は書き込み(記憶)を制御する。光学ドライブ314は着脱可能な記録媒体の一例としてのCD−ROM(Compact Disc Read Only Memory)313等に対する各種データの読み出し又は書き込みを制御する。
なお、上記監視プログラムは、インストール可能な形式又は実行可能な形式のファイルで、メディア306やCD−ROM313等のコンピュータで読み取り可能な記録媒体に記録して流通させるようにしてもよい。あるいは、監視プログラムは、任意のサーバ型の情報処理装置からダウンロードされる形態で配布されてもよい。
なお、監視システム10は、クラウドコンピューティングにより構築されていてもよい。クラウドコンピューティングでは、監視システム10の機能が搭載される情報処理装置が固定されていたり1つの筐体内に設置されていたりする必要はなく、物理的な構造は変動しうる。したがって、図示する監視システム10のハードウェア構成は、監視システム10が備えていることが好ましいハード的な要素を示す。
また、インシデント管理システム30及び各社の被監視システム41のハードウェア構成は図4と同様であるか、差異があっても本実施形態の説明には支障がないものとする。しかしながら、インシデント管理システム30のHD304にはインシデント管理システム30のためのプログラムが記憶されている。
<保守サービスシステムの機能について>
続いて、図5を用いて保守サービスシステム200の各機能について説明する。図5は、保守サービスシステム200の機能ブロック図の一例を示す。なお、被監視システム41は本実施形態では監視対象であるので、その機能は被監視システム41によって異なる。
続いて、図5を用いて保守サービスシステム200の各機能について説明する。図5は、保守サービスシステム200の機能ブロック図の一例を示す。なお、被監視システム41は本実施形態では監視対象であるので、その機能は被監視システム41によって異なる。
≪監視システム≫
監視システム10は、送受信部11、監視部12、アラーム判定部13、アラーム情報生成部14、操作受付部15、画面表示制御部16、再発監視部22、検索要求部23、発生頻度監視部24、及び、記憶・読出部19を有する。これらの各機能は図4に示したCPU301が監視プログラムを実行して図4の各種のハードウェアと協働することで実現される機能又は手段である。これらの機能の一部又は全てがICなどのハードウェア回路により実現されてもよい。
監視システム10は、送受信部11、監視部12、アラーム判定部13、アラーム情報生成部14、操作受付部15、画面表示制御部16、再発監視部22、検索要求部23、発生頻度監視部24、及び、記憶・読出部19を有する。これらの各機能は図4に示したCPU301が監視プログラムを実行して図4の各種のハードウェアと協働することで実現される機能又は手段である。これらの機能の一部又は全てがICなどのハードウェア回路により実現されてもよい。
また、監視システム10は、図4に示したHD304又はRAM303により実現される記憶部1000を有している。記憶部1000には、顧客情報DB1001、アラーム発報対象DB1002、対応方法DB1003、アラーム情報DB1004、顧客作業情報DB1005、及び、監視プログラム1010が構築されている。以下、これら各データベースについて説明する。
記憶部1000には、表1に示されているような顧客情報によって構成されている顧客情報DB1001が構築されている。顧客情報には、顧客ID、顧客名、サーバID、及び、担当者情報が対応づけて登録されている。顧客IDは、データセンター40の顧客を一意に識別するための識別情報である。識別情報とは、複数の対象からある特定の対象を一意的に区別するために用いられる名称、符号、文字列、数値又はこれらの組み合わせをいう。以下の識別情報においても同様である。顧客IDは顧客に固有の情報なので顧客固有情報と称してもよい。
顧客名は顧客の通称名である。サーバIDは、各顧客がデータセンター40内に保有するサーバを一意に識別するための識別情報である。サーバIDはサーバに固有の情報なのでサーバ固有情報と称してもよい。また、サーバIDに代えて又はサーバIDと共にホスト名が登録されていてもよい。
担当者情報は、各顧客の担当者8と連絡先などを含む。担当者情報は、一例としてサーバごとに構築されており、担当者情報には、担当者ID、氏名、TEL、及び、E−Mailアドレス(電子メールアドレス)が対応づけて登録されている。担当者IDは担当者8を一意に識別するための識別情報である。氏名は、担当者8の名称であるが戸籍上の氏名でもニックネームでもよい。TELはオペレータ9が担当者8に電話するための電話番号である。例えば、担当者8の携帯電話やスマートフォンの電話番号、担当者8の会社のデスクの電話番号、又は、自宅の電話番号である。E-Mailアドレスはオペレータ9が担当者8に電子メールを送信するためのアドレス情報である。電話番号が宛先になるいわゆるショートメッセージサービスで送信してもよい。
なお、監視システム10は担当者情報を顧客ごとに作成してもよい。また、顧客の住所、代表者氏名、締め日などの情報は、別のデータベースに登録されている。
記憶部1000には、表2に示されているようなアラーム発報対象情報によって構成されているアラーム発報対象DB1002が構築されている。アラーム発報対象情報には、アラーム番号に対応づけて、監視システム10がアラームを発報する障害、発報条件及び重要度が登録されている。アラーム発報対象情報には、アラームの基本的な発報対象として予め設定されている障害と(ARM001〜003)、顧客が任意に設定できる障害(ARM004,005)とがある。
例えば、アラーム番号がARM001の障害は「PING応答なし」である。これは、監視システム10からのPINGコマンドに対しサーバ等が応答しない障害を意味する。アラーム番号がARM002の障害は「プログラム異常終了」である。これは、プログラムが想定されないタイミングで終了した障害を意味する。アラーム番号がARM003の障害は「温度異常」である。これは、センサー42が検出する被監視システム41のラックの温度が閾値を超えて上昇した障害を意味する。
アラーム番号がARM004、005の障害は顧客がPC等を使用して定義できる(オペレータ9が顧客の要望を聞いてアラーム発報対象DB1002に登録してもよい。)。例えば、CPU使用率とアラーム発報の閾値、HDD空き容量とアラーム発報の閾値などを顧客は登録できる。さらに、例えばCPU使用率の単位時間の上昇率、CPU温度の上昇率など、監視情報の値の微分値や2回微分値をアラーム発報対象情報に用いてもよい。また、複数の監視情報の組み合わせをアラーム発報対象情報に用いてもよい。
したがって、オペレータ9及び顧客はアラーム番号によって障害の内容を把握できる。なお、顧客がアラームを発報する障害を定義しなければ、アラーム発報対象情報は顧客ごとに共通である。このように、アラームが発報される障害は顧客ごとに異なっていても、そうでなくてもよい。表2に記載されたアラーム発報対象情報はあくまで一例であり、この他にも多くの障害(アラームが発報される事象)が存在しうる。
各障害はおよその重要度が予め登録されている。したがって、監視システム10は1つのアラームから少なくとも障害の重要度を決定できる。監視システム10は、例えば同じサーバIDについて異なるアラーム番号のアラームが発報された場合、同じアラーム番号のアラームだけが発報されるよりも重要度を大きくすることができる。例えば、単純に重要度を加えたり、乗じたり、最も大きな重要度を定数倍することなどが考えられる。
記憶部1000には、表3に示されているような対応方法によって構成されている対応方法DB1003が構築されている。対応方法は、アラームの発生時にオペレータ9が取り得るべき具体的な処置である。対応方法は、サーバIDとアラーム番号に対応付けられている。例えば、サーバIDがS001の場合で、アラーム番号がARM001であれば「佐藤さんに電話」することが対応方法となる。このように対応方法DB1003には、サーバIDとアラーム番号に対応付けてオペレータ9が取り得るべき具体的な対応方法が登録されている。
顧客はPC等を使用して障害(アラーム番号)に応じて任意の対応方法を登録できる。あるいは、オペレータ9が顧客の要望を聞いて対応方法DB1003に登録してもよい。障害の内容(例えば、ソフト系とハード系の違い、重要度など)によって担当者8や連絡方法が異なっていたりする場合がある。本実施形態では表3のような対応方法DB1003を備えることで、サーバIDとアラーム番号に応じてオペレータ9が適切な処置を取ることができる。
また、後述するように本実施形態では複数のアラーム情報が集約されるが、監視システム10がアラームを集約して表示する場合、対応方法の一部又は全部が同じアラームを1つに集約することができる。
なお、電話や電子メールの他、Twitter(登録商標)、Facebook(登録商標)、Line(登録商標)などのSNS(Social Network System)の通知先が登録されていてもよい。
記憶部1000には、表4に示されているようなアラーム情報によって構成されているアラーム情報DB1004が構築されている。アラーム情報は、アラームを発報させた障害の内容がまとめられたレコードである。アラーム情報は障害が検出されるごとに生成される。したがって、障害の原因が同じでも解決されるまでに複数の同じアラーム情報が生成されうる。なお、アラーム情報の具体例は図7等で説明される。
アラーム情報は、通番、顧客ID、顧客名、発生日時、サーバID、アラーム番号、対応方法、及び、拡張部を有している。通番とは、アラーム情報に付される重複しない連続した番号である。顧客ID、顧客名、サーバIDは顧客情報DB1001と同じものである。発生日時は、アラームが発報された日時である(障害が検出された日時と称してもよい)。アラーム番号はアラーム発報対象情報と同じものである。対応方法には、対応方法DB1003から抽出されたサーバIDとアラーム番号に対応した対応方法、及び、顧客情報DB1001から抽出された顧客の連絡先(TELやE−Mail)が設定される。
拡張部は、本実施形態の監視システム10の主に画面制御に使用される付加的な情報である。拡張部は集約された複数のアラーム情報について共通の情報となる。拡張部は、集約番号、経過時間、件数、集約フラグ、表示色フラグ、過去事例フラグ、分割フラグ、再発フラグ、及び、対応完了を有している。集約番号は集約条件を満たした複数のアラーム情報が集約された場合に、集約された各アラーム情報に共通に付与される識別情報である。すなわち、1つに集約された複数のアラーム情報には同じ集約番号が付与される。経過時間は同じ障害に起因する最初のアラームが発報されてからの時間である。件数は同じ障害に起因するアラーム情報の数である。集約フラグは集約条件を満たす場合にON,満たさない場合にOFFが設定されるフラグである。表示色フラグは集約されたアラーム情報が色分けして表示されるか否か、及び、色分けされている場合の色を示すフラグである。過去事例フラグは過去に対応が完了しているインシデントデータと類似するアラーム情報である場合にONとなり、そうでない場合にOFFとなるフラグである。分割フラグは画面の分割条件を満たした場合にONとなり満たさない場合にOFFとなるフラグである。再発フラグは対応が完了した障害について再度、アラームが発報された場合にONとなり、再発でない場合にOFFとなるフラグである。再発フラグと過去事例フラグはタイムスケールが異なり、再発フラグは例えば1時間程度以内に同じアラームが発報された場合にONとなる。過去事例フラグは例えば1時間以上前に発生してインシデントデータと類似した障害が発生した場合にONとなる。対応完了は、後述する所定時間T2が経過するか又はオペレータ9が対応方法DB1003の対応方法にしたがって対応したことが登録される。
記憶部1000には、表5に示されているような顧客作業情報によって構成されている顧客作業情報DB1005が構築されている。顧客作業情報は、顧客が作業する予定が登録された情報である。顧客作業情報は、顧客ID、サーバID、担当者ID、作業日時、及び、備考を有している。顧客ID、サーバID、担当者IDは顧客情報DB1001と同じものである。作業日時は、顧客の担当者8が作業する日時である。備考には、例えば作業内容が登録される。したがって、監視システム10は、顧客作業情報を参照することで、どの顧客のどのサーバに対し誰がいつ作業するかを抽出することができる。なお、顧客作業情報は、顧客の担当者8がPC等を使用して顧客作業情報DB1005に登録しておいてもよいし、オペレータ9が顧客の要望を聞いて顧客作業情報DB1005に登録してもよい。
(監視システム10の機能について)
次に、監視システム10が有する機能又は手段について説明する。送受信部11は、図4に示されているCPU301からの命令、及びネットワークI/F309等によって実現され、ネットワークNを介してインシデント管理システム30や被監視システム41等と各種データの送受信を行う。なお、以下では監視システム10がデータを送受信する場合でも「送受信部11を介して」という記載を省略する場合がある。
次に、監視システム10が有する機能又は手段について説明する。送受信部11は、図4に示されているCPU301からの命令、及びネットワークI/F309等によって実現され、ネットワークNを介してインシデント管理システム30や被監視システム41等と各種データの送受信を行う。なお、以下では監視システム10がデータを送受信する場合でも「送受信部11を介して」という記載を省略する場合がある。
監視部12は、図4に示されているCPU301からの命令等によって実現され、被監視システム41を監視する。具体的には、定期的に被監視システム41に問い合わせて監視に必要な情報を取得する。監視に必要な情報は、サーバIDなど障害が発生した被監視システム41を特定するための情報とアラームの発報条件を満たすかどうかを判定するための情報である。具体的には、監視部12はアラーム発報対象情報に設定されている障害を検出するため、PING応答、プログラム異常情報、及び、温度異常などを監視する。すなわち、定期的に被監視システム41に対しPINGコマンドを送信し応答時間を取得する。また、被監視システム41のプログラムが異常終了した場合に残すログを被監視システム41から取得する。また、温度センサーとしてのセンサー42が検出した温度を取得する。監視部12はこれらの監視結果を随時、アラーム判定部13に送出する。なお、監視部12はSNMP(Simple Network Management Protocol)マネージャの機能を有していてもよい。この場合、被監視システム41はSNMPエージェントの機能を有する。
アラーム判定部13は、図4に示されているCPU301からの命令等によって実現され、監視部12による監視結果がアラームの発報条件を満たすか否かを判定し、満たす場合にアラームを発報する。アラーム判定部13は、アラーム発報対象DB1002から障害と発報条件を読み出し、アラームの発報対象を満たす監視結果があるか否かを判定する。例えば、監視部12から取得した監視結果に基づいて、PINGコマンドへの応答時間が閾値(表3の○○ミリ秒)を超えないかなどを判定する。また、被監視システム41のプログラムが異常終了した場合に残すログにプログラム異常終了の有無が記録されているか否かを判定する。また、ラックの周囲の温度が基準(T度)より高くなっていないかを判定する。アラーム判定部13はアラームを発報すべきであると判定すると発報条件を満たすアラーム番号を読み出し、アラーム情報生成部14に通知する。
アラーム情報生成部14は、図4に示されているCPU301からの命令等によって実現され、アラーム情報を生成する。アラーム情報生成部14は、まず、アラーム情報DB1004で最も新しいアラーム情報の通番より1つ大きい通番を採番する。そして、監視部12が取得したサーバIDに基づいて顧客情報DB1001から顧客IDと顧客名を読み出す。これにより、拡張部を除いてアラーム情報を生成できる。拡張部の生成方法については後述する。
操作受付部15は、図4に示されているCPU301からの命令、キーボード311及びマウス312等によって実現され、オペレータ9の各種の操作を受け付ける。
画面表示制御部16は、図4に示されているCPU301からの命令及びディスプレイ308等によって実現され、ディスプレイ308にアラーム情報が表示される画面を作成し表示する。この画面については図7などで説明される。
画面表示制御部16は、さらに、画面分割部17、スクロール制御部18及びアラーム情報集約部21を有している。画面分割部17は分割フラグがONになるとアラーム情報が表示される画面を分割して新しい分割領域を生成したり、ポップアップウィンドウを表示したりする。スクロール制御部18はアラーム情報のスクロール速度を一定以下に制御する。アラーム情報集約部21は、集約フラグがONの場合に複数のアラーム情報を集約する。集約条件については後述するが、例えば、サーバ名、アラーム番号又は対応方法の1つ以上が一致するアラーム情報を集約する。あるいは、アラーム情報の類似度を判定して集約してもよい。
再発監視部22は、図4に示されているCPU301からの命令等により実現され、対応が完了した障害に関するアラームが再発したかどうかを監視する。
検索要求部23は、図4に示されているCPU301からの命令等により実現され、インシデント管理システム30にアラーム情報を送信して類似するインシデントデータの検索を要求する。
発生頻度監視部24は、図4に示されているCPU301からの命令等により実現され、アラームの発生頻度の急な変化を検出する。
記憶・読出部19は、図4に示されているCPU301からの命令、及びHDD305等によって実現され、記憶部1000に各種データを記憶したり、記憶部1000に記憶された各種データを読み出したりする処理を行う。なお、以下では監視システム10が記憶部1000にアクセスする場合でも「記憶・読出部19を介して」という記載を省略する場合がある。
≪インシデント管理システム30≫
インシデント管理システム30は、送受信部31、データ検索部32、及び、記憶・読出部39を有する。これらの各機能は図4に示したCPU301が監視プログラムを実行して図4の各種のハードウェアと協働することで実現される機能又は手段である。これらの機能の一部又は全てがICなどのハードウェア回路により実現されてもよい。
インシデント管理システム30は、送受信部31、データ検索部32、及び、記憶・読出部39を有する。これらの各機能は図4に示したCPU301が監視プログラムを実行して図4の各種のハードウェアと協働することで実現される機能又は手段である。これらの機能の一部又は全てがICなどのハードウェア回路により実現されてもよい。
また、インシデント管理システム30は、図4に示したHD304又はRAM303により実現される記憶部3000を有している。記憶部3000には、インシデントデータDB3001及びインシデント管理プログラム3010が構築されている。以下、これら各データベースについて説明する。
記憶部3000には、表6に示されているようなインシデントデータによって構成されているインシデントデータDB3001が構築されている。インシデントデータには、インシデント番号、顧客ID、サーバID、アラーム番号、発生日時、対応方法、及び、対応結果が対応づけて登録されている。
インシデント番号は、オペレータ9が対応した障害を区別するための識別情報である。同じ被監視システム41から同じ障害に起因するアラームが何度も発報される場合があるが、この場合、オペレータ9は1つのインシデントとして扱うことができる。インシデント番号は重複しないように付与される。顧客ID、サーバID、アラーム番号は上記の通りである。発生日時はアラームが発報された日時である。同じサーバから同じ障害に起因する複数のアラームが発報された場合は、最初のアラームが発報された日時である。対応方法は、オペレータ9が取った実際の対応である。対応方法には、「山田さんに電話」のような単なる連絡先と連絡方法が登録される。さらに、どのようにして障害が解決されたのかが登録されることが好ましい。対応結果には、対応(少なくとも担当者により障害を復旧させた「障害対応」とオペレータによる担当者への連絡などの一次対応の2つがある)による障害への対応内容が登録される。
集約されたアラーム情報はオペレータ9が対応すべきアラーム情報であると考えられるので、アラーム情報が集約されると同じ複数のアラーム情報のうち最初のアラーム情報がインシデントデータDB3001に自動的に登録される。したがって、オペレータ9は対応方法と対応結果を登録すればよい。集約されないアラーム情報の場合、オペレータ9が対応したアラーム情報だけをインシデントデータDB3001に登録すればよい。なお、集約されたアラーム情報の場合もオペレータ9が手動でアラーム情報をインシデントデータDB3001に登録してよい。
インシデントデータDB3001には、アラーム番号、対応方法、及び、対応結果が登録されるので、オペレータ9は過去の事例として活用することができる。
(インシデント管理システムの機能について)
次に、インシデント管理システム30が有する機能又は手段について説明する。送受信部31は、図4に示されているCPU301からの命令、及びネットワークI/F309等によって実現され、ネットワークNを介して監視システム10等と各種データの送受信を行う。
次に、インシデント管理システム30が有する機能又は手段について説明する。送受信部31は、図4に示されているCPU301からの命令、及びネットワークI/F309等によって実現され、ネットワークNを介して監視システム10等と各種データの送受信を行う。
データ検索部32は、図4に示されているCPU301からの命令等によって実現され、監視システム10から要求された検索条件(アラーム情報の項目)でインシデントデータDB3001を検索する。検索結果は監視システム10に送信される。
記憶・読出部39は、図4に示されているCPU301からの命令、及びHDD305等によって実現され、記憶部3000に各種データを記憶したり、記憶部3000に記憶された各種データを読み出したりする処理を行う。
<動作手順>
まず、図6を用いて監視システム10の全体的な動作手順を説明する。図6は、監視システム10がアラーム情報を表示する画面の表示制御の手順を示すフローチャート図の一例である。図6の処理は例えばアラームが発報されるとスタートする。
まず、図6を用いて監視システム10の全体的な動作手順を説明する。図6は、監視システム10がアラーム情報を表示する画面の表示制御の手順を示すフローチャート図の一例である。図6の処理は例えばアラームが発報されるとスタートする。
画面表示制御部16はアラームが新規であるか否かを判定する(S10)。アラームが新規であるとは、過去の所定期間において同じアラームが発報されていないことをいう。例えば集約条件が「サーバIDが同じであること」であれば、過去の所定期間において同じサーバIDのアラームが発報されていないことをいう。したがって、同じアラームとは、集約条件に適合するアラーム情報が生成されるアラームをいう。集約条件に適合するアラーム情報が生成される複数のアラームを単に「同じアラーム」という。また、同じアラームに基づいて生成されるアラーム情報を「同じアラーム情報」という。アラームが同じかどうかの判断は分割条件と集約条件とで異なる場合が多いが、同じであってもよい。
過去の所定期間は、最後に検出された障害に基づくアラームと関係がないと推定される程度の時間であり、例えば数時間程度であるがこれに限られるものではない。顧客やオペレータ9、担当者8等はこの過去の所定時間の設定できる。
ステップS10の判定がNoの場合、処理はステップS32に進む。これにより、新規のアラームでない場合はステップS20、S30をスキップできる。
ステップS10の判定がYesの場合、画面表示制御部16は経過時間の測定を開始する(S20)。この経過時間は、文字色の変更や画面分割の終了の判定に使用される。また、アラーム情報生成部14はアラーム情報の拡張部の経過時間に、ここで測定を開始した経過時間を設定する。時間は変化するものであるため、例えば1分ごとに拡張部の経過時間を更新する。
次に、画面表示制御部16は件数の測定を開始する(S30)。この件数とは、同じアラームの数である。ステップS10でNoと判定されたアラームは件数のカウント対象となる。また、アラーム情報生成部14はアラーム情報の拡張部の件数に、ここで測定を開始した件数を設定する。例えば件数が増えるごとに拡張部の件数を更新する。
次に、監視システム10は過去事例の有無を判定する(S32)。過去事例の有無の判定とは、過去に類似のアラームが発生されているか否かを判定することをいう。具体的には検索要求部23はインシデント管理システム30にアラーム情報を送信して類似するアラーム情報の有無を問い合わせる。類似するかどうかは、集約条件に基づいて判定されてもよいし異なっていてもよい。異なっている場合、例えば別の顧客のインシデントデータを検索できる。
アラーム情報と類似するインシデントデータがある場合、インシデント管理システム30は類似するインシデントデータを監視システム10に送信する。これにより、アラーム情報生成部は過去事例フラグをONに設定する。なお、類似するインシデントデータがあるアラーム情報は過去事例フラグのONによりその旨が自動的に画面に表示される。また、オペレータの操作によりインシデントデータが表示されてもよい。インシデントデータの表示例については図19にて説明することにする。
次に、監視システム10は同じ障害が再発した場合の処理を行う(S34)。すなわち、再発監視部22はアラーム情報DB1004をアラーム情報で検索して障害が再発したか否かを判定する。詳細は図14にて説明される。
次に、画面表示制御部16は新規のアラームが発報されてから所定時間T1が経過したか否かを判定する(S40)。所定時間T1は大量のアラームが発報されるかどうかを予想するための時間である。この所定時間T1に多くのアラームが発報される場合は以降も大量のアラームが発報されると予想される。所定時間T1は例えば数十秒〜数分であるものとして説明するが、これには限られない。また、オペレータ9や担当者8が任意の所定時間T1を設定してもよい。
ステップS40の判定がYesの場合、処理はステップS20に戻る。これにより所定時間T1が経過したアラームは集約せず、新規アラームとして取り扱うことができる。
ステップS40の判定がNoの場合、所定時間T1が経過していないので、同じアラームの件数をカウントしたり(S52)、経過時間の測定を継続したりする。
次に、アラーム情報生成部14はアラーム情報の件数が1より多いか否かを判定する(S60)。この"1"は複数の同じアラーム情報を集約するか否かを判定するための閾値である。この閾値はオペレータ9が適宜設定でき"1"に限られない。
ステップS60の判定がYesの場合、アラーム情報生成部14はアラーム情報の拡張部の集約フラグをONに設定する(S70)。したがって、所定時間T1で収集された複数のアラームの件数が1より多い場合、アラーム情報が集約される。
次に、アラーム情報生成部14は同じアラーム情報の件数が30より多いか否かを判定する(S80)。この"30"は1つの画面に表示可能なアラーム情報が想定された閾値である。換言すると画面を分割した方が見やすいと考えられる同じアラームに基づくアラーム情報の数である。この閾値はオペレータ9が適宜設定でき"30"に限られない。
ステップS80の判定がYesの場合、アラーム情報生成部14はアラーム情報の拡張部の分割フラグをONに設定する(S90)。
なお、同じアラームから生成されたアラーム情報の拡張部は共通になる(同じ情報を有する)ので、ステップS70と90において、アラーム情報生成部14は同じアラームの最初のアラーム情報の拡張部だけ設定してもよいし、全てのアラーム情報の拡張部に設定してもよい。
次に、画面表示制御部16は分割フラグがONか否かを判定する(S100)。分割フラグがONである場合、画面分割部17は後述するように画面を分割する(S110)。分割された画面の一例を図13に示す。これにより、画面には新しく分割領域が生成される。スクロール制御部18は分割で生成された分割領域内で表示されるアラーム情報のスクロール速度を一定以下に制御する。詳細は図12にて説明される。
次に、画面表示制御部16は集約フラグがONか否かを判定する(S120)。集約フラグがONである場合、アラーム情報集約部21は同じアラームから生成された複数のアラーム情報を集約する(S130)。集約の例を図7にて説明する。なお、アラーム情報生成部14は集約番号を付与して、アラーム情報の拡張部に設定する。また、ステップS130の集約よりも後にステップS110の画面の分割が行われてもよい。
次に、画面表示制御部16はアラーム情報の表示色を制御する(S140)。表示色の制御とは、集約されたアラーム情報の色をアラームが発報されてからの時間、集約の件数、又は、重要度等によって変更することをいう。表示色は、表示色フラグにより制御される。詳細は図8,9にて説明される。
次に、発生頻度監視部24は、障害の発生頻度の変化処理を行う(S142)。発生頻度の変化処理は、発生頻度が急に変化したことを検出して、その旨を表示する処理である。詳細は図16にて説明される。
次に、画面表示制御部16は、同じアラームの最初の発報から所定時間T2が経過したか、又は、オペレータ9の対応が完了したか否かを判定する(S150)。これにより、画面の分割、及び、集約されたアラーム情報の表示色の制御を解除するか否かが判定される。所定時間T2が経過したか、対応完了かによって若干、処理が異なっている。対応完了の場合、分割により生成された分割領域は、消去される。分割領域が多くなりすぎてオペレータ9にとって画面が見にくくなることを抑制できる。所定時間T2が経過した場合、分割領域が消去される場合も残される場合もある。
なお、所定時間T2はオペレータ9が障害に対応することができる時間、障害が解決することが想定される時間、又は、障害を解決すべき時間であり予め定められている。所定時間T2は例えば、10分であるがこれに限られるものではなく、顧客や障害内容によって異なっていてもよい。
所定時間T2が経過した場合、アラーム情報生成部14はアラーム情報の拡張部の対応完了に解決した旨を設定する。また、オペレータ9が対応を完了させた場合には、オペレータ9がアラーム情報の拡張部の対応完了に解決した旨を設定する。
ステップS150の判定がNoの場合、処理はステップS100に戻り、ステップS100以下の処理が繰り返し実行される。これにより、同じアラームが発生すれば分割領域に表示され、また、集約して表示される。
ステップS150の判定がYesの場合、画面表示制御部16は分割フラグをOFFに設定する(S160)。集約フラグがONのままなのは、集約された状態でスクロールされてよいためである。
そして、分割フラグがOFFなので、画面分割部17は画面の分割を解除する(S170)。画面の分割を解除するとは、分割領域に表示されていた同じアラーム情報と分割領域を消去することをいう。
また、画面表示制御部16は、表示色の制御を終了する(S180)。すなわち、障害が解決されたと推定されるので集約されたアラーム情報の色を元の色に戻す。ただし、画面の分割が解除されても、切り分け対応が未完で集約状態が残っているのであれば、アラーム情報の色は変更されたままでよい。
以上で、同じアラームに起因した画面の分割(スクロール速度の制御)と集約の処理が完了する。ステップS150の判定で分かるように、所定時間T2が経過することで図6の処理が終わった場合は、再度同じ、アラームが発生する可能性がある。また、オペレータ9が対応したが、再度同じ、アラームが発生する可能性はゼロでない。このような場合は、図14にて後述するように、同じアラームが再発したことが画面に表示される。
<集約処理>
図7は、集約処理を説明する図の一例である。図7(a)はアラーム情報の一例を示す。図7(a)のアラーム情報はアラームが発報されることで時系列に生成されるリアルタイムのアラーム情報である。各項目の内容については表4と重複するため省略する。図7(a)では下から上に、発生した障害から生成されたアラーム情報が順番に表示されている。図7(a)のアラーム情報がディスプレイ308の画面に表示されるが、画面からあふれたアラーム情報は削除されてしまうか、又は、削除されずに欄外表示になり見えなくなる。
図7は、集約処理を説明する図の一例である。図7(a)はアラーム情報の一例を示す。図7(a)のアラーム情報はアラームが発報されることで時系列に生成されるリアルタイムのアラーム情報である。各項目の内容については表4と重複するため省略する。図7(a)では下から上に、発生した障害から生成されたアラーム情報が順番に表示されている。図7(a)のアラーム情報がディスプレイ308の画面に表示されるが、画面からあふれたアラーム情報は削除されてしまうか、又は、削除されずに欄外表示になり見えなくなる。
そこで、アラーム情報集約部21は、集約条件を満たすアラーム情報を集約する。例えば、集約条件が「同一のサーバIDを有するアラーム情報を集約する」である場合、図6にて説明したように、新規のアラームが発生してから所定時間T1以内に1つより多い同じサーバIDを有するアラーム情報が生成されると、アラーム情報集約部21はアラーム情報を集約する。
図7(b)はサーバIDで集約されたアラーム情報の一例を示す。図7(a)でサーバIDがS001のアラーム情報が4つあるが、通番1と4のアラーム情報が所定時間T1以内に生成されたものである場合、集約条件を満たす。また、図6で所定時間T2が経過したか、又は、オペレータ9の対応が完了する前に通番が6と7のアラーム情報が生成されたとする。この場合、4つのアラーム情報が集約される。したがって、図7(b)ではサーバIDがS001のアラーム情報は4つになる。アラーム情報生成部14は集約されるアラーム情報を生成すると拡張部の件数を更新する。図7(b)のサーバIDがS001のアラーム情報では、4件のアラーム情報が集約されていることが分かる。同様に、サーバIDがS002について、2つのアラーム情報が集約されている。なお、サーバIDがS003のアラーム情報は集約の対象とならないが、後述する集約領域に表示される。これは、オペレータが集約領域を見ていれば適切な対応を可能とするためである。2回目のサーバIDがS003のアラーム情報が生成された場合、集約条件を満たさなければ1件だけ表示される。
図7(b)では、通番、顧客名、サーバID、発生時刻、アラーム番号、対応方法、及び、件数しか表示されないが、集約されたアラーム情報は拡張部(例えば集約番号)が同じになるので、集約された図7(b)のアラーム情報と図7(a)のアラーム情報は対応付けられている。したがって、オペレータ9が図7(b)のアラーム情報をマウスで右クリックするなどの操作を行うと、画面表示制御部16は対応付けられているアラーム情報を画面に表示する。すなわち、図7(a)のアラーム情報がやがて画面からあふれてしまっても、画面表示制御部16はアラーム情報DB1004から集約番号で対応付けられているアラーム情報を読み出して図7(b)の画面の横に表示したり重畳させて表示したりする。
また、例えば、集約条件が「同一の対応方法を有するアラーム情報を集約する」である場合、新規のアラームが発生してから所定時間T1以内に1つより多い同じ対応方法を有するアラーム情報が生成されると、アラーム情報集約部21はアラーム情報を集約する。
図7(c)はサーバIDと対応方法で集約されたアラーム情報の一例を示す。ここでは対応方法のうち同じ連絡方法のアラーム情報を同じ対応方法であると判定する。例えば、電話のよる連絡、電子メールによる連絡はそれぞれ同じ対応方法である。図7(a)でサーバIDがS001で対応方法が電話のアラーム情報が3つあるが(佐藤さんに電話)、通番1、4、6のアラーム情報が所定時間T2以内に生成されたものである場合、3つのアラーム情報が集約される。また、サーバIDがS002のアラーム情報についても同様で、対応方法が「Aさんに電話」というアラーム情報が集約される。
したがって、図7(c)では、通番が1、4、6の3つのアラーム情報が1つに集約される(件数が3)。通番が7のアラーム情報は対応方法が電子メールによる送信なので、サーバIDが同じ001でも集約されないが、通番3のアラーム情報と同じ理由で集約領域に表示される。
このような集約は、対応の単位でアラーム情報を集約できるという利点がある。オペレータ9が画面を監視するのは適切なインシデント管理を行うため、すなわち適切な対応を迅速に行うためなので、対応方法が同じアラーム情報が集約されていれば、集約されたアラーム情報に対して1回の対応を行えばよいため対応しやすい。
なお、電話や電子メールという連絡方法を対応方法とするのは一例に過ぎず、電話番号又は電子メールのメールアドレス、で集約してもよい。また、連絡先となる担当者8で集約してもよい。また、対応方法の全体(担当者8と連絡先と連絡方法)で集約してもよい。
また、アラーム情報集約部21は、所定時間T1の経過時にアラーム情報を集約した後に同じアラームが発報されると、所定時間T2が経過するか又は対応完了まで該アラームのアラーム情報も集約する。したがって、同じアラームは次々に集約されるためオペレータ9が対応しやすい。
また、アラーム情報の類似度でアラーム情報を集約してもよい。例えば、顧客名、サーバID、アラーム番号、及び、対応方法のそれぞれの項目で同じアラーム情報があれば、アラーム情報集約部21は項目に応じた点数をアラーム情報に付与する。例えば、顧客名…6、サーバID…10、アラーム番号…4、対応方法…3などのように予め定められた点数を新規のアラーム情報を基準にして時間的に後のアラーム情報に付与する。この点数は類似性が高いと推測される項目ほど高くなっている。アラーム情報集約部21は閾値以上のアラーム情報は同じアラームであると判定し集約する。したがって、各項目別に集約する場合には集約されないアラーム情報を集約できる可能性があり、集約効率を向上させることができる。
また、図7(b)(c)では集約の際、最初のアラーム情報に集約されているが(最初のアラーム情報だけが表示されている)、最後のアラーム情報に集約されてもよい。すなわち、同じアラーム情報が生成されるたびに、最後のアラーム情報のみが表示される。あるいは、最初のアラーム情報と最後のアラーム情報の2つを集約の結果として表示してもよい。
<表示色フラグの処理>
図8は、表示色フラグの制御手順を示すフローチャート図の一例である。図8の処理は例えば1分間に1回など適当な時間間隔をもって繰り返し実行される。表示色フラグの初期値は0であり、1〜3の値を取る。表示色フラグの数が大きくなると集約して表示されたアラーム情報の色が変化する。すなわち、注意喚起性が高い色に変わっていく。
図8は、表示色フラグの制御手順を示すフローチャート図の一例である。図8の処理は例えば1分間に1回など適当な時間間隔をもって繰り返し実行される。表示色フラグの初期値は0であり、1〜3の値を取る。表示色フラグの数が大きくなると集約して表示されたアラーム情報の色が変化する。すなわち、注意喚起性が高い色に変わっていく。
まず、画面表示制御部16は、集約フラグがONであるか否かを判定する(S210)。これは、表示色の制御は集約されたアラーム情報に対し行われるためである。
ステップS210の判定がYesの場合、画面表示制御部16は、集約されたアラーム情報の拡張部を参照して経過時間が30分以上か否かを判定する(S220)。この判定は、経過時間がアラーム情報を注意喚起性が高い色に変えるほどの時間を超えたか否かを判定するためのものである。したがって、30分には限られない。
ステップS220の判定がYesの場合、画面表示制御部16は表示色フラグを"3"に設定する(S230)。
ステップS220の判定がNoの場合、画面表示制御部16は、集約されたアラーム情報の拡張部を参照して経過時間が10分以上か否かを判定する(S240)。この判定は、経過時間がアラーム情報を注意喚起性が中程度の色に変えるほどの時間を超えたか否かを判定するためのものである。したがって、10分には限られない。
ステップS240の判定がYesの場合、画面表示制御部16は表示色フラグを"2"に設定する(S250)。
ステップS240の判定がNoの場合、画面表示制御部16は表示色フラグを"1"に設定する(S260)。
以上のような処理を1分に1回程度行えば、経過時間に応じて表示色フラグが制御される。なお、表示色フラグの制御は画面に表示中の集約されたアラーム情報にだけ行えばよい。
次に、図9を用いて表示色フラグを用いたアラーム情報の表示色の制御について説明する。図9は、画面表示制御部16がアラーム情報の表示色を制御する手順を示すフローチャート図の一例である。図9の処理は図6のフローチャート内で実行される。
画面表示制御部16は、表示色フラグが"1"か否かを判定する(S310)。ステップS310の判定がYesの場合、画面表示制御部16はアラーム情報をYellowで表示する(S320)。
ステップS310の判定がNoの場合、表示色フラグが"2"か否かを判定する(S330)。
ステップS330の判定がYesの場合、画面表示制御部16はアラーム情報をOrangeで表示する(S340)。
ステップS330の判定がNoの場合、表示色フラグが"3"か否かを判定する(S350)。
ステップS350の判定がYesの場合、画面表示制御部16はアラーム情報をRedで表示する(S360)。
ステップS350の判定がNoの場合、画面表示制御部16はアラーム情報の表示色を制御しない。したがって、例えば白黒などの強調性の低い色で表示されたままとなる。
なお、経過時間による変更だけでなく、件数等よって表示色を変更してもよい。例えば、以下のように表示色を変更する。
10件未満:黄色
10件以上:赤色
また、経過時間、件数及び重要度の2つ以上を組み合わせて表示色を変更してもよい。
10件以上:赤色
また、経過時間、件数及び重要度の2つ以上を組み合わせて表示色を変更してもよい。
図10は、表示色が制御されるアラーム情報の一例を示す図である。図10(a)は集約された直後のA社とB社のアラーム情報を示す。経過時間はいずれも10分未満であるため、図10(a)のA社とB社のアラーム情報はYellowで表示されている。C社と通番7のA社のアラーム情報は集約されていないので文字色は通常のままである。なお、実際の画面ではYellowという文字が表示されるのでなく、文字が黄色で表示される。
図10(b)は図10(a)の状態から10分以上経過した状態のアラーム情報を示す。A社とB社のアラーム情報はアラームの発生から10分以上経過しているので、A社とB社のアラーム情報はOrangeで表示されている。これに対し、C社と通番7のA社のアラーム情報は発生から10分が経過していないので、Yellowで表示されている。
図10(c)は図10(b)の状態から20分以上(最初のアラームの発報から30分以上)経過した状態のアラーム情報を示す。新たな集約によりD社のアラーム情報が追加されている。A社とB社のアラーム情報はアラームの発生から30分以上経過しているので、A社とB社のアラーム情報はRedで表示されている。C社と通番7のA社のアラーム情報はアラームの発生から10分以上経過しているのでOrangeで表示されている。D社のアラーム情報は発生から10分が経過していないので、Yellowで表示されている。
このような処理により、アラームの発報からの経過時間に応じてアラーム情報の表示色を変更できる。オペレータ9は表示色によってどのアラーム情報が長時間、解決されていないかを感覚的に把握できる。
表示色の変更には、文字色の変更の他、背景色の変更が含まれる。また、文字を点滅させたり、文字を拡大して表示してもよい。
<画面分割処理>
図11は、画面の分割について説明する図の一例である。図11(a)は図7(a)と同じものであり、アラーム情報がリアルタイムに表示される。したがって、アラームが発報される頻度によってはオペレータ9が確認する前にアラーム情報が画面からあふれてしまう場合がある。そこで、本実施形態の監視システム10は、画面を分割して生成した分割領域に同じアラーム情報を表示し、さらに、スクロール速度を制御する。これにより、アラーム情報があふれる前にオペレータ9が確認しやすくなる。
図11は、画面の分割について説明する図の一例である。図11(a)は図7(a)と同じものであり、アラーム情報がリアルタイムに表示される。したがって、アラームが発報される頻度によってはオペレータ9が確認する前にアラーム情報が画面からあふれてしまう場合がある。そこで、本実施形態の監視システム10は、画面を分割して生成した分割領域に同じアラーム情報を表示し、さらに、スクロール速度を制御する。これにより、アラーム情報があふれる前にオペレータ9が確認しやすくなる。
図6にて説明したように画面の分割条件は件数を除いて集約条件と同じである。分割するかどうかと集約するかどうかで、所定時間T1における同じアラームの件数と比較される閾値が異なっている。この閾値が分割するかどうかと集約するかどうかで同じでもよい。この場合、アラーム情報が集約される場合は画面も分割される。また、分割条件と集約条件が互いに全く独立(互いに異なる)でもよい。
画面分割部17は分割条件を満たす複数のアラーム情報を、画面を分割して生成した分割領域に表示する。例えば、分割条件が「同一のサーバIDを有するアラーム情報」である場合、図6にて説明したように、新規のアラームが発生してから所定時間T1以内に30以上の同じサーバIDを有するアラーム情報が生成されると、画面分割部17は画面を分割してアラーム情報を表示する。
図11(b)はサーバIDが同じため分割して表示されたアラーム情報の一例を示す。図11(a)で説明の便宜上、サーバIDがS001のアラーム情報が4つしかないが、不図示の部分を含めて30以上あれば、図11(b)のアラーム情報が分割領域に表示される。
図11(b)では、図11(a)と同じ項目のアラーム情報が表示されているが、画面分割部17は分割して表示されるアラーム情報の項目を少なくしてもよい。この場合、オペレータ9が図11(b)のアラーム情報(例えば項目の部分)をマウスで右クリックするなどの操作を行うと、画面分割部17は表示されていないアラーム情報の項目を表示する。したがって、限られた画面に発報件数が多いアラームのアラーム情報を、画面を分割して表示しておき、必要に応じて詳細な項目を表示できる。
なお、画面表示制御部16は、所定時間T1の経過時に画面を分割した場合、分割後に同じアラームが発報されると、該アラームのアラーム情報を分割した場面に表示する。したがって、障害の発生頻度が高いと分割された画面からも、オペレータ9が確認する前にアラーム情報があふれてしまうおそれがある。そこで、以下のようにスクロール制御部18が分割領域におけるアラーム情報のスクロール速度を制御する。
図12は、スクロール速度の制御手順を示すフローチャート図の一例である。図12の処理は、図6のフローチャート図の処理により画面が分割された場合に、定期的に実行される。画面の分割により、所定時間T1に発報されたアラームに関するアラーム情報は分割領域に表示されている。
スクロール制御部18は、同じアラームが発報されたか否かを判定する(S410)。同じアラームが発報されない場合、スクロール制御部18は待機する。同じアラームとは分割領域のアラーム情報と同じアラーム情報が生成されるアラームをいう。
ステップS410の判定がYesの場合、スクロール制御部18はタイマーがオーバーフローしたか否かを判定する(S420)。タイマーとはステップS440でセットされるタイマーであり、このタイマーは最後にアラーム情報が追加して表示されてからの時間を測定する。
ステップS420の判定がNoの場合、スクロール制御部18はアラーム情報を表示することなく待機する。
ステップS420の判定がYesの場合、スクロール制御部18は、分割領域に表示されているアラーム情報の全体を1行ずつ下に移動した後、分割領域の最上部に新しいアラーム情報を追加して表示する(S430)。
そして、スクロール制御部18はタイマーをセットする(S440)。これにより、タイマーは再度、時間の測定を開始する。したがって、タイマーのオーバーフロー値が適切に設定されていることで、スクロール速度を制御できる。スクロール速度が制御されることで、数多くのアラーム情報が生成され分割領域に表示されてもオペレータ9が確認する前にあふれてしまうことを抑制できる。また、分割領域に表示されるアラーム情報は同じアラームに関して生成されたアラーム情報なので、オペレータ9が確認しやすいという利点がある。また、分割領域で仮にアラーム情報があふれても、オペレータ9は過去に遡るようにアラーム情報をスクロールさせることで過去のアラーム情報を確認できる。異なるアラーム情報が混在している場合は、他のアラーム情報が次々と生成されるため過去のアラーム情報をスクロールさせると、アラームのリアルタイムの発報状況を確認しにくくなる。これに対し、本実施形態のように分割領域が生成されることで、オペレータ9は他のアラーム情報とは関係なく分割領域のアラーム情報を処理できる。
なお、画面分割部17は同じアラーム情報の数に応じて画面に表示するアラーム情報の表示色を可変にしてもよい。例えば、画面が分割されてからの累計の件数が30〜49で黄色、50以上で赤のように変更する。これにより、オペレータ9はアラームのおよその発報件数が分かるのでアラームの重要度を把握しやすくなる。あるいは、集約されたアラーム情報と同じ表示色に変更してもよい。
また、図12ではスクロール速度を一定以下に制御する例を説明したが、アラーム発報対象情報から読み出された重要度に応じてスクロール速度を変化させてもよい。例えば、重要度が大きいほど早くスクロールさせる、又は、重要度が大きいほど遅くスクロールさせる。早くスクロールさせる場合、画面分割部17は同じアラーム情報を何度も画面に表示させるので(最後のアラーム情報を表示したら最初のアラーム情報から再度、表示する)、オペレータがアラーム情報を補足できないということはない。これにより、集約されたアラーム情報のうち、緊急性の高いものに気づきやすくなる。また、単なる警告表示と異なり、アラームの傾向や個々のアラームについて認識が容易になる。オペレータがスクロール速度を操作により調整してもよい。
なお、スクロール制御部18は分割領域のスクロール速度だけでなく、メイン領域及び集約領域のスクロール速度を制御してもよい。すなわち、分割領域、メイン領域及び集約領域の1つ以上のスクロール速度を同様な処理で制御できる。
<画面例>
図13を用いて、画面の分割やアラーム情報の集約について説明する。図13はアラーム情報が表示されるアラーム表示画面600を示す図である。アラーム表示画面600は、時系列に全てのアラーム情報が表示されるメイン領域601、集約されたアラーム情報が表示される集約領域602、及び、分割により生成された分割領域603を有する。メイン領域601にはリアルタイムに発報され生成されたアラーム情報が上から下に時系列に表示される。集約領域602には図7(b)又は(c)のように集約されたアラーム情報が表示される(図13では図7(c)が表示されている)。分割領域603には分割フラグがONのアラーム情報が、同じ集約番号ごとに表示される。
図13を用いて、画面の分割やアラーム情報の集約について説明する。図13はアラーム情報が表示されるアラーム表示画面600を示す図である。アラーム表示画面600は、時系列に全てのアラーム情報が表示されるメイン領域601、集約されたアラーム情報が表示される集約領域602、及び、分割により生成された分割領域603を有する。メイン領域601にはリアルタイムに発報され生成されたアラーム情報が上から下に時系列に表示される。集約領域602には図7(b)又は(c)のように集約されたアラーム情報が表示される(図13では図7(c)が表示されている)。分割領域603には分割フラグがONのアラーム情報が、同じ集約番号ごとに表示される。
各領域はウィンドウ形式なのでオペレータが各領域の場所を任意に変更できる。また、表示されるアラーム情報の項目をオペレータが取捨することもできる。
図13の表示形式は一例に過ぎず、オペレータがタブを切り替えることで3つの領域のいずれかが画面を占有して表示されてもよい。この他、アラーム表示画面600は図示される形式には限定されない。
また、メイン領域601、集約領域602、及び、分割領域603は同じディスプレイに表示される場合も異なるディスプレイに表示される場合もある。
<<同じ障害の再発>>
図6のステップS34にて説明したように、集約されたアラーム情報や分割して表示されたアラーム情報は、障害の発生から所定時間T2が経過するか又は対応完了により、分割が解除される。
図6のステップS34にて説明したように、集約されたアラーム情報や分割して表示されたアラーム情報は、障害の発生から所定時間T2が経過するか又は対応完了により、分割が解除される。
しかし、切り分け対応済みのアラーム情報と同じアラームが再度、現れる場合が生じうる。これは、所定時間T2が経過したがオペレータ9や顧客の担当者8が何ら対応しなかった場合や、対応完了がアラーム情報に登録されたが、同じアラームが再度発報された場合に生じる。この場合、すでに所定時間T2が経過しているか、又は、対応が困難な障害が発生した可能性があるため、早急な対応が必要である。
そこで、アラーム情報集約部21は、集約されたアラーム情報及び過去に発生したアラーム情報等を用いて、同じアラームが再度、発報されたことをオペレータ9に知らせる。
図14は、同じ障害に基づくアラームが再度、発報されたことを監視システム10が画面に表示する手順を示すフローチャート図の一例である。図14の処理は図6のステップS32で実行される。
アラームが発報されると監視システム10は、近い過去に発生し、対応されたアラームが再発したか否かを判定する(S610)。まず、再発監視部22はアラーム情報DB1004から過去のアラーム情報のうち、拡張部の対応完了に対処が完了した旨が登録されているアラーム情報を読み出す。どのくらい過去まで読み出すかは再発したと判定される程度の期間でよい。例えば、1時間程度であるがこれには限れられない。次に、発報されたアラーム情報と同じアラームかどうかを判定する。同じかどうかの判定は集約条件と同じでよい。このような判定により、過去に集約されたアラームが再発したか否かを判定できる。
ステップS610の判定がYesの場合、画面表示制御部16は、アラーム情報の再発フラグをONに設定する(S620)。再発したアラーム情報はマークなどで強調して表示される。なお、再発した時点のアラーム情報処理は1つであるが集約して表示してもよい。過去に集約されているためである。
図15は、再発したアラームに関するアラーム情報を模式的に示す図の一例である。図15(a)は再発前のアラームに関するアラーム情報を示し、図15(b)は所定時間T2が経過するか又は対応完了したアラーム情報を示す。図15(a)ではA社、B社のアラーム情報が集約によりYellowで表示されている。図15(b)に示すように対応完了することで、A社(通番1)、B社(通番2)のアラーム情報が非表示になる。所定時間T2が経過したが未対応のアラーム情報はYellowのまま表示される。なお、図15(b)では、C社のアラーム情報が追加されている。
図15(c)はA社のアラームが再度発報された場合のアラーム情報を示す。画面表示制御部16は、再度発報されたアラーム情報が、過去に集約されていたアラーム情報と同じアラームに起因することを示すため★マークを表示している。これにより、オペレータ9は表示されたアラーム情報が過去に集約されたアラーム情報と同じアラームに基づき生成されたことを容易に把握できる。
なお、図15の表示例は一例であり、過去に集約されていたアラーム情報と同じアラームが再度発報されたことを文字で表示してもよい。また、アラーム情報の輝度を上げたり、点滅させたり、文字を大きく表示したりしてもよい。
<<発生頻度の変化処理>>
同じ複数のアラームの発報が停止した場合、一般に、アラームを発報させていた障害が解決したと推定される。障害が解決したと推定される場合、オペレータ9は他のアラームを優先するなどの行動が可能になる。
同じ複数のアラームの発報が停止した場合、一般に、アラームを発報させていた障害が解決したと推定される。障害が解決したと推定される場合、オペレータ9は他のアラームを優先するなどの行動が可能になる。
図16は、発生頻度監視部24がアラームを発報させていた障害が解決したと推定する手順を示すフローチャート図の一例である。図16の手順は、例えば図6のステップS142で実行される。
発生頻度監視部24は、同じアラームが発報されたか否かを判定する(S710)。
ステップS710の判定がYesの場合、発生頻度監視部24は、アラームが発報されるとタイマーの測定値が閾値1よりも小さいか否かを判定する(S720)。このタイマーは同じアラームの発報のたびにセットされるタイマーであり、同じアラームが発報されてからの時間を測定している。閾値1は、同じアラームが連続していると見なせる程度の時間である。
ステップS720の判定がYesの場合、発生頻度監視部24は連続フラグを1つ大きくする(S730)。連続フラグは、同じアラームが連続して発報されていると見なせる程度の同じアラームの件数である。
ステップS730に続いて、又は、ステップS720の判定がNoの場合、発生頻度監視部24はタイマーをセットする(S740)。すなわち、タイマーは同じアラームの発報のたびにセットされる。この後、処理はステップS710に進む。
ステップS710の判定がNoの場合、発生頻度監視部24はタイマーの測定値が閾値2よりも小さいか否かを判定する(S750)。閾値2は、連続していた同じアラームが途切れたと見なせる程度の時間である。
ステップS750の判定がNoの場合、処理はステップS710に進む。
ステップS750の判定がYesの場合、発生頻度監視部24は、連続フラグが閾値3よりも大きいか否かを判定する(S760)。ステップS760の判定がNoの場合、同じアラームは止まったが連続していたほどではないので、図16の処理は終了する。
ステップS760の判定がYesの場合、画面表示制御部16はアラーム情報に、障害が解決したと推定される旨みを表示する(S770)。
図17は、解決済みが表示されるアラーム情報を模式的に示す図の一例である。図17ではA社、B社のアラーム情報が集約によりYellowで表示されているが、A社のアラーム情報に「解決?」という文字が表示されている。この文字は、障害が解決したと推定される旨を意味する。これにより、オペレータ9は表示されている障害が解決した可能性があると判断できる。
なお、図17の表示例は一例であり、単なるマークにより障害が解決した可能性があることを表示してもよいし、アラーム情報の輝度を下げたり、文字を小さく表示したりしてもよい。
<<過去の事例の表示>>
図6にて説明したように、過去事例フラグがONの場合、監視システム10は、集約されたアラーム情報や分割領域で表示されるアラーム情報に過去に類似するインシデントデータがある旨を表示する。また、オペレータの操作によっても過去のインシデントデータを表示することができる。以下では、オペレータの操作によって表示されるインシデントデータについて説明する。
図6にて説明したように、過去事例フラグがONの場合、監視システム10は、集約されたアラーム情報や分割領域で表示されるアラーム情報に過去に類似するインシデントデータがある旨を表示する。また、オペレータの操作によっても過去のインシデントデータを表示することができる。以下では、オペレータの操作によって表示されるインシデントデータについて説明する。
図18は、監視システム10がアラーム情報に関連したインシデントデータを表示する手順を示すフローチャート図の一例である。図19は、集約されたアラーム情報と共に表示されるインシデントデータを模式的に示す図の一例である。図18の説明では適宜、図19を参照して説明する。図19(a)の通番が1のアラーム情報には類似インシデントマーク503が表示されている。類似インシデントマーク503は過去事例フラグのONにより表示される。
S1:オペレータ9は類似インシデントマーク503をみて、マウス312のカーソル502を例えば右クリックする。監視システム10の操作受付部15は集約されたアラーム情報の選択を受け付ける。図19(a)に示すように、画面表示制御部16が「過去事例の表示」というメニュー501を表示する。このメニュー501は、オペレータ9がマウス312で選択したアラーム情報と類似する過去のアラーム情報を、監視システム10が表示するためのメニューである。オペレータ9がマウス312を例えば左クリックすることでメニュー501を押下する。監視システム10の操作受付部15はメニュー501の押下を受け付ける。
S2:監視システム10はアラーム情報の項目をインシデント管理システム30に送信する。この項目はインシデントデータDB3001を検索するための項目である。例えば、サーバIDとアラーム番号などである。
S3:インシデント管理システム30はアラーム情報の項目を受信し、データ検索部32がアラーム情報の項目でインシデントデータDB3001を検索する。すなわち、サーバIDとアラーム番号が同じインシデントデータをインシデントデータDB3001から検索する。
S4:インシデント管理システム30の送受信部31は検索に適合したインシデントデータを監視システム10に送信する。
S5:監視システム10はインシデントデータを受信して、画面表示制御部16がディスプレイ308にインシデントデータを表示する。図19(b)では、サーバIDとアラーム番号が同じインシデントデータが表示されている。したがって、担当者は過去の類似したアラーム情報の対応方法を参照して対応することができる。
なお、検索に用いられるアラーム情報の項目はアラーム番号だけでもよい。この場合、セキュリティで許可されている場合にインシデント管理システム30は異なる顧客のアラーム情報を検索できる。また、検索に用いられるアラーム情報の項目はサーバIDだけでもよい。この場合、インシデント管理システム30は同じ顧客のアラーム情報だけを検索できる。このように検索に用いられるアラーム情報の項目によって得られるインシデントデータが異なるので、検索に用いられるアラーム情報の項目はオペレータ9が任意に選択できることが好ましい。
<アラーム情報のその他の表示例>
集約されたアラーム情報又は分割して表示されたアラーム情報のその他の表示例について説明する。
集約されたアラーム情報又は分割して表示されたアラーム情報のその他の表示例について説明する。
<<作業に起因するアラーム情報>>
顧客の担当者8が作業中の場合、アラームが頻繁に発報される場合がある。これは、作業により被監視システム41のサーバがPING応答しなくなったり、ラックが開放されたりするためである。しかし、作業に起因するアラーム情報は、オペレータ9が顧客に連絡する必要性がほとんどない。そこで、以下のように、作業に起因するアラーム情報を検出し、その旨を画面に表示してもよい。
顧客の担当者8が作業中の場合、アラームが頻繁に発報される場合がある。これは、作業により被監視システム41のサーバがPING応答しなくなったり、ラックが開放されたりするためである。しかし、作業に起因するアラーム情報は、オペレータ9が顧客に連絡する必要性がほとんどない。そこで、以下のように、作業に起因するアラーム情報を検出し、その旨を画面に表示してもよい。
図20は、アラーム情報集約部21が、作業に起因するアラーム情報を検出して画面を表示する手順を示すフローチャート図の一例である。図20の処理は図6の集約処理の後、前後、又は並行して実行される。
まず、アラーム情報集約部21は例えばアラーム情報のサーバIDをキーにして顧客作業情報DB1005を参照する(S510)。これにより、アラーム情報と同じサーバIDが設定された顧客作業情報を読み出すことができる。
次に、アラーム情報集約部21は集約されたアラーム情報が作業に起因するかどうかを判定する(S520)。アラーム情報集約部21は、ステップS510で読み出した顧客作業情報のうち、アラーム情報の発生日時が作業時間と重複するかどうかを判定する。
ステップS520の判定がNoの場合、図20の処理は終了する。
ステップS520の判定がYesの場合、アラーム情報集約部21は集約されたアラーム情報に作業中である旨を表示する(S530)。
図21は、集約されたアラーム情報を模式的に示す図の一例である。図21のアラーム情報には、作業中の項目が表示されており、A社のアラーム情報に「作業中」という文字が表示されている。したがって、オペレータ9は集約されたアラーム情報が顧客の担当者8の作業に起因するものかどうかを一目で把握でき、オペレータ9が顧客に連絡する必要性がない又は連絡はしても緊急度が低いことを把握できる。
なお、図21の表示例は一例であり、顧客作業情報に含まれる情報であれば画面表示制御部16が表示できる。例えば、作業時間、担当者8、備考などを表示してよい。また、「作業中」のように文字で表示するのでなく、作業に起因するアラーム情報の輝度を下げたり、白黒表示したり、文字を小さく表示したりしてもよい。
<その他の適用例>
以上、本発明を実施するための最良の形態について実施例を用いて説明したが、本発明はこうした実施例に何等限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変形及び置換を加えることができる。
以上、本発明を実施するための最良の形態について実施例を用いて説明したが、本発明はこうした実施例に何等限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変形及び置換を加えることができる。
図22に示すように、複数台の端末を監視システムに接続することも有効である。図22は、複数台の端末を利用した監視システム10の適用例を説明する図の一例である。端末Aをオペレータが使用し、端末Bをリーダー5が使用する。リーダー5とは複数のオペレータの統括者である。このようなシステムによれば、監視システムのアラームに対応するだけでなく、アラームに対応するオペレータのアラームにも対応できる。オペレータは主に集約領域を監視し、メイン領域を参考のために参照する。リーダーは主に分割領域を監視し、メイン領域を参考のために参照する。オペレータの端末Aとリーダーの端末Bは異なる画面を表示できる。
例えば、監視システム10のアラームのバースト(対応しきれないほどのアラームが大量に発生する状態)が起こっている際又はオペレータの対応が遅延している際、オペレータ又は監視システム10が分割領域を表示してリーダー5にエスカレーション(緊急対応の要請)する。この場合、監視システム10はオペレータ9から通知を受けるなどにより端末Bに画面の分割を要求する。リーダー5は画面が分割されたことで対応が必要であることを把握できる。リーダー5は必要に応じてメイン領域を参照するので個別のアラームを確認できる。また、分割領域又はメイン領域のスクロール速度を調整すると、見たいアラームを早期に見つけられる。例えば、分割領域の一連のアラームの先頭にフォーカスした状態で、メイン領域を表示する。
リーダーへの通知は以下のようなケースが考えられる。
(1) 緊急度が高い(何かしらの支援や対処が必要なもの)ケースの例
・対応が遅延しているケース(例:アラーム発生時刻から未対応が10分を超えた場合)
・バーストが発生しているケース(例:同一ユーザでシステムアラームが1分間で60回を超えた場合)
・アラームが同時多発しているケース(例:複数ユーザで同時に20件以上のアラームが発生した場合)
(2) 重要度が高い(周知が必要でリーダーが状況を把握しておく必要があるもの) ケースの例
・重要システムからのアラーム(例:社会基盤システム、センター共通サービス基盤など)
・重要顧客からのアラーム(例:重要顧客に位置づけられるユーザ)
・繰り返しアラームが発生している(例:同一ユーザにて1時間以上連続してアラームが出続けている)
したがって、分割領域を利用することでエスカレーションが容易になる。また、端末Aにおけるオペレータの実作業と端末Bにおけるリーダー5の全体統制作業について、役割等も明確に分けることができる。上記のように、オペレータ9の対応方法ごとにアラームが集約されることで効率的な運用を実現できる。
(1) 緊急度が高い(何かしらの支援や対処が必要なもの)ケースの例
・対応が遅延しているケース(例:アラーム発生時刻から未対応が10分を超えた場合)
・バーストが発生しているケース(例:同一ユーザでシステムアラームが1分間で60回を超えた場合)
・アラームが同時多発しているケース(例:複数ユーザで同時に20件以上のアラームが発生した場合)
(2) 重要度が高い(周知が必要でリーダーが状況を把握しておく必要があるもの) ケースの例
・重要システムからのアラーム(例:社会基盤システム、センター共通サービス基盤など)
・重要顧客からのアラーム(例:重要顧客に位置づけられるユーザ)
・繰り返しアラームが発生している(例:同一ユーザにて1時間以上連続してアラームが出続けている)
したがって、分割領域を利用することでエスカレーションが容易になる。また、端末Aにおけるオペレータの実作業と端末Bにおけるリーダー5の全体統制作業について、役割等も明確に分けることができる。上記のように、オペレータ9の対応方法ごとにアラームが集約されることで効率的な運用を実現できる。
さらに、分割領域がポップアップ表示される場合、重要性に応じて、ポップアップ位置を変えてもよい。例えば、重要性が高い時は右上、低い時は右下などに表示位置を決定する。これにより、オペレータ9は重要性の判断が容易になり、また、集約領域やメイン領域の真ん中に重畳するよりも視認性が向上する。
また、リーダーの端末Bが分割領域を表示する態様は2パターンある。1つは、オペレータの端末Aで分割された分割対象のアラーム情報(複数の分割が発生)を、1つのレコードに集約して、複数の端末Aのアラーム情報をリスト状に表示するパターンである。もう1つは、オペレータの複数の端末Aで分割されたアラーム情報を、端末Bの別々のテーブルに表示するパターンである。この場合、各テーブルのアラーム情報は集約されない。個別のアラーム情報が表示されるのでスクロール制御されている場合に有効である。
なお、リーダー5ではなく、サブオペレータや担当者が別端末で確認する事なども可能である。
また、監視システム10は、アラームの過去の発報状況と対応方法の組を学習することができる。この学習結果により、対応方法が学習されていないアラームが発報された場合、監視システム10がオペレータ9に警告してもよい。例えば、強調色で表示したり、音声を出力したりしてもよい。監視システム10がバイブレータを振動させたりパトランプを点滅させたりしてもよい。
また、本実施形態では、上から下にアラーム情報がスクロールされる例を説明したが、下から上にスクロールされてもよい。
また、本実施形態では、監視システム10にローカルに接続されたディスプレイ308に表示される画面を説明したが、監視システム10はサーバクライアント方式でもよい。この場合、監視システム10はWebサーバ又はWebアプリとして機能しHTMLやJavaScript(登録商標)で生成された画面情報をクライアントPCに送信する。この画面情報には、アラーム情報が集約されている。また、分割領域のスクロール速度が一定化になるように画面情報が生成されている。したがって、オペレータ9は遠隔地から被監視システム41を監視できる。
また、監視システム10の機能は複数のサーバに分散して搭載されていてもよいし、監視システム10が複数あってもよい。
また、図5などの構成例は、監視システム10による処理の理解を容易にするために、主な機能に応じて分割したものである。処理単位の分割の仕方や名称によって本願発明が制限されることはない。監視システム10、データセンター40、及び、インシデント管理システム30の処理は、処理内容に応じてさらに多くの処理単位に分割することもできる。また、1つの処理単位がさらに多くの処理を含むように分割することもできる。
また、本実施形態では障害の発生時のアラームを例にして説明したが、災害の発生時に発報されるアラームに対しても適用できる。災害とは、例えば、水害、風害、砂嵐、塩害、土砂災害、雪害、雹、雷、震度やマグニチュードが閾値以上の地震、火山の噴火、隕石の落下、太陽活動、テロ、暴動、爆発などである。
なお、アラーム情報生成部14はアラーム情報生成手段の一例であり、画面表示制御部16はアラーム情報表示手段の一例であり、画面分割部17は分割領域生成手段の一例であり、スクロール制御部18はスクロール速度制御手段の一例である。アラーム情報集約部はアラーム情報集約手段の一例であり、顧客作業情報DB1005は作業予定情報の一例であり、集約領域に表示されたアラーム情報は集約アラーム情報の一例である。
10 監視システム
12 監視部
13 アラーム判定部
14 アラーム情報生成部
15 操作受付部
16 画面表示制御部
17 画面分割部
18 スクロール制御部
21 アラーム情報集約部
22 再発監視部
23 検索要求部
24 発生頻度監視部
30 インシデント管理システム
40 データセンター
41 被監視システム
100 運用管理システム
200 保守サービスシステム
12 監視部
13 アラーム判定部
14 アラーム情報生成部
15 操作受付部
16 画面表示制御部
17 画面分割部
18 スクロール制御部
21 アラーム情報集約部
22 再発監視部
23 検索要求部
24 発生頻度監視部
30 インシデント管理システム
40 データセンター
41 被監視システム
100 運用管理システム
200 保守サービスシステム
Claims (10)
- 被監視システムの稼動状況を監視し障害が検出された場合にアラームを発報する監視システムであって、
前記アラームが発報されるごとに前記アラームに関するアラーム情報を生成するアラーム情報生成手段と、
複数の同じアラーム情報を集約条件に基づいて1つの集約アラーム情報に集約するアラーム情報集約手段と、
前記アラーム情報生成手段が生成した前記アラーム情報及び前記アラーム情報集約手段により集約された前記集約アラーム情報を表示するアラーム情報表示手段と、
を有する監視システム。 - 前記アラーム情報は、前記障害に対しオペレータが取るべき対応方法を含んでおり、
前記集約条件が、前記対応方法が同じ前記アラーム情報を集約するという条件である場合、
前記アラーム情報集約手段は、前記対応方法が同じ複数の前記アラーム情報を前記集約アラーム情報に集約する請求項1に記載の監視システム。 - さらに、複数の同じアラーム情報を分割して表示する分割条件が満たされる場合、前記アラーム情報が時系列に表示される領域とは別の分割領域を生成する分割領域生成手段と、
前記分割領域に前記同じアラーム情報を、停止状態を含む一定以下のスクロール速度で表示するスクロール速度制御手段と、を有する請求項1又は2に記載の監視システム。 - 前記対応方法は、電話による連絡、電話による連絡の場合の電話番号、電子メールによる連絡、電子メールによる連絡の場合の電子メールアドレス、又は、SNS(Social Network System)の通知先のいずれか1つ以上を含み、
前記アラーム情報集約手段は、電話による連絡、電子メールによる連絡、電話番号、及び、電子メールアドレスのいずれか1つ以上が一致する複数の前記アラーム情報を前記集約アラーム情報に集約する請求項2に記載の監視システム。 - 前記アラーム情報は、前記障害が解決したか否か登録される項目を有し、
前記アラームの発報により生成した前記アラーム情報が、前記項目に前記障害が解決した旨が登録された前記アラーム情報と同じ場合、
前記アラーム情報表示手段は、前記集約アラーム情報に集約された前記アラーム情報を生成させた前記アラームが再発したおそれがある旨を表示する請求項2に記載の監視システム。 - 連続して発報されていた同じ前記アラームが所定時間、発報されなくなった場合、
前記アラーム情報表示手段は、連続した前記アラームに関し表示されている前記集約アラーム情報に、前記障害が解決した可能性がある旨を表示する請求項2に記載の監視システム。 - 前記アラーム情報表示手段は、複数の前記同じアラーム情報のうち最初の前記アラーム情報が生成された時からの経過時間又は前記同じアラーム情報が集約された件数を測定し、
前記アラーム情報表示手段は、前記経過時間又は前記件数に応じて前記集約アラーム情報の表示色を変更する請求項2〜6のいずれか1項に記載の監視システム。 - 前記アラーム情報表示手段は、前記被監視システムの前記障害として検出されうる前記被監視システムに対する作業の作業日時が登録された作業予定情報から前記作業日時を読み出し、前記アラームを発報させた前記障害の発生時刻と比較して、
前記発生時刻が前記作業日時と重複する場合、前記集約アラーム情報に前記作業に起因するアラームの可能性がある旨を表示する請求項2〜7のいずれか1項に記載の監視システム。 - 前記アラーム情報は、オペレータにより前記障害が解決したか否か登録される項目を有し、前記項目に前記障害が解決した旨が登録されると、
前記分割領域生成手段は、前記分割領域に表示されていた複数の前記同じアラーム情報と共に前記分割領域を消去する請求項3に記載の監視システム。 - 被監視システムの稼動状況を監視し障害が検出された場合にアラームを発報する情報処理装置を、
前記アラームが発報されるごとに前記アラームに関するアラーム情報を生成するアラーム情報生成手段と、
前記アラーム情報生成手段が生成した前記アラーム情報を時系列に表示するアラーム情報表示手段と、
複数の同じアラーム情報を分割して表示する分割条件が満たされる場合、前記アラーム情報が時系列に表示される領域とは別の分割領域を生成する分割領域生成手段と、
前記分割領域に前記同じアラーム情報を一定以下のスクロール速度で表示するスクロール速度制御手段、として機能させるためのプログラム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2016037735A JP2017156863A (ja) | 2016-02-29 | 2016-02-29 | 監視システム、プログラム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2016037735A JP2017156863A (ja) | 2016-02-29 | 2016-02-29 | 監視システム、プログラム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2017156863A true JP2017156863A (ja) | 2017-09-07 |
Family
ID=59809719
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2016037735A Pending JP2017156863A (ja) | 2016-02-29 | 2016-02-29 | 監視システム、プログラム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2017156863A (ja) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2019054157A1 (ja) * | 2017-09-15 | 2019-03-21 | 株式会社Fuji | ストッカ |
JP6735398B1 (ja) * | 2019-08-06 | 2020-08-05 | 株式会社 ディー・エヌ・エー | ライブ動画を配信するためのシステム、方法、及びプログラム |
JP2020144954A (ja) * | 2020-06-12 | 2020-09-10 | ヤフー株式会社 | 監視装置、監視方法、およびプログラム |
JP2021027583A (ja) * | 2019-08-06 | 2021-02-22 | 株式会社 ディー・エヌ・エー | ライブ動画を配信するためのシステム、方法、及びプログラム |
-
2016
- 2016-02-29 JP JP2016037735A patent/JP2017156863A/ja active Pending
Cited By (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2019054157A1 (ja) * | 2017-09-15 | 2019-03-21 | 株式会社Fuji | ストッカ |
JP2019053544A (ja) * | 2017-09-15 | 2019-04-04 | 株式会社Fuji | ストッカ |
JP7128615B2 (ja) | 2017-09-15 | 2022-08-31 | 株式会社Fuji | ストッカ |
JP6735398B1 (ja) * | 2019-08-06 | 2020-08-05 | 株式会社 ディー・エヌ・エー | ライブ動画を配信するためのシステム、方法、及びプログラム |
JP2021027583A (ja) * | 2019-08-06 | 2021-02-22 | 株式会社 ディー・エヌ・エー | ライブ動画を配信するためのシステム、方法、及びプログラム |
JP2021027471A (ja) * | 2019-08-06 | 2021-02-22 | 株式会社 ディー・エヌ・エー | ライブ動画を配信するためのシステム、方法、及びプログラム |
US11589130B2 (en) | 2019-08-06 | 2023-02-21 | DeNA Co., Ltd. | System, method, and program for distributing live video |
JP7341956B2 (ja) | 2019-08-06 | 2023-09-11 | 株式会社 ディー・エヌ・エー | ライブ動画を配信するためのシステム、方法、及びプログラム |
JP7399343B1 (ja) | 2019-08-06 | 2023-12-15 | 株式会社 ディー・エヌ・エー | ライブ動画を配信するためのシステム、方法、及びプログラム |
JP2020144954A (ja) * | 2020-06-12 | 2020-09-10 | ヤフー株式会社 | 監視装置、監視方法、およびプログラム |
JP7181253B2 (ja) | 2020-06-12 | 2022-11-30 | ヤフー株式会社 | 監視装置、監視方法、およびプログラム |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10142213B1 (en) | Techniques for providing event driven notifications | |
JP2017156863A (ja) | 監視システム、プログラム | |
CN111343424B (zh) | 在线评标的监控***及方法 | |
US20200133698A1 (en) | Alerting, diagnosing, and transmitting computer issues to a technical resource in response to a dedicated physical button or trigger | |
US20140277753A1 (en) | Events Management | |
JP2015028700A (ja) | 障害検知装置、障害検知方法、障害検知プログラム及び記録媒体 | |
KR102549129B1 (ko) | 디바이스 장애 통합 관리 플랫폼 제공 방법 | |
JP2017538173A (ja) | ランタイムイベントを分類及び分析するためのシステム及び方法 | |
JP2007241872A (ja) | ネットワーク上のコンピュータ資源の変更監視プログラム | |
US20230262081A1 (en) | Intelligent alert customization in a backup and recovery activity monitoring system | |
JP5975094B2 (ja) | 交換候補提示方法、情報処理装置、及びプログラム | |
CN106921518A (zh) | 监控视图展示方法及装置 | |
US20140006607A1 (en) | Monitoring method and apparatus | |
CN111082998A (zh) | 一种运维监控校园汇聚层的架构*** | |
JP6373217B2 (ja) | 情報処理装置、プログラム、情報提供方法 | |
JP6665503B2 (ja) | データ収集システム、データ収集装置及びデータ収集方法 | |
CN114328107A (zh) | 光磁融合存储服务器集群的监控方法、***及电子设备 | |
JP2005167523A (ja) | カメラ監視システムおよび画像管理装置並びにプログラム | |
JP6636605B1 (ja) | 履歴監視方法、監視処理装置および監視処理プログラム | |
JP2007013928A (ja) | 遠隔障害監視装置及び遠隔障害監視方法 | |
JP6592577B1 (ja) | 影響範囲通知装置、影響範囲通知システム、影響範囲通知方法、及びプログラム | |
CN110635445A (zh) | 继电保护远程在线监测和分析***及方法 | |
JP2005284357A (ja) | ログ解析プログラム及びログ解析装置 | |
JP2005167524A (ja) | カメラ監視システムおよび画像閲覧端末装置並びにプログラム | |
JP2015032068A (ja) | 情報処理画面出力装置、情報処理画面出力プログラム、および情報処理画面出力システム |