JP4819014B2 - ログ解析方法、ログ格納装置及びプログラム - Google Patents

ログ解析方法、ログ格納装置及びプログラム Download PDF

Info

Publication number
JP4819014B2
JP4819014B2 JP2007243570A JP2007243570A JP4819014B2 JP 4819014 B2 JP4819014 B2 JP 4819014B2 JP 2007243570 A JP2007243570 A JP 2007243570A JP 2007243570 A JP2007243570 A JP 2007243570A JP 4819014 B2 JP4819014 B2 JP 4819014B2
Authority
JP
Japan
Prior art keywords
log
abnormality
occurrence
false alarm
event
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
Application number
JP2007243570A
Other languages
English (en)
Other versions
JP2009075817A (ja
JP2009075817A5 (ja
Inventor
友洋 中村
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2007243570A priority Critical patent/JP4819014B2/ja
Publication of JP2009075817A publication Critical patent/JP2009075817A/ja
Publication of JP2009075817A5 publication Critical patent/JP2009075817A5/ja
Application granted granted Critical
Publication of JP4819014B2 publication Critical patent/JP4819014B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Landscapes

  • Debugging And Monitoring (AREA)

Description

本発明は、高信頼なコンピュータシステムを実現するために、異常検出もしくは異常予測を実現するログ解析技術に関する。
コンピュータシステムは、社会の様々な分野で利用され、社会活動に欠かせないものとなっている。それに伴って、コンピュータシステムの高信頼化に対する要求も高まっている。しかし、Web3層システム(業務システム)のような複数の計算機からなる複雑なシステムでは、高信頼化を実現する上で欠かせない、システムの異常の検出や予測の実現が難しくなっている。最近ではWeb3層等のシステムを構成するハードウェア及びソフトウェアのマルチベンダ化や処理の分散化によって、この傾向はますます強まっている。
システムの異常を検出・予測するには、異常を検出するためのプローブをシステムに埋め込むか、システムから出力されるログから異常を検出するためのルールを用意するのが基本的な対策である。ところが、前記のようにシステムの複雑化やブラックボックス化によって、すべての異常に対してこのような対策がとれなくなっている。場合によっては、どのような異常が起こりえるかを列挙することも難しくなっている。しかしながら、コンピュータシステムの社会インフラストラクチャとしての重要性は増大しており、異常の検出・予測を迅速かつ正確に行う必要がある。
そこで、システムから出力されるログを、正常稼動時に出力されたログと比較して、変化が見られた場合に、システムの異常が起こった、もしくは起こる可能性があると判定する統計的手法を用いたログ解析技術を、異常の検出・予測に利用しようとする動きがある。例えば、非特許文献1や非特許文献2では、Webシステムのアクセスログに対して通常時のログと現在のログを比較して、Webシステムでの異常の発生を検出したり予測したりできることが開示されている。
非特許文献1や非特許文献2でも指摘されているが、このようなログ解析技術を利用したコンピュータシステムの異常の検出・予測では、フォールスポジティブ(以下では、誤報とフォールスポジティブを同義語とする)と呼ばれる現象が問題となることが知られている。フォールスポジティブとは、実際には異常が発生していないが、ログ解析結果では異常の発生を検出、もしくは予測してしまう現象である。フォールスポジティブが発生する理由はコンピュータシステムの構成や、ログ解析に利用するログの特性、ログ解析技術で利用するアルゴリズムなどにより異なり、様々であるが、大きく分けると以下の3つが挙げられる。
(A)時々現れる異常ではないイベントによってフォールスポジティブが発生する場合
(B)ログ解析で利用する入力データ(ログ)に含まれているノイズによってフォールスポジティブが発生する場合
(C)ログ解析で利用するアルゴリズムやデータの前処理に不適切なものが含まれてフォールスポジティブが発生する場合
これらに対して、部分的な解決策が従来技術により与えられている。(A)に対しては特許文献1および特許文献2が、(B)に対しては特許文献3が、(C)に対しては特許文献4、特許文献5および特許文献6がそれぞれ部分的な解決策を与えている。
上記(A)の「時々現れる異常ではないイベントによってフォールスポジティブが発生する」問題に対しては、特許文献1の「時系列データ検索システム」(特開2003−132088)で開示されるように、ウェーブレット変換を利用してデータ波形の特徴を保存し検索する時系列データ検索システムにより、時々現れる異常ではないイベントのログの特徴抽出をすることで部分的な解決が実現できる。また特許文献2の「障害原因発見装置、障害原因対策装置、及びそれらの方法」(特開平7−311691)で開示されているように、環境情報の変化と異常の発生原因及び対策の情報の組を用意して、環境情報の変化から異常の検出、対策を実行する方法において、異常の発生原因に対して正常なイベントであると登録することで、時々現れる異常ではないイベントによるフォールスポジティブの発生を低減することができる。
上記(B)の「ログ解析で利用する入力データ(ログ)に含まれているノイズによってフォールスポジティブが発生する」問題に対しては、特許文献3の「状態変化検出装置」(特開平7−301544)で開示されているように、ログを取得するサンプリング間隔の連続2区間で状態変化を検出したらノイズの影響と判定してサンプリング間隔を調整する方法により、ノイズによるフォールスポジティブの発生を低減することができる。
上記(C)の「ログ解析で利用するアルゴリズムやデータの前処理に不適切なものが含まれてフォールスポジティブが発生する」問題に対しては、特許文献4の「異常診断装置、異常予兆診断装置、及び不要事象検出装置」(特開2003−271239)で開示されている、システムの正常時のパターンを覚えておいて正常時とのずれが一定量を超えたら異常と判定し、異常と判定されたときのパターンは記憶しない方法により、コンピュータシステムの異常を判定する学習アルゴリズムに異常時のログを学習させなくすることでフォールスポジティブの発生を低減することができる。また、特許文献5の「異常検出装置」(特開2001−74799)で開示されている、フーリエ変換を利用してデータの周波数成分の変化を検出して異常の有無を判定する方法により、時間成分に現れない異常を検出でき、検出アルゴリズムが改善され、フォールスポジティブの発生を低減することができる。さらに特許文献6の「ネットワーク監視システム及びその方法、プログラム」(特開2005−285040)で開示されているように、異常の予兆を検出する監視によりシステムの異常を予測すると、その内容に応じたルールに従って詳細な情報を収集し、その結果異常ではないと判定したらその監視を止める方法により、複数の監視レベルを設けて実際に異常が発生しているか否かを詳細に判定することで、フォールスポジティブの発生を低減することができる。
特開2003−132088 公報 特開平7−311691 公報 特開平7−301544 公報 特開2003−271239 公報 特開2001−74799 公報 特開2005−285040 公報 P. Bodik、 G. Friedman、 L. Biewald、 H. Levine、 G. Candea、 K. Patel、 G. Tolle、 J. Hui、 A. Fox、 M. I. Jordan and D. Patterson、 "Combining Visualization and Statistical Analysis to Improve Operator Confidence and Efficiency for Failure Detection and Localization"、The 2nd IEEE International Conference on Autonomic Computing (ICAC '05)、 Seattle、 June 2005. 中村友洋、「Webアプリケーションの障害を予測する``アクセス時間解析方式''の提案」、 情報処理学会論文誌、情報処理学会発行、2006年9月、コンピューティングシステム、Vol.47、No. SIG12 (ACS15)、pp.349−357
本発明が対象とする、コンピュータシステムの高信頼化のための、ログ解析技術による異常の検出・予測では、異常の検出・予測の感度と精度のバランスをいかに取るかが課題となっている。一般に、異常の発生を逃さずに検出・予測しようとして検出・予測の感度を上げると、実際には異常が発生していない時にも異常の発生を検出したり予測したりしてしまうフォールスポジティブの発生が増加し、検出・予測の精度が低下してしまうというトレードオフが存在する。フォールスポジティブが増加するとログ解析技術を利用した異常の検出・予測に対する信頼が失われるため、フォールスポジティブを低減する必要がある。ただし、実際には異常が発生しているにも拘わらず異常の検出・予測がなされない状態をフォールスネガティブと呼ぶが、フォールスネガティブを発生させないことが前提となる。つまり、フォールスネガティブを発生させずに、いかにフォールスポジティブの発生を低減するかが課題である。
背景技術の項で説明したように、フォールスポジティブが発生する原因は、大きく分けて以下の3つがある。
(A) 時々現れる異常ではないイベントによってフォールスポジティブが発生する場合
(B) ログ解析で利用する入力データ(ログ)に含まれているノイズによってフォールスポジティブが発生する場合
(C) ログ解析で利用するアルゴリズムやデータの前処理に不適切なものが含まれてフォールスポジティブが発生する場合
この中で、(B)、(C)に関しては、背景技術で示した従来技術によってほぼ解決されているが、(A)に関しては従来技術だけでは十分な解決ができていない。
そこで、本発明は、時々現れる異常ではないイベントによって発生するフォールスポジティブを低減し、異常の検出・予測に対する信頼を高めることを目的とする。
本発明は、ログ解析技術を利用したコンピュータシステムの異常の検出・予測におけるフォールスポジティブの発生を低減する方法および装置で、従来の異常の検出・予測方法および装置に加える形で実現する。
すなわち、計算機から出力されるログを解析して、計算機の異常を検出もしくは予測するログ解析方法において、前記計算機からログを受け付け、記受け付けたログを解析して、前記計算機に異常が発生したことを検出、または前記計算機に異常の発生を予測し、前記ログと、予め設定した誤報のルールとを比較して、前記計算機の異常の検出または異常の予測において誤報の発生を判定し、前記誤報の発生が判定されたときには、前記計算機の異常発生の検出または前記計算機の異常発生の予測において誤報の発生を低減する。
つまり、異常の検出・予測方法および装置の実現方法そのものは従来技術でよく、基本的にはどのようなログ解析技術を利用した異常の検出・予測方法であっても、本発明による方法および装置によってフォールスポジティブの発生を低減させることができる。
本発明により、従来技術で実現される異常の検出・予測方法および装置に加える部分は、大きく分けて5つのステップで構成される。5つのステップは必ずすべてが必要なわけではなく、一部だけでも本発明が解決しようとする課題の一部を解決できる。以下に5つのステップについて示す。
[ステップ1] フォールスポジティブの発生の通知もしくはフォールスポジティブの発生パターンの登録。異常の検出・予測結果がフォールスポジティブであった場合に、フォールスポジティブの発生を通知して、どのような場合にフォールスポジティブが発生するかを登録する。もしくは、例えば周期的にフォールスポジティブ発生することがわかっているような場合に、その周期を登録する。
[ステップ2] フォールスポジティブを起す状態の登録。フォールスポジティブが発生したときのログを登録する。登録するものは、ログそのものでなく、例えば通常時のログとの差分や、ログの発生頻度などの情報でもよい。またステップ1に示したフォールスポジティブの発生周期などの発生条件などでもよい。
[ステップ3] フォールスポジティブを起す状態の検出。フォールスポジティブ発生時のログや発生条件と、現在のログや状態を比較することで、フォールスポジティブの発生を検出・予測する。
[ステップ4] フォールスポジティブの発生可能性を低減する処理。例えば、フォールスポジティブの発生が検出・予測された場合に、ログ解析の結果を無効化したり、フォールスポジティブを起す可能性のあるログを削除したりする。
[ステップ5] 処理結果の通知。フォールスポジティブ発生可能性を低減する処理を行ったことを通知する。もしくは、フォールスポジティブ発生可能性を低減する処理を行った場合と、行わなかった場合の両方のログ解析結果を通知する。
したがって、課題を解決するための手段に示した5つのステップによれば、例えば、フォールスポジティブの発生時にフォールスポジティブを発生させたログの登録を行い、以降で同様のログが出力された場合にそれを検出し、そのログを削除することでログ解析結果がフォールスポジティブにならないようにすることが可能となる。つまり、本発明によれば、従来技術で実現されるログ解析技術を利用したコンピュータシステムの異常の検出・予測に関し、フォールスポジティブの発生を低減して異常の検出精度または予測精度を向上でき、ログ解析技術による異常の検出・予測に対する信頼を高め、コンピュータシステムの高信頼化を実現できる効果がある。
さらに、ログ解析技術による異常の検出・予測の精度向上により、異常の検出・予測を全自動化もしくは半自動化することが可能となるので、従来よりもコンピュータシステムの運用管理に要するコストを低減できる。
以下、本発明の一実施形態を添付図面に基づいて説明する。
本発明によるコンピュータシステムの異常検出における誤報発生(フォールスポジティブ)を低減するログ解析処理の一例を図1から図20を使って説明する。
図1は、本発明を適用する計算機システムの基本的な構成を示すブロック図である。コンピュータシステム101は、異常の検出・予測を行う対象となるコンピュータシステムである。コンピュータシステム101は、1台以上の計算機102から構成される。計算機102は、演算処理を行うCPUと、プログラムやデータを格納するメモリを備え、コンピュータシステム101が提供するサービスを実現するための処理を実行する。各計算機102は、1つ以上のログ生成部103を持つ。各ログ生成部103は、各計算機102を構成するハードウェアやソフトウェアの実行状態や、実行した処理や発生したエラーなどのイベント履歴などをログとして生成する。ログ生成部103で生成されたログは、各計算機102や、コンピュータシステム101内外に記録される。このログの記録は、例えば、各計算機102のストレージ装置や、コンピュータシステム101内のストレージ装置、あるいはコンピュータシステム101に接続されたネットワーク上のストレージ装置などに適宜書き込むことで実現できる。
ログ解析部105は、ログ生成部103で生成されたログをネットワーク104経由で取得し、ログを解析することで、コンピュータシステム101の異常の発生を検出または予測する。ログ解析部105は、取得したログからコンピュータシステム101の異常の検出または異常発生の予測を行う検出・予測部106と、コンピュータシステムの異常検出結果または異常の予測結果を出力する結果表示部111から構成される。なお、コンピュータシステム101の異常の検出とは、例えば、ハードウェアの停止や誤動作、ソフトウェアの停止や誤動作などの検出であり、異常の予測とは、例えば、ハードウェアリソースの不足(ストレージ装置やメモリの記憶領域の不足)やCPUやネットワークの過負荷、通常とは異なる処理の実行など、コンピュータシステム101の停止や誤動作を引き起こす可能性のある状態を判定するものである。
さらに、異常検出・予測部106は、ログ収集部107、異常判定部108、結果出力部109から構成される。ログ収集部107は、ネットワーク104を介して、コンピュータシステム101の各計算機102のログ生成部103で生成されたログを収集する。異常判定部108は、ログ収集部107が収集したログから、コンピュータシステム101に異常が発生しているか判定する。異常の発生の判定方法については、上述の非特許文献1や非特許文献2等に記載の公知または周知の方法の他に、異常判定ルールに基づいて判定する方法などがある。ただし、異常の発生の判定方法について、これらに限定するものではない。
異常判定部108の判定結果は、結果出力部109から結果出力パス110を介して結果表示部111に伝達する。結果表示部111は、異常判定結果または異常の予測結果を表示する。
上記図1に示した構成は、コンピュータシステム101の異常の検出・予測を行うログ解析方法に関する、基本的な構成図であるが、本発明が対象とするログ解析方法は、この構成に限定するものではなく、コンピュータシステム101内で生成されたログを解析して異常の発生を検出・予測するすべての方法が対象となる。また、図1に示すログ解析部105は、後述の図20のように計算機で構成される。
図2は、本発明の第1の実施形態による誤報発生時のログを利用した誤報発生の可能性を検出する方法を適用したコンピュータシステムの一例を示すブロック図である。
図2において、コンピュータシステム101は、図1に記載のコンピュータシステム101と同じであるが、コンピュータシステム101内に含まれる計算機102、ログ生成部103は図2では省略してある。以下の図でも同様に、コンピュータシステム101には、図1に示したように計算機102、ログ生成部103が含まれるものとする。
図2において、誤報検出部201は、コンピュータシステム101内で生成されたログを、ネットワーク104を介して取得し、誤報時ログ記憶部202に予め記録されている誤報発生時のログと照合することで、コンピュータシステム101の異常の検出・予測を行う、異常検出・予測部207の解析結果が誤報である可能性を検出する。
より具体的には、誤報検出部201は、比較器205を含み、比較器205はネットワーク104から入力されるコンピュータシステム101の現在のログと、誤報時ログ記憶部202から誤報時ログパス203を介して入力される誤報時のログを比較し、両者が一致もしくは類似した場合に誤報検出結果パス204に誤報発生の可能性を出力する。なお、現在のログと誤報時のログの類似は、例えば、現在のログの発生パターンと、誤報時のログの発生パターンを比較して、パターンが一致したときに双方のログが類似していると判定することができる。異常検出・予測部207は、誤報検出結果パス204から誤報発生の可能性に関する情報を得て、誤報の発生を抑止したり、結果表示部111に対して誤報発生の可能性を通知したりする。誤報検出結果の利用方法については、後で実施例を述べる。
また、図2に示すログ解析部206は、後述の図20のように複数の計算機で構成することができる。そして、ログ解析部206は、図20のように誤報検出部を実行する計算機と、異常検出・予測部を実行する計算機を独立させても良いし、これら2つの機能を同一の計算機で実行するようにしてもよい。また、比較器205で使用する誤報時のログは、予め設定した誤報のルールを用いてもよい。さらに、誤報時ログ記憶部202は、誤報検出部202を実行する計算機のストレージ装置などに格納しておけばよい。
図3(A)、(B)は、本発明による図2に示した方法において、誤報発生時のログ(または誤報のルール)と現在のログとの比較方法の具体的な例を示す図である。まず、図3(A)に基づいて誤報時ログ記憶部202に記録する誤報時ログの例303〜306の生成方法について説明する。
正常時のログ301は、コンピュータシステム101が正常に稼動しており、異常検出・予測部207での異常判定結果も誤報とならない場合のログの例である。この例では、ログはタイムスタンプとイベント名の組を1行で示しており、正常時のログ301では9:00:00から9:00:12までにイベントAとイベントBが交互に合計7回発生している場合を示している。一方、誤報発生時のログ302は、コンピュータシステム101は正常に稼動しているが、異常検出・予測部207での異常判定結果では異常の発生を検出もしくは予測された場合のログの例である。つまり、誤報が発生した際のログである。この例では、9:30:00から9:30:12までにイベントA、イベントB、イベントCの3種類のイベントが順次に発生している。
誤報時ログ記憶部202には、正常時のログ301と誤報発生時のログ302から、例えば図中(例1)から(例4)に示すような誤報時ログ303〜306が登録される。
(例1)誤報時ログ303は、特定の時刻におけるイベントCのログが誤報を発生させるログであることを示している。図3(A)の例では、毎時30分に起こるイベントCが誤報発生の原因である場合、XX=*(任意)、YY=30、ZZ=*(任意)として登録する。なお、XXは「時」を示し、YYは「分」を示し、「ZZ」は秒を示す。
(例2)誤報時ログ304は、4秒間隔でイベントCが発生すると誤報が発生する場合の登録方法である。
(例3)誤報時ログ305は、イベントA、イベントB、イベントCが順番に、それぞれの時間間隔が、イベントAの2秒後にイベントB、イベントBの1秒後にイベントCの場合にイベントCがあることによって誤報が発生する場合の登録方法である。図3(A)で記号#は、#のついたイベントが誤報を発生させる原因となっていることを示している。
(例4)誤報時ログ306は、時刻ではなく、ログに含まれるイベントA、イベントB、イベントCの比が、1:1:1の時に誤報が発生することを示している。ここで、各イベントの比は、例えば、各イベントA〜Cの出現頻度の比などとすればよい。
次に、誤報検出部201での誤報検出方法の具体的な例について図3Bで説明する。ネットワーク104から入力される現在のログ307は、図3(B)において、10:20:30から10:20:38までのログで、7つのイベントを含んでいる。一方、誤報時ログ記憶部202から誤報時ログパス203を介して入力される誤報時ログ304は、イベントCが4秒間隔で発生したときに、誤報が発生することを示している。誤報検出部201では、誤報検出時ログ308に示すように、現在のログの中から4秒間隔で並ぶイベントCのログを比較器205によって検出して、10:20:33と10:20:37に誤報の発生可能性204を異常検出・予測部207へ出力する。誤報の発生可能性204を受信した異常検出・予測部207では、当該ログの無効化を行ってからログ解析を行って、コンピュータシステム101の異常の検出及び予測を行うことで、検出精度及び予測精度を向上させることができる。
なお、図3(A),(B)に示した誤報時ログの例や誤報検出時ログなどは、一例を示したにすぎない。例えば、誤報時ログ記憶部202には、誤報が発生したときのログをそのまま登録するなどの方法も考えられる。
図4は、ログ解析部206で行われる処理の一例を示すフローチャートである。
最初にコンピュータシステム101から誤報検出部201でログを受信する(ステップ2302)。誤報検出部201は誤報時ログ記憶部202に記録されている誤報時ログと、ステップ2302で受信したログを比較して、誤報の発生可能性を検出する(ステップ2303)。
誤報の発生可能性の検出の有無によって処理が分岐する(ステップ2304)。誤報の発生可能性を検出しなかった場合は、異常検出・予測部207はログ収集部107でコンピュータシステム101からログを受信する(ステップ2305)。次に、異常検出・予測部207は異常判定部108で異常の発生の検出・予測を行う(ステップ2306)。異常検出・予測部207は結果出力部109で異常の発生の検出・予測結果を送信する(ステップ2307)。そして結果表示部111で異常の発生の検出・予測結果を表示する(ステップ2308)。
一方、ステップ2304の判定で誤報の発生可能性を検出した場合、ステップ2304に続いてステップ2309が実行される。つまり、異常検出・予測部207に誤報検出部201は誤報検出結果204を送信する(ステップ2309)。異常検出・予測部207は、誤報検出結果に応じて異常判定結果の出力の無効化や、処理の停止などを行う(ステップ2310)。以上の処理フローによって、誤報検出部201を利用した誤報の発生の低減が実現される。これにより、異常検出の精度と異常予測の精度を高めることが可能となる。
図5は、本発明による誤報発生条件を利用した誤報発生の可能性を検出する方法を適用したコンピュータシステムのブロック図である。上記図2に示した誤報検出方法とは別の方法であるが、図2と図5に示した方法を同時に利用することもできる。図2に示した方法との主な違いは、誤報検出部401と誤報検出部401への入力の1つである誤報発生条件記憶部402である。
図5において、誤報検出部401は、コンピュータシステム101内で生成されたログを、ネットワーク104を介して取得し、誤報発生条件記憶部402に記録されている誤報条件と照合することで、コンピュータシステム101の異常の検出・予測を行う。より具体的には、誤報検出部401は、比較器408を含み、比較器408はネットワーク104から入力されるコンピュータシステム101の現在のログと、誤報発生条件記憶部402から誤報発生条件パス403を介して誤報発生条件を入力とする。ただし、現在のログについては、比較器入力パス407を介して比較器408へ入力する経路上にログ入力スイッチ406があり、誤報発生条件に含まれる誤報発生周期に関する情報によって、比較器408に現在のログ104を入力するか、しないかを選択できる。
誤報発生周期とは、例えば1日の中で午前0時から午前1時の間がコンピュータシステムの定期保守時間となっている場合、この1時間を除いた時間についてのみ、誤報検出を行いたい場合などに設定して利用する。これによって、誤報の発生可能性を検出する必要がない場合に、検出をしないようにすることができる。図5のその他の部分については、図2と同様の処理である。
図6(A)、(B)は、本発明による図5に示した方法において、誤報発生条件と現在のログとの比較方法の具体的な例を示す図である。まず、誤報発生条件記憶部402に記録する誤報発生条件の例503〜506の生成方法について図6(A)を参照しながら説明する。定期的に発生するログ501は、毎時00分にだけイベントCが発生する例を示している。一定時間だけ発生するログ502は、午前0時から午前1時の間だけイベントCが発生する例を示している。いずれの例でも、イベントCは限られた回数もしくは時間帯にのみ発生するので、非特許文献1や非特許文献2に記載されているような、通常時のログと現在のログを比較して、その乖離が大きい場合に異常の発生を検出・予測するような手法では、イベントCによって異常の発生が検出されたり予測されたりすることが起こりえる。しかし、定期的に発生するログ501のような毎時00分にだけ発生するようなイベントは、例えば定期的なデータのバックアップや、キャッシュのクリアなどでよく見られるケースであるし、一定時間だけ発生するログ502も、例えば、毎晩実行される定期保守や、毎朝・毎夕実行される起動・終了処理などよく見られるケースである。このように、実際には異常は発生していないものの、ログ解析による異常の発生の検出・予測では異常と判定される可能性がある条件を記録しておくのが、誤報発生条件記憶部402である。
(例1)誤報発生条件503は、特定の時刻に発生するイベントCを誤報発生条件として登録する例である。
(例2)誤報発生条件504は、イベントBの前後で発生するイベントCを誤報発生条件として登録する例である。
(例3)誤報発生条件505は、特定の時間帯(ここでは1時間)のイベントCを誤報発生条件として登録する例である。
(例4)誤報発生条件506は、イベントAに対してイベントCの発生回数が1%未満ならばイベントCが誤報を発生させる可能性があることを誤報発生条件として登録する例である。
図6(A)で示す記号#は、#のついたイベントが誤報を発生させる原因となっていることを示している。次に、誤報検出部401での誤報検出方法の具体的な例について図6(B)で説明する。
ネットワーク104から入力される現在のログ507は、23:59:59から00:00:05までのログで、7つのイベントを含んでいる。一方、誤報発生条件記憶部402から誤報発生条件パス403を介して入力される誤報発生条件508は、午前0時から午前1時の時間帯に発生するイベントCは誤報を発生させる可能性があることを示している。逆にこの時間帯以外は、誤報の発生検出を行わなくても良いことになる。そこで、誤報発生周期パス405を介して、ログ入力スイッチ406を午前0時から午前1時までの間だけログを通す状態にする。すると誤報検出部401に入力される、選択されたログ509は6つのイベントだけになる。誤報検出部401では、誤報発生条件508に誤報を発生させる可能性のあるイベントとして登録されているイベントCを検出する。誤報検出部401は、誤報の発生可能性404を異常検出・予測部410へ出力する。誤報の発生可能性404を受信した異常検出・予測部410では、当該ログの無効化を行ってからログ解析を行って、コンピュータシステム101の異常の検出及び予測を行うことで、検出精度及び予測精度を向上させることができる。
なお、ログ入力スイッチ406を省略し、誤報検出部401で午前0時から午前1時までの間のログだけを誤報検出する方法でもよい。
図7は、ログ解析部409で行われる処理の一例を示すフローチャートである。
最初にコンピュータシステム101から誤報検出部401でログを受信する(ステップ2402)。誤報検出部401は誤報発生条件記憶部402に記録されている誤報発生条件(誤報発生周期)と、ステップ2402で受信したログを比較して、誤報の発生可能性を検出する(ステップ2403)。受信したログが誤報発生条件403に合致していればステップ2404へ進み、合致していなければステップ2406に進む。
誤報の発生可能性を検出しなかった場合は、異常検出・予測部410はログ収集部107でコンピュータシステム101からログを受信する(ステップ2406)。次に、異常検出・予測部410は異常判定部108で異常の発生の検出・予測を行う(ステップ2407)。異常検出・予測部410は結果出力部109で異常の発生の検出・予測結果を送信する(ステップ2408)。そして結果表示部111で異常の発生の検出・予測結果を表示する(ステップ2409)。
一方、ステップ2403の判定で誤報の発生可能性を検出した場合、ステップ2403に続いてステップ2404が実行される。ステップ2404では、誤報検出部401が誤報発生条件記憶部402に記録されている誤報発生条件(誤報発生周期)と、ステップ2402で受信したログを比較して、誤報の発生可能性を検出する。誤報の発生可能性があればステップ2410ヘ進み、そうでなければステップ2406へ進む。
ステップ2410では、誤報検出部401が異常検出・予測部410に誤報検出結果404を送信する(ステップ2410)。異常検出・予測部410は、誤報検出結果に応じて異常判定結果の出力の無効化や、処理の停止などを行う(ステップ2411)。以上の処理フローによって、誤報検出部401を利用した誤報の発生の低減が実現される。これにより、異常検出の精度と異常予測の精度を高めることが可能となる。
図8は誤報発生可能性を検出した際に異常検出・予測処理を無効化する方法を適用したコンピュータシステムを示すブロック図である。図8で誤報検出部601は、図2の誤報検出部201や図5の誤報検出部401と同じ方法で誤報の発生可能性を検出する。また、誤報時ログ・誤報発生条件記憶部602も、図2の誤報時ログ記憶部202や図5の誤報発生条件記憶部402を併せたもので、誤報時のログと誤報発生条件を格納したものである。なお、誤報時のログと誤報発生条件は、誤報検出のルールとすることができる。
誤報検出部601で誤報の発生可能性が検出されると、誤報検出結果パス604を介して異常検出・予測部613に含まれる制御部605に誤報検出結果が通知される。制御部605は、異常検出・予測部613のログ収集部107、異常判定部108、結果出力部109のすべてもしくは一部に対して誤報検出結果に基づいて処理の中止や処理結果の無効化を行う。誤報の発生可能性が検出された場合、制御部605はログ収集部107に対して、例えば、ログの収集処理の中止や収集してあるログの廃棄を指示する。また、制御部605は異常判定部108に対して、例えば、異常判定結果の無効化を指示する。制御部605は結果出力部109に対して、出力しようとする結果が、異常が発生したと検出もしくは予測を示している場合、例えばそれを無効化する。以上のような方法で、誤報の発生可能性が検出された場合に、異常検出・予測部613が異常の発生と検出もしくは予測していたとしても、結果表示部においては、異常の発生を検出もしくは予測したとは表示されず、誤報の発生を抑止することができる。誤報検出結果パス604を介して誤報検出部601から制御部605に通知される誤報検出結果609については、ある時点に誤報の発生の可能性が検出されたと通知する方法の他に、図8に示した誤報検出結果(例1)610のように、ある時点から1時間の間、異常検出・予測部613での異常判定処理をストップする指示を通知してもよい。また、誤報検出結果(例2)611のように、ある時点から1時間の間、異常検出・予測部613で判定した異常度を半減させる支持を通知することで、異常検出・予測の感度を低くし、誤報の発生を低減する方法なども含まれる。
図9は図8に示した方法において、誤報発生可能性を検出した際に異常検出・予測処理を無効化する方法を示す処理フローである。最初にコンピュータシステム101から誤報検出部601でログを受信する(ステップ702)。誤報検出部601は誤報時ログ・誤報発生条件記憶部602に記録されている誤報時ログ・誤報発生条件と、ステップ702で受信したログを比較して、誤報の発生可能性を検出する(ステップ703)。誤報の発生可能性の検出の有無によって処理が分岐する(ステップ704)。誤報の発生可能性を検出しなかった場合は、異常検出・予測部613はログ収集部107でコンピュータシステムからログを受信する(ステップ705)。
次に、異常検出・予測部613は異常判定部108で異常の発生の検出・予測を行う(ステップ706)。異常検出・予測部613は結果出力部109で異常の発生の検出・予測結果を送信する(ステップ707)。そして結果表示部111で異常の発生の検出・予測結果を表示する(ステップ708)。誤報の発生可能性を検出した場合、ステップ704に続いてステップ709が実行される。つまり、異常検出・予測部613に誤報検出部601は誤報検出結果を送信する(ステップ709)。異常検出・予測部613の制御部605は、誤報検出結果に応じて異常判定結果の出力の無効化や、処理の停止などを行う(ステップ710)。以上の処理フローによって、誤報検出部601を利用した誤報の発生の低減が実現される。
図10は誤報発生可能性を検出した際に誤報発生を起す可能性のあるログを削除する方法を適用したコンピュータシステムを示すブロック図である。
図10は、図8で示した方法と目的は同じであるが、別の方法で目的を達成する方法である。図10で誤報検出部801は、図2の誤報検出部201や図5の誤報検出部401と同じ方法で誤報の発生可能性を検知し、誤報時ログ・誤報発生条件記憶部802も、図2の誤報時ログ記憶部202や図5の誤報発生条件記憶部402と同じ方法で誤報時のログや誤報発生条件を格納したものである。
誤報検出部801で誤報の発生可能性が検出されると、誤報検出結果パス805を介してログ修正部804に誤報検出結果が通知される。ログ修正部804は、ネットワーク104を介してコンピュータシステム101内で生成されたログを受信するが、誤報検出結果に基づいてログの修正や削除を行う。例えば、ログに含まれる特定のイベントが誤報を発生する原因であることが、誤報時ログ・誤報発生条件記憶部802に記録されており、そのログの発生を誤報検出部801が検出した場合、誤報検出部801はそのログの削除をログ修正部804に対して指示し、ログ修正部804は該当するログの削除を実行する。修正後のログは異常検出・予測部807のログ収集部107に送信される。これにより、異常検出・予測部807では誤報を発生することがなくなり、異常検出の精度と異常予測の精度を高めることが可能となる。
図10では、ログ収集部107はコンピュータシステム101からネットワーク104を介して直接ログを受信できるパスと、ログ修正部804から修正後のログを受信できるパスの2つのパスが1つのパスにまとめて記載されているが、これは2つのパス別々でも問題なく、さらに、ログ修正部804からの修正後のログを受信するパスだけでも良い。異常検出・予測部807および結果表示部111の処理方法については、図2や図5に示した方法と同じである。以上のような方法で、誤報の発生可能性が検出された場合に、ログ修正部804によって、誤報を発生する可能性のあるログを修正・削除できるため、誤報の発生を抑止することができる。
図11は図10に示した方法において、誤報発生可能性を検出した際に誤報発生を起す可能性のあるログを削除する方法を示す処理フローである。最初にコンピュータシステム101から誤報検出部801でログを受信する(ステップ902)。誤報検出部801は誤報時ログ・誤報発生条件記憶部802に記録されている誤報時ログ・誤報発生条件と、ステップ902で受信したログを比較して、誤報の発生可能性を検出する(ステップ903)。
誤報の発生可能性の検出の有無によって処理が分岐する(ステップ904)。誤報の発生可能性を検出しなかった場合は、異常検出・予測部807はログ収集部107でコンピュータシステムからログを受信する(ステップ905)。ステップ905では、ログ修正部804からログを受信しても良い。なぜならば、ステップ905は、誤報の発生可能性を検出しなかった場合であるので、ログ修正部804からログを受信しても、ネットワーク104を介して直接コンピュータシステム101からログを受信しても、ログに相違がないからである。次に、異常検出・予測部807は異常判定部108で異常の発生の検出・予測を行う(ステップ906)。異常検出・予測部807は結果出力部109で異常の発生の検出・予測結果を送信する(ステップ907)。そして結果表示部111で異常の発生の検出・予測結果を表示する(ステップ908)。
誤報の発生可能性を検出した場合、ステップ904に続いてステップ909が実行される。つまり、ログ修正部804に誤報検出部601は誤報検出結果を送信する(ステップ909)。ログ修正部804はコンピュータシステム101からログを受信し、誤報検出結果に応じてログを修正・削除する(ステップ910)。異常検出・予測部807のログ収集部107は、ログ修正部804からログを受信する(ステップ911)。ステップ911では、ネットワーク104を介してコンピュータシステム101からもログを受信してよい。続いてステップ912からステップ914で異常検出予測部807と結果表示部111は、異常の発生の検出・予測を行い、結果を表示する。ステップ912からステップ914は、ステップ906からステップ908と同じである。
以上の処理フローによって、誤報検出部801とログ修正部804を利用した誤報の発生の低減が実現される。
図12は誤報発生可能性を検出した際に誤報発生を起す可能性のあるログに印をつけて、異常検出・予測処理を変更する方法を適用したコンピュータシステムの一例を示すブロック図である。図12は、図10で示した方法と目的は同じであるが、別の方法で目的を達成する方法である。
図12で誤報検出部1001は、図2の誤報検出部201や図5の誤報検出部401と同じ方法で、誤報時ログ・誤報発生条件記憶部1002も、図2の誤報時ログ記憶部202や図5の誤報発生条件記憶部402と同じ方法である。誤報検出部1001で誤報の発生可能性が検出されると、誤報検出結果パス1005を介してログ修正部1004に誤報検出結果が通知される。
ログ修正部1004は、ネットワーク104を介してコンピュータシステム101内で生成されたログを受信するが、誤報検出結果に基づいてログに印を付ける。例えば、ある時間帯のログが誤報を発生させる可能性が高い場合、誤報検出部1001はその時間帯に入ったことを検出し、誤報検出部1001はそのログに印を付けることをログ修正部1004に対して指示し、ログ修正部1004は該当するログに印を付ける。印は1種類である必要はなく、複数種類の印でも良い。
ログ修正部1004で修正後のログはログスイッチ1007に送信される。ログスイッチ1007は、ログに印が付いているか、いないかによって異常検出・予測部1010に含まれる複数のログ収集部107のいずれにログを転送するかを決定する。ログに付加した印に応じてどのログ収集部107に転送するかを決めるために、誤報検出部1001は誤報検出結果パス1006を介してログスイッチ1007に印と転送先のログ収集部107の関係について情報を送信する。これにより、異常検出・予測部1010では、誤報を起こす可能性のあるログと、それ以外のログで異常検出・予測の方法を変更したり、結果の出力を別々にしたりでき、誤報を起す可能性に応じて異常の発生の検出や予測の感度を変更したり、結果の表示方法を誤報の発生の可能性に応じて変更したりすることができ、誤報の発生を低減したり、誤報である可能性を通知したりすることができる。
異常検出・予測部1010は、複数のログ収集部107、異常判定部108、結果出力部109を持つ。これらの一部は共用しても良い。それぞれのログ収集部107、異常判定部108、結果出力部109での処理方法については、図2や図5に示した方法と同じである。
以上のような方法で、誤報の発生可能性が検出された場合に、ログ修正部1004とログスイッチ1007によって、異常検出・予測部1010における異常検出・予測方法を変更したり、結果の出力方法を変更したりできるので、誤報の発生を抑止することができる。なお、図8、図10、図12で示した方法は、このうちの1つだけを利用しても良いし、複数を組み合わせて利用しても良い。
図13は図12に示した方法において、誤報発生可能性を検出した際に誤報発生を起す可能性のあるログに印をつけて、異常検出・予測処理を変更する方法を示す処理フローである。
最初にコンピュータシステム101から誤報検出部1001でログを受信する(ステップ1102)。誤報検出部1001は、誤報時ログ・誤報発生条件記憶部1002に記録されている誤報時ログ及び誤報発生条件と、ステップ1102で受信したログを比較して、誤報の発生可能性を検出する(ステップ1103)。誤報の発生可能性の検出の有無によって処理が分岐する(ステップ1104)。誤報の発生可能性を検出しなかった場合は、異常検出・予測部1010はログ収集部107でコンピュータシステム101からログを受信する(ステップ1105)。次に、異常検出・予測部1010は異常判定部108で異常の発生の検出・予測を行う(ステップ1106)。異常検出・予測部1010は結果出力部109で異常の発生の検出・予測結果を送信する(ステップ1107)。そして結果表示部111で異常の発生の検出・予測結果を表示する(ステップ1108)。
誤報の発生可能性を検出した場合、ステップ1104に続いてステップ1109が実行される。つまり、ログ修正部1004とログスイッチ1007に誤報検出部1001は誤報検出結果を送信する(ステップ1109)。ログ修正部1004はコンピュータシステム101からログを受信し、誤報検出結果に応じてログに印を付ける(ステップ1110)。ログスイッチ1007はコンピュータシステム101とログ修正部1004からログを受信し、誤報検出結果とログに付いた印に応じて複数のログ収集部107の何れかひとつへログを転送する(ステップ1111)。ステップ1112からステップ1114は、ステップ1106からステップ1108と同じである。
以上の処理フローによって、誤報検出部1001とログ修正部1004、ログスイッチ1007を利用した誤報の発生の低減が実現される。
図14は異常検出・予測結果が誤報であることを通知する処理と、誤報発生時のログを記録する方法を適用したコンピュータシステムを示すブロック図である。
図14で、誤報通知部1201は、誤報が発生した際に、誤報の発生を誤報記録部1203に通知する手段である。例えば、誤報が発生した時刻と、誤報の発生が終了した時刻を通知する方法などがある。誤報通知部1201では、どのような誤報であったかを通知内容に含めることもある。これは、同様の原因で発生した誤報に関して、誤報時ログをまとめて記録するのに利用できる。
誤報記録部1203は、コンピュータシステム101内で生成されたログを、ネットワーク104を介して受信する。さらに、誤報通知部1201から誤報通知パス1202を介して誤報の発生通知を受信し、誤報発生時には、受信しているログを利用して、誤報発生時のログを、誤報記録パス1204を介して誤報時ログ・誤報発生条件記憶部602に記録する。
誤報記録部1203の処理は、例えば、図3の説明で述べた、誤報時ログの生成方法である。図14で誤報検出部601や異常検出予測部613、結果表示部111の処理は、図8に示した方法と同じである。なお、図14では、図8の方法に対して、誤報通知部1201、誤報記録部1203などを加えた構成となっているが、図8に限らず、図10や図12の方法に対して誤報通知部1201、誤報記録部1203などを加えた構成も可能である。
図15は図14に示した方法において、異常検出・予測結果が誤報であることを通知する手段と、誤報発生時のログを記録する方法を示す処理フローである。
最初に誤報通知部1201で誤報の発生を通知する(ステップ1302)。誤報記録部1203は、誤報通知部1201から誤報の発生通知を受信すると、誤報発生時のログを誤報時ログ・誤報発生条件記憶部602に記録する(ステップ1303)。次にコンピュータシステム101から誤報検出部601でログを受信する(ステップ1304)。誤報検出部601は誤報時ログ・誤報発生条件記憶部602に記録されている誤報時ログ及び誤報発生条件と、ステップ1304で受信したログを比較して、誤報の発生可能性を検出する(ステップ1305)。誤報の発生可能性の検出の有無によって処理が分岐する(ステップ1306)。
誤報の発生可能性を検出しなかった場合は、異常検出・予測部613はログ収集部107でコンピュータシステムからログを受信する(ステップ1307)。次に、異常検出・予測部613は異常判定部108で異常の発生の検出・予測を行う(ステップ1308)。異常検出・予測部613は結果出力部109で異常の発生の検出・予測結果を送信する(ステップ1309)。そして結果表示部111で異常の発生の検出・予測結果を表示する(ステップ1310)。
誤報の発生可能性を検出した場合、ステップ1306に続いてステップ1311が実行される。つまり、異常検出・予測部613に誤報検出部601は誤報検出結果を送信する(ステップ1311)。異常検出・予測部613の制御部605は、誤報検出結果に応じて異常判定結果の出力の無効化や、処理の停止などを行う(ステップ1312)。
以上の処理フローによって、誤報検出部601を利用した誤報の発生の低減が実現される。
図16は異常検出・予測において誤報が発生する可能性のある条件を設定する処理を含むログ解析方法を適用したコンピュータシステムを示すブロック図である。
図16で、誤報発生条件登録部1401は、誤報が発生した際もしくは、誤報の発生条件が分かっている場合に、誤報の発生条件を誤報発生条件記録部1403に通知する処理である。例えば、コンピュータシステム101の定期保守を特定の時間帯に行う場合、その時間帯には誤報が発生する可能性が高くなることを登録する方法などがある。誤報発生条件登録部1401では、どのような誤報であるかを通知内容に含めることもある。これは、同様の原因で発生する誤報に関して、誤報発生条件をまとめて記録するのに利用できる。
誤報発生条件記録部1403は、誤報発生条件登録部1401から誤報発生条件通知パス1402を介して誤報の発生条件を受信し、誤報発生条件記録パス1404を介して誤報時ログ・誤報発生条件記憶部602に記録する。誤報発生条件登録部1401および誤報発生条件記録部1403の処理は、例えば、図6の説明で述べた、誤報発生条件の生成方法である。図16に示す誤報検出部601や異常検出予測部613、結果表示部111の処理は、図8に示した方法と同じである。なお、図16では、図8の方法に対して、誤報発生条件登録部1401、誤報発生条件記録部1403などを加えた構成となっているが、図8に限らず、図10や図12,図14の方法に対して誤報発生条件登録部1401、誤報発生条件記録部1403などを加えた構成も可能である。
図17は図16に示した方法において、異常検出・予測において誤報が発生する可能性のある条件を設定する手段を含むログ解析方法を示す処理フローである。
最初に誤報発生条件登録部1401で誤報の発生条件を登録する(ステップ1502)。誤報発生条件記録部1403は、誤報発生条件登録部1401から誤報の発生条件を受信すると、誤報発生条件を誤報時ログ・誤報発生条件記憶部602に記録する(ステップ1503)。次にコンピュータシステム101から誤報検出部601でログを受信する(ステップ1504)。誤報検出部601は誤報時ログ・誤報発生条件記憶部602に記録されている誤報時ログ及び誤報発生条件と、ステップ1504で受信したログを比較して、誤報の発生可能性を検出する(ステップ1505)。誤報の発生可能性の検出の有無によって処理が分岐する(ステップ1506)。
誤報の発生可能性を検出しなかった場合は、異常検出・予測部613はログ収集部107でコンピュータシステムからログを受信する(ステップ1507)。次に、異常検出・予測部613は異常判定部108で異常の発生の検出・予測を行う(ステップ1508)。異常検出・予測部613は結果出力部109で異常の発生の検出・予測結果を結果表示部111へ送信する(ステップ1509)。そして結果表示部111で異常の発生の検出・予測結果を表示する(ステップ1510)。
誤報の発生可能性を検出した場合、ステップ1506に続いてステップ1511が実行される。つまり、異常検出・予測部613に誤報検出部601は誤報検出結果を送信する(ステップ1511)。異常検出・予測部613の制御部605は、誤報検出結果に応じて異常判定結果の出力の無効化や、処理の停止などを行う(ステップ1512)。
以上の処理フローによって、誤報検出部601を利用した誤報の発生の低減が実現される。
図18は異常検出・予測結果に、誤報発生を起す可能性を検出してログ修正したことを示す情報を付加する処理を含むログ解析方法を適用したコンピュータシステムを示すブロック図である。
図18で、誤報検出部801は、異常検出・予測部807の結果出力部1602に対して誤報検出結果パス1601を介して誤報の発生可能性を通知する。結果出力部1602は、誤報の発生可能性を受信すると、該当するログ解析の結果について、例えば誤報の発生可能性がある場合に、ログ修正部804でログが修正されたことを結果出力パス1603に出力する異常判定結果1605に含める。結果表示部1604は、異常判定結果がログ修正後の、つまり誤報の発生を低減させる処理を行った後の結果であることを表示する。以上の方法により、誤報検出部801とログ修正部804によって誤報の発生を低減させたことを結果表示部1604で確認することができるようになる。これによって誤報の発生を低減させる処理の妥当性の確認ができ、異常判定結果の精度をより高めることができる。図18に示す誤報検出部801やログ修正部804などの処理は、図10に示した方法と同じである。なお、図18では、図10の方法に対して、結果出力部1602に誤報検出結果パスを接続した構成となっているが、図10に限らず、図8や図12,図14の方法に対して変更を加えた構成も可能である。
図19は誤報発生を起す可能性を検出してログ修正する処理を含む異常検出・予測結果と、ログ修正を行わずに異常検出・予測結果の両方を結果表示する処理を含むログ解析方法を適用したコンピュータシステムを示すブロック図である。図19で、異常検出・予測部1010は、ログ解析により異常の検出・予測を行うために少なくとも2つの検出部1702、1703を持ち、誤報検出部1001は、一方の検出部1702へはネットワーク104を介してコンピュータシステム101内で生成されたログを直接入力し、もう一方の検出部1703へは修正ログ入力パス1701を介してログ修正部1004で修正されたログが入力される。
結果出力部1706に対しては、検出部1702、1703毎に結果出力パス1704、1705が接続され、検出部1702、1703の両方の異常判定結果を表示することができる。以上の方法により、誤報検出部1001やログ修正部1004による誤報の発生を低減させる処理の有無による異常判定結果の差異を確認することができるようになる。
これによって誤報の発生を低減させる処理の妥当性の確認ができ、異常判定結果の精度をより高めることができる。
図19に示した誤報検出部1001やログ修正部1004などの処理は、図12に示した方法と同じである。なお、図19では、図12の方法に対して、複数の結果出力パスなどを接続した構成となっているが、図12に限らず、図8や図10,図14の方法に対して変更を加えた構成も可能である。
ここまで第1の実施形態について図1から図19を使って説明してきたが、本発明の方法は図1から図19までに示した方法すべてを同時に行う必要はない。例えば、誤報の検出方法については、図2と図5に示した方法のいずれか一方でも、両方同時に行ってもよい。誤報の検出結果を利用した誤報の発生を低減させる処理については、図8、図10、図12に示した方法のいずれか1つもしくは2つでも、すべて同時に行ってもよい。誤報時のログや誤報の発生条件の登録方法については、図14、図16に示した方法のいずれか一方でも、両方同時に行ってもよい。さらに誤報時のログや誤報の発生条件の登録は予め行っておき、後から登録しない方法、つまり図14に示した方法も図16に示した方法も含まれない方法も考えられる。異常判定結果の出力・表示方法も、図18、図19に示した方法のいずれか一方でも、両方同時に行ってもよい。本発明には、上記の組み合わせによる方法も含まれている。
<第2実施形態>
本発明によるコンピュータシステムの異常検出における誤報発生を低減するログ解析装置の第2の実施形態を図20から図24を使って説明する。なお、ログ解析装置内部の処理方法については、前記第1実施形態に示した方法によって実施できるので、主に装置の外部仕様について説明する。
図20は本発明のログ解析装置に関する基本的なシステム構成を示すブロック図である。計算機1801で生成されたログはネットワークパス1802、1804、ネットワーク装置1803を経由してログ解析装置1805に送られる。計算機1801は、CPU、メモリ、ディスク装置などのハードウェアコンポーネントと、OSやミドルウェア、アプリケーションソフトウェアなどのソフトウェアコンポーネントによって構成される装置である。計算機1801はハードウェアコンポーネントやソフトウェアコンポーネントの組み合わせによって、様々な種類のサービスを提供する。ネットワーク装置1803とは、接続されているネットワークパス間で、データやコマンドのやり取りを行う装置で、例えば、計算機から出力されたログを誤報検出装置1806に転送したりする。
ログ解析装置1805は、誤報検出装置1806、異常検出・予測装置1808、異常検出・予測結果出力装置1810、誤報通知・登録インタフェース装置1811から構成される。誤報検出装置1806は、計算機1801と同様の構成を持つ装置で、CPU、メモリ1815とOS1816上に誤報検出ソフトウェア1817や、ログ修正ソフトウェア1818が動作しており、入出力インタフェース1813を介して、外部からのログや誤報発生条件などを入力したり、誤報検出結果や修正後のログを出力したりする。また、誤報時のログや、誤報発生条件を記憶するストレージ装置1814も含まれる。
誤報検出ソフトウェア1817は、例えば、図12の誤報検出部1001に示した方法を実現するソフトウェアである。ログ修正ソフトウェア1818は、例えば、図12のログ修正部1004に示した方法を実現するソフトウェアである。ストレージ装置1814は、例えば、図12の誤報時ログ・誤報発生条件記憶部1002を実現する装置である。図12のログスイッチ1007は、図20ではログ修正ソフトウェア1818に含めて実現しても、異常検出・予測装置1808上にソフトウェアで実現してもよい。
異常検出・予測装置1808も誤報検出装置1806と同様に、CPU、メモリ、OS、入出力インタフェース、ストレージ装置などから成り、例えばOS上で異常検出・予測ソフトウェアが動作する。異常検出・予測ソフトウェアは、例えば、図12の異常検出・予測部1010を実現するソフトウェアである。
異常検出・予測結果出力装置1810は、異常検出・予測装置1808で行うログ解析の結果出力を受けて異常通報の概要や詳細状況などを表示する装置である。例えば、図12の結果表示部111を実現する装置である。図20には記載されていないが、異常検出・予測結果出力装置1810に入出力装置を加えて、結果の表示方法を変更するなどできるようにすることも含まれる。
誤報通知・登録インタフェース装置1811は、誤報検出装置1806に誤報時ログや、誤報発生条件を登録するのに利用する。例えば、図14の誤報通知部1201や図16の誤報発生条件登録部1401を実現する装置である。図14の誤報記録部1203や図16の誤報発生条件記録部1403は、図20では誤報通知・登録インタフェース装置1811上にソフトウェアで実現しても、誤報検出装置1806上にソフトウェアで実現してもよい。
図20では、誤報検出装置1806、異常検出・予測装置1808などをそれぞれ1台ずつの計算機で実現しているが、これらを1台の計算機で実現してもよく、逆にそれぞれを複数台の計算機で実現してもよい。同様に、異常検出・予測結果出力装置1810と誤報通知・登録インタフェース装置1811も1台の装置で実現してもよい。
各装置間のパスで通信されるデータは、以下の通りである。ネットワークパス1802、1804では、計算機1801で生成されたログデータが通信される。誤報検出結果ネットワークパス1807では、誤報検出装置1806の誤報検出ソフトウェア1817で検出された誤報検出結果と、ログ修正ソフトウェア1818で修正を行ったログデータが通信される。誤報検出結果の例としては、図8に示した誤報検出結果609などが挙げられる。異常判定結果ネットワークパス1809では、異常検出・予測装置1808でログ解析した結果である異常判定結果が通信される。異常判定結果の例としては、図18に示した異常判定結果1605などが挙げられる。誤報通知・登録ネットワークパス1812では、誤報発生を通知するデータや誤報発生条件が通信される。誤報発生を通知するデータとは、誤報が発生した時刻やその内容説明などであり、誤報発生条件の例としては、図6(A)、(B)に示した誤報発生条件503〜506などが挙げられる。
なお、以上で説明した内容は、あくまでも1つの実装例であり、計算機1801とネットワーク装置1803の接続方法や、ログ解析装置1805内の装置の構成などは図20に示した構成に限らない。
図21は誤報発生通知インタフェースを含むログ解析装置のユーザインタフェースの実施例を示す図である。図20に示した本発明のログ解析装置1805の構成において、異常検出・予測結果出力装置1810と誤報通知・登録インタフェース装置1811を1つの装置で実現した例である。
図21は、タッチパネル機能付き液晶ディスプレイなどの表示画面1901に以下の4つのインタフェースを表示した例である。異常通報概要ウィンドウ1902には、異常検出・予測装置1808から出力される異常判定結果を元にコンピュータシステムに異常が発生しているかいないかを表示する。さらに、異常通報詳細ウィンドウ1903には、異常判定結果を元に、どのような異常であるかなどの異常に関する詳細な情報を表示する。誤報発生通知ボタン1904は、表示された異常が誤報であることを通知する入力インタフェースである。
誤報情報入力ボックス1905は、誤報の内容を入力するのに利用する入力インタフェースである。コンピュータシステムでの異常の発生を監視する際には、最初に異常通報概要ウィンドウ1902で異常の発生の検出・予測を確認し、その内容を異常通報詳細ウィンドウ1903で確認する。表示された異常が誤報であった場合には、誤報情報入力ボックス1905に誤報の内容を記入し、誤報発生通知ボタン1904を押すことで、誤報検出装置1806に誤報時ログや誤報発生条件が登録できる。
図22は誤報発生条件を登録するインタフェースを含むログ解析装置のユーザインタフェースの実施例を示す図である。図22は、ノートPCなどの入力インタフェース2001に誤報発生条件登録用のウィンドウ2002を表示した例である。誤報発生条件を入力するインタフェースとして、図22では大きく分けて以下の3つのウィンドウがある。時間指定ウィンドウ2003は、誤報が発生する時刻や発生の周期を登録する入力インタフェースである。発生条件ウィンドウ2004は、誤報を発生させるログ条件、ログの発生順序によって誤報が発生する場合のログ順序条件、ログに含まれるイベントの発生比率によって誤報が発生する場合のログ比率条件を登録する入力インタフェースである。操作対象ログウィンドウ2005は、誤報の発生可能性が検出された場合に修正や削除の対象となるログ種類を登録する入力インタフェースである。
これらの入力インタフェースとしては、直接条件や値・文字列などを入力することのできる入力ボックス2006や、条件や値・文字列などを記入したファイルを指定して読み込む参照ボタン2007などがある。
図23は異常検出・予測結果に、誤報発生を起す可能性を検出してログを修正したことを示す情報を付加して表示する手段を含むログ解析装置1805のユーザインタフェースの一例を示す図である。
図23は、液晶ディスプレイなどの表示画面2101に以下の4つのインタフェースを表示した例である。これらのインタフェースは、図18に示した誤報発生を起す可能性を検出してログ修正したことを示すインタフェースを含む例である。図23の例では、異常通報概要ウィンドウ2102に、異常検出・予測装置1808から出力された異常判定結果を元に、10:00:00から10:02:59までの間にコンピュータシステムに異常が発生しているかいないかを表示している。この例では異常の発生は無い。さらに、異常通報詳細ウィンドウ2103には、異常判定結果を元に、どのような異常であるかなどの異常に関する詳細な情報を表示している。
この例では、コンピュータシステムの異常度を定量化し、時系列に表示したグラフを示している。誤報発生可能性検出結果ウィンドウ2104には、誤報検出装置1806で誤報発生の可能性が検出されたいないかを表示している。この例では10:02:00〜10:02:59に誤報の発生可能性が検出されたことを示している。誤報発生可能性によるログ修正ウィンドウ2105には、誤報検出装置1806でログ修正が実行されたかどうかを表示している。この例では、定期的なキャッシュクリアによって発生するログ種類Xのログを削除したことを表示している。
図23に示したような表示インタフェースによって、異常の発生はないが、表示期間中に誤報の発生可能性を検出してログ修正をした結果として、異常の発生がないと検出・予測されていることを確認できる。
図24は誤報発生を起す可能性を検出してログを修正する手段を含む異常検出・予測結果と、ログの修正を行わない異常検出・予測結果の両方を表示する手段を含むログ解析装置のユーザインタフェースの実施例を示す図である。図24は、液晶ディスプレイなどの表示画面2201に大きく分けて以下の2つのインタフェースを表示した例である。これらのインタフェースは、図19に示した誤報発生を起す可能性を検出してログ修正した場合としなかった場合の両方の異常判定結果を示すインタフェースを含む例である。図24の例では、上側にログ修正をしなかった場合の異常判定結果を示すウィンドウ2202、下側に誤報の発生可能性を検出した場合にログ修正をした場合の異常判定結果を示すウィンドウ2203が表示されている。このウィンドウ2203には、図23に示した4つのインタフェースが含まれ、この例では10:02:00〜10:02:59に誤報の発生可能性が検出され、定期的なキャッシュクリアによって発生するログ種類Xのログを削除したこと、そしてその結果として10:00:00〜10:02:59の間にはコンピュータシステムに異常が発生していないと判定されたことを表示している。一方、ログ修正を行わなかった場合の異常判定結果を表示している上側のウィンドウ2202では、10:02:00に異常の発生が検出されたことが表示されている。図24に示したような表示インタフェースによって、異常の発生が検出・予測されたが、その検出結果は誤報である可能性があり、誤報の発生を低減させる処理によって異常が発生していないと判定されること、また誤報の原因が何であるかを理解することができる。
<補足>
請求項11乃至請求項13のいずれかひとつに記載のログ解析装置であって、前記誤報検出部は、前記誤報の発生を判定したときには、前記ログ解析部の解析を停止または解析結果を無効化することを特徴とするログ解析装置。
本発明により、ログ解析技術を利用したコンピュータシステムの異常の検出・予測に関し、実際には異常が発生していないのに異常を検出・予測してしまうフォールスポジティブの発生を低減でき、検出・予測の精度を向上することができるので、ログ解析技術のコンピュータシステムの異常の検出・予測への適用範囲が広がり、結果としてコンピュータシステムの信頼度が向上する。本技術は、システム運用管理ツールの基盤技術として利用可能である。
本発明の適用対象とするログ解析方法用いたコンピュータシステムに関する基本的な構成を示すブロック図である。 本願発明の第1の実施形態を示し、誤報発生時のログを利用して誤報発生の可能性を検出するコンピュータシステムのブロック図である。 誤報発生時のログと現在のログとの比較方法の例を示す説明図で、(A)はログの内容と誤報時のログの内容を示し、(B)は誤報時のログを用いて現在のログから誤報発生の可能性を検出する例を示す。 誤報発生可能性を検出した際に異常検出・予測部へ誤報発生の可能性を通知する処理の一例を示すフローチャートである。 本願発明の第1の実施形態の他の例を示し、誤報発生条件を利用して誤報発生の可能性を検出するコンピュータシステムのブロック図である。 誤報発生条件を用いて現在のログとの比較方法の例を示す説明図で、(A)はログの内容と誤報時のログの内容を示し、(B)は誤報時のログを用いて現在のログから誤報発生の可能性を検出する例を示す。 誤報発生条件を用いて誤報発生可能性を検出した際に異常検出・予測部へ誤報発生の可能性を通知する処理の一例を示すフローチャートある。 本願発明の第1の実施形態の他の例を示し、誤報発生可能性を検出した際に異常検出・予測部を無効化するコンピュータシステムのブロック図である。 誤報発生可能性を検出した際に異常検出・予測部を無効化する場合の処理の一例を示すフローチャートである。 本願発明の第1の実施形態の他の例を示し、誤報発生可能性を検出した際に誤報発生を起す可能性のあるログを削除するコンピュータシステムのブロック図である。 誤報発生可能性を検出した際に誤報発生を起す可能性のあるログを削除する場合の処理の一例を示すフローチャートである。 本願発明の第1の実施形態の他の例を示し、誤報発生可能性を検出した際に誤報発生を起す可能性のあるログに印をつけて、異常検出・予測部を変更するコンピュータシステムのブロック図である。 誤報発生可能性を検出した際に誤報発生を起す可能性のあるログに印をつけて、異常検出・予測部を変更する場合の処理の一例を示すフローチャートである。 本願発明の第1の実施形態の他の例を示し、異常検出・予測結果が誤報であることを通知し、誤報発生時のログを記録する方法を適用したコンピュータシステムを示すブロック図である。 誤報発生可能性を検出した際に誤報発生を起す可能性のあるログに印をつけて、異常検出・予測部を変更する場合の処理の一例を示すフローチャートである。 本願発明の第1の実施形態の他の例を示し、異常検出・予測において誤報が発生する可能性のある条件を設定する方法を適用したコンピュータシステムを示すブロック図である。 異常検出・予測において誤報が発生する可能性のある条件を設定する場合の処理の一例を示すフローチャートである。 本願発明の第1の実施形態の他の例を示し、異常検出・予測結果に、誤報発生を起す可能性を検出してログの修正を指令するコンピュータシステムを示すブロック図である。処理のしたことを 誤報発生を起す可能性を検出してログ修正する手段を含む異常検出・予測結果と、ログ修正を含まない異常検出・予測結果の両方を結果表示する場合のログ解析方法を示すブロック図である。 本発明の第2の実施形態を示し、ログ解析装置のシステムに関する基本的な構成を示すブロック図である。 誤報発生通知インタフェースを含むログ解析装置のユーザインタフェースの実施例を示す図である。 誤報発生条件を登録するインタフェースを含むログ解析装置のユーザインタフェースの実施例を示す説明図である。 異常検出・予測結果に、誤報発生を起す可能性を検出してログ修を行うことを示す情報を付加して表示する手段を含むログ解析装置のユーザインタフェースの実施例を示す図である。 誤報発生を起す可能性を検出してログ修正する手段を含む異常検出・予測結果と、含まない異常検出・予測結果の両方を表示する手段を含むログ解析装置のユーザインタフェースの実施例を示す図である。
符号の説明
101 コンピュータシステム
102 計算機
103 ログ生成部
105、206、409、612、806、1009、1205、1405、1606、1707 ログ解析部
106、207、410、613、807、1010 異常検出・予測部
107 ログ収集部
108 異常判定部
109、1602 結果出力部
111、1604、1706 結果表示部
201、401、601、801、1001 誤報検出部
202 誤報時ログ記憶部
203 誤報時ログパス
204、404、604、805、1005、1006、1601 誤報検出結果パス
205、408 比較器
301 正常時ログ
302 誤報発生時ログ
307、507 現在ログ
308、510 誤報検出時ログ
402 誤報発生条件記憶部
403 誤報発生条件パス
405 誤報発生周期パス
406 ログ入力スイッチ

Claims (7)

  1. 計算機から出力されるイベント発生のログを解析して、計算機の異常を検出もしくは予測するログ解析方法であって、
    前記イベントを識別するためのイベント識別情報と、前記イベントが発生する時刻であるイベント発生時刻と、を対応付けて前記ログの少なくとも一部として保持するステップと、
    前記計算機の異常の検出または異常の予測において誤報が発生した場合における前記イベントである第1のイベントを少なくとも1以上含む複数の前記イベントについて、前記イベント識別情報の比較と、前記イベント発生時刻の比較と、を行って、前記第1のイベントの前記イベント発生時刻に関する規則性を示す規則性情報を生成するステップと、
    新たに前記計算機からログを受け付けるステップと、
    前記新たに受け付けたログを解析して、前記計算機に異常が発生したことを検出、または前記計算機に異常が発生することを予測するステップと、
    前記新たに受け付けた前記計算機の異常の検出または異常の予測を行ったログに含まれる前記イベント識別情報と前記イベント発生時刻と、を抽出するステップと、
    前記規則性情報を参照し、前記抽出した前記イベント識別情報が前記第1のイベントの前記識別情報と同じで、且つ前記抽出した前記イベント発生時刻が前記規則性を有する場合に、前記計算機の異常の検出または異常の予測において誤報の発生を判定するステップと、
    前記誤報が発生と判定されたときには、前記計算機の異常発生の検出または前記計算機の異常発生の予測において誤報の発生を低減するステップと、
    を含むことを特徴とするログ解析方法。
  2. 請求項1に記載のログ解析方法であって、前記規則性情報が、誤報の発生周期を含む予め設定した発生条件であることを特徴とするログ解析方法。
  3. 請求項1又は2に記載のログ解析方法であって、前記誤報の発生を低減するステップは、
    前記誤報の発生が判定されたときには、前記異常の検出または予測の実行を停止し、もしくは、異常の検出結果もしくは予測結果を無効化することにより、誤報の発生を低減することを特徴とするログ解析方法。
  4. 請求項1又は2に記載のログ解析方法であって、前記誤報の発生を低減するステップは、
    前記誤報の発生が判定されたときには、前記誤報の発生が予測されるログを前記ログの解析対象から除外することにより、誤報の発生を低減することを特徴とするログ解析方法。
  5. 請求項1又は2に記載のログ解析方法であって、前記誤報の発生を低減するステップは、
    前記誤報の発生が判定されたときには、前記誤報を発生させる可能性のあるログに印を付加し、前記印に基づいて前記異常の検出または予測の実行を変更することにより、誤報の発生を低減することを特徴とするログ解析方法。
  6. イベント発生のログを出力する計算機と、
    前記計算機から出力されるログを解析して、前記計算機の異常を検出もしくは予測するログ解析部と、を備えたログ解析装置であって、
    前記イベントを識別するためのイベント識別情報と、前記イベントが発生する時刻であるイベント発生時刻と、を対応付けて前記ログの少なくとも一部として保持するログ生成手段と、
    前記新たに受け付けたログを解析して、前記計算機に異常が発生したことを検出、または前記計算機に異常が発生することを予測する異常検出・予測手段と、
    前記計算機の異常の検出または異常の予測において誤報が発生した場合における前記イベントである第1のイベントを少なくとも1以上含む複数の前記イベントについて、前記イベント識別情報の比較と、前記イベント発生時刻の比較と、を行って、前記第1のイベントの前記イベント発生時刻に関する規則性を示す規則性情報を記録する誤報ログと、
    前記計算機の異常の検出または異常の予測において誤報の発生を判定する誤報検出手段と、を備え
    前記誤報検出手段は、
    前記新たに受け付けた前記計算機の異常の検出または異常の予測を行ったログに含まれる前記イベント識別情報と前記イベント発生時刻と、を抽出し、
    前記規則性情報を参照し、前記抽出した前記イベント識別情報が前記第1のイベントの前記識別情報と同じで、且つ前記抽出した前記イベント発生時刻が前記規則性を有する場合に、前記計算機の異常の検出または異常の予測において誤報の発生を判定し、前記誤報が発生と判定されたときには、誤報の発生を低減するよう前記受け付けたログを修正し、または前記ログ解析部を制御することを特徴とするログ解析装置。
  7. 計算機から出力されるイベント発生のログを解析して、計算機の異常を検出もしくは予測する処理をログ解析用計算機に実行させるためのプログラムであって、
    前記イベントを識別するためのイベント識別情報と、前記イベントが発生する時刻であるイベント発生時刻と、を対応付けて前記ログの少なくとも一部として保持する手順と、
    前記計算機の異常の検出または異常の予測において誤報が発生した場合における前記イベントである第1のイベントを少なくとも1以上含む複数の前記イベントについて、前記イベント識別情報の比較と、前記イベント発生時刻の比較と、を行って、前記第1のイベントの前記イベント発生時刻に関する規則性を示す規則性情報を生成する手順と、
    新たに前記計算機からログを受け付ける手順と、
    前記新たに受け付けたログを解析して、前記計算機に異常が発生したことを検出、または前記計算機に異常の発生を予測する手順と、
    前記新たに受け付けた前記計算機の異常の検出または異常の予測を行ったログに含まれる前記イベント識別情報と前記イベント発生時刻と、を抽出する手順と、
    前記規則性情報を参照し、前記抽出した前記イベント識別情報が前記第1のイベントの前記識別情報と同じで、且つ前記抽出した前記イベント発生時刻が前記規則性を有する場合に、前記計算機の異常の検出または異常の予測において誤報の発生を判定する手順と、
    前記誤報の発生が判定されたときには、前記計算機の異常発生の検出または前記計算機の異常発生の予測において誤報の発生を低減する手順と、
    をログ解析用計算機に実行させるためのプログラム。
JP2007243570A 2007-09-20 2007-09-20 ログ解析方法、ログ格納装置及びプログラム Expired - Fee Related JP4819014B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2007243570A JP4819014B2 (ja) 2007-09-20 2007-09-20 ログ解析方法、ログ格納装置及びプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2007243570A JP4819014B2 (ja) 2007-09-20 2007-09-20 ログ解析方法、ログ格納装置及びプログラム

Publications (3)

Publication Number Publication Date
JP2009075817A JP2009075817A (ja) 2009-04-09
JP2009075817A5 JP2009075817A5 (ja) 2010-04-02
JP4819014B2 true JP4819014B2 (ja) 2011-11-16

Family

ID=40610726

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007243570A Expired - Fee Related JP4819014B2 (ja) 2007-09-20 2007-09-20 ログ解析方法、ログ格納装置及びプログラム

Country Status (1)

Country Link
JP (1) JP4819014B2 (ja)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5416833B2 (ja) * 2010-04-06 2014-02-12 株式会社日立製作所 性能監視装置,方法,プログラム
JP5541130B2 (ja) 2010-12-10 2014-07-09 富士通株式会社 管理装置、管理方法および管理用プログラム
WO2013021530A1 (ja) * 2011-08-11 2013-02-14 日本電気株式会社 監視装置、監視方法およびプログラム
JP5873832B2 (ja) * 2013-04-24 2016-03-01 京セラドキュメントソリューションズ株式会社 電子機器
JP6008404B2 (ja) * 2014-03-14 2016-10-19 Necフィールディング株式会社 情報管理装置、情報管理方法、及びプログラム
WO2016194212A1 (ja) * 2015-06-04 2016-12-08 富士通株式会社 記憶処理装置、記憶装置故障判定プログラム、記憶装置故障判定方法および情報処理システム
US20180365124A1 (en) * 2015-12-14 2018-12-20 Nec Corporation Log analysis system, log analysis method, and log analysis program
CN107291911B (zh) * 2017-06-26 2020-01-21 北京奇艺世纪科技有限公司 一种异常检测方法和装置
JP6939906B2 (ja) * 2018-01-22 2021-09-22 日本電気株式会社 異常検知装置
JP2024051321A (ja) * 2022-09-30 2024-04-11 株式会社デンソー ログ判定装置、ログ判定方法、ログ判定プログラム、及びログ判定システム

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4892367B2 (ja) * 2007-02-02 2012-03-07 株式会社日立システムズ 異常兆候検出システム

Also Published As

Publication number Publication date
JP2009075817A (ja) 2009-04-09

Similar Documents

Publication Publication Date Title
JP4819014B2 (ja) ログ解析方法、ログ格納装置及びプログラム
Gu et al. Online anomaly prediction for robust cluster systems
JP4859558B2 (ja) コンピュータシステムの制御方法及びコンピュータシステム
US9152530B2 (en) Telemetry data analysis using multivariate sequential probability ratio test
US8214364B2 (en) Modeling user access to computer resources
Tan et al. Adaptive system anomaly prediction for large-scale hosting infrastructures
WO2020052147A1 (zh) 监测设备故障检测方法及装置
US20210149790A1 (en) Event specific log file generation
US11196613B2 (en) Techniques for correlating service events in computer network diagnostics
JPWO2016132717A1 (ja) アプリケーション自動制御システム、アプリケーション自動制御方法およびプログラム
CN119249285A (zh) 设备故障预警方法、装置、设备及存储介质
Ozcelik et al. Seer: a lightweight online failure prediction approach
US20130091391A1 (en) User-coordinated resource recovery
CN113196311A (zh) 用于识别和预测机器的异常感测行为模式的系统和方法
Sethupathy et al. Self-healing systems and telemetry-driven automation in DevOps pipelines
Rony AI-Enabled Predictive Analytics And Fault Detection Frameworks For Industrial Equipment Reliability And Resilience
JP2014120001A (ja) 監視装置、監視対象ホストの監視方法、監視プログラム及び記録媒体
KR101444250B1 (ko) 개인정보 접근감시 시스템 및 그 방법
Thota Toward self-healing data infrastructure: Predictive monitoring and root cause intelligence for modern databases
Steidl et al. How industry tackles anomalies during runtime: Approaches and key monitoring parameters
Guntupalli AI-driven anomaly detection and root cause analysis: Using machine learning on logs, metrics, and traces to detect subtle performance anomalies, security threats, or failures in complex cloud environments
Zhang et al. Deoxys: A causal inference engine for unhealthy node mitigation in large-scale cloud infrastructure
WO2020044898A1 (ja) 機器状態監視装置及びプログラム
KR20240133818A (ko) 화면 출력 기반 이상 상태 감지 방법 및 장치
EP4485245B1 (en) Incident event cause identification system and incident event cause identification method

Legal Events

Date Code Title Description
A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100217

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20100217

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110517

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20110518

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110714

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: 20110802

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20110831

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140909

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees