根本原因分析をさらにスマートに：ITSIのKPIから因果関係を特定する

複雑なITシステムのトラブルシューティングとなると、根本原因分析は一筋縄には行きません。このブログ記事では、機械学習を使ってIT Service Intelligence (ITSI)エピソードの根本原因分析を行う方法をご紹介します。具体的には因果推論を用います。

以下で説明する手法はSmart ITSI Insights App for Splunkに含まれています。この記事では[ITSI Episode Analysis]ダッシュボードの使い方について大まかに解説していきます。本題に入る前に1点、ここで取り上げる機能を使うにはDeep Learning Toolkitのバージョン3.4がインストール済みで動作していることが条件となりますので、ご注意ください。

エピソード分析

はじめに、Appの[ITSI Episode Analysis]ダッシュボードでITSIのエピソードをすべて表示します。重大度や特定の時間枠で絞り込んで表示させることも可能です。

ここにはエピソードの基本的なレポートが表示されます。各サービスのトレンドラインの推移のほか、問題が発生したサービスの内訳も表示されるので、問題があるサービスがあるかどうかをひと目で確認できます。レポートの下にはすべてのエピソードをリストしたテーブルがあり、エピソードが生成された時刻、エピソードのタイトル、問題が発生したサービス、エピソードの重大度が表示されます。

因果分析

テーブルのいずれかのエピソードをクリックすると、その下にダッシュボードが表示されます。このダッシュボードでは、問題が発生したサービスが依存しているKPI間の因果関係(どのKPIが互いに影響し合っているか)を確認できます。

この計算はエピソードが生成された直前の4時間を対象に行われるので、エピソードの生成前にKPI同士がどのような状態にあったかをすばやく評価できます。 

テーブルには、問題が発生したサービスの健全性スコアに直接影響していると思われるKPIがすべて表示されます。言い換えれば、これらのKPIがエピソード生成の犯人である可能性があります。テーブルの下には、問題となっているサービスのKPI間の関係がすべてハイライトされたグラフが表示されます。KPIにマウスオーバーするとその関係を確認できます。

根本原因分析

root_cause_kpisにリンクされたサービスを含むテーブルをクリックすると、[ITSI Deep Dive]ダッシュボードに移動します。ここでは、テーブル内の各KPIのスイムレーンが表示されます。表示中のデータは、エピソードの生成時刻をはさむ1時間(エピソード生成前45分と生成後15分)の状況を示しています。

この例では、ディスク使用率が非常に高くなっていたことが、エピソードの生成原因である可能性が高いことがわかります。

以上のように、機械学習を使うとエピソードの根本原因を簡単に特定することができます。この手法を使えば、IT環境で発生した問題の根本をさらにスムーズに特定できるはずです。

Splunkのメリットをどうぞお試しください。

このブログはこちらの英語ブログの翻訳、沼本 尚明によるレビューです。