概要

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

デプロイメント

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

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

1. app.thousandeyes.com/login でThousandEyesプラットフォームにログインします

2. Cloud & Enterprise Agents > Agent Settings > Add New Enterprise Agent に移動します

3. Account Group Token をコピーします

4. トークンをBase64エンコードします：

   echo -n 'your-token-here' | base64

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

Splunk 連携

Splunk Observability Cloud について

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

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

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

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

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

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

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

ThousandEyes UI を使用する

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

1. ThousandEyesプラットフォームでアカウントにログインし、Manage > Integration > Integration 1.0 に移動します

2. New Integration をクリックし、OpenTelemetry Integration を選択します

   

3. 連携の Name を入力します

4. Target を HTTP に設定します

5. Endpoint URL を入力します：https://ingest.{REALM}.signalfx.com/v2/datapoint/otlp

   • {REALM} をSplunk環境に置き換えます（例：us1、eu0）

6. Preset Configuration で Splunk Observability Cloud を選択します

7. Auth Type で Custom を選択します

8. 以下の Custom Headers を追加します：

   • X-SF-Token: {TOKEN}（ステップ1で作成したSplunk Observability Cloudアクセストークンを入力）
   • Content-Type: application/x-protobuf

9. OpenTelemetry Signal で Metric を選択します

10. Data Model Version で v2 を選択します

11. テストを選択します

12. 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インスタンスの正しい値に置き換えてください。

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

学習内容

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

• 内部サービスを計装して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つのことを行います：

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

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

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

1. Deployment アノテーション - OpenTelemetry Operatorがランタイム固有の計装を挿入するため。
2. Instrumentation リソース - 挿入されたSDKがトレースの送信先と使用するプロパゲーターを知るため。
3. 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に表示されることはありません。

ステップ 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"}}}}}'

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

1. デプロイメントのロールアウトが完了するまで待ちます：

   kubectl rollout status deployment/api-gateway -n production

2. 複数のサービスを横断するバックエンドエンドポイントに対していくつかのリクエストを生成します。例：

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

   現在のワークショップクラスターでは、http://teastore-webui.teastore.svc.cluster.local:8080/ のようなサービスが適切なターゲットです。これは、いくつかの下流アプリケーションサービスをフロントエンドし、単純なヘルスチェックよりも有用なエンドツーエンドトレースを生成するためです。

3. 続行する前に、Splunk APM にトレースが到着していることを確認してください。

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

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

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

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

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

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

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

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

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

ThousandEyes から始める

1. ThousandEyesでテストを開きます。
2. Service Map タブに移動します。
3. トレースパス、サービスレイテンシー、下流のエラーが表示されることを確認します。
4. 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テストに戻ります。

推奨される学習シナリオ

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

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

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

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

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

よくある落とし穴

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

参考資料

• ThousandEyes Distributed Tracing
• ThousandEyes Distributed Tracing with Splunk Observability APM
• Splunk APM: View traces with Cisco ThousandEyes integration
• Splunk OTel Collector zero-code instrumentation for Kubernetes language runtimes

Kubernetes サービステストと相関

AppDynamics テスト推奨機能の再現

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

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

仕組み

1. サービスディスカバリ: kubectl get svc を使用してクラスター内のサービスを列挙します
2. ホスト名の構築: Kubernetes DNS命名規則を使用してテストURLを構築します: <service-name>.<namespace>.svc.cluster.local
3. テストの作成: 内部サービスに対して可用性テストとトレース対応トランザクションテストの両方を作成します
4. 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 経由

1. Cloud & Enterprise Agents > Test Settings に移動します
2. Add New Test → HTTP Server をクリックします
3. 可用性テストを設定します:
   • 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
4. トレース対応トランザクションテストを設定します:
   • 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
5. 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を有効にします。

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

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

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

5. Splunk Observability Cloud での結果表示

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

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

ベストプラクティス

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

ThousandEyes と Splunk RUM

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

前提条件

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

統合手順

1. ThousandEyesでOAuth Bearerトークンを作成します：
   • 右上隅のユーザー名を選択し、Profile を選択します。
   • User API Tokensの下で Create を選択してOAuth Bearer Tokenを生成します。
   • Observability Cloudのデータ統合ウィザードで使用するため、トークンをコピーまたはメモしておきます。
2. 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を関連付けることができます！

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

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

トラブルシューティング

このセクションでは、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サーバーに到達できない

解決策：

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

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

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

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

統合の設定を確認：

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

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

# 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はヘッダーを注入できるがトレースは出力されない
• エンドポイントがローカルのヘルスレスポンスのみを返し、下流サービスを実行しない

推奨される修正：

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

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

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

一般的な原因：

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

修正：

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

OTEL_PROPAGATORS=baggage,b3,tracecontext

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

Splunk APM Connector の認証エラー

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

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

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

メモリ使用量が高い

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

解決策：

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

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

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

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

サポートを受ける

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

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