OpenTelemetryを使用したLinkerdディストリビューティッド（分散）トレーシング

Linkerd 2.19以降では、追加のトレーシングバックエンドやcert-managerのセットアップを必要とせずに、メッシュサイドカーから直接、プロキシされたすべてのリクエストのスパンをエクスポートできます。インストゥルメントされたアプリケーションポッドと組み合わせることで、これらのプロキシスパンはエンドツーエンドのトレースに接続され、リクエストがメッシュ内をどのように移動したかを正確に示します。

使い方

トレーシングの有効化には2つの部分があります：

メッシュレベルのトレースエクスポート：Linkerdプロキシは、リクエストごとにスパンをOTel Collectorにエクスポートします。これだけで、アプリケーションに触れることなく、プロキシレベルのトレース（再試行、mTLSハンドシェイク、ホップごとのレイテンシ）を取得できます。
アプリケーションの計装：アプリのポッドは、プロキシが使用するのと同じW3Cトレースコンテキストを伝播し、独自のスパンをエクスポートします。両方を組み合わせることで、クライアントアプリからLinkerdプロキシを経由してバックエンドアプリに至るまで、同じトレース内に完全なウォーターフォールが表示されます。

あなたが始める前に

以下のものを用意してください:

Linkerd edge-26.7.0以降（2.19以降）。以前のリリースでのプロキシトレーシングには、個別のコレクターサービスとcert-managerのインテグレーションが必要でしたが、このガイドでは説明していません。アップグレードが必要な場合は、Linkerdのスタートガイドを参照してください。
LinkerdインスタンスでNRDOTまたはOTel Collector Contribが稼働していること：
- NRDOTの場合は、Helmチャートまたはマニフェストのいずれかを使用します。
- OTel Collector Contribの場合は、Helmチャートまたはマニフェストのいずれかを使用します。
トレースするネームスペースでインジェクションが有効になっていること。

ディストリビューティッド（分散）トレーシングの設定

tracesdeployment.configMap.extraConfigのにvalues.yaml パイプラインを追加します。otlpレシーバーを再定義しないでください。チャートにはデフォルトですでに1つ含まれています：

追加するプロセッサ:

k8sattributes/traces:
  auth_type: serviceAccount
  passthrough: false
  extract:
    metadata: [ k8s.deployment.name, k8s.node.name, k8s.namespace.name, k8s.pod.name ]
    labels:
      - { tag_name: linkerd_control_plane_ns, key: linkerd.io/control-plane-ns, from: pod }
      - { tag_name: linkerd_control_plane_component, key: linkerd.io/control-plane-component, from: pod }
  pod_association:
    - sources: [{ from: resource_attribute, name: k8s.pod.ip }]
    - sources: [{ from: connection }]

# Must run before transform/linkerd_service_name below.
transform/linkerd_component_inject:
  trace_statements:
    - context: span
      statements:
        - set(attributes["linkerd_control_plane_component"], "linkerd-proxy")
          where resource.attributes["service.name"] == "linkerd-proxy"
          and resource.attributes["linkerd_control_plane_ns"] != nil

# Renames service.name=linkerd-proxy to the correlated deployment name.
transform/linkerd_service_name:
  trace_statements:
    - context: resource
      statements:
        - set(attributes["service.name"], attributes["k8s.deployment.name"])
          where attributes["service.name"] == "linkerd-proxy"
          and attributes["k8s.deployment.name"] != nil

resourcedetection:
  detectors: [env]
  override: false

追加するパイプライン：

pipelines:
  traces:
    receivers: [otlp]
    processors: [memory_limiter, k8sattributes/traces, transform/linkerd_component_inject, transform/linkerd_service_name, resourcedetection, batch]
    exporters: [otlp_http/newrelic]

重要

transform/linkerd_service_name 各メッシュ化されたデプロイメントの名前をそのAPM service.nameにします。同じアカウントにレポートするすべてのクラスタで、一意のデプロイメント名を使用してください。別のクラスタにも存在する名前は、そこにある同じエンティティに解決されるため、データは2つの別々のサービスとして表示されるのではなく、マージされます。

更新されたvalues.yamlを使用して、「OpenTelemetryを使用したKubernetes上のLinkerdのモニター」からhelm upgradeコマンドを再実行し、次の1回限りの手順を完了します：

1. コレクターをメッシュ化します。Linkerdプロキシは、それ自体がメッシュ内にあるコレクターにのみトレースをエクスポートできます：

bash

$kubectl annotate namespace newrelic linkerd.io/inject=enabled
$kubectl rollout restart deployment/nr-k8s-otel-collector-deployment -n newrelic
$kubectl rollout restart daemonset/nr-k8s-otel-collector-daemonset -n newrelic

2. コレクターのOTLPポートをgRPCとしてマークします。チャートのnr-k8s-otel-collector-gatewayサービスは、そのgRPCポートでappProtocolを宣言していません。これがないと、Linkerd独自のプロトコル検出がコレクターへのトラフィックを誤認し、プロキシのトレースエクスポートを暗黙のうちにドロップする可能性があります：

bash

$kubectl patch svc nr-k8s-otel-collector-gateway -n newrelic --type=json \
>  -p='[{"op":"add","path":"/spec/ports/1/appProtocol","value":"grpc"}]'

3. Linkerdプロキシでトレースを有効にします：

# linkerd-values.yaml
proxy:
  tracing:
    enabled: true
    collector:
      endpoint: nr-k8s-otel-collector-gateway.newrelic.svc.cluster.local:4317
      meshIdentity:
        serviceAccountName: nr-k8s-otel-collector
        namespace: newrelic

bash

$linkerd upgrade -f linkerd-values.yaml | kubectl apply -f -

bash

$linkerd upgrade \
>  --set proxy.tracing.enabled=true \
>  --set proxy.tracing.collector.endpoint=nr-k8s-otel-collector-gateway.newrelic.svc.cluster.local:4317 \
>  --set proxy.tracing.collector.meshIdentity.serviceAccountName=nr-k8s-otel-collector \
>  --set proxy.tracing.collector.meshIdentity.namespace=newrelic \
>  | kubectl apply -f -

bash

$kubectl rollout restart deployment -n <YOUR_NAMESPACE>

次に、以下の「アプリケーションポッドの計装」に進みます。

同じdeployment-configmap.yamlに以下を追加します。otlpレシーバーを再定義しないでください。ベースマニフェストにはデフォルトですでに1つ含まれています：

追加するプロセッサ:

processors:
  k8sattributes/traces:
    auth_type: serviceAccount
    passthrough: false
    extract:
      metadata: [ k8s.deployment.name, k8s.node.name, k8s.namespace.name, k8s.pod.name ]
      labels:
        - { tag_name: linkerd_control_plane_ns, key: linkerd.io/control-plane-ns, from: pod }
        - { tag_name: linkerd_control_plane_component, key: linkerd.io/control-plane-component, from: pod }
    pod_association:
      - sources: [{ from: resource_attribute, name: k8s.pod.ip }]
      - sources: [{ from: connection }]

  # Must run before transform/linkerd_service_name below.
  transform/linkerd_component_inject:
    trace_statements:
      - context: span
        statements:
          - set(attributes["linkerd_control_plane_component"], "linkerd-proxy")
            where resource.attributes["service.name"] == "linkerd-proxy"
            and resource.attributes["linkerd_control_plane_ns"] != nil

  # Renames service.name=linkerd-proxy to the correlated deployment name.
  transform/linkerd_service_name:
    trace_statements:
      - context: resource
        statements:
          - set(attributes["service.name"], attributes["k8s.deployment.name"])
            where attributes["service.name"] == "linkerd-proxy"
            and attributes["k8s.deployment.name"] != nil

  resourcedetection:
    detectors: [env]
    override: false

追加するパイプライン：

pipelines:
  traces:
    receivers: [otlp]
    processors: [memory_limiter, k8sattributes/traces, transform/linkerd_component_inject, transform/linkerd_service_name, resourcedetection, batch]
    exporters: [otlp_http/newrelic]

重要

上記のConfigMapを再適用し、次の1回限りの手順を完了します：

1. コレクターをメッシュ化します。Linkerdプロキシは、それ自体がメッシュ内にあるコレクターにのみトレースをエクスポートできます：

bash

$kubectl annotate namespace newrelic linkerd.io/inject=enabled
$kubectl rollout restart deployment/nr-k8s-otel-collector-deployment -n newrelic
$kubectl rollout restart daemonset/nr-k8s-otel-collector-daemonset -n newrelic

2. コレクターのOTLPポートをgRPCとしてマークします。レンダリングされたnr-k8s-otel-collector-gateway Serviceは、そのgRPCポートでappProtocolを宣言していません。これがないと、Linkerd独自のプロトコル検出がコレクターへのトラフィックを誤認し、プロキシのトレースエクスポートを暗黙のうちにドロップする可能性があります：

bash

$kubectl patch svc nr-k8s-otel-collector-gateway -n newrelic --type=json \
>  -p='[{"op":"add","path":"/spec/ports/1/appProtocol","value":"grpc"}]'

3. Linkerdプロキシでトレースを有効にします：

# linkerd-values.yaml
proxy:
  tracing:
    enabled: true
    collector:
      endpoint: nr-k8s-otel-collector-gateway.newrelic.svc.cluster.local:4317
      meshIdentity:
        serviceAccountName: nr-k8s-otel-collector
        namespace: newrelic

bash

$linkerd upgrade -f linkerd-values.yaml | kubectl apply -f -

bash

$linkerd upgrade \
>  --set proxy.tracing.enabled=true \
>  --set proxy.tracing.collector.endpoint=nr-k8s-otel-collector-gateway.newrelic.svc.cluster.local:4317 \
>  --set proxy.tracing.collector.meshIdentity.serviceAccountName=nr-k8s-otel-collector \
>  --set proxy.tracing.collector.meshIdentity.namespace=newrelic \
>  | kubectl apply -f -

bash

$kubectl rollout restart deployment -n <YOUR_NAMESPACE>

次に、以下の「アプリケーションポッドの計装」に進みます。

Linkerd 2.19以降、プロキシトレースのエクスポートはコントロールプレーンで直接構成され、cert-managerや個別のポートは必要ありません。2つの手順が必要です：コレクターがトレースを受信できるようにしてから、プロキシからのトレースのエクスポートをオンにします。

手順1：コレクターにトレースの取り込みを追加する

NRDOTチャートとは異なり、コミュニティのopen-telemetry/opentelemetry-collectorチャートにはデフォルトでotlpレシーバーが含まれていません。NRDOTタブで使用されているのと同じプロセッサとともに、これを明示的に追加します。

Helmを使用したOTel Collector Contribのvalues.yamlの同じconfigセクションに以下を追加します：

追加予定のレシーバー：

otlp:
  protocols:
    grpc:
      endpoint: 0.0.0.0:4317
    http:
      endpoint: 0.0.0.0:4318

追加するプロセッサ:

k8sattributes/traces:
  auth_type: serviceAccount
  passthrough: false
  extract:
    metadata: [ k8s.deployment.name, k8s.node.name, k8s.namespace.name, k8s.pod.name ]
    labels:
      - { tag_name: linkerd_control_plane_ns, key: linkerd.io/control-plane-ns, from: pod }
      - { tag_name: linkerd_control_plane_component, key: linkerd.io/control-plane-component, from: pod }
  pod_association:
    - sources: [{ from: resource_attribute, name: k8s.pod.ip }]
    - sources: [{ from: connection }]

# Must run before transform/linkerd_service_name below.
transform/linkerd_component_inject:
  trace_statements:
    - context: span
      statements:
        - set(attributes["linkerd_control_plane_component"], "linkerd-proxy")
          where resource.attributes["service.name"] == "linkerd-proxy"
          and resource.attributes["linkerd_control_plane_ns"] != nil

# Renames service.name=linkerd-proxy to the correlated deployment name.
transform/linkerd_service_name:
  trace_statements:
    - context: resource
      statements:
        - set(attributes["service.name"], attributes["k8s.deployment.name"])
          where attributes["service.name"] == "linkerd-proxy"
          and attributes["k8s.deployment.name"] != nil

resourcedetection:
  detectors: [env]
  override: false

追加するパイプライン：

traces:
  receivers: [otlp]
  processors: [memory_limiter, k8sattributes/traces, transform/linkerd_component_inject, transform/linkerd_service_name, resourcedetection, batch]
  exporters: [otlp_http/newrelic]

再適用：

bash

$helm upgrade my-opentelemetry-collector open-telemetry/opentelemetry-collector -f values.yaml -n newrelic --create-namespace --install

マニフェストを使用したOTel Collector Contribのotel-collector.yamlにあるConfigMapのconfigキーに、上記の同じ3つのブロック（Receivers、Processors、Pipelines）を追加します。そのマニフェストのServiceはすでにポート4317（grpc）と4318（http）を公開しているため、ポートの変更は必要ありません。再適用して再起動します。ConfigMapを再適用するだけでは実行中のコレクターポッドは再起動されないため、2番目のコマンドを実行しないと新しい構成は取得されません：

bash

$kubectl apply -f otel-collector.yaml
$kubectl rollout restart deployment/my-opentelemetry-collector -n newrelic

手順2：プロキシトレースのエクスポートを有効にする

1. コレクターをメッシュ化します。Linkerdプロキシは、それ自体がメッシュ内にあるコレクターにのみトレースをエクスポートできます。NRDOTチャートのnr-k8s-otel-collector-gatewayとは異なり、OTel Collector ContribマニフェストまたはHelmチャートには、デフォルトでコレクターポッドをメッシュに挿入するものは何もありません：

bash

$kubectl annotate namespace newrelic linkerd.io/inject=enabled
$kubectl rollout restart deployment/my-opentelemetry-collector -n newrelic

重要

以下のmeshIdentityスタンザは必須です。Linkerdはメッシュ内にあるコレクターにのみトレースをエクスポートできます。これは、上記のコマンドが実行したことです。

2. Linkerdプロキシでトレースを有効にします：

# values.yaml
proxy:
  tracing:
    enabled: true
    collector:
      endpoint: my-opentelemetry-collector.newrelic.svc.cluster.local:4317
      meshIdentity:
        serviceAccountName: my-opentelemetry-collector
        namespace: newrelic

bash

$helm upgrade linkerd-control-plane linkerd/linkerd-control-plane \
>  --namespace linkerd --reuse-values -f values.yaml

bash

$linkerd upgrade \
>  --set proxy.tracing.enabled=true \
>  --set proxy.tracing.collector.endpoint=my-opentelemetry-collector.newrelic.svc.cluster.local:4317 \
>  --set proxy.tracing.collector.meshIdentity.serviceAccountName=my-opentelemetry-collector \
>  --set proxy.tracing.collector.meshIdentity.namespace=newrelic \
>  | kubectl apply -f -

手順3：アプリケーションのメッシュ化されたポッドを再起動する

これは手順2のコレクターの再起動とは異なります — 実際にトレースしているポッドに新しいプロキシトレース構成を適用します：

bash

$kubectl rollout restart deployment -n <YOUR_NAMESPACE>

アプリケーションポッドの計装

トレースコンテキストヘッダーを伝播するために、OTel Javaエージェント（または使用する言語のエージェント）を追加します。Linkerdは、W3CトレースコンテキストとB3フォーマットの両方をサポートしています。OTelエージェントはこれを自動的に処理します。

ヒント

spec.exporter.endpoint 以下は、マニフェストを使用したOTel Collector ContribページのServiceを指しています。NRDOTコレクターをデプロイした場合は、代わりにhttp://nr-k8s-otel-collector-gateway.newrelic.svc.cluster.local:4317を使用します。

bash

$kubectl apply -f https://github.com/open-telemetry/opentelemetry-operator/releases/latest/download/opentelemetry-operator.yaml
$
$kubectl apply -f - <<'EOF'
$apiVersion: opentelemetry.io/v1alpha1
$kind: Instrumentation
$metadata:
$  name: nr-instrumentation
$  namespace: <YOUR_NAMESPACE>
$spec:
$  exporter:
$    endpoint: http://my-opentelemetry-collector.newrelic.svc.cluster.local:4317
$  propagators: [tracecontext, baggage]
$  java:
$    image: ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-java:latest
$EOF
$
$kubectl annotate deployment <YOUR_DEPLOYMENT> \
>  instrumentation.opentelemetry.io/inject-java="true" \
>  -n <YOUR_NAMESPACE>

その他の言語（Python、.NET、Node.js、Go）および、サイドカーとinit-コンテナのインジェクション、リソース制限、マルチコンテナポッドなどの高度なOperator設定については、OpenTelemetry Operatorの自動計装に関するドキュメントをご覧ください。

アプリのメトリクスをAPMと関連付ける（オプション）

アプリが（トレースだけでなく）OTel SDKメトリクスもコレクターにエクスポートする場合は、以下を追加してAPM互換のメトリクスパイプラインにルーティングしてください。

追加するプロセッサ:

metricstransform/apm_compat:
  transforms:
    - include: http.server.request.duration
      action: insert
      new_name: apm.service.transaction.duration

追加するパイプライン：

metrics/otlp:
  receivers: [otlp]
  processors: [memory_limiter, resourcedetection, transform/metadata_nullify, metricstransform/apm_compat, batch]
  exporters: [otlp_http/newrelic]

デプロイしたコレクター設定に両方を追加し、再適用してください：

デプロイした場合	追加先	再適用方法
NRDOT - Helm	の`deployment.configMap.extraConfig` `values.yaml`	`helm upgrade nr-k8s-otel-collector newrelic/nr-k8s-otel-collector --namespace newrelic --reuse-values -f values.yaml`
NRDOT - マニフェスト	`deployment-configmap.yaml`	`kubectl apply -f rendered/deployment-configmap.yaml -n newrelic && kubectl rollout restart deployment -n newrelic`
OTel Collector Contrib - Helm	の`config`セクション `values.yaml`	`helm upgrade my-opentelemetry-collector open-telemetry/opentelemetry-collector -f values.yaml -n newrelic --create-namespace --install`
OTel Collector Contrib - マニフェスト	のConfigMapの`config`キー `otel-collector.yaml`	`kubectl apply -f otel-collector.yaml && kubectl rollout restart deployment/my-opentelemetry-collector -n newrelic`

Linkerdプロキシログを収集する

オプションで

linkerd-proxy

サイドカーコンテナのログを収集します。

メトリクスリファレンス

OTel Collectorによって収集されるLinkerdメトリクスとリソース属性の完全なリスト。

データを検索してクエリを実行する

ダッシュボードのウォークスルー、NRQLクエリ、およびトラブルシューティングの手順。

この機械翻訳は、参考として提供されています。

OpenTelemetryを使用したLinkerdディストリビューティッド（分散）トレーシング

使い方

あなたが始める前に

ディストリビューティッド（分散）トレーシングの設定

Helm インストール

重要

Helm経由

代替方法：Linkerd CLI

マニフェストのインストール

重要

Helm経由

代替方法：Linkerd CLI

手順1：コレクターにトレースの取り込みを追加する

兜

マニフェスト

手順2：プロキシトレースのエクスポートを有効にする

重要

Helm経由

代替方法：Linkerd CLI

手順3：アプリケーションのメッシュ化されたポッドを再起動する

アプリケーションポッドの計装

ヒント

OTel Operator（推奨）

アプリのメトリクスをAPMと関連付ける（オプション）

Linkerdプロキシログを収集する

メトリクスリファレンス

データを検索してクエリを実行する

この機械翻訳は、参考として提供されています。

OpenTelemetryを使用したLinkerdディストリビューティッド（分散）トレーシング

使い方 .css-21sua1{background:none;border:none;width:0;padding:0;}

あなたが始める前に

ディストリビューティッド（分散）トレーシングの設定

マニフェストのインストール

手順1：コレクターにトレースの取り込みを追加する

兜

マニフェスト

手順2：プロキシトレースのエクスポートを有効にする

重要

Helm経由

代替方法：Linkerd CLI

手順3：アプリケーションのメッシュ化されたポッドを再起動する

アプリケーションポッドの計装

ヒント

OTel Operator（推奨）

アプリのメトリクスをAPMと関連付ける（オプション）

関連記事

Linkerdプロキシログを収集する

メトリクスリファレンス

データを検索してクエリを実行する

使い方