ThousandEyes と Splunk Observability Cloud の統合

120 minutes Author Alec Chamberlain

このワークショップでは、ThousandEyes と Splunk Observability Cloud を統合し、シンセティックモニタリングとオブザーバビリティデータ全体にわたる統合的な可視性を提供する方法を紹介します。

学習内容

このワークショップを完了すると、以下のことができるようになります

ThousandEyes Enterprise Agent を Kubernetes のコンテナ化されたワークロードとしてデプロイする
OpenTelemetry を使用して ThousandEyes メトリクスを Splunk Observability Cloud に統合する
ThousandEyes と Splunk APM が同じリクエストにリンクできるよう分散トレーシングを設定する
内部の Kubernetes サービスおよび外部依存関係に対するシンセティックテストを作成する
Splunk Observability Cloud ダッシュボードでテスト結果を監視する
ThousandEyes から Splunk APM トレースに移動し、元の ThousandEyes テストに戻る

セクション

コアパス

概要 - ThousandEyes のエージェントタイプとアーキテクチャを理解する
デプロイ - Kubernetes に Enterprise Agent をデプロイする
Splunk 統合 - ThousandEyes メトリクスを Splunk Observability Cloud にストリーミングする
分散トレーシング - ThousandEyes と Splunk APM 間のサポートされた双方向ドリルダウンを有効にする

シナリオ拡張

Kubernetes テスト - シンセティックモニタリングとトレース相関の両方に有用な内部テストを作成する
RUM - ThousandEyes のネットワークシグナルと Splunk RUM を関連付けてエンドユーザー調査に活用する

サポート

トラブルシューティング - よくある問題と解決方法

ヒント

このシナリオは2つの連携した統合として考えてください：OpenTelemetry ストリームが ThousandEyes メトリクスを Splunk に取り込み、分散トレーシングが Splunk APM から ThousandEyes への逆方向のパスを提供します。

前提条件

Kubernetes クラスター（v1.16以上）
選択した namespace にリソースをデプロイするための RBAC 権限
Enterprise Agent トークンにアクセスできる ThousandEyes アカウント
インジェストトークンへのアクセスと APM ルックアップ用の API トークンを作成する権限を持つ Splunk Observability Cloud アカウント

統合のメリット

ThousandEyes を Splunk Observability Cloud に接続することで、以下のメリットが得られます

🔗 統合的な可視性: シンセティックテスト結果を RUM、APM トレース、およびインフラストラクチャメトリクスと相関付ける
📊 強化されたダッシュボード: 既存の Splunk オブザーバビリティメトリクスと並べて ThousandEyes データを可視化する
🔄 双方向ドリルダウン: ThousandEyes Service Map から Splunk トレースへ、また Splunk APM からリクエストを生成した ThousandEyes テストへ移動する
🚨 一元化されたアラート: Splunk 内で ThousandEyes テスト結果に基づくアラートを設定する
🔍 根本原因分析: 問題がネットワーク関連（ThousandEyes）かアプリケーション関連（APM）かを迅速に特定する
📈 包括的な分析: Splunk の強力な分析エンジンでシンセティックモニタリングのトレンドを分析する

概要

10 minutes

ThousandEyes エージェントタイプ

Enterprise Agent

Enterprise Agent は、自社のインフラストラクチャ内にデプロイするソフトウェアベースの監視エージェントです。以下の機能を提供します

内部からの可視性: 内部ネットワークから外部サービスへの監視とテスト
カスタマイズ可能な配置: ユーザーとアプリケーションが存在する場所にデプロイ
フルテスト機能: HTTP、ネットワーク、DNS、音声、その他のテストタイプ
永続的な監視: スケジュールされたテストを実行し続けるエージェント

このワークショップでは、Enterprise Agent を Kubernetes クラスター内のコンテナ化されたワークロードとしてデプロイします。

Endpoint Agent

Endpoint Agent は、エンドユーザーのデバイス（ラップトップ、デスクトップ）にインストールされる軽量なエージェントで、以下の機能を提供します

実際のユーザー視点: 実際のユーザーエンドポイントからの監視
ブラウザベースの監視: リアルユーザーエクスペリエンスメトリクスのキャプチャ
セッションデータ: ユーザーの視点からのアプリケーションパフォーマンスに関する詳細なインサイト

このワークショップでは、Enterprise Agent のデプロイのみに焦点を当てます。

アーキテクチャ

---
config:
  theme: 'base'
---
graph LR
    subgraph k8s["Kubernetes Cluster"]
        secret["Secret<br/>te-creds"]
        agent["ThousandEyes<br/>Enterprise Agent<br/>Pod"]
        
        subgraph apps["Application Pods"]
            api["API Gateway<br/>Pod"]
            payment["Payment Service<br/>Pod"]
            auth["Auth Service<br/>Pod"]
        end
        
        subgraph svcs["Services"]
            api_svc["api-gateway<br/>Service"]
            payment_svc["payment-svc<br/>Service"]
            auth_svc["auth-service<br/>Service"]
        end
        
        api_svc --> api
        payment_svc --> payment
        auth_svc --> auth
        
        secret -.-> agent
        agent -->|"HTTP Tests"| api_svc
        agent -->|"HTTP Tests"| payment_svc
        agent -->|"HTTP Tests"| auth_svc
    end
    
    external["External<br/>Services"]
    
    agent --> external
    
    subgraph te["ThousandEyes Platform"]
        te_cloud["ThousandEyes<br/>Cloud"]
        te_api["API<br/>v7/stream"]
        te_cloud <--> te_api
    end
    
    agent -->|"Test Results"| te_cloud
    
    subgraph splunk["Splunk Observability Cloud"]
        otel["OpenTelemetry<br/>Collector"]
        metrics["Metrics"]
        dashboards["Dashboards"]
        apm["APM/RUM"]
        alerts["Alerts"]
        
        otel --> metrics
        otel --> dashboards
        metrics --> apm
        dashboards --> alerts
    end
    
    te_cloud -->|"OTel/HTTP metrics"| otel
    te_cloud -->|"Trace lookup"| apm
    apm -->|"Deep links to test"| te_cloud
    
    user["DevOps/SRE<br/>Team"]
    user -.-> te_cloud
    user -.-> dashboards
    user -.-> agent
    
    style k8s fill:#e1f5ff,stroke:#0288d1,stroke-width:2px
    style apps fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
    style svcs fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
    style agent fill:#ffeb3b,stroke:#f57c00,stroke-width:2px
    style secret fill:#ffcdd2,stroke:#c62828,stroke-width:2px
    style api fill:#e1bee7,stroke:#7b1fa2,stroke-width:1px
    style payment fill:#e1bee7,stroke:#7b1fa2,stroke-width:1px
    style auth fill:#e1bee7,stroke:#7b1fa2,stroke-width:1px
    style api_svc fill:#ce93d8,stroke:#7b1fa2,stroke-width:1px
    style payment_svc fill:#ce93d8,stroke:#7b1fa2,stroke-width:1px
    style auth_svc fill:#ce93d8,stroke:#7b1fa2,stroke-width:1px
    style external fill:#c8e6c9,stroke:#388e3c,stroke-width:2px
    style te fill:#fff9c4,stroke:#f57f17,stroke-width:2px
    style te_cloud fill:#ffecb3,stroke:#f57f17,stroke-width:2px
    style te_api fill:#ffe082,stroke:#f57f17,stroke-width:2px
    style splunk fill:#ff6e40,stroke:#d84315,stroke-width:2px
    style otel fill:#ff8a65,stroke:#d84315,stroke-width:2px
    style metrics fill:#ffccbc,stroke:#d84315,stroke-width:1px
    style dashboards fill:#ffccbc,stroke:#d84315,stroke-width:1px
    style apm fill:#ffccbc,stroke:#d84315,stroke-width:1px
    style alerts fill:#ffccbc,stroke:#d84315,stroke-width:1px
    style user fill:#b2dfdb,stroke:#00695c,stroke-width:2px

アーキテクチャコンポーネント

1. Kubernetes クラスター

Secret (te-creds): 認証用の base64 エンコードされた TEAGENT_ACCOUNT_TOKEN を保存します
ThousandEyes Enterprise Agent Pod:
- コンテナイメージ: thousandeyes/enterprise-agent:latest
- ホスト名: te-agent-aleccham（カスタマイズ可能）
- セキュリティケーパビリティ: NET_ADMIN、SYS_ADMIN（ネットワークテストに必要）
- メモリ割り当て: 2GB リクエスト、3.5GB リミット
- ネットワークモード: IPv4 のみ（環境変数 TEAGENT_INET: "4" で設定）
- イメージプルポリシー: Always（最新のイメージが確実にプルされます）
- Init コマンド: /sbin/my_init（エージェントの適切な初期化に必要）
内部サービス: REST API、マイクロサービス、データベース、gRPC サービスを含む Kubernetes ワークロード

2. テスト対象

内部サービス: Kubernetes クラスター内のサービスを監視します
外部サービス: 以下のような外部依存関係をテストします
- 決済ゲートウェイ（Stripe、PayPal）
- サードパーティ API
- SaaS アプリケーション
- CDN エンドポイント
- パブリック Web サイト

3. ThousandEyes Platform

ThousandEyes Cloud: 以下の機能を提供する中央プラットフォーム
- エージェントの登録と管理
- テストの設定とスケジューリング
- メトリクスの収集と集約
- 組み込みアラートエンジン
ThousandEyes API: プログラマティックアクセスのための RESTful API（v7/stream エンドポイント）

4. テストタイプとメトリクス

Enterprise Agent は以下を実行します

HTTP/HTTPS テスト: Web ページの可用性、レスポンスタイム、ステータスコード
DNS テスト: 名前解決時間、レコード検証
ネットワークレイヤーテスト: レイテンシー、パケットロス、パス可視化
Voice/RTP テスト: 音声トラフィックの品質メトリクス

収集されるメトリクスは以下の通りです

HTTP サーバー可用性（%）
スループット（bytes/s）
リクエスト時間（秒）
ページロード完了率（%）
エラーコードと失敗理由

5. Splunk Observability Cloud との統合

OpenTelemetry Metrics Stream:
- エンドポイント: https://ingest.{realm}.signalfx.com/v2/datapoint/otlp
- プロトコル: HTTP または gRPC
- フォーマット: Protobuf
- 認証: X-SF-Token ヘッダー
- シグナルタイプ: Metrics（OpenTelemetry v2）
分散トレーシング統合:
- ThousandEyes テストタイプ: 分散トレーシングが有効な HTTP Server または API
- ThousandEyes コネクターターゲット: https://api.{realm}.signalfx.com
- 認証: X-SF-Token ヘッダーの Splunk API トークン
- 結果: ThousandEyes から関連する Splunk APM トレースを開くことができ、Splunk APM トレースから元の ThousandEyes テストにリンクバックできます
オブザーバビリティ機能:
- Metrics: ThousandEyes データのリアルタイム可視化
- Dashboards: 統合ビューを備えた構築済み ThousandEyes ダッシュボード
- APM/RUM 統合: シンセティックテストとアプリケーショントレースおよびリアルユーザーモニタリングの相関
- Alerting: 相関ルールを備えた一元的なアラート管理

6. データフロー

エージェントが Kubernetes Secret のトークンを使用して認証します
エージェントが内部および外部のターゲットに対してスケジュールされたテストを実行します
テスト結果が ThousandEyes Cloud に送信されます
ThousandEyes が OpenTelemetry プロトコル経由で Splunk にメトリクスをストリーミングします
分散トレーシングが有効な HTTP Server および API テストでは、ThousandEyes がリクエストに b3、traceparent、tracestate ヘッダーを挿入します
インストルメント済みアプリケーションが結果のトレースを Splunk APM に送信します
ThousandEyes から関連する Splunk トレースを開くことができ、Splunk APM から元の ThousandEyes テストにリンクバックできます
DevOps、ネットワーク、アプリケーションチームが調査中に両方のビューを使用して連携します

テスト機能

このデプロイにより、以下のことが可能になります

✅ 内部サービスのテスト: クラスター内から Kubernetes サービス、API、マイクロサービスを監視します
✅ 外部依存関係のテスト: 決済ゲートウェイ、サードパーティ API、SaaS プラットフォームへの接続性を検証します
✅ パフォーマンスの測定: クラスターの視点からレイテンシー、可用性、パフォーマンスメトリクスをキャプチャします
✅ 問題のトラブルシューティング: 問題がインフラストラクチャ、ネットワークパス、またはインストルメント済みアプリケーションサービスのいずれに起因するかを特定します

注意

これは ThousandEyes エージェントの公式にサポートされたデプロイ構成ではありません。ただし、本番環境に近い環境でテスト済みであり、非常にうまく動作します。

デプロイメント

20 minutes

このセクションでは、KubernetesクラスターにThousandEyes Enterprise Agentをデプロイする手順を説明します。

コンポーネント

デプロイメントは2つのファイルで構成されています：

1. シークレットファイル (`credentialsSecret.yaml`)

ThousandEyesエージェントトークン（base64エンコード済み）を含みます。このシークレットは、エージェントをThousandEyes Cloudで認証するためにデプロイメントから参照されます。

apiVersion: v1
kind: Secret
metadata:
  name: te-creds
type: Opaque
data:
  TEAGENT_ACCOUNT_TOKEN: <base64-encoded-token>

2. デプロイメントマニフェスト (`thousandEyesDeploy.yaml`)

以下の主要な設定でEnterprise AgentのPod構成を定義します：

Namespace: te-demo（必要に応じてカスタマイズ）
Image: Docker Hubの thousandeyes/enterprise-agent:latest
Hostname: te-agent-aleccham（ThousandEyesダッシュボードに表示されます）
Capabilities: ネットワークテストに NET_ADMIN と SYS_ADMIN が必要
Resources:
- メモリ制限: 3584Mi
- メモリ要求: 2000Mi

apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: te-demo
  name: thousandeyes
  labels:
    app: thousandeyes
spec:
  replicas: 1
  selector:
    matchLabels:
      app: thousandeyes
  template:
    metadata:
      labels:
        app: thousandeyes
    spec:
      hostname: te-agent-aleccham
      containers:
      - name: thousandeyes
        image: 'thousandeyes/enterprise-agent:latest'
        imagePullPolicy: Always
        command:
          - /sbin/my_init
        securityContext:
          capabilities:
            add:
              - NET_ADMIN
              - SYS_ADMIN
        env:
          - name: TEAGENT_ACCOUNT_TOKEN
            valueFrom:
              secretKeyRef:
                name: te-creds
                key: TEAGENT_ACCOUNT_TOKEN
          - name: TEAGENT_INET
            value: "4"
        resources:
          limits:
            memory: 3584Mi
          requests:
            memory: 2000Mi

重要な注意事項

エージェントはネットワークテストを実行するために昇格した権限（NET_ADMIN、SYS_ADMIN）が必要です
TEAGENT_INET: "4" 環境変数はIPv4専用モードを強制します（一部のネットワーク構成で必要）
/sbin/my_init コマンドは、エージェントの適切な初期化とサービス管理に必要です
imagePullPolicy: Always は常に最新のイメージバージョンをプルすることを保証します
ThousandEyesダッシュボードでエージェントを一意に識別するために hostname フィールドを調整してください
Kubernetes環境に合わせて namespace を変更してください
ThousandEyes Enterprise Agentは比較的高いハードウェア要件があります。環境に応じてこれらを調整する必要がある場合があります

インストール手順

ステップ 1: ThousandEyes トークンの作成

app.thousandeyes.com/login でThousandEyesプラットフォームにログインします
Cloud & Enterprise Agents > Agent Settings > Add New Enterprise Agent に移動します
Account Group Token をコピーします
トークンをBase64エンコードします：
```
echo -n 'your-token-here' | base64
```
次のステップのためにbase64エンコードされた出力を保存します

ステップ 2: Namespace の作成

Namespaceを作成します（存在しない場合）：

kubectl create namespace te-demo

ステップ 3: シークレットの作成

base64エンコードされたトークンを含む credentialsSecret.yaml という名前のファイルを作成します：

apiVersion: v1
kind: Secret
metadata:
  name: te-creds
  namespace: te-demo
type: Opaque
data:
  TEAGENT_ACCOUNT_TOKEN: <your-base64-encoded-token-here>

シークレットを適用します：

kubectl apply -f credentialsSecret.yaml

ステップ 4: デプロイメントの作成

上記のデプロイメントマニフェストを含む thousandEyesDeploy.yaml という名前のファイルを作成します（必要に応じてhostnameとnamespaceをカスタマイズしてください）。

デプロイメントを適用します：

kubectl apply -f thousandEyesDeploy.yaml

ステップ 5: デプロイメントの確認

エージェントが実行中であることを確認します：

kubectl get pods -n te-demo

期待される出力：

NAME                            READY   STATUS    RESTARTS   AGE
thousandeyes-xxxxxxxxxx-xxxxx   1/1     Running   0          2m

エージェントが接続していることを確認するためにログをチェックします：

kubectl logs -n te-demo -l app=thousandeyes

ステップ 6: ThousandEyes ダッシュボードでの確認

ThousandEyesダッシュボードでエージェントが正常に登録されたことを確認します：

Cloud & Enterprise Agents > Agent Settings に移動して、新しく登録されたエージェントを確認します。

成功

ThousandEyes Enterprise AgentがKubernetesで実行されています！次に、Splunk Observability Cloudとの統合を行います。

背景

ThousandEyesは公式のKubernetesデプロイメントドキュメントを提供していません。標準的なデプロイメント方法は docker run コマンドを使用するため、再利用可能なKubernetesマニフェストに変換することが困難です。このガイドは、本番環境対応のKubernetes構成を提供することでそのギャップを埋めます。

Splunk 連携

15 minutes

Splunk Observability Cloud について

Splunk Observability Cloudは、メトリクス、トレース、ログを大規模に監視するために構築されたリアルタイムのオブザーバビリティプラットフォームです。OpenTelemetryデータを取り込み、高度なダッシュボードと分析機能を提供して、チームがパフォーマンスの問題を迅速に検出し解決できるよう支援します。このセクションでは、OpenTelemetryを使用してThousandEyesデータをSplunk Observability Cloudと統合する方法を説明します。

このセクションの範囲

このセクションでは、ThousandEyesからSplunk Observability Cloudへのメトリクスストリーミングパスについて説明します。次のセクションでは、ThousandEyesとSplunk APM間の双方向リンクを作成する別の分散トレーシングワークフローを追加します。

ステップ 1: Splunk Observability Cloud アクセストークンを作成する

ThousandEyesメトリクスをSplunk Observability Cloudに送信するには、Ingest スコープを持つアクセストークンが必要です。以下の手順に従ってください：

Splunk Observability Cloudプラットフォームで、Settings > Access Token に移動します
Create Token をクリックします
Name を入力します
Ingest スコープを選択します
Create を選択してアクセストークンを生成します
アクセストークンをコピーし、安全に保管します

テレメトリデータをSplunk Observability Cloudに送信するには、アクセストークンが必要です。

ステップ 2: 連携を作成する

この連携は、ThousandEyesメトリクスをSplunk Observability Cloudのダッシュボードとディテクターに送信する一方向のテレメトリストリームです。

ThousandEyes UI を使用する

Splunk Observability CloudとThousandEyesを連携するには：

ThousandEyesプラットフォームでアカウントにログインし、Manage > Integration > Integration 1.0 に移動します
New Integration をクリックし、OpenTelemetry Integration を選択します
連携の Name を入力します
Target を HTTP に設定します
Endpoint URL を入力します：https://ingest.{REALM}.signalfx.com/v2/datapoint/otlp
- {REALM} をSplunk環境に置き換えます（例：us1、eu0）
Preset Configuration で Splunk Observability Cloud を選択します
Auth Type で Custom を選択します
以下の Custom Headers を追加します：
- X-SF-Token: {TOKEN}（ステップ1で作成したSplunk Observability Cloudアクセストークンを入力）
- Content-Type: application/x-protobuf
OpenTelemetry Signal で Metric を選択します
Data Model Version で v2 を選択します
テストを選択します
Save をクリックして連携の設定を完了します

これでThousandEyesデータとSplunk Observability Cloudの連携が正常に完了しました。

ThousandEyes API を使用する

プログラムによる連携には、以下のAPIコマンドを使用します：

HTTP Protocol

curl -v -XPOST https://api.thousandeyes.com/v7/stream \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $BEARER_TOKEN" \
  -d '{
    "type": "opentelemetry",
    "testMatch": [{
      "id": "281474976717575",
      "domain": "cea"
    }],
    "endpointType": "http",
    "streamEndpointUrl": "https://ingest.{REALM}.signalfx.com:443/v2/datapoint/otlp",
    "customHeaders": {
      "X-SF-Token": "{TOKEN}",
      "Content-Type": "application/x-protobuf"
    }
  }'

gRPC Protocol

curl -v -XPOST https://api.thousandeyes.com/v7/stream \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $BEARER_TOKEN" \
  -d '{
    "type": "opentelemetry",
    "testMatch": [{
      "id": "281474976717575",
      "domain": "cea"
    }],
    "endpointType": "grpc",
    "streamEndpointUrl": "https://ingest.{REALM}.signalfx.com:443",
    "customHeaders": {
      "X-SF-Token": "{TOKEN}",
      "Content-Type": "application/x-protobuf"
    }
  }'

streamEndpointUrl と X-SF-Token の値を、お使いのSplunk Observability Cloudインスタンスの正しい値に置き換えてください。

注意

{REALM} をSplunk環境のRealm（例：us1、us2、eu0）に、{TOKEN} を実際のSplunkアクセストークンに置き換えてください。

次のステップ

メトリクス連携が完了したら、分散トレーシングに進み、ThousandEyesからSplunk APMへの、そしてその逆の調査パスを追加します。

ステップ 3: Splunk Observability Cloud の ThousandEyes ダッシュボード

連携が設定されると、Splunk Observability Cloud内のThousandEyes Network Monitoring Dashboardでリアルタイムの監視データを表示できます。ダッシュボードには以下が含まれます：

HTTP Server Availability (%)：監視対象のHTTPサーバーの可用性を表示します
HTTP Throughput (bytes/s)：時間の経過に伴うデータ転送速度を表示します
Client Request Duration (seconds)：クライアントリクエストのレイテンシを測定します
Web Page Load Completion (%)：ページ読み込み成功の割合を表示します
Page Load Duration (seconds)：ページの読み込み時間を表示します

ダッシュボードテンプレート

ダッシュボードテンプレートは以下のリンクからダウンロードできます：ThousandEyes Splunk Observability Cloud ダッシュボードテンプレートをダウンロード (Google Drive)。

完了

ThousandEyesデータがSplunk Observability Cloudにストリーミングされるようになりました。次に、分散トレーシングコネクタを追加して、トラブルシューティング中にThousandEyesとSplunk APMの間を移動できるようにします。

分散トレーシングと双方向ドリルダウン

25 minutes

このセクションでは、ThousandEyesとSplunkの統合を真の調査ワークフローに変えます。前のセクションでは、ThousandEyesが合成メトリクスをSplunk Observability Cloudにストリーミングしました。このセクションでは、サポートされている ThousandEyes <-> Splunk APM 分散トレーシング統合 を有効にし、ネットワーク、プラットフォーム、アプリケーションチームが同じリクエストを見ながら両方のツール間を行き来できるようにします。

これが重要な理由

これは、2つの環境間で 双方向アクセス を可能にする部分です。ThousandEyesからSplunk APMの関連トレースを開くことができ、Splunk APMから元のThousandEyesテストに戻ることができます。

学習内容

このセクションを終了すると、以下のことができるようになります：

内部サービスを計装してSplunk APMにトレースを送信する
ThousandEyesの HTTP Server または API テストで分散トレーシングを有効にする
Splunk APM用のThousandEyes Generic Connector を設定する
ThousandEyesの Service Map を開き、対応するSplunkトレースに直接ジャンプする
Splunk APMのThousandEyesメタデータを使用して、元のThousandEyesテストに戻る

サポートされているワークフロー

この学習シナリオは、ThousandEyesとSplunkがドキュメント化しているサポートされたワークフローに従います：

ThousandEyesは、分散トレーシングが有効になっている場合、HTTP Server および API テストに b3、traceparent、tracestate ヘッダーを自動的に挿入します。
監視対象のエンドポイントは、ヘッダーを受け入れ、OpenTelemetryで計装され、トレースコンテキストを伝播し、オブザーバビリティバックエンドにトレースを送信する必要があります。
Splunk APMの場合、ThousandEyesは https://api.<REALM>.signalfx.com を指し、API スコープ のSplunkトークンで認証する Generic Connector を使用します。
Splunk APMは、thousandeyes.test.id や thousandeyes.permalink などのThousandEyes属性で一致するトレースを強化し、ThousandEyesへの逆ジャンプを可能にします。

これらのヘッダーの実際の意味

この部分は見落としがちですが、そうすべきではありません。トレース相関は、サービスがThousandEyesが挿入するヘッダーを理解し、トレースを正しく継続する場合にのみ機能します。

traceparent と tracestate はW3C Trace Contextヘッダーです。
b3 はZipkin B3シングルヘッダー形式です。
ThousandEyesは両方を挿入します。これは、実際の環境には、同じ伝播形式を好まないプロキシ、メッシュ、ゲートウェイ、アプリランタイムが混在していることが多いためです。

OpenTelemetryの用語では、重要な設定はプロパゲーターリストです：

OTEL_PROPAGATORS=baggage,b3,tracecontext

これは2つのことを行います：

サービスが受信ThousandEyesリクエストから B3 または W3C コンテキストのいずれかを抽出できるようにします。
tracecontext を有効にしておくことで、W3C tracestate を保持します。

重要な詳細

tracestate を別のOpenTelemetryプロパゲーターとして追加する必要は ありません。tracecontext プロパゲーターが traceparent と tracestate の両方を処理します。

「正しく行う」とはどういうことか

コレクターはこのセットアップの一部に過ぎません。Kubernetesでの正しいThousandEyesトレーシングデプロイメントには 3 つのレイヤー があります：

Deployment アノテーション - OpenTelemetry Operatorがランタイム固有の計装を挿入するため。
Instrumentation リソース - 挿入されたSDKがトレースの送信先と使用するプロパゲーターを知るため。
Collector トレースパイプライン - OTLPトレースが実際に受信され、Splunk APMにエクスポートされるため。

最も一般的な間違いは、コレクターだけに焦点を当てることです。コレクターは生の b3、traceparent、または tracestate リクエストヘッダーを直接見ることはありません。アプリケーションまたは自動計装ライブラリがまずそれらのヘッダーを抽出し、スパンコンテキストを継続し、次にOTLP経由でコレクターにスパンを送信する必要があります。

現在のクラスターからの実際の設定

以下の例は、このワークショップを現在実行しているライブクラスターからトリミングされたものです。これらは、今日Kubernetesで実際に機能しているパターンを示しています。

1. Deployment アノテーション

ライブクラスターでは、teastore アプリケーションは teastore/default Instrumentationリソースを指しています：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: teastore-webui-v1
  namespace: teastore
spec:
  template:
    metadata:
      annotations:
        instrumentation.opentelemetry.io/container-names: teastore-webui-v1
        instrumentation.opentelemetry.io/inject-java: teastore/default

これは、ThousandEyesリクエストがトレースに変換されない場合に最初に確認する場所です。

2. Instrumentation リソース

これは teastore からのライブ Instrumentation オブジェクトで、ThousandEyesに関係するフィールドにトリミングされています：

apiVersion: opentelemetry.io/v1alpha1
kind: Instrumentation
metadata:
  name: default
  namespace: teastore
spec:
  exporter:
    endpoint: http://splunk-otel-collector-agent.otel-splunk.svc:4317
  propagators:
    - baggage
    - b3
    - tracecontext
  sampler:
    type: parentbased_always_on
  env:
    - name: OTEL_RESOURCE_ATTRIBUTES
      value: deployment.environment=teastore

これがThousandEyesシナリオの重要な部分です：

endpoint はクラスターローカルのOTelエージェントサービスにスパンを送信します。
b3 はThousandEyes B3ヘッダーの抽出を可能にします。
tracecontext は traceparent と tracestate を保持します。
parentbased_always_on は、ThousandEyesがリクエストを開始するとトレースが継続することを保証します。

3. 挿入された Pod が実際に取得するもの

実行中の teastore-webui-v1 Podでは、オペレーターが以下の環境変数を挿入しました：

- name: JAVA_TOOL_OPTIONS
  value: " -javaagent:/otel-auto-instrumentation-java-teastore-webui-v1/javaagent.jar"
- name: OTEL_SERVICE_NAME
  value: teastore-webui-v1
- name: OTEL_EXPORTER_OTLP_ENDPOINT
  value: http://splunk-otel-collector-agent.otel-splunk.svc:4317
- name: OTEL_PROPAGATORS
  value: baggage,b3,tracecontext
- name: OTEL_TRACES_SAMPLER
  value: parentbased_always_on

これは有用な検証チェックポイントです。プロパゲーターが抽象的な設定オブジェクトで宣言されているだけでなく、ワークロードに適用されていることを証明するためです。

4. Agent Collector トレースパイプライン

otel-splunk のライブエージェントコレクターは、OTLP、Jaeger、Zipkinトラフィックを受信し、上流にトレースを転送しています。これは実行中のConfigMapからのトリミングされた抜粋です：

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318
  jaeger:
    protocols:
      grpc:
        endpoint: 0.0.0.0:14250
      thrift_http:
        endpoint: 0.0.0.0:14268
  zipkin:
    endpoint: 0.0.0.0:9411

service:
  pipelines:
    traces:
      receivers: [otlp, jaeger, zipkin]
      processors:
        [memory_limiter, k8sattributes, batch, resourcedetection, resource, resource/add_environment]
      exporters: [otlp, signalfx]

ThousandEyesの場合、重要な部分はコレクターの特別なB3オプションではありません。重要な部分は、コレクターが 4317 と 4318 でOTLPを公開していること、およびサービスがそこにスパンをエクスポートしていることです。

5. Gateway Collector の Splunk APM へのエクスポート

ライブゲートウェイコレクターは、トレースをSplunk Observability Cloudに転送します。これは実行中のゲートウェイConfigMapの関連部分です：

exporters:
  otlphttp:
    auth:
      authenticator: headers_setter
    traces_endpoint: https://ingest.us1.signalfx.com/v2/trace/otlp

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
        include_metadata: true
      http:
        endpoint: 0.0.0.0:4318
        include_metadata: true

service:
  pipelines:
    traces:
      receivers: [otlp, jaeger, zipkin]
      processors:
        [memory_limiter, k8sattributes, batch, resource/add_cluster_name, resource/add_environment]
      exporters: [otlphttp, signalfx]

これは、スパンをSplunk APMに送信する部分です。このパイプラインが壊れている場合、ThousandEyesはリクエストにヘッダーを挿入できますが、相関トレースがSplunkに表示されることはありません。

現在のクラスターのポイント

ライブクラスターでは、teastore/default InstrumentationリソースがThousandEyesで従うべきパターンです。これは b3 と tracecontext を明示的に含んでいるためです。これが、このシナリオで複製したい設定です。

重要

このセクションではブラウザページのURLを使用 しないでください。ThousandEyesのドキュメントによると、ブラウザはこのワークフローに必要なカスタムトレースヘッダーを受け入れません。代わりに、HTTP Server または API テストの背後にある計装されたバックエンドエンドポイントを使用してください。

ステップ 1：ワークロードが Splunk APM にトレースを送信していることを確認する

アプリケーションがすでに計装されていて、トレースがSplunk APMに表示されている場合は、ステップ2にスキップできます。そうでない場合、Kubernetesでの最速の学習パスは、ゼロコード計装用のオペレーターを有効にしたSplunk OpenTelemetry Collectorを使用することです。

Splunk OpenTelemetry Collector とオペレーターをインストールする

helm repo add splunk-otel-collector-chart https://signalfx.github.io/splunk-otel-collector-chart
helm repo update

helm install splunk-otel-collector splunk-otel-collector-chart/splunk-otel-collector \
  --namespace otel-splunk \
  --create-namespace \
  --set splunkObservability.realm=$REALM \
  --set splunkObservability.accessToken=$ACCESS_TOKEN \
  --set clusterName=$CLUSTER_NAME \
  --set operator.enabled=true \
  --set operatorcrds.install=true

自動計装用に Deployment にアノテーションを付ける

Javaワークロードの場合、一般的な例は次のようになります：

kubectl patch deployment api-gateway -n production -p '{"spec":{"template":{"metadata":{"annotations":{"instrumentation.opentelemetry.io/inject-java":"otel-splunk/splunk-otel-collector"}}}}}'

他のランタイムの場合は、言語に合ったアノテーションを使用してください：

instrumentation.opentelemetry.io/inject-nodejs
instrumentation.opentelemetry.io/inject-python
instrumentation.opentelemetry.io/inject-dotnet

コレクターがアプリケーションと同じ名前空間にインストールされている場合、公式のSplunkドキュメントでは "true" をアノテーション値として使用することもサポートしています。

このワークショップ環境の ライブクラスターパターン に従いたい場合、アノテーション値は名前空間修飾され、teastore/default Instrumentationオブジェクトを指します：

kubectl patch deployment teastore-webui-v1 -n teastore -p '{"spec":{"template":{"metadata":{"annotations":{"instrumentation.opentelemetry.io/container-names":"teastore-webui-v1","instrumentation.opentelemetry.io/inject-java":"teastore/default"}}}}}'

トレースが存在することを検証する

デプロイメントのロールアウトが完了するまで待ちます：
```
kubectl rollout status deployment/api-gateway -n production
```
複数のサービスを横断するバックエンドエンドポイントに対していくつかのリクエストを生成します。例：
```
http://api-gateway.production.svc.cluster.local:8080/api/v1/orders
```
現在のワークショップクラスターでは、http://teastore-webui.teastore.svc.cluster.local:8080/ のようなサービスが適切なターゲットです。これは、いくつかの下流アプリケーションサービスをフロントエンドし、単純なヘルスチェックよりも有用なエンドツーエンドトレースを生成するためです。
続行する前に、Splunk APM にトレースが到着していることを確認してください。

学習のヒント

トレーシング演習には、純粋な /health エンドポイントではなく、ビジネストランザクションを使用してください。マルチサービスリクエストは、ThousandEyesでより良いService Mapを提供し、Splunk APMでより有用なトレースを提供します。

ステップ 2：ThousandEyes テストで分散トレーシングを有効にする

ステップ1の計装されたバックエンドエンドポイントをターゲットとする HTTP Server または API テストを作成または編集します。

ThousandEyesで、HTTP Server または API テストを作成します。
Advanced Settings を開きます。
Distributed Tracing を有効にします。
テストを保存し、すでにSplunk APMにトレースを送信しているのと同じエンドポイントに対して実行します。

テストが実行された後、ThousandEyesはトレースヘッダーを挿入し、そのリクエストのトレースコンテキストをキャプチャします。

ステップ 3：ThousandEyes で Splunk APM コネクターを作成する

前のセクションのメトリックストリーミング統合は Ingest トークンを使用します。このステップは異なります：ThousandEyesはSplunk APMにクエリを実行してトレースリンクを構築する必要があるため、代わりにSplunk API トークンを使用します。

Splunk Observability Cloudで、API スコープを持つアクセストークンを作成します。
ThousandEyesで、Manage > Integrations > Integrations 2.0 に移動します。
以下の設定で Generic Connector を作成します：
- Target URL: https://api.<REALM>.signalfx.com
- Header: X-SF-Token: <your-api-scope-token>
新しい Operation を作成し、Splunk Observability APM を選択します。
オペレーションを有効にして、統合を保存します。

ステップ 4：双方向調査ループを検証する

テストが実行され、コネクターが有効になったら、両方向でワークフローを検証します。

ThousandEyes から始める

ThousandEyesでテストを開きます。
Service Map タブに移動します。
トレースパス、サービスレイテンシー、下流のエラーが表示されることを確認します。
ThousandEyesから Splunk APM へのリンクを使用して、完全なトレースを検査します。

Splunk APM で続ける

Splunk APM内で、トレースに以下のようなThousandEyesメタデータが含まれていることを確認します：

thousandeyes.account.id
thousandeyes.test.id
thousandeyes.permalink
thousandeyes.source.agent.id

thousandeyes.permalink フィールドまたはトレースウォーターフォールビューの Go to ThousandEyes test ボタンを使用して、元のThousandEyesテストに戻ります。

推奨される学習シナリオ

ワークショップ中に以下のフローを使用してください：

複数のサービスを呼び出す内部APIルートに対するThousandEyesテストを作成します。
ThousandEyesに最初に問題を表示させ、クラスがネットワークと合成モニタリングの観点から始められるようにします。
ThousandEyesで Service Map を開き、レイテンシーやエラーがどこから始まるかを特定します。
スパンレベルの分析のために Splunk APM にジャンプします。
テスト、エージェント、ネットワークパスを再度検査するために ThousandEyes に戻ります。

これは、異なるチームが実際に作業する方法を反映しているため、強力な教育ループです：

ネットワークおよびエッジチームは、ThousandEyesから始めることが多いです。
SREおよびプラットフォームチームは、Splunkダッシュボードまたはアラートから始めることが多いです。
アプリケーションチームは、通常Splunk APMのトレースを求めます。

この統合が整っていれば、全員がコンテキストを失うことなく切り替えることができます。

よくある落とし穴

テストがSplunkダッシュボードに表示されていても、トレース相関がない場合があります。これは通常、メトリクス ストリームのみが設定されており、Splunk APM Generic Connector が設定されていないことを意味します。
監視対象のエンドポイントがトレースヘッダーを下流に伝播しない場合、トレースがSplunk APMに存在してもThousandEyesに表示されない場合があります。
/health のような浅いエンドポイントは、設定が正しくても限られたトレース価値しか生成しないことがよくあります。

参考資料

Kubernetes サービステストと相関

20 minutes

AppDynamics テスト推奨機能の再現

AppDynamicsには、アプリケーションのエンドポイントに対するシンセティックテストを自動的に提案する「Test Recommendations」という機能があります。ThousandEyesをKubernetesクラスター内にデプロイすることで、KubernetesのサービスディスカバリとSplunk Observability Cloudの統合ビューを組み合わせて、この機能を再現できます。

ThousandEyes Enterprise Agentはクラスター内部で実行されるため、サービス名をホスト名として使用して内部Kubernetesサービスを直接テストできます。これにより、外部に公開されていないバックエンドサービスを監視する強力な方法が得られます。

仕組み

サービスディスカバリ: kubectl get svc を使用してクラスター内のサービスを列挙します
ホスト名の構築: Kubernetes DNS命名規則を使用してテストURLを構築します: <service-name>.<namespace>.svc.cluster.local
テストの作成: 内部サービスに対して可用性テストとトレース対応トランザクションテストの両方を作成します
Splunk での相関: シンセティックテストの結果をAPMトレースおよびインフラストラクチャメトリクスと並べて表示します

クラスター内テストのメリット

内部サービス監視: インターネットに公開されていないバックエンドサービスをテストできます
サービスメッシュ対応: Istio、Linkerd、その他のサービスメッシュの背後にあるサービスを監視できます
DNS 解決テスト: Kubernetes DNSとサービスディスカバリを検証できます
ネットワークポリシー検証: ネットワークポリシーが適切な通信を許可していることを確認できます
レイテンシベースライン: クラスター内部のネットワークパフォーマンスを測定できます
本番前テスト: Ingress/LoadBalancer経由で公開する前にサービスをテストできます

ステップバイステップガイド

1. Kubernetes サービスの検出

クラスター内または特定のnamespace内のすべてのサービスを一覧表示します:

# Get all services in all namespaces
kubectl get svc --all-namespaces

# Get services in a specific namespace
kubectl get svc -n production

# Get services with detailed output including ports
kubectl get svc -n production -o wide

出力例:

NAMESPACE    NAME           TYPE        CLUSTER-IP      PORT(S)    AGE
production   api-gateway    ClusterIP   10.96.100.50    8080/TCP   5d
production   payment-svc    ClusterIP   10.96.100.51    8080/TCP   5d
production   auth-service   ClusterIP   10.96.100.52    9000/TCP   5d
production   postgres       ClusterIP   10.96.100.53    5432/TCP   5d

2. テストホスト名の構築

Kubernetesサービスは、以下の命名パターンを使用してDNS経由でアクセスできます:

<service-name>.<namespace>.svc.cluster.local

上記のサービスの場合:

api-gateway.production.svc.cluster.local:8080
payment-svc.production.svc.cluster.local:8080
auth-service.production.svc.cluster.local:9000

同じ namespace 内での省略形: ThousandEyesエージェントと同じnamespace内のサービスをテストする場合は、サービス名のみを使用できます:

api-gateway:8080
payment-svc:8080

3. 内部サービス用の ThousandEyes テストの作成

最良の学習成果を得るために、2 種類のテストを作成します:

/health または /readiness エンドポイントに対する可用性テストで、到達可能性と応答時間を検証します
複数のサービスを横断するビジネスエンドポイントに対するトレース対応トランザクションテスト

最初のテストはシンセティック監視を学ぶためのものです。2番目のテストはSplunk APMを使用したクロスツールトラブルシューティングを学ぶためのものです。

ThousandEyes UI 経由

Cloud & Enterprise Agents > Test Settings に移動します
Add New Test → HTTP Server をクリックします
可用性テストを設定します:
- Test Name: [K8s] API Gateway Health
- URL: http://api-gateway.production.svc.cluster.local:8080/health
- Interval: 2 minutes
- Agents: KubernetesにデプロイされたEnterprise Agentを選択します
- HTTP Response Code: 200
トレース対応トランザクションテストを設定します:
- Test Name: [Trace] API Gateway Orders
- URL: http://api-gateway.production.svc.cluster.local:8080/api/v1/orders
- Interval: 2 minutes
- Agents: KubernetesにデプロイされたEnterprise Agentを選択します
- Advanced Settings > Distributed Tracing: Enabled
Create Test をクリックします

ThousandEyes API 経由

curl -X POST https://api.thousandeyes.com/v6/tests/http-server/new \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $BEARER_TOKEN" \
  -d '{
    "testName": "[K8s] API Gateway Health",
    "url": "http://api-gateway.production.svc.cluster.local:8080/health",
    "interval": 120,
    "agents": [
      {"agentId": "<your-k8s-agent-id>"}
    ],
    "httpTimeLimit": 5000,
    "targetResponseTime": 1000,
    "alertsEnabled": 1
  }'

トレース対応バージョンの場合は、url をビジネストランザクションエンドポイントに切り替え、ThousandEyesテスト設定でdistributed tracingを有効にします。

ベストプラクティス

distributed tracingを教えることが目的の場合、/health だけを例として使用することは避けてください。ヘルスチェックは稼働時間の監視には便利ですが、ThousandEyesとSplunk APMの統合を魅力的にするマルチサービストレースを生成することはほとんどありません。

4. アラートルールの設定

一般的な障害シナリオに対するアラートを設定します:

可用性アラート: HTTPレスポンスが200でない場合にトリガーします
パフォーマンスアラート: レスポンスタイムがベースラインを超えた場合にトリガーします
DNS 解決アラート: サービスDNSが解決できない場合にトリガーします

5. Splunk Observability Cloud での結果表示

テストが実行され、Splunkと統合されたら:

Splunk Observability Cloudで ThousandEyes Dashboard に移動します
テスト名でフィルターします（例: [K8s] プレフィックス）、すべてのKubernetes内部テストを表示します
トレース対応テストの場合は、まず ThousandEyes から開始します:
- Service Map を開きます
- サービスレベルのレイテンシとダウンストリームエラーを調べます
- Splunk APM へのリンクをたどります
APM データとの相関:
- シンセティックテストの失敗をAPMエラー率と並べて表示します
- 問題がネットワーク関連（ThousandEyes）かアプリケーション関連（APM）かを特定します
- Splunkトレースメタデータを使用して、元のThousandEyesテストに戻ります
以下を組み合わせたカスタムダッシュボードを作成します:
- ThousandEyes HTTP可用性メトリクス
- APMサービスレイテンシとエラー率
- Kubernetesインフラストラクチャメトリクス（CPU、メモリ、Pod再起動）

ユースケース例

ユースケース 1: マイクロサービスヘルスチェック

複数のマイクロサービスヘルスエンドポイントをテストします:

http://user-service.production.svc.cluster.local:8080/actuator/health
http://order-service.production.svc.cluster.local:8080/actuator/health
http://inventory-service.production.svc.cluster.local:8080/actuator/health

ユースケース 2: API Gateway エンドポイントテスト

有用なトレースを生成する可能性が高いAPI Gatewayルートをテストします:

http://api-gateway.production.svc.cluster.local:8080/api/v1/users
http://api-gateway.production.svc.cluster.local:8080/api/v1/orders
http://api-gateway.production.svc.cluster.local:8080/api/v1/products

ユースケース 3: データベース接続テスト

ThousandEyesは主にHTTPテスト用ですが、データベースプロキシをテストできます:

# Test PgBouncer or database HTTP management interfaces
http://pgbouncer.production.svc.cluster.local:8080/stats
http://redis-exporter.production.svc.cluster.local:9121/metrics

ユースケース 4: 外部サービス依存関係

クラスター内ThousandEyesエージェントの最も価値のある機能の1つは、サービスと同じネットワークの視点からアプリケーションの外部依存関係を監視することです。これにより、問題がインフラストラクチャ、ネットワークパス、または外部サービス自体のいずれに起因するかを特定できます。

決済ゲートウェイのテスト

重要な決済ゲートウェイエンドポイントの可用性とパフォーマンスを確保するためのテストを作成します:

Stripe API:

# Via ThousandEyes UI
Test Name: [External] Stripe API Health
URL: https://api.stripe.com/healthcheck
Interval: 2 minutes
Agents: Your Kubernetes Enterprise Agent
Expected Response: 200

PayPal API:

Test Name: [External] PayPal API Health
URL: https://api.paypal.com/v1/notifications/webhooks
Interval: 2 minutes
Agents: Your Kubernetes Enterprise Agent
Expected Response: 401 (authentication required, but endpoint is reachable)

ThousandEyes API 経由:

curl -X POST https://api.thousandeyes.com/v6/tests/http-server/new \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $BEARER_TOKEN" \
  -d '{
    "testName": "[External] Stripe API Availability",
    "url": "https://api.stripe.com/healthcheck",
    "interval": 120,
    "agents": [
      {"agentId": "<your-k8s-agent-id>"}
    ],
    "httpTimeLimit": 5000,
    "targetResponseTime": 2000,
    "alertsEnabled": 1
  }'

なぜ外部依存関係を監視するのか？

プロアクティブな問題検出: 顧客から報告される前に決済ゲートウェイの障害を把握できます
ネットワークパス検証: Kubernetesエグレスネットワークが外部サービスに到達できることを確認します
パフォーマンスベースライン: クラスターから外部APIへのレイテンシを追跡します
コンプライアンスと SLA 監視: サードパーティサービスがSLAコミットメントを満たしていることを確認します
根本原因分析: 問題がネットワーク関連か、インフラストラクチャか、外部プロバイダーかを迅速に判断します

監視を推奨する外部サービス

決済プロセッサ: Stripe、PayPal、Square、Braintree
認証プロバイダー: Auth0、Okta、Azure AD
メールサービス: SendGrid、Mailgun、AWS SES
SMS/コミュニケーション: Twilio、MessageBird
CDN エンドポイント: Cloudflare、Fastly、Akamai
クラウドストレージ: AWS S3、Google Cloud Storage、Azure Blob Storage
サードパーティ API: 重要なビジネスパートナー API

ベストプラクティス

テスト名に [External] プレフィックスを使用して、ダッシュボードで内部Kubernetesサービスと外部依存関係を簡単に区別できるようにします。

ベストプラクティス

一貫した命名を使用する: フィルタリングを容易にするため、テスト名に [K8s] または [Internal] プレフィックスを付けます
まずヘルスエンドポイントをテストする: ビジネスロジックをテストする前に /health または /readiness エンドポイントから始めます
適切な間隔を設定する: 重要なサービスには短い間隔（1〜2分）を使用します
テストにタグを付ける: ThousandEyesのラベル/タグを使用してテストをグループ化します:
- 環境（dev、staging、production）
- サービスタイプ（API、database、cache）
- チームオーナーシップ
テストエージェントの健全性を監視する: ThousandEyesエージェントPodが健全で、十分なリソースがあることを確認します
両方のテストタイプを使用する: 各重要なサービスパスに対して、シンプルな可用性テストとトレース対応ビジネストランザクションテストをペアにします
APM との相関: シンセティックデータとAPMデータを並べて表示するSplunkダッシュボードを作成します
トレースラボには計装されたバックエンドを使用する: distributed tracingは、ThousandEyesのターゲットがOpenTelemetryで計装されたサービスによってバックアップされたHTTP ServerまたはAPIエンドポイントである場合に最も効果的です

ヒント

内部サービスを外部に公開する前にテストすることで、問題を早期に発見し、ユーザートラフィックが到達する前にインフラストラクチャが健全であることを確認できます。

ThousandEyes と Splunk RUM

10 minutes

ThousandEyesとSplunk RUMを統合して、ネットワークの問題がエンドユーザーの問題と関連しているかどうかを把握します。

前提条件

Splunk Observability CloudとThousandEyes両方の管理者権限
Splunk RUMにデータを送信しているアプリケーションが少なくとも1つ
Splunk RUMのアプリと同じドメインで、ThousandEyesで以下のタイプのテストが少なくとも1つ実行されていること：

統合手順

ThousandEyesでOAuth Bearerトークンを作成します：
- 右上隅のユーザー名を選択し、Profile を選択します。
- User API Tokensの下で Create を選択してOAuth Bearer Tokenを生成します。
- Observability Cloudのデータ統合ウィザードで使用するため、トークンをコピーまたはメモしておきます。
Splunk Observability Cloudで、Data Management > Available Integrations > ThousandEyes Integration with RUMを開きます。
- 前回の Splunk 統合で使用したものと同じ Ingest トークンを使用するか、RUM統合のデータ使用量をより適切に追跡するために専用の Ingest トークンを作成して選択します。
- ThousandEyesからのOAuth Bearerトークンを入力します。
- テストのマッチングを確認し、必要に応じて選択を変更し、推定データ取り込み量を確認してから Done を選択します。

統合の確認

ThousandEyesテストが実行されているRUMアプリケーションに移動し、Mapを表示します。 ThousandEyesテストも実行されているロケーションにカーソルを合わせると、ThousandEyesメトリクスのプレビューが表示されます：

ThousandEyesでアクティブなアラートがある場合、RUMの該当するロケーションのバブル上にThousandEyesアイコンが表示されます：

該当するリージョンをクリックすると、RUMの他のメトリクスと一緒にネットワークメトリクスが表示されます。View ThousandEyes Tests を開いてThousandEyesの関連テストに移動できます：

カスタムダッシュボードで RUM と ThousandEyes のメトリクスを表示する

これで、関連するThousandEyesテストからのシグナルと他のObservability CloudのKPIを関連付けることができます！

Dashboards > “RUM” で検索 > RUM applications グループ内のすぐに使えるRUMダッシュボードの1つをクリックします。
興味のあるRUM KPIのチャートをコピーするか、右上のダッシュボードのアクションメニューを開いて Save As で自分のダッシュボードグループにコピーを作成します。
新しいダッシュボードで、シグナル network.latency を使用して新しいチャートを作成します。
- extrapolation policyを Last value に変更します。
- 測定単位をTime > Millisecond に変更します。
- Chart Optionsで、Show on-chart legend を選択し、値を thousandeyes.source.agent.name にします。これにより、ThousandEyesのエージェントロケーション別にチャートが分割されます。
新しいチャートに名前を付けて保存し、それをコピーして network.jitter と network.loss の類似チャートを作成します。コピーしたチャートのシグナルでメトリクスを変更し、必要に応じて測定単位と可視化オプションを調整します。

カスタムダッシュボードとチャートの作成に関する詳細なガイダンスは、Dashboard Workshop を参照してください。

ヒント

ThousandEyesのテストメトリクスと並べて表示すると便利なObservability Cloudの他のメトリクスについて考えてみてください。

例えば、SyntheticsでAPIテストを実行している場合は、ロケーション別のAPIテスト成功率のヒートマップを追加することを検討してください。

トラブルシューティング

15 minutes

このセクションでは、KubernetesでThousandEyes Enterprise Agentをデプロイおよび使用する際に遭遇する可能性のある一般的な問題について説明します。

DNS 解決エラーでテストが失敗する

テストがDNS解決エラーで失敗している場合は、ThousandEyes Pod内からDNSを確認してください：

# Verify DNS resolution from within the pod
kubectl exec -n te-demo -it <pod-name> -- nslookup api-gateway.production.svc.cluster.local

# Check CoreDNS logs
kubectl logs -n kube-system -l k8s-app=kube-dns

一般的な原因：

指定されたnamespaceにサービスが存在しない
サービス名またはnamespaceの入力ミス
CoreDNSが正常に機能していない

接続拒否エラー

接続拒否エラーが発生している場合は、以下を確認してください：

# Verify service endpoints exist
kubectl get endpoints -n production api-gateway

# Check if pods are ready
kubectl get pods -n production -l app=api-gateway

# Test connectivity from agent pod
kubectl exec -n te-demo -it <pod-name> -- curl -v http://api-gateway.production.svc.cluster.local:8080/health

一般的な原因：

サービスをバックアップするPodがない（endpointsが空）
PodがReady状態でない
テストURLで間違ったポートが指定されている
サービスセレクターがPodラベルと一致しない

Network Policy がトラフィックをブロックしている

Network PolicyがThousandEyesエージェントからのトラフィックをブロックしている場合：

# List network policies
kubectl get networkpolicies -n production

# Describe network policy
kubectl describe networkpolicy <policy-name> -n production

解決策： te-demo namespaceからサービスへのトラフィックを許可するNetwork Policyを作成します：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-thousandeyes-agent
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api-gateway
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: te-demo
    ports:
    - protocol: TCP
      port: 8080

エージェント Pod が起動しない

ThousandEyesエージェントPodが起動しない場合は、Podのステータスとイベントを確認してください：

# Get pod status
kubectl get pods -n te-demo

# Describe pod to see events
kubectl describe pod -n te-demo <pod-name>

# Check logs
kubectl logs -n te-demo <pod-name>

一般的な原因：

リソース不足（memory/CPU）
無効または欠落しているTEAGENT_ACCOUNT_TOKENシークレット
Pod Security Policyによってセキュリティコンテキストのケイパビリティが許可されていない
イメージプルエラー

解決策：

OOMKilledの場合はメモリ制限を増やす
シークレットが正しく作成されているか確認する：kubectl get secret te-creds -n te-demo -o yaml
Pod Security PolicyがNET_ADMINおよびSYS_ADMINケイパビリティを許可しているか確認する
イメージプルを確認する：kubectl describe pod -n te-demo <pod-name>

エージェントが ThousandEyes ダッシュボードに表示されない

エージェントは実行中だがThousandEyesダッシュボードに表示されない場合：

# Check agent logs for connection issues
kubectl logs -n te-demo -l app=thousandeyes --tail=100

一般的な原因：

無効または不正なTEAGENT_ACCOUNT_TOKEN
ネットワークのEgressがブロックされている（ファイアウォールまたはNetwork Policy）
エージェントがThousandEyes Cloudサーバーに到達できない

解決策：

トークンが正しく、適切にbase64エンコードされているか確認する
*.thousandeyes.com へのEgressが許可されているか確認する
エージェントがインターネットに到達できるか確認する：

kubectl exec -n te-demo -it <pod-name> -- curl -v https://api.thousandeyes.com

データが Splunk Observability Cloud に表示されない

ThousandEyesのデータがSplunkに表示されない場合：

統合の設定を確認：

ThousandEyesでOpenTelemetry統合が正しく設定されているか確認する
SplunkインジェストエンドポイントURLがお使いのRealmに対して正しいか確認する
X-SF-Token ヘッダーに有効なSplunkアクセストークンが含まれているか確認する
テストが統合に割り当てられているか確認する

テストの割り当てを確認：

# Use ThousandEyes API to verify integration
curl -v https://api.thousandeyes.com/v7/stream \
  -H "Authorization: Bearer $BEARER_TOKEN"

一般的な原因：

エンドポイントURLのSplunk Realmが間違っている
無効または期限切れのSplunkアクセストークン
テストがOpenTelemetry統合に割り当てられていない
統合が適切に有効化または保存されていない

分散トレーシングが ThousandEyes に表示されない

メトリクスストリームは機能しているが、ThousandEyesの Service Map が空であるか、トレースが見つからない場合：

監視対象のエンドポイントを確認：

HTTPヘッダーを受け入れること
OpenTelemetryで計装されていること
トレースコンテキストを下流に伝播すること
Splunk APMにトレースを送信すること

一般的な原因：

エンドポイントがHTTP ServerまたはAPIターゲットではなくページURLである
サービスが計装されていないため、ThousandEyesはヘッダーを注入できるがトレースは出力されない
エンドポイントがローカルのヘルスレスポンスのみを返し、下流サービスを実行しない

推奨される修正：

ThousandEyesテストを計装されたバックエンドAPIルートに切り替える
そのルートのトレースが既にSplunk APMに存在することを確認する
ThousandEyes分散トレーシングを有効にした後、テストを再実行する

Splunk APM に ThousandEyes リンクが表示されない

トレースがSplunk APMで開くが、ThousandEyesのバックリンクやメタデータが表示されない場合：

一般的な原因：

b3 プロパゲーターが trace_state を上書きし、ThousandEyesがリバースリンクのために保持することを期待している値をクリアする可能性があります。

修正：

計装されたサービスでプロパゲーターを明示的に設定します：

OTEL_PROPAGATORS=baggage,b3,tracecontext

環境変数を変更した後、計装されたワークロードを再起動し、新しいトラフィックを生成します。

Splunk APM Connector の認証エラー

ThousandEyesの Generic Connector がSplunk APMにクエリできない場合：

以下を確認してください：

コネクターのターゲットが https://api.<REALM>.signalfx.com であること
コネクターで使用されているトークンが API スコープを持っていること
トークンを作成するユーザーがSplunk Observability Cloudで必要なロールを持っていること

トークンに関する注意

OpenTelemetryメトリクスストリームはSplunk Ingest トークンを使用します。APM用のThousandEyes Generic Connector はSplunk API トークンを使用します。これらを混同することは、部分的な統合の最も一般的な原因の一つです。

メモリ使用量が高い

ThousandEyesエージェントPodが過剰なメモリを消費している場合：

# Check current memory usage
kubectl top pod -n te-demo

# Check for OOMKilled events
kubectl describe pod -n te-demo <pod-name> | grep -i oom

解決策：

デプロイメントでメモリ制限を増やす：

resources:
  limits:
    memory: 4096Mi  # Increase from 3584Mi
  requests:
    memory: 2500Mi  # Increase from 2000Mi

エージェントに割り当てられた同時テストの数を減らす
エージェントが不要なサービスを実行していないか確認する

Permission Denied エラー

エージェントのログにPermission Deniedエラーが表示される場合：

セキュリティコンテキストを確認：

kubectl get pod -n te-demo <pod-name> -o jsonpath='{.spec.containers[0].securityContext}'

解決策： Podに必要なケイパビリティがあることを確認します：

securityContext:
  capabilities:
    add:
      - NET_ADMIN
      - SYS_ADMIN

注意

厳格なPod Security Policyを持つ一部のKubernetesクラスターでは、これらのケイパビリティが許可されない場合があります。適切なポリシー例外を作成するために、クラスター管理者と協力する必要があるかもしれません。

サポートを受ける

このガイドでカバーされていない問題に遭遇した場合：

ThousandEyes Support: support.thousandeyes.com でThousandEyesサポートに連絡してください
Splunk Support: Splunk Observability Cloudの問題については、Splunk Support をご覧ください
コミュニティフォーラム:
- ThousandEyes Community
- Splunk Community

ヒント

サポートを求める際は、より効果的にトラブルシューティングできるよう、関連するログ、Podの説明、エラーメッセージを必ず含めてください。

ThousandEyes と Splunk Observability Cloud の統合

学習内容

セクション

コアパス

シナリオ拡張

サポート

前提条件

統合のメリット

ThousandEyes 統合のサブセクション

概要

ThousandEyes エージェントタイプ

Enterprise Agent

Endpoint Agent

アーキテクチャ

アーキテクチャコンポーネント

1. Kubernetes クラスター

2. テスト対象

3. ThousandEyes Platform

4. テストタイプとメトリクス

5. Splunk Observability Cloud との統合

6. データフロー

テスト機能

デプロイメント

コンポーネント

1. シークレットファイル (credentialsSecret.yaml)

2. デプロイメントマニフェスト (thousandEyesDeploy.yaml)

インストール手順

ステップ 1: ThousandEyes トークンの作成

ステップ 2: Namespace の作成

ステップ 3: シークレットの作成

ステップ 4: デプロイメントの作成

ステップ 5: デプロイメントの確認

ステップ 6: ThousandEyes ダッシュボードでの確認

背景

Splunk 連携

Splunk Observability Cloud について

ステップ 1: Splunk Observability Cloud アクセストークンを作成する

ステップ 2: 連携を作成する

ThousandEyes UI を使用する

ThousandEyes API を使用する

HTTP Protocol

gRPC Protocol

ステップ 3: Splunk Observability Cloud の ThousandEyes ダッシュボード

ダッシュボードテンプレート

分散トレーシングと双方向ドリルダウン

学習内容

サポートされているワークフロー

これらのヘッダーの実際の意味

「正しく行う」とはどういうことか

現在のクラスターからの実際の設定

1. Deployment アノテーション

2. Instrumentation リソース

3. 挿入された Pod が実際に取得するもの

4. Agent Collector トレースパイプライン

5. Gateway Collector の Splunk APM へのエクスポート

ステップ 1：ワークロードが Splunk APM にトレースを送信していることを確認する

Splunk OpenTelemetry Collector とオペレーターをインストールする

自動計装用に Deployment にアノテーションを付ける

トレースが存在することを検証する

ステップ 2：ThousandEyes テストで分散トレーシングを有効にする

ステップ 3：ThousandEyes で Splunk APM コネクターを作成する

ステップ 4：双方向調査ループを検証する

ThousandEyes から始める

Splunk APM で続ける

推奨される学習シナリオ

よくある落とし穴

参考資料

Kubernetes サービステストと相関

AppDynamics テスト推奨機能の再現

仕組み

クラスター内テストのメリット

ステップバイステップガイド

1. Kubernetes サービスの検出

2. テストホスト名の構築

3. 内部サービス用の ThousandEyes テストの作成

ThousandEyes UI 経由

ThousandEyes API 経由

4. アラートルールの設定

5. Splunk Observability Cloud での結果表示

ユースケース例

1. シークレットファイル (`credentialsSecret.yaml`)

2. デプロイメントマニフェスト (`thousandEyesDeploy.yaml`)