監視装置、監視方法、および監視プログラム
【課題】アラートの過剰出力を防止し、監視負荷を軽減する。
【解決手段】監視装置が、観測データが閾値より小さいか否かにより、観測データが条件を満たしているかを判断する。観測時刻が12:00の場合、条件を満たしていないと判断され、アラートに関する処理が行われない。観測時刻が12:10や12:20の場合には、条件を満たしていると判断され、監視装置が、直前観測時刻Tと観測データが得られた観測時刻との時間間隔が所定時間tと一致するか否かを判断する。観測時刻が12:10の場合、直前観測時刻Tに値がないので、一致しないと判断され、監視装置がアラートを出力し、直前観測時刻Tに観測時刻を保存する。観測時刻が12:20の場合、直前観測時刻T(12:10)と観測時刻との時間間隔が所定時間tと一致するため、監視装置がアラートを出力せず、直前観測時刻Tに観測時刻を保存する。
【解決手段】監視装置が、観測データが閾値より小さいか否かにより、観測データが条件を満たしているかを判断する。観測時刻が12:00の場合、条件を満たしていないと判断され、アラートに関する処理が行われない。観測時刻が12:10や12:20の場合には、条件を満たしていると判断され、監視装置が、直前観測時刻Tと観測データが得られた観測時刻との時間間隔が所定時間tと一致するか否かを判断する。観測時刻が12:10の場合、直前観測時刻Tに値がないので、一致しないと判断され、監視装置がアラートを出力し、直前観測時刻Tに観測時刻を保存する。観測時刻が12:20の場合、直前観測時刻T(12:10)と観測時刻との時間間隔が所定時間tと一致するため、監視装置がアラートを出力せず、直前観測時刻Tに観測時刻を保存する。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、データを監視する監視装置、監視方法、および監視プログラムに関する。
【背景技術】
【0002】
従来、企業内で扱う業務データ(以下、「観測データ」と称する。)を監視して、観測データの値に基づいてトラブルが発生したか否かを検出する技術が知られている。たとえば、倉庫にある商品在庫数を示すデータを一定間隔ごとに取得し、商品在庫数が危険域(閾値)に達した場合に、商品管理の担当者へアラートを通知する。
【0003】
トラブルが発生してから対処までに時間がかかる場合、同一内容のアラートが過剰に管理者に通知されてしまう問題点がある。さらに、たとえば、倉庫であれば商品が1つとは限らないため、複数の製品においてアラートが過剰に通知されると、商品管理の担当者が困惑してしまう恐れがある。そこで、アラートを通知してから次にアラートを通知するまでの期間(以下、「抑止期間」と称する。)を管理者に指定させる技術が開示されている。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】特開昭64−28748号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
しかしながら、管理者にあらかじめ抑止期間を設定させたとしても、トラブルの発生から復旧するまでにかかる期間はまちまちであるため、復旧前に抑止期間が終了してしまう、または復旧後再度トラブルが発生する時点においても抑止期間が終了していない、といった事態になりうる。
【0006】
本発明の一側面においては、アラートの過剰出力を抑制することを目的とする。
【課題を解決するための手段】
【0007】
本発明の一側面によれば、所定時間間隔で得られる観測データについて、所定の条件を満たす場合に、警報を出力し、制御に応じて前記警報の出力を抑制し、前記警報の出力と、前記警報の出力の抑制と、のうちいずれか一方が行なわれてから前記所定時間経過するまで、前記警報の出力を抑制させる制御を行なう監視装置、監視方法、および監視プログラムが提案される。
【発明の効果】
【0008】
本発明の一側面によれば、アラートの過剰出力を防止することができる。
【図面の簡単な説明】
【0009】
【図1】図1は、実施例1を示す説明図である。
【図2】図2は、システム例を示す説明図である。
【図3】図3は、モニタリングサーバ201のハードウェア例を示すブロック図である。
【図4】図4は、アラート発生管理テーブル400の一例を示す説明図である。
【図5】図5は、実施例1にかかるモニタリングサーバ201の機能ブロックの一例を示す説明図である。
【図6】図6は、モニタリングサーバ201による監視手順を示すフローチャートである。
【図7】図7は、図6で示した判定処理(ステップS607)の詳細な説明を示すフローチャートである。
【図8】図8は、実施例2を示す説明図である。
【図9】図9は、実施例2にかかるアラート発生管理テーブルの一例を示す説明図である。
【図10】図10は、実施例2にかかる平均一致回数管理テーブルの一例を示す説明図である。
【図11】図11は、実施例2にかかるモニタリングサーバ201の機能ブロックの一例を示す説明図である。
【図12】図12は、実施例2にかかる図6で示した判定処理(ステップS607)の詳細な説明を示すフローチャートである。
【図13】図13は、図12で示した平均一致回数の算出処理(ステップS1210)の詳細な説明を示すフローチャートである。
【発明を実施するための形態】
【0010】
本実施の形態においては、システムから出力されるアラートの過剰出力を抑止する。たとえば、アラートを一度しか通知しないようにすることなどが考えられるが、観測データが異常値となった1回目のデータチェック時のみアラートを出力するには、アラートが2回目以降なのか1回目なのかが不明確である。そのため、データチェックごとに、アラートが連続しているか否かを示すステータスなどを持たなければならない。
【0011】
しかしながら、トラブルが発生しているか否かに関わらず、常時アラートを出力させるか否かの判定や該ステータスの更新などを行うと、監視装置の処理量が増大するという問題点がある。そこで、本実施の形態では、等間隔ごとに得られる観測データが条件を満たし場合にはアラートを出すが、以降等間隔で観測データが条件を満たす場合にはアラートを出さないことで、アラートの過剰出力を防止することができる。さらに、観測データが条件を満たしている場合、すなわちトラブルが発生している場合には処理を行うが、観測データが条件を満たしていない場合、すなわちトラブルが発生していない場合には特に処理をさせない。
【0012】
以下に添付図面を参照して、本発明にかかる監視装置、監視方法、および監視プログラムの実施の形態を詳細に説明する。
【0013】
(実施例1)
図1は、実施例1を示す説明図である。監視装置が、所定時間tごとに観測データを取得する。ここで、観測データとしては、たとえば、在庫データ、生産データ、発注データ、財務データ、性能データなどが挙げられる。
【0014】
そして、監視装置が、観測データが条件を満たしているか否かを判断する。ここで、図1では、条件とは観測データが閾値より小さいことである。たとえば、閾値を100とする。監視装置が、観測データが条件を満たしていると判断した場合に、観測データの観測時刻を記憶装置に直前観測時刻Tとして記憶することとする。
【0015】
観測時刻が12:00の場合には、観測データが閾値以上であるため、条件を満たしていないと判断される。監視装置は、条件を満たしていないと判断した場合、特になにも処理をしない。
【0016】
観測時刻が12:10の場合には、観測データが閾値より小さいため、条件を満たしていると判断される。監視装置が、条件を満たしていると判断すると、記憶装置に保存されている直前観測時刻Tと観測データが得られた観測時刻との時間間隔が所定時間tと一致するか否かを判断する。記憶装置に保存されている直前観測時刻Tはないため、一致しないと判断される。監視装置が、一致しないと判断した場合、アラートを出力する。監視装置が、直前観測時刻Tに観測時刻(12:10)を保存する。
【0017】
観測時刻が12:20の場合には、観測データが閾値より小さいため、条件を満たしていると判断される。監視装置が、条件を満たしていると判断すると、記憶装置に保存されている直前観測時刻Tと観測データが得られた観測時刻との時間間隔が所定時間tと一致するか否かを判断する。また、時間間隔が、t≦x<2xtの範囲であるか否かの判断であってもよい。これにより、所定時間t〜時間2xtの期間には、アラートが出力されないこととなる。xは利用者の入力により決定されてもよい。これに限らず、実施例2のように監視装置が一致回数に応じて2xtを決定してもよい。
【0018】
ここでは、直前観測時刻T(12:10)と観測時刻(12:20)との時間間隔が10分であるため、所定時間tと一致すると判断される。監視装置が、一致すると判断した場合、アラートを出力せず、直前観測時刻Tに観測時刻(12:20)を保存する。
【0019】
観測時刻が12:30と12:40の場合も、観測時刻が12:20の場合と同様に、条件を満たしていても、アラートが出力されず、直前観測時刻Tに観測時刻が保存される。
【0020】
観測時刻が12:50の場合には、観測データが閾値以上であるため、条件を満たしていないと判断される。監視装置は、条件を満たしていないと判断した場合、特になにも処理をしない。よって、直前観測時刻Tは12:40のままである。
【0021】
観測時刻が13:00の場合には、観測データが閾値より小さいため、条件を満たしていると判断される。監視装置が、条件を満たしていると判断すると、記憶装置に保存されている直前観測時刻Tと観測データが得られた観測時刻との時間間隔が所定時間tと一致するか否かを判断する。直前観測時刻T(12:40)と観測時刻(13:00)との時間間隔が20分であるため、所定時間tと一致しないと判断される。監視装置が、一致しないと判断した場合、アラートを出力し、直前観測時刻Tに観測時刻(12:20)を保存する。
【0022】
また、図1では、観測時刻としているが、これに限らず、観測日でもよいし、観測日時としてもよい。
【0023】
従来であれば、たとえば、観測時刻が12:10において、観測データが閾値より小さくなると、監視装置が、トラブルが発生していると判断し、アラートを担当者へ通知する。そして、たとえば、観測時刻が12:20において、観測データが閾値より小さいが、前回のアラートの通知から抑止期間経過していないため、アラートが通知されない。そして、たとえば、観測時刻が12:30において、観測データが閾値より小さく、前回のアラートの通知から抑止期間経過しているため、アラートが通知されてしまう。
【0024】
実施例1では、等間隔ごとに得られる観測データが条件を満たし場合にはアラートを出すが、以降等間隔で観測データが条件を満たす場合にはアラートを出さないことで、アラートの過剰出力を防止することができる。さらに、観測データが条件を満たしている場合、すなわちトラブルが発生している場合には処理を行うが、観測データが条件を満たしていない場合、すなわちトラブルが発生していない場合には特に処理をさせない。トラブルが発生していない状態の方が、トラブルが発生している状態よりもはるかに長い期間である。トラブルが発生していない状態では処理を行わないことにより、監視負荷を軽減することができる。
【0025】
(システム)
図2は、システム例を示す説明図である。本実施の形態では、監視装置の一例として、システム200を挙げている。システム200は、たとえば、モニタリングサーバ201、監視対象業務システム202、定義クライアント203、Webダッシュボード204を有している。各装置は、ネットワークNWを経由して通信を行っている。モニタリングサーバ201のハードウェアについては、図3を用いて後述する。
【0026】
ここで、たとえば、Webダッシュボード204は、利用者の操作により観測データの集計が行われたり、アラートをモニタリングサーバ201から受け付けたりする。具体的には、たとえば、Webダッシュボード204は、携帯端末やPC(Personal Computer)であり、図3に示すモニタリングサーバ201のハードウェアに加えて、利用者がアラートや集計結果を閲覧可能なディスプレイを有していることとする。
【0027】
たとえば、定義クライアント203は、業務管理者の操作により入力されるデータを受け付ける。たとえば、定義クライアント203は、PCであり、図3に示すモニタリングサーバ201のハードウェアに加えて、業務管理者が閾値を入力可能なキーボードやマウスなどを有していることとする。
【0028】
たとえば、監視対象業務システム202は、観測データを観測時刻と関連付けて業務データベースに登録する。業務データベースは、たとえば、観測データの種別や判別キーごとにあることとする。監視対象業務システム202は、複数個(N個)あることとする。監視対象業務システム202は、図3に示すモニタリングサーバ201のハードウェアと同一とする。
【0029】
(モニタリングサーバ201のハードウェア例)
図3は、モニタリングサーバ201のハードウェア例を示すブロック図である。図3において、モニタリングサーバ201は、CPU(Central Processing Unit)301と、ROM(Read‐Only Memory)302と、RAM(Random Access Memory)303と、磁気ディスクドライブ304と、磁気ディスク305と、光ディスクドライブ306と、光ディスク307と、を備えている。また、各部はバス300によってそれぞれ接続されている。
【0030】
ここで、CPU301は、監視装置の全体の制御を司る。ROM302は、ブートプログラムなどのプログラムを記憶している。RAM303は、CPU301のワークエリアとして使用される。磁気ディスクドライブ304は、CPU301の制御にしたがって磁気ディスク305に対するデータのリード/ライトを制御する。磁気ディスク305は、磁気ディスクドライブ304の制御で書き込まれたデータを記憶する。
【0031】
光ディスクドライブ306は、CPU301の制御にしたがって光ディスク307に対するデータのリード/ライトを制御する。光ディスク307は、光ディスクドライブ306の制御で書き込まれたデータを記憶したり、光ディスク307に記憶されたデータをコンピュータに読み取らせたりする。
【0032】
I/F308は、通信回線を通じてLAN(Local Area Network)、WAN(Wide Area Network)、インターネットなどのネットワークNWに接続され、このネットワークNWを介して他の装置に接続される。そして、I/F308は、ネットワークNWと内部のインターフェースを司り、外部装置からのデータの入出力を制御する。I/F308には、たとえば、モデムやLANアダプタなどを採用することができる。
【0033】
(実施例1にかかるアラート発生管理テーブル400)
図4は、アラート発生管理テーブル400の一例を示す説明図である。アラート発生管理テーブル400は、アラート名、判別キー、最終観測日時のフィールドを有している。アラート名のフィールドには、在庫アラートなどのアラートの種類が登録される。判別キーのフィールドには、「東京」や「大阪」などの地名が登録される。最終観測日時のフィールドには、観測データが条件を満たした場合の観測データの観測日時が順次上書きされて登録される。
【0034】
各フィールドに値が設定されることによりレコード(401−1,401−2)が登録される。アラート発生管理テーブル400については、RAM303、磁気ディスク305、光ディスク307などの記憶装置に記憶されていることとする。
【0035】
(実施例1にかかるモニタリングサーバ201の機能ブロック例)
図5は、実施例1にかかるモニタリングサーバ201の機能ブロックの一例を示す説明図である。モニタリングサーバ201は、取得部501と、条件判断部502と、出力部503と、制御部504と、抑制部505と、を有している。
【0036】
取得部501〜抑制部505は、具体的には、たとえば、図3に示したROM302、RAM303、磁気ディスク305、光ディスク307などの記憶装置に記憶された監視プログラムにコーディングされていることとする。CPU301が記憶装置から監視プログラムを読み出し、監視プログラムにコーディングされた処理を実行することにより、取得部501〜抑制部505はその機能が実現される。
【0037】
取得部501は、所定時間tごとに観測データを取得する。具体的には、たとえば、取得部501は、ネットワークNWを介して監視対象業務システム202の業務データベース群のうち対象となる業務データベースから、最新の観測データを取得する。ここでは、たとえば、判別キーが「東京」であり、アラートの種類が「在庫アラート」である観測データに関する処理を例に挙げて説明することとする。
【0038】
条件判断部502は、取得部501により所定時間tが経過する都度取得される観測データが条件を満たしているか否かを判断する。具体的には、たとえば、条件判断部502は、観測データが閾値以上であるか否かを判断する。具体的には、たとえば、条件判断部502は、観測データが閾値より小さいと判断した場合、観測データが条件を満たしていると判断し、観測データが閾値以上であると判断した場合、観測データが条件を満たしていないと判断する。これに限らず、たとえば、条件判断部502は、観測データが閾値以下であるか否かを判断し、観測データが閾値以下であれば、観測データが条件を満たしていると判断し、観測データが閾値より大きければ、観測データが条件を満たしていないと判断してもよい。
【0039】
出力部503は、条件判断部502により条件を満たしていると判断された場合、アラートを出力する。具体的には、たとえば、出力部503は、I/F308によりネットワークNWを介してWebダッシュボード204へアラートに関するメールを送信する。これに限らず、たとえば、出力部503は、I/F308によりネットワークNWを介してWebダッシュボード204のディスプレイへアラートを表示させる。
【0040】
制御部504は、出力部503による警報の出力と、抑制部505による警報の出力の抑制と、のうちいずれか一方が行なわれてから所定時間経過するまで、抑制部505に警報の出力を抑制させる制御を行なう。具体的には、たとえば、制御部504は、観測時刻更新部511と間隔判断部512を有している。間隔判断部512は、観測時刻更新部511による更新に先立って、あらたに条件を満たした観測データが得られた観測日時と記憶装置に保存されている観測日時との時間間隔が、所定時間tと一致するか否かを判断する。具体的には、たとえば、間隔判断部512は、現日時を取得する。たとえば、間隔判断部512は、判別キーが「東京」であり、アラート名が「在庫アラート」であるレコードをアラート発生管理テーブル400から特定する。たとえば、間隔判断部512は、特定したレコードが有する最終観測日時のフィールドの値と現日時との時間間隔が所定時間tと一致するか否かを判断する。また、たとえば、間隔判断部512は、特定したレコードがない場合、該時間間隔が、所定時間tと一致しないと判断することとする。
【0041】
観測時刻更新部511は、条件判断部502により条件を満たしていると判断された観測データの観測時刻を記憶装置に上書き保存する。具体的には、たとえば、観測時刻更新部511は、条件判断部502により条件を満たしていると判断された場合、現日時を間隔判断部512により特定されたレコードの最終観測日時のフィールドに上書き保存する。また、たとえば、間隔判断部512により該レコードが特定されなかった場合、観測時刻更新部511は、アラート発生管理テーブル400へアラート名のフィールドに「在庫アラート」を登録する。そして、観測時刻更新部511は、判別キーのフィールドに「東京」、最終観測日時のフィールドに現日時を登録する。これにより、アラート発生管理テーブル400にあらたなレコードが生成される。
【0042】
抑制部505は、制御部504による制御に応じて出力部503による警報の出力を抑制する。具体的には、たとえば、抑制部505は、間隔判断部512によって一致すると判断された場合は出力部503によるアラートの出力を停止するよう制御する。具体的には、たとえば、抑制部505は、間隔判断部512によって不一致と判断された場合は出力部503にアラートを出力させる。
【0043】
(実施例1にかかるモニタリングサーバ201による監視手順)
図6は、モニタリングサーバ201による監視手順を示すフローチャートである。モニタリングサーバ201が、取得部501により所定時間t経過したか否かを判断する(ステップS601)。モニタリングサーバ201が、所定時間t経過していないと判断した場合(ステップS601:No)、ステップS601へ戻る。
【0044】
モニタリングサーバ201が、所定時間t経過したと判断した場合(ステップS601:Yes)、取得部501により、観測データを取得する(ステップS602)。モニタリングサーバ201が、現在の日時を取得する(ステップS603)。モニタリングサーバ201が、観測データの加工が必要か否かを判断する(ステップS604)。
【0045】
モニタリングサーバ201が、観測データの加工が必要であると判断した場合(ステップS604:Yes)、観測データを加工し(ステップS605)、ステップS606へ移行する。観測データの加工は、たとえば、係数を掛けたりなどの処理である。
【0046】
ステップS604において、モニタリングサーバ201が、観測データの加工が必要でないと判断した場合(ステップS604:No)、観測データまたは加工後の観測データを対象データに設定する(ステップS606)。そして、モニタリングサーバ201が、判定処理を実施し(ステップS607)、ステップS601へ戻る。
【0047】
図7は、図6で示した判定処理(ステップS607)の詳細な説明を示すフローチャートである。まず、モニタリングサーバ201が、対象データが条件を満たしているか否かを判断し(ステップS701)、対象データが条件を満たしていないと判断した場合(ステップS701:No)、ステップS601へ戻る。すなわち、対象データが条件を満たしていないと判断した場合には、何も処理をしない。
【0048】
モニタリングサーバ201が、対象データが条件を満たしていると判断した場合(ステップS701:No)、アラート発生管理テーブル400から対象データに関するレコードを特定する(ステップS702)。モニタリングサーバ201が、特定できたか否かを判断し(ステップS703)、特定できた場合(ステップS703:Yes)、現在の日時と最終観測日時との差分を算出する(ステップS704)。
【0049】
モニタリングサーバ201が、差分と所定時間tが一致するか否かを判断する(ステップS705)。モニタリングサーバ201が、差分と所定時間tが一致すると判断した場合(ステップS705:Yes)、抑制部505により、ステップS708へ移行する。すなわち、差分と所定時間tが一致する場合には、出力部503によるアラートの出力がされない。差分と所定時間tが一致する場合とは、すなわち、継続して観測データが条件を満たしていないことを示している。よって、継続して観測データが条件を満たす場合、1回目の判定時のみにアラートが出力される。
【0050】
モニタリングサーバ201が、差分と所定時間tが一致しないと判断した場合(ステップS705:No)、出力部503により、ステップS707へ移行する。ステップS703において、モニタリングサーバ201が、特定できなかった場合(ステップS703:No)、アラート発生管理テーブル400に新規レコードを追加する(ステップS706)。ステップS706、またはステップS705のNoの場合のつぎに、モニタリングサーバ201が、出力部503により、アラートを出力し(ステップS707)、ステップS708へ移行する。
【0051】
ステップS705のYesの場合、またはステップS707のつぎに、モニタリングサーバ201が、観測時刻更新部511により、特定したレコードまたは新規レコードの最終観測日時を現在の日時に更新し(ステップS708)、ステップS601へ戻る。
【0052】
(実施例2)
図8は、実施例2を示す説明図である。実施例2では、観測データが条件を満たし、かつ記憶装置に記憶された最終観測時刻と現時刻との差分が、所定時間tと一致する場合の一致回数が所定回数以上の場合に、再度アラートを出力させる。図8では、所定回数が4回であるため、一致回数が4回となると、アラートが出力されている。たとえば、所定回数は、過去の観測データが条件を満たさなくなるまでに要した期間に基づいて決定されることとする。これにより、観測データが条件を満たす場合が長期に渡り継続したら、再度アラートを出力させることができる。
【0053】
また、実施例2では、実施例1で説明した部やデータと同一な部やデータについては同一符号を付し、その説明を省略する。
【0054】
(実施例2にかかるアラート発生管理テーブル)
図9は、実施例2にかかるアラート発生管理テーブルの一例を示す説明図である。アラート発生管理テーブル900は、アラート名、判別キー、一致回数、最終観測日時のフィールドを有する。アラート名のフィールドには、たとえば、在庫アラートなどのアラートの種類が登録される。判別キーのフィールドには、たとえば、「東京」や「大阪」などの地名が登録される。一致回数のフィールドには、たとえば、観測データが条件を満たすようになってからの回数が登録される。最終観測日時のフィールドには、たとえば、観測データが条件を満たした場合の観測データの観測日時が順次上書きされて登録される。
【0055】
各フィールドに値が設定されることによりレコード(901−1,901−2)が登録される。アラート発生管理テーブル900については、RAM303、磁気ディスク305、光ディスク307などの記憶装置に記憶されていることとする。
【0056】
(実施例2にかかる平均一致回数管理テーブル)
図10は、実施例2にかかる平均一致回数管理テーブルの一例を示す説明図である。平均一致回数管理テーブル1000は、アラート名、判別キー、平均一致回数、更新回数、標準偏差のフィールドを有する。アラート名のフィールドには、たとえば、「在庫アラート」などのアラートの種類が登録される。判別キーのフィールドには、たとえば、「東京」や「大阪」などの地名が登録される。
【0057】
平均一致回数のフィールドには、あらたに条件を満たした観測データが得られた観測時刻とアラート発生管理テーブル900に記憶された観測時刻との時間間隔が、所定時間tと一致すると判断された一致回数の平均値が登録される。平均値の初期値については、定義クライアント203へ業務管理者の操作により入力されることとする。更新回数のフィールドには、平均一致回数の更新回数が登録される。標準偏差のフィールドには、平均一致回数の標準偏差が登録される。
【0058】
各フィールドに値が設定されることによりレコード(1001−1,1001−2)が登録される。平均一致回数管理テーブル1000については、RAM303、磁気ディスク305、光ディスク307などの記憶装置に記憶されていることとする。
【0059】
図11は、実施例2にかかるモニタリングサーバ201の機能ブロックの一例を示す説明図である。モニタリングサーバ201は、取得部1101と、条件判断部1102と、出力部1103と、制御部1104と、抑制部1105と、を有している。取得部1101〜抑制部1105は、具体的には、たとえば、図3に示したROM302、RAM303、磁気ディスク305、光ディスク307などの記憶装置に記憶された監視プログラムにコーディングされていることとする。CPU301が記憶装置から監視プログラムを読み出し、監視プログラムにコーディングされた処理を実行することにより、取得部1101〜抑制部1105はその機能が実現される。
【0060】
取得部1101、条件判断部1102、出力部1103、抑制部1105の詳細な説明については、実施例1で示したそれぞれ取得部501、条件判断部502、出力部503、抑制部505の詳細と同一であるため、詳細な説明を省略する。
【0061】
制御部1104は、観測時刻更新部1111と、間隔判断部1112と、一致回数計数部1113と、異常値判断部1114と、所定回数更新部1115と、更新回数計数部1116と、ばらつき算出部1117と、を有している。観測時刻更新部1111、間隔判断部1112の詳細な説明については、実施例1で示したそれぞれ観測時刻更新部511、間隔判断部512の詳細と同一であるため、詳細な説明を省略する。
【0062】
制御部1104は、所定回数連続で抑制部1105に警報の出力を抑制させる場合に記所定回数目の警報の出力は抑制させない制御を行なう。さらに、制御部が、抑制させない制御を、抑制させる制御を行なった回数の平均に基づいて設定される回数に応じて行なう。具体的には、制御部1104は、一致回数計数部1113と、異常値判断部1114と、所定回数更新部1115と、更新回数計数部1116と、ばらつき算出部1117と、によって処理が行われる。実施例2では、抑制させる制御を行なった回数は、一致回数c−1である。
【0063】
一致回数計数部1113は、間隔判断部1112によって一致すると判断された場合、連続して一致すると判断された一致回数cを計数する。具体的には、たとえば、一致回数計数部1113は、アラート発生管理テーブル900の観測データに関するレコードの一致回数のフィールドの値をカウントアップする。
【0064】
また、一致回数計数部1113は、間隔判断部1112によって一致しないと判断された場合、一致回数をリセットする。具体的には、たとえば、一致回数計数部1113は、アラート発生管理テーブル900の観測データに関するレコードの一致回数のフィールドの値を0に設定する。
【0065】
抑制部1105は、間隔判断部1112によって一致すると判断され、かつ一致回数計数部1113により計数された一致回数が所定回数以上である場合は出力部1103にアラートを出力させる。ここで、所定回数は、平均一致回数管理テーブル1000の平均一致回数のフィールドに登録された値(以下、「平均一致回数a」と称する。)である。
【0066】
異常値判断部1114は、間隔判断部1112によって一致しないと判断された場合、一致回数が異常値であるか否かを平均一致回数と平均一致回数のばらつき情報とに基づいて判断する。ここで、ばらつき情報とは、平均一致回数管理テーブル1000の標準偏差のフィールドに登録された値(以下省略して「標準偏差σ」と称する。)である。
【0067】
具体的には、たとえば、異常値判断部1114は、式(1),(2)のいずれか一方を満たす場合に一致回数cが異常値であると判断する。
・一致回数c>平均一致回数a+2×標準偏差σ・・・(1)
・一致回数c<平均一致回数a−2×標準偏差σ・・・(2)
【0068】
詳細には、上記式(1)または式(2)を満たす場合には、一致回数cは過去の一致回数cが約95[%]が含まれる値の範囲外の値であると判断される。
【0069】
所定回数更新部1115は、異常値判断部1114により一致回数cが異常値でないと判断された場合、一致回数計数部1113による一致回数cのリセット前に、一致回数cと平均一致回数aと平均一致回数aの更新回数に基づき、平均一致回数aを更新する。ここで、平均一致回数aの更新回数は、平均一致回数管理テーブル1000の更新回数のフィールドに登録された値(以下、「更新回数u」)である。
【0070】
具体的には、たとえば、所定回数更新部1115は、下記式(3)に基づいて平均一致回数aを算出して更新する。
・平均一致回数a=(平均一致回数a×更新回数u+一致回数c)÷(更新回数u+1)・・・(3)
【0071】
また、所定回数更新部1115は、異常値判断部1114により一致回数cが異常値であると判断された場合、平均一致回数aを更新しない。
【0072】
更新回数計数部1116は、所定回数更新部1115による一致回数cの更新後、更新回数uを計数する。具体的には、たとえば、更新回数計数部1116は、更新回数uをインクリメントする。また、更新回数計数部1116は、異常値判断部1114により一致回数cが異常値であると判断された場合、更新回数uを計数しない。
【0073】
ばらつき算出部1117は、異常値判断部1114により一致回数cが異常値でないと判断された場合、一致回数cと更新回数計数部1116による計数後の更新回数uに基づいて標準偏差σを算出する。具体的には、たとえば、ばらつき算出部1117は、下記式(4)により分散σ2uを算出することにより、標準偏差σを算出する。
・分散σ2u=(1/更新回数u)×((更新回数u−1)×分散σ2(u-1)+(一致回数c−平均一致回数a)2)・・・(4)
【0074】
式(4)では分散σ2(u-1)を用いているが、これに限らず、たとえば、過去の一致回数をすべて記憶させておいて、分散σ2uを算出してもよい。
【0075】
また、ばらつき算出部1117は、異常値判断部1114により一致回数cが異常値であると判断された場合、標準偏差σを再計算しない。
【0076】
(実施例2にかかるモニタリングサーバ201による監視手順)
図12は、実施例2にかかる図6で示した判定処理(ステップS607)の詳細な説明を示すフローチャートである。実施例2にかかるモニタリングサーバ201による監視手順については、具体的には、判定処理(ステップS607)を除く処理についてはすべて同一であるため、ここでは、実施例2にかかる判定処理(ステップS607)についてのみ説明する。
【0077】
モニタリングサーバ201が、条件判断部1102により、対象データが条件を満たすか否かを判断し(ステップS1201)、対象データが条件を満たしていないと判断した場合(ステップS1201:No)、ステップS601へ戻る。モニタリングサーバ201が、対象データが条件を満たしていると判断した場合(ステップS1201:Yes)、アラート発生管理テーブル900と平均一致回数管理テーブル1000から対象データに関するレコードを特定する(ステップS1202)。
【0078】
モニタリングサーバ201が、特定したか否かを判断し(ステップS1203)、特定したと判断した場合(ステップS1203:Yes)、間隔判断部1112により、現在の日時と最終観測日時との差分を算出する(ステップS1204)。
【0079】
モニタリングサーバ201が、間隔判断部1112により、差分と所定時間tが一致するか否かを判断し(ステップS1205)、一致すると判断した場合(ステップS1205:Yes)、一致回数計数部1113により、一致回数をカウントアップする(ステップS1206)。
【0080】
モニタリングサーバ201が、一致回数>平均一致回数であるか否かを判断する(ステップS1207)。モニタリングサーバ201が、一致回数>平均一致回数であると判断した場合(ステップS1207:Yes)、(一致回数−1)が平均一致回数の倍数であるか否かを判断する(ステップS1208)。たとえば、平均一致回数の倍数については、小数点の値を切り捨てまたは四捨五入した値としてもよい。
【0081】
モニタリングサーバ201が、(一致回数−1)が平均一致回数の倍数であると判断した場合(ステップS1208:Yes)、出力部1103により、アラートを出力し(ステップS1209)、ステップS1214へ移行する。これにより、連続して一致する場合に、平均一致回数ごとに1回アラートを出力させることができる。
【0082】
ステップS1207において、モニタリングサーバ201が、一致回数>平均一致回数でないと判断した場合(ステップS1207:No)、ステップS1214へ移行する。ステップS1208において、モニタリングサーバ201が、(一致回数−1)が平均一致回数の倍数でないと判断した場合(ステップS1208:No)、ステップS1214へ移行する。
【0083】
ステップS1205において、モニタリングサーバ201が、差分と所定時間tが一致しないと判断した場合(ステップS1205:No)、平均一致回数の算出処理を実行する(ステップS1210)。モニタリングサーバ201が、一致回数計数部1113により、一致回数をリセットし(ステップS1211)、出力部1103により、アラートを出力し(ステップS1212)、ステップS1214へ移行する。
【0084】
ステップS1203において、モニタリングサーバ201が、特定していないと判断した場合(ステップS1203:No)、アラート発生管理テーブル900と平均一致回数管理テーブル1000のそれぞれに値を設定することで新規レコードを追加し(ステップS1213)、ステップS1212へ移行する。
【0085】
ステップS1207のNoの場合、ステップS1208のNoの場合、ステップS1209、ステップS1212のつぎに、モニタリングサーバ201が、観測時刻更新部1111により、最終観測日時を現在の日時に更新し(ステップS1214)、ステップS601へ移行する。
【0086】
図13は、図12で示した平均一致回数の算出処理(ステップS1210)の詳細な説明を示すフローチャートである。モニタリングサーバ201が、異常値判断部1114により、一致回数が異常値であるか否かを判断する(ステップS1301)。異常値であるか否かについては、上述したように式(1)または式(2)を満たすか否かによって判断される。
【0087】
モニタリングサーバ201が、一致回数が異常値であると判断した場合(ステップS1301:Yes)、ステップS1211へ移行する。モニタリングサーバ201が、一致回数が異常値でないと判断した場合(ステップS1301:No)、所定回数更新部1115により、一致回数に基づきあらたに平均一致回数を算出して更新する(ステップS1302)。平均一致回数については、上述した式(3)に基づいて算出される。
【0088】
モニタリングサーバ201が、更新回数計数部1116により、更新回数をカウントアップし(ステップS1303)、ばらつき算出部1117により、標準偏差を算出して更新し(ステップS1304)、ステップS1211へ移行する。標準偏差については、式(4)で得られる分散に基づいて算出される。
【0089】
以上説明したように、所定時間ごとに得られる観測データが条件を継続して満たしている場合、前回条件を満たした観測時刻を記憶し、記憶された観測時刻と観測データの観測時刻との差分が所定時間と一致したときのみアラートを出力する。これにより、アラートの過剰出力を防止することができる。
【0090】
観測データが条件を満たしている場合、すなわちトラブルが発生している場合には処理を行うが、観測データが条件を満たしていない場合、すなわちトラブルが発生していない場合には特に処理をさせない。トラブルが発生していない状態の方が、トラブルが発生している状態よりもはるかに長い期間である。トラブルが発生していない状態では処理を行わないことにより、監視負荷を軽減することができる。
【0091】
また、観測データが条件を満たしている状態が長期間継続する場合、すなわち、トラブルが発生している状態が長期間継続している場合、過去にトラブルの解消までに要した期間に基づいて再度アラートを出力させる。記憶された観測時刻と観測データの観測時刻との差分が所定時間と一致した一致回数に基づいて該期間が決定されている。
【0092】
また、平均から大きく乖離した一致回数をばらつき情報を用いて取り除き、平均一致回数を算出することにより、平均一致回数を最適化することができ、最適なタイミングでアラートを出力させることができる。
【0093】
なお、本実施の形態で説明した監視方法は、あらかじめ用意された監視プログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本監視プログラムは、ハードディスク、フレキシブルディスク、CD−ROM、MO、DVD等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また本監視プログラムは、インターネット等のネットワークNWを介して配布してもよい。
【符号の説明】
【0094】
201 モニタリングサーバ
503,1103 出力部
504,1104 制御部
505,1105 抑制部
【技術分野】
【0001】
本発明は、データを監視する監視装置、監視方法、および監視プログラムに関する。
【背景技術】
【0002】
従来、企業内で扱う業務データ(以下、「観測データ」と称する。)を監視して、観測データの値に基づいてトラブルが発生したか否かを検出する技術が知られている。たとえば、倉庫にある商品在庫数を示すデータを一定間隔ごとに取得し、商品在庫数が危険域(閾値)に達した場合に、商品管理の担当者へアラートを通知する。
【0003】
トラブルが発生してから対処までに時間がかかる場合、同一内容のアラートが過剰に管理者に通知されてしまう問題点がある。さらに、たとえば、倉庫であれば商品が1つとは限らないため、複数の製品においてアラートが過剰に通知されると、商品管理の担当者が困惑してしまう恐れがある。そこで、アラートを通知してから次にアラートを通知するまでの期間(以下、「抑止期間」と称する。)を管理者に指定させる技術が開示されている。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】特開昭64−28748号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
しかしながら、管理者にあらかじめ抑止期間を設定させたとしても、トラブルの発生から復旧するまでにかかる期間はまちまちであるため、復旧前に抑止期間が終了してしまう、または復旧後再度トラブルが発生する時点においても抑止期間が終了していない、といった事態になりうる。
【0006】
本発明の一側面においては、アラートの過剰出力を抑制することを目的とする。
【課題を解決するための手段】
【0007】
本発明の一側面によれば、所定時間間隔で得られる観測データについて、所定の条件を満たす場合に、警報を出力し、制御に応じて前記警報の出力を抑制し、前記警報の出力と、前記警報の出力の抑制と、のうちいずれか一方が行なわれてから前記所定時間経過するまで、前記警報の出力を抑制させる制御を行なう監視装置、監視方法、および監視プログラムが提案される。
【発明の効果】
【0008】
本発明の一側面によれば、アラートの過剰出力を防止することができる。
【図面の簡単な説明】
【0009】
【図1】図1は、実施例1を示す説明図である。
【図2】図2は、システム例を示す説明図である。
【図3】図3は、モニタリングサーバ201のハードウェア例を示すブロック図である。
【図4】図4は、アラート発生管理テーブル400の一例を示す説明図である。
【図5】図5は、実施例1にかかるモニタリングサーバ201の機能ブロックの一例を示す説明図である。
【図6】図6は、モニタリングサーバ201による監視手順を示すフローチャートである。
【図7】図7は、図6で示した判定処理(ステップS607)の詳細な説明を示すフローチャートである。
【図8】図8は、実施例2を示す説明図である。
【図9】図9は、実施例2にかかるアラート発生管理テーブルの一例を示す説明図である。
【図10】図10は、実施例2にかかる平均一致回数管理テーブルの一例を示す説明図である。
【図11】図11は、実施例2にかかるモニタリングサーバ201の機能ブロックの一例を示す説明図である。
【図12】図12は、実施例2にかかる図6で示した判定処理(ステップS607)の詳細な説明を示すフローチャートである。
【図13】図13は、図12で示した平均一致回数の算出処理(ステップS1210)の詳細な説明を示すフローチャートである。
【発明を実施するための形態】
【0010】
本実施の形態においては、システムから出力されるアラートの過剰出力を抑止する。たとえば、アラートを一度しか通知しないようにすることなどが考えられるが、観測データが異常値となった1回目のデータチェック時のみアラートを出力するには、アラートが2回目以降なのか1回目なのかが不明確である。そのため、データチェックごとに、アラートが連続しているか否かを示すステータスなどを持たなければならない。
【0011】
しかしながら、トラブルが発生しているか否かに関わらず、常時アラートを出力させるか否かの判定や該ステータスの更新などを行うと、監視装置の処理量が増大するという問題点がある。そこで、本実施の形態では、等間隔ごとに得られる観測データが条件を満たし場合にはアラートを出すが、以降等間隔で観測データが条件を満たす場合にはアラートを出さないことで、アラートの過剰出力を防止することができる。さらに、観測データが条件を満たしている場合、すなわちトラブルが発生している場合には処理を行うが、観測データが条件を満たしていない場合、すなわちトラブルが発生していない場合には特に処理をさせない。
【0012】
以下に添付図面を参照して、本発明にかかる監視装置、監視方法、および監視プログラムの実施の形態を詳細に説明する。
【0013】
(実施例1)
図1は、実施例1を示す説明図である。監視装置が、所定時間tごとに観測データを取得する。ここで、観測データとしては、たとえば、在庫データ、生産データ、発注データ、財務データ、性能データなどが挙げられる。
【0014】
そして、監視装置が、観測データが条件を満たしているか否かを判断する。ここで、図1では、条件とは観測データが閾値より小さいことである。たとえば、閾値を100とする。監視装置が、観測データが条件を満たしていると判断した場合に、観測データの観測時刻を記憶装置に直前観測時刻Tとして記憶することとする。
【0015】
観測時刻が12:00の場合には、観測データが閾値以上であるため、条件を満たしていないと判断される。監視装置は、条件を満たしていないと判断した場合、特になにも処理をしない。
【0016】
観測時刻が12:10の場合には、観測データが閾値より小さいため、条件を満たしていると判断される。監視装置が、条件を満たしていると判断すると、記憶装置に保存されている直前観測時刻Tと観測データが得られた観測時刻との時間間隔が所定時間tと一致するか否かを判断する。記憶装置に保存されている直前観測時刻Tはないため、一致しないと判断される。監視装置が、一致しないと判断した場合、アラートを出力する。監視装置が、直前観測時刻Tに観測時刻(12:10)を保存する。
【0017】
観測時刻が12:20の場合には、観測データが閾値より小さいため、条件を満たしていると判断される。監視装置が、条件を満たしていると判断すると、記憶装置に保存されている直前観測時刻Tと観測データが得られた観測時刻との時間間隔が所定時間tと一致するか否かを判断する。また、時間間隔が、t≦x<2xtの範囲であるか否かの判断であってもよい。これにより、所定時間t〜時間2xtの期間には、アラートが出力されないこととなる。xは利用者の入力により決定されてもよい。これに限らず、実施例2のように監視装置が一致回数に応じて2xtを決定してもよい。
【0018】
ここでは、直前観測時刻T(12:10)と観測時刻(12:20)との時間間隔が10分であるため、所定時間tと一致すると判断される。監視装置が、一致すると判断した場合、アラートを出力せず、直前観測時刻Tに観測時刻(12:20)を保存する。
【0019】
観測時刻が12:30と12:40の場合も、観測時刻が12:20の場合と同様に、条件を満たしていても、アラートが出力されず、直前観測時刻Tに観測時刻が保存される。
【0020】
観測時刻が12:50の場合には、観測データが閾値以上であるため、条件を満たしていないと判断される。監視装置は、条件を満たしていないと判断した場合、特になにも処理をしない。よって、直前観測時刻Tは12:40のままである。
【0021】
観測時刻が13:00の場合には、観測データが閾値より小さいため、条件を満たしていると判断される。監視装置が、条件を満たしていると判断すると、記憶装置に保存されている直前観測時刻Tと観測データが得られた観測時刻との時間間隔が所定時間tと一致するか否かを判断する。直前観測時刻T(12:40)と観測時刻(13:00)との時間間隔が20分であるため、所定時間tと一致しないと判断される。監視装置が、一致しないと判断した場合、アラートを出力し、直前観測時刻Tに観測時刻(12:20)を保存する。
【0022】
また、図1では、観測時刻としているが、これに限らず、観測日でもよいし、観測日時としてもよい。
【0023】
従来であれば、たとえば、観測時刻が12:10において、観測データが閾値より小さくなると、監視装置が、トラブルが発生していると判断し、アラートを担当者へ通知する。そして、たとえば、観測時刻が12:20において、観測データが閾値より小さいが、前回のアラートの通知から抑止期間経過していないため、アラートが通知されない。そして、たとえば、観測時刻が12:30において、観測データが閾値より小さく、前回のアラートの通知から抑止期間経過しているため、アラートが通知されてしまう。
【0024】
実施例1では、等間隔ごとに得られる観測データが条件を満たし場合にはアラートを出すが、以降等間隔で観測データが条件を満たす場合にはアラートを出さないことで、アラートの過剰出力を防止することができる。さらに、観測データが条件を満たしている場合、すなわちトラブルが発生している場合には処理を行うが、観測データが条件を満たしていない場合、すなわちトラブルが発生していない場合には特に処理をさせない。トラブルが発生していない状態の方が、トラブルが発生している状態よりもはるかに長い期間である。トラブルが発生していない状態では処理を行わないことにより、監視負荷を軽減することができる。
【0025】
(システム)
図2は、システム例を示す説明図である。本実施の形態では、監視装置の一例として、システム200を挙げている。システム200は、たとえば、モニタリングサーバ201、監視対象業務システム202、定義クライアント203、Webダッシュボード204を有している。各装置は、ネットワークNWを経由して通信を行っている。モニタリングサーバ201のハードウェアについては、図3を用いて後述する。
【0026】
ここで、たとえば、Webダッシュボード204は、利用者の操作により観測データの集計が行われたり、アラートをモニタリングサーバ201から受け付けたりする。具体的には、たとえば、Webダッシュボード204は、携帯端末やPC(Personal Computer)であり、図3に示すモニタリングサーバ201のハードウェアに加えて、利用者がアラートや集計結果を閲覧可能なディスプレイを有していることとする。
【0027】
たとえば、定義クライアント203は、業務管理者の操作により入力されるデータを受け付ける。たとえば、定義クライアント203は、PCであり、図3に示すモニタリングサーバ201のハードウェアに加えて、業務管理者が閾値を入力可能なキーボードやマウスなどを有していることとする。
【0028】
たとえば、監視対象業務システム202は、観測データを観測時刻と関連付けて業務データベースに登録する。業務データベースは、たとえば、観測データの種別や判別キーごとにあることとする。監視対象業務システム202は、複数個(N個)あることとする。監視対象業務システム202は、図3に示すモニタリングサーバ201のハードウェアと同一とする。
【0029】
(モニタリングサーバ201のハードウェア例)
図3は、モニタリングサーバ201のハードウェア例を示すブロック図である。図3において、モニタリングサーバ201は、CPU(Central Processing Unit)301と、ROM(Read‐Only Memory)302と、RAM(Random Access Memory)303と、磁気ディスクドライブ304と、磁気ディスク305と、光ディスクドライブ306と、光ディスク307と、を備えている。また、各部はバス300によってそれぞれ接続されている。
【0030】
ここで、CPU301は、監視装置の全体の制御を司る。ROM302は、ブートプログラムなどのプログラムを記憶している。RAM303は、CPU301のワークエリアとして使用される。磁気ディスクドライブ304は、CPU301の制御にしたがって磁気ディスク305に対するデータのリード/ライトを制御する。磁気ディスク305は、磁気ディスクドライブ304の制御で書き込まれたデータを記憶する。
【0031】
光ディスクドライブ306は、CPU301の制御にしたがって光ディスク307に対するデータのリード/ライトを制御する。光ディスク307は、光ディスクドライブ306の制御で書き込まれたデータを記憶したり、光ディスク307に記憶されたデータをコンピュータに読み取らせたりする。
【0032】
I/F308は、通信回線を通じてLAN(Local Area Network)、WAN(Wide Area Network)、インターネットなどのネットワークNWに接続され、このネットワークNWを介して他の装置に接続される。そして、I/F308は、ネットワークNWと内部のインターフェースを司り、外部装置からのデータの入出力を制御する。I/F308には、たとえば、モデムやLANアダプタなどを採用することができる。
【0033】
(実施例1にかかるアラート発生管理テーブル400)
図4は、アラート発生管理テーブル400の一例を示す説明図である。アラート発生管理テーブル400は、アラート名、判別キー、最終観測日時のフィールドを有している。アラート名のフィールドには、在庫アラートなどのアラートの種類が登録される。判別キーのフィールドには、「東京」や「大阪」などの地名が登録される。最終観測日時のフィールドには、観測データが条件を満たした場合の観測データの観測日時が順次上書きされて登録される。
【0034】
各フィールドに値が設定されることによりレコード(401−1,401−2)が登録される。アラート発生管理テーブル400については、RAM303、磁気ディスク305、光ディスク307などの記憶装置に記憶されていることとする。
【0035】
(実施例1にかかるモニタリングサーバ201の機能ブロック例)
図5は、実施例1にかかるモニタリングサーバ201の機能ブロックの一例を示す説明図である。モニタリングサーバ201は、取得部501と、条件判断部502と、出力部503と、制御部504と、抑制部505と、を有している。
【0036】
取得部501〜抑制部505は、具体的には、たとえば、図3に示したROM302、RAM303、磁気ディスク305、光ディスク307などの記憶装置に記憶された監視プログラムにコーディングされていることとする。CPU301が記憶装置から監視プログラムを読み出し、監視プログラムにコーディングされた処理を実行することにより、取得部501〜抑制部505はその機能が実現される。
【0037】
取得部501は、所定時間tごとに観測データを取得する。具体的には、たとえば、取得部501は、ネットワークNWを介して監視対象業務システム202の業務データベース群のうち対象となる業務データベースから、最新の観測データを取得する。ここでは、たとえば、判別キーが「東京」であり、アラートの種類が「在庫アラート」である観測データに関する処理を例に挙げて説明することとする。
【0038】
条件判断部502は、取得部501により所定時間tが経過する都度取得される観測データが条件を満たしているか否かを判断する。具体的には、たとえば、条件判断部502は、観測データが閾値以上であるか否かを判断する。具体的には、たとえば、条件判断部502は、観測データが閾値より小さいと判断した場合、観測データが条件を満たしていると判断し、観測データが閾値以上であると判断した場合、観測データが条件を満たしていないと判断する。これに限らず、たとえば、条件判断部502は、観測データが閾値以下であるか否かを判断し、観測データが閾値以下であれば、観測データが条件を満たしていると判断し、観測データが閾値より大きければ、観測データが条件を満たしていないと判断してもよい。
【0039】
出力部503は、条件判断部502により条件を満たしていると判断された場合、アラートを出力する。具体的には、たとえば、出力部503は、I/F308によりネットワークNWを介してWebダッシュボード204へアラートに関するメールを送信する。これに限らず、たとえば、出力部503は、I/F308によりネットワークNWを介してWebダッシュボード204のディスプレイへアラートを表示させる。
【0040】
制御部504は、出力部503による警報の出力と、抑制部505による警報の出力の抑制と、のうちいずれか一方が行なわれてから所定時間経過するまで、抑制部505に警報の出力を抑制させる制御を行なう。具体的には、たとえば、制御部504は、観測時刻更新部511と間隔判断部512を有している。間隔判断部512は、観測時刻更新部511による更新に先立って、あらたに条件を満たした観測データが得られた観測日時と記憶装置に保存されている観測日時との時間間隔が、所定時間tと一致するか否かを判断する。具体的には、たとえば、間隔判断部512は、現日時を取得する。たとえば、間隔判断部512は、判別キーが「東京」であり、アラート名が「在庫アラート」であるレコードをアラート発生管理テーブル400から特定する。たとえば、間隔判断部512は、特定したレコードが有する最終観測日時のフィールドの値と現日時との時間間隔が所定時間tと一致するか否かを判断する。また、たとえば、間隔判断部512は、特定したレコードがない場合、該時間間隔が、所定時間tと一致しないと判断することとする。
【0041】
観測時刻更新部511は、条件判断部502により条件を満たしていると判断された観測データの観測時刻を記憶装置に上書き保存する。具体的には、たとえば、観測時刻更新部511は、条件判断部502により条件を満たしていると判断された場合、現日時を間隔判断部512により特定されたレコードの最終観測日時のフィールドに上書き保存する。また、たとえば、間隔判断部512により該レコードが特定されなかった場合、観測時刻更新部511は、アラート発生管理テーブル400へアラート名のフィールドに「在庫アラート」を登録する。そして、観測時刻更新部511は、判別キーのフィールドに「東京」、最終観測日時のフィールドに現日時を登録する。これにより、アラート発生管理テーブル400にあらたなレコードが生成される。
【0042】
抑制部505は、制御部504による制御に応じて出力部503による警報の出力を抑制する。具体的には、たとえば、抑制部505は、間隔判断部512によって一致すると判断された場合は出力部503によるアラートの出力を停止するよう制御する。具体的には、たとえば、抑制部505は、間隔判断部512によって不一致と判断された場合は出力部503にアラートを出力させる。
【0043】
(実施例1にかかるモニタリングサーバ201による監視手順)
図6は、モニタリングサーバ201による監視手順を示すフローチャートである。モニタリングサーバ201が、取得部501により所定時間t経過したか否かを判断する(ステップS601)。モニタリングサーバ201が、所定時間t経過していないと判断した場合(ステップS601:No)、ステップS601へ戻る。
【0044】
モニタリングサーバ201が、所定時間t経過したと判断した場合(ステップS601:Yes)、取得部501により、観測データを取得する(ステップS602)。モニタリングサーバ201が、現在の日時を取得する(ステップS603)。モニタリングサーバ201が、観測データの加工が必要か否かを判断する(ステップS604)。
【0045】
モニタリングサーバ201が、観測データの加工が必要であると判断した場合(ステップS604:Yes)、観測データを加工し(ステップS605)、ステップS606へ移行する。観測データの加工は、たとえば、係数を掛けたりなどの処理である。
【0046】
ステップS604において、モニタリングサーバ201が、観測データの加工が必要でないと判断した場合(ステップS604:No)、観測データまたは加工後の観測データを対象データに設定する(ステップS606)。そして、モニタリングサーバ201が、判定処理を実施し(ステップS607)、ステップS601へ戻る。
【0047】
図7は、図6で示した判定処理(ステップS607)の詳細な説明を示すフローチャートである。まず、モニタリングサーバ201が、対象データが条件を満たしているか否かを判断し(ステップS701)、対象データが条件を満たしていないと判断した場合(ステップS701:No)、ステップS601へ戻る。すなわち、対象データが条件を満たしていないと判断した場合には、何も処理をしない。
【0048】
モニタリングサーバ201が、対象データが条件を満たしていると判断した場合(ステップS701:No)、アラート発生管理テーブル400から対象データに関するレコードを特定する(ステップS702)。モニタリングサーバ201が、特定できたか否かを判断し(ステップS703)、特定できた場合(ステップS703:Yes)、現在の日時と最終観測日時との差分を算出する(ステップS704)。
【0049】
モニタリングサーバ201が、差分と所定時間tが一致するか否かを判断する(ステップS705)。モニタリングサーバ201が、差分と所定時間tが一致すると判断した場合(ステップS705:Yes)、抑制部505により、ステップS708へ移行する。すなわち、差分と所定時間tが一致する場合には、出力部503によるアラートの出力がされない。差分と所定時間tが一致する場合とは、すなわち、継続して観測データが条件を満たしていないことを示している。よって、継続して観測データが条件を満たす場合、1回目の判定時のみにアラートが出力される。
【0050】
モニタリングサーバ201が、差分と所定時間tが一致しないと判断した場合(ステップS705:No)、出力部503により、ステップS707へ移行する。ステップS703において、モニタリングサーバ201が、特定できなかった場合(ステップS703:No)、アラート発生管理テーブル400に新規レコードを追加する(ステップS706)。ステップS706、またはステップS705のNoの場合のつぎに、モニタリングサーバ201が、出力部503により、アラートを出力し(ステップS707)、ステップS708へ移行する。
【0051】
ステップS705のYesの場合、またはステップS707のつぎに、モニタリングサーバ201が、観測時刻更新部511により、特定したレコードまたは新規レコードの最終観測日時を現在の日時に更新し(ステップS708)、ステップS601へ戻る。
【0052】
(実施例2)
図8は、実施例2を示す説明図である。実施例2では、観測データが条件を満たし、かつ記憶装置に記憶された最終観測時刻と現時刻との差分が、所定時間tと一致する場合の一致回数が所定回数以上の場合に、再度アラートを出力させる。図8では、所定回数が4回であるため、一致回数が4回となると、アラートが出力されている。たとえば、所定回数は、過去の観測データが条件を満たさなくなるまでに要した期間に基づいて決定されることとする。これにより、観測データが条件を満たす場合が長期に渡り継続したら、再度アラートを出力させることができる。
【0053】
また、実施例2では、実施例1で説明した部やデータと同一な部やデータについては同一符号を付し、その説明を省略する。
【0054】
(実施例2にかかるアラート発生管理テーブル)
図9は、実施例2にかかるアラート発生管理テーブルの一例を示す説明図である。アラート発生管理テーブル900は、アラート名、判別キー、一致回数、最終観測日時のフィールドを有する。アラート名のフィールドには、たとえば、在庫アラートなどのアラートの種類が登録される。判別キーのフィールドには、たとえば、「東京」や「大阪」などの地名が登録される。一致回数のフィールドには、たとえば、観測データが条件を満たすようになってからの回数が登録される。最終観測日時のフィールドには、たとえば、観測データが条件を満たした場合の観測データの観測日時が順次上書きされて登録される。
【0055】
各フィールドに値が設定されることによりレコード(901−1,901−2)が登録される。アラート発生管理テーブル900については、RAM303、磁気ディスク305、光ディスク307などの記憶装置に記憶されていることとする。
【0056】
(実施例2にかかる平均一致回数管理テーブル)
図10は、実施例2にかかる平均一致回数管理テーブルの一例を示す説明図である。平均一致回数管理テーブル1000は、アラート名、判別キー、平均一致回数、更新回数、標準偏差のフィールドを有する。アラート名のフィールドには、たとえば、「在庫アラート」などのアラートの種類が登録される。判別キーのフィールドには、たとえば、「東京」や「大阪」などの地名が登録される。
【0057】
平均一致回数のフィールドには、あらたに条件を満たした観測データが得られた観測時刻とアラート発生管理テーブル900に記憶された観測時刻との時間間隔が、所定時間tと一致すると判断された一致回数の平均値が登録される。平均値の初期値については、定義クライアント203へ業務管理者の操作により入力されることとする。更新回数のフィールドには、平均一致回数の更新回数が登録される。標準偏差のフィールドには、平均一致回数の標準偏差が登録される。
【0058】
各フィールドに値が設定されることによりレコード(1001−1,1001−2)が登録される。平均一致回数管理テーブル1000については、RAM303、磁気ディスク305、光ディスク307などの記憶装置に記憶されていることとする。
【0059】
図11は、実施例2にかかるモニタリングサーバ201の機能ブロックの一例を示す説明図である。モニタリングサーバ201は、取得部1101と、条件判断部1102と、出力部1103と、制御部1104と、抑制部1105と、を有している。取得部1101〜抑制部1105は、具体的には、たとえば、図3に示したROM302、RAM303、磁気ディスク305、光ディスク307などの記憶装置に記憶された監視プログラムにコーディングされていることとする。CPU301が記憶装置から監視プログラムを読み出し、監視プログラムにコーディングされた処理を実行することにより、取得部1101〜抑制部1105はその機能が実現される。
【0060】
取得部1101、条件判断部1102、出力部1103、抑制部1105の詳細な説明については、実施例1で示したそれぞれ取得部501、条件判断部502、出力部503、抑制部505の詳細と同一であるため、詳細な説明を省略する。
【0061】
制御部1104は、観測時刻更新部1111と、間隔判断部1112と、一致回数計数部1113と、異常値判断部1114と、所定回数更新部1115と、更新回数計数部1116と、ばらつき算出部1117と、を有している。観測時刻更新部1111、間隔判断部1112の詳細な説明については、実施例1で示したそれぞれ観測時刻更新部511、間隔判断部512の詳細と同一であるため、詳細な説明を省略する。
【0062】
制御部1104は、所定回数連続で抑制部1105に警報の出力を抑制させる場合に記所定回数目の警報の出力は抑制させない制御を行なう。さらに、制御部が、抑制させない制御を、抑制させる制御を行なった回数の平均に基づいて設定される回数に応じて行なう。具体的には、制御部1104は、一致回数計数部1113と、異常値判断部1114と、所定回数更新部1115と、更新回数計数部1116と、ばらつき算出部1117と、によって処理が行われる。実施例2では、抑制させる制御を行なった回数は、一致回数c−1である。
【0063】
一致回数計数部1113は、間隔判断部1112によって一致すると判断された場合、連続して一致すると判断された一致回数cを計数する。具体的には、たとえば、一致回数計数部1113は、アラート発生管理テーブル900の観測データに関するレコードの一致回数のフィールドの値をカウントアップする。
【0064】
また、一致回数計数部1113は、間隔判断部1112によって一致しないと判断された場合、一致回数をリセットする。具体的には、たとえば、一致回数計数部1113は、アラート発生管理テーブル900の観測データに関するレコードの一致回数のフィールドの値を0に設定する。
【0065】
抑制部1105は、間隔判断部1112によって一致すると判断され、かつ一致回数計数部1113により計数された一致回数が所定回数以上である場合は出力部1103にアラートを出力させる。ここで、所定回数は、平均一致回数管理テーブル1000の平均一致回数のフィールドに登録された値(以下、「平均一致回数a」と称する。)である。
【0066】
異常値判断部1114は、間隔判断部1112によって一致しないと判断された場合、一致回数が異常値であるか否かを平均一致回数と平均一致回数のばらつき情報とに基づいて判断する。ここで、ばらつき情報とは、平均一致回数管理テーブル1000の標準偏差のフィールドに登録された値(以下省略して「標準偏差σ」と称する。)である。
【0067】
具体的には、たとえば、異常値判断部1114は、式(1),(2)のいずれか一方を満たす場合に一致回数cが異常値であると判断する。
・一致回数c>平均一致回数a+2×標準偏差σ・・・(1)
・一致回数c<平均一致回数a−2×標準偏差σ・・・(2)
【0068】
詳細には、上記式(1)または式(2)を満たす場合には、一致回数cは過去の一致回数cが約95[%]が含まれる値の範囲外の値であると判断される。
【0069】
所定回数更新部1115は、異常値判断部1114により一致回数cが異常値でないと判断された場合、一致回数計数部1113による一致回数cのリセット前に、一致回数cと平均一致回数aと平均一致回数aの更新回数に基づき、平均一致回数aを更新する。ここで、平均一致回数aの更新回数は、平均一致回数管理テーブル1000の更新回数のフィールドに登録された値(以下、「更新回数u」)である。
【0070】
具体的には、たとえば、所定回数更新部1115は、下記式(3)に基づいて平均一致回数aを算出して更新する。
・平均一致回数a=(平均一致回数a×更新回数u+一致回数c)÷(更新回数u+1)・・・(3)
【0071】
また、所定回数更新部1115は、異常値判断部1114により一致回数cが異常値であると判断された場合、平均一致回数aを更新しない。
【0072】
更新回数計数部1116は、所定回数更新部1115による一致回数cの更新後、更新回数uを計数する。具体的には、たとえば、更新回数計数部1116は、更新回数uをインクリメントする。また、更新回数計数部1116は、異常値判断部1114により一致回数cが異常値であると判断された場合、更新回数uを計数しない。
【0073】
ばらつき算出部1117は、異常値判断部1114により一致回数cが異常値でないと判断された場合、一致回数cと更新回数計数部1116による計数後の更新回数uに基づいて標準偏差σを算出する。具体的には、たとえば、ばらつき算出部1117は、下記式(4)により分散σ2uを算出することにより、標準偏差σを算出する。
・分散σ2u=(1/更新回数u)×((更新回数u−1)×分散σ2(u-1)+(一致回数c−平均一致回数a)2)・・・(4)
【0074】
式(4)では分散σ2(u-1)を用いているが、これに限らず、たとえば、過去の一致回数をすべて記憶させておいて、分散σ2uを算出してもよい。
【0075】
また、ばらつき算出部1117は、異常値判断部1114により一致回数cが異常値であると判断された場合、標準偏差σを再計算しない。
【0076】
(実施例2にかかるモニタリングサーバ201による監視手順)
図12は、実施例2にかかる図6で示した判定処理(ステップS607)の詳細な説明を示すフローチャートである。実施例2にかかるモニタリングサーバ201による監視手順については、具体的には、判定処理(ステップS607)を除く処理についてはすべて同一であるため、ここでは、実施例2にかかる判定処理(ステップS607)についてのみ説明する。
【0077】
モニタリングサーバ201が、条件判断部1102により、対象データが条件を満たすか否かを判断し(ステップS1201)、対象データが条件を満たしていないと判断した場合(ステップS1201:No)、ステップS601へ戻る。モニタリングサーバ201が、対象データが条件を満たしていると判断した場合(ステップS1201:Yes)、アラート発生管理テーブル900と平均一致回数管理テーブル1000から対象データに関するレコードを特定する(ステップS1202)。
【0078】
モニタリングサーバ201が、特定したか否かを判断し(ステップS1203)、特定したと判断した場合(ステップS1203:Yes)、間隔判断部1112により、現在の日時と最終観測日時との差分を算出する(ステップS1204)。
【0079】
モニタリングサーバ201が、間隔判断部1112により、差分と所定時間tが一致するか否かを判断し(ステップS1205)、一致すると判断した場合(ステップS1205:Yes)、一致回数計数部1113により、一致回数をカウントアップする(ステップS1206)。
【0080】
モニタリングサーバ201が、一致回数>平均一致回数であるか否かを判断する(ステップS1207)。モニタリングサーバ201が、一致回数>平均一致回数であると判断した場合(ステップS1207:Yes)、(一致回数−1)が平均一致回数の倍数であるか否かを判断する(ステップS1208)。たとえば、平均一致回数の倍数については、小数点の値を切り捨てまたは四捨五入した値としてもよい。
【0081】
モニタリングサーバ201が、(一致回数−1)が平均一致回数の倍数であると判断した場合(ステップS1208:Yes)、出力部1103により、アラートを出力し(ステップS1209)、ステップS1214へ移行する。これにより、連続して一致する場合に、平均一致回数ごとに1回アラートを出力させることができる。
【0082】
ステップS1207において、モニタリングサーバ201が、一致回数>平均一致回数でないと判断した場合(ステップS1207:No)、ステップS1214へ移行する。ステップS1208において、モニタリングサーバ201が、(一致回数−1)が平均一致回数の倍数でないと判断した場合(ステップS1208:No)、ステップS1214へ移行する。
【0083】
ステップS1205において、モニタリングサーバ201が、差分と所定時間tが一致しないと判断した場合(ステップS1205:No)、平均一致回数の算出処理を実行する(ステップS1210)。モニタリングサーバ201が、一致回数計数部1113により、一致回数をリセットし(ステップS1211)、出力部1103により、アラートを出力し(ステップS1212)、ステップS1214へ移行する。
【0084】
ステップS1203において、モニタリングサーバ201が、特定していないと判断した場合(ステップS1203:No)、アラート発生管理テーブル900と平均一致回数管理テーブル1000のそれぞれに値を設定することで新規レコードを追加し(ステップS1213)、ステップS1212へ移行する。
【0085】
ステップS1207のNoの場合、ステップS1208のNoの場合、ステップS1209、ステップS1212のつぎに、モニタリングサーバ201が、観測時刻更新部1111により、最終観測日時を現在の日時に更新し(ステップS1214)、ステップS601へ移行する。
【0086】
図13は、図12で示した平均一致回数の算出処理(ステップS1210)の詳細な説明を示すフローチャートである。モニタリングサーバ201が、異常値判断部1114により、一致回数が異常値であるか否かを判断する(ステップS1301)。異常値であるか否かについては、上述したように式(1)または式(2)を満たすか否かによって判断される。
【0087】
モニタリングサーバ201が、一致回数が異常値であると判断した場合(ステップS1301:Yes)、ステップS1211へ移行する。モニタリングサーバ201が、一致回数が異常値でないと判断した場合(ステップS1301:No)、所定回数更新部1115により、一致回数に基づきあらたに平均一致回数を算出して更新する(ステップS1302)。平均一致回数については、上述した式(3)に基づいて算出される。
【0088】
モニタリングサーバ201が、更新回数計数部1116により、更新回数をカウントアップし(ステップS1303)、ばらつき算出部1117により、標準偏差を算出して更新し(ステップS1304)、ステップS1211へ移行する。標準偏差については、式(4)で得られる分散に基づいて算出される。
【0089】
以上説明したように、所定時間ごとに得られる観測データが条件を継続して満たしている場合、前回条件を満たした観測時刻を記憶し、記憶された観測時刻と観測データの観測時刻との差分が所定時間と一致したときのみアラートを出力する。これにより、アラートの過剰出力を防止することができる。
【0090】
観測データが条件を満たしている場合、すなわちトラブルが発生している場合には処理を行うが、観測データが条件を満たしていない場合、すなわちトラブルが発生していない場合には特に処理をさせない。トラブルが発生していない状態の方が、トラブルが発生している状態よりもはるかに長い期間である。トラブルが発生していない状態では処理を行わないことにより、監視負荷を軽減することができる。
【0091】
また、観測データが条件を満たしている状態が長期間継続する場合、すなわち、トラブルが発生している状態が長期間継続している場合、過去にトラブルの解消までに要した期間に基づいて再度アラートを出力させる。記憶された観測時刻と観測データの観測時刻との差分が所定時間と一致した一致回数に基づいて該期間が決定されている。
【0092】
また、平均から大きく乖離した一致回数をばらつき情報を用いて取り除き、平均一致回数を算出することにより、平均一致回数を最適化することができ、最適なタイミングでアラートを出力させることができる。
【0093】
なお、本実施の形態で説明した監視方法は、あらかじめ用意された監視プログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本監視プログラムは、ハードディスク、フレキシブルディスク、CD−ROM、MO、DVD等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また本監視プログラムは、インターネット等のネットワークNWを介して配布してもよい。
【符号の説明】
【0094】
201 モニタリングサーバ
503,1103 出力部
504,1104 制御部
505,1105 抑制部
【特許請求の範囲】
【請求項1】
所定時間間隔で得られる観測データについて、所定の条件を満たす場合に、警報を出力する出力手段と、
制御に応じて前記出力手段による前記警報の出力を抑制する抑制手段と、
前記出力手段による前記警報の出力と、前記抑制手段による前記警報の出力の抑制と、のうちいずれか一方が行なわれてから前記所定時間経過するまで、前記抑制手段に前記警報の出力を抑制させる制御を行なう制御手段と、
を備えることを特徴とする監視装置。
【請求項2】
前記制御手段は、
所定回数連続で前記抑制手段に前記警報の出力を抑制させる場合に、前記所定回数目の前記警報の出力は抑制させない制御を行なう、
ことを特徴とする請求項1に記載の監視装置。
【請求項3】
前記制御手段が、
前記抑制させない制御を、前記抑制させる制御を行なった回数の平均に基づいて設定される回数に応じて行なう、
ことを特徴とする請求項2に記載の監視装置。
【請求項4】
コンピュータが、
所定時間間隔で得られる観測データについて、所定の条件を満たす場合に、警報を出力し、
制御に応じて前記警報の出力を抑制し、
前記警報の出力と、前記警報の出力の抑制と、のうちいずれか一方が行なわれてから前記所定時間経過するまで、前記警報の出力を抑制させる制御を行なう、
処理を実行することを特徴とする監視方法。
【請求項5】
コンピュータに、
所定時間間隔で得られる観測データについて、所定の条件を満たす場合に、警報を出力する出力処理と、
制御に応じて前記警報の出力を抑制する抑制処理と、
前記出力処理による警報の出力と、前記抑制処理による警報の出力の抑制と、のうちいずれか一方が行なわれてから前記所定時間経過するまで、前記警報の出力を抑制させる制御を行なう制御処理と、
を実行させることを特徴とする監視プログラム。
【請求項1】
所定時間間隔で得られる観測データについて、所定の条件を満たす場合に、警報を出力する出力手段と、
制御に応じて前記出力手段による前記警報の出力を抑制する抑制手段と、
前記出力手段による前記警報の出力と、前記抑制手段による前記警報の出力の抑制と、のうちいずれか一方が行なわれてから前記所定時間経過するまで、前記抑制手段に前記警報の出力を抑制させる制御を行なう制御手段と、
を備えることを特徴とする監視装置。
【請求項2】
前記制御手段は、
所定回数連続で前記抑制手段に前記警報の出力を抑制させる場合に、前記所定回数目の前記警報の出力は抑制させない制御を行なう、
ことを特徴とする請求項1に記載の監視装置。
【請求項3】
前記制御手段が、
前記抑制させない制御を、前記抑制させる制御を行なった回数の平均に基づいて設定される回数に応じて行なう、
ことを特徴とする請求項2に記載の監視装置。
【請求項4】
コンピュータが、
所定時間間隔で得られる観測データについて、所定の条件を満たす場合に、警報を出力し、
制御に応じて前記警報の出力を抑制し、
前記警報の出力と、前記警報の出力の抑制と、のうちいずれか一方が行なわれてから前記所定時間経過するまで、前記警報の出力を抑制させる制御を行なう、
処理を実行することを特徴とする監視方法。
【請求項5】
コンピュータに、
所定時間間隔で得られる観測データについて、所定の条件を満たす場合に、警報を出力する出力処理と、
制御に応じて前記警報の出力を抑制する抑制処理と、
前記出力処理による警報の出力と、前記抑制処理による警報の出力の抑制と、のうちいずれか一方が行なわれてから前記所定時間経過するまで、前記警報の出力を抑制させる制御を行なう制御処理と、
を実行させることを特徴とする監視プログラム。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【公開番号】特開2013−8162(P2013−8162A)
【公開日】平成25年1月10日(2013.1.10)
【国際特許分類】
【出願番号】特願2011−139907(P2011−139907)
【出願日】平成23年6月23日(2011.6.23)
【出願人】(000005223)富士通株式会社 (25,993)
【Fターム(参考)】
【公開日】平成25年1月10日(2013.1.10)
【国際特許分類】
【出願日】平成23年6月23日(2011.6.23)
【出願人】(000005223)富士通株式会社 (25,993)
【Fターム(参考)】
[ Back to top ]