AIOps「Splunk IT Service Intelligence」を用いた統合ITダッシュボードと監視ツールThousandEyesの連携方法のご紹介

2026.03.25

ライター：知念　紀昭: メーカーで生産ライン業務を経験後、製品の評価・設計を担当。
その後SIerでシステム設計構築業務を経てネットワンシステムズに入社。
入社後は仮想化ハードウェア・ソフトウェアの評価・検証業務、クラウドソリューション業務などを担当。
現在は、主にデータの利活用・機械学習ビジネスを推進している。

監視ツール群からデータを収集

前回はAIを活用してITインフラやサービス全体を監視・運用および分析するツールSplunk IT Service Intelligence（ITSI）と監視ツールZabbixを連携させた「統合ITダッシュボード」をご紹介しました。各監視ツールのデータを統合ITダッシュボードに集約することにより、運用者は各監視ツールを一つ一つ確認しなくても通常運用時には正常・異常の判断が出来るようになります。また障害時にはそのダッシュボードから障害切り分けを迅速に行うことができます。

今回は、オブザーバビリティ監視ツールCisco ThousandEyesとの連携方法についてご紹介します。

Splunk ITSIとCisco ThousandEyesの連携

ThousandEyesは、ネットワーク経路やアプリケーションを監視し、障害箇所を切り分けするCisco傘下のSaaSです。ネットワーク監視情報としては、アプリケーションへの全経路における遅延やパケットロス等の品質データを保持しています。またアプリケーションの監視情報としては、例えばWebサイトの場合にはレスポンスコードやHTTP応答時間などの情報を保持しています。

ThousandEyesでアプリケーションを監視している場合、もしもネットワーク経路とアプリケーションが共に応答が無いときには、ネットワーク障害が起きていると切り分けができます。逆にネットワーク経路の応答が問題なくアプリケーションの応答が無いときには、アプリケーションに何か問題が起きていると判別できます。ThousandEyes自体のダッシュボードでこのような切り分けは可能ですが、複数のダッシュボード画面を切り替えて確認を行う必要があり手間がかかります。

Splunk ITSIにThousandEyesの情報を取り込んだ統合ITダッシュボードでは、一つのダッシュボードから正常・異常の判断が出来ます。また障害時にはそのダッシュボードで障害切り分けを実施できるため、よりトラブルシューティングの時間が短縮されるでしょう。

Splunk ITSIがThousandEyesから情報を受け取る方法は主に以下の2種類になります。

Splunkbaseで公開されているCisco ThousandEyes App for Splunkを用いる方法
Splunk Add-on BuilderでREST APIを用いる方法

前者がThousandEyes側からSplunk側に対してデータを送る方式に対して、後者はSplunk側からThousandEyes側にデータを取りに行く方式になるため、Splunk ITSIがオンプレミスに存在する場合には後者が容易な実装となります。今回は後者の方式をご紹介します。

図1：ネットワーク経路とアプリを監視するThousandEyesとSplunk ITSIの連携の論理構成

ThousandEyes側の連携設定

あるサービスに対してThousandEyesのエンドポイントエージェントからWebやネットワークテストが既に構成されている前提とします。予めThousandEyesのテストのURLからテストID情報を入手しておきます。またREST API連携をさせるためのトークンをThousandEyes管理者から入手しておきます。連携方法は、ThousandEyesのREST APIドキュメントに記載されておりますので事前に確認しておきます。ThousandEyesのバージョンによってREST APIの仕様が異なるため、以前の情報が使えない可能性があるので注意が必要となります。

図2：ThousandEyesのテストのURLからテストID情報を入手

Splunk ITSI側の連携設定

Splunk ITSI側では、まずAdd-onを自作するためのツールである「Splunk Add-on Builder」Appをインストールします。

図3：「Splunk Add-on Builder」App

Splunk Add-on Builderをインストール後、このAppを用いてAdd-onを新規作成します。Add-on作成時に好みの名前や独自のアイコンを指定することもできます。

図4：新規Add-onの作成

続いてデータの入力を選択すると、「REST API」「Shell Commands」「Python code」のデータ入力方法選択画面に移行します。この画面でShellやPythonを使えば複雑なデータ取り込みに対応できることがわかります。Shellに関してはSplunkをインストールしたホストのOSに依存する点に注意が必要です。今回のThousandEyesとの連携では「REST API」を選択します。

図5：データ入力方法の選択

続いて「Source type name」「Input display name」「Input name」などを入力します。

図6：各種名前の指定

いよいよREST APIの設定画面となります。ThousandEyesのマニュアルに合わせたURL、headerを指定します。認証は、ThousandEyes管理者から得られたトークンを指定します。テストを実行すると、設定が全て正しければ応答が返ってきます。正しい応答があれば、「完了」ボタンを押して保存します。

図7：REST APIの設定

作成したAdd-onは新規Appとして登録されますので、それを指定して新規入力名と情報取得間隔とIndex名を指定すれば、Indexにデータの取り込みが始まります。

図8：Add-onの設定

Splunk ITSI側のサービス設定

Splunk ITSI側で設定するサービスの例として今回はWebサービスを、そしてKPIとしてhttpレスポンスタイムとhttpレスポンスコードを設定する例をご紹介します。Add-onで指定したIndexとsourceやsource typeを基にサーチ文で絞り込みを行った後に、httpレスポンスタイムメトリックデータが含まれるresults{}.responseTimeフィールドとresults{}.responseCodeフィールドをそれぞれ指定します。今回はhttp responseTimeのKPI設定の画面をご紹介します。

図9：Webサービスのhttp responseTimeのKPI設定

前回ご紹介したZabbixデータ由来のKPI設定と合わせて3つのKPIを持つWebサービスを設定しています。複数の監視ツールから得られたデータを活用して高度な運用を行えることがSplunk ITSIを用いた統合ITダッシュボードの大きな利点となります。これは他の可視化ツールでは実現が難しい内容となります。

統合ITダッシュボードの見え方

コンテナ上にWordpressサービスを構築し、ユーザがネットワーク経由で利用するような環境で統合ITダッシュボードを活用する例をご紹介します。ZabbixとThousandEyesの2つの監視ツールで監視しており、それらのデータを統合ITダッシュボードで統合して運用高度化を図っています。ツリー形式の統合ITダッシュボードでは監視対象のネットワークが他の全てのサービスに依存されているため最下位層に、そのネットワーク上にコンテナ基盤があり、さらにその上でWordpressサーバのWebサーバとDBサーバがコンテナとして起動している様子が一目で確認できます。なお、このダッシュボードはデフォルトで用意されるものとなり、サービスの定義が終わると自動的に作成されるので管理者が作成する必要はありません。

サービスの依存関係を俯瞰的に見ることが可能なため、障害の根本原因の箇所を一目で特定できるようになります。例えばDBサーバに障害が発生してWebサーバのコンテンツ表示に不具合が発生した場合には、WebサーバとDBサーバの色が黄色や赤色に変わるでしょう。それらの依存関係から根本原因はDBサーバの障害であると速やかに切り分けが行えます。