단일 단계 APM 트러블슈팅 (Troubleshooting Single Step APM)

원문 보기 위키 갱신 2026.10.05

단일 단계 계측(SSI)으로 애플리케이션을 계측할 때 발생하는 일반적인 문제를 진단하고 해결하는 방법을 안내해요.

출처: 문서

본문

개요

단일 단계 계측(SSI)은 애플리케이션 프로세스에 Datadog SDK를 자동으로 로드해 애플리케이션을 계측하도록 돕는 기능이에요. SSI는 Linux 호스트에서 실행되는 애플리케이션, Kubernetes와 Docker 같은 컨테이너 환경, 그리고 Windows IIS가 제공하는 .NET 애플리케이션에서 작동하며, 애플리케이션 종속성이나 이미지를 변경할 필요가 없어요. SSI로 APM을 활성화할 때 문제가 발생하면 이 가이드를 사용해 일반적인 문제를 트러블슈팅하고 해결해요. 추가 지원이 필요하면 Datadog 지원에 문의하세요.

트러블슈팅 방법

주입 문제는 Datadog UI의 Fleet Automation에서 또는 컨테이너 레벨에서 수동으로 조사할 수 있어요. 주입기가 각 프로세스에 대해 내린 결정을 더 낮은 레벨에서 보려면 주입기 디버그 로그를 참조하세요.

Datadog Fleet Automation에서 주입 트러블슈팅

Fleet Automation은 SSI에 대한 두 가지 유형의 계측 인사이트를 제공해요:

프로세스 레벨 인사이트는 개별 호스트나 컨테이너의 계측 상태와 SDK 설치 세부 정보를 보여줘요.
Kubernetes 클러스터 인사이트는 클러스터 전반의 계측에 대한 더 높은 레벨의 보기를 제공하며, SSI 구성과 주입이 규모에 맞게 어떻게 적용되는지 이해하도록 도와줘요.

이 두 보기는 프로세스 관점과 클러스터 관점 모두에서 주입 문제를 진단할 수 있게 해줘요.

사전 요구 사항

이 기능은 다음에서 사용할 수 있어요:

언어: Python, Java, Node.js, PHP, .NET
환경: Linux 호스트, 컨테이너, Kubernetes
Datadog Agent v7.68.2+

프로세스 레벨 인사이트 보기

프로세스 레벨 인사이트를 사용해 SSI가 애플리케이션 프로세스에 올바르게 적용되었는지 확인하고 주입 실패를 식별해요.

Fleet Automation으로 이동해요.
패싯을 사용해 관련 호스트로 필터링해요:
- single_step_instrumentation은 SSI가 활성화되었거나 비활성화된 호스트를 보여줘요.
- single_step_instrumentation_status는 서비스 계측에 문제가 발생한 호스트를 보여줘요.
호스트를 선택해 Agent 세부 정보 패널을 열어요.
Agent 패널에서 Services 탭으로 이동해요.
호스트에서 SSI가 활성화되어 있으면 탭은 다음을 보여줘요:
- "Single Step Instrumentation is enabled on this host." 메시지가 있는 배너.
- 트러블슈팅할 문제가 있는 경우 SDK Installations 섹션.

Kubernetes 클러스터 인사이트 보기

클러스터 레벨 인사이트를 사용해 SSI가 Kubernetes 클러스터 전반에서 어떻게 구성되고 작동하는지 이해해요. 이 인사이트는 개별 프로세스를 넘어 워크로드에 계측이 클러스터 레벨에서 어떻게 적용되는지 보여주며 트러블슈팅을 확장해요.

Fleet Automation > View Agents로 이동하고 오른쪽 위에서 Kubernetes Clusters를 선택해요.
클러스터를 선택해 세부 정보를 봐요. 다음을 포함해요:
- 클러스터가 Helm 또는 Datadog Operator로 관리되는지 여부
- Cluster Agent 및 Node Agent 버전
- 각 호스트에서 실행 중인 통합 및 서비스
Single Step Instrumentation 탭을 열어 다음을 검토해요:
- 클러스터의 SSI 구성 (YAML 보기)
- 클러스터 구성 또는 파드 레벨 어노테이션을 기반으로 계측 대상으로 식별된 파드
- 계측 성공 여부를 포함한 각 대상 파드의 상태
- 각 파드에 주입된 SDK (언어 및 버전 포함)
- 각 계측된 워크로드가 트레이스를 생성하는지 여부
상태 아이콘 위에 마우스를 올리면 계측 또는 트레이스 수집 상태에 대한 맥락적 세부 정보를 볼 수 있어요.

애플리케이션 컨테이너에서 주입 수동 확인

Datadog UI에 계측 문제가 표시되지 않거나 단일 서비스나 컨테이너를 트러블슈팅하는 경우, 주입이 예상대로 발생했는지 수동으로 확인할 수 있어요. 이 방법은 중앙 집중식 가시성이 제한된 환경에서 디버깅하거나 특정 서비스가 트레이스를 보고하지 않을 때 유용해요.

컨테이너 레벨에서 주입을 확인하려면 다음을 확인해요:

/etc/ld.so.preload에 다음 항목이 포함돼 있는지:

/opt/datadog-packages/datadog-apm-inject/stable/inject/launcher.preload.so

LD_PRELOAD 환경 변수가 같은 값으로 설정돼 있는지.
/opt/datadog-packages/datadog-apm-inject 디렉터리가 존재하고 stable 및 $version 하위 디렉터리가 있는지.
언어별 디렉터리가 존재하는지 (예: Java의 경우 /opt/datadog/apm/library/java/).

수동 확인 중에 디버그 로그를 활성화하려면:

파드 스펙에 다음을 설정해요:

   env:
     - name: DD_TRACE_DEBUG    # SDK에 대한 디버그 로깅
       value: "true"
     - name: DD_APM_INSTRUMENTATION_DEBUG    # 주입기에 대한 디버그 로깅
       value: "true"


1. 주입 중 디버그 로그를 활성화하려면 파드를 삭제해요.

### 주입기 디버그 로그

주입기 디버그 로그는 주입기가 각 프로세스에 대해 내린 결정, 즉 주입이 성공했는지, 거부되었는지, 건너뛰어졌는지와 그 이유를 보여줘요. Fleet Automation이 실패를 설명하지 못할 때, 호스트나 컨테이너 레벨에서 진단할 때, 또는 [Datadog 지원](https://docs.datadoghq.com/tracing/trace_collection/automatic_instrumentation/single-step-apm/kubernetes?tab=agentv764recommended#remove-apm-for-all-services-on-the-infrastructure)을 위해 정보를 수집할 때 활성화해요.

주입기 디버그 로그는 트레이서 디버그 로그와 별개예요. 트레이서가 주입되었는지와 어떻게 주입되었는지를 진단하려면 주입기 로그를 사용하고, 주입 후에는 프로세스 내부에서 실행되는 트레이서를 진단하려면 [트레이서 디버그 로그](https://docs.datadoghq.com/tracing/troubleshooting/tracer_debug_logs)를 사용해요.

#### 디버그 모드 활성화

계측하려는 프로세스에 다음 환경 변수를 설정해요:

DD_APM_INSTRUMENTATION_DEBUG=true


이렇게 하면 주입기 로그 레벨이 `DEBUG`로 올라가고 `stderr`가 로그 싱크로 추가돼요.

이 변수는 주입된 프로세스가 상속하는 환경에 설정해야 해요:

##### 호스트

프로세스를 시작하기 전에 변수를 내보내요:

```sh
export DD_APM_INSTRUMENTATION_DEBUG=true
./my-service

Docker

애플리케이션 컨테이너에 환경 변수를 추가해요:

docker run -e DD_APM_INSTRUMENTATION_DEBUG=true my-image

디버그 출력은 컨테이너 로그(docker logs <container>)에 나타나요.

Kubernetes

파드 템플릿의 컨테이너 스펙에 변수를 추가해요:

spec:
  containers:
    - name: my-app
      env:
        - name: DD_APM_INSTRUMENTATION_DEBUG
          value: "true"

또는 컨테이너 스펙을 편집하지 않고 디버그 모드를 활성화하려면 다음 파드 어노테이션을 추가해요:

metadata:
  annotations:
    admission.datadoghq.com/apm-inject.debug: "true"

디버그 출력은 애플리케이션 파드 로그(kubectl logs <pod>)에 나타나요.

디버그 로그 검토

로그를 찾을 위치

디버그 모드가 활성화되면 주입기는 계측된 프로세스의 stderr에 기록해요:

환경	찾을 위치
호스트 또는 셸	프로세스의 터미널, 또는 `stderr`가 리디렉션된 곳
Docker	`docker logs <container>`
Kubernetes	`kubectl logs <pod>` (Cluster Agent가 아닌 애플리케이션 파드)

참고: stderr 대신 파일로 디버그 출력을 보내려면 DD_APM_INSTRUMENTATION_OUTPUT_PATHS를 절대 경로로 설정해요.

성공적인 주입

주입이 발생했는지 확인하려면 실행 파일이 런타임과 일치하는 로그 블록을 찾아요. 다음 예시는 성공적인 Node.js 주입을 보여줘요:

<DEBUG> ... [linux/process.c:405] process_exe: 'node'
<DEBUG> ... [linux/process.c:443] Main executable path: '/usr/local/bin/node'
<DEBUG> ... [workload_selection.c:147] Workload selection allowed injection: continuing
<DEBUG> ... [workload_selection.c:90] Succesfully loaded policy: 'requirements.bin from SDK policies' from '/opt/datadog-packages/datadog-apm-inject/0.67.0/requirements/nodejs/requirements.bin' [size: 3864]
<DEBUG> ... [languages.c:71] detected language: 'nodejs'
<DEBUG> ... [languages.c:72] detected language version: '20.20.2'
<DEBUG> ... [linux/env_injector.c:38] injection config: DD_TELEMETRY_FORWARDER_PATH=/opt/datadog-packages/datadog-apm-inject/0.67.0/inject/process
<DEBUG> ... [linux/env_injector.c:38] injection config: DD_TAGS=_dd.injection.mode:k8s
<DEBUG> ... [linux/env_injector.c:38] injection config: DD_INJECTION_ENABLED=tracer
<DEBUG> ... [linux/env_injector.c:38] injection config: NODE_OPTIONS=--require /opt/datadog/apm/library/js/node_modules/dd-trace/init.js
<INFO>  ... [./libinject.c:81] injection duration: 1.066500 ms
<DEBUG> ... [injection_metadata.c:101] sending injection-metadata telemetry: result='0', result_reason='injection completed successfully'
<DEBUG> ... [./libinject.c:231] injector finished

로그 줄	의미
`process_exe: '<exe>'` / `Main executable path: '<path>'`	평가 중인 프로세스.
`Workload selection allowed injection: continuing`	정책이 주입을 허용했어요.
`Succesfully loaded policy: 'requirements.bin...'`	감지된 런타임에 대한 언어 요구 사항 정책이 로드되었어요.
`detected language: '<lang>'` / `detected language version: '<version>'`	런타임(`nodejs`, `java`, `python`, `ruby`, `dotnet`, `php`)이 식별되었고 그 버전이 읽혔어요.
`injection config: <VAR>=<value>`	주입기가 설정한 각 환경 변수. `DD_INJECTION_ENABLED=tracer`와 언어별 변수(예: `NODE_OPTIONS` 또는 `JAVA_TOOL_OPTIONS`)가 함께 보이면 추적 SDK가 로드되었음을 확인해줘요.
`injection duration: <N> ms`	주입이 완료되었고 경과 시간.
`injection completed successfully` (`result='0'`)	주입기가 텔레메트리에 성공적인 주입을 보고했어요. 0이 아닌 `result`와 다른 `result_reason`은 실패를 나타내요.
`injector finished`	주입기 생성자가 반환되었어요.

일반적인 로그 메시지

주입 비활성화

DD_INSTRUMENT_SERVICE_WITH_APM=false 또는 주입이 다른 방식으로 비활성화된 경우:

<DEBUG> ... [libinject.c:115] disabled flag set, not injecting

주입기는 로드되었지만 의도적으로 주입을 건너뛰었어요. DD_INSTRUMENT_SERVICE_WITH_APM=false를 제거하거나 true로 설정해 주입을 허용해요.

런타임 감지 안 됨

프로세스가 지원되지 않는 언어 런타임인 경우:

<DEBUG> ... [libinject.c:175] No known runtime was detected - not injecting!

주입기가 실행되었지만 프로세스가 주입 대상 언어(nodejs, java, python, ruby, dotnet, php)가 아니에요. 비애플리케이션 프로세스에서는 예상된 동작이에요.

워크로드 선택 거부

<DEBUG> ... [workload_selection.c:149] Workload selection denied injection

정책이 이 프로세스에 대한 주입을 방지했어요. 앞선 Evaluating '<policy-name>' 줄은 어떤 규칙이 일치했고 어떤 값을 비교했는지 보여줘요.

재실행 감지

<DEBUG> ... [libinject.c:102] Re-exec detected!

프로세스가 주입된 환경 변수가 적용되도록 스스로 재실행했어요. 예상된 동작이에요. 주입은 재실행된 프로세스에서 계속되며, 이 프로세스는 자체 디버그 줄 집합을 생성해요.

주입에 영향을 주는 구성 옵션

주입 동작을 차단하거나 변경할 수 있는 여러 구성 메커니즘이 있어요.

저장 공간 요구 사항

SSI는 언어 SDK와 주입기 패키지를 각 호스트에 다운로드해요. 필요한 디스크 공간은 사용 중인 언어 수와 계측되는 파드 수에 따라 달라져요. 대략적인 추정치는:

[언어 라이브러리 크기의 합]
+
[주입기 패키지 크기] * [호스트당 주입된 파드 수]

라이브러리 패키지는 자주 업데이트되고 새 언어 버전 지원이 추가되면 커질 수 있으므로 디스크 사용량은 시간이 지나면서 변할 수 있어요. 디스크 공간이 제한된 환경이라면 패키지 크기를 모니터링하고 주입 실패를 피하기 위해 여유 용량을 확보해요.

주입기 버전

주입기 버전을 설정하려면:

클러스터 레벨에서:

values.yaml의 datadog.apm.instrumentation.injector.imageTag 아래에 설정해요.

파드 레벨에서:

admission.datadoghq.com/apm-inject.version 어노테이션으로 설정해요.

호스트 또는 Docker 주입의 경우 auto_inject 버전 수정은 권장되지 않아요.

허용 및 거부 목록

기본 거부 목록

Datadog은 특정 프로세스(예: IDE 또는 데이터베이스)에 주입되는 것을 방지하는 내부 거부 목록을 유지해요. 프로세스 명령이나 엔트리포인트가 이 목록에 있으면 주입기는 주입 과정을 건너뛰어요.

Linux 계측 규칙

계측 규칙은 제한된 이용 가능 프리뷰를 통해 Linux 기반 앱에 사용할 수 있어요. 프로세스 주입에 대한 허용 또는 거부 규칙을 구성하려면 프리뷰 액세스에 가입하세요.

액세스 요청

Kubernetes 계측 규칙

계측 규칙은 Kubernetes 라벨과 선택기를 기반으로 주입을 활성화해요. 고려해야 할 규칙:

disabledNamespaces는 항상 우선해요.
파드가 초기화될 때 대상 목록이 위에서 아래로 확인돼요. 파드당 첫 번째 일치 규칙만 적용돼요.

보안 스캐너가 표시한 주입 컨테이너

보안 도구는 apm-inject 컨테이너가 시작 시 실행 파일을 실행하므로(악성 소프트웨어와 비슷해 보일 수 있음) 이를 표시할 수 있어요.

컨테이너의 동작은 예상되고 안전해요. 실행 파일은 자동 계측을 위한 환경을 구성해요.

Datadog은 보안 모범 사례를 준수하며 이 컨테이너를 허용 목록에 추가하기 위해 보안 공급업체와 협력하고 있어요.

파드 보안 설정이 엄격한 환경

파드 보안 규칙이 Datadog init 컨테이너를 차단하면 다음과 같은 오류가 나타날 수 있어요:

Privilege escalation container is not allowed or violates PodSecurity "restricted: latest": allowPrivilegeEscalation is false

이를 해결하려면 다음 Cluster Agent 옵션 중 하나를 설정해요:

DD_ADMISSION_CONTROLLER_AUTO_INSTRUMENTATION_INIT_SECURITY_CONTEXT
admission_controller.auto_instrumentation.init_security_context

값은 Datadog init 컨테이너에 필요한 보안 컨텍스트를 적용하는 JSON 문자열이어야 해요.

커스텀 계측

커스텀 계측은 여전히 SDK를 가져와야 해요. .NET의 DD_TRACE_METHODS 같은 구성 변수는 커스텀 스팬을 정의하는 데 계속 사용할 수 있어요.

일반 트러블슈팅

DD_TRACE_ENABLED=false 설정 후에도 SSI가 계속 실행됨

DD_TRACE_ENABLED=false를 설정해도 SSI가 SDK를 로드하는 것을 막지는 못해요. 주입기는 SDK가 환경 변수를 평가하기 전에 실행되므로 SDK 레벨 환경 변수는 SSI에 영향을 주지 않아요. SSI를 비활성화하거나 제거하려면 해당 플랫폼의 SSI 설정 페이지를 참조하세요.

환경별 트러블슈팅

호스트 및 Docker 환경

호스트 주입이 기존 프로세스에 적용되지 않음

프리로드 라이브러리는 새로 시작된 프로세스에만 주입해요. 계측을 적용하려면 새 셸 세션을 시작하거나 로그아웃 후 다시 로그인해요.

참고: Docker 기반 주입에는 이 제한이 없어요.

소규모 인스턴스 유형에서 주입 실패

프리로드 라이브러리는 분석기에 1초를 주어 작업을 완료하게 해요. 여러 서비스를 실행하는 소규모 VM 인스턴스(예: t2.micro)에서는 이 시간 제한을 초과할 수 있어요. 이 문제를 해결하려면 t2.small 같은 더 큰 인스턴스 크기를 사용해요.

Agent 파일을 수동으로 제거한 후 오류

Agent 파일을 수동으로 삭제하면 다음과 같은 오류가 나타날 수 있어요:

ERROR: ld.so: object /opt/datadog/apm/inject/launcher.preload.so from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored

SSI를 제대로 제거하려면 플랫폼별 지침을 따르세요:

루트리스 Docker에서 주입이 작동하지 않음

루트리스 Docker를 사용할 때 /etc/datadog-agent/inject/docker_config.yaml의 docker_socket을 현재 사용자가 사용하는 Docker 소켓의 경로(일반적으로 /run/user/$UID/docker.sock)로 설정해요. 재부팅은 필요하지 않아요.

정적으로 링크된 런처에서 주입 실패

커스텀 런처가 정적으로 링크되어 있으면(Go에서 흔함) 프리로드 라이브러리가 호출되지 않을 수 있어요. 다음 조건에서는 주입이 여전히 성공할 수 있어요:

런처의 명령줄에 언어 이름이 포함된 경우
런처가 중간의 동적으로 링크된 프로그램을 실행하는 경우

그러나 정적으로 링크된 바이너리에서 직접 프로세스 시작은 주입되지 않아요.

Kubernetes 환경

Datadog Admission Controller는 애플리케이션 파드가 생성되기 전에 배포되고 구성되어야 해요. 기존 파드를 수정할 수는 없어요.

Admission Controller 문제를 트러블슈팅하려면:

Cluster Agent 파드 상태를 확인해요:
```
kubectl get pods
kubectl get deployments
```

Cluster Agent 리더 로그에서 Admission Controller 시작 성공을 나타내는 INFO 메시지를 확인해요. 예:

Group version 'admissionregistration.k8s.io/v1' is available, Starting secrets controller, Starting webhook controller

다음 중 하나를 수행해 Admission Controller 상태를 확인해요:
- Cluster Agent 파드 안에서 agent status를 실행해 실시간 상태 출력을 얻어요.
- 소급하여 트러블슈팅한다면 flare 안의 status.log를 확인해요. flare가 생성되면 시스템이 agent status를 실행하고 그 출력을 status.log에 저장해요.

두 경우 모두 Admission Controller와 Webhooks 섹션을 찾아 다음을 확인해요:

예상된 모든 MutatingWebhookConfiguration 리소스가 나열되어 있는지(자동 계측, 구성 주입, 태그 주입용).
웹훅 구성이 올바른 Secret을 참조하는지.
CA 번들 다이제스트가 구성 간에 일치하는지.

telemetry.log 또는 다음 명령의 출력에서 주입 시도를 검사해요:
```
kubectl exec -it <cluster agent pod> agent telemetry
```

admission_webhooks_library_injection_attempts를 찾아 언어별 주입 시도를 확인해요.

실패한 변형(mutation)

Cluster Agent는 주입 실패에 대한 경고와 오류를 로그로 기록하며, 일반적으로 admission/server.go에서 발생해요. 예를 들어 valueFrom을 사용해 JAVA_TOOL_OPTIONS가 설정되면 경고가 나타날 수 있어요.

추가 디버깅에는 datadog.cluster_agent.admission_webhooks.library_injection_errors 메트릭을 사용해요.

언어 어노테이션을 적용할 수 없음

설정 중에 SSI는 서비스의 애플리케이션 언어를 감지하고 internal.dd.datadoghq.com/service-name.detected_langs 형식의 서비스 라벨을 적용해요. 라벨을 적용할 수 없으면 주입이 실패해요.

때로는 서비스 이름이 Kubernetes 문자열 제한(63자)을 넘기 때문에 라벨링 오류가 발생해요. 예:

languagedetection/patcher.go:231 in handleDeploymentEvent) | failed to handle deployment event: annotations: Invalid value: "internal.dd.datadoghq.com/dummy-python-container-long-long-long-long-long-x.detected_langs": name part must be no more than 63 characters

통합 서비스 태깅을 통해 서비스 태그가 명시적으로 설정되지 않은 경우 기본 이미지 이름이 사용되므로 문자열 제한 위반이 흔해요.

주입은 성공한 것처럼 보이지만 트레이스가 없음

로그에 문제가 없는데 트레이스가 없다면 애플리케이션 측 구성 오류가 있을 수 있어요. 다음을 확인해요:

필요한 어노테이션과 라벨이 있는지.
통합 서비스 태깅이 올바르게 설정되었는지.
계측 규칙의 허용/거부 목록이 올바르게 정의되었는지.

언어별 트러블슈팅

Java

`JAVA_TOOL_OPTIONS`이 너무 길다

JAVA_TOOL_OPTIONS 환경 변수에는 JVM이 시행하는 1024자 제한이 있어요. 주입 중에 Datadog은 트레이싱을 활성화하기 위해 이 변수에 -javaagent 플래그를 추가해요. 결합된 값이 제한을 초과하면 JVM은 경고를 내보내고 변수를 무시해 주입을 방지해요.

이 문제를 피하려면 해당 프로세스를 주입에서 제외해요.

`JAVA_TOOL_OPTIONS`가 프로그램 출력을 변경

JAVA_TOOL_OPTIONS가 설정되면 JVM은 Picked up JAVA_TOOL_OPTIONS: -Xmx1024m 같은 메시지를 stdout에 출력해요. 프로세스가 이 출력을 읽고 의존한다면 영향을 받을 수 있어요.

버전 0.12.2부터 출력을 파싱하는 프로세스를 방해하지 않도록 java -version에 대한 주입은 건너뛰어져요.

여러 Java 사이트가 같은 서비스 이름으로 보고됨

기본적으로 단일 단계는 DD_SERVICE 환경 변수를 설정하며, 이 변수는 같은 서버(예: Tomcat 또는 WebLogic)에서 실행되는 모든 웹 애플리케이션에 단일 서비스 이름을 적용해요. 결과적으로 모든 사이트가 같은 이름으로 보고돼요.

각 사이트가 자신의 이름으로 보고되도록 split-by-tags를 활성화하려면 다음 옵션 중 하나를 사용해요:

JVM 시스템 속성: -Ddd.trace.split-by-tags=servlet.context
환경 변수: DD_TRACE_SPLIT_BY_TAGS=servlet.context

트레이서가 이미 존재함

SSI는 이미 -javaagent 옵션 또는 다른 트레이싱 구성을 사용하는 애플리케이션에는 주입하지 않아요.

Ruby

Ruby 주입은 Gemfile을 수정해 Datadog SDK를 추가해요. 이후 주입 지원이 제거되면 애플리케이션이 누락된 종속성 때문에 시작에 실패할 수 있어요.

이를 해결하려면 원래 Gemfile을 복원해요. 주입 제거 후에도 APM을 계속 사용하려면 bundle install을 실행해 gem을 다운로드해요.

Python

버전 2.7.5 이하에는 시스템 라이브러리와 충돌할 수 있는 사전 패키징된 protobuf 종속성이 포함돼 있어요.

.NET

SSI가 적용되었지만 .NET 트레이스가 Agent에 도달하지 않음

파드에 SSI 어노테이션과 init 컨테이너가 있는데 .NET 트레이스가 도착하지 않는다면 다른 프로파일러가 우선권을 가질 수 있어요. 메인 컨테이너의 CORECLR_PROFILER를 확인해요. 값이 {846F5F1C-F9AE-4B07-969E-05C26BC060D8}(Datadog .NET 트레이서 CLSID)가 아니라면 Datadog 대신 다른 프로파일러가 로드된 것이에요.

충돌하는 CORECLR_* 환경 변수(및 다른 프로파일러를 참조하는 LD_PRELOAD 항목)를 이를 주입한 소스(다른 공급업체의 operator, init 컨테이너, 파드 템플릿 또는 Helm values)에서 제거해요. 그런 다음 파드를 롤해요. .NET CLR Profiling API는 프로세스당 한 명의 구독자만 허용해요.

지원을 위한 진단 정보 수집

주입 문제로 지원에 연락할 때 트러블슈팅을 돕기 위해 다음 정보를 수집해요:

호스트 주입, Docker 주입 또는 둘 다 사용하고 있나요?
/opt/datadog-packages/datadog-apm* 디렉터리가 존재하는지 확인해요.
호스트 주입의 경우 /etc/ld.so.preload의 존재와 권한을 확인해요:
```
sudo ls -l /etc/ld.so.preload
```

root가 소유하고 644 권한(-rw-r--r--)이어야 해요.

주입기 디버그 로그를 활성화하고 출력을 수집해요. 지침은 "주입기 디버그 로그"를 참조하세요.
Agent flare를 제공해요.

Kubernetes 기반 주입을 위한 추가 정보

Kubernetes 환경에서 주입을 트러블슈팅한다면 다음 세부 정보를 수집해요:

Cluster Agent를 배포하는 데 사용한 방법(예: Helm, Datadog Operator 또는 kubectl 명령).
애플리케이션 파드의 배포 파일.
이상적으로는 DEBUG 모드를 활성화한 Node Agent와 Cluster Agent의 flare.
다음의 출력:
```
kubectl describe pod <app pod>
```
애플리케이션 파드(Cluster Agent가 아님)의 주입기 디버그 로그. 지침은 "주입기 디버그 로그"를 참조하세요.