JP3871643B2 - 業務運用監視システム - Google Patents
業務運用監視システム Download PDFInfo
- Publication number
- JP3871643B2 JP3871643B2 JP2002371683A JP2002371683A JP3871643B2 JP 3871643 B2 JP3871643 B2 JP 3871643B2 JP 2002371683 A JP2002371683 A JP 2002371683A JP 2002371683 A JP2002371683 A JP 2002371683A JP 3871643 B2 JP3871643 B2 JP 3871643B2
- Authority
- JP
- Japan
- Prior art keywords
- unit
- monitoring
- condition
- monitoring information
- state
- 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.)
- Expired - Fee Related
Links
Images
Landscapes
- Debugging And Monitoring (AREA)
- Computer And Data Communications (AREA)
Description
【０００１】
【発明の属する技術分野】
この発明は運用監視システムに関し、特に、監視対象に発生した障害を検出するための運用監視システムに関する。
【０００２】
【従来の技術】
従来の運用監視システムは、監視対象システムの稼動状態を「システムの障害」として検出し、管理者に通知することで障害監視を実現している。復合コンピュータの運行状況を一箇所で集中監視して得た各種のメッセージ群を、その優先度や内容に応じて滞りなく自動的に分類・ランク付けし、発生した異常への対処を誤りなく行う（例えば、特許文献１参照。）。
【０００３】
【特許文献１】
特開平１０−６３５３９号公報
【０００４】
当該特許文献１によれば、コンピュータの運用に重大な影響を与えるおそれのある事象についてのメッセージのみが自動的に選別・通報されるため、運用監視業務に従事するオペレータは、メッセージ群を取捨選択して、障害発生に関するメッセージを選び出す必要がなくなり、個々のメッセージの通報に即応して対策措置を開始することができる。また、選別されたメッセージは、所定の優先度ごとにランク付けされた順序で所定の通報先に通報されるので、緊急性のある事象への対処手順をより効率化することができる。
【０００５】
【発明が解決しようとする課題】
従来のシステムは上述のように構成されており、以下に挙げるような問題点があった。
【０００６】
第１の問題点として、こうした業務の視点の運用監視システムは主に「システムの障害」を通知することによって動作しており、「物理的に正常に動作しているシステム」が、処理遅延等の理由により、業務に支障を来すような事項については異常として検出されないのが現実である。従来のシステムで管理者（オペレータ）がこれを知るための方法としては、こうした処理の完了を通知させることにしておき、完了が通知されないシステムがあれば、それはまだ完了していないものだと管理者が理解するという方法がある。しかしながら、その方法では、膨大な監視情報の中から完了通知の無いシステムを管理者が見つけ出す必要がある。当然ながら、その作業は、あらかじめ知り得るシステムについての情報を元に、または、記憶をたよりに見つけ出す作業であるが、人間には「無いものを探す」行為は、それ自体非常に困難な作業である。また、すべての管理者が必ずしもすべてのシステムの存在を知り得る訳ではないため、そのような管理者にとって未知のシステムから通知が無い場合の問題を早期検出することはまず不可能であるという問題点があった。
【０００７】
第２の問題点として、非常に複雑な系で障害が発生した場合には、業務の視点による障害監視システムでさえも、その系の障害を、時として、障害監視システムのもつ所定の条件判定のみで「業務に影響する障害」と判定させることができない場合がある。このような例として、障害回避のために多重化・冗長化された系、特に独自の方法で複雑に多重化・冗長化された系や、複数システムで独自に構成した系を監視するような場合が挙げられる。このような系では、ある部分が障害を発生しても、系全体としては正常に動作を続けることができ、即座に業務に支障を及ぼすものではないような、業務の視点からは軽度とみなされる障害が発生し得るが、現在の監視システムではそれぞれのシステムを独立して個別に監視するか、系全体を単独のシステムとして監視する方法しかなく、監視システムはその複雑な系の動作状態を内部の所定の条件判定では適切に表現しきれない場合が生じ得る。その結果、監視システムは適切に業務への影響を通知することができなくなり、障害の実際の業務への影響を示す情報はその正確性・信頼性を失ってしまうという問題点があった。
【０００８】
この発明は、かかる問題点を解決するためになされたものであり、単なるシステムの障害のみならず、システムは一応稼働してはいるものの“業務”に支障をきたす「業務に影響する障害」が発生した場合にも、それを的確に検出することができる業務運用監視システムを得ることを目的とする。
【０００９】
【課題を解決するための手段】
この発明は、監視対象システムの業務の運用状態を監視する業務運用監視システムであって、前記監視対象システムの業務の運用状態を示す業務運用監視情報が入力され、予め設定された所定の業務運用判定条件に基づいて、前記業務運用監視情報の検査を行い、当該検査の結果に基づいて、前記業務運用監視情報の蓄積を行う受動処理機構部と、予め設定された所定のスケジュールに従って、前記監視対象システムが業務に支障をきたさない状態を定義した状態条件と前記受動処理機構部により蓄積された前記業務運用監視情報とを比較して、正常動作であれば正常動作通知を生成して送信し、前記業務運用判定条件を満たしていないものの業務に支障をきたさない状態であれば警告通知を生成して送信し、業務に支障をきたす状態であれば障害通知を生成して送信する能動処理機構部と、前記受動処理機構部により蓄積される前記業務運用監視情報、前記業務運用判定条件および前記状態条件を格納する蓄積部とを備え、前記受動処理機構部は、前記監視対象システムの業務運用状態を示す業務運用監視情報が入力されたときに、前記業務運用判定条件に基づいて、前記監視情報の条件判定を行うとともに、前記監視情報の蓄積を行う条件判定処理部と、前記条件判定処理部からの指令に基づいて、前記業務運用監視情報をそのまま外部に出力することにより前記監視情報の中継処理を行う監視情報中継部と、前記条件判定処理部からの指令に基づいて、操作・再生成・再構成のいずれかの処理を前記監視情報に対して行った後に外部に出力する監視情報処理部とを備えていることを特徴とする業務運用監視システムである。
【００１０】
また、前記受動処理機構部は、前記監視対象システムの業務運用状態を示す業務運用監視情報が入力されたときに、前記業務運用判定条件に基づいて、前記監視情報の条件判定を行うとともに、前記監視情報の蓄積を行う条件判定処理部と、前記条件判定処理部からの指令に基づいて、前記業務運用監視情報をそのまま外部に出力することにより前記監視情報の中継処理を行う監視情報中継部と、前記条件判定処理部からの指令に基づいて、操作・再生成・再構成のいずれかの処理を前記監視情報に対して行った後に外部に出力する監視情報処理部とを備えている。
【００１１】
また、前記能動処理機構部は、前記スケジュールに従って起動信号を出力する自律制御部と、前記監視対象システムが業務に支障をきたさない状態を定義した前記状態条件と前記受動処理機構部により蓄積された前記業務運用監視情報とを比較することで、前記監視対象システムの状態判定を行う状態判定処理部と、当該状態判定結果に基づいて通知情報を生成して送信する監視情報生成部とを備えている。
【００１２】
【発明の実施の形態】
実施の形態１．
本発明の運用監視システムについて、図１〜図３を用いて説明する。図１は、本発明の運用監視システムの構成を示した概略構成図である。図１において、１００は監視対象である監視対象システムであり、１０１は監視対象システム１００の運用および監視を行うシステム監視部、１０２は、システム監視部１０１からの情報に基づいて、監視対象システム１００における障害発生を監視する障害監視部である。
【００１３】
本発明による運用監視システムは、これらの監視対象システム１００とシステム監視部１０１との間、および、システム監視部１０１と障害監視部１０２との間に、図１に示すように、それらの間で通知される監視情報の受信により動作を開始し、所定の条件に従って、当該監視情報を操作したり蓄積したり、あるいは、単に中継する受動処理機構１０３と、自律的制御により動作を開始し、受動処理機構１０３によって蓄積された情報および予め蓄積された所定の条件に従って状態条件判定を行って新しい監視情報を生成する能動処理機構１０４と、状態条件と状態監視に必要な情報を保存しておくための蓄積部１０５とを、それぞれ設けている。各部は独立したシステムでも、統合されたシステムでも構わない。また、監視情報が送信されるシステム間であればどこに適用しても良く、監視対象システム内の機能として適用しても良い。
【００１４】
また、ここで説明する運用監視システムでは、システムの障害状態は障害通知によって管理者へ報告され、業務に影響の無いシステムの問題は警告通知によって管理者へ報告する例を挙げて説明する。
【００１５】
詳細を、図２により説明する。図２において、図１と同じ構成については同一符号を付して示し、ここでは説明を省略する。図２は、図１におけるシステム監視部１０１と障害監視部１０２との間（あるいは、監視対象システム１００とシステム監視部１０１との間）の部分を示したものである。但し、図２においては、図１で図示を省略した、監視情報出力部２と監視情報入力部１０とが記載されている。すなわち、監視情報を受動処理機構１０３で処理しやすくするため、受動処理機構１０３の前後に、監視情報を受け取って条件判定を容易にするために分解処理を行う監視情報入力部１０と、処理用のデータを再統合処理するための監視情報出力部２とが設けられている。
【００１６】
また、図２に示すように、受動処理機構部１０３は、監視情報入力部１０により分解処理されたデータを用いて条件判定処理を行うとともに、監視情報の蓄積を行う条件判定処理部５と、条件判定処理部５の指令により監視情報についての単なる中継処理を行う監視情報中継部３と、条件判定処理部５の指令に基づいて監視情報を操作・再構成・再生成する処理を行う操作・再構成・再生成処理部４とを備える。
【００１７】
一方、能動処理機構部１０４は、ＯＳのスケジュール機能や従来の運用監視ツールに備えられたスケジュール機能、または、後述の状態判定処理部８の起動を連続的・周期的に繰り返すような専用のプログラムによって実現される自律制御部７と、自律制御部７によって起動され、システムがその時点であるべき状態（業務に支障をきたさない状態）にあるかどうか、システムの状態をあらかじめ設定された状態条件テーブルと比較することで状態判定を行う状態判定処理部８と、状態判定に基づいて障害情報や警告情報が必要な際にその旨を示す監視情報を生成する監視情報生成部９とを備える。
【００１８】
動作について説明する。まず、初期設定として、監視対象システム１００のあるべき状態（正常な状態）を定義する設定条件を設定した状態条件テーブルと、監視対象システム１００の状態を示す監視情報から得られた条件判断に必要な状態情報を、あらかじめ蓄積部１０５に保存しておく。ここで、あるべき状態（正常な状態）とは、「業務に影響する障害」が全く発生していない状態をいう。
【００１９】
図３は、受動処理機構部１０３および能動処理機構部１０４の動作を示した流れ図である。まず、図２および図３（ａ）に基づいて、受動処理機構部１０３について詳しく説明する。監視情報が、システム監視部１０１から障害監視部１０２へ向けて送信される場合、まず、監視情報は監視情報入力部１０により受け取られた後、受動処理機構部１０３の条件判定処理部５へ送られる（ステップＳ１）。これを受け取った条件判定処理部５は、これを解析する操作として、蓄積部１０５に保存された状態条件テーブルの条件情報を取り出し（ステップＳ２）、当該条件情報に基づいて、受け取った監視情報と以前に蓄積された状態情報とを含め、その時点でシステムのあるべき条件を項目ごとに比較し、蓄積された監視情報同士の関係やそれぞれのあるべき条件を判定する（ステップＳ３）。比較すべき関連条件項目が無いか、あるいは、中継条件項目が満たされた場合は、条件判定処理部５は、監視情報中継部３へ中継処理を指示し、一方、操作・再構成・再生成処理条件項目が満たされた場合は、監視情報操作・再構成・再生成処理部４へそれぞれの処理を指示する。このとき、監視情報中継部３は監視情報を監視情報出力部２へ送信する中継処理を行い（ステップＳ４）、一方、監視情報操作・再構成・再生成処理部４は、監視情報に対し業務に影響の無い障害情報を警告情報に変換する処理と、一つの障害発生が他の障害に繋がる場合に複数の障害通知を生成する処理と、監視情報により新たな障害状態が発生すると同時に、警告状態の発生・解除なども同時に起こるような複雑な場合の再構成処理などを行う（ステップＳ５）。その後、条件判定処理部５は条件テーブルの設定に基づいて他の条件判断に必要な監視情報を蓄積部１０５へ保存する（ステップＳ６）。なお、ステップＳ３において、監視情報が予め設定された所定の条件を満たした場合には、条件テーブルの設定に基づいて、能動処理機構１０４の自律制御部７を起動させて、能動処理を開始するようにしてもよい（ステップＳ７）。また、ステップＳ７の処理と同時に、先に指示された監視情報は監視情報出力部２を経由して本来の受信先である障害監視部１０２へ送信される（ステップＳ８）。ここまでの受動処理機構１０３の動作により、入力される監視情報についての情報をより適切に運用監視システム上で拡張できる。なお、監視対象システム１００からシステム監視部１０１に監視情報が送信される場合も同様である。
【００２０】
次に、図２および図３（ａ）に基づいて、能動処理機構１０４が動作する場合について詳しく説明する。上述の受動動作は、監視情報が受動処理機構１０３へ入力されて初めて動作を開始したが、能動処理機構１０４は、機構内部または外部に設けられた自律制御部７によって起動され、状態判定処理部８が処理を実行する。ここで、自律制御部７はＯＳのスケジュール機能や従来の運用監視ツールに備えられたスケジュール機能、または条件判定部の起動を連続的、周期的に繰り返すような専用のプログラムによって実現されるものであり、具体的には、経過時間を計測し、予め定められた所定の時間が経過すると、所定の信号を状態判定処理部８に出力し、それにより、状態判定処理部８の動作を開始させるものである。
【００２１】
このようにして、自律制御部７が状態判定処理部８を起動させると、状態判定処理部８は、蓄積部１０５に保存された状態条件テーブルの状態条件情報を取り出し（ステップＳ１０）、蓄積部１０５に保存された状態条件テーブルと、現在のシステムの状態を表す監視情報とを用いて、ある時点で、監視対象システム１００が「本来あるべき状態（正常な状態）」にあるかを、設定された条件情報テーブルの能動条件が含まれるすべての項目について、項目ごとに比較や論理条件判定を行って状態判断を行い、障害状態や警告すべき状況の検出を行う（ステップＳ１１）。この処理によって通知の必要な状態が検出されると、監視情報生成部９を用いて、監視情報出力部２、監視情報入力部１０および受動処理機構内の条件判定処理部５のいずれかに対して、監視情報を各経路から送信する。監視情報生成部９は、条件判定処理部５の指定に基づいて、必要な監視情報を生成し（ステップＳ１２）、最も適切な経路に対し、指定の監視情報を送信する（ステップＳ１３）。具体的には、下位監視部または監視対象から監視情報が送信されたものとして扱いたい場合は監視情報入力部１０へ、また、最終的な生成処理を受動処理機構部１０３に任せ直接受動処理を起動したい場合には受動処理機構部１０３の条件判定処理部５へ、あるいは、直接上位の監視部へ送りたい場合には監視情報出力部２へと、それぞれの経路で送信する。各部に送信された後の監視情報は、受動処理の場合と同じく各部所定の処理が行われる。
【００２２】
以上のように、本実施の形態においては、１つまたは複数の計算機で構成されたシステムの状態を監視する「運用監視システム」において、「監視対象システム」、「システム監視部」と「業務障害監視部」との間で通知される監視情報（メッセージ）を、所定の条件に従って操作・蓄積・再生成・再構成するか、あるいは、単に中継する受動処理機構と、自律的制御により動作し、受動処理機構によって蓄積された情報、および、あらかじめ蓄積された所定の条件によって状態条件判定を行って新しい監視情報を生成する能動処理機構とを設け、これらの機構の組み合わせにより、システムの状態が業務に及ぼす影響を明確にするようにして、システムの障害の発生を検出するようにしたので、ある時点においては「物理的に正常な稼動状態にあるシステム」においても、処理遅延などの理由により業務上障害となりうる状態を検出したり、業務障害監視部の判定可能な範囲を超えるような複雑な系の障害が業務に与える影響をも適切に検出することができる。これにより、運用監視システムが通知する情報から、実際の業務に対する真の影響を、管理者自ら判断する負荷を最小限に抑えるとともに、障害発生の状況に見合った迅速な連絡や的確な復旧処置を行うことが可能になる。
【００２３】
実施の形態２．
以下の実施の形態においては、監視対象システム１００の具体的な例を挙げて、本発明の運用監視システムを適用した場合について説明する。本実施の形態においては、例えば、種々の商業用システムのように、営業時間帯には通常の業務運用を行い、営業時間終了後にバッチ処理を行うようなシステムの設置局があり、この種のシステムを本発明の運用監視システムにおいて監視する例について考える。
【００２４】
このようなシステムの設置局（以下、被監視局と呼ぶ。）は正常に閉局すれば問題ないが、何らかの事情により閉局すべき時刻を大幅に過ぎて閉局した場合、夜間のバッチ処理の遅れにより業務上支障が生じ得る。すなわち、万一バッチ処理を完了できない場合には、翌営業開始時間にシステムの通常運用が再開できないため、業務に支障をきたす。
【００２５】
このようなシステムでは、閉局時刻に被監視局が閉局通知を運用監視システムに送信するように構成すれば、管理者は閉局した被監視局を知ることができるが、障害ではないメッセージを監視しなければならないので、管理者の負荷となる。
【００２６】
そこで、このシステムに図４のように本発明の受動処理機構部１０３および能動処理機構１０４を加えた構成にする。すなわち、被監視局（Ａ）１００ａ，被監視局（Ｂ）１００ｂ，被監視局（Ｃ）１００ｃを監視運用する監視局２００には、障害監視部１０２、システム監視部１０１、および、その中間に本発明による受動処理機構部１０３および能動処理機構部１０４を設けることによって、受動処理機構部１０３によって閉局通知（監視情報）を各被監視局１００ａ〜１００ｃから受信し、それを各監視局の状態情報として蓄積部１０５に格納するとともに、当該蓄積部１０５に蓄積された情報を基に、閉局状況検査を能動処理機構１０４によって連続的および定期的に実行することによって追跡監視を行えるようになる。受動処理機構部１０３および能動処理機構部１０４の内部の構成については、図２に示したものと同様であるので、ここでは図２を参照するものとし、詳細な説明については省略する。なお、以下の説明の期間において、被監視局（Ｂ）１００ｂの物理的なシステムからの障害は検出されないものとする。
【００２７】
図４のシステムについて説明する。当該システムにおいては、
（１）１７：００ 閉局チェック開始
（２）１８：００ 閉局期限
と設定されており、
例として、１７：０１に被監視局１００ａが閉局し、１７：０２に被監視局１００ｃが閉局したが、閉局期限の１８：００を過ぎても、被監視局１００ｂからの閉局通知が送信されてこなかったという状況を仮定して、以下、説明する。
【００２８】
いま、被監視局（Ａ）１００ａ，（Ｂ）１００ｂ，（Ｃ）１００ｃのあるべき状態（正常な状態）を定義する条件が、既に、蓄積部１０５の状態条件テーブルに保存されており、システム監視部１０１が受信した監視情報から得られた条件判断に必要な状態情報が、受信された順に、徐々に、蓄積部１０５の状態条件テーブルに保存されていっている状態である。図５（ａ）に、状態条件テーブルの一例を示す。本実施の形態においては、状態条件テーブルにおけるあるべき状態を定義する条件として、「１７：００〜１８：００の間に閉局」という条件が設定されており、当該テーブルにおけるフラグは、監視対象システムが当該条件を満たしているか否かを示すものであり、満たした時点で「レ」が記載される。従って、このフラグが、本実施の形態における監視情報から得られた条件判断に必要な状態情報となっている。
【００２９】
図６に本実施の形態による運用監視システムの動作の流れを示す。まず、図２および図６（ａ）に基づいて、本発明の受動処理機構の動作について説明する。図４に示す監視局２００で、３つの被監視局（Ａ）１００ａ、被監視局（Ｂ）１００ｂおよび被監視局（Ｃ）１００ｃを監視する場合、被監視局（Ａ）１００ａおよび被監視局（Ｃ）１００ｃが適切な時間に閉局通知（監視情報）を送信すると、システム監視部１０１がこれを受け取り、受動処理機構部１０３へ送る（ステップＳ２１）。受動処理機構部１０３では、条件判定処理部５が、「１７：００〜１８：００の間に閉局」という所定の判定条件を蓄積部１０５から取り出し（ステップＳ２２）、受信した閉局通知が、当該所定の判定条件を満たすか否かを検査し（ステップＳ２３）、条件を満たしていた場合には、図５（ｂ）のように、状態条件テーブルのフラグの欄にフラグを立てることにより、当該閉局通知の内容を、能動処理機構１０４の追跡用に、蓄積部１０５に蓄積する（ステップＳ２４）。また、必要に応じて、それと同時に、障害監視部１０２へ正常閉局通知として送信する（もちろん必要なければ正常通知は送信しなくとも良い。）。
【００３０】
次に、図２および図６（ｂ）を用いて、能動処理機構部１０４の動作について説明する。能動処理機構部１０４は、自律制御部７の働きによって、適当な時刻に起動し（本実施の形態では、１回目の起動が１７：００になった時点で、以下、５分間隔に繰り返し起動）、状態判定処理部８は、蓄積部１０５から状態条件テーブルの内容を取り出し（ステップＳ３１）、当該状態条件テーブルにおける判定条件と蓄積された状態情報とを比較して閉局通知を検査する（ステップＳ３２）。なお、本実施の形態においては、受動処理機構部１０３が用いる判定条件と、能動処理機構部１０４が用いる状態条件とは、同じ条件となっているが、これに限らず、異なる条件としてもよい。この時点で、状態条件テーブルの状態情報を示すフラグにより、被監視局（Ａ），（Ｂ），（Ｃ）の正常通知の有無を確認するが、１７：００の時点においては、図５（ａ）のように、いずれにもフラグはたっていない。一方、２回目の起動における１７：０５の時点では、図５（ｂ）に示す状態条件テーブルのフラグにより、被監視局（Ａ）１００ａおよび被監視局（Ｃ）１００ｃの正常な閉局通知を確認するが、同時に被監視局（Ｂ）１００ｂの通知が無いことも検出できる。このようにして、一定の時間内（本実施の形態においては１７：００〜１８：００）に閉局通知が生成されるか否かを確認する場合は、例えば、能動処理機構１０４が、閉局時刻の期限（１８：００）以前の所定の時刻（１７：００）から起動し始め、以下、所定の時間間隔（５分間隔）で繰り返し起動して、起動の度に閉局通知が生成されていない被監視局があった場合には、状態判定処理部８が、監視情報生成部９に警告メッセージを発するように指示するように設定しておいてもよいが、むやみに警告を出すよりも最初の３０分程度は警告を発さずに様子を見ていた方が望ましいので、例えば、予め設定した所定の回数目の起動（例えば、１７：３０の７回目の起動）において、閉局通知が生成されていない監視局があった場合には、状態判定処理部８が、監視情報生成部９に警告メッセージを発するように指示するように設定しておいてもよい。このようにして監視対象システムは正常でも、その動作が業務に影響を与える障害状態となりうるものと検出して、必要な監視情報（ここでは警告通知）を生成して（ステップＳ３３）、当該警告通知を障害監視部１０２へ通知する（ステップＳ３４）。さらに、最大許容時間（１８：００）まで定期的に（例えば、５分間隔で）検査を繰り返すことによって追跡し、その期間内に閉局通知が無ければ、これを最終的に障害として通知すれば、管理者は障害が発生したものとして対応を開始することができる。
【００３１】
以上のように、本実施の形態によれば、従来の運用監視システムでは困難だったような、業務における障害をより的確に通知できるだけでなく、多重系や複数の監視対象を統合する形で構成された系においても、本来の運用監視システムの機能を生かしたまま、より的確に障害状態を通知できるようになる。これにより、運用監視システムが通知する情報から、実際の業務に対する真の影響を、管理者自ら判断する必要を最小限に抑えるとともに、障害発生の状況に見合った迅速な連絡や的確な復旧処置を行うことが可能になる。
【００３２】
実施の形態３．
本実施の形態においては、監視対象システムとして、障害回避のために多重化・冗長化された系を例に挙げて説明する。この種の系として、ここでは、二重化によって同一の機能を持つ２つのシステムが常に同期して動作しており、片方の系が障害を発生しても、全体としては正常に動作を続けることができる系、および、二重化されているが通常は片方のシステムのみ動作しており、障害発生時には待機していたもう一方の系（待機系）に切り替えて動作する系の２種類の系を考える。
【００３３】
こうした系においては、前者では片系が障害により停止しても、他系が代わりに処理を行うので、必要な処理自体は正常に継続できるため、即座に業務に障害を与えることはない。また、後者の例ではどちらかのシステムが動作していればよく、障害が発生して片方のシステムがダウンしても待機系が正常に動作を開始すれば業務に支障は出ないが、その一方の問題として、障害発生により待機系へ切り替える際に、万一、待機系が正常に起動しなかった場合には、重大な事態となってしまうということが考えられる。
【００３４】
図７のように、監視対象システム１００である被監視系１００Ａが、第一の系１００ｄと第二の系１００ｅとから構成された二重系のシステムを監視する場合にも、本発明においては、被監視系１００Ａとシステム監視部１０１との間に、受動処理機構部１０３と能動処理機構部１０４とを適用することによって、システム監視部、監視対象システムをほとんど変更することなく、従来のシステムにおいては実現できなかったような障害を検出できるようになる。
【００３５】
ここでは、まず、同期して動作する二重系の片系で障害が発生したものとする。図７の被監視系１００Ａについて説明する。当該被監視系においては、
（１）被監視系から１０分おきに正常通知を受信
（２）１分おきに状態チェック
と設定されており、
例として、１７：００の時点では第一の系１００ｄおよび第二の系１００ｅの両方が共に正常に動作しており、１８：００に第一の系１００ｄに異常が発生してダウンし、１９：００に第二の系１００ｅにも異常が発生してダウンしたという状況を仮定して、以下、説明する。
【００３６】
まず、被監視系１００Ａのあるべき状態（正常な状態）を定義する条件と、監視情報から得られた条件判断に必要な状態情報とを、あらかじめ蓄積部１０５の状態条件テーブルに保存しておく。図８に、状態条件テーブルの一例を示す。本実施の形態においては、状態条件テーブルにおけるあるべき状態を定義する条件として、「２系とも正常」という条件が設定されており、当該テーブルにおける状態情報は、被監視系１００Ａが当該条件を満たしているか否かを示すものであり、「○」が２系とも正常、「△」が片系が異常、「×」が２系とも異常を意味する。「△」のときに、警告メッセージが発せられ、「×」のときに障害通知がなされることとする。本実施の形態においては、これらの「○」、「△」、「×」が、監視情報から得られた条件判断に必要な状態情報となっている。なお、第一の系および第二の系における「○」および「×」は、各時刻における「正常」および「異常」を意味する監視情報である。
【００３７】
図９に本実施の形態による運用監視システムの動作の流れを示す。まず、図２および図９（ａ）に基づいて、本発明の受動処理機構の動作について説明する。図７に示す被監視系１００Ａで、２つの系１００ｄおよび１００ｅを監視する場合、第一の系１００ｄおよび第二の系１００ｅが適切な時間に正常通知（監視情報）を送信すると、システム監視部１０１が、これを受け取り、受動処理機構１０３へ送る（ステップＳ４１）。受動処理機構１０３では、条件判定処理部５が、「正常動作」という所定の判定条件を蓄積部１０５から取り出し（ステップＳ４２）、受信した正常通知が、当該所定の判定条件を満たすか否かを検査し（ステップＳ４３）、条件を満たしていた場合には、図８のように、状態条件テーブルの第一の系および第二の系の欄に「○」を入力することにより、当該正常通知の内容を、能動処理機構１０４の追跡用に、蓄積部１０５に蓄積する（ステップＳ４４）。ここで、異常通知があった場合には、条件を満たしていないと判断して、図８のように、状態条件テーブルの第一の系および第二の系の欄に「×」を入力するとともに、それらの結果から、被監視系１００Ａ全体の状態情報を「○」、「△」、「×」により入力する。また、必要に応じて、それと同時に、障害監視部１０２へ、２系とも正常の場合は正常動作通知として、片系が異常の場合は警告通知として、２系とも異常の場合は障害通知として送信する（もちろん必要なければ正常動作通知は送信しなくとも良い。）。
【００３８】
次に、図２および図９（ｂ）を用いて、能動処理機構部１０４の動作について説明する。能動処理機構部１０４は、自律制御部７の働きによって、適当な時間間隔で起動し（本実施の形態では、１０分おきに起動）、状態判定処理部８は、蓄積部１０５から状態条件テーブルの内容を取り出し（ステップＳ５１）、当該状態条件テーブルにおける判定条件と蓄積された状態情報とを比較して正常動作通知を検査する（ステップＳ５２）。この時点で、状態条件テーブルの状態情報を示す「○」、「△」、「×」により、被監視系１００Ａの正常通知の有無を確認するが、１７：００の時点においては、図８のように、正常状態である。一方、１８：００の時点では、第一の系１００ｄがダウンしていて、第二の系１００ｅは正常動作していることも検出できる。このときには、被監視系１００Ａは、いずれかの系が正常動作していれば、支障をきたさないので、被監視系１００Ａとしては正常動作である。しかしながら、この時点で警告メッセージを出しておけば、管理者は万一に備えて適切な処理を行うことができる。１９：００の時点では、第一の系１００ｄがダウンしていて、第二の系１００ｅもダウンしていることが検出できる。このときにはじめて、被監視系１００Ａは障害発生となる。このように、被監視系１００Ａは正常でも、片系に異常が発生した時点で、動作が業務に影響を与える障害状態となりうるものと検出して、必要な監視情報（ここでは警告通知）を生成して（ステップＳ５３）、当該警告通知を監視情報出力部２を介して障害監視部１０２へ通知する（ステップＳ５４）。さらに、所定間隔で検査を繰り返すことによって追跡し、２系ともにダウンした場合に、これを最終的に障害として通知すれば、管理者は障害が発生したものとして対応を開始することができる。
【００３９】
以上のように、受動処理機構部１０４は被監視系１００Ａの片系からの障害通知を受け取るが、蓄積部１０５にあらかじめ設定された条件情報テーブルと、この時点までの機構の動作により蓄積された状態情報に対して比較および条件判定を行うことによって、もう一方の系が障害通知を生成していないか、もしくは、正常通知を生成していることなどを検出できる。これによりシステム全体では障害状態に無いものと判断できるので、この障害通知は業務には支障の無い障害の発生として警告通知に変換し、システム監視部１０１へ送信するのが適切である。 監視情報はシステム監視部１０１が所定の処理を行った後、最終的に障害監視部１０２へ送信され、管理者には業務に支障の無い警告通知として正しく識別される。
【００４０】
一方、正常に動作していたもう片方の系でも障害が発生したときには、受動処理機構部１０３は被監視系１００Ａから先ほどと同様に障害通知を受け取るが、ここでは前回の片系の障害状態が既に蓄積されており、このデータと条件情報テーブルの検査から二重系全体が動作を継続できない障害、すなわち、業務に影響のある障害であることが検出できる。これによりこの障害通知を中継してシステム監視部１０１へ送信すると共に、もう片系の警告状態を障害状態に変更し新しく通知する。その結果、システム監視部１０１の処理を経て最終的に二重系全体で障害が発生しているものと通知されることにより、管理者には業務に障害を発生し得る重大障害として正しく識別される。
【００４１】
以上のように、本実施の形態によれば、従来の運用監視システムでは困難だったような、業務における障害をより的確に通知できるだけでなく、多重系や複数の監視対象を統合する形で構成された系においても、従来の運用監視システムの機能を生かしたまま、より的確に障害状態を通知できるようになる。これにより、運用監視システムが通知する情報から、実際の業務に対する真の影響を、管理者自ら判断する必要を最小限に抑えるとともに、障害発生の状況に見合った迅速な連絡や的確な復旧処置を行うことが可能になる。
【００４２】
実施の形態４．
本実施の形態においては、二重系が通常は片系でのみ動作しており、障害時に待機系に切り替えるよう構成された系において障害が発生したものとする。すなわち、図７の構成において、第一の系１００ｄが通常側の系で、第二の系１００ｅが待機系であるとする。全体の構成としては、図２に示したものと同様であるため、ここでは、図２を参照することとし、詳細な説明は省略する。図１０の本実施の形態における動作の流れを示す。
【００４３】
まずはじめに、受動処理機構部１０３の動作について図１０（ａ）を用いて説明する。この場合、通常側の第一の系１００ｄが障害を発生し障害通知を受動処理機構部１０３へ送信する（ステップＳ６１）。受動処理機構部１０３の条件判定処理部５では、蓄積部１０５に格納されている所定の判定条件を取り出して（ステップＳ６２）、当該条件に基づいて、蓄積部１０５に蓄積されているいままでの監視状況から、待機系である第二の系１００ｅからの障害通知が無いこと、あるいは、第二の系１００ｅからの正常通知が存在するかなどを検査し（ステップＳ６３）、待機系である第二の系１００ｅが正常であると判定した場合には、この情報を警告に変換してシステム監視部１０１へ送信すると共に、この情報を蓄積部１０５に蓄積する（ステップＳ６４）。同時に、待機系である第二の系１００ｅが正常に起動することを能動処理機構部１０４で検出するため、待機系である第二の系１００ｅの起動検査条件（例えば、最大限許容できる時刻など）を生成し、蓄積部１０５へ格納する（ステップＳ６５）。必要であれば、図２における自律制御部７を起動する。この時点で、警告はシステム監視部１０１の所定の処理を経て障害監視部１０２へ送られると共に、管理者は通常側の第一の系１００ｄが障害発生し待機系である第二の系１００ｅへの切り替えが発生することを認識できる。
【００４４】
次に、能動処理機構部１０４の動作について図１０（ｂ）を用いて説明する。このとき、もし、待機系である第二の系１００ｅが正しく起動しなかった場合には、能動処理機構部１０４の自律制御部７により状態判定処理部８が自律的に動作を開始し、先の待機系切り替え発生の起動検査条件を取り出して（ステップＳ７１）、当該起動検査条件に基づいて、定期的に（例えば、１分間隔で）待機系である第二の系１００ｅの状態条件の検査を行う（ステップＳ７２）。この後、最大限許容できる時刻を過ぎても待機系である第二の系１００ｅが起動しない場合、待機系である第二の系１００ｅに障害が発生したとみなしてシステム監視部１０１に対して障害を通知するとともに、通常側の第一の系１００ｄの警告状態を障害状態に変換して、障害監視部１０２へ障害通知を送信する（ステップＳ７３，Ｓ７４）。これらの通知はシステム監視部１０１の処理を経て障害状態を障害監視部１０２へ送り、結果的に管理者は業務に影響を及ぼす二重系全体の重大障害を正しく認識できる。
【００４５】
一方、待機系である第二の系１００ｅが正しく起動して起動完了通知を送信すれば（ステップＳ６１）、受動処理機構部１０３は二重系が正しく起動したことを条件情報テーブルの条件と状態情報の検査により検出し（Ｓ６２，Ｓ６３）、システム監視部１０１へ切り替えの完了を通知すると共に、この情報を蓄積部１０５に格納し、さらに、能動処理機構部１０４の起動検査条件をリセットする。これにより業務に影響なく二重系は動作を続けていること、および、先の警告により通常側の第一の系１００ｄの復旧が必要なことを管理者は正しく知ることができる。
【００４６】
以上のように、本実施の形態によれば、従来の運用監視システムでは困難だったような、業務における障害をより的確に通知できるだけでなく、多重系や複数の監視対象を統合する形で構成された系においても、従来の運用監視システムの機能を生かしたまま、より的確に障害状態を通知できるようになる。これにより、運用監視システムが通知する情報から、実際の業務に対する真の影響を、管理者自ら判断する必要を最小限に抑えるとともに、障害発生の状況に見合った迅速な連絡や的確な復旧処置を行うことが可能になる。
【００４７】
実施の形態５．
本実施の形態においては、上述の実施の形態３の変形例について説明する。本実施の形態における動作は、基本的に、図９と同じであるため、図９の流れ図を用いて説明する。
【００４８】
実施の形態３においては、図９（ａ）に示す受動処理機構１０３の処理のステップＳ４４において、異常通知があった場合には、条件を満たしていないと判断して、図８のように、状態条件テーブルの第一の系および第二の系の欄に「×」を入力するとともに、それらの結果から、被監視系１００Ａ全体の状態情報を「○」、「△」、「×」により入力するという例について説明したが、本実施の形態においては、当該ステップＳ４４の処理において、能動処理機構部１０４を併用することで、何も通知が来ない状態を検知し、その場合には、図１１に示すように、状態条件テーブルの第一の系および第二の系の欄に「−」を入力する。一方、異常通知があった場合には、条件を満たしていないと判断して、状態条件テーブルの第一の系および第二の系の欄に「×」を入力するとともに、それらの結果から、被監視系１００Ａ全体の状態情報を、２系とも正常の場合は「○」、片系が正常の場合は「△」、２系とも異常の場合は「×」、少なくともいずれか一方の系からの通知が何もない場合は「−」により入力する。また、必要に応じて、それと同時に、障害監視部１０２へ、２系とも正常の場合は正常動作通知として、片系が異常の場合は警告通知として、２系とも異常の場合は障害通知として、少なくともいずれか一方の系からの通知が何もない場合は、通信線または条件判定部５の異常か当該系の異常かのいずれの異常であるかを知らせる障害通知として、送信する（もちろん必要なければ正常動作通知は送信しなくとも良い。）。
【００４９】
本実施の形態においては、実施の形態３と同様の効果が得られるとともに、さらに、通知がない場合と障害が発生した場合とを区別して蓄積部１０５の状態条件テーブルに格納するようにしたので、管理者は、通知がない場合でも障害を認識することができる。
【００５０】
実施の形態６．
実施の形態２〜５においては監視対象システムを統括する機構として、被監視系１００Ａとシステム監視部１０１との間に、本発明の受動処理記憶部１０３と能動処理機構部１０４とを適用した例について説明したが、その場合に限らず、系が比較的単純な場合や、同様な構成の系が多数あり、各々に同一の処理を行いたいような場合は、図４のように、システム監視部１０１と障害監視部１０２との間に適用しても良く、また、図１のようにその両方に適用しても良い。
【００５１】
さらに、図１２のように蓄積部１０５を受動処理機構部１０３および能動処理機構部１０４から分離して外部に持たせたり、複数の監視対象システム１００で１組の受動処理機構部１０３および能動処理機構部１０４を共有する構成にしても良い。このような構成にすることで、異なるシステム監視部１０１の下にある監視対象システム１００同士を互いに連携させるような状態条件テーブルを作成することも可能になる。なお、図１２のように、蓄積部１０５を外部に持たせた場合においても、必要に応じて、個別に、受動処理機構部１０３および能動処理機構部１０４に対して蓄積部１０５ａを併設するようにしてもよい。
【００５２】
本実施の形態によれば、運用監視システムの本来の機能を生かしながらも、このように自由な適用ができることで、運用監視システム自体を構築する際にも柔軟な応用が可能である。
【００５３】
【発明の効果】
この発明は、監視対象システムの業務の運用状態を監視する業務運用監視システムであって、前記監視対象システムの業務の運用状態を示す業務運用監視情報が入力され、予め設定された所定の業務運用判定条件に基づいて、前記業務運用監視情報の検査を行い、当該検査の結果に基づいて、前記業務運用監視情報の蓄積を行う受動処理機構部と、予め設定された所定のスケジュールに従って、前記監視対象システムが業務に支障をきたさない状態を定義した状態条件と前記受動処理機構部により蓄積された前記業務運用監視情報とを比較して、正常動作であれば正常動作通知を生成して送信し、前記業務運用判定条件を満たしていないものの業務に支障をきたさない状態であれば警告通知を生成して送信し、業務に支障をきたす状態であれば障害通知を生成して送信する能動処理機構部と、前記受動処理機構部により蓄積される前記業務運用監視情報、前記業務運用判定条件および前記状態条件を格納する蓄積部とを備え、前記受動処理機構部は、前記監視対象システムの業務運用状態を示す業務運用監視情報が入力されたときに、前記業務運用判定条件に基づいて、前記監視情報の条件判定を行うとともに、前記監視情報の蓄積を行う条件判定処理部と、前記条件判定処理部からの指令に基づいて、前記業務運用監視情報をそのまま外部に出力することにより前記監視情報の中継処理を行う監視情報中継部と、前記条件判定処理部からの指令に基づいて、操作・再生成・再構成のいずれかの処理を前記監視情報に対して行った後に外部に出力する監視情報処理部とを備えていることを特徴とする業務運用監視システムであるので、単なるシステムの障害のみならず、システムは一応稼働してはいるものの“業務”に支障をきたす「業務に影響する障害」が発生した場合にも、それを的確に検出することができる。逆に今までは障害として通知されていたケースでも、実害がない場合は通知しないようフィルタリングすることができる。
【図面の簡単な説明】
【図１】 本発明の実施の形態１に係る運用監視システムの全体の構成を示した構成図である。
【図２】 本発明の実施の形態１に係る運用監視システムの構成を示した部分詳細構成図である。
【図３】 本発明の実施の形態１に係る運用監視システムの動作を示した流れ図である。
【図４】 本発明の実施の形態２に係る運用監視システムの全体の構成を示した構成図である。
【図５】 本発明の実施の形態２に係る運用監視システムにおける条件情報テーブルの一例を示した説明図である。
【図６】 本発明の実施の形態２に係る運用監視システムの動作を示した流れ図である。
【図７】 本発明の実施の形態３に係る運用監視システムの全体の構成を示した構成図である。
【図８】 本発明の実施の形態３に係る運用監視システムの条件情報テーブルの一例を示した説明図である。
【図９】 本発明の実施の形態３に係る運用監視システムの動作を示した流れ図である。
【図１０】 本発明の実施の形態４に係る運用監視システムの動作を示した流れ図である。
【図１１】 本発明の実施の形態５に係る運用監視システムの条件情報テーブルの一例を示した説明図である。
【図１２】 本発明の実施の形態６に係る運用監視システムの全体の構成を示した構成図である。
【符号の説明】
２ 監視情報出力部、３ 監視情報中継部、４ 監視情報操作・再構成・再生成処理部、５ 条件判定処理部、７ 自律制御部、８ 状態判定処理部、９ 監視情報生成部、１０ 監視情報入力部、１００ 監視対象システム、１００ａ，１００ｂ，１００ｃ 被監視局、１００ｄ 第一の系、１００ｅ 第二の系、１０１ システム監視部、１０２ 障害監視部、１０３ 受動処理機構部、１０４能動処理機構部、１０５ 蓄積部。
【発明の属する技術分野】
この発明は運用監視システムに関し、特に、監視対象に発生した障害を検出するための運用監視システムに関する。
【０００２】
【従来の技術】
従来の運用監視システムは、監視対象システムの稼動状態を「システムの障害」として検出し、管理者に通知することで障害監視を実現している。復合コンピュータの運行状況を一箇所で集中監視して得た各種のメッセージ群を、その優先度や内容に応じて滞りなく自動的に分類・ランク付けし、発生した異常への対処を誤りなく行う（例えば、特許文献１参照。）。
【０００３】
【特許文献１】
特開平１０−６３５３９号公報
【０００４】
当該特許文献１によれば、コンピュータの運用に重大な影響を与えるおそれのある事象についてのメッセージのみが自動的に選別・通報されるため、運用監視業務に従事するオペレータは、メッセージ群を取捨選択して、障害発生に関するメッセージを選び出す必要がなくなり、個々のメッセージの通報に即応して対策措置を開始することができる。また、選別されたメッセージは、所定の優先度ごとにランク付けされた順序で所定の通報先に通報されるので、緊急性のある事象への対処手順をより効率化することができる。
【０００５】
【発明が解決しようとする課題】
従来のシステムは上述のように構成されており、以下に挙げるような問題点があった。
【０００６】
第１の問題点として、こうした業務の視点の運用監視システムは主に「システムの障害」を通知することによって動作しており、「物理的に正常に動作しているシステム」が、処理遅延等の理由により、業務に支障を来すような事項については異常として検出されないのが現実である。従来のシステムで管理者（オペレータ）がこれを知るための方法としては、こうした処理の完了を通知させることにしておき、完了が通知されないシステムがあれば、それはまだ完了していないものだと管理者が理解するという方法がある。しかしながら、その方法では、膨大な監視情報の中から完了通知の無いシステムを管理者が見つけ出す必要がある。当然ながら、その作業は、あらかじめ知り得るシステムについての情報を元に、または、記憶をたよりに見つけ出す作業であるが、人間には「無いものを探す」行為は、それ自体非常に困難な作業である。また、すべての管理者が必ずしもすべてのシステムの存在を知り得る訳ではないため、そのような管理者にとって未知のシステムから通知が無い場合の問題を早期検出することはまず不可能であるという問題点があった。
【０００７】
第２の問題点として、非常に複雑な系で障害が発生した場合には、業務の視点による障害監視システムでさえも、その系の障害を、時として、障害監視システムのもつ所定の条件判定のみで「業務に影響する障害」と判定させることができない場合がある。このような例として、障害回避のために多重化・冗長化された系、特に独自の方法で複雑に多重化・冗長化された系や、複数システムで独自に構成した系を監視するような場合が挙げられる。このような系では、ある部分が障害を発生しても、系全体としては正常に動作を続けることができ、即座に業務に支障を及ぼすものではないような、業務の視点からは軽度とみなされる障害が発生し得るが、現在の監視システムではそれぞれのシステムを独立して個別に監視するか、系全体を単独のシステムとして監視する方法しかなく、監視システムはその複雑な系の動作状態を内部の所定の条件判定では適切に表現しきれない場合が生じ得る。その結果、監視システムは適切に業務への影響を通知することができなくなり、障害の実際の業務への影響を示す情報はその正確性・信頼性を失ってしまうという問題点があった。
【０００８】
この発明は、かかる問題点を解決するためになされたものであり、単なるシステムの障害のみならず、システムは一応稼働してはいるものの“業務”に支障をきたす「業務に影響する障害」が発生した場合にも、それを的確に検出することができる業務運用監視システムを得ることを目的とする。
【０００９】
【課題を解決するための手段】
この発明は、監視対象システムの業務の運用状態を監視する業務運用監視システムであって、前記監視対象システムの業務の運用状態を示す業務運用監視情報が入力され、予め設定された所定の業務運用判定条件に基づいて、前記業務運用監視情報の検査を行い、当該検査の結果に基づいて、前記業務運用監視情報の蓄積を行う受動処理機構部と、予め設定された所定のスケジュールに従って、前記監視対象システムが業務に支障をきたさない状態を定義した状態条件と前記受動処理機構部により蓄積された前記業務運用監視情報とを比較して、正常動作であれば正常動作通知を生成して送信し、前記業務運用判定条件を満たしていないものの業務に支障をきたさない状態であれば警告通知を生成して送信し、業務に支障をきたす状態であれば障害通知を生成して送信する能動処理機構部と、前記受動処理機構部により蓄積される前記業務運用監視情報、前記業務運用判定条件および前記状態条件を格納する蓄積部とを備え、前記受動処理機構部は、前記監視対象システムの業務運用状態を示す業務運用監視情報が入力されたときに、前記業務運用判定条件に基づいて、前記監視情報の条件判定を行うとともに、前記監視情報の蓄積を行う条件判定処理部と、前記条件判定処理部からの指令に基づいて、前記業務運用監視情報をそのまま外部に出力することにより前記監視情報の中継処理を行う監視情報中継部と、前記条件判定処理部からの指令に基づいて、操作・再生成・再構成のいずれかの処理を前記監視情報に対して行った後に外部に出力する監視情報処理部とを備えていることを特徴とする業務運用監視システムである。
【００１０】
また、前記受動処理機構部は、前記監視対象システムの業務運用状態を示す業務運用監視情報が入力されたときに、前記業務運用判定条件に基づいて、前記監視情報の条件判定を行うとともに、前記監視情報の蓄積を行う条件判定処理部と、前記条件判定処理部からの指令に基づいて、前記業務運用監視情報をそのまま外部に出力することにより前記監視情報の中継処理を行う監視情報中継部と、前記条件判定処理部からの指令に基づいて、操作・再生成・再構成のいずれかの処理を前記監視情報に対して行った後に外部に出力する監視情報処理部とを備えている。
【００１１】
また、前記能動処理機構部は、前記スケジュールに従って起動信号を出力する自律制御部と、前記監視対象システムが業務に支障をきたさない状態を定義した前記状態条件と前記受動処理機構部により蓄積された前記業務運用監視情報とを比較することで、前記監視対象システムの状態判定を行う状態判定処理部と、当該状態判定結果に基づいて通知情報を生成して送信する監視情報生成部とを備えている。
【００１２】
【発明の実施の形態】
実施の形態１．
本発明の運用監視システムについて、図１〜図３を用いて説明する。図１は、本発明の運用監視システムの構成を示した概略構成図である。図１において、１００は監視対象である監視対象システムであり、１０１は監視対象システム１００の運用および監視を行うシステム監視部、１０２は、システム監視部１０１からの情報に基づいて、監視対象システム１００における障害発生を監視する障害監視部である。
【００１３】
本発明による運用監視システムは、これらの監視対象システム１００とシステム監視部１０１との間、および、システム監視部１０１と障害監視部１０２との間に、図１に示すように、それらの間で通知される監視情報の受信により動作を開始し、所定の条件に従って、当該監視情報を操作したり蓄積したり、あるいは、単に中継する受動処理機構１０３と、自律的制御により動作を開始し、受動処理機構１０３によって蓄積された情報および予め蓄積された所定の条件に従って状態条件判定を行って新しい監視情報を生成する能動処理機構１０４と、状態条件と状態監視に必要な情報を保存しておくための蓄積部１０５とを、それぞれ設けている。各部は独立したシステムでも、統合されたシステムでも構わない。また、監視情報が送信されるシステム間であればどこに適用しても良く、監視対象システム内の機能として適用しても良い。
【００１４】
また、ここで説明する運用監視システムでは、システムの障害状態は障害通知によって管理者へ報告され、業務に影響の無いシステムの問題は警告通知によって管理者へ報告する例を挙げて説明する。
【００１５】
詳細を、図２により説明する。図２において、図１と同じ構成については同一符号を付して示し、ここでは説明を省略する。図２は、図１におけるシステム監視部１０１と障害監視部１０２との間（あるいは、監視対象システム１００とシステム監視部１０１との間）の部分を示したものである。但し、図２においては、図１で図示を省略した、監視情報出力部２と監視情報入力部１０とが記載されている。すなわち、監視情報を受動処理機構１０３で処理しやすくするため、受動処理機構１０３の前後に、監視情報を受け取って条件判定を容易にするために分解処理を行う監視情報入力部１０と、処理用のデータを再統合処理するための監視情報出力部２とが設けられている。
【００１６】
また、図２に示すように、受動処理機構部１０３は、監視情報入力部１０により分解処理されたデータを用いて条件判定処理を行うとともに、監視情報の蓄積を行う条件判定処理部５と、条件判定処理部５の指令により監視情報についての単なる中継処理を行う監視情報中継部３と、条件判定処理部５の指令に基づいて監視情報を操作・再構成・再生成する処理を行う操作・再構成・再生成処理部４とを備える。
【００１７】
一方、能動処理機構部１０４は、ＯＳのスケジュール機能や従来の運用監視ツールに備えられたスケジュール機能、または、後述の状態判定処理部８の起動を連続的・周期的に繰り返すような専用のプログラムによって実現される自律制御部７と、自律制御部７によって起動され、システムがその時点であるべき状態（業務に支障をきたさない状態）にあるかどうか、システムの状態をあらかじめ設定された状態条件テーブルと比較することで状態判定を行う状態判定処理部８と、状態判定に基づいて障害情報や警告情報が必要な際にその旨を示す監視情報を生成する監視情報生成部９とを備える。
【００１８】
動作について説明する。まず、初期設定として、監視対象システム１００のあるべき状態（正常な状態）を定義する設定条件を設定した状態条件テーブルと、監視対象システム１００の状態を示す監視情報から得られた条件判断に必要な状態情報を、あらかじめ蓄積部１０５に保存しておく。ここで、あるべき状態（正常な状態）とは、「業務に影響する障害」が全く発生していない状態をいう。
【００１９】
図３は、受動処理機構部１０３および能動処理機構部１０４の動作を示した流れ図である。まず、図２および図３（ａ）に基づいて、受動処理機構部１０３について詳しく説明する。監視情報が、システム監視部１０１から障害監視部１０２へ向けて送信される場合、まず、監視情報は監視情報入力部１０により受け取られた後、受動処理機構部１０３の条件判定処理部５へ送られる（ステップＳ１）。これを受け取った条件判定処理部５は、これを解析する操作として、蓄積部１０５に保存された状態条件テーブルの条件情報を取り出し（ステップＳ２）、当該条件情報に基づいて、受け取った監視情報と以前に蓄積された状態情報とを含め、その時点でシステムのあるべき条件を項目ごとに比較し、蓄積された監視情報同士の関係やそれぞれのあるべき条件を判定する（ステップＳ３）。比較すべき関連条件項目が無いか、あるいは、中継条件項目が満たされた場合は、条件判定処理部５は、監視情報中継部３へ中継処理を指示し、一方、操作・再構成・再生成処理条件項目が満たされた場合は、監視情報操作・再構成・再生成処理部４へそれぞれの処理を指示する。このとき、監視情報中継部３は監視情報を監視情報出力部２へ送信する中継処理を行い（ステップＳ４）、一方、監視情報操作・再構成・再生成処理部４は、監視情報に対し業務に影響の無い障害情報を警告情報に変換する処理と、一つの障害発生が他の障害に繋がる場合に複数の障害通知を生成する処理と、監視情報により新たな障害状態が発生すると同時に、警告状態の発生・解除なども同時に起こるような複雑な場合の再構成処理などを行う（ステップＳ５）。その後、条件判定処理部５は条件テーブルの設定に基づいて他の条件判断に必要な監視情報を蓄積部１０５へ保存する（ステップＳ６）。なお、ステップＳ３において、監視情報が予め設定された所定の条件を満たした場合には、条件テーブルの設定に基づいて、能動処理機構１０４の自律制御部７を起動させて、能動処理を開始するようにしてもよい（ステップＳ７）。また、ステップＳ７の処理と同時に、先に指示された監視情報は監視情報出力部２を経由して本来の受信先である障害監視部１０２へ送信される（ステップＳ８）。ここまでの受動処理機構１０３の動作により、入力される監視情報についての情報をより適切に運用監視システム上で拡張できる。なお、監視対象システム１００からシステム監視部１０１に監視情報が送信される場合も同様である。
【００２０】
次に、図２および図３（ａ）に基づいて、能動処理機構１０４が動作する場合について詳しく説明する。上述の受動動作は、監視情報が受動処理機構１０３へ入力されて初めて動作を開始したが、能動処理機構１０４は、機構内部または外部に設けられた自律制御部７によって起動され、状態判定処理部８が処理を実行する。ここで、自律制御部７はＯＳのスケジュール機能や従来の運用監視ツールに備えられたスケジュール機能、または条件判定部の起動を連続的、周期的に繰り返すような専用のプログラムによって実現されるものであり、具体的には、経過時間を計測し、予め定められた所定の時間が経過すると、所定の信号を状態判定処理部８に出力し、それにより、状態判定処理部８の動作を開始させるものである。
【００２１】
このようにして、自律制御部７が状態判定処理部８を起動させると、状態判定処理部８は、蓄積部１０５に保存された状態条件テーブルの状態条件情報を取り出し（ステップＳ１０）、蓄積部１０５に保存された状態条件テーブルと、現在のシステムの状態を表す監視情報とを用いて、ある時点で、監視対象システム１００が「本来あるべき状態（正常な状態）」にあるかを、設定された条件情報テーブルの能動条件が含まれるすべての項目について、項目ごとに比較や論理条件判定を行って状態判断を行い、障害状態や警告すべき状況の検出を行う（ステップＳ１１）。この処理によって通知の必要な状態が検出されると、監視情報生成部９を用いて、監視情報出力部２、監視情報入力部１０および受動処理機構内の条件判定処理部５のいずれかに対して、監視情報を各経路から送信する。監視情報生成部９は、条件判定処理部５の指定に基づいて、必要な監視情報を生成し（ステップＳ１２）、最も適切な経路に対し、指定の監視情報を送信する（ステップＳ１３）。具体的には、下位監視部または監視対象から監視情報が送信されたものとして扱いたい場合は監視情報入力部１０へ、また、最終的な生成処理を受動処理機構部１０３に任せ直接受動処理を起動したい場合には受動処理機構部１０３の条件判定処理部５へ、あるいは、直接上位の監視部へ送りたい場合には監視情報出力部２へと、それぞれの経路で送信する。各部に送信された後の監視情報は、受動処理の場合と同じく各部所定の処理が行われる。
【００２２】
以上のように、本実施の形態においては、１つまたは複数の計算機で構成されたシステムの状態を監視する「運用監視システム」において、「監視対象システム」、「システム監視部」と「業務障害監視部」との間で通知される監視情報（メッセージ）を、所定の条件に従って操作・蓄積・再生成・再構成するか、あるいは、単に中継する受動処理機構と、自律的制御により動作し、受動処理機構によって蓄積された情報、および、あらかじめ蓄積された所定の条件によって状態条件判定を行って新しい監視情報を生成する能動処理機構とを設け、これらの機構の組み合わせにより、システムの状態が業務に及ぼす影響を明確にするようにして、システムの障害の発生を検出するようにしたので、ある時点においては「物理的に正常な稼動状態にあるシステム」においても、処理遅延などの理由により業務上障害となりうる状態を検出したり、業務障害監視部の判定可能な範囲を超えるような複雑な系の障害が業務に与える影響をも適切に検出することができる。これにより、運用監視システムが通知する情報から、実際の業務に対する真の影響を、管理者自ら判断する負荷を最小限に抑えるとともに、障害発生の状況に見合った迅速な連絡や的確な復旧処置を行うことが可能になる。
【００２３】
実施の形態２．
以下の実施の形態においては、監視対象システム１００の具体的な例を挙げて、本発明の運用監視システムを適用した場合について説明する。本実施の形態においては、例えば、種々の商業用システムのように、営業時間帯には通常の業務運用を行い、営業時間終了後にバッチ処理を行うようなシステムの設置局があり、この種のシステムを本発明の運用監視システムにおいて監視する例について考える。
【００２４】
このようなシステムの設置局（以下、被監視局と呼ぶ。）は正常に閉局すれば問題ないが、何らかの事情により閉局すべき時刻を大幅に過ぎて閉局した場合、夜間のバッチ処理の遅れにより業務上支障が生じ得る。すなわち、万一バッチ処理を完了できない場合には、翌営業開始時間にシステムの通常運用が再開できないため、業務に支障をきたす。
【００２５】
このようなシステムでは、閉局時刻に被監視局が閉局通知を運用監視システムに送信するように構成すれば、管理者は閉局した被監視局を知ることができるが、障害ではないメッセージを監視しなければならないので、管理者の負荷となる。
【００２６】
そこで、このシステムに図４のように本発明の受動処理機構部１０３および能動処理機構１０４を加えた構成にする。すなわち、被監視局（Ａ）１００ａ，被監視局（Ｂ）１００ｂ，被監視局（Ｃ）１００ｃを監視運用する監視局２００には、障害監視部１０２、システム監視部１０１、および、その中間に本発明による受動処理機構部１０３および能動処理機構部１０４を設けることによって、受動処理機構部１０３によって閉局通知（監視情報）を各被監視局１００ａ〜１００ｃから受信し、それを各監視局の状態情報として蓄積部１０５に格納するとともに、当該蓄積部１０５に蓄積された情報を基に、閉局状況検査を能動処理機構１０４によって連続的および定期的に実行することによって追跡監視を行えるようになる。受動処理機構部１０３および能動処理機構部１０４の内部の構成については、図２に示したものと同様であるので、ここでは図２を参照するものとし、詳細な説明については省略する。なお、以下の説明の期間において、被監視局（Ｂ）１００ｂの物理的なシステムからの障害は検出されないものとする。
【００２７】
図４のシステムについて説明する。当該システムにおいては、
（１）１７：００ 閉局チェック開始
（２）１８：００ 閉局期限
と設定されており、
例として、１７：０１に被監視局１００ａが閉局し、１７：０２に被監視局１００ｃが閉局したが、閉局期限の１８：００を過ぎても、被監視局１００ｂからの閉局通知が送信されてこなかったという状況を仮定して、以下、説明する。
【００２８】
いま、被監視局（Ａ）１００ａ，（Ｂ）１００ｂ，（Ｃ）１００ｃのあるべき状態（正常な状態）を定義する条件が、既に、蓄積部１０５の状態条件テーブルに保存されており、システム監視部１０１が受信した監視情報から得られた条件判断に必要な状態情報が、受信された順に、徐々に、蓄積部１０５の状態条件テーブルに保存されていっている状態である。図５（ａ）に、状態条件テーブルの一例を示す。本実施の形態においては、状態条件テーブルにおけるあるべき状態を定義する条件として、「１７：００〜１８：００の間に閉局」という条件が設定されており、当該テーブルにおけるフラグは、監視対象システムが当該条件を満たしているか否かを示すものであり、満たした時点で「レ」が記載される。従って、このフラグが、本実施の形態における監視情報から得られた条件判断に必要な状態情報となっている。
【００２９】
図６に本実施の形態による運用監視システムの動作の流れを示す。まず、図２および図６（ａ）に基づいて、本発明の受動処理機構の動作について説明する。図４に示す監視局２００で、３つの被監視局（Ａ）１００ａ、被監視局（Ｂ）１００ｂおよび被監視局（Ｃ）１００ｃを監視する場合、被監視局（Ａ）１００ａおよび被監視局（Ｃ）１００ｃが適切な時間に閉局通知（監視情報）を送信すると、システム監視部１０１がこれを受け取り、受動処理機構部１０３へ送る（ステップＳ２１）。受動処理機構部１０３では、条件判定処理部５が、「１７：００〜１８：００の間に閉局」という所定の判定条件を蓄積部１０５から取り出し（ステップＳ２２）、受信した閉局通知が、当該所定の判定条件を満たすか否かを検査し（ステップＳ２３）、条件を満たしていた場合には、図５（ｂ）のように、状態条件テーブルのフラグの欄にフラグを立てることにより、当該閉局通知の内容を、能動処理機構１０４の追跡用に、蓄積部１０５に蓄積する（ステップＳ２４）。また、必要に応じて、それと同時に、障害監視部１０２へ正常閉局通知として送信する（もちろん必要なければ正常通知は送信しなくとも良い。）。
【００３０】
次に、図２および図６（ｂ）を用いて、能動処理機構部１０４の動作について説明する。能動処理機構部１０４は、自律制御部７の働きによって、適当な時刻に起動し（本実施の形態では、１回目の起動が１７：００になった時点で、以下、５分間隔に繰り返し起動）、状態判定処理部８は、蓄積部１０５から状態条件テーブルの内容を取り出し（ステップＳ３１）、当該状態条件テーブルにおける判定条件と蓄積された状態情報とを比較して閉局通知を検査する（ステップＳ３２）。なお、本実施の形態においては、受動処理機構部１０３が用いる判定条件と、能動処理機構部１０４が用いる状態条件とは、同じ条件となっているが、これに限らず、異なる条件としてもよい。この時点で、状態条件テーブルの状態情報を示すフラグにより、被監視局（Ａ），（Ｂ），（Ｃ）の正常通知の有無を確認するが、１７：００の時点においては、図５（ａ）のように、いずれにもフラグはたっていない。一方、２回目の起動における１７：０５の時点では、図５（ｂ）に示す状態条件テーブルのフラグにより、被監視局（Ａ）１００ａおよび被監視局（Ｃ）１００ｃの正常な閉局通知を確認するが、同時に被監視局（Ｂ）１００ｂの通知が無いことも検出できる。このようにして、一定の時間内（本実施の形態においては１７：００〜１８：００）に閉局通知が生成されるか否かを確認する場合は、例えば、能動処理機構１０４が、閉局時刻の期限（１８：００）以前の所定の時刻（１７：００）から起動し始め、以下、所定の時間間隔（５分間隔）で繰り返し起動して、起動の度に閉局通知が生成されていない被監視局があった場合には、状態判定処理部８が、監視情報生成部９に警告メッセージを発するように指示するように設定しておいてもよいが、むやみに警告を出すよりも最初の３０分程度は警告を発さずに様子を見ていた方が望ましいので、例えば、予め設定した所定の回数目の起動（例えば、１７：３０の７回目の起動）において、閉局通知が生成されていない監視局があった場合には、状態判定処理部８が、監視情報生成部９に警告メッセージを発するように指示するように設定しておいてもよい。このようにして監視対象システムは正常でも、その動作が業務に影響を与える障害状態となりうるものと検出して、必要な監視情報（ここでは警告通知）を生成して（ステップＳ３３）、当該警告通知を障害監視部１０２へ通知する（ステップＳ３４）。さらに、最大許容時間（１８：００）まで定期的に（例えば、５分間隔で）検査を繰り返すことによって追跡し、その期間内に閉局通知が無ければ、これを最終的に障害として通知すれば、管理者は障害が発生したものとして対応を開始することができる。
【００３１】
以上のように、本実施の形態によれば、従来の運用監視システムでは困難だったような、業務における障害をより的確に通知できるだけでなく、多重系や複数の監視対象を統合する形で構成された系においても、本来の運用監視システムの機能を生かしたまま、より的確に障害状態を通知できるようになる。これにより、運用監視システムが通知する情報から、実際の業務に対する真の影響を、管理者自ら判断する必要を最小限に抑えるとともに、障害発生の状況に見合った迅速な連絡や的確な復旧処置を行うことが可能になる。
【００３２】
実施の形態３．
本実施の形態においては、監視対象システムとして、障害回避のために多重化・冗長化された系を例に挙げて説明する。この種の系として、ここでは、二重化によって同一の機能を持つ２つのシステムが常に同期して動作しており、片方の系が障害を発生しても、全体としては正常に動作を続けることができる系、および、二重化されているが通常は片方のシステムのみ動作しており、障害発生時には待機していたもう一方の系（待機系）に切り替えて動作する系の２種類の系を考える。
【００３３】
こうした系においては、前者では片系が障害により停止しても、他系が代わりに処理を行うので、必要な処理自体は正常に継続できるため、即座に業務に障害を与えることはない。また、後者の例ではどちらかのシステムが動作していればよく、障害が発生して片方のシステムがダウンしても待機系が正常に動作を開始すれば業務に支障は出ないが、その一方の問題として、障害発生により待機系へ切り替える際に、万一、待機系が正常に起動しなかった場合には、重大な事態となってしまうということが考えられる。
【００３４】
図７のように、監視対象システム１００である被監視系１００Ａが、第一の系１００ｄと第二の系１００ｅとから構成された二重系のシステムを監視する場合にも、本発明においては、被監視系１００Ａとシステム監視部１０１との間に、受動処理機構部１０３と能動処理機構部１０４とを適用することによって、システム監視部、監視対象システムをほとんど変更することなく、従来のシステムにおいては実現できなかったような障害を検出できるようになる。
【００３５】
ここでは、まず、同期して動作する二重系の片系で障害が発生したものとする。図７の被監視系１００Ａについて説明する。当該被監視系においては、
（１）被監視系から１０分おきに正常通知を受信
（２）１分おきに状態チェック
と設定されており、
例として、１７：００の時点では第一の系１００ｄおよび第二の系１００ｅの両方が共に正常に動作しており、１８：００に第一の系１００ｄに異常が発生してダウンし、１９：００に第二の系１００ｅにも異常が発生してダウンしたという状況を仮定して、以下、説明する。
【００３６】
まず、被監視系１００Ａのあるべき状態（正常な状態）を定義する条件と、監視情報から得られた条件判断に必要な状態情報とを、あらかじめ蓄積部１０５の状態条件テーブルに保存しておく。図８に、状態条件テーブルの一例を示す。本実施の形態においては、状態条件テーブルにおけるあるべき状態を定義する条件として、「２系とも正常」という条件が設定されており、当該テーブルにおける状態情報は、被監視系１００Ａが当該条件を満たしているか否かを示すものであり、「○」が２系とも正常、「△」が片系が異常、「×」が２系とも異常を意味する。「△」のときに、警告メッセージが発せられ、「×」のときに障害通知がなされることとする。本実施の形態においては、これらの「○」、「△」、「×」が、監視情報から得られた条件判断に必要な状態情報となっている。なお、第一の系および第二の系における「○」および「×」は、各時刻における「正常」および「異常」を意味する監視情報である。
【００３７】
図９に本実施の形態による運用監視システムの動作の流れを示す。まず、図２および図９（ａ）に基づいて、本発明の受動処理機構の動作について説明する。図７に示す被監視系１００Ａで、２つの系１００ｄおよび１００ｅを監視する場合、第一の系１００ｄおよび第二の系１００ｅが適切な時間に正常通知（監視情報）を送信すると、システム監視部１０１が、これを受け取り、受動処理機構１０３へ送る（ステップＳ４１）。受動処理機構１０３では、条件判定処理部５が、「正常動作」という所定の判定条件を蓄積部１０５から取り出し（ステップＳ４２）、受信した正常通知が、当該所定の判定条件を満たすか否かを検査し（ステップＳ４３）、条件を満たしていた場合には、図８のように、状態条件テーブルの第一の系および第二の系の欄に「○」を入力することにより、当該正常通知の内容を、能動処理機構１０４の追跡用に、蓄積部１０５に蓄積する（ステップＳ４４）。ここで、異常通知があった場合には、条件を満たしていないと判断して、図８のように、状態条件テーブルの第一の系および第二の系の欄に「×」を入力するとともに、それらの結果から、被監視系１００Ａ全体の状態情報を「○」、「△」、「×」により入力する。また、必要に応じて、それと同時に、障害監視部１０２へ、２系とも正常の場合は正常動作通知として、片系が異常の場合は警告通知として、２系とも異常の場合は障害通知として送信する（もちろん必要なければ正常動作通知は送信しなくとも良い。）。
【００３８】
次に、図２および図９（ｂ）を用いて、能動処理機構部１０４の動作について説明する。能動処理機構部１０４は、自律制御部７の働きによって、適当な時間間隔で起動し（本実施の形態では、１０分おきに起動）、状態判定処理部８は、蓄積部１０５から状態条件テーブルの内容を取り出し（ステップＳ５１）、当該状態条件テーブルにおける判定条件と蓄積された状態情報とを比較して正常動作通知を検査する（ステップＳ５２）。この時点で、状態条件テーブルの状態情報を示す「○」、「△」、「×」により、被監視系１００Ａの正常通知の有無を確認するが、１７：００の時点においては、図８のように、正常状態である。一方、１８：００の時点では、第一の系１００ｄがダウンしていて、第二の系１００ｅは正常動作していることも検出できる。このときには、被監視系１００Ａは、いずれかの系が正常動作していれば、支障をきたさないので、被監視系１００Ａとしては正常動作である。しかしながら、この時点で警告メッセージを出しておけば、管理者は万一に備えて適切な処理を行うことができる。１９：００の時点では、第一の系１００ｄがダウンしていて、第二の系１００ｅもダウンしていることが検出できる。このときにはじめて、被監視系１００Ａは障害発生となる。このように、被監視系１００Ａは正常でも、片系に異常が発生した時点で、動作が業務に影響を与える障害状態となりうるものと検出して、必要な監視情報（ここでは警告通知）を生成して（ステップＳ５３）、当該警告通知を監視情報出力部２を介して障害監視部１０２へ通知する（ステップＳ５４）。さらに、所定間隔で検査を繰り返すことによって追跡し、２系ともにダウンした場合に、これを最終的に障害として通知すれば、管理者は障害が発生したものとして対応を開始することができる。
【００３９】
以上のように、受動処理機構部１０４は被監視系１００Ａの片系からの障害通知を受け取るが、蓄積部１０５にあらかじめ設定された条件情報テーブルと、この時点までの機構の動作により蓄積された状態情報に対して比較および条件判定を行うことによって、もう一方の系が障害通知を生成していないか、もしくは、正常通知を生成していることなどを検出できる。これによりシステム全体では障害状態に無いものと判断できるので、この障害通知は業務には支障の無い障害の発生として警告通知に変換し、システム監視部１０１へ送信するのが適切である。 監視情報はシステム監視部１０１が所定の処理を行った後、最終的に障害監視部１０２へ送信され、管理者には業務に支障の無い警告通知として正しく識別される。
【００４０】
一方、正常に動作していたもう片方の系でも障害が発生したときには、受動処理機構部１０３は被監視系１００Ａから先ほどと同様に障害通知を受け取るが、ここでは前回の片系の障害状態が既に蓄積されており、このデータと条件情報テーブルの検査から二重系全体が動作を継続できない障害、すなわち、業務に影響のある障害であることが検出できる。これによりこの障害通知を中継してシステム監視部１０１へ送信すると共に、もう片系の警告状態を障害状態に変更し新しく通知する。その結果、システム監視部１０１の処理を経て最終的に二重系全体で障害が発生しているものと通知されることにより、管理者には業務に障害を発生し得る重大障害として正しく識別される。
【００４１】
以上のように、本実施の形態によれば、従来の運用監視システムでは困難だったような、業務における障害をより的確に通知できるだけでなく、多重系や複数の監視対象を統合する形で構成された系においても、従来の運用監視システムの機能を生かしたまま、より的確に障害状態を通知できるようになる。これにより、運用監視システムが通知する情報から、実際の業務に対する真の影響を、管理者自ら判断する必要を最小限に抑えるとともに、障害発生の状況に見合った迅速な連絡や的確な復旧処置を行うことが可能になる。
【００４２】
実施の形態４．
本実施の形態においては、二重系が通常は片系でのみ動作しており、障害時に待機系に切り替えるよう構成された系において障害が発生したものとする。すなわち、図７の構成において、第一の系１００ｄが通常側の系で、第二の系１００ｅが待機系であるとする。全体の構成としては、図２に示したものと同様であるため、ここでは、図２を参照することとし、詳細な説明は省略する。図１０の本実施の形態における動作の流れを示す。
【００４３】
まずはじめに、受動処理機構部１０３の動作について図１０（ａ）を用いて説明する。この場合、通常側の第一の系１００ｄが障害を発生し障害通知を受動処理機構部１０３へ送信する（ステップＳ６１）。受動処理機構部１０３の条件判定処理部５では、蓄積部１０５に格納されている所定の判定条件を取り出して（ステップＳ６２）、当該条件に基づいて、蓄積部１０５に蓄積されているいままでの監視状況から、待機系である第二の系１００ｅからの障害通知が無いこと、あるいは、第二の系１００ｅからの正常通知が存在するかなどを検査し（ステップＳ６３）、待機系である第二の系１００ｅが正常であると判定した場合には、この情報を警告に変換してシステム監視部１０１へ送信すると共に、この情報を蓄積部１０５に蓄積する（ステップＳ６４）。同時に、待機系である第二の系１００ｅが正常に起動することを能動処理機構部１０４で検出するため、待機系である第二の系１００ｅの起動検査条件（例えば、最大限許容できる時刻など）を生成し、蓄積部１０５へ格納する（ステップＳ６５）。必要であれば、図２における自律制御部７を起動する。この時点で、警告はシステム監視部１０１の所定の処理を経て障害監視部１０２へ送られると共に、管理者は通常側の第一の系１００ｄが障害発生し待機系である第二の系１００ｅへの切り替えが発生することを認識できる。
【００４４】
次に、能動処理機構部１０４の動作について図１０（ｂ）を用いて説明する。このとき、もし、待機系である第二の系１００ｅが正しく起動しなかった場合には、能動処理機構部１０４の自律制御部７により状態判定処理部８が自律的に動作を開始し、先の待機系切り替え発生の起動検査条件を取り出して（ステップＳ７１）、当該起動検査条件に基づいて、定期的に（例えば、１分間隔で）待機系である第二の系１００ｅの状態条件の検査を行う（ステップＳ７２）。この後、最大限許容できる時刻を過ぎても待機系である第二の系１００ｅが起動しない場合、待機系である第二の系１００ｅに障害が発生したとみなしてシステム監視部１０１に対して障害を通知するとともに、通常側の第一の系１００ｄの警告状態を障害状態に変換して、障害監視部１０２へ障害通知を送信する（ステップＳ７３，Ｓ７４）。これらの通知はシステム監視部１０１の処理を経て障害状態を障害監視部１０２へ送り、結果的に管理者は業務に影響を及ぼす二重系全体の重大障害を正しく認識できる。
【００４５】
一方、待機系である第二の系１００ｅが正しく起動して起動完了通知を送信すれば（ステップＳ６１）、受動処理機構部１０３は二重系が正しく起動したことを条件情報テーブルの条件と状態情報の検査により検出し（Ｓ６２，Ｓ６３）、システム監視部１０１へ切り替えの完了を通知すると共に、この情報を蓄積部１０５に格納し、さらに、能動処理機構部１０４の起動検査条件をリセットする。これにより業務に影響なく二重系は動作を続けていること、および、先の警告により通常側の第一の系１００ｄの復旧が必要なことを管理者は正しく知ることができる。
【００４６】
以上のように、本実施の形態によれば、従来の運用監視システムでは困難だったような、業務における障害をより的確に通知できるだけでなく、多重系や複数の監視対象を統合する形で構成された系においても、従来の運用監視システムの機能を生かしたまま、より的確に障害状態を通知できるようになる。これにより、運用監視システムが通知する情報から、実際の業務に対する真の影響を、管理者自ら判断する必要を最小限に抑えるとともに、障害発生の状況に見合った迅速な連絡や的確な復旧処置を行うことが可能になる。
【００４７】
実施の形態５．
本実施の形態においては、上述の実施の形態３の変形例について説明する。本実施の形態における動作は、基本的に、図９と同じであるため、図９の流れ図を用いて説明する。
【００４８】
実施の形態３においては、図９（ａ）に示す受動処理機構１０３の処理のステップＳ４４において、異常通知があった場合には、条件を満たしていないと判断して、図８のように、状態条件テーブルの第一の系および第二の系の欄に「×」を入力するとともに、それらの結果から、被監視系１００Ａ全体の状態情報を「○」、「△」、「×」により入力するという例について説明したが、本実施の形態においては、当該ステップＳ４４の処理において、能動処理機構部１０４を併用することで、何も通知が来ない状態を検知し、その場合には、図１１に示すように、状態条件テーブルの第一の系および第二の系の欄に「−」を入力する。一方、異常通知があった場合には、条件を満たしていないと判断して、状態条件テーブルの第一の系および第二の系の欄に「×」を入力するとともに、それらの結果から、被監視系１００Ａ全体の状態情報を、２系とも正常の場合は「○」、片系が正常の場合は「△」、２系とも異常の場合は「×」、少なくともいずれか一方の系からの通知が何もない場合は「−」により入力する。また、必要に応じて、それと同時に、障害監視部１０２へ、２系とも正常の場合は正常動作通知として、片系が異常の場合は警告通知として、２系とも異常の場合は障害通知として、少なくともいずれか一方の系からの通知が何もない場合は、通信線または条件判定部５の異常か当該系の異常かのいずれの異常であるかを知らせる障害通知として、送信する（もちろん必要なければ正常動作通知は送信しなくとも良い。）。
【００４９】
本実施の形態においては、実施の形態３と同様の効果が得られるとともに、さらに、通知がない場合と障害が発生した場合とを区別して蓄積部１０５の状態条件テーブルに格納するようにしたので、管理者は、通知がない場合でも障害を認識することができる。
【００５０】
実施の形態６．
実施の形態２〜５においては監視対象システムを統括する機構として、被監視系１００Ａとシステム監視部１０１との間に、本発明の受動処理記憶部１０３と能動処理機構部１０４とを適用した例について説明したが、その場合に限らず、系が比較的単純な場合や、同様な構成の系が多数あり、各々に同一の処理を行いたいような場合は、図４のように、システム監視部１０１と障害監視部１０２との間に適用しても良く、また、図１のようにその両方に適用しても良い。
【００５１】
さらに、図１２のように蓄積部１０５を受動処理機構部１０３および能動処理機構部１０４から分離して外部に持たせたり、複数の監視対象システム１００で１組の受動処理機構部１０３および能動処理機構部１０４を共有する構成にしても良い。このような構成にすることで、異なるシステム監視部１０１の下にある監視対象システム１００同士を互いに連携させるような状態条件テーブルを作成することも可能になる。なお、図１２のように、蓄積部１０５を外部に持たせた場合においても、必要に応じて、個別に、受動処理機構部１０３および能動処理機構部１０４に対して蓄積部１０５ａを併設するようにしてもよい。
【００５２】
本実施の形態によれば、運用監視システムの本来の機能を生かしながらも、このように自由な適用ができることで、運用監視システム自体を構築する際にも柔軟な応用が可能である。
【００５３】
【発明の効果】
この発明は、監視対象システムの業務の運用状態を監視する業務運用監視システムであって、前記監視対象システムの業務の運用状態を示す業務運用監視情報が入力され、予め設定された所定の業務運用判定条件に基づいて、前記業務運用監視情報の検査を行い、当該検査の結果に基づいて、前記業務運用監視情報の蓄積を行う受動処理機構部と、予め設定された所定のスケジュールに従って、前記監視対象システムが業務に支障をきたさない状態を定義した状態条件と前記受動処理機構部により蓄積された前記業務運用監視情報とを比較して、正常動作であれば正常動作通知を生成して送信し、前記業務運用判定条件を満たしていないものの業務に支障をきたさない状態であれば警告通知を生成して送信し、業務に支障をきたす状態であれば障害通知を生成して送信する能動処理機構部と、前記受動処理機構部により蓄積される前記業務運用監視情報、前記業務運用判定条件および前記状態条件を格納する蓄積部とを備え、前記受動処理機構部は、前記監視対象システムの業務運用状態を示す業務運用監視情報が入力されたときに、前記業務運用判定条件に基づいて、前記監視情報の条件判定を行うとともに、前記監視情報の蓄積を行う条件判定処理部と、前記条件判定処理部からの指令に基づいて、前記業務運用監視情報をそのまま外部に出力することにより前記監視情報の中継処理を行う監視情報中継部と、前記条件判定処理部からの指令に基づいて、操作・再生成・再構成のいずれかの処理を前記監視情報に対して行った後に外部に出力する監視情報処理部とを備えていることを特徴とする業務運用監視システムであるので、単なるシステムの障害のみならず、システムは一応稼働してはいるものの“業務”に支障をきたす「業務に影響する障害」が発生した場合にも、それを的確に検出することができる。逆に今までは障害として通知されていたケースでも、実害がない場合は通知しないようフィルタリングすることができる。
【図面の簡単な説明】
【図１】 本発明の実施の形態１に係る運用監視システムの全体の構成を示した構成図である。
【図２】 本発明の実施の形態１に係る運用監視システムの構成を示した部分詳細構成図である。
【図３】 本発明の実施の形態１に係る運用監視システムの動作を示した流れ図である。
【図４】 本発明の実施の形態２に係る運用監視システムの全体の構成を示した構成図である。
【図５】 本発明の実施の形態２に係る運用監視システムにおける条件情報テーブルの一例を示した説明図である。
【図６】 本発明の実施の形態２に係る運用監視システムの動作を示した流れ図である。
【図７】 本発明の実施の形態３に係る運用監視システムの全体の構成を示した構成図である。
【図８】 本発明の実施の形態３に係る運用監視システムの条件情報テーブルの一例を示した説明図である。
【図９】 本発明の実施の形態３に係る運用監視システムの動作を示した流れ図である。
【図１０】 本発明の実施の形態４に係る運用監視システムの動作を示した流れ図である。
【図１１】 本発明の実施の形態５に係る運用監視システムの条件情報テーブルの一例を示した説明図である。
【図１２】 本発明の実施の形態６に係る運用監視システムの全体の構成を示した構成図である。
【符号の説明】
２ 監視情報出力部、３ 監視情報中継部、４ 監視情報操作・再構成・再生成処理部、５ 条件判定処理部、７ 自律制御部、８ 状態判定処理部、９ 監視情報生成部、１０ 監視情報入力部、１００ 監視対象システム、１００ａ，１００ｂ，１００ｃ 被監視局、１００ｄ 第一の系、１００ｅ 第二の系、１０１ システム監視部、１０２ 障害監視部、１０３ 受動処理機構部、１０４能動処理機構部、１０５ 蓄積部。
Claims (2)
- 監視対象システムの業務の運用状態を監視する業務運用監視システムであって、
前記監視対象システムの業務の運用状態を示す業務運用監視情報が入力され、予め設定された所定の業務運用判定条件に基づいて、前記業務運用監視情報の検査を行い、当該検査の結果に基づいて、前記業務運用監視情報の蓄積を行う受動処理機構部と、
予め設定された所定のスケジュールに従って、前記監視対象システムが業務に支障をきたさない状態を定義した状態条件と前記受動処理機構部により蓄積された前記業務運用監視情報とを比較して、正常動作であれば正常動作通知を生成して送信し、前記業務運用判定条件を満たしていないものの業務に支障をきたさない状態であれば警告通知を生成して送信し、業務に支障をきたす状態であれば障害通知を生成して送信する能動処理機構部と、
前記受動処理機構部により蓄積される前記業務運用監視情報、前記業務運用判定条件および前記状態条件を格納する蓄積部と
を備え、
前記受動処理機構部は、
前記監視対象システムの業務運用状態を示す業務運用監視情報が入力されたときに、前記業務運用判定条件に基づいて、前記監視情報の条件判定を行うとともに、前記監視情報の蓄積を行う条件判定処理部と、
前記条件判定処理部からの指令に基づいて、前記業務運用監視情報をそのまま外部に出力することにより前記監視情報の中継処理を行う監視情報中継部と、
前記条件判定処理部からの指令に基づいて、操作・再生成・再構成のいずれかの処理を前記監視情報に対して行った後に外部に出力する監視情報処理部と
を備えている
ことを特徴とする業務運用監視システム。 - 前記能動処理機構部は、
前記スケジュールに従って起動信号を出力する自律制御部と、
前記監視対象システムが業務に支障をきたさない状態を定義した前記状態条件と前記受動処理機構部により蓄積された前記業務運用監視情報とを比較することで、前記監視対象システムの状態判定を行う状態判定処理部と、
当該状態判定結果に基づいて通知情報を生成して送信する監視情報生成部と
を備えていることを特徴とする請求項１に記載の業務運用監視システム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002371683A JP3871643B2 (ja) | 2002-12-24 | 2002-12-24 | 業務運用監視システム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002371683A JP3871643B2 (ja) | 2002-12-24 | 2002-12-24 | 業務運用監視システム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004206212A JP2004206212A (ja) | 2004-07-22 |
| JP3871643B2 true JP3871643B2 (ja) | 2007-01-24 |
Family
ID=32810512
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002371683A Expired - Fee Related JP3871643B2 (ja) | 2002-12-24 | 2002-12-24 | 業務運用監視システム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3871643B2 (ja) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2009040876A1 (ja) * | 2007-09-28 | 2009-04-02 | Fujitsu Limited | ネットワーク管理装置及びプログラム |
| US9251002B2 (en) | 2013-01-15 | 2016-02-02 | Stratus Technologies Bermuda Ltd. | System and method for writing checkpointing data |
| US9652338B2 (en) | 2013-12-30 | 2017-05-16 | Stratus Technologies Bermuda Ltd. | Dynamic checkpointing systems and methods |
| US9588844B2 (en) | 2013-12-30 | 2017-03-07 | Stratus Technologies Bermuda Ltd. | Checkpointing systems and methods using data forwarding |
| ES2652262T3 (es) | 2013-12-30 | 2018-02-01 | Stratus Technologies Bermuda Ltd. | Método de retardar puntos de comprobación inspeccionando paquetes de red |
| CN111556992A (zh) * | 2018-01-15 | 2020-08-18 | 三菱电机株式会社 | 故障检测装置、监视控制系统及故障检测方法 |
-
2002
- 2002-12-24 JP JP2002371683A patent/JP3871643B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2004206212A (ja) | 2004-07-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109726046B (zh) | 机房切换方法及切换装置 | |
| JP3871643B2 (ja) | 業務運用監視システム | |
| JP5322581B2 (ja) | 駅務システム | |
| CN110737256B (zh) | 一种用于控制变频传动系统的方法及装置 | |
| JP2007122583A (ja) | 広域警報監視システム | |
| JP2001092688A (ja) | 故障管理装置 | |
| US20220365508A1 (en) | Service console log processing devices, systems, and methods | |
| CN114624989A (zh) | 预防性控制器切换 | |
| JP4348485B2 (ja) | プロセス制御装置 | |
| JPH06195318A (ja) | 分散処理システム | |
| JP5951520B2 (ja) | 多重系処理システム | |
| JP3843388B2 (ja) | プロセス制御装置 | |
| JP3087827B2 (ja) | ファブリック障害検出方法及び装置 | |
| JPH08249212A (ja) | 多重化されたコンピュータシステムにおける障害監視方法 | |
| JP2777142B2 (ja) | 警報通報装置 | |
| JP2006344023A (ja) | 制御装置 | |
| CN115801664A (zh) | 用于经连接网络的另选通信路径的方法和装置 | |
| JP2021012517A (ja) | コントローラ冗長化システム及びその制御方法 | |
| JPH04190428A (ja) | 冗長化制御システム | |
| JPH0442632A (ja) | システム管理方式 | |
| JP2011022741A (ja) | コンピュータシステム、サービスプロセッサ、及びその診断方法 | |
| JPH04179687A (ja) | エレベータの遠隔制御装置 | |
| JPH02173898A (ja) | 遠隔監視装置 | |
| JPH0530927U (ja) | ネツトワーク・システムにおけるコンピユータの停電保護装置 | |
| JPS59221756A (ja) | 障害通報装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20050706 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050712 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050902 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20060718 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060824 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20060921 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20061010 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20061017 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091027 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121027 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |