(57)【特許請求の範囲】
【請求項１】
計算機システムまたは監視システムが出力したメッセージを受け取るメッセージ受信部と、
前記メッセージ受信部から受け取ったメッセージがシステムの障害に関するインシデントかどうかを判定する障害情報判定部と、
前記メッセージが障害に関するメッセージであると判定したとき、インシデント管理テーブルを参照し、前記メッセージに含まれる発生時刻、機器ＩＤの一致文字数及び障害情報を基に、前記メッセージと同件のインシデントが前記インシデント管理テーブルに登録されているかどうかを判定し、前記インシデント管理テーブルに前記メッセージと同件のインシデントが登録されていれば、前記インシデント管理テーブルに、前記メッセージと同件のインシデントの第一のインシデントＩＤと前記メッセージを登録し、登録されていなければ前記インシデント管理テーブルに、第二のインシデントＩＤと前記メッセージを登録するメッセージ集約部と、
前記インシデント管理テーブルを参照し、インシデントに含まれる機器ＩＤ及び監視ＩＤを基に、メッセージの集約結果に関する情報を作成する表示作成部と、
登録されているインシデントＩＤ、およびインシデントＩＤ毎に登録されている前記集約結果に関する情報を出力する入出力部と、を備えることを特徴とするインシデント管理システム。
【請求項２】
前記メッセージ集約部は、受け取ったメッセージ、および前記インシデント管理テーブルに登録されているインシデントのメッセージに含まれる発生時刻差、機器ＩＤの一致文字数及び障害情報に含まれる予め定められた単語の出現回数を基に、前記受け取ったメッセージが前記インシデント管理テーブルに登録されているメッセージと同件であるかの判定に使用する判定データを作成する判定データ作成部と、
判定データを用いて受信した２つのメッセージが同件かどうかを判定し、結果を判定データに付加する同件判定部と、
を含む、
ことを特徴とする請求項１に記載のインシデント管理システム。
【請求項３】
前記判定データ作成部は、前記インシデント管理テーブルに登録されているインシデントのメッセージと前記受け取ったメッセージとの、発生時刻差、機器ＩＤの一致文字数及び障害情報に含まれる予め定められた単語の出現回数の差を、線形結合した前記判定データを作成する、
ことを特徴とする請求項２に記載のインシデント管理システム。
【請求項４】
前記表示作成部は、インシデントＩＤ毎に登録されている前記集約結果に含まれ、同じインシデントＩＤと共に登録された複数のメッセージに含まれる複数の機器ＩＤが、互いに隣接する機器の機器ＩＤであるか判定し、前記集約結果に含まれる複数の機器に、互いに隣接する機器以外の機器ＩＤが含まれていると判定された場合、隣接する機器以外の機器から受信したメッセージが集約されていることを警告する警告表示を作成する、
ことを特徴とする請求項１に記載のインシデント管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、計算機システムを対象とする監視運用システムなどの技術に関し、特にコンピュータにより行われるインシデント管理の技術に関する。
【背景技術】
【０００２】
データセンタの計算機システム（以下システム基盤と記載）の運用では、監視システムにて検知した障害の情報を管理し、サービスが復旧したのか、あるいは調査中なのか、などの状況を管理する、いわゆるインシデント管理を行う必要がある。インシデント管理を効率的に行うことは、迅速な復旧や正確な対応につながり、結果としてサービスの品質がよくなるため、システムによる自動処理が進んでいる。
【０００３】
この自動処理の１つとして、計算機システムとインシデント管理システムを連携させ、インシデント管理システムへのメッセージ登録を自動的に行う方法が知られている。
【０００４】
一方、システム間の連携を行うと、１つの障害であっても、監視の方法などによって、複数のインシデントとしてインシデント管理システムに登録されることがある。このような事態が発生する例として、例えば、ネットワーク上のスイッチに障害が発生し、スイッチに接続されている機器からメッセージが発生する場合などが考えられる。
【０００５】
このような事態への対策として、複数のメッセージを同件のメッセージとしてまとめる仕組みがあり、例えば、特許文献１が知られている。この技術は発生したメッセージのホスト名とアプリケーション名、および障害情報などの情報をキーに障害事例情報を検索して同件のメッセージをまとめ、また検索にヒットしない場合は新たな障害事例として障害事例情報を増強する仕組みを可能にするものである。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１４−１１９９８２
【発明の概要】
【発明が解決しようとする課題】
【０００７】
かかる従来の方法においては、次のような課題がある。
【０００８】
すなわち、リリース後間もないシステム基盤を自動化するのに十分な障害事例情報がなく、自動化が有効に動作しない可能性がある。
【０００９】
また、障害事例情報を用いたメッセージ集約技術は、障害事例情報を検索して根本原因となるメッセージを特定し、それに付随するメッセージを障害事例情報より判定する技術であるが、インシデント管理システムの監視間隔やネットワークの経路によって、必ずしも根本原因のメッセージが最初にインシデント管理システムで受信されるかはわからない。すなわち、根本原因のメッセージより前に根本原因に付随するメッセージが登録されれば、自動処理はうまく機能せず、手動による集約が必要になる。
【００１０】
このように従来の方法で効率的に自動化を図るには、障害事例を充実させるしかないが、これは計算機システムの運用者に大きな負荷をかけなければならない。
【００１１】
本発明の目的は、過去に運用管理者がメッセージ集約した対応を機械学習の方法で学習することで、集約のために特別な障害事例を作成せずともメッセージを自動集約し、インシデント一覧画面を参照しただけで、インシデントを特定できる機能を提供することにある。また、誤って自動的に集約した場合も、インシデントに警告表示を付けることで利用者に対して誤って自動集約した可能性があることを認識させることができる。
【課題を解決するための手段】
【００１２】
本発明は、メッセージ集約された場合と、集約されなかった場合のデータに着目し、
２つのメッセージ間の発生時刻の差や機器ＩＤの文字不一致数などの関連性を示すデータである判定データを作成する。このデータに対して、２つのメッセージが集約された場合は同件であることを示す分類ラベルを付け、集約されなかった場合は、同件でないことを示す分類ラベルを付ける。このラベル付きデータを蓄積した判定データを作成する。新規にメッセージが発生したとき、登録済のインシデントの最新のメッセージとの間に先に述べたデータを作成する。次に、判定データを用いて、サポート・ベクター・マシンやニューラル・ネットワークにて分類ラベルを判定する。分類ラベルが同件であると判定された場合は、登録済のインシデントにメッセージを追加し、同件でないと判定された場合は、新しいインシデントＩＤを付け、新しいインシデントとする。運用端末には、インシデントＩＤ毎にインシデントを表示する。また、誤って集約した場合は、運用端末から手動で誤りを修正する。
【００１３】
このようにインシデントＩＤ毎にインシデントを表示することで、一覧画面からインシデントを認識しやすくする。加えて、一覧画面から対象インシデントを選択し、詳細表示すると集約したメッセージが表示され、どのようなメッセージが集約されているのかがわかる。
【００１４】
また、誤って集約された場合や集約されなかった場合は、運用端末から人手によってメッセージを集約することになるが、その場合も修正内容に基づいて、判定データを更新するため間違った集約が発生確率は徐々に小さくなっていく。
【発明の効果】
【００１５】
インシデント管理に要する時間を短縮することができる。
【図面の簡単な説明】
【００１６】
【図１】本発明の実施例におけるシステムの構成の例を示す図である。
【図２】本発明の実施例におけるメッセージを集約するフローチャートの例を示す図である。
【図３】本発明の実施例における判定処理のフローチャートの例である。
【図４】本発明の実施例における判定処理のフローチャートの例である（続き）。
【図５】本発明の実施例における表示処理のフローチャートの例である。
【図６】本発明の実施例における判定データ更新処理のフローチャートの例である。
【図７】本発明の実施例におけるインシデント管理テーブルの例である。
【図８】本発明の実施例におけるエラーＩＤに対応するエラーレベルである。
【図９】本発明の実施例における出現単語情報の例である。
【図１０】本発明の実施例における判定データテーブルの例である。
【図１１】本発明の実施例における一覧画面の例である。
【図１２】本発明の実施例における詳細画面の例である。
【図１３】本発明の実施例における構成図の例である。
【発明を実施するための形態】
【００１７】
以下本発明の実施形態を図面に基づいて詳細に説明する。
【００１８】
特許文献１にあるように従来は、事例情報を基に集約を判定していた。しかし、事例に登録されていないメッセージに関してはうまく集約できず、またメッセージ到着順序によってうまく集約できないことがあった。そこで、受け取ったメッセージと登録済のメッセージの２つのメッセージ間の関係性に着目して集約するかどうかを判定することで、事例の有無や到着順序によらず判定することができる。
【００１９】
一方、機械的に集約できる反面、誤った集約が発生する可能性もある。特に、発生頻度が極端に低いインシデントに対して誤った集約が発生する可能性がある。ネットワークの情報などを分析し、誤った集約をしない方法も考えられるが、すべての発生パターンを網羅するのは非常に困難である。そこで誤った集約をした可能性がある場合には、警告を出力することで利用者に誤った集約の可能性があることを示す。利用者は警告を見ることで集約されたメッセージに対して注意を払うことができ、誤った集約に気が付き対応ミスが少なくなる。
【００２０】
図１は、本発明の実施例におけるインシデント管理システムの構成例を示した図である。本実施例のシステムは、インシデント管理システム１、計算機システム２、監視システム３、外部記憶装置４０、ネットワーク経由で入力及び出力を行う運用端末４を有する。インシデント管理システム１は、ＣＰＵ３０、主記憶装置１０を有する。主記憶装置１０は、メッセージ受信部１１、障害情報判定部１２、メッセージ集約部１３、表示作成部１７、入出力部１８を有する。メッセージ集約部１３は、判定データ作成部１４、同件判定部１５、判定データ更新部１６を有する。外部記憶装置４０は、データベース２０を有し、データベースは、構成情報２１、インシデント管理２２、特定単語情報２３、出現単語情報２４、判定データ２５の各テーブルを有する。
【００２１】
ＣＰＵ３０は、主記憶装置１０にソフトウェアモジュールとして格納されたメッセージ受信部１１、障害情報判定部１２、メッセージ集約部１３、表示作成部１７、入出力部１８を実行し、外部記憶装置４０に格納されたデータベース２０の情報を参照し、処理をする。
【００２２】
図２は、本発明の実施例におけるメッセージの集約処理を示すフローチャートの例である。
【００２３】
メッセージ集約部１３は、本フローに従ってメッセージを集約し、表示作成部１７は、集約結果に対して警告表示を付ける。
【００２４】
以下フローチャートに沿って説明する。
ステップ２０１：メッセージ受信部１１は、インシデント管理システム１に接続されている計算機システム２もしくは監視システム３からメッセージを受け付ける。
ステップ２０２：受け付けたメッセージの集約判定に必要な情報をデータベース２０より取得する。
ステップ２０３：メッセージ集約部１３は、図３、図４のフローで集約の可能性があるメッセージであるかを判定し、インシデントとしてインシデント管理テーブル２２に登録する。
ステップ２０４：インシデント管理テーブル２２を参照し、集約済のインシデントを取得する。
ステップ２０５：メッセージの集約結果が合理的であるか判定するために必要な情報をデータベース２０より取得する。
ステップ２０６：表示作成部１７は、図５のフローでインシデントに表示する警告画面を作成する。
ステップ２０７：入出力部１８は、運用端末４へインシデントと警告表示を出力する。
【００２５】
図３は、本発明の実施例におけるインシデント判定処理を示すフローチャートの例である。
ステップ３０１：障害情報判定部１２は、メッセージに含まれるエラーＩＤがエラーＩＤの情報１１０で障害として扱うレベルであるかを判定する。扱うレベルである場合はステップ３０３へ進む。扱うレベルでない場合はステップ３０２へ進む。
ステップ３０２：メッセージを破棄する。
ステップ３０３：インシデント管理テーブル２２を参照し、ステータス１０２が完了になっていないインシデントがあるか検索する。未完のインシデントがないときステップ３０７へ進む。未完のインシデントがあるときステップ３０４へ進む。
ステップ３０４：ステップ３０３で取得したインシデントの中に、新規に発生したメッセージのシステム名１０４と同じもがあるか判定する。
ステップ３０５：同じものがある場合ある場合、ステップ３０７へ進む。同じものがない場合、ステップ３０６へ進む。
ステップ３０６：ステップ３０３で抽出したインシデントの中から発生時刻１０１が最新のメッセージを抽出する。
ステップ３０７： 新規発生したメッセージに新しいインシデントＩＤを採番する。
ステップ３０８：抽出したメッセージの判定データを作成する。
【００２６】
判定データは、判定データを作成する２つのメッセージの発生時刻１０１の差、機器ＩＤ１０５の文字不一致数、障害情報１０７に含まれる特定単語の単語出現回数１２０の差で構成される。
【００２７】
このとき、判定データは隣接するメッセージID間のメッセージについてのみ作成する。
【００２８】
図４は、本発明の実施例における同件判定の処理をするフローチャートの例である。
同件判定部１５は、判定データ作成部１４からメッセージ受け取った場合、本フローチャートを実施し、受け取ったメッセージにインシデントＩＤを採番する。
ステップ４０１：判定データテーブル２５を用いて、サポート・ベクター・マシンやニューラル・ネットワークなど分類器で判定データの分類ラベルを判定する。分類前には、判定データテーブル２５の各パラメータに適した重みづけを行う。
ステップ４０２：分類ラベルが「同件である」と判定した場合、ステップ４０３へ進む。分類ラベルの値が「同件でない」と判定した場合、ステップ４０５へ進む。
ステップ４０３：受信メッセージに未完のインシデントと同じインシデントＩＤを追加し、インシデント管理テーブル２２に登録する。
ステップ４０４：判定データの分類ラベルに「同件である」を登録し、判定データテーブル２５に格納し、処理を終了する。
ステップ４０５：未完のインシデント中メッセージの中から本ステップで判定データを作成していないメッセージを１件抽出する。
ステップ４０６：判定データを作成する。同件でないと判定されたメッセージIDについては隣接するメッセージID間のメッセージに関する判定データだけでなく、他のメッセージとの間の判定データも作成する。これにより同件であるという判定データと同件でないという判定データの数のバランスが取れ、より正確な同件かどうかの判断をすることができる。
ステップ４０７：作成した判定データの分類ラベルに「同件でない」を登録し、判定データテーブル２５に登録する。
ステップ４０８：ステップ４０５で抽出するメッセージがない場合、ステップ４０９へ進む。メッセージがある場合、ステップ４０５に戻る。
ステップ４０９：受信メッセージに新しいインシデントＩＤを採番し、インシデント管理テーブル２２に登録する。
【００２９】
サポート・ベクター・マシン等をにより作成された判定データを用いて分離超平面を求め、判定対象のメッセージが分離超平面のどちら側にあるかを求めることによりメッセージが同件かどうかを判断するようにするれば、さらに判定の精度を上げることができる。
【００３０】
図５は、本発明の実施例における表示処理を示すフローチャートの例である。
【００３１】
インシデントに含まれるメッセージの機器ＩＤ１０５がネットワーク上隣接しない機器から発生していた場合は、集約してもよいかは判断がつかない。しかし、機械的に集約を行うとこのような場合も集約されてしまう。また、インシデントに含まれるメッセージが異なる監視項目（以下監視項目を特定するＩＤを監視ＩＤと記載）を集約したときも、集約の判定が正しいか判断がつかない。このような場合に、表示作成部１７は、本フローに従ってインシデントに警告表示を付ける。以下フローチャートに沿って説明する。
ステップ５０１：インシデント管理テーブル２２に登録されているインシデントのインシデントＩＤ１０３を取得し、インシデントＩＤに対応付けられている機器ＩＤ１０５（以下第一の機器ＩＤと記載）をすべて取得する。
ステップ５０２：ステップ５０１で取得した第一の機器ＩＤが異なっているかを確認する。異なっている場合、ステップ５０３へ進む。第一の機器ＩＤがすべて同じ場合は、ステップ５０７へ進む。
ステップ５０３：第一の機器ＩＤに隣接する機器の機器ＩＤ（以下第二の機器ＩＤと記載）を構成情報２１からすべて取得し、取得した第二の機器ＩＤの集合に第一の機器ＩＤがすべて存在するかを確認する。
ステップ５０４：すべて存在する場合、ステップ５０６へ進む。そうでない場合、ステップ５０５へ進む。
ステップ５０５：「異なる機器ＩＤ、および機器を跨いだメッセージ集約があります」を表示項目に追加する。
ステップ５０６：「異なる機器ＩＤのメッセージが集約されています」を表示項目に追加する。
ステップ５０７：インシデントＩＤに登録されている監視ＩＤ１０６が異なるか判定する。監視ＩＤが異なる場合は、ステップ５０８へ進む。監視ＩＤが同じ場合は、処理を終了する。
ステップ５０８：「異なる監視項目のメッセージが集約されています」を表示項目に追加する。
【００３２】
図６は、本発明実施例における判定データを更新する処理を示すフローチャートの例である。
【００３３】
判定データ更新部１６は、インシデント管理テーブル２２のインシデントＩＤ１０３が入出力画面からの操作により変更された場合、本フローに従って判定データテーブル２５の分類ラベル１３０を再計算する。
【００３４】
以下フローチャートに沿って説明する。
ステップ６０１：運用端末４よりインシデントＩＤの更新を受け付ける。
ステップ６０２：インシデント管理テーブル２２を参照し、インシデントＩＤ１０３が更新されたメッセージのメッセージＩＤ１００を取得し、判定データデータブル２５から該当メッセージＩＤを含むデータを抽出する。
ステップ６０３：ステップ６０２で抽出したデータのうち、判定データの分類ラベル１３０を更新していない判定データを１件選択する。
ステップ６０４：ステップ６０３で選択した判定データを構成する２つのメッセージのインシデントＩＤ１０３をインシデント管理テーブル２２より取得する。
ステップ６０５：２つのインシデントＩＤが等しいか判定する。等しい場合は、ステップ６０６へ進む。等しくない場合は、ステップ６０７へ進む。
ステップ６０６：分類ラベル１３０を「同件である」に更新し、ステップ６０８へ進む。
ステップ６０７：分類ラベル１３０を「同件でない」に更新する。
【００３５】
端末からインシデント管理テーブルが更新された場合、その更新結果を判定データテーブルに反映する。判定データを構成する２つのメッセージの更新後のインシデントＩＤを比較し、インシデントＩＤが等しければ、端末から同件インシデント扱いとされたと判断でき、同件と判断し、更新後のインシデントＩＤが異なれば同件でないとする。
ステップ６０８：ステップ６０２で抽出したデータのうち、判定データの分類ラベル１３０を更新していないデータがあるか検索する。
ステップ６０９：更新していないデータがある場合は、ステップ６０３へ戻る。更新していないデータがない場合は、処理を終了する。
【００３６】
図７は、本発明の実施例におけるインシデント管理テーブルの例を示した図である。代表的な項目として、メッセージＩＤ１００、メッセージが発生した発生時刻１０１、インシデントの管理状態を示すステータス１０２、インシデントＩＤ１０３、メッセージが発生したシステム名１０４、メッセージが発生した機器の機器ＩＤ１０５、監視の種類を示す監視ＩＤ１０６、メッセージに含まれる障害情報１０７などの情報を有する。
【００３７】
図８は、本発明の実施例におけるエラーＩＤに対応するエラーレベルの例を示した図である。エラーIDが障害、警告、注意など対応が必要な内容か、単に情報提供をしているものなのかを判定するために用いる。
【００３８】
このエラーレベルは、運用端末４より利用者が変更できる。
【００３９】
図９は、本発明の実施例における障害情報の出現単語情報テーブルの例を示した図である。メッセージＩＤ毎に、障害情報１０７の単語の出現回数１２０を保持している。単語の出現回数の計算は、データベースに格納してあるメッセージに現れる特徴のあるキーワードを登録し、どのようなメッセージなのかを判断するために用いる特定単語情報テーブル２３を用いて、形態素解析で品詞単位に分解し、各品詞の出現回数を集計している。
【００４０】
図１０は、本発明の実施例における判定データテーブルの例を示した図である。判定データテーブル２５は図４のフローチャートに基づいて作成される。分類ラベル１３０は図６の処理で随時更新処理される。
【００４１】
図７、図９、図１０を用いて判定データの作成手順を具体的に説明する。判定データ作成対象を図９のメッセージＩＤ：１０００１とメッセージＩＤ：１０００２とする。初めに、発生時刻の差を計算すると、インシデント管理テーブル２２の発生時刻１０１よりメッセージ１００２はメッセージ１００１が発生した２分後に発生している。次に機器ＩＤ１０５を比較すると、「ＸＸＸＳＷ１０１」、「ＸＸＸＹＹＹ０２」の最初の不一致文字を左から数えると４文字目となる。次に形態素解析にて障害情報１０７を品詞分解し、特定単語の出現回数を数えて、その差分の絶対値を取得する。
【００４２】
メッセージＩＤ：１０００１とメッセージＩＤ：１０００２の障害情報１０７の特定単語の出現回数は、図９の出現単語情報２４のテーブルの1行目、2行目のようになり、1行目と2行目の単語出現回数１２０の差分の絶対値を取得する。単語１〜単語Ｘの列は、特定単語情報テーブル２３を基に品詞単位に分割された各単語の出現回数と読み替える。この発生時刻の差１３２、機器ＩＤの文字不一致数１３３、単語出現回数の差１３４、を線形結合したデータが判定データとなる。この判定データを判定し、例えば、同件であると判定された場合、同件である分類ラベルを追加して、図１０の判定データテーブル２５に登録する。図１０の図の1行目は、メッセージＩＤ：１０００１、メッセージＩＤ：１０００２より作成した判定済の判定データの例である。判定データテーブル２５の各パラメータは、単位が異なるため、分類ラベルを判定する前に各パラメータを公知の方法、例えば交差検定やグリッドサーチなどで重みづけをしてから判定を行う。
【００４３】
図１１は、本発明の実施例におけるインシデントの一覧画面の例を示した図である。インシデントをインシデントＩＤごとに表示し、詳細表示ボタン１４１などを有している。複数のメッセージを集約した場合は、初めにインシデントに登録されたメッセージを表示する。集約されたメッセージが存在するかどうかは、メッセージ集約の有無欄を確認する。詳細表示ボタンを押下すると図１２の詳細画面１５０が表示される。
【００４４】
図１２は、本発明の実施例におけるインシデントの詳細画面１５０の例を示した図である。インシデント詳細画面１５０は、例えば、図１１のインシデントの一覧画面の詳細表示ボタンから進むことができる。詳細画面には、代表的なメッセージ、もしくは一番初めに登録されたメッセージを画面左部分１５１に表示する。また、どのようなメッセージが集約されているかを画面下部１５３に表示する。加えて、システムのどこに障害が発生しているのかを、構成情報２１をもとに作成した構成図を画面左上１５２に表示する。
【００４５】
図１３は詳細画面に表示される構成図の例であり、異常の発生した機器を示す情報を構成図に表示する。
【００４６】
インシデント一覧画面からインシデントを選択し詳細表示すると、警告が表示される場合がある。利用者は警告画面の内容を確認することで集約結果が正しいか意識しながら作業を行える。警告に表示される項目は、インシデントに登録されている機器ＩＤや監視ＩＤである。
【符号の説明】
【００４７】
１…インシデント管理システム、２…計算機システム、３…監視システム、４…運用端末、１０…主記憶装置、１１…メッセージ受信部、１２…障害情報判定部、１３…メッセージ集約部、１４…判定データ作成部、１５…同件判定部、１６…判定データ更新部、１７…表示作成部、１８…入出力部、２０…データベース、２１…構成情報テーブル、２２…インシデント管理テーブル、２３…特定単語情報テーブル、２４…出現単語情報テーブル、２５…判定データテーブル、３０…中央演算装置、４０…外部記憶装置、１４０…一覧画面、１５０…詳細画面
【図１】
0006515048.tif 000002
【図２】
0006515048.tif 000003
【図３】
0006515048.tif 000004
【図４】
0006515048.tif 000005
【図５】
0006515048.tif 000006
【図６】
0006515048.tif 000007
【図７】
0006515048.tif 000008
【図８】
0006515048.tif 000009
【図９】
0006515048.tif 000010
【図１０】
0006515048.tif 000011
【図１１】
0006515048.tif 000012
【図１２】
0006515048.tif 000013
【図１３】
0006515048.tif 000014