複雑な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のメリットをどうぞお試しください。
このブログはこちらの英語ブログの翻訳、沼本 尚明によるレビューです。
