イベント相関分析とは、膨大な数のイベントの中から、真に重要な少数のイベントを特定するための手法です。これは、イベント間の関係性を探し出し、分析することによって実現されます。
イベント相関は、長年にわたり様々な分野で利用されてきた。
統合経営は、従来、さまざまな分野に細分化されてきた。
イベント相関は、研究分野によって異なる構成要素で発生します。
本稿では、統合管理における事象相関に焦点を当て、他の分野との関連性についても述べる。
統合管理の目標は、ネットワーク(データ、電話、マルチメディア)、システム(サーバー、データベース、アプリケーション)、およびITサービスの管理を一貫性のある方法で統合することです。この分野の範囲には、特にネットワーク管理、システム管理、およびサービスレベル管理が含まれます。
イベント相関は通常、1つまたは複数の管理プラットフォーム内で実行されます。これは、イベント相関器と呼ばれるソフトウェアによって実装されます。このコンポーネントには、管理対象要素(アプリケーション、デバイス)、監視ツール、トラブルチケットシステムなどから発生するイベントが自動的に供給されます。各イベントは、イベント相関器が関心を持つ領域で発生した特別な何か(イベントソースの観点から)を捉えます。この特別な何かは、相関器が実行しようとしている分析の種類によって異なります。
イベント相関器は統合管理において重要な役割を果たします。なぜなら、イベント相関器内でのみ、様々なソースからのイベントが集約され、ソース間の比較が可能になるからです。例えば、サービスの障害が基盤となるITインフラストラクチャの特定の障害に起因するものなのか、あるいは潜在的なセキュリティ攻撃の根本原因はどこにあるのかを特定できるのは、まさにこの部分です。
ほとんどのイベント相関器は、トラブルチケットシステムからイベントを受信できます。しかし、問題が解決した際にトラブルチケットシステムに通知できるイベント相関器はごく一部であり、これがサービスデスクが最新情報を把握しにくい理由の一つとなっています。理論的には、組織における管理の統合には、イベント相関器とトラブルチケットシステム間の双方向通信が不可欠です。
イベントは、警報を発したり、インシデントを報告したりする場合もあります(イベント相関がかつて警報相関と呼ばれていたのはそのためです)が、必ずしもそうとは限りません。状況が正常に戻ったことを報告したり、単に関連性があると判断した情報(例えば、デバイスDでポリシーPが更新されたなど)を送信したりする場合もあります。イベントの重大度は、イベントソースがイベント宛先に対して、処理中にこのイベントに与えるべき優先度を示すものです。
イベント相関は、イベントフィルタリング、イベント集約、イベントマスキング、根本原因分析の4つのステップに分解できます。5つ目のステップ(アクションのトリガー)はイベント相関と密接に関連しているため、ここでは簡単に触れておきます。
イベントフィルタリングとは、イベント相関器が無関係と判断したイベントを破棄することです。例えば、低価格帯のデバイスの中には設定が難しく、管理プラットフォームにとって無関係なイベント(例:プリンタPがトレイ1にA4用紙を必要としている)を送信するものがあります。また、可用性と障害のみに関心のあるイベント相関器が、情報イベントやデバッグイベントをフィルタリングする場合も、同様の例が挙げられます。
イベント集約とは、非常に類似した(ただし必ずしも同一ではない)複数のイベントを、基となるイベントデータを表す集約データにまとめる手法です。その主な目的は、入力イベントの集合を、さまざまな分析手法で処理できるより小さな集合に要約することです。例えば、集約データからは、基となるイベントや、それらのイベントによって影響を受けるリソースに関する統計的な要約データが得られる場合があります。また、時間的集約もその一例です。これは、イベント発生源から同じ問題が繰り返し報告され、最終的に問題が解決されるまで続く場合などに用いられます。
イベント重複排除は、同一イベントの完全な重複を統合する特殊なイベント集約手法です。このような重複は、ネットワークの不安定性によって発生する可能性があります(例えば、最初のイベントが十分に迅速に確認応答されなかったために、イベントソースから同じイベントが2回送信され、最終的に両方のイベントがイベントの宛先に到達する場合など)。
イベントマスキング(ネットワーク管理ではトポロジーマスキングとも呼ばれる)とは、障害が発生したシステムの下流にあるシステムに関連するイベントを無視することです。例えば、ルーターがクラッシュした下流にあるサーバーは、可用性ポーリングに失敗します。
根本原因分析は、イベント相関分析の最終段階であり、最も複雑なステップです。これは、環境モデルや依存関係グラフなどに基づいてイベント間の依存関係を分析し、あるイベントが他のイベントによって説明できるかどうかを検出するものです。例えば、データベースDがサーバーS上で稼働しており、このサーバーが継続的に過負荷状態になった場合(CPU使用率が長時間100%になった場合)、「データベースDのSLAが満たされなくなった」というイベントは、「サーバーSが継続的に過負荷状態になった」というイベントによって説明できます。
この段階では、イベント相関器には、対処が必要なイベントがせいぜい数個しか残っていません。厳密に言えば、イベント相関はここで終了します。しかし、言葉の濫用として、市場に出回っているイベント相関器(例えば、ネットワーク管理分野)には、問題解決機能が含まれている場合もあります。例えば、自動的に是正措置や追加調査をトリガーする機能などです。
ITILの適用範囲は統合マネジメントよりも広い。しかし、ITILにおけるイベント相関は、統合マネジメントにおけるイベント相関と非常に類似している。
ITILバージョン2のフレームワークでは、イベント相関はインシデント管理、問題管理、サービスレベル管理の3つのプロセスにまたがります。
ITILバージョン3フレームワークでは、イベント相関はイベント管理プロセスで行われます。イベント相関器は相関エンジンと呼ばれます。