概要

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

Cilium のインストール

ステップ 1: Cilium Enterprise の設定

cilium-enterprise-values.yaml という名前のファイルを作成します。<YOUR-EKS-API-SERVER-ENDPOINT> を前のステップで取得したエンドポイントに置き換えてください（https:// プレフィックスは除きます）。

# Enable/disable debug logging
debug:
  enabled: false
  verbose: ~

# Configure unique cluster name & ID
cluster:
  name: isovalent-demo
  id: 0

# Configure ENI specifics
eni:
  enabled: true
  updateEC2AdapterLimitViaAPI: true   # Dynamically fetch ENI limits from EC2 API
  awsEnablePrefixDelegation: true     # Assign /28 CIDR blocks per ENI (16 IPs) instead of individual IPs

enableIPv4Masquerade: false           # Pods use their real VPC IPs — no SNAT needed in ENI mode
loadBalancer:
  serviceTopology: true               # Prefer backends in the same AZ to reduce cross-AZ traffic costs

ipam:
  mode: eni

routingMode: native                   # No overlay tunnels — traffic routes natively through VPC

# BPF / KubeProxyReplacement
# Cilium replaces kube-proxy entirely with eBPF programs in the kernel.
# This requires a direct path to the API server, hence k8sServiceHost.
kubeProxyReplacement: "true"
k8sServiceHost: <YOUR-EKS-API-SERVER-ENDPOINT>
k8sServicePort: 443

# TLS for internal Cilium communication
tls:
  ca:
    certValidityDuration: 3650        # 10 years for the CA cert

# Hubble: network observability built on top of Cilium's eBPF datapath
hubble:
  enabled: true
  metrics:
    enableOpenMetrics: true           # Use OpenMetrics format for better Prometheus compatibility
    enabled:
      # DNS: query/response tracking with namespace-level label context
      - dns:labelsContext=source_namespace,destination_namespace
      # Drop: packet drop reasons (policy deny, invalid, etc.) per namespace
      - drop:labelsContext=source_namespace,destination_namespace
      # TCP: connection state tracking (SYN, FIN, RST) per namespace
      - tcp:labelsContext=source_namespace,destination_namespace
      # Port distribution: which destination ports are being used
      - port-distribution:labelsContext=source_namespace,destination_namespace
      # ICMP: ping/traceroute visibility with workload identity context
      - icmp:labelsContext=source_namespace,destination_namespace;sourceContext=workload-name|reserved-identity;destinationContext=workload-name|reserved-identity
      # Flow: per-workload flow counters (forwarded, dropped, redirected)
      - flow:sourceContext=workload-name|reserved-identity;destinationContext=workload-name|reserved-identity
      # HTTP L7: request/response metrics with full workload context and exemplars for trace correlation
      - "httpV2:exemplars=true;labelsContext=source_ip,source_namespace,source_workload,destination_namespace,destination_workload,traffic_direction;sourceContext=workload-name|reserved-identity;destinationContext=workload-name|reserved-identity"
      # Policy: network policy verdict tracking (allowed/denied) per workload
      - "policy:sourceContext=app|workload-name|pod|reserved-identity;destinationContext=app|workload-name|pod|dns|reserved-identity;labelsContext=source_namespace,destination_namespace"
      # Flow export: enables Hubble to export flow records to Timescape for historical storage
      - flow_export
    serviceMonitor:
      enabled: true                   # Creates a Prometheus ServiceMonitor for auto-discovery
  tls:
    enabled: true
    auto:
      enabled: true
      method: cronJob                 # Automatically rotate Hubble TLS certs on a schedule
      certValidityDuration: 1095      # 3 years per cert rotation
  relay:
    enabled: true                     # Hubble Relay aggregates flows from all nodes cluster-wide
    tls:
      server:
        enabled: true
    prometheus:
      enabled: true
      serviceMonitor:
        enabled: true
  timescape:
    enabled: true                     # Stores historical flow data for time-travel debugging

# Cilium Operator: cluster-wide identity and endpoint management
operator:
  prometheus:
    enabled: true
    serviceMonitor:
      enabled: true

# Cilium Agent: per-node eBPF datapath metrics
prometheus:
  enabled: true
  serviceMonitor:
    enabled: true

# Cilium Envoy: L7 proxy metrics (HTTP, gRPC)
envoy:
  prometheus:
    enabled: true
    serviceMonitor:
      enabled: true

# Enable the Cilium agent to hand off DNS proxy responsibilities to the
# external DNS Proxy HA deployment, so policies keep working during upgrades
extraConfig:
  external-dns-proxy: "true"

# Enterprise feature gates — these must be explicitly approved
enterprise:
  featureGate:
    approved:
      - DNSProxyHA          # High-availability DNS proxy (installed separately)
      - HubbleTimescape     # Historical flow storage via Timescape

ステップ 2: Cilium Enterprise のインストール

新しいノードがEKSクラスターに参加すると、そのノードのkubeletはすぐにCNIプラグインを探してネットワーキングをセットアップします。/etc/cni/net.d/ に存在するCNI設定を読み取り、それを使用してノードを初期化します。ノードグループを先に作成すると、AWS VPC CNI が最初に到達します — そして一度ノードが特定のCNIで初期化されると、別のCNIに切り替えるにはノードをドレインして再初期化する必要があります。

ノードが存在する前にCiliumをインストールすることで、CiliumのCNI設定が kube-system に既に存在し、ノードが起動した瞬間にピックアップされる準備ができていることを保証します。EC2インスタンスが起動すると、CiliumのDaemonSet Podがすぐにスケジュールされ、eBPFプログラムがロードされ、ノードは最初の瞬間からCiliumの制御下で Ready 状態になります。

これは、EKSセットアップのステップ3でクラスターが disableDefaultAddons: true で作成された理由でもあります — これがないと、AWS VPC CNIが自動的にインストールされ、Ciliumと競合することになります。

Helmを使用してCiliumをインストールします：

helm install cilium isovalent/cilium --version 1.18.4 \
  --namespace kube-system -f cilium-enterprise-values.yaml

ステップ 3: ノードグループの作成

nodegroup.yaml という名前のファイルを作成します：

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: isovalent-demo
  region: us-east-1
managedNodeGroups:
- name: standard
  instanceType: m5.xlarge
  desiredCapacity: 2
  privateNetworking: true

ノードグループを作成します（5〜10分かかります）：

eksctl create nodegroup -f nodegroup.yaml

ステップ 4: Cilium インストールの確認

ノードの準備ができたら、すべてのコンポーネントを確認します：

# Check nodes
kubectl get nodes

# Check Cilium pods
kubectl get pods -n kube-system -l k8s-app=cilium

# Check all Cilium components
kubectl get pods -n kube-system | grep -E "(cilium|hubble)"

期待される出力：

• 2つのノードが Ready 状態
• Cilium Podが実行中（ノードごとに1つ）
• Hubble relayとtimescapeが実行中
• Cilium operatorが実行中

ステップ 5: 拡張ネットワークオブザーバビリティを備えた Tetragon のインストール

Tetragonはそのままでもランタイムセキュリティとプロセスレベルの可視性を提供します。Splunkとの統合 — 特にNetwork Explorerダッシュボード — には、TCP/UDPソケット統計、RTT、接続イベント、DNSをカーネルレベルで追跡する拡張ネットワークオブザーバビリティモードも有効にする必要があります。

tetragon-network-values.yaml という名前のファイルを作成します：

# Tetragon configuration with Enhanced Network Observability enabled
# Required for Splunk Observability Cloud Network Explorer integration

tetragon:
  # Enable network events — this activates eBPF-based socket tracking
  enableEvents:
    network: true

  # Layer3 settings: track TCP, UDP, and ICMP with RTT and latency
  # These enable the socket stats metrics (srtt, retransmits, bytes, etc.)
  layer3:
    tcp:
      enabled: true
      rtt:
        enabled: true     # Round-trip time per TCP flow
    udp:
      enabled: true
    icmp:
      enabled: true
    latency:
      enabled: true       # Per-connection latency tracking

  # DNS tracking at the kernel level (complements Hubble DNS metrics)
  dns:
    enabled: true

  # Expose Tetragon metrics via Prometheus
  prometheus:
    enabled: true
    serviceMonitor:
      enabled: true

  # Filter out noise from internal system namespaces — we only care about
  # application workloads, not the observability stack itself
  exportDenyList: |-
    {"health_check":true}
    {"namespace":["", "cilium", "tetragon", "kube-system", "otel-splunk"]}

  # Only include labels that are meaningful for the Network Explorer
  metricsLabelFilter: "namespace,workload,binary"

  resources:
    limits:
      cpu: 500m
      memory: 1Gi
    requests:
      cpu: 100m
      memory: 256Mi

# Enable the Tetragon Operator and TracingPolicy support.
# With tracingPolicy.enabled: true, the operator manages and deploys
# TracingPolicies (TCP connection tracking, HTTP visibility, etc.) automatically.
tetragonOperator:
  enabled: true
  tracingPolicy:
    enabled: true

これらの値でTetragonをインストールします：

helm install tetragon isovalent/tetragon --version 1.18.0 \
  --namespace tetragon --create-namespace \
  -f tetragon-network-values.yaml

インストールを確認します：

kubectl get pods -n tetragon

表示される内容： TetragonはDaemonSet（ノードごとに1つのPod）とオペレーターとして実行されます。

ステップ 6: Cilium DNS Proxy HA のインストール

cilium-dns-proxy-ha-values.yaml という名前のファイルを作成します：

enableCriticalPriorityClass: true
metrics:
  serviceMonitor:
    enabled: true

DNS Proxy HAをインストールします：

helm upgrade -i cilium-dnsproxy isovalent/cilium-dnsproxy --version 1.16.7 \
  -n kube-system -f cilium-dns-proxy-ha-values.yaml

確認します：

kubectl rollout status -n kube-system ds/cilium-dnsproxy --watch

Splunk Integration

概要

Splunk OpenTelemetry Collectorは、Prometheusレシーバーを使用してすべてのIsovalentコンポーネントからメトリクスをスクレイプします。各コンポーネントは異なるポートでメトリクスを公開しており、CiliumとHubbleは同じPodを共有しています（ポートが異なるだけです）。そのため、Podアノテーションに依存するのではなく、各コンポーネントに対して個別のレシーバーを設定します。

ステップ 1: 設定ファイルの作成

splunk-otel-collector-values.yaml という名前のファイルを作成します。認証情報のプレースホルダーを実際の値に置き換えてください。

terminationGracePeriodSeconds: 30
agent:
  config:
    extensions:
      # k8s_observer watches the Kubernetes API for pod and port changes.
      # This enables automatic service discovery without static endpoint lists.
      k8s_observer:
        auth_type: serviceAccount
        observe_pods: true

    receivers:
      kubeletstats:
        collection_interval: 30s
        insecure_skip_verify: true

      # Cilium Agent (port 9962) and Hubble (port 9965) both run in the
      # same DaemonSet pod, identified by label k8s-app=cilium.
      # We use two separate scrape jobs because they're on different ports.
      prometheus/isovalent_cilium:
        config:
          scrape_configs:
            - job_name: 'cilium_metrics_9962'
              scrape_interval: 30s
              metrics_path: /metrics
              kubernetes_sd_configs:
                - role: pod
              relabel_configs:
                - source_labels: [__meta_kubernetes_pod_label_k8s_app]
                  action: keep
                  regex: cilium
                - source_labels: [__meta_kubernetes_pod_ip]
                  target_label: __address__
                  replacement: ${__meta_kubernetes_pod_ip}:9962
                - target_label: job
                  replacement: 'cilium_metrics_9962'
            - job_name: 'hubble_metrics_9965'
              scrape_interval: 30s
              metrics_path: /metrics
              kubernetes_sd_configs:
                - role: pod
              relabel_configs:
                - source_labels: [__meta_kubernetes_pod_label_k8s_app]
                  action: keep
                  regex: cilium
                - source_labels: [__meta_kubernetes_pod_ip]
                  target_label: __address__
                  replacement: ${__meta_kubernetes_pod_ip}:9965
                - target_label: job
                  replacement: 'hubble_metrics_9965'

      # Cilium Envoy uses a different pod label (k8s-app=cilium-envoy)
      prometheus/isovalent_envoy:
        config:
          scrape_configs:
            - job_name: 'envoy_metrics_9964'
              scrape_interval: 30s
              metrics_path: /metrics
              kubernetes_sd_configs:
                - role: pod
              relabel_configs:
                - source_labels: [__meta_kubernetes_pod_label_k8s_app]
                  action: keep
                  regex: cilium-envoy
                - source_labels: [__meta_kubernetes_pod_ip]
                  target_label: __address__
                  replacement: ${__meta_kubernetes_pod_ip}:9964
                - target_label: job
                  replacement: 'cilium_metrics_9964'

      # Cilium Operator is a Deployment (not DaemonSet), identified by io.cilium.app=operator
      prometheus/isovalent_operator:
        config:
          scrape_configs:
            - job_name: 'cilium_operator_metrics_9963'
              scrape_interval: 30s
              metrics_path: /metrics
              kubernetes_sd_configs:
                - role: pod
              relabel_configs:
                - source_labels: [__meta_kubernetes_pod_label_io_cilium_app]
                  action: keep
                  regex: operator
                - target_label: job
                  replacement: 'cilium_metrics_9963'

      # Tetragon is identified by app.kubernetes.io/name=tetragon
      prometheus/isovalent_tetragon:
        config:
          scrape_configs:
            - job_name: 'tetragon_metrics_2112'
              scrape_interval: 30s
              metrics_path: /metrics
              kubernetes_sd_configs:
                - role: pod
              relabel_configs:
                - source_labels: [__meta_kubernetes_pod_label_app_kubernetes_io_name]
                  action: keep
                  regex: tetragon
                - source_labels: [__meta_kubernetes_pod_ip]
                  target_label: __address__
                  replacement: ${__meta_kubernetes_pod_ip}:2112
                - target_label: job
                  replacement: 'tetragon_metrics_2112'

    processors:
      # Strict allowlist filter: only forward metrics we've explicitly named.
      # Without this, Cilium and Tetragon can generate thousands of metric series
      # and overwhelm Splunk Observability Cloud with cardinality.
      filter/includemetrics:
        metrics:
          include:
            match_type: strict
            metric_names:
            # --- Kubernetes base metrics ---
            - container.cpu.usage
            - container.memory.rss
            - k8s.container.restarts
            - k8s.pod.phase
            - node_namespace_pod_container
            - tcp.resets
            - tcp.syn_timeouts

            # --- Cilium Agent metrics ---
            # API rate limiting — detect if the agent is being throttled
            - cilium_api_limiter_processed_requests_total
            - cilium_api_limiter_processing_duration_seconds
            # BPF map utilization — alerts when eBPF maps are near capacity
            - cilium_bpf_map_ops_total
            # Controller health — tracks background reconciliation tasks
            - cilium_controllers_group_runs_total
            - cilium_controllers_runs_total
            # Endpoint state — how many pods are in each lifecycle state
            - cilium_endpoint_state
            # Agent error/warning counts — early warning for problems
            - cilium_errors_warnings_total
            # IP address allocation tracking
            - cilium_ip_addresses
            - cilium_ipam_capacity
            # Kubernetes event processing rate
            - cilium_kubernetes_events_total
            # L7 policy enforcement (HTTP, DNS, Kafka)
            - cilium_policy_l7_total
            # DNS proxy latency histogram — key metric for catching DNS saturation
            - cilium_proxy_upstream_reply_seconds_bucket

            # --- Hubble metrics ---
            # DNS query and response counts — primary indicator in the demo scenario
            - hubble_dns_queries_total
            - hubble_dns_responses_total
            # Packet drops by reason (policy_denied, invalid, TTL_exceeded, etc.)
            - hubble_drop_total
            # Total flows processed — overall network activity volume
            - hubble_flows_processed_total
            # HTTP request latency histogram and total count
            - hubble_http_request_duration_seconds_bucket
            - hubble_http_requests_total
            # ICMP traffic tracking
            - hubble_icmp_total
            # Policy verdict counts (forwarded vs. dropped by policy)
            - hubble_policy_verdicts_total
            # TCP flag tracking (SYN, FIN, RST) — connection lifecycle visibility
            - hubble_tcp_flags_total

            # --- Tetragon metrics ---
            # Total eBPF events processed
            - tetragon_events_total
            # DNS cache health
            - tetragon_dns_cache_evictions_total
            - tetragon_dns_cache_misses_total
            - tetragon_dns_total
            # HTTP response tracking with latency
            - tetragon_http_response_total
            - tetragon_http_stats_latency_bucket
            - tetragon_http_stats_latency_count
            - tetragon_http_stats_latency_sum
            # Layer3 errors
            - tetragon_layer3_event_errors_total
            # TCP socket statistics — per-connection RTT, retransmits, byte/segment counts
            # These power the latency and throughput views in Network Explorer
            - tetragon_socket_stats_retransmitsegs_total
            - tetragon_socket_stats_rxsegs_total
            - tetragon_socket_stats_srtt_count
            - tetragon_socket_stats_srtt_sum
            - tetragon_socket_stats_txbytes_total
            - tetragon_socket_stats_txsegs_total
            - tetragon_socket_stats_rxbytes_total
            # UDP statistics
            - tetragon_socket_stats_udp_retrieve_total
            - tetragon_socket_stats_udp_txbytes_total
            - tetragon_socket_stats_udp_txsegs_total
            - tetragon_socket_stats_udp_rxbytes_total
            # Network flow events (connect, close, send, receive)
            - tetragon_network_connect_total
            - tetragon_network_close_total
            - tetragon_network_send_total
            - tetragon_network_receive_total

      resourcedetection:
        detectors: [system]
        system:
          hostname_sources: [os]

    service:
      pipelines:
        metrics:
          receivers:
            - prometheus/isovalent_cilium
            - prometheus/isovalent_envoy
            - prometheus/isovalent_operator
            - prometheus/isovalent_tetragon
            - hostmetrics
            - kubeletstats
            - otlp
          processors:
            - filter/includemetrics
            - resourcedetection

autodetect:
  prometheus: true

clusterName: isovalent-demo

splunkObservability:
  accessToken: <YOUR-SPLUNK-ACCESS-TOKEN>
  realm: <YOUR-SPLUNK-REALM>           # e.g. us1, us2, eu0
  profilingEnabled: true

cloudProvider: aws
distribution: eks
environment: isovalent-demo

# Gateway mode runs a central collector deployment that receives from all agents.
# Agents send to the gateway, which handles batching and export to Splunk.
# This reduces the number of direct connections to Splunk's ingest endpoint.
gateway:
  enabled: true
  resources:
    requests:
      cpu: 250m
      memory: 512Mi
    limits:
      cpu: 1
      memory: 1Gi

# certmanager handles mTLS between the OTel Collector agent and gateway
certmanager:
  enabled: true

重要: 以下を置き換えてください:

• <YOUR-SPLUNK-ACCESS-TOKEN> をSplunk Observability Cloudのアクセストークンに
• <YOUR-SPLUNK-REALM> をレルム（例: us1、us2、eu0）に

ステップ 2: Splunk OpenTelemetry Collector のインストール

コレクターをインストールします:

helm upgrade --install splunk-otel-collector \
  splunk-otel-collector-chart/splunk-otel-collector \
  -n otel-splunk --create-namespace \
  -f splunk-otel-isovalent.yaml

ロールアウトが完了するまで待ちます:

kubectl rollout status daemonset/splunk-otel-collector-agent -n otel-splunk --timeout=60s

ステップ 3: メトリクス収集の確認

コレクターがメトリクスをスクレイプしていることを確認します:

kubectl logs -n otel-splunk -l app=splunk-otel-collector --tail=100 | grep -i "cilium\|hubble\|tetragon"

各コンポーネントのスクレイプが成功していることを示すログエントリが表示されるはずです。

デモ — Isovalent と Splunk を使用した DNS 問題の調査

このデモで示すこと

このデモは、すべての運用チームやプラットフォームチームが経験したことのあるストーリーを語ります。何かが壊れていて、ユーザーが不満を訴えていて、どこから始めればよいかわからない状況です。調査は通常の最初のステップを経由します — APMは問題なさそう、インフラストラクチャも問題なさそう — そしてネットワーク層へとピボットします。そこでIsovalentのHubbleオブザーバビリティがSplunkに流れ込み、本当の問題を明らかにします。それは他のすべてのツールからは完全に見えなかったDNS過負荷です。

アプリケーションは jobs-app で、tenant-jobs namespaceで実行されるシミュレートされたマルチサービスの採用プラットフォームです。フロントエンド（recruiter、jobposting）、中央API（coreapi）、バックグラウンドデータパイプライン（Kafka + resumes + loader）、および定期的にインターネットへHTTP呼び出しを行う crawler サービスがあります。このcrawlerがこのストーリーの悪役になります。

開始前の準備

これは誰もいない状態で行ってください。デモが始まるときには、クリーンで正常なダッシュボードの前に座っていたいものです — 人々が見ている中でkubectlをいじっているのではなく。

Jobs App のデプロイ

まだ行っていない場合は、isovalent-demo-jobs-app リポジトリからjobs-app Helm chartをデプロイします。

helm dependency build .
helm upgrade --install jobs-app . --namespace tenant-jobs --create-namespace

すべてが実行中であることを確認

デモ中に驚かないよう、これらのチェックを実行します。

# Confirm your nodes are healthy
kubectl get nodes

# Confirm Cilium and Hubble are running on both nodes
kubectl get pods -n kube-system | grep -E "(cilium|hubble)"

# Confirm the Splunk OTel Collector is running — this is what ships metrics to Splunk
kubectl get pods -n otel-splunk

# Confirm the jobs-app is fully deployed and healthy
kubectl get pods -n tenant-jobs

アプリを正常なベースラインにリセット

crawlerが穏やかで通常のペースで実行されていることを確認します — 1レプリカ、0.5から5秒ごとにクロール：

helm upgrade jobs-app . --namespace tenant-jobs --reuse-values \
  --set crawler.replicas=1 \
  --set crawler.crawlFrequencyLowerBound=0.5 \
  --set crawler.crawlFrequencyUpperBound=5 \
  --set resumes.replicas=1

その後、少なくとも 5 分待ちます。Splunkがクリーンなベースラインを取り込む時間が必要で、これから作成するスパイクが視覚的に明らかになります。これをスキップすると、チャートが明確なストーリーを伝えません。

問題を注入

デモ開始の約5〜10分前（または効果を出すためにデモ中にライブで）、以下を実行します：

helm upgrade jobs-app . --namespace tenant-jobs --reuse-values \
  --set crawler.replicas=5 \
  --set crawler.crawlFrequencyLowerBound=0.2 \
  --set crawler.crawlFrequencyUpperBound=0.3 \
  --set resumes.replicas=2

これによりcrawlerが1 Podから5にスケールアップし、クロール間隔が0.2〜0.3秒に短縮されます。各crawler Podは api.github.com にHTTPリクエストを行い、それらのリクエストごとに最初にDNSルックアップが必要です。5つのPodが毎秒複数回DNSを叩くと、約15〜25のDNSクエリが持続的に発生します — DNSプロキシを飽和させ、応答レイテンシを蓄積させるのに十分な量です。DNSに依存するnamespace内の他のサービスが断続的な障害を経験し始めます。これがまさにチケットに記載されている内容です。

Act 1 — チケットが届く

まず状況を描写します。まだ何もクリックする必要はありません — シーンを設定するだけです。

「普通の午後で、ITSM チケットが届きました。jobs アプリケーションチームから、エンドユーザーが recruiter と job posting ページで断続的な 500 エラーを報告していて、過去 15 分ほどでロード時間が明らかに悪化したと言っています。P2 にエスカレートされました。調査しましょう。」

「最近のデプロイメントはない — これが実は興味深い点です。責めるべき明らかな変更イベントがありません。だから自分たちで何が変わったかを把握する必要があります。どこから始めましょう？APM です。」

Act 2 — APM を確認（行き止まり）

ここはほとんどの人が最初に行くところで、それがポイントです。APMを表示し、役に立たないことを見つけ、それを使ってより深いものが必要であるケースを構築します。

移動先： Splunk Observability Cloud → APM → Service Map

tenant-jobs 環境のサービスマップはトポロジーを示します：recruiter と jobposting は両方とも coreapi を呼び出し、coreapiはElasticsearchに接続します。resumes と loader サービスはバックグラウンドでKafkaを介して通信します。

「これがサービスマップです。すべてのサービスが点灯しています — すべて応答していて、すべて接続されています。数字が実際に何を示しているか見てみましょう。

リクエストレートは正常に見えます。レイテンシはわずかに上昇しているかもしれませんが、ユーザー向けのエラーを説明するほどのものではありません。coreapi のエラーレートを見てください — 約 10% です。これが問題だと思うかもしれませんが、そうではありません。このアプリはセットアップの一部として設定可能なエラーレートが組み込まれています。10 パーセントはベースラインであり、リグレッションではありません。

つまり APM が教えてくれるのは：サービスは生きていて、トラフィックは流れていて、エラーレートは変化していないということです。アプリケーショントレースには根本原因を示すものがありません。インフラストラクチャを試してみましょう。」

Act 3 — インフラストラクチャを確認（行き止まり）

インフラを表示し、クリーンであることを見つけ、聴衆にまだ答えがないフラストレーションを感じさせます。

移動先： Splunk Observability Cloud → Infrastructure → Kubernetes → Cluster: isovalent-demo

「クラスター自体を見てみましょう。何かリソースが制約されているかもしれません — ノードが高負荷、Pod が OOMKilled されている、そのようなことです。

両方のノードは正常に見えます。CPU とメモリは正常範囲内です。Pod を掘り下げると — すべて Running 状態で、再起動なし、退去もされていません。コンテナ自体もリソース制限に達していません。

これで少し不快な状況になりました。チケットにはユーザーがエラーを見ていると書いてあります。APM はアプリが実行中だと言っています。インフラストラクチャはクラスターが正常だと言っています。これでどうなりますか？

これは実際に非常によくある状況です。アプリケーション層より下、インフラストラクチャ層より下に存在する問題のクラス全体があります — 従来のモニタリングツールでは単純に見えないネットワークレベルで起こっていること。DNS 障害、接続の切断、ポリシー拒否、トラフィックの非対称性。これらはトレースや Pod メトリクスには現れません。ネットワーク自体を観察できるものが必要です。そこで Isovalent の出番です。」

Act 4 — ネットワークが真実を語る

これがデモの核心です。ここはゆっくり時間をかけてください。

移動先： Splunk Observability Cloud → Dashboards → Hubble by Isovalent

「Cilium — 私たちの CNI、すべてのノードで実行されているネットワーキング層 — には Hubble という組み込みのオブザーバビリティコンポーネントがあります。Hubble は eBPF を使用してクラスター内のすべてのネットワークフローをリアルタイムで監視します。サンプリングではなく、近似でもなく — すべての接続、すべての DNS リクエスト、すべてのパケットドロップ。そして OpenTelemetry Collector がそれらの Hubble メトリクスをスクレイプして Splunk に転送するように設定しているので、APM やインフラストラクチャを見ていたのと同じプラットフォームでそれらすべてを見ることができます。

Hubble ダッシュボードを表示しましょう。」

DNS クエリが制御不能

DNS Queries チャートを指し、次に DNS Overview タブに移動します。

「ありました。DNS クエリ量を見てください — 約 15 分前に急激にスパイクしています。このタイムスタンプはチケットが開かれた時間とぴったり一致します。

見ているのは hubble_dns_queries_total で、ソース namespace ごとに分類されています。スパイクは完全に tenant-jobs — アプリケーション namespace から来ています。アプリケーション内の何かが大量の DNS トラフィックを生成し始め、DNS プロキシが追いつくのに苦労し始めました。

しかし右下を見てください — Missing DNS Responses チャートです。これはアラートが発火しているものです。値が深くマイナスになっています。これは DNS クエリが送信されているのに、応答が一度も戻ってこないことを意味します。DNS プロキシが圧倒され、接続は静かにタイムアウトしています。これがユーザーの 500 エラーとして現れている波及効果です。」

トップ DNS クエリが原因を明らかに

Top 10 DNS Queries チャートを指します。

「これらすべての DNS リクエストを行っているものを特定しましょう。Top 10 DNS Queries チャートは最も頻繁にクエリされるドメインを分類しており、1 つの名前が圧倒的に目立っています：api.github.com。

これはクラスター内部のサービスではありません — 外部エンドポイントです。そしてアプリ内で外部エンドポイントと通信するのは crawler サービスだけです。crawler はジョブシミュレーションの一部として外部 URL への HTTP 呼び出しを行います。その HTTP 呼び出しを行うたびに、最初に DNS を通じて api.github.com を解決する必要があります。

通常これは問題ありません。1 つの crawler Pod が数秒ごとにリクエストを行うのは完全に管理可能です。しかし、どれだけ積極的に実行されているかについて何かが明らかに変化しています。」

ドロップされたフローが影響範囲を示す

Dropped Flows チャートを指します。

「Dropped Flows チャートは別の注目すべきことを示しています。Hubble は成功した接続だけを追跡するのではありません — 拒否またはドロップされたすべての接続と、その理由コードをキャプチャします。DNS スパイクと全く同じ時間にドロップの増加が見られます。

これらのドロップは DNS 過負荷の下流の結果です。namespace 内のサービスが接続を試み、DNS が遅すぎるか失敗すると、それらの接続試行はタイムアウトしてドロップされます。これが APM がレイテンシの上昇として見ていたものです — しかし APM にはその下に DNS 問題があることは全くわかりませんでした。」

ネットワークフロー量がパターンを確認

Metrics & Monitoring タブに移動します。

「そして Metrics & Monitoring タブを見ると、全体像がさらに明確になります。ノードごとの処理フロー数が垂直に上昇しています — これは生のネットワークトラフィック量です。Forwarded vs Dropped チャートは、それらのフローのかなりの割合が転送されずにドロップされていることを示しています。そして Drop Reason の内訳は、TTL_EXCEEDED と DROP_REASON_UNKNOWN の混合であることを教えてくれます — DNS タイムアウトがカスケードし始めたときにまさに予想されるものです。特定の時点で何かが変わり、その時点以降のすべてがベースラインとは異なって見えます。」

L7 HTTP トラフィックが興味深いストーリーを語る

L7 HTTP Metrics タブに移動します。

「L7 HTTP Metrics タブで指摘する価値のあることがあります。これは実際に APM が役に立たなかった理由を補強するからです。受信リクエスト量はゼロではありません — トラフィックはまだ流れています。成功率チャートはほとんど緑に見えます。HTTP レベルの可視性だけを見ていた場合、アプリは問題ないと結論づけるかもしれません。

しかし Incoming Requests by Source チャートを見てください。crawler が不釣り合いなシェアのトラフィックを生成しています — 他のサービスから分離しているのが見えます。HTTP 呼び出しを成功させているので、APM はフラグを立てません。問題は 1 つ下の層、DNS で、HTTP 接続が確立される前に起こっています。」

Act 5 — 根本原因の確認

ここで点と点をつなぎ、証明します。

「これが全体像です：ある時点で、crawler サービスが 1 レプリカから 5 にスケールアップされ、クロール間隔が非常に積極的に設定されました — 0.2 から 0.3 秒ごと。これは 5 つの Pod が、それぞれ api.github.com を解決するために DNS ルックアップを毎秒複数回発火させています。合計すると、毎秒 15 から 25 の DNS クエリが持続的に発生します。DNS プロキシは単一のワークロードからそのような負荷を処理するようには作られていないので、キューイング、スローダウン、そして最終的にはリクエストのドロップを開始します。DNS 解決を必要とする namespace 内の他のすべてのサービスが巻き添えを食います。

それが何を見ているか確認しましょう。」

# Confirm the current crawler replica count — you'll see 5
kubectl get deploy crawler -n tenant-jobs

# Pull the environment config to see the crawl frequency settings
kubectl get deploy crawler -n tenant-jobs \
  -o jsonpath='{.spec.template.spec.containers[0].env}' | jq .

オプションとして、Cilium by Isovalent dashboard → Policy: L7 Proxy タブに切り替えます。

「Hubble 側ではなく Cilium 側からこれを見たい場合は、Cilium by Isovalent dashboard に切り替えて Policy: L7 Proxy タブを見てください。FQDN の L7 Request Processing Rate — これが DNS です — が 21,000 リクエストを超えています。これは分あたりではありません。DNS プロキシは非常に大量の FQDN ルックアップを処理しており、すべて受信されて転送されているため、バックアップし始めました。このビューは DNS Proxy Upstream Reply レイテンシも表示しており、プロキシが圧力下にあることを確認できます。」

「ありました。5 レプリカ、0.2 から 0.3 秒ごとにクロール。

APM ではこれが見えません。コードを計装しているのであって、DNS ではないからです。インフラストラクチャモニタリングでもこれは見えません。Pod は正常です — 設定されたとおりに正確に動作しています。これをキャッチできる唯一のツールは、eBPF レベルで動作し、すべてのパケット、すべての DNS リクエスト、すべての接続試行をリアルタイムで監視するものです。それが Hubble です。そして Splunk に接続しているので、他のすべてに使用しているのと同じダッシュボードでキャッチしました。」

Act 6 — ライブで修正

この部分は満足感があります。チャートがリアルタイムで回復するのを見ることができるからです。

「修正は簡単です — crawler をスケールダウンして、通常のクロール間隔を復元します。」

helm upgrade jobs-app . --namespace tenant-jobs --reuse-values \
  --set crawler.replicas=1 \
  --set crawler.crawlFrequencyLowerBound=0.5 \
  --set crawler.crawlFrequencyUpperBound=5 \
  --set resumes.replicas=1

Hubble by Isovalent ダッシュボードに戻り、1分ほど待ちます。

「DNS Queries チャートを見てください — ほぼ即座に下がってくるのが見えます。1〜2 分以内にベースラインに戻ります。ドロップされたフローはゼロになります。ネットワークフロー量は通常に戻ります。

そして今 APM に戻ると、レイテンシが正常化し、エラーレートが予想される 10% のベースラインに落ち着くのが見えるでしょう。

チケットをクローズできます。根本原因：crawler の設定ミスによる DNS 飽和。解決策：Helm を使用して crawler のレプリカ数とクロール間隔を元に戻す。解決までの時間：チケットが開かれてから約 15 分。」

Act 7 — これが実際に意味すること

ズームアウトして、価値のステートメントを具体的に感じさせて終わります。

「ここで何が起こったか考えてみましょう。本番スタイルの本当の問題がありました — エンドユーザーにとって何かが壊れていて — 標準的なプレイブックを経由しました。APM は何も問題ないと言いました。インフラストラクチャも何も問題ないと言いました。Hubble がなければ、次のステップはおそらく戦争部屋の通話、ログを見つめる人々、namespace 全体の再起動を期待して行うことだったでしょう。

代わりに、Hubble ダッシュボードを開いた瞬間から 3 分以内に見つけました。私たちが賢いからではなく、正しい層への可視性があったからです。

これが機能する理由は eBPF です。Cilium の Hubble コンポーネントは Linux カーネルにフックし、ソースでネットワークイベントを観察します — アプリケーションコードに到達する前に、Pod ログに現れる前に、APM のトレースになる前に。そして OpenTelemetry Collector を通じてそれらのメトリクスを Splunk に送信することで、APM データやインフラストラクチャデータと同じプラットフォームに並んでいます。ツールを切り替えたり、5 つの異なるダッシュボード間でコンテキストスイッチする必要はありません。以前なかった可視性の層を追加し、チームがすでに知っているワークフローに保持します。

これがストーリーです。ネットワークオブザーバビリティはニッチなニーズではありません — APM とインフラストラクチャモニタリングが残すギャップです。Isovalent がそのギャップを埋め、Splunk でそれを見ることができます。」

クイックリファレンス

問題を注入（デモの約10分前に実行）：

helm upgrade jobs-app . -n tenant-jobs --reuse-values \
  --set crawler.replicas=5 \
  --set crawler.crawlFrequencyLowerBound=0.2 \
  --set crawler.crawlFrequencyUpperBound=0.3 \
  --set resumes.replicas=2

修復（Act 6でライブ実行）：

helm upgrade jobs-app . -n tenant-jobs --reuse-values \
  --set crawler.replicas=1 \
  --set crawler.crawlFrequencyLowerBound=0.5 \
  --set crawler.crawlFrequencyUpperBound=5 \
  --set resumes.replicas=1

設定ミスを確認：

kubectl get deploy crawler -n tenant-jobs
kubectl get deploy crawler -n tenant-jobs \
  -o jsonpath='{.spec.template.spec.containers[0].env}' | jq .

Splunk ナビゲーションパス： APM → Service Map → （クリーンであることを表示） → Infrastructure → Kubernetes → （クリーンであることを表示） → Dashboards → Hubble by Isovalent → （DNS スパイクを表示）

タイミングガイド