트레이서 디버그 로그 (Tracer Debug Logs)

구성 및 연결 문제를 해결하기 위해 Datadog SDK에서 디버그 로그를 활성화하고 수집해요.

출처: 문서

본문

자동화된 디버그 로그 수집 (Automated debug log collection)

danger 자동화된 디버그 로그는 Java, Python, Node.js, .NET에서만 지원돼요. 다른 언어는 수동 디버그 로그 수집을 대신 사용하세요.

플레어(flare)를 사용하면 민감한 데이터를 제거한 상태에서 트레이서 로그를 포함한 필수 문제 해결 정보를 Datadog 지원팀에 보낼 수 있어요. 플레어는 높은 CPU 사용량, 높은 메모리 사용량, 누락된 스팬 같은 문제를 해결하는 데 유용해요.

사전 요구 사항 (Prerequisites)

• Remote Configuration이 활성화되어 있어야 해요.
• API 키가 Remote Configuration용으로 구성되어 있어야 해요.
• 지원되는 트레이서 버전을 사용해야 해요:
  • Java: 1.26.0 이상
  • Python: 3.12.0 이상
  • Node.js: 5.15.0 이상 또는 4.39.0 이상
  • .NET: 2.46.0 이상

플레어 보내기 (Send a flare)

Datadog 사이트에서 플레어를 보내려면 Agent에서 Fleet Automation을 활성화했는지 확인하세요. 원격 플레어를 보내려면:

1. Fleet Automation 페이지에서 지원이 필요한 Agent를 선택하세요.
2. Support를 클릭하세요.
3. Send Support Ticket을 클릭하세요.
4. 기존 Zendesk 지원 티켓 번호를 제공하세요. 티켓 번호를 제공하지 않으면 대신 티켓이 생성됩니다.
5. Debug mode를 활성화해 Datadog 지원 직원이 문제를 더 빠르게 해결할 수 있게 하세요. 플레어를 보낸 후 로그 레벨은 이전 구성으로 재설정돼요.
6. 애플리케이션 문제를 해결하는 경우 플레어에 애플리케이션 트레이서 레벨 로그가 포함되도록 활성화하세요.
7. Send Ticket을 클릭하세요.

danger 서비스에 이 옵션이 보이지 않으면 애플리케이션과 Datadog Agent 사이에 연결 오류가 있을 가능성이 높으므로 디버그 트레이서 로그를 제공하는 수동 옵션을 사용해야 해요.

디버그 모드 활성화 (Enable debug mode)

문제를 진단하거나 트레이스 데이터를 감사하려면 Datadog 디버그 설정을 사용하세요. 디버그 모드는 로거로 전송되는 이벤트 수를 증가시키므로 프로덕션 시스템에서 활성화하는 것을 권장하지 않아요. 디버그 모드는 디버깅 목적으로만 사용하세요.

디버그 모드는 기본적으로 비활성화되어 있어요. 활성화하려면 해당 언어 트레이서 지침을 따르세요:

Java

Datadog Java Tracer의 디버그 모드를 활성화하려면 JVM을 시작할 때 -Ddd.trace.debug=true 플래그를 설정하거나 DD_TRACE_DEBUG=true를 환경 변수로 추가하세요.

참고:

• Datadog Java Tracer는 SLF4J SimpleLogger를 구현하므로 모든 설정을 적용할 수 있어요. 예를 들어 전용 로그 파일에 기록하도록 구성할 수 있어요:

-Ddatadog.slf4j.simpleLogger.logFile=<NEW_LOG_FILE_PATH>

• Datadog Java Tracer 로그를 Datadog Logs UI와 호환되는 JSON 형식으로 출력하려면 다음을 사용하세요:

-Ddatadog.slf4j.simpleLogger.jsonEnabled=true

버전 1.58.0부터 DD_LOG_FORMAT_JSON 환경 변수를 사용해 Datadog Java Tracer 로그 형식을 제어할 수 있어요.

Python

Datadog Python Tracer에서 디버그 모드를 활성화하는 단계는 애플리케이션이 사용하는 SDK 버전에 따라 달라져요. 해당하는 시나리오를 선택하세요:

시나리오 1: ddtrace 버전 2.x 이상

1. 디버그 모드 활성화: DD_TRACE_DEBUG=true
2. 디버그 로그를 로그 파일로 라우팅하려면 DD_TRACE_LOG_FILE을 현재 작업 디렉터리를 기준으로 한 해당 로그 파일 이름으로 설정하세요. 예: DD_TRACE_LOG_FILE=ddtrace_logs.log. 기본적으로 파일 크기는 15728640바이트(약 15MB)이며 백업 로그 파일이 하나 생성돼요. 기본 로그 파일 크기를 늘리려면 DD_TRACE_LOG_FILE_SIZE_BYTES 설정으로 크기를 바이트 단위로 지정하세요.

참고: 애플리케이션이 루트 로거를 사용하고 로그 레벨을 DEBUG로 변경하면 디버그 트레이서 로그가 활성화됩니다. 이 동작을 재정의하려면 다음 중 하나를 수행하세요:

1. DD_TRACE_LOG_LEVEL 환경 변수를 설정하세요(예: DD_TRACE_LOG_LEVEL=CRITICAL). 이 옵션은 v4.4.0+에서 사용 가능하며 DD_TRACE_DEBUG=true와 함께 사용할 수 없어요.

2. 코드에서 ddtrace 로거를 재정의하세요:

   import logging
   
   # root logger configuration
   root_logger = logging.getLogger()
   root_logger.setLevel(logging.DEBUG)
   
   # override the ddtrace configuration to WARNING log level
   logging.getLogger("ddtrace").setLevel(logging.WARNING)
   

시나리오 2: ddtrace 버전 1.3.2 ~ <2.x

1. 디버그 모드 활성화: DD_TRACE_DEBUG=true
2. 디버그 로그를 로그 파일로 라우팅하려면 DD_TRACE_LOG_FILE을 트레이서 로그가 기록될 파일 이름으로, 현재 작업 디렉터리를 기준으로 설정하세요. 예: DD_TRACE_LOG_FILE=ddtrace_logs.log. 기본적으로 파일 크기는 15728640바이트(약 15MB)이고 백업 로그 파일이 하나 생성돼요. 기본 로그 파일 크기를 늘리려면 DD_TRACE_LOG_FILE_SIZE_BYTES 설정으로 크기를 바이트 단위로 지정하세요.
3. 로그를 콘솔로 라우팅하려면 Python 2 애플리케이션의 경우 logging.basicConfig() 등을 구성하세요. Python 3 애플리케이션은 로그가 자동으로 콘솔로 전송돼요.

시나리오 3: ddtrace 버전 1.0.x ~ 1.2.x

1. 디버그 모드 활성화: DD_TRACE_DEBUG=true
2. 로그를 콘솔로 라우팅하려면 Python 2 또는 Python 3 애플리케이션의 경우 logging.basicConfig()를 구성하거나 DD_CALL_BASIC_CONFIG=true를 사용하세요.

시나리오 4: ddtrace 버전 0.x

1. 디버그 모드 활성화: DD_TRACE_DEBUG=true
2. 로그를 콘솔로 라우팅하려면 Python 2 또는 Python 3 애플리케이션의 경우 logging.basicConfig()를 구성하거나 DD_CALL_BASIC_CONFIG=true를 사용하세요.

시나리오 5: 표준 logging 라이브러리로 애플리케이션 코드에서 디버그 로깅 구성

모든 ddtrace 버전에서 DD_TRACE_DEBUG 트레이서 환경 변수를 설정하는 대신 logging 표준 라이브러리를 직접 사용해 애플리케이션 코드에서 디버그 로깅을 활성화할 수 있어요:

log = logging.getLogger("ddtrace.tracer")
log.setLevel(logging.DEBUG)

Ruby

Datadog Ruby Tracer의 디버그 모드를 활성화하려면 환경 변수 DD_TRACE_DEBUG=true를 설정하세요.

애플리케이션 로그 (Application Logs)

기본적으로 모든 로그는 기본 Ruby 로거로 처리돼요. Rails를 사용하는 경우 애플리케이션 로그 파일에서 메시지를 볼 수 있어야 해요.

Datadog 클라이언트 로그 메시지는 [ddtrace]로 표시되므로 다른 메시지와 분리할 수 있어요.

트레이서의 log 속성을 사용해 기본 로거를 재정의하고 사용자 정의 로거로 교체할 수 있어요:

f = File.new("<FILENAME>.log", "w+")           # Log messages should go there
Datadog.configure do |c|
  c.logger.instance = Logger.new(f)                 # Overriding the default tracer
end

Datadog::Tracing.logger.info { "this is typically called by tracing code" }

자세한 내용은 API 문서를 참고하세요.

Go

참고: 이 문서는 Datadog이 모든 사용자에게 권장하는 Go 트레이서 v2를 사용해요. v1을 사용 중이라면 마이그레이션 가이드를 참고해 v2로 업그레이드하세요.

Datadog Go Tracer의 디버그 모드를 활성화하려면 환경 변수 DD_TRACE_DEBUG=true를 설정하거나 Start 구성 중에 디버그 모드를 활성화하세요:

package main

import (
  "github.com/DataDog/dd-trace-go/v2/ddtrace/tracer"
)

func main() {
    tracer.Start(tracer.WithDebugMode(true))
    defer tracer.Stop()
}

버려진 스팬 로그 (Abandoned span logs)

Datadog Go Tracer는 잠재적으로 버려진 스팬에 대한 로깅도 지원해요. Go에서 이 디버그 모드를 활성화하려면 환경 변수 DD_TRACE_DEBUG_ABANDONED_SPANS=true를 설정하세요. 스팬이 버려진 것으로 간주되는 기간(기본값=10m)을 변경하려면 환경 변수 DD_TRACE_ABANDONED_SPAN_TIMEOUT을 원하는 시간으로 설정하세요. 버려진 스팬 로그는 Info 레벨에 표시돼요.

Start 구성 중에도 버려진 스팬 디버깅을 활성화할 수 있어요:

package main

import (
  "time"

  "github.com/DataDog/dd-trace-go/v2/ddtrace/tracer"
)

func main() {
    tracer.Start(tracer.WithDebugSpansMode(10 * time.Minute))
    defer tracer.Stop()
}

Node.js

Datadog Node.js Tracer의 디버그 모드를 활성화하려면 환경 변수 DD_TRACE_DEBUG=true를 사용하세요.

참고: 2.X 미만 버전에서는 트레이서 초기화 내부에서 프로그래밍 방식으로 디버그 모드를 활성화할 수 있었지만 더 이상 지원되지 않아요.

애플리케이션 로그 (Application Logs)

디버그 모드에서 트레이서는 디버그 정보를 console.log()에, 오류를 console.error()에 기록해요. 이 동작은 트레이서에 사용자 정의 로거를 전달해 변경할 수 있어요. 로거에는 각각 메시지와 오류를 처리할 수 있는 debug()와 error() 메서드가 있어야 해요.

예를 들어:

const bunyan = require('bunyan')
const logger = bunyan.createLogger({
  name: 'dd-trace',
  level: 'trace'
})

const tracer = require('dd-trace').init({
  logger: {
    debug: message => logger.trace(message),
    error: err => logger.error(err)
  }
})

그런 다음 Agent 로그를 확인해 문제에 대한 추가 정보가 있는지 살펴보세요:

• 트레이스가 Agent로 제대로 전송되었다면 Response from the Agent: OK 로그 항목이 보여야 해요. 이는 트레이서가 제대로 작동한다는 뜻이므로 문제는 Agent 자체에 있을 수 있어요. 자세한 내용은 Agent 문제 해결 가이드를 참고하세요.
• Agent가 오류를 보고했거나(또는 Agent에 도달할 수 없거나) Error from the Agent 로그 항목이 보일 거예요. 이 경우 네트워크 구성을 검증해 Agent에 도달할 수 있는지 확인하세요. 네트워크가 정상이고 오류가 Agent에서 발생한 것이라고 확신한다면 Agent 문제 해결 가이드를 참고하세요.

이 두 로그 항목이 모두 없다면 Agent로 요청이 전송되지 않았다는 뜻이며, 이는 트레이서가 애플리케이션을 계측하지 않고 있음을 의미해요. 이 경우 Datadog 지원팀에 연락해 플레어와 함께 관련 로그 항목을 제공하세요.

더 많은 트레이서 설정은 API 문서를 확인하세요.

.NET

Datadog .NET Tracer의 디버그 모드를 활성화하려면 DD_TRACE_DEBUG 구성 설정을 true로 설정하세요. 이 설정은 환경 변수, web.config 또는 app.config 파일(.NET Framework만), 또는 datadog.json 파일로 설정할 수 있어요. 또는 GlobalSettings.SetDebugEnabled(true)를 호출해 디버그 모드를 활성화할 수 있어요:

using Datadog.Trace;

// enable debug mode
GlobalSettings.SetDebugEnabled(true);

로그 파일은 기본적으로 다음 디렉터리에 저장돼요. DD_TRACE_LOG_DIRECTORY 설정으로 경로를 변경할 수 있어요.

플랫폼	경로
Windows	%ProgramData%\Datadog .NET Tracer\logs\
Linux	/var/log/datadog/dotnet/
Linux (Kubernetes 라이브러리 주입 사용 시)	/datadog-lib/logs
Azure App Service	%AzureAppServiceHomeDirectory%\LogFiles\datadog

참고: Linux에서 디버그 모드를 활성화하기 전에 로그 디렉터리를 만들어야 해요.

버전 2.19.0부터 DD_TRACE_LOGFILE_RETENTION_DAYS 설정을 사용해 시작 시 현재 로깅 디렉터리에서 로그 파일을 삭제하도록 트레이서를 구성할 수 있어요. 트레이서는 주어진 일수보다 같거나 오래된 로그 파일을 삭제하며 기본값은 32예요.

.NET Tracer 구성 방법에 대한 자세한 내용은 Configuration 섹션을 참고하세요.

이러한 경로에 생성되는 로그에는 두 가지 유형이 있어요:

1. 네이티브 코드 로그: 1.26.0 이상에서 이 로그는 dotnet-tracer-native-<processname>-<processid>.log로 저장돼요. 1.21.0부터 1.25.x까지는 dotnet-tracer-native.log로 저장됐어요. 1.20.x 및 이전 버전에서는 dotnet-profiler.log로 저장되었어요.
2. 관리 코드 로그: 1.21.0 이상에서 이 로그는 dotnet-tracer-managed-<processname>-<date>.log로 저장돼요. 1.20.x 및 이전 버전에서는 dotnet-tracer-<processname>-<date>.log로 저장되었어요.

PHP

Datadog PHP Tracer의 디버그 모드를 활성화하려면 환경 변수 DD_TRACE_DEBUG=true를 설정하세요. 이 환경 변수 값이 트레이서에 의해 제대로 처리되도록 설정해야 하는 방법과 시기에 대한 자세한 내용은 PHP 구성 문서를 참고하세요.

디버그 트레이서 로그를 파일로 라우팅하는 데는 두 가지 옵션이 있어요.

옵션 1:

dd-trace-php 0.98.0+에서 특정 디버그 트레이서 로그에 대해 로그 파일 경로를 지정할 수 있어요:

• 환경 변수: DD_TRACE_LOG_FILE
• INI: datadog.trace.log_file

참고:

• DD_TRACE_LOG_FILE을 어디에 설정해야 하는지에 대한 자세한 내용은 Configuring the PHP SDK를 검토하세요.
• DD_TRACE_LOG_FILE을 지정하지 않으면 로그는 기본 PHP 오류 위치로 이동해요(옵션 2 참조).

옵션 2:

PHP가 error_log 메시지를 어디에 둘지 서버 레벨에서 또는 PHP ini 매개변수(표준 PHP 동작 구성 방식)로 지정할 수 있어요.

Apache 서버를 사용한다면 ErrorLog 지시어를 사용하세요. NGINX 서버를 사용한다면 error_log 지시어를 사용하세요. PHP 레벨에서 구성한다면 PHP의 error_log ini 매개변수를 사용하세요.

C++

릴리스 바이너리 라이브러리는 모두 최적화된 릴리스에 디버그 심볼이 추가되어 컴파일돼요. GDB 또는 LLDB를 사용해 라이브러리를 디버깅하고 코어 덤프를 읽을 수 있어요. 소스에서 라이브러리를 빌드하는 경우 cmake에 -DCMAKE_BUILD_TYPE=RelWithDebInfo 인수를 전달해 디버그 심볼이 포함된 최적화 빌드를 컴파일하세요.

cmake -B .build -DCMAKE_BUILD_TYPE=RelWithDebInfo ..
cmake --build .build -j
cmake --install .build

디버그 로그 검토 (Review debug logs)

트레이서 디버그 모드가 활성화되면 트레이서별 로그 메시지가 트레이서가 어떻게 초기화되었는지, 트레이스가 Agent로 전송되었는지 보고해요. 디버그 로그는 로깅 구성에 따라 별도 경로에 저장돼요. 애플리케이션 레벨 트레이서 정보를 활성화하면 지원되는 언어의 경우 디버그 로그도 플레어로 전송돼요. 다음 로그 예시는 로그 파일에 나타날 수 있는 것을 보여줘요.

이해할 수 없는 오류가 있거나 트레이스가 Datadog으로 플러시되었다고 보고되었지만 Datadog UI에서 볼 수 없다면 Datadog 지원팀에 연락해 플레어와 함께 관련 로그 항목을 제공하세요.

Java:

트레이서의 초기화 로그:

[main] DEBUG datadog.trace.agent.ot.DDTracer - Using config: Config(runtimeId=<runtime ID>, serviceName=<service name>, traceEnabled=true, writerType=DDAgentWriter, agentHost=<IP HERE>, agentPort=8126, agentUnixDomainSocket=null, prioritySamplingEnabled=true, traceResolverEnabled=true, serviceMapping={}, globalTags={env=none}, spanTags={}, jmxTags={}, excludedClasses=[], headerTags={}, httpServerErrorStatuses=[512, 513, 514, 515, 516, 517, 518, 519, 520, 521, 522, 523, 524, 525, 526, 527, 528, 529, 530, 531, 532, 533, 534, 535, 536, 537, 538, 539, 540, 541, 542, 543, 544, 545, 546, 547, 548, 549, 550, 551, 552, 553, 554, 555, 556, 557, 558, 559, 560, 561, 562, 563, 564, 565, 566, 567, 568, 569, 570, 571, 572, 573, 574, 575, 576, 577, 578, 579, 580, 581, 582, 583, 584, 585, 586, 587, 588, 589, 590, 591, 592, 593, 594, 595, 596, 597, 598, 599, 500, 501, 502, 503, 504, 505, 506, 507, 508, 509, 510, 511], httpClientErrorStatuses=[400, 401, 402, 403, 404, 405, 406, 407, 408, 409, 410, 411, 412, 413, 414, 415, 416, 417, 418, 419, 420, 421, 422, 423, 424, 425, 426, 427, 428, 429, 430, 431, 432, 433, 434, 435, 436, 437, 438, 439, 440, 441, 442, 443, 444, 445, 446, 447, 448, 449, 450, 451, 452, 453, 454, 455, 456, 457, 458, 459, 460, 461, 462, 463, 464, 465, 466, 467, 468, 469, 470, 471, 472, 473, 474, 475, 476, 477, 478, 479, 480, 481, 482, 483, 484, 485, 486, 487, 488, 489, 490, 491, 492, 493, 494, 495, 496, 497, 498, 499], httpClientSplitByDomain=false, partialFlushMinSpans=1000, runtimeContextFieldInjection=true, propagationStylesToExtract=[DATADOG], propagationStylesToInject=[DATADOG], jmxFetchEnabled=true, jmxFetchMetricsConfigs=[], jmxFetchCheckPeriod=null, jmxFetchRefreshBeansPeriod=null, jmxFetchStatsdHost=null, jmxFetchStatsdPort=8125, logsInjectionEnabled=false, reportHostName=false)

트레이스 생성 예시:

[http-nio-8080-exec-1] DEBUG datadog.trace.agent.ot.DDSpan - Finished: DDSpan [ t_id=<trace id>, s_id=<span id>, p_id=<parent id>] trace=SpringBoot_Service/OperationHandler.handle/OperationHandler.handle metrics={} tags={component=spring-web-controller, env=none, span.kind=server, thread.id=33, thread.name=http-nio-8080-exec-1}, duration_ns=92808848
[http-nio-8080-exec-1] DEBUG datadog.trace.agent.ot.PendingTrace - traceId: <trace id> -- Expired reference. count = 1
[http-nio-8080-exec-1] DEBUG datadog.trace.agent.ot.DDSpan - Finished: DDSpan [ t_id=<trace id>, s_id=<span id>, p_id=0] trace=SpringBoot_Service/servlet.request/GET /actuator/prometheus metrics={_sampling_priority_v1=1} tags={component=java-web-servlet, env=none, http.method=GET, http.status_code=200, http.url=http://<IP>:8080/actuator/prometheus, language=jvm, peer.hostname=<IP>, peer.ipv4=<IP>, peer.port=50778, runtime-id=<runtime id>, span.kind=server, span.origin.type=org.apache.catalina.core.ApplicationFilterChain, thread.id=33, thread.name=http-nio-8080-exec-1}, duration_ns=157972901
[http-nio-8080-exec-1] DEBUG datadog.trace.agent.ot.PendingTrace - Writing 2 spans to DDAgentWriter { api=DDApi { tracesUrl=http://<IP address>/v0.4/traces } }.

트레이스가 Datadog Agent로 전송됨:

[http-nio-8080-exec-1] DEBUG datadog.trace.agent.ot.PendingTrace - traceId: <trace id> -- Expired reference. count = 0
[dd-trace-writer] DEBUG datadog.trace.agent.common.writer.DDApi - Successfully sent 1 of 2 traces to the DD agent.

Python:

Python Tracer가 생성한 로그는 로깅 핸들러 이름이 ddtrace예요.

트레이스 생성:

<YYYY-MM-DD> 19:51:22,262 DEBUG [ddtrace.internal.processor.trace] [trace.py:211] - trace <TRACE ID> has 8 spans, 7 finished

Python 트레이서가 생성한 스팬:

<YYYY-MM-DD> 19:51:22,251 DEBUG [ddtrace.tracer] [tracer.py:715] - finishing span name='flask.process_response' id=<SPAN ID> trace_id=<TRACE ID>  parent_id=<PARENT ID> service='flask' resource='flask.process_response' type=None start=1655495482.2478693 end=1655495482.2479873 duration=0.000118125 error=0 tags={} metrics={} (enabled:True)
0.0:5050/

트레이스가 Datadog Agent로 전송됨:

<YYYY-MM-DD> 19:59:19,657 DEBUG [ddtrace.internal.writer] [writer.py:405] - sent 1.57KB in 0.02605s to http://localhost:8126/v0.4/traces

트레이스가 Datadog Agent로 전송 실패:

<YYYY-MM-DD> 19:51:23,249 ERROR [ddtrace.internal.writer] [writer.py:567] - failed to send traces to Datadog Agent at http://localhost:8126/v0.4/traces

Ruby:

스팬 생성:

D, [<YYYY-MM-DD>T16:42:51.147563 #476] DEBUG -- ddtrace: [ddtrace] (/usr/local/bundle/gems/ddtrace-<version>/lib/ddtrace/tracer.rb:371:in `write') Writing 4 spans (enabled: true)

 Name: rack.request
Span ID: <span id>
Parent ID: 0
Trace ID: <trace id>
Type: web
Service: todo
Resource: NotesController#index
Error: 0
Start: <start time>
End: <end time>
Duration: 11985000
Allocations: 1202
Tags: [
   system.pid => 476,
   env => dev,
   language => ruby,
   http.method => GET,
   http.url => /notes,
   http.base_url => http://0.0.0.0:3000,
   http.status_code => 304,
   http.response.headers.x_request_id => <header value>]
Metrics: [
   ..],

Go:

Agent로 트레이스 제출 시도:

YYYY/MM/DD 16:06:35 Datadog Tracer <version> DEBUG: Sending payload: size: <size of traces> traces: <number of traces>.

트레이스가 Agent로 전송 실패:

2019/08/07 16:12:27 Datadog Tracer <version> ERROR: lost <number of traces> traces: Post http://localhost:8126/v0.4/traces: dial tcp 127.0.0.1:8126: connect: connection refused, 4 additional messages skipped (first occurrence: DD MM YY 16:11 UTC)

Node.js:

트레이스 전송 문제:

{
	"name": "dd-trace",
	"hostname": "<hostname>",
	"pid": 28817,
	"level": 50,
	"err": {
		"message": "Network error trying to reach the agent: connect ECONNREFUSED 127.0.0.1:8126",
		"name": "Error",
		"stack": "Error: Network error trying to reach the agent: connect ECONNREFUSED 127.0.0.1:8126\n    at ClientRequest.req.on.e (/path/to/dd-trace/src/platform/node/request.js:44:33)\n    at scope.activate (/path/to/dd-trace/packages/dd-trace/src/scope/base.js:68:19)\n    at Scope._activate (/path/to/dd-trace/packages/dd-trace/src/scope/base.js:44:14)\n    at Scope.activate (/path/to/dd-trace/packages/dd-trace/src/scope/base.js:13:17)\n    at ClientRequest.<anonymous> (/path/to/dd-trace/packages/dd-trace/src/scope/base.js:67:20)\n    at ClientRequest.emit (events.js:193:13)\n    at ClientRequest.req.emit (/path/to/dd-trace/packages/datadog-plugin-http/src/client.js:93:21)\n    at Socket.socketErrorListener (_http_client.js:397:9)\n    at Socket.emit (events.js:198:15)\n    at emitErrorNT (internal/streams/destroy.js:91:8)"
	},
	"msg": "Network error trying to reach the agent: connect ECONNREFUSED 127.0.0.1:8126",
	"time": "2019-08-06T20:48:27.769Z",
	"v": 0
}

.NET:

네이티브 코드 로그:

[dotnet] 19861: [debug] JITCompilationStarted: function_id=<function id> token=<token id> name=System.Net.Http.Headers.HttpHeaders.RemoveParsedValue()

스팬이 생성되었음을 보여주는 관리 코드 로그:

{ MachineName: ".", ProcessName: "dotnet", PID: <process id>, AppDomainName: "test-webapi" }
YYYY-MM-DD HH:MM:SS.<integer> +00:00 [DBG] Span started: [s_id: <span id>, p_id: <parent span id>, t_id: <trace id>]
{ MachineName: ".", ProcessName: "dotnet", PID: <process id>, AppDomainName: "test-webapi" }
YYYY-MM-DD HH:MM:SS.<integer> +00:00 [DBG] Span closed: [s_id: <span id>, p_id: <parent span id>, t_id: <trace id>] for (Service: test-webapi, Resource: custom, Operation: custom.function, Tags: [<span tags>])

트레이스를 Datadog Agent로 보낼 수 없음을 보여주는 관리 코드 로그:

YYYY-MM-DD HH:MM:SS.<integer> +00:00 [ERR] An error occurred while sending traces to the agent at System.Net.Http.HttpRequestException: Connection refused ---> System.Net.Sockets.SocketException: Connection refused
   at System.Net.Http.ConnectHelper.ConnectAsync(String host, Int32 port, CancellationToken cancellationToken)
   --- End of inner exception stack trace ---

PHP:

통합 로드:

참고: 이 로그는 DD_TRACE_LOG_FILE(ini: datadog.trace.log_file)을 따르지 않으며 항상 ErrorLog 지시어로 라우팅돼요.

[Mon MM  DD 19:56:23 YYYY] [YYYY-MM-DDT19:56:23+00:00] [ddtrace] [debug] - Loaded integration web

스팬 정보:

0.98.0부터 사용 가능:

[Mon MM  DD 19:56:23 YYYY] [YYYY-MM-DDT19:56:23+00:00] [ddtrace] [span] Encoding span <SPAN ID>: trace_id=<TRACE ID>, name='wpdb.query', service='wordpress', resource: '<RESOURCE NAME>', type 'sql' with tags: component='wordpress'; and metrics: -

트레이스 전송 시도:

[Mon MM  DD 19:56:23 YYYY] [YYYY-MM-DDT19:56:23+00:00] [ddtrace] [info] Flushing trace of size 56 to send-queue for http://datadog-agent:8126

더 알아보기 (Learn more)

• APM 연결 오류 문제 해결하기