アプリケーションのビルドとデプロイ

Splunk APMで確認する

10 minutes

このステップでは、Splunk Observability Cloudで切断されたトレースがどのように表示されるかを確認します。これはワークショップの残りの部分で修正する「問題のある状態」です。

APMリクエストパス

Place order をクリックすると、リクエストは以下の経路を通ります。

text
Browser (RUM span)
  → Frontend NGINX
    → Edge Gateway NGINX     ← break #1: trace headers dropped
      → Order API
        → Catalog API        ← direct HTTP 
        → Payment Gateway    ← break #2: strips headers to payment-api
          → Payment API
            → RabbitMQ       ← break #3: no trace context in message
              → Fulfillment Worker  ← orphan root trace

3つの断絶が発生します。

  1. HTTP break #1 edge NGINXゲートウェイ(browser → order API)
  2. HTTP break #2 payment-gatewayプロキシ(order API → payment API)
  3. Messaging break RabbitMQ(payment API → fulfillment worker)

Splunk APMで確認する

注意

データ生成後、メトリクスが表示されるまで 2〜5分 かかります。

Service Map

  1. APM → Service Map に移動します
  2. 環境をフィルタリングします: workshop-context-prop
  3. 以下のサービスが表示されます: order-api, payment-gateway, payment-api, fulfillment-worker, catalog-api

servicemap

  1. APM → Trace Analyzer に移動します
  2. フィルタを設定します:
    • Environment: workshop-context-prop
    • Service: order-api
    • Operation: POST /api/orders(または storefront.place_order
  3. 最新のトレースを開きます

表示される内容(断絶状態)

trace-b4

理解度チェック

NGINXがプロパゲーションを断絶する理由

回答を表示するにはここをクリック

ゲートウェイは本番環境でよく使われるNGINXパターンを使用しています。

nginx
location /api/ {
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_pass http://storefront_api;
}
text
When **any** `proxy_set_header` directive is present, NGINX stops automatically forwarding 
client headers to the upstream. Headers like `traceparent`, `tracestate`, and `baggage` 
are silently dropped unless explicitly configured.

This is one of the most common causes of broken trace correlation in production.

RabbitMQがプロパゲーションを断絶する理由

回答を表示するにはここをクリック

ストアフロントは以下のように注文を発行します(断絶状態)。

javascript
channel.sendToQueue(ordersQueue, Buffer.from(JSON.stringify(order)), {
  persistent: true,
  headers: { 'x-order-id': order.orderId },  // no traceparent
});
text
Unlike HTTP, message brokers don't participate in W3C Trace Context automatically. The
producer must **inject** trace context into message headers, and the consumer must
**extract** it. Without this, the consumer starts a new root trace.
Last Modified ·