OpenTelemetry를 사용한 Linkerd 분산 추적

Linkerd 2.19 이상은 추가적인 트레이싱 백앤드 또는 cert-manager 설정 없이 메시 사이드카에서 직접 프록시된 모든 요청에 대한 스팬을 내보낼 수 있습니다. 계측된 애플리케이션 파드와 결합하여, 이러한 프록시 스팬은 요청이 메시를 통해 어떻게 이동했는지 정확히 보여주는 엔드투엔드 트레이스로 연결됩니다.

작동 원리

트레이스 활성화는 두 부분으로 나뉩니다:

메시 수준 트레이스 내보내기: Linkerd 프록시는 요청당 하나의 스팬을 OTel Collector로 내보냅니다. 이것만으로도 애플리케이션을 수정하지 않고 프록시 수준의 트레이스(재시도, mTLS 핸드셰이크, 홉당 지연시간)를 얻을 수 있습니다.
애플리케이션 계측: 앱 파드는 프록시가 사용하는 것과 동일한 W3C Trace Context를 전파하고 자체 스팬을 내보냅니다. 이 두 가지를 결합하면 클라이언트 앱에서 Linkerd 프록시를 거쳐 백앤드 앱에 이르기까지 동일한 트레이스에서 전체 워터폴을 얻을 수 있습니다.

시작하기 전에

다음 사항을 확인하십시오:

Linkerd edge-26.7.0 이상 (2.19+). 이전 릴리스의 프록시 추적에는 별도의 수집기 서비스 및 cert-manager 통합이 필요했으며, 이 가이드에서는 이를 다루지 않습니다. 업그레이드해야 하는 경우 Linkerd 시작 가이드를 참조하십시오.
Linkerd 인스턴스에 대해 NRDOT 또는 OTel Collector Contrib이 실행 중이어야 합니다:
- NRDOT의 경우 Helm 차트 또는 매니페스트를 사용합니다.
- OTel Collector Contrib의 경우 Helm 차트 또는 매니페스트를 사용합니다.
트레이스하려는 네임스페이스에 주입이 활성화되어 있어야 합니다.

분산 추적 설정

의 에 traces deployment.configMap.extraConfig values.yaml 파이프라인을 추가하십시오. otlp 수신기를 재정의하지 마십시오. 차트에는 이미 기본적으로 하나가 포함되어 있습니다:

추가할 프로세서:

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(으)로 만듭니다. 동일한 계정에 보고하는 모든 클러스터에서 고유한 배포 이름을 사용하십시오. 다른 클러스터에도 존재하는 이름은 해당 클러스터의 동일한 엔티티로 확인되므로, 데이터가 두 개의 별도 서비스로 표시되지 않고 병합됩니다.

업데이트된 values.yaml을(를) 사용하여 OpenTelemetry로 Kubernetes에서 Linkerd 모니터의 helm upgrade 명령을 다시 실행한 다음, 다음 일회성 단계를 완료하십시오:

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 수신기를 재정의하지 마십시오. 기본 매니페스트에는 이미 기본적으로 하나가 포함되어 있습니다:

추가할 프로세서:

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. 수집기를 메시합니다. 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>

그런 다음 아래의 애플리케이션 파드 계측하기를 계속 진행합니다.

Linkerd 2.19부터 프록시 트레이스 내보내기는 컨트롤 플레인에서 직접 구성되며, cert-manager나 별도의 포트가 필요하지 않습니다. 두 가지 단계가 필요합니다: 수집기가 트레이스를 수신할 수 있도록 한 다음, 프록시에서 트레이스 내보내기를 켭니다.

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

위의 동일한 세 블록(Receivers, Processors, Pipelines)을 매니페스트가 있는 OTel Collector Contrib의 otel-collector.yaml에 있는 ConfigMap의 config 키에 추가합니다. 해당 매니페스트의 서비스는 이미 포트 4317 (grpc) 및 4318 (http)을 노출하므로 포트를 변경할 필요가 없습니다. 다시 적용하고 다시 시작합니다. ConfigMap만 다시 적용하면 실행 중인 수집기 파드가 다시 시작되지 않으므로 두 번째 명령 없이는 새 구성을 가져오지 않습니다:

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 자바 에이전트(또는 해당 언어의 에이전트)를 추가하십시오. Linkerd는 W3C Trace Context 및 B3 형식을 모두 지원합니다. OTel 에이전트가 이를 자동으로 처리합니다.

팁

spec.exporter.endpoint 아래는 매니페스트가 있는 OTel Collector Contrib 페이지의 서비스를 가리킵니다. 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>

다른 언어(파이썬, .NET, Node.js, Go) 및 사이드카 대 init-container 주입, 리소스 제한 또는 다중 컨테이너 파드와 같은 고급 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 - Manifest	`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 - Manifest	다음에 있는 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단계: 수집기에 트레이스 수집 추가

지배

Manifest

2단계: 프록시 트레이스 내보내기 활성화

중요

Helm을 통해

대안: Linkerd CLI

3단계: 애플리케이션의 메시된 파드 다시 시작

애플리케이션 파드 계측

팁

OTel Operator(권장)

앱 메트릭을 APM과 상관관계 지정(선택 사항)

Linkerd 프록시 로그 수집

지표 참조

데이터 찾기 및 쿼리

사용자의 편의를 위해 제공되는 기계 번역입니다.

OpenTelemetry를 사용한 Linkerd 분산 추적

작동 원리 .css-21sua1{background:none;border:none;width:0;padding:0;}

시작하기 전에

분산 추적 설정

매니페스트 설치

1단계: 수집기에 트레이스 수집 추가

지배

Manifest

2단계: 프록시 트레이스 내보내기 활성화

중요

Helm을 통해

대안: Linkerd CLI

3단계: 애플리케이션의 메시된 파드 다시 시작

애플리케이션 파드 계측

팁

OTel Operator(권장)

앱 메트릭을 APM과 상관관계 지정(선택 사항)

관련 기사

Linkerd 프록시 로그 수집

지표 참조

데이터 찾기 및 쿼리

작동 원리