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
【発明の属する技術分野】
この発明は運用監視システムに関し、特に、監視対象に発生した障害を検出するための運用監視システムに関する。
【0002】
【従来の技術】
従来の運用監視システムは、監視対象システムの稼動状態を「システムの障害」として検出し、管理者に通知することで障害監視を実現している。復合コンピュータの運行状況を一箇所で集中監視して得た各種のメッセージ群を、その優先度や内容に応じて滞りなく自動的に分類・ランク付けし、発生した異常への対処を誤りなく行う(例えば、特許文献1参照。)。
【0003】
【特許文献1】
特開平10−63539号公報
【0004】
当該特許文献1によれば、コンピュータの運用に重大な影響を与えるおそれのある事象についてのメッセージのみが自動的に選別・通報されるため、運用監視業務に従事するオペレータは、メッセージ群を取捨選択して、障害発生に関するメッセージを選び出す必要がなくなり、個々のメッセージの通報に即応して対策措置を開始することができる。また、選別されたメッセージは、所定の優先度ごとにランク付けされた順序で所定の通報先に通報されるので、緊急性のある事象への対処手順をより効率化することができる。
【0005】
【発明が解決しようとする課題】
従来のシステムは上述のように構成されており、以下に挙げるような問題点があった。
【0006】
第1の問題点として、こうした業務の視点の運用監視システムは主に「システムの障害」を通知することによって動作しており、「物理的に正常に動作しているシステム」が、処理遅延等の理由により、業務に支障を来すような事項については異常として検出されないのが現実である。従来のシステムで管理者(オペレータ)がこれを知るための方法としては、こうした処理の完了を通知させることにしておき、完了が通知されないシステムがあれば、それはまだ完了していないものだと管理者が理解するという方法がある。しかしながら、その方法では、膨大な監視情報の中から完了通知の無いシステムを管理者が見つけ出す必要がある。当然ながら、その作業は、あらかじめ知り得るシステムについての情報を元に、または、記憶をたよりに見つけ出す作業であるが、人間には「無いものを探す」行為は、それ自体非常に困難な作業である。また、すべての管理者が必ずしもすべてのシステムの存在を知り得る訳ではないため、そのような管理者にとって未知のシステムから通知が無い場合の問題を早期検出することはまず不可能であるという問題点があった。
【0007】
第2の問題点として、非常に複雑な系で障害が発生した場合には、業務の視点による障害監視システムでさえも、その系の障害を、時として、障害監視システムのもつ所定の条件判定のみで「業務に影響する障害」と判定させることができない場合がある。このような例として、障害回避のために多重化・冗長化された系、特に独自の方法で複雑に多重化・冗長化された系や、複数システムで独自に構成した系を監視するような場合が挙げられる。このような系では、ある部分が障害を発生しても、系全体としては正常に動作を続けることができ、即座に業務に支障を及ぼすものではないような、業務の視点からは軽度とみなされる障害が発生し得るが、現在の監視システムではそれぞれのシステムを独立して個別に監視するか、系全体を単独のシステムとして監視する方法しかなく、監視システムはその複雑な系の動作状態を内部の所定の条件判定では適切に表現しきれない場合が生じ得る。その結果、監視システムは適切に業務への影響を通知することができなくなり、障害の実際の業務への影響を示す情報はその正確性・信頼性を失ってしまうという問題点があった。
【0008】
この発明は、かかる問題点を解決するためになされたものであり、単なるシステムの障害のみならず、システムは一応稼働してはいるものの“業務”に支障をきたす「業務に影響する障害」が発生した場合にも、それを的確に検出することができる業務運用監視システムを得ることを目的とする。
【0009】
【課題を解決するための手段】
この発明は、監視対象システムの業務の運用状態を監視する業務運用監視システムであって、前記監視対象システムの業務の運用状態を示す業務運用監視情報が入力され、予め設定された所定の業務運用判定条件に基づいて、前記業務運用監視情報の検査を行い、当該検査の結果に基づいて、前記業務運用監視情報の蓄積を行う受動処理機構部と、予め設定された所定のスケジュールに従って、前記監視対象システムが業務に支障をきたさない状態を定義した状態条件と前記受動処理機構部により蓄積された前記業務運用監視情報とを比較して、正常動作であれば正常動作通知を生成して送信し、前記業務運用判定条件を満たしていないものの業務に支障をきたさない状態であれば警告通知を生成して送信し、業務に支障をきたす状態であれば障害通知を生成して送信する能動処理機構部と、前記受動処理機構部により蓄積される前記業務運用監視情報、前記業務運用判定条件および前記状態条件を格納する蓄積部とを備え、前記受動処理機構部は、前記監視対象システムの業務運用状態を示す業務運用監視情報が入力されたときに、前記業務運用判定条件に基づいて、前記監視情報の条件判定を行うとともに、前記監視情報の蓄積を行う条件判定処理部と、前記条件判定処理部からの指令に基づいて、前記業務運用監視情報をそのまま外部に出力することにより前記監視情報の中継処理を行う監視情報中継部と、前記条件判定処理部からの指令に基づいて、操作・再生成・再構成のいずれかの処理を前記監視情報に対して行った後に外部に出力する監視情報処理部とを備えていることを特徴とする業務運用監視システムである。
【0010】
また、前記受動処理機構部は、前記監視対象システムの業務運用状態を示す業務運用監視情報が入力されたときに、前記業務運用判定条件に基づいて、前記監視情報の条件判定を行うとともに、前記監視情報の蓄積を行う条件判定処理部と、前記条件判定処理部からの指令に基づいて、前記業務運用監視情報をそのまま外部に出力することにより前記監視情報の中継処理を行う監視情報中継部と、前記条件判定処理部からの指令に基づいて、操作・再生成・再構成のいずれかの処理を前記監視情報に対して行った後に外部に出力する監視情報処理部とを備えている。
【0011】
また、前記能動処理機構部は、前記スケジュールに従って起動信号を出力する自律制御部と、前記監視対象システムが業務に支障をきたさない状態を定義した前記状態条件と前記受動処理機構部により蓄積された前記業務運用監視情報とを比較することで、前記監視対象システムの状態判定を行う状態判定処理部と、当該状態判定結果に基づいて通知情報を生成して送信する監視情報生成部とを備えている。
【0012】
【発明の実施の形態】
実施の形態1.
本発明の運用監視システムについて、図1〜図3を用いて説明する。図1は、本発明の運用監視システムの構成を示した概略構成図である。図1において、100は監視対象である監視対象システムであり、101は監視対象システム100の運用および監視を行うシステム監視部、102は、システム監視部101からの情報に基づいて、監視対象システム100における障害発生を監視する障害監視部である。
【0013】
本発明による運用監視システムは、これらの監視対象システム100とシステム監視部101との間、および、システム監視部101と障害監視部102との間に、図1に示すように、それらの間で通知される監視情報の受信により動作を開始し、所定の条件に従って、当該監視情報を操作したり蓄積したり、あるいは、単に中継する受動処理機構103と、自律的制御により動作を開始し、受動処理機構103によって蓄積された情報および予め蓄積された所定の条件に従って状態条件判定を行って新しい監視情報を生成する能動処理機構104と、状態条件と状態監視に必要な情報を保存しておくための蓄積部105とを、それぞれ設けている。各部は独立したシステムでも、統合されたシステムでも構わない。また、監視情報が送信されるシステム間であればどこに適用しても良く、監視対象システム内の機能として適用しても良い。
【0014】
また、ここで説明する運用監視システムでは、システムの障害状態は障害通知によって管理者へ報告され、業務に影響の無いシステムの問題は警告通知によって管理者へ報告する例を挙げて説明する。
【0015】
詳細を、図2により説明する。図2において、図1と同じ構成については同一符号を付して示し、ここでは説明を省略する。図2は、図1におけるシステム監視部101と障害監視部102との間(あるいは、監視対象システム100とシステム監視部101との間)の部分を示したものである。但し、図2においては、図1で図示を省略した、監視情報出力部2と監視情報入力部10とが記載されている。すなわち、監視情報を受動処理機構103で処理しやすくするため、受動処理機構103の前後に、監視情報を受け取って条件判定を容易にするために分解処理を行う監視情報入力部10と、処理用のデータを再統合処理するための監視情報出力部2とが設けられている。
【0016】
また、図2に示すように、受動処理機構部103は、監視情報入力部10により分解処理されたデータを用いて条件判定処理を行うとともに、監視情報の蓄積を行う条件判定処理部5と、条件判定処理部5の指令により監視情報についての単なる中継処理を行う監視情報中継部3と、条件判定処理部5の指令に基づいて監視情報を操作・再構成・再生成する処理を行う操作・再構成・再生成処理部4とを備える。
【0017】
一方、能動処理機構部104は、OSのスケジュール機能や従来の運用監視ツールに備えられたスケジュール機能、または、後述の状態判定処理部8の起動を連続的・周期的に繰り返すような専用のプログラムによって実現される自律制御部7と、自律制御部7によって起動され、システムがその時点であるべき状態(業務に支障をきたさない状態)にあるかどうか、システムの状態をあらかじめ設定された状態条件テーブルと比較することで状態判定を行う状態判定処理部8と、状態判定に基づいて障害情報や警告情報が必要な際にその旨を示す監視情報を生成する監視情報生成部9とを備える。
【0018】
動作について説明する。まず、初期設定として、監視対象システム100のあるべき状態(正常な状態)を定義する設定条件を設定した状態条件テーブルと、監視対象システム100の状態を示す監視情報から得られた条件判断に必要な状態情報を、あらかじめ蓄積部105に保存しておく。ここで、あるべき状態(正常な状態)とは、「業務に影響する障害」が全く発生していない状態をいう。
【0019】
図3は、受動処理機構部103および能動処理機構部104の動作を示した流れ図である。まず、図2および図3(a)に基づいて、受動処理機構部103について詳しく説明する。監視情報が、システム監視部101から障害監視部102へ向けて送信される場合、まず、監視情報は監視情報入力部10により受け取られた後、受動処理機構部103の条件判定処理部5へ送られる(ステップS1)。これを受け取った条件判定処理部5は、これを解析する操作として、蓄積部105に保存された状態条件テーブルの条件情報を取り出し(ステップS2)、当該条件情報に基づいて、受け取った監視情報と以前に蓄積された状態情報とを含め、その時点でシステムのあるべき条件を項目ごとに比較し、蓄積された監視情報同士の関係やそれぞれのあるべき条件を判定する(ステップS3)。比較すべき関連条件項目が無いか、あるいは、中継条件項目が満たされた場合は、条件判定処理部5は、監視情報中継部3へ中継処理を指示し、一方、操作・再構成・再生成処理条件項目が満たされた場合は、監視情報操作・再構成・再生成処理部4へそれぞれの処理を指示する。このとき、監視情報中継部3は監視情報を監視情報出力部2へ送信する中継処理を行い(ステップS4)、一方、監視情報操作・再構成・再生成処理部4は、監視情報に対し業務に影響の無い障害情報を警告情報に変換する処理と、一つの障害発生が他の障害に繋がる場合に複数の障害通知を生成する処理と、監視情報により新たな障害状態が発生すると同時に、警告状態の発生・解除なども同時に起こるような複雑な場合の再構成処理などを行う(ステップS5)。その後、条件判定処理部5は条件テーブルの設定に基づいて他の条件判断に必要な監視情報を蓄積部105へ保存する(ステップS6)。なお、ステップS3において、監視情報が予め設定された所定の条件を満たした場合には、条件テーブルの設定に基づいて、能動処理機構104の自律制御部7を起動させて、能動処理を開始するようにしてもよい(ステップS7)。また、ステップS7の処理と同時に、先に指示された監視情報は監視情報出力部2を経由して本来の受信先である障害監視部102へ送信される(ステップS8)。ここまでの受動処理機構103の動作により、入力される監視情報についての情報をより適切に運用監視システム上で拡張できる。なお、監視対象システム100からシステム監視部101に監視情報が送信される場合も同様である。
【0020】
次に、図2および図3(a)に基づいて、能動処理機構104が動作する場合について詳しく説明する。上述の受動動作は、監視情報が受動処理機構103へ入力されて初めて動作を開始したが、能動処理機構104は、機構内部または外部に設けられた自律制御部7によって起動され、状態判定処理部8が処理を実行する。ここで、自律制御部7はOSのスケジュール機能や従来の運用監視ツールに備えられたスケジュール機能、または条件判定部の起動を連続的、周期的に繰り返すような専用のプログラムによって実現されるものであり、具体的には、経過時間を計測し、予め定められた所定の時間が経過すると、所定の信号を状態判定処理部8に出力し、それにより、状態判定処理部8の動作を開始させるものである。
【0021】
このようにして、自律制御部7が状態判定処理部8を起動させると、状態判定処理部8は、蓄積部105に保存された状態条件テーブルの状態条件情報を取り出し(ステップS10)、蓄積部105に保存された状態条件テーブルと、現在のシステムの状態を表す監視情報とを用いて、ある時点で、監視対象システム100が「本来あるべき状態(正常な状態)」にあるかを、設定された条件情報テーブルの能動条件が含まれるすべての項目について、項目ごとに比較や論理条件判定を行って状態判断を行い、障害状態や警告すべき状況の検出を行う(ステップS11)。この処理によって通知の必要な状態が検出されると、監視情報生成部9を用いて、監視情報出力部2、監視情報入力部10および受動処理機構内の条件判定処理部5のいずれかに対して、監視情報を各経路から送信する。監視情報生成部9は、条件判定処理部5の指定に基づいて、必要な監視情報を生成し(ステップS12)、最も適切な経路に対し、指定の監視情報を送信する(ステップS13)。具体的には、下位監視部または監視対象から監視情報が送信されたものとして扱いたい場合は監視情報入力部10へ、また、最終的な生成処理を受動処理機構部103に任せ直接受動処理を起動したい場合には受動処理機構部103の条件判定処理部5へ、あるいは、直接上位の監視部へ送りたい場合には監視情報出力部2へと、それぞれの経路で送信する。各部に送信された後の監視情報は、受動処理の場合と同じく各部所定の処理が行われる。
【0022】
以上のように、本実施の形態においては、1つまたは複数の計算機で構成されたシステムの状態を監視する「運用監視システム」において、「監視対象システム」、「システム監視部」と「業務障害監視部」との間で通知される監視情報(メッセージ)を、所定の条件に従って操作・蓄積・再生成・再構成するか、あるいは、単に中継する受動処理機構と、自律的制御により動作し、受動処理機構によって蓄積された情報、および、あらかじめ蓄積された所定の条件によって状態条件判定を行って新しい監視情報を生成する能動処理機構とを設け、これらの機構の組み合わせにより、システムの状態が業務に及ぼす影響を明確にするようにして、システムの障害の発生を検出するようにしたので、ある時点においては「物理的に正常な稼動状態にあるシステム」においても、処理遅延などの理由により業務上障害となりうる状態を検出したり、業務障害監視部の判定可能な範囲を超えるような複雑な系の障害が業務に与える影響をも適切に検出することができる。これにより、運用監視システムが通知する情報から、実際の業務に対する真の影響を、管理者自ら判断する負荷を最小限に抑えるとともに、障害発生の状況に見合った迅速な連絡や的確な復旧処置を行うことが可能になる。
【0023】
実施の形態2.
以下の実施の形態においては、監視対象システム100の具体的な例を挙げて、本発明の運用監視システムを適用した場合について説明する。本実施の形態においては、例えば、種々の商業用システムのように、営業時間帯には通常の業務運用を行い、営業時間終了後にバッチ処理を行うようなシステムの設置局があり、この種のシステムを本発明の運用監視システムにおいて監視する例について考える。
【0024】
このようなシステムの設置局(以下、被監視局と呼ぶ。)は正常に閉局すれば問題ないが、何らかの事情により閉局すべき時刻を大幅に過ぎて閉局した場合、夜間のバッチ処理の遅れにより業務上支障が生じ得る。すなわち、万一バッチ処理を完了できない場合には、翌営業開始時間にシステムの通常運用が再開できないため、業務に支障をきたす。
【0025】
このようなシステムでは、閉局時刻に被監視局が閉局通知を運用監視システムに送信するように構成すれば、管理者は閉局した被監視局を知ることができるが、障害ではないメッセージを監視しなければならないので、管理者の負荷となる。
【0026】
そこで、このシステムに図4のように本発明の受動処理機構部103および能動処理機構104を加えた構成にする。すなわち、被監視局(A)100a,被監視局(B)100b,被監視局(C)100cを監視運用する監視局200には、障害監視部102、システム監視部101、および、その中間に本発明による受動処理機構部103および能動処理機構部104を設けることによって、受動処理機構部103によって閉局通知(監視情報)を各被監視局100a〜100cから受信し、それを各監視局の状態情報として蓄積部105に格納するとともに、当該蓄積部105に蓄積された情報を基に、閉局状況検査を能動処理機構104によって連続的および定期的に実行することによって追跡監視を行えるようになる。受動処理機構部103および能動処理機構部104の内部の構成については、図2に示したものと同様であるので、ここでは図2を参照するものとし、詳細な説明については省略する。なお、以下の説明の期間において、被監視局(B)100bの物理的なシステムからの障害は検出されないものとする。
【0027】
図4のシステムについて説明する。当該システムにおいては、
(1)17:00 閉局チェック開始
(2)18:00 閉局期限
と設定されており、
例として、17:01に被監視局100aが閉局し、17:02に被監視局100cが閉局したが、閉局期限の18:00を過ぎても、被監視局100bからの閉局通知が送信されてこなかったという状況を仮定して、以下、説明する。
【0028】
いま、被監視局(A)100a,(B)100b,(C)100cのあるべき状態(正常な状態)を定義する条件が、既に、蓄積部105の状態条件テーブルに保存されており、システム監視部101が受信した監視情報から得られた条件判断に必要な状態情報が、受信された順に、徐々に、蓄積部105の状態条件テーブルに保存されていっている状態である。図5(a)に、状態条件テーブルの一例を示す。本実施の形態においては、状態条件テーブルにおけるあるべき状態を定義する条件として、「17:00〜18:00の間に閉局」という条件が設定されており、当該テーブルにおけるフラグは、監視対象システムが当該条件を満たしているか否かを示すものであり、満たした時点で「レ」が記載される。従って、このフラグが、本実施の形態における監視情報から得られた条件判断に必要な状態情報となっている。
【0029】
図6に本実施の形態による運用監視システムの動作の流れを示す。まず、図2および図6(a)に基づいて、本発明の受動処理機構の動作について説明する。図4に示す監視局200で、3つの被監視局(A)100a、被監視局(B)100bおよび被監視局(C)100cを監視する場合、被監視局(A)100aおよび被監視局(C)100cが適切な時間に閉局通知(監視情報)を送信すると、システム監視部101がこれを受け取り、受動処理機構部103へ送る(ステップS21)。受動処理機構部103では、条件判定処理部5が、「17:00〜18:00の間に閉局」という所定の判定条件を蓄積部105から取り出し(ステップS22)、受信した閉局通知が、当該所定の判定条件を満たすか否かを検査し(ステップS23)、条件を満たしていた場合には、図5(b)のように、状態条件テーブルのフラグの欄にフラグを立てることにより、当該閉局通知の内容を、能動処理機構104の追跡用に、蓄積部105に蓄積する(ステップS24)。また、必要に応じて、それと同時に、障害監視部102へ正常閉局通知として送信する(もちろん必要なければ正常通知は送信しなくとも良い。)。
【0030】
次に、図2および図6(b)を用いて、能動処理機構部104の動作について説明する。能動処理機構部104は、自律制御部7の働きによって、適当な時刻に起動し(本実施の形態では、1回目の起動が17:00になった時点で、以下、5分間隔に繰り返し起動)、状態判定処理部8は、蓄積部105から状態条件テーブルの内容を取り出し(ステップS31)、当該状態条件テーブルにおける判定条件と蓄積された状態情報とを比較して閉局通知を検査する(ステップS32)。なお、本実施の形態においては、受動処理機構部103が用いる判定条件と、能動処理機構部104が用いる状態条件とは、同じ条件となっているが、これに限らず、異なる条件としてもよい。この時点で、状態条件テーブルの状態情報を示すフラグにより、被監視局(A),(B),(C)の正常通知の有無を確認するが、17:00の時点においては、図5(a)のように、いずれにもフラグはたっていない。一方、2回目の起動における17:05の時点では、図5(b)に示す状態条件テーブルのフラグにより、被監視局(A)100aおよび被監視局(C)100cの正常な閉局通知を確認するが、同時に被監視局(B)100bの通知が無いことも検出できる。このようにして、一定の時間内(本実施の形態においては17:00〜18:00)に閉局通知が生成されるか否かを確認する場合は、例えば、能動処理機構104が、閉局時刻の期限(18:00)以前の所定の時刻(17:00)から起動し始め、以下、所定の時間間隔(5分間隔)で繰り返し起動して、起動の度に閉局通知が生成されていない被監視局があった場合には、状態判定処理部8が、監視情報生成部9に警告メッセージを発するように指示するように設定しておいてもよいが、むやみに警告を出すよりも最初の30分程度は警告を発さずに様子を見ていた方が望ましいので、例えば、予め設定した所定の回数目の起動(例えば、17:30の7回目の起動)において、閉局通知が生成されていない監視局があった場合には、状態判定処理部8が、監視情報生成部9に警告メッセージを発するように指示するように設定しておいてもよい。このようにして監視対象システムは正常でも、その動作が業務に影響を与える障害状態となりうるものと検出して、必要な監視情報(ここでは警告通知)を生成して(ステップS33)、当該警告通知を障害監視部102へ通知する(ステップS34)。さらに、最大許容時間(18:00)まで定期的に(例えば、5分間隔で)検査を繰り返すことによって追跡し、その期間内に閉局通知が無ければ、これを最終的に障害として通知すれば、管理者は障害が発生したものとして対応を開始することができる。
【0031】
以上のように、本実施の形態によれば、従来の運用監視システムでは困難だったような、業務における障害をより的確に通知できるだけでなく、多重系や複数の監視対象を統合する形で構成された系においても、本来の運用監視システムの機能を生かしたまま、より的確に障害状態を通知できるようになる。これにより、運用監視システムが通知する情報から、実際の業務に対する真の影響を、管理者自ら判断する必要を最小限に抑えるとともに、障害発生の状況に見合った迅速な連絡や的確な復旧処置を行うことが可能になる。
【0032】
実施の形態3.
本実施の形態においては、監視対象システムとして、障害回避のために多重化・冗長化された系を例に挙げて説明する。この種の系として、ここでは、二重化によって同一の機能を持つ2つのシステムが常に同期して動作しており、片方の系が障害を発生しても、全体としては正常に動作を続けることができる系、および、二重化されているが通常は片方のシステムのみ動作しており、障害発生時には待機していたもう一方の系(待機系)に切り替えて動作する系の2種類の系を考える。
【0033】
こうした系においては、前者では片系が障害により停止しても、他系が代わりに処理を行うので、必要な処理自体は正常に継続できるため、即座に業務に障害を与えることはない。また、後者の例ではどちらかのシステムが動作していればよく、障害が発生して片方のシステムがダウンしても待機系が正常に動作を開始すれば業務に支障は出ないが、その一方の問題として、障害発生により待機系へ切り替える際に、万一、待機系が正常に起動しなかった場合には、重大な事態となってしまうということが考えられる。
【0034】
図7のように、監視対象システム100である被監視系100Aが、第一の系100dと第二の系100eとから構成された二重系のシステムを監視する場合にも、本発明においては、被監視系100Aとシステム監視部101との間に、受動処理機構部103と能動処理機構部104とを適用することによって、システム監視部、監視対象システムをほとんど変更することなく、従来のシステムにおいては実現できなかったような障害を検出できるようになる。
【0035】
ここでは、まず、同期して動作する二重系の片系で障害が発生したものとする。図7の被監視系100Aについて説明する。当該被監視系においては、
(1)被監視系から10分おきに正常通知を受信
(2)1分おきに状態チェック
と設定されており、
例として、17:00の時点では第一の系100dおよび第二の系100eの両方が共に正常に動作しており、18:00に第一の系100dに異常が発生してダウンし、19:00に第二の系100eにも異常が発生してダウンしたという状況を仮定して、以下、説明する。
【0036】
まず、被監視系100Aのあるべき状態(正常な状態)を定義する条件と、監視情報から得られた条件判断に必要な状態情報とを、あらかじめ蓄積部105の状態条件テーブルに保存しておく。図8に、状態条件テーブルの一例を示す。本実施の形態においては、状態条件テーブルにおけるあるべき状態を定義する条件として、「2系とも正常」という条件が設定されており、当該テーブルにおける状態情報は、被監視系100Aが当該条件を満たしているか否かを示すものであり、「○」が2系とも正常、「△」が片系が異常、「×」が2系とも異常を意味する。「△」のときに、警告メッセージが発せられ、「×」のときに障害通知がなされることとする。本実施の形態においては、これらの「○」、「△」、「×」が、監視情報から得られた条件判断に必要な状態情報となっている。なお、第一の系および第二の系における「○」および「×」は、各時刻における「正常」および「異常」を意味する監視情報である。
【0037】
図9に本実施の形態による運用監視システムの動作の流れを示す。まず、図2および図9(a)に基づいて、本発明の受動処理機構の動作について説明する。図7に示す被監視系100Aで、2つの系100dおよび100eを監視する場合、第一の系100dおよび第二の系100eが適切な時間に正常通知(監視情報)を送信すると、システム監視部101が、これを受け取り、受動処理機構103へ送る(ステップS41)。受動処理機構103では、条件判定処理部5が、「正常動作」という所定の判定条件を蓄積部105から取り出し(ステップS42)、受信した正常通知が、当該所定の判定条件を満たすか否かを検査し(ステップS43)、条件を満たしていた場合には、図8のように、状態条件テーブルの第一の系および第二の系の欄に「○」を入力することにより、当該正常通知の内容を、能動処理機構104の追跡用に、蓄積部105に蓄積する(ステップS44)。ここで、異常通知があった場合には、条件を満たしていないと判断して、図8のように、状態条件テーブルの第一の系および第二の系の欄に「×」を入力するとともに、それらの結果から、被監視系100A全体の状態情報を「○」、「△」、「×」により入力する。また、必要に応じて、それと同時に、障害監視部102へ、2系とも正常の場合は正常動作通知として、片系が異常の場合は警告通知として、2系とも異常の場合は障害通知として送信する(もちろん必要なければ正常動作通知は送信しなくとも良い。)。
【0038】
次に、図2および図9(b)を用いて、能動処理機構部104の動作について説明する。能動処理機構部104は、自律制御部7の働きによって、適当な時間間隔で起動し(本実施の形態では、10分おきに起動)、状態判定処理部8は、蓄積部105から状態条件テーブルの内容を取り出し(ステップS51)、当該状態条件テーブルにおける判定条件と蓄積された状態情報とを比較して正常動作通知を検査する(ステップS52)。この時点で、状態条件テーブルの状態情報を示す「○」、「△」、「×」により、被監視系100Aの正常通知の有無を確認するが、17:00の時点においては、図8のように、正常状態である。一方、18:00の時点では、第一の系100dがダウンしていて、第二の系100eは正常動作していることも検出できる。このときには、被監視系100Aは、いずれかの系が正常動作していれば、支障をきたさないので、被監視系100Aとしては正常動作である。しかしながら、この時点で警告メッセージを出しておけば、管理者は万一に備えて適切な処理を行うことができる。19:00の時点では、第一の系100dがダウンしていて、第二の系100eもダウンしていることが検出できる。このときにはじめて、被監視系100Aは障害発生となる。このように、被監視系100Aは正常でも、片系に異常が発生した時点で、動作が業務に影響を与える障害状態となりうるものと検出して、必要な監視情報(ここでは警告通知)を生成して(ステップS53)、当該警告通知を監視情報出力部2を介して障害監視部102へ通知する(ステップS54)。さらに、所定間隔で検査を繰り返すことによって追跡し、2系ともにダウンした場合に、これを最終的に障害として通知すれば、管理者は障害が発生したものとして対応を開始することができる。
【0039】
以上のように、受動処理機構部104は被監視系100Aの片系からの障害通知を受け取るが、蓄積部105にあらかじめ設定された条件情報テーブルと、この時点までの機構の動作により蓄積された状態情報に対して比較および条件判定を行うことによって、もう一方の系が障害通知を生成していないか、もしくは、正常通知を生成していることなどを検出できる。これによりシステム全体では障害状態に無いものと判断できるので、この障害通知は業務には支障の無い障害の発生として警告通知に変換し、システム監視部101へ送信するのが適切である。 監視情報はシステム監視部101が所定の処理を行った後、最終的に障害監視部102へ送信され、管理者には業務に支障の無い警告通知として正しく識別される。
【0040】
一方、正常に動作していたもう片方の系でも障害が発生したときには、受動処理機構部103は被監視系100Aから先ほどと同様に障害通知を受け取るが、ここでは前回の片系の障害状態が既に蓄積されており、このデータと条件情報テーブルの検査から二重系全体が動作を継続できない障害、すなわち、業務に影響のある障害であることが検出できる。これによりこの障害通知を中継してシステム監視部101へ送信すると共に、もう片系の警告状態を障害状態に変更し新しく通知する。その結果、システム監視部101の処理を経て最終的に二重系全体で障害が発生しているものと通知されることにより、管理者には業務に障害を発生し得る重大障害として正しく識別される。
【0041】
以上のように、本実施の形態によれば、従来の運用監視システムでは困難だったような、業務における障害をより的確に通知できるだけでなく、多重系や複数の監視対象を統合する形で構成された系においても、従来の運用監視システムの機能を生かしたまま、より的確に障害状態を通知できるようになる。これにより、運用監視システムが通知する情報から、実際の業務に対する真の影響を、管理者自ら判断する必要を最小限に抑えるとともに、障害発生の状況に見合った迅速な連絡や的確な復旧処置を行うことが可能になる。
【0042】
実施の形態4.
本実施の形態においては、二重系が通常は片系でのみ動作しており、障害時に待機系に切り替えるよう構成された系において障害が発生したものとする。すなわち、図7の構成において、第一の系100dが通常側の系で、第二の系100eが待機系であるとする。全体の構成としては、図2に示したものと同様であるため、ここでは、図2を参照することとし、詳細な説明は省略する。図10の本実施の形態における動作の流れを示す。
【0043】
まずはじめに、受動処理機構部103の動作について図10(a)を用いて説明する。この場合、通常側の第一の系100dが障害を発生し障害通知を受動処理機構部103へ送信する(ステップS61)。受動処理機構部103の条件判定処理部5では、蓄積部105に格納されている所定の判定条件を取り出して(ステップS62)、当該条件に基づいて、蓄積部105に蓄積されているいままでの監視状況から、待機系である第二の系100eからの障害通知が無いこと、あるいは、第二の系100eからの正常通知が存在するかなどを検査し(ステップS63)、待機系である第二の系100eが正常であると判定した場合には、この情報を警告に変換してシステム監視部101へ送信すると共に、この情報を蓄積部105に蓄積する(ステップS64)。同時に、待機系である第二の系100eが正常に起動することを能動処理機構部104で検出するため、待機系である第二の系100eの起動検査条件(例えば、最大限許容できる時刻など)を生成し、蓄積部105へ格納する(ステップS65)。必要であれば、図2における自律制御部7を起動する。この時点で、警告はシステム監視部101の所定の処理を経て障害監視部102へ送られると共に、管理者は通常側の第一の系100dが障害発生し待機系である第二の系100eへの切り替えが発生することを認識できる。
【0044】
次に、能動処理機構部104の動作について図10(b)を用いて説明する。このとき、もし、待機系である第二の系100eが正しく起動しなかった場合には、能動処理機構部104の自律制御部7により状態判定処理部8が自律的に動作を開始し、先の待機系切り替え発生の起動検査条件を取り出して(ステップS71)、当該起動検査条件に基づいて、定期的に(例えば、1分間隔で)待機系である第二の系100eの状態条件の検査を行う(ステップS72)。この後、最大限許容できる時刻を過ぎても待機系である第二の系100eが起動しない場合、待機系である第二の系100eに障害が発生したとみなしてシステム監視部101に対して障害を通知するとともに、通常側の第一の系100dの警告状態を障害状態に変換して、障害監視部102へ障害通知を送信する(ステップS73,S74)。これらの通知はシステム監視部101の処理を経て障害状態を障害監視部102へ送り、結果的に管理者は業務に影響を及ぼす二重系全体の重大障害を正しく認識できる。
【0045】
一方、待機系である第二の系100eが正しく起動して起動完了通知を送信すれば(ステップS61)、受動処理機構部103は二重系が正しく起動したことを条件情報テーブルの条件と状態情報の検査により検出し(S62,S63)、システム監視部101へ切り替えの完了を通知すると共に、この情報を蓄積部105に格納し、さらに、能動処理機構部104の起動検査条件をリセットする。これにより業務に影響なく二重系は動作を続けていること、および、先の警告により通常側の第一の系100dの復旧が必要なことを管理者は正しく知ることができる。
【0046】
以上のように、本実施の形態によれば、従来の運用監視システムでは困難だったような、業務における障害をより的確に通知できるだけでなく、多重系や複数の監視対象を統合する形で構成された系においても、従来の運用監視システムの機能を生かしたまま、より的確に障害状態を通知できるようになる。これにより、運用監視システムが通知する情報から、実際の業務に対する真の影響を、管理者自ら判断する必要を最小限に抑えるとともに、障害発生の状況に見合った迅速な連絡や的確な復旧処置を行うことが可能になる。
【0047】
実施の形態5.
本実施の形態においては、上述の実施の形態3の変形例について説明する。本実施の形態における動作は、基本的に、図9と同じであるため、図9の流れ図を用いて説明する。
【0048】
実施の形態3においては、図9(a)に示す受動処理機構103の処理のステップS44において、異常通知があった場合には、条件を満たしていないと判断して、図8のように、状態条件テーブルの第一の系および第二の系の欄に「×」を入力するとともに、それらの結果から、被監視系100A全体の状態情報を「○」、「△」、「×」により入力するという例について説明したが、本実施の形態においては、当該ステップS44の処理において、能動処理機構部104を併用することで、何も通知が来ない状態を検知し、その場合には、図11に示すように、状態条件テーブルの第一の系および第二の系の欄に「−」を入力する。一方、異常通知があった場合には、条件を満たしていないと判断して、状態条件テーブルの第一の系および第二の系の欄に「×」を入力するとともに、それらの結果から、被監視系100A全体の状態情報を、2系とも正常の場合は「○」、片系が正常の場合は「△」、2系とも異常の場合は「×」、少なくともいずれか一方の系からの通知が何もない場合は「−」により入力する。また、必要に応じて、それと同時に、障害監視部102へ、2系とも正常の場合は正常動作通知として、片系が異常の場合は警告通知として、2系とも異常の場合は障害通知として、少なくともいずれか一方の系からの通知が何もない場合は、通信線または条件判定部5の異常か当該系の異常かのいずれの異常であるかを知らせる障害通知として、送信する(もちろん必要なければ正常動作通知は送信しなくとも良い。)。
【0049】
本実施の形態においては、実施の形態3と同様の効果が得られるとともに、さらに、通知がない場合と障害が発生した場合とを区別して蓄積部105の状態条件テーブルに格納するようにしたので、管理者は、通知がない場合でも障害を認識することができる。
【0050】
実施の形態6.
実施の形態2〜5においては監視対象システムを統括する機構として、被監視系100Aとシステム監視部101との間に、本発明の受動処理記憶部103と能動処理機構部104とを適用した例について説明したが、その場合に限らず、系が比較的単純な場合や、同様な構成の系が多数あり、各々に同一の処理を行いたいような場合は、図4のように、システム監視部101と障害監視部102との間に適用しても良く、また、図1のようにその両方に適用しても良い。
【0051】
さらに、図12のように蓄積部105を受動処理機構部103および能動処理機構部104から分離して外部に持たせたり、複数の監視対象システム100で1組の受動処理機構部103および能動処理機構部104を共有する構成にしても良い。このような構成にすることで、異なるシステム監視部101の下にある監視対象システム100同士を互いに連携させるような状態条件テーブルを作成することも可能になる。なお、図12のように、蓄積部105を外部に持たせた場合においても、必要に応じて、個別に、受動処理機構部103および能動処理機構部104に対して蓄積部105aを併設するようにしてもよい。
【0052】
本実施の形態によれば、運用監視システムの本来の機能を生かしながらも、このように自由な適用ができることで、運用監視システム自体を構築する際にも柔軟な応用が可能である。
【0053】
【発明の効果】
この発明は、監視対象システムの業務の運用状態を監視する業務運用監視システムであって、前記監視対象システムの業務の運用状態を示す業務運用監視情報が入力され、予め設定された所定の業務運用判定条件に基づいて、前記業務運用監視情報の検査を行い、当該検査の結果に基づいて、前記業務運用監視情報の蓄積を行う受動処理機構部と、予め設定された所定のスケジュールに従って、前記監視対象システムが業務に支障をきたさない状態を定義した状態条件と前記受動処理機構部により蓄積された前記業務運用監視情報とを比較して、正常動作であれば正常動作通知を生成して送信し、前記業務運用判定条件を満たしていないものの業務に支障をきたさない状態であれば警告通知を生成して送信し、業務に支障をきたす状態であれば障害通知を生成して送信する能動処理機構部と、前記受動処理機構部により蓄積される前記業務運用監視情報、前記業務運用判定条件および前記状態条件を格納する蓄積部とを備え、前記受動処理機構部は、前記監視対象システムの業務運用状態を示す業務運用監視情報が入力されたときに、前記業務運用判定条件に基づいて、前記監視情報の条件判定を行うとともに、前記監視情報の蓄積を行う条件判定処理部と、前記条件判定処理部からの指令に基づいて、前記業務運用監視情報をそのまま外部に出力することにより前記監視情報の中継処理を行う監視情報中継部と、前記条件判定処理部からの指令に基づいて、操作・再生成・再構成のいずれかの処理を前記監視情報に対して行った後に外部に出力する監視情報処理部とを備えていることを特徴とする業務運用監視システムであるので、単なるシステムの障害のみならず、システムは一応稼働してはいるものの“業務”に支障をきたす「業務に影響する障害」が発生した場合にも、それを的確に検出することができる。逆に今までは障害として通知されていたケースでも、実害がない場合は通知しないようフィルタリングすることができる。
【図面の簡単な説明】
【図1】 本発明の実施の形態1に係る運用監視システムの全体の構成を示した構成図である。
【図2】 本発明の実施の形態1に係る運用監視システムの構成を示した部分詳細構成図である。
【図3】 本発明の実施の形態1に係る運用監視システムの動作を示した流れ図である。
【図4】 本発明の実施の形態2に係る運用監視システムの全体の構成を示した構成図である。
【図5】 本発明の実施の形態2に係る運用監視システムにおける条件情報テーブルの一例を示した説明図である。
【図6】 本発明の実施の形態2に係る運用監視システムの動作を示した流れ図である。
【図7】 本発明の実施の形態3に係る運用監視システムの全体の構成を示した構成図である。
【図8】 本発明の実施の形態3に係る運用監視システムの条件情報テーブルの一例を示した説明図である。
【図9】 本発明の実施の形態3に係る運用監視システムの動作を示した流れ図である。
【図10】 本発明の実施の形態4に係る運用監視システムの動作を示した流れ図である。
【図11】 本発明の実施の形態5に係る運用監視システムの条件情報テーブルの一例を示した説明図である。
【図12】 本発明の実施の形態6に係る運用監視システムの全体の構成を示した構成図である。
【符号の説明】
2 監視情報出力部、3 監視情報中継部、4 監視情報操作・再構成・再生成処理部、5 条件判定処理部、7 自律制御部、8 状態判定処理部、9 監視情報生成部、10 監視情報入力部、100 監視対象システム、100a,100b,100c 被監視局、100d 第一の系、100e 第二の系、101 システム監視部、102 障害監視部、103 受動処理機構部、104能動処理機構部、105 蓄積部。
Claims (2)
- 監視対象システムの業務の運用状態を監視する業務運用監視システムであって、
前記監視対象システムの業務の運用状態を示す業務運用監視情報が入力され、予め設定された所定の業務運用判定条件に基づいて、前記業務運用監視情報の検査を行い、当該検査の結果に基づいて、前記業務運用監視情報の蓄積を行う受動処理機構部と、
予め設定された所定のスケジュールに従って、前記監視対象システムが業務に支障をきたさない状態を定義した状態条件と前記受動処理機構部により蓄積された前記業務運用監視情報とを比較して、正常動作であれば正常動作通知を生成して送信し、前記業務運用判定条件を満たしていないものの業務に支障をきたさない状態であれば警告通知を生成して送信し、業務に支障をきたす状態であれば障害通知を生成して送信する能動処理機構部と、
前記受動処理機構部により蓄積される前記業務運用監視情報、前記業務運用判定条件および前記状態条件を格納する蓄積部と
を備え、
前記受動処理機構部は、
前記監視対象システムの業務運用状態を示す業務運用監視情報が入力されたときに、前記業務運用判定条件に基づいて、前記監視情報の条件判定を行うとともに、前記監視情報の蓄積を行う条件判定処理部と、
前記条件判定処理部からの指令に基づいて、前記業務運用監視情報をそのまま外部に出力することにより前記監視情報の中継処理を行う監視情報中継部と、
前記条件判定処理部からの指令に基づいて、操作・再生成・再構成のいずれかの処理を前記監視情報に対して行った後に外部に出力する監視情報処理部と
を備えている
ことを特徴とする業務運用監視システム。 - 前記能動処理機構部は、
前記スケジュールに従って起動信号を出力する自律制御部と、
前記監視対象システムが業務に支障をきたさない状態を定義した前記状態条件と前記受動処理機構部により蓄積された前記業務運用監視情報とを比較することで、前記監視対象システムの状態判定を行う状態判定処理部と、
当該状態判定結果に基づいて通知情報を生成して送信する監視情報生成部と
を備えていることを特徴とする請求項1に記載の業務運用監視システム。
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 |
WO2015102875A1 (en) | 2013-12-30 | 2015-07-09 | Stratus Technologies Bermuda Ltd. | Checkpointing systems and methods of using data forwarding |
JP6518672B2 (ja) | 2013-12-30 | 2019-05-22 | ストラタス・テクノロジーズ・バミューダ・リミテッド | 動的チェックポインティングシステムおよび方法 |
WO2015102874A2 (en) | 2013-12-30 | 2015-07-09 | Stratus Technologies Bermuda Ltd. | Method of delaying checkpoints by inspecting network packets |
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) | 駅務システム | |
JP4679334B2 (ja) | 広域警報監視システム | |
CN110737256B (zh) | 一种用于控制变频传动***的方法及装置 | |
CN114624989A (zh) | 预防性控制器切换 | |
JP4348485B2 (ja) | プロセス制御装置 | |
JPH06195318A (ja) | 分散処理システム | |
JP5951520B2 (ja) | 多重系処理システム | |
US20220365508A1 (en) | Service console log processing devices, systems, and methods | |
JP3843388B2 (ja) | プロセス制御装置 | |
JP3087827B2 (ja) | ファブリック障害検出方法及び装置 | |
JPH08249212A (ja) | 多重化されたコンピュータシステムにおける障害監視方法 | |
JP5532687B2 (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 |