JP5724670B2 - 監視装置、監視方法、および監視プログラム - Google Patents

Description

本発明は、データを監視する監視装置、監視方法、および監視プログラムに関する。

従来、企業内で扱う業務データ（以下、「観測データ」と称する。）を監視して、観測データの値に基づいてトラブルが発生したか否かを検出する技術が知られている。たとえば、倉庫にある商品在庫数を示すデータを一定間隔ごとに取得し、商品在庫数が危険域（閾値）に達した場合に、商品管理の担当者へアラートを通知する。

トラブルが発生してから対処までに時間がかかる場合、同一内容のアラートが過剰に管理者に通知されてしまう問題点がある。さらに、たとえば、倉庫であれば商品が１つとは限らないため、複数の製品においてアラートが過剰に通知されると、商品管理の担当者が困惑してしまう恐れがある。そこで、アラートを通知してから次にアラートを通知するまでの期間（以下、「抑止期間」と称する。）を管理者に指定させる技術が開示されている。

特開昭６４−２８７４８号公報

しかしながら、管理者にあらかじめ抑止期間を設定させたとしても、トラブルの発生から復旧するまでにかかる期間はまちまちであるため、復旧前に抑止期間が終了してしまう、または復旧後再度トラブルが発生する時点においても抑止期間が終了していない、といった事態になりうる。

本発明の一側面においては、アラートの過剰出力を抑制することを目的とする。

本発明の一側面によれば、所定時間間隔で得られる観測データについて、所定の条件を満たす場合に、警報を出力し、制御に応じて前記警報の出力を抑制し、前記警報の出力と、前記警報の出力の抑制と、のうちいずれか一方が行なわれてから前記所定時間経過するまで、前記警報の出力を抑制させる制御を行なう監視装置、監視方法、および監視プログラムが提案される。

本発明の一側面によれば、アラートの過剰出力を防止することができる。

図１は、実施例１を示す説明図である。 図２は、システム例を示す説明図である。 図３は、モニタリングサーバ２０１のハードウェア例を示すブロック図である。 図４は、アラート発生管理テーブル４００の一例を示す説明図である。 図５は、実施例１にかかるモニタリングサーバ２０１の機能ブロックの一例を示す説明図である。 図６は、モニタリングサーバ２０１による監視手順を示すフローチャートである。 図７は、図６で示した判定処理（ステップＳ６０７）の詳細な説明を示すフローチャートである。 図８は、実施例２を示す説明図である。 図９は、実施例２にかかるアラート発生管理テーブルの一例を示す説明図である。 図１０は、実施例２にかかる平均一致回数管理テーブルの一例を示す説明図である。 図１１は、実施例２にかかるモニタリングサーバ２０１の機能ブロックの一例を示す説明図である。 図１２は、実施例２にかかる図６で示した判定処理（ステップＳ６０７）の詳細な説明を示すフローチャートである。 図１３は、図１２で示した平均一致回数の算出処理（ステップＳ１２１０）の詳細な説明を示すフローチャートである。

本実施の形態においては、システムから出力されるアラートの過剰出力を抑止する。たとえば、アラートを一度しか通知しないようにすることなどが考えられるが、観測データが異常値となった１回目のデータチェック時のみアラートを出力するには、アラートが２回目以降なのか１回目なのかが不明確である。そのため、データチェックごとに、アラートが連続しているか否かを示すステータスなどを持たなければならない。

しかしながら、トラブルが発生しているか否かに関わらず、常時アラートを出力させるか否かの判定や該ステータスの更新などを行うと、監視装置の処理量が増大するという問題点がある。そこで、本実施の形態では、等間隔ごとに得られる観測データが条件を満たし場合にはアラートを出すが、以降等間隔で観測データが条件を満たす場合にはアラートを出さないことで、アラートの過剰出力を防止することができる。さらに、観測データが条件を満たしている場合、すなわちトラブルが発生している場合には処理を行うが、観測データが条件を満たしていない場合、すなわちトラブルが発生していない場合には特に処理をさせない。

以下に添付図面を参照して、本発明にかかる監視装置、監視方法、および監視プログラムの実施の形態を詳細に説明する。

（実施例１）
図１は、実施例１を示す説明図である。監視装置が、所定時間ｔごとに観測データを取得する。ここで、観測データとしては、たとえば、在庫データ、生産データ、発注データ、財務データ、性能データなどが挙げられる。

そして、監視装置が、観測データが条件を満たしているか否かを判断する。ここで、図１では、条件とは観測データが閾値より小さいことである。たとえば、閾値を１００とする。監視装置が、観測データが条件を満たしていると判断した場合に、観測データの観測時刻を記憶装置に直前観測時刻Ｔとして記憶することとする。

観測時刻が１２：００の場合には、観測データが閾値以上であるため、条件を満たしていないと判断される。監視装置は、条件を満たしていないと判断した場合、特になにも処理をしない。

観測時刻が１２：１０の場合には、観測データが閾値より小さいため、条件を満たしていると判断される。監視装置が、条件を満たしていると判断すると、記憶装置に保存されている直前観測時刻Ｔと観測データが得られた観測時刻との時間間隔が所定時間ｔと一致するか否かを判断する。記憶装置に保存されている直前観測時刻Ｔはないため、一致しないと判断される。監視装置が、一致しないと判断した場合、アラートを出力する。監視装置が、直前観測時刻Ｔに観測時刻（１２：１０）を保存する。

観測時刻が１２：２０の場合には、観測データが閾値より小さいため、条件を満たしていると判断される。監視装置が、条件を満たしていると判断すると、記憶装置に保存されている直前観測時刻Ｔと観測データが得られた観測時刻との時間間隔が所定時間ｔと一致するか否かを判断する。また、時間間隔が、ｔ≦ｘ＜２ｘｔの範囲であるか否かの判断であってもよい。これにより、所定時間ｔ〜時間２ｘｔの期間には、アラートが出力されないこととなる。ｘは利用者の入力により決定されてもよい。これに限らず、実施例２のように監視装置が一致回数に応じて２ｘｔを決定してもよい。

ここでは、直前観測時刻Ｔ（１２：１０）と観測時刻（１２：２０）との時間間隔が１０分であるため、所定時間ｔと一致すると判断される。監視装置が、一致すると判断した場合、アラートを出力せず、直前観測時刻Ｔに観測時刻（１２：２０）を保存する。

観測時刻が１２：３０と１２：４０の場合も、観測時刻が１２：２０の場合と同様に、条件を満たしていても、アラートが出力されず、直前観測時刻Ｔに観測時刻が保存される。

観測時刻が１２：５０の場合には、観測データが閾値以上であるため、条件を満たしていないと判断される。監視装置は、条件を満たしていないと判断した場合、特になにも処理をしない。よって、直前観測時刻Ｔは１２：４０のままである。

観測時刻が１３：００の場合には、観測データが閾値より小さいため、条件を満たしていると判断される。監視装置が、条件を満たしていると判断すると、記憶装置に保存されている直前観測時刻Ｔと観測データが得られた観測時刻との時間間隔が所定時間ｔと一致するか否かを判断する。直前観測時刻Ｔ（１２：４０）と観測時刻（１３：００）との時間間隔が２０分であるため、所定時間ｔと一致しないと判断される。監視装置が、一致しないと判断した場合、アラートを出力し、直前観測時刻Ｔに観測時刻（１２：２０）を保存する。

また、図１では、観測時刻としているが、これに限らず、観測日でもよいし、観測日時としてもよい。

従来であれば、たとえば、観測時刻が１２：１０において、観測データが閾値より小さくなると、監視装置が、トラブルが発生していると判断し、アラートを担当者へ通知する。そして、たとえば、観測時刻が１２：２０において、観測データが閾値より小さいが、前回のアラートの通知から抑止期間経過していないため、アラートが通知されない。そして、たとえば、観測時刻が１２：３０において、観測データが閾値より小さく、前回のアラートの通知から抑止期間経過しているため、アラートが通知されてしまう。

実施例１では、等間隔ごとに得られる観測データが条件を満たし場合にはアラートを出すが、以降等間隔で観測データが条件を満たす場合にはアラートを出さないことで、アラートの過剰出力を防止することができる。さらに、観測データが条件を満たしている場合、すなわちトラブルが発生している場合には処理を行うが、観測データが条件を満たしていない場合、すなわちトラブルが発生していない場合には特に処理をさせない。トラブルが発生していない状態の方が、トラブルが発生している状態よりもはるかに長い期間である。トラブルが発生していない状態では処理を行わないことにより、監視負荷を軽減することができる。

（システム）
図２は、システム例を示す説明図である。本実施の形態では、監視装置の一例として、システム２００を挙げている。システム２００は、たとえば、モニタリングサーバ２０１、監視対象業務システム２０２、定義クライアント２０３、Ｗｅｂダッシュボード２０４を有している。各装置は、ネットワークＮＷを経由して通信を行っている。モニタリングサーバ２０１のハードウェアについては、図３を用いて後述する。

ここで、たとえば、Ｗｅｂダッシュボード２０４は、利用者の操作により観測データの集計が行われたり、アラートをモニタリングサーバ２０１から受け付けたりする。具体的には、たとえば、Ｗｅｂダッシュボード２０４は、携帯端末やＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）であり、図３に示すモニタリングサーバ２０１のハードウェアに加えて、利用者がアラートや集計結果を閲覧可能なディスプレイを有していることとする。

たとえば、定義クライアント２０３は、業務管理者の操作により入力されるデータを受け付ける。たとえば、定義クライアント２０３は、ＰＣであり、図３に示すモニタリングサーバ２０１のハードウェアに加えて、業務管理者が閾値を入力可能なキーボードやマウスなどを有していることとする。

たとえば、監視対象業務システム２０２は、観測データを観測時刻と関連付けて業務データベースに登録する。業務データベースは、たとえば、観測データの種別や判別キーごとにあることとする。監視対象業務システム２０２は、複数個（Ｎ個）あることとする。監視対象業務システム２０２は、図３に示すモニタリングサーバ２０１のハードウェアと同一とする。

（モニタリングサーバ２０１のハードウェア例）
図３は、モニタリングサーバ２０１のハードウェア例を示すブロック図である。図３において、モニタリングサーバ２０１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）３０１と、ＲＯＭ（Ｒｅａｄ‐Ｏｎｌｙ Ｍｅｍｏｒｙ）３０２と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）３０３と、磁気ディスクドライブ３０４と、磁気ディスク３０５と、光ディスクドライブ３０６と、光ディスク３０７と、を備えている。また、各部はバス３００によってそれぞれ接続されている。

ここで、ＣＰＵ３０１は、監視装置の全体の制御を司る。ＲＯＭ３０２は、ブートプログラムなどのプログラムを記憶している。ＲＡＭ３０３は、ＣＰＵ３０１のワークエリアとして使用される。磁気ディスクドライブ３０４は、ＣＰＵ３０１の制御にしたがって磁気ディスク３０５に対するデータのリード／ライトを制御する。磁気ディスク３０５は、磁気ディスクドライブ３０４の制御で書き込まれたデータを記憶する。

光ディスクドライブ３０６は、ＣＰＵ３０１の制御にしたがって光ディスク３０７に対するデータのリード／ライトを制御する。光ディスク３０７は、光ディスクドライブ３０６の制御で書き込まれたデータを記憶したり、光ディスク３０７に記憶されたデータをコンピュータに読み取らせたりする。

Ｉ／Ｆ３０８は、通信回線を通じてＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、インターネットなどのネットワークＮＷに接続され、このネットワークＮＷを介して他の装置に接続される。そして、Ｉ／Ｆ３０８は、ネットワークＮＷと内部のインターフェースを司り、外部装置からのデータの入出力を制御する。Ｉ／Ｆ３０８には、たとえば、モデムやＬＡＮアダプタなどを採用することができる。

（実施例１にかかるアラート発生管理テーブル４００）
図４は、アラート発生管理テーブル４００の一例を示す説明図である。アラート発生管理テーブル４００は、アラート名、判別キー、最終観測日時のフィールドを有している。アラート名のフィールドには、在庫アラートなどのアラートの種類が登録される。判別キーのフィールドには、「東京」や「大阪」などの地名が登録される。最終観測日時のフィールドには、観測データが条件を満たした場合の観測データの観測日時が順次上書きされて登録される。

各フィールドに値が設定されることによりレコード（４０１−１，４０１−２）が登録される。アラート発生管理テーブル４００については、ＲＡＭ３０３、磁気ディスク３０５、光ディスク３０７などの記憶装置に記憶されていることとする。

（実施例１にかかるモニタリングサーバ２０１の機能ブロック例）
図５は、実施例１にかかるモニタリングサーバ２０１の機能ブロックの一例を示す説明図である。モニタリングサーバ２０１は、取得部５０１と、条件判断部５０２と、出力部５０３と、制御部５０４と、抑制部５０５と、を有している。

取得部５０１〜抑制部５０５は、具体的には、たとえば、図３に示したＲＯＭ３０２、ＲＡＭ３０３、磁気ディスク３０５、光ディスク３０７などの記憶装置に記憶された監視プログラムにコーディングされていることとする。ＣＰＵ３０１が記憶装置から監視プログラムを読み出し、監視プログラムにコーディングされた処理を実行することにより、取得部５０１〜抑制部５０５はその機能が実現される。

取得部５０１は、所定時間ｔごとに観測データを取得する。具体的には、たとえば、取得部５０１は、ネットワークＮＷを介して監視対象業務システム２０２の業務データベース群のうち対象となる業務データベースから、最新の観測データを取得する。ここでは、たとえば、判別キーが「東京」であり、アラートの種類が「在庫アラート」である観測データに関する処理を例に挙げて説明することとする。

条件判断部５０２は、取得部５０１により所定時間ｔが経過する都度取得される観測データが条件を満たしているか否かを判断する。具体的には、たとえば、条件判断部５０２は、観測データが閾値以上であるか否かを判断する。具体的には、たとえば、条件判断部５０２は、観測データが閾値より小さいと判断した場合、観測データが条件を満たしていると判断し、観測データが閾値以上であると判断した場合、観測データが条件を満たしていないと判断する。これに限らず、たとえば、条件判断部５０２は、観測データが閾値以下であるか否かを判断し、観測データが閾値以下であれば、観測データが条件を満たしていると判断し、観測データが閾値より大きければ、観測データが条件を満たしていないと判断してもよい。

出力部５０３は、条件判断部５０２により条件を満たしていると判断された場合、アラートを出力する。具体的には、たとえば、出力部５０３は、Ｉ／Ｆ３０８によりネットワークＮＷを介してＷｅｂダッシュボード２０４へアラートに関するメールを送信する。これに限らず、たとえば、出力部５０３は、Ｉ／Ｆ３０８によりネットワークＮＷを介してＷｅｂダッシュボード２０４のディスプレイへアラートを表示させる。

制御部５０４は、出力部５０３による警報の出力と、抑制部５０５による警報の出力の抑制と、のうちいずれか一方が行なわれてから所定時間経過するまで、抑制部５０５に警報の出力を抑制させる制御を行なう。具体的には、たとえば、制御部５０４は、観測時刻更新部５１１と間隔判断部５１２を有している。間隔判断部５１２は、観測時刻更新部５１１による更新に先立って、あらたに条件を満たした観測データが得られた観測日時と記憶装置に保存されている観測日時との時間間隔が、所定時間ｔと一致するか否かを判断する。具体的には、たとえば、間隔判断部５１２は、現日時を取得する。たとえば、間隔判断部５１２は、判別キーが「東京」であり、アラート名が「在庫アラート」であるレコードをアラート発生管理テーブル４００から特定する。たとえば、間隔判断部５１２は、特定したレコードが有する最終観測日時のフィールドの値と現日時との時間間隔が所定時間ｔと一致するか否かを判断する。また、たとえば、間隔判断部５１２は、特定したレコードがない場合、該時間間隔が、所定時間ｔと一致しないと判断することとする。

観測時刻更新部５１１は、条件判断部５０２により条件を満たしていると判断された観測データの観測時刻を記憶装置に上書き保存する。具体的には、たとえば、観測時刻更新部５１１は、条件判断部５０２により条件を満たしていると判断された場合、現日時を間隔判断部５１２により特定されたレコードの最終観測日時のフィールドに上書き保存する。また、たとえば、間隔判断部５１２により該レコードが特定されなかった場合、観測時刻更新部５１１は、アラート発生管理テーブル４００へアラート名のフィールドに「在庫アラート」を登録する。そして、観測時刻更新部５１１は、判別キーのフィールドに「東京」、最終観測日時のフィールドに現日時を登録する。これにより、アラート発生管理テーブル４００にあらたなレコードが生成される。

抑制部５０５は、制御部５０４による制御に応じて出力部５０３による警報の出力を抑制する。具体的には、たとえば、抑制部５０５は、間隔判断部５１２によって一致すると判断された場合は出力部５０３によるアラートの出力を停止するよう制御する。具体的には、たとえば、抑制部５０５は、間隔判断部５１２によって不一致と判断された場合は出力部５０３にアラートを出力させる。

（実施例１にかかるモニタリングサーバ２０１による監視手順）
図６は、モニタリングサーバ２０１による監視手順を示すフローチャートである。モニタリングサーバ２０１が、取得部５０１により所定時間ｔ経過したか否かを判断する（ステップＳ６０１）。モニタリングサーバ２０１が、所定時間ｔ経過していないと判断した場合（ステップＳ６０１：Ｎｏ）、ステップＳ６０１へ戻る。

モニタリングサーバ２０１が、所定時間ｔ経過したと判断した場合（ステップＳ６０１：Ｙｅｓ）、取得部５０１により、観測データを取得する（ステップＳ６０２）。モニタリングサーバ２０１が、現在の日時を取得する（ステップＳ６０３）。モニタリングサーバ２０１が、観測データの加工が必要か否かを判断する（ステップＳ６０４）。

モニタリングサーバ２０１が、観測データの加工が必要であると判断した場合（ステップＳ６０４：Ｙｅｓ）、観測データを加工し（ステップＳ６０５）、ステップＳ６０６へ移行する。観測データの加工は、たとえば、係数を掛けたりなどの処理である。

ステップＳ６０４において、モニタリングサーバ２０１が、観測データの加工が必要でないと判断した場合（ステップＳ６０４：Ｎｏ）、観測データまたは加工後の観測データを対象データに設定する（ステップＳ６０６）。そして、モニタリングサーバ２０１が、判定処理を実施し（ステップＳ６０７）、ステップＳ６０１へ戻る。

図７は、図６で示した判定処理（ステップＳ６０７）の詳細な説明を示すフローチャートである。まず、モニタリングサーバ２０１が、対象データが条件を満たしているか否かを判断し（ステップＳ７０１）、対象データが条件を満たしていないと判断した場合（ステップＳ７０１：Ｎｏ）、ステップＳ６０１へ戻る。すなわち、対象データが条件を満たしていないと判断した場合には、何も処理をしない。

モニタリングサーバ２０１が、対象データが条件を満たしていると判断した場合（ステップＳ７０１：Ｎｏ）、アラート発生管理テーブル４００から対象データに関するレコードを特定する（ステップＳ７０２）。モニタリングサーバ２０１が、特定できたか否かを判断し（ステップＳ７０３）、特定できた場合（ステップＳ７０３：Ｙｅｓ）、現在の日時と最終観測日時との差分を算出する（ステップＳ７０４）。

モニタリングサーバ２０１が、差分と所定時間ｔが一致するか否かを判断する（ステップＳ７０５）。モニタリングサーバ２０１が、差分と所定時間ｔが一致すると判断した場合（ステップＳ７０５：Ｙｅｓ）、抑制部５０５により、ステップＳ７０８へ移行する。すなわち、差分と所定時間ｔが一致する場合には、出力部５０３によるアラートの出力がされない。差分と所定時間ｔが一致する場合とは、すなわち、継続して観測データが条件を満たしていないことを示している。よって、継続して観測データが条件を満たす場合、１回目の判定時のみにアラートが出力される。

モニタリングサーバ２０１が、差分と所定時間ｔが一致しないと判断した場合（ステップＳ７０５：Ｎｏ）、出力部５０３により、ステップＳ７０７へ移行する。ステップＳ７０３において、モニタリングサーバ２０１が、特定できなかった場合（ステップＳ７０３：Ｎｏ）、アラート発生管理テーブル４００に新規レコードを追加する（ステップＳ７０６）。ステップＳ７０６、またはステップＳ７０５のＮｏの場合のつぎに、モニタリングサーバ２０１が、出力部５０３により、アラートを出力し（ステップＳ７０７）、ステップＳ７０８へ移行する。

ステップＳ７０５のＹｅｓの場合、またはステップＳ７０７のつぎに、モニタリングサーバ２０１が、観測時刻更新部５１１により、特定したレコードまたは新規レコードの最終観測日時を現在の日時に更新し（ステップＳ７０８）、ステップＳ６０１へ戻る。

（実施例２）
図８は、実施例２を示す説明図である。実施例２では、観測データが条件を満たし、かつ記憶装置に記憶された最終観測時刻と現時刻との差分が、所定時間ｔと一致する場合の一致回数が所定回数以上の場合に、再度アラートを出力させる。図８では、所定回数が４回であるため、一致回数が４回となると、アラートが出力されている。たとえば、所定回数は、過去の観測データが条件を満たさなくなるまでに要した期間に基づいて決定されることとする。これにより、観測データが条件を満たす場合が長期に渡り継続したら、再度アラートを出力させることができる。

また、実施例２では、実施例１で説明した部やデータと同一な部やデータについては同一符号を付し、その説明を省略する。

（実施例２にかかるアラート発生管理テーブル）
図９は、実施例２にかかるアラート発生管理テーブルの一例を示す説明図である。アラート発生管理テーブル９００は、アラート名、判別キー、一致回数、最終観測日時のフィールドを有する。アラート名のフィールドには、たとえば、在庫アラートなどのアラートの種類が登録される。判別キーのフィールドには、たとえば、「東京」や「大阪」などの地名が登録される。一致回数のフィールドには、たとえば、観測データが条件を満たすようになってからの回数が登録される。最終観測日時のフィールドには、たとえば、観測データが条件を満たした場合の観測データの観測日時が順次上書きされて登録される。

各フィールドに値が設定されることによりレコード（９０１−１，９０１−２）が登録される。アラート発生管理テーブル９００については、ＲＡＭ３０３、磁気ディスク３０５、光ディスク３０７などの記憶装置に記憶されていることとする。

（実施例２にかかる平均一致回数管理テーブル）
図１０は、実施例２にかかる平均一致回数管理テーブルの一例を示す説明図である。平均一致回数管理テーブル１０００は、アラート名、判別キー、平均一致回数、更新回数、標準偏差のフィールドを有する。アラート名のフィールドには、たとえば、「在庫アラート」などのアラートの種類が登録される。判別キーのフィールドには、たとえば、「東京」や「大阪」などの地名が登録される。

平均一致回数のフィールドには、あらたに条件を満たした観測データが得られた観測時刻とアラート発生管理テーブル９００に記憶された観測時刻との時間間隔が、所定時間ｔと一致すると判断された一致回数の平均値が登録される。平均値の初期値については、定義クライアント２０３へ業務管理者の操作により入力されることとする。更新回数のフィールドには、平均一致回数の更新回数が登録される。標準偏差のフィールドには、平均一致回数の標準偏差が登録される。

各フィールドに値が設定されることによりレコード（１００１−１，１００１−２）が登録される。平均一致回数管理テーブル１０００については、ＲＡＭ３０３、磁気ディスク３０５、光ディスク３０７などの記憶装置に記憶されていることとする。

図１１は、実施例２にかかるモニタリングサーバ２０１の機能ブロックの一例を示す説明図である。モニタリングサーバ２０１は、取得部１１０１と、条件判断部１１０２と、出力部１１０３と、制御部１１０４と、抑制部１１０５と、を有している。取得部１１０１〜抑制部１１０５は、具体的には、たとえば、図３に示したＲＯＭ３０２、ＲＡＭ３０３、磁気ディスク３０５、光ディスク３０７などの記憶装置に記憶された監視プログラムにコーディングされていることとする。ＣＰＵ３０１が記憶装置から監視プログラムを読み出し、監視プログラムにコーディングされた処理を実行することにより、取得部１１０１〜抑制部１１０５はその機能が実現される。

取得部１１０１、条件判断部１１０２、出力部１１０３、抑制部１１０５の詳細な説明については、実施例１で示したそれぞれ取得部５０１、条件判断部５０２、出力部５０３、抑制部５０５の詳細と同一であるため、詳細な説明を省略する。

制御部１１０４は、観測時刻更新部１１１１と、間隔判断部１１１２と、一致回数計数部１１１３と、異常値判断部１１１４と、所定回数更新部１１１５と、更新回数計数部１１１６と、ばらつき算出部１１１７と、を有している。観測時刻更新部１１１１、間隔判断部１１１２の詳細な説明については、実施例１で示したそれぞれ観測時刻更新部５１１、間隔判断部５１２の詳細と同一であるため、詳細な説明を省略する。

制御部１１０４は、所定回数連続で抑制部１１０５に警報の出力を抑制させる場合に記所定回数目の警報の出力は抑制させない制御を行なう。さらに、制御部が、抑制させない制御を、抑制させる制御を行なった回数の平均に基づいて設定される回数に応じて行なう。具体的には、制御部１１０４は、一致回数計数部１１１３と、異常値判断部１１１４と、所定回数更新部１１１５と、更新回数計数部１１１６と、ばらつき算出部１１１７と、によって処理が行われる。実施例２では、抑制させる制御を行なった回数は、一致回数ｃ−１である。

一致回数計数部１１１３は、間隔判断部１１１２によって一致すると判断された場合、連続して一致すると判断された一致回数ｃを計数する。具体的には、たとえば、一致回数計数部１１１３は、アラート発生管理テーブル９００の観測データに関するレコードの一致回数のフィールドの値をカウントアップする。

また、一致回数計数部１１１３は、間隔判断部１１１２によって一致しないと判断された場合、一致回数をリセットする。具体的には、たとえば、一致回数計数部１１１３は、アラート発生管理テーブル９００の観測データに関するレコードの一致回数のフィールドの値を０に設定する。

抑制部１１０５は、間隔判断部１１１２によって一致すると判断され、かつ一致回数計数部１１１３により計数された一致回数が所定回数以上である場合は出力部１１０３にアラートを出力させる。ここで、所定回数は、平均一致回数管理テーブル１０００の平均一致回数のフィールドに登録された値（以下、「平均一致回数ａ」と称する。）である。

異常値判断部１１１４は、間隔判断部１１１２によって一致しないと判断された場合、一致回数が異常値であるか否かを平均一致回数と平均一致回数のばらつき情報とに基づいて判断する。ここで、ばらつき情報とは、平均一致回数管理テーブル１０００の標準偏差のフィールドに登録された値（以下省略して「標準偏差σ」と称する。）である。

具体的には、たとえば、異常値判断部１１１４は、式（１），（２）のいずれか一方を満たす場合に一致回数ｃが異常値であると判断する。
・一致回数ｃ＞平均一致回数ａ＋２×標準偏差σ・・・（１）
・一致回数ｃ＜平均一致回数ａ−２×標準偏差σ・・・（２）

詳細には、上記式（１）または式（２）を満たす場合には、一致回数ｃは過去の一致回数ｃが約９５［％］が含まれる値の範囲外の値であると判断される。

所定回数更新部１１１５は、異常値判断部１１１４により一致回数ｃが異常値でないと判断された場合、一致回数計数部１１１３による一致回数ｃのリセット前に、一致回数ｃと平均一致回数ａと平均一致回数ａの更新回数に基づき、平均一致回数ａを更新する。ここで、平均一致回数ａの更新回数は、平均一致回数管理テーブル１０００の更新回数のフィールドに登録された値（以下、「更新回数ｕ」）である。

具体的には、たとえば、所定回数更新部１１１５は、下記式（３）に基づいて平均一致回数ａを算出して更新する。
・平均一致回数ａ＝（平均一致回数ａ×更新回数ｕ＋一致回数ｃ）÷（更新回数ｕ＋１）・・・（３）

また、所定回数更新部１１１５は、異常値判断部１１１４により一致回数ｃが異常値であると判断された場合、平均一致回数ａを更新しない。

更新回数計数部１１１６は、所定回数更新部１１１５による一致回数ｃの更新後、更新回数ｕを計数する。具体的には、たとえば、更新回数計数部１１１６は、更新回数ｕをインクリメントする。また、更新回数計数部１１１６は、異常値判断部１１１４により一致回数ｃが異常値であると判断された場合、更新回数ｕを計数しない。

ばらつき算出部１１１７は、異常値判断部１１１４により一致回数ｃが異常値でないと判断された場合、一致回数ｃと更新回数計数部１１１６による計数後の更新回数ｕに基づいて標準偏差σを算出する。具体的には、たとえば、ばらつき算出部１１１７は、下記式（４）により分散σ２ｕを算出することにより、標準偏差σを算出する。
・分散σ² _u＝（１／更新回数ｕ）×（（更新回数ｕ−１）×分散σ² _(u-1)＋（一致回数ｃ−平均一致回数ａ）²）・・・（４）

式（４）では分散σ² _(u-1)を用いているが、これに限らず、たとえば、過去の一致回数をすべて記憶させておいて、分散σ² _uを算出してもよい。

また、ばらつき算出部１１１７は、異常値判断部１１１４により一致回数ｃが異常値であると判断された場合、標準偏差σを再計算しない。

（実施例２にかかるモニタリングサーバ２０１による監視手順）
図１２は、実施例２にかかる図６で示した判定処理（ステップＳ６０７）の詳細な説明を示すフローチャートである。実施例２にかかるモニタリングサーバ２０１による監視手順については、具体的には、判定処理（ステップＳ６０７）を除く処理についてはすべて同一であるため、ここでは、実施例２にかかる判定処理（ステップＳ６０７）についてのみ説明する。

モニタリングサーバ２０１が、条件判断部１１０２により、対象データが条件を満たすか否かを判断し（ステップＳ１２０１）、対象データが条件を満たしていないと判断した場合（ステップＳ１２０１：Ｎｏ）、ステップＳ６０１へ戻る。モニタリングサーバ２０１が、対象データが条件を満たしていると判断した場合（ステップＳ１２０１：Ｙｅｓ）、アラート発生管理テーブル９００と平均一致回数管理テーブル１０００から対象データに関するレコードを特定する（ステップＳ１２０２）。

モニタリングサーバ２０１が、特定したか否かを判断し（ステップＳ１２０３）、特定したと判断した場合（ステップＳ１２０３：Ｙｅｓ）、間隔判断部１１１２により、現在の日時と最終観測日時との差分を算出する（ステップＳ１２０４）。

モニタリングサーバ２０１が、間隔判断部１１１２により、差分と所定時間ｔが一致するか否かを判断し（ステップＳ１２０５）、一致すると判断した場合（ステップＳ１２０５：Ｙｅｓ）、一致回数計数部１１１３により、一致回数をカウントアップする（ステップＳ１２０６）。

モニタリングサーバ２０１が、一致回数＞平均一致回数であるか否かを判断する（ステップＳ１２０７）。モニタリングサーバ２０１が、一致回数＞平均一致回数であると判断した場合（ステップＳ１２０７：Ｙｅｓ）、（一致回数−１）が平均一致回数の倍数であるか否かを判断する（ステップＳ１２０８）。たとえば、平均一致回数の倍数については、小数点の値を切り捨てまたは四捨五入した値としてもよい。

モニタリングサーバ２０１が、（一致回数−１）が平均一致回数の倍数であると判断した場合（ステップＳ１２０８：Ｙｅｓ）、出力部１１０３により、アラートを出力し（ステップＳ１２０９）、ステップＳ１２１４へ移行する。これにより、連続して一致する場合に、平均一致回数ごとに１回アラートを出力させることができる。

ステップＳ１２０７において、モニタリングサーバ２０１が、一致回数＞平均一致回数でないと判断した場合（ステップＳ１２０７：Ｎｏ）、ステップＳ１２１４へ移行する。ステップＳ１２０８において、モニタリングサーバ２０１が、（一致回数−１）が平均一致回数の倍数でないと判断した場合（ステップＳ１２０８：Ｎｏ）、ステップＳ１２１４へ移行する。

ステップＳ１２０５において、モニタリングサーバ２０１が、差分と所定時間ｔが一致しないと判断した場合（ステップＳ１２０５：Ｎｏ）、平均一致回数の算出処理を実行する（ステップＳ１２１０）。モニタリングサーバ２０１が、一致回数計数部１１１３により、一致回数をリセットし（ステップＳ１２１１）、出力部１１０３により、アラートを出力し（ステップＳ１２１２）、ステップＳ１２１４へ移行する。

ステップＳ１２０３において、モニタリングサーバ２０１が、特定していないと判断した場合（ステップＳ１２０３：Ｎｏ）、アラート発生管理テーブル９００と平均一致回数管理テーブル１０００のそれぞれに値を設定することで新規レコードを追加し（ステップＳ１２１３）、ステップＳ１２１２へ移行する。

ステップＳ１２０７のＮｏの場合、ステップＳ１２０８のＮｏの場合、ステップＳ１２０９、ステップＳ１２１２のつぎに、モニタリングサーバ２０１が、観測時刻更新部１１１１により、最終観測日時を現在の日時に更新し（ステップＳ１２１４）、ステップＳ６０１へ移行する。

図１３は、図１２で示した平均一致回数の算出処理（ステップＳ１２１０）の詳細な説明を示すフローチャートである。モニタリングサーバ２０１が、異常値判断部１１１４により、一致回数が異常値であるか否かを判断する（ステップＳ１３０１）。異常値であるか否かについては、上述したように式（１）または式（２）を満たすか否かによって判断される。

モニタリングサーバ２０１が、一致回数が異常値であると判断した場合（ステップＳ１３０１：Ｙｅｓ）、ステップＳ１２１１へ移行する。モニタリングサーバ２０１が、一致回数が異常値でないと判断した場合（ステップＳ１３０１：Ｎｏ）、所定回数更新部１１１５により、一致回数に基づきあらたに平均一致回数を算出して更新する（ステップＳ１３０２）。平均一致回数については、上述した式（３）に基づいて算出される。

モニタリングサーバ２０１が、更新回数計数部１１１６により、更新回数をカウントアップし（ステップＳ１３０３）、ばらつき算出部１１１７により、標準偏差を算出して更新し（ステップＳ１３０４）、ステップＳ１２１１へ移行する。標準偏差については、式（４）で得られる分散に基づいて算出される。

以上説明したように、所定時間ごとに得られる観測データが条件を継続して満たしている場合、前回条件を満たした観測時刻を記憶し、記憶された観測時刻と観測データの観測時刻との差分が所定時間と一致したときのみアラートを出力する。これにより、アラートの過剰出力を防止することができる。

観測データが条件を満たしている場合、すなわちトラブルが発生している場合には処理を行うが、観測データが条件を満たしていない場合、すなわちトラブルが発生していない場合には特に処理をさせない。トラブルが発生していない状態の方が、トラブルが発生している状態よりもはるかに長い期間である。トラブルが発生していない状態では処理を行わないことにより、監視負荷を軽減することができる。

また、観測データが条件を満たしている状態が長期間継続する場合、すなわち、トラブルが発生している状態が長期間継続している場合、過去にトラブルの解消までに要した期間に基づいて再度アラートを出力させる。記憶された観測時刻と観測データの観測時刻との差分が所定時間と一致した一致回数に基づいて該期間が決定されている。

また、平均から大きく乖離した一致回数をばらつき情報を用いて取り除き、平均一致回数を算出することにより、平均一致回数を最適化することができ、最適なタイミングでアラートを出力させることができる。

なお、本実施の形態で説明した監視方法は、あらかじめ用意された監視プログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本監視プログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また本監視プログラムは、インターネット等のネットワークＮＷを介して配布してもよい。

２０１ モニタリングサーバ
５０３，１１０３ 出力部
５０４，１１０４ 制御部
５０５，１１０５ 抑制部

Claims (3)

1. 所定時間間隔で得られる観測データについて、所定の条件を満たす場合に、警報を出力する出力手段と、
   制御に応じて前記出力手段による前記警報の出力を抑制する抑制手段と、
   前記出力手段による前記警報の出力と、前記抑制手段による前記警報の出力の抑制と、のうちいずれか一方が行なわれた時からあらたに所定条件を満たすと判断された時までの時間間隔が所定時間である場合に、前記抑制手段に前記警報の出力を抑制させる制御を行ない、前記抑制させる制御を行なった回数の平均に基づいて設定される回数に応じた所定回数連続で前記抑制手段に前記警報の出力を抑制させる場合に、前記所定回数目の前記警報の出力は抑制させない制御を行なう制御手段と、
   を備えることを特徴とする監視装置。
2. コンピュータが、
   所定時間間隔で得られる観測データについて、所定の条件を満たす場合に、警報を出力し、
   制御に応じて前記警報の出力を抑制し、
   前記警報の出力と、前記警報の出力の抑制と、のうちいずれか一方が行なわれた時からあらたに所定条件を満たすと判断された時までの時間間隔が所定時間である場合に、前記警報の出力を抑制させる制御を行ない、前記抑制させる制御を行なった回数の平均に基づいて設定される回数に応じた所定回数連続で前記警報の出力を抑制させる場合に、前記所定回数目の前記警報の出力は抑制させない制御を行なう、
   処理を実行することを特徴とする監視方法。
3. コンピュータに、
   所定時間間隔で得られる観測データについて、所定の条件を満たす場合に、警報を出力し、
   制御に応じて前記警報の出力を抑制し、
   前記警報の出力と、前記警報の出力の抑制と、のうちいずれか一方が行なわれた時からあらたに所定条件を満たすと判断された時までの時間間隔が所定時間である場合に、前記警報の出力を抑制させる制御を行ない、前記抑制させる制御を行なった回数の平均に基づいて設定される回数に応じた所定回数連続で前記警報の出力を抑制させる場合に、前記所定回数目の前記警報の出力は抑制させない制御を行なう、
   処理を実行することを特徴とする監視プログラム。

Images