DDTrace를 Guance로 보내는 방법: 설정·확인·롤백

Guance를 검토하기 위해 기존 DDTrace 계측부터 다시 만들 필요는 없습니다. 가장 작은 가역 경로는 현재 DDTrace SDK 또는 Java Agent를 그대로 두고, 위험이 낮은 비운영 서비스 하나의 Trace destination만 DataKit DDTrace receiver로 바꾸는 것입니다. 그 다음 같은 테스트 요청을 Guance에서 찾고, 합의한 검증 항목이 실패하면 기록해 둔 원래 destination으로 되돌린 뒤 기존 backend에 새 Trace가 다시 들어오는지 확인합니다.

이 DDTrace Canary가 바꾸는 것과 바꾸지 않는 것

이번 실험에서 바꾸는 것은 테스트 서비스 하나의 Trace destination뿐입니다. 애플리케이션은 기존 DDTrace library와 계측을 유지하고, DataKit이 DDTrace protocol의 span을 받아 선택한 Guance workspace로 보냅니다.

TrueWatch DDTrace collector 문서와 Guance DDTrace 문서에는 혼동하기 쉬운 세 경로가 구분되어 있습니다.

DataKit의 ddtrace collector는 Trace를 수신합니다. Profiling은 별도 collector가 필요하고, runtime metric과 JMX는 StatsD 또는 별도 integration이 필요할 수 있습니다. 따라서 Trace 하나가 보였다는 사실은 Trace 경로만 검증하며, 두 platform의 기능 동등성을 입증하지 않습니다.

한국 환경에서 사용하는 가역 평가 경로

첫 평가는 다음 경계를 지켜야 합니다.

관련 가이드Datadog 대안 6가지 비교: 비용·리전·지원 (2026)→

1. 비운영 Canary 서비스 하나만 선택합니다.
2. 기존 DDTrace SDK 또는 Agent는 그대로 둡니다.
3. 그 서비스의 Trace destination만 내부에서 접근 가능한 DataKit receiver로 바꿉니다.
4. service, env, version, propagation, sampling 조건을 비교 기간 동안 고정합니다.
5. receiver, upload, Guance UI를 각각 검증하고 stop condition이 발생하면 원래 destination을 복구합니다.

이 경로를 dual write라고 부르면 안 됩니다. 일반 DDTrace tracer가 동일 payload를 두 backend에 독립적으로 전달한다고 가정하지 않습니다. 나중에 병렬 전송이 필요하면, 서비스가 OTLP를 내보내는 별도 단계에서 OpenTelemetry Collector의 queue, retry, egress, ingestion 비용과 실패 경로를 따로 설계해야 합니다.

기존 Agent endpoint 전환과 현재 호환성 공개 자료에 명시되지 않음을 구분하기

공식 DataKit 문서는 기존 DDTrace SDK 또는 Agent가 Agent-compatible Trace endpoint로 전송하는 경우 DD_AGENT_HOST와 DD_TRACE_AGENT_PORT=9529를 명시하는 좁은 receiver-switch 경로를 설명합니다. 하지만 이것이 현재 모든 DDTrace tracer, 언어, version, remote configuration, transport option, encoding과 자동으로 호환된다는 뜻은 아닙니다.

Datadog Python tracer 설정 문서는 DD_TRACE_AGENT_URL이 설정된 경우 host와 port 조합보다 우선할 수 있음을 설명합니다. 현재 Python, Java, Node.js 문서는 Trace Agent port에 DD_TRACE_AGENT_PORT를 사용합니다. 오래된 예제의 DD_AGENT_PORT를 복사하지 말고, Canary에 실제로 설치된 Datadog language library 문서에서 변수명과 우선순위를 다시 확인합니다.

설정 파일에 새 destination을 추가해도 더 높은 우선순위의 기존 URL, admission injection 또는 remote configuration이 남아 있으면 실행 중인 process는 예상과 다른 곳으로 보낼 수 있습니다. 배포 manifest만 보지 말고 최종 process와 effective environment를 확인해야 합니다.

첫 서비스를 정하고 Stop Condition부터 합의하기

독립적으로 재시작할 수 있고 downstream dependency 하나 이상을 호출하는 비운영 서비스를 선택합니다. staging의 login, catalogue 또는 checkout API처럼 정상 요청과 안전한 test-error 요청을 모두 만들 수 있는 서비스가 적합합니다. 실제 고객 데이터나 production fault를 사용하지 않습니다.

다음 중 하나라도 발생하면 확장을 멈추고 rollback합니다.

• public ingress 또는 과도하게 넓은 firewall rule 없이는 Canary가 DataKit에 도달할 수 없음
• startup, error rate 또는 request latency가 팀이 사전에 정한 허용 범위를 벗어남
• 예상한 entry span이나 downstream span이 없고 이유를 설명할 수 없음
• sampling 또는 filtering 차이 때문에 두 기간을 비교할 수 없음
• Trace attribute에 credential, request body 또는 개인정보가 노출됨
• 기존 destination을 승인된 change window 안에 복구할 수 없음
• DataKit receiver 또는 DataWay upload error가 테스트 중 계속 증가함

“5분 기다렸더니 보였다”는 성공 기준이 아닙니다. batch, network distance, buffer와 부하는 환경마다 다릅니다. 자체 환경의 평상시 도착 지연을 먼저 측정하고 같은 조건에서 비교합니다.

Destination을 바꾸기 전에 현재 상태 기록하기

Rollback은 기억이 아니라 정확한 baseline에 의존합니다. 값이 없으면 추측해서 채우지 말고 unset이라고 기록합니다.

전체 environment를 ticket이나 CI log에 출력하지 않습니다. 필요한 비밀이 아닌 변수만 개별적으로 확인합니다. env 전체 또는 DD_ prefix 전체를 출력하면 관련 없는 API key나 credential이 노출될 수 있습니다. 이 문서의 예제에는 실제 API key, Token 또는 password가 없습니다.

DataKit DDTrace receiver 활성화하기

Host 설치에서는 DataKit conf.d/samples의 ddtrace.conf.sample을 복사해 ddtrace.conf로 관리하는 방식이 문서화되어 있습니다. 최소 receiver 설정은 호환 endpoint를 그대로 유지합니다.

[[inputs.ddtrace]]
  endpoints = ["/v0.3/traces", "/v0.4/traces", "/v0.5/traces"]

  # 안정적이고 필요한 low-cardinality field만 승격한다.
  # customer_tags = ["team", "deployment.region"]

단순해 보이게 만들기 위해 endpoint version을 제거하지 않습니다. 또한 receiver-side sampling을 사용하지 않는다면 불완전한 [inputs.ddtrace.sampler] table을 남기지 않습니다. 공식 collector 문서의 sample 설정에는 rate가 빠진 sampler가 Trace를 모두 버릴 수 있다는 경고가 있으므로, sampling을 의도하지 않았다면 table 자체를 제거합니다.

정상 DataKit 운영 절차로 설정을 반영한 뒤 영향을 받는 DataKit instance만 재시작하고, ddtrace input이 enabled 상태이며 새 startup error가 없는지 확인합니다. DataKit Monitor에서 지원하는 확인 방식은 다음과 같습니다.

datakit monitor --input ddtrace

특정 screenshot을 성공 기준으로 삼지 않습니다. DataKit version, input 상태, error count 변화, 테스트 시간 구간을 기록합니다.

9529 Port는 필요한 Workload에만 노출하기

DataKit HTTP listener는 기본적으로 localhost:9529에서 대기합니다. tracer와 DataKit이 같은 host에 있으면 이 경로를 사용할 수 있습니다. 다른 Pod 또는 host에서 접근해야 한다면 도달 가능한 listener가 필요합니다.

[http_api]
  listen = "0.0.0.0:9529"

0.0.0.0은 security policy가 아닙니다. Kubernetes Service와 NetworkPolicy, security group, host firewall 또는 동등한 내부 제어로 source를 제한합니다. Trace receiver를 public Internet에 직접 노출하지 않습니다. 같은 HTTP service가 다른 DataKit API도 제공할 수 있으므로, 넓은 ingress rule은 이 테스트보다 큰 공격 표면을 만듭니다.

Kubernetes에서는 selector를 명시한 private ClusterIP Service를 우선 검토합니다. 다음 fragment는 예시이며 실제 DataKit 배포의 label과 namespace에 맞춰야 합니다.

apiVersion: v1
kind: Service
metadata:
  name: datakit-trace
  namespace: observability
spec:
  type: ClusterIP
  selector:
    app: datakit
  ports:
    - name: datakit-http
      port: 9529
      targetPort: 9529

Trace destination을 바꾸기 전에 Canary network context에서 DNS와 HTTP 도달성을 확인합니다.

curl --fail --silent --show-error \
  --output /dev/null --write-out '%{http_code}\n' \
  http://datakit-trace.observability.svc.cluster.local:9529/v1/ping

Health response는 HTTP service가 도달 가능하다는 뜻일 뿐, DDTrace collector가 span을 수신했다는 증거는 아닙니다. 응답을 얻기 위해 network control을 약화하지 않습니다.

Canary 서비스 하나를 DataKit으로 보내기

실행 중인 tracer version이 지원하는 destination 형식 중 하나만 선택합니다. host/port 형식과 URL 형식을 동시에 설정하지 않습니다.

export DD_AGENT_HOST="datakit-trace.observability.svc.cluster.local"
export DD_TRACE_AGENT_PORT="9529"

  # 기존 identity와 SDK sampling은 바꾸지 않는다.
export DD_SERVICE="<existing-service>"
export DD_ENV="<existing-env>"
export DD_VERSION="<existing-version>"

  # 승인된 기존 command 또는 deployment로 애플리케이션을 시작한다.

해당 tracer가 URL 형식을 지원하고 그 형식을 사용하기로 결정했다면 다음처럼 설정합니다.

export DD_TRACE_AGENT_URL="http://datakit-trace.observability.svc.cluster.local:9529"
export DD_SERVICE="<existing-service>"
export DD_ENV="<existing-env>"
export DD_VERSION="<existing-version>"

  # 승인된 기존 command 또는 deployment로 애플리케이션을 시작한다.

비교 중 service, env, version과 기존 SDK sampling rule을 고정합니다. Backend 전환과 동시에 이름이나 sampling을 바꾸면 누락 원인이 destination인지 검색·그룹화·sampling 차이인지 구분할 수 없습니다. 100% sampling이 필요하다면 낮은 traffic의 별도 실험으로 승인하고 기록합니다.

Tracer가 실제로 Load되었는지 확인하기

Receiver가 reachable하다는 사실만으로 application이 tracer를 load했다는 뜻은 아닙니다. template이 아니라 최종 runtime command를 확인합니다.

• Java: 실제 JVM command에서 승인된 -javaagent가 -jar보다 앞에 있는지 확인합니다.
• Node.js: dd-trace가 instrumented module보다 먼저 초기화되는지 확인합니다. injection을 사용한다면 실행 중인 container의 NODE_OPTIONS를 확인합니다.
• Python: 기존 ddtrace-run 또는 framework integration을 유지합니다. ddtrace-run --info는 설정 확인에 도움을 주지만 end-to-end Trace를 대체하지 않습니다.

Guance Operator injection의 annotation 또는 설정 변경은 새로 생성된 Pod에 적용됩니다. Canary Pod만 rollout 또는 재생성하고 effective runtime 설정을 확인합니다. 실행 중인 기존 Pod가 자동으로 바뀐다고 가정하지 않습니다.

안전한 정상 Trace와 알려진 Error Trace 만들기

고객 식별자가 없는 staging endpoint, synthetic transaction 또는 test fixture를 사용합니다. Sampling 동작을 볼 수 있을 만큼 요청하되, 실수로 load test를 만들지 않습니다.

for attempt in 1 2 3 4 5; do
  curl --fail --silent --show-error \
    "https://staging.example.test/health/trace-canary?attempt=${attempt}" \
    --output /dev/null
done

그 다음 예상 status와 downstream call이 알려진 승인된 test-error 경로를 한 번 호출합니다. 변경 기록에는 요청 시간, 예상 HTTP status, 예상 entry resource, 예상 downstream service만 남기고 payload나 개인정보는 남기지 않습니다.

• 정상 요청은 일반 entry span과 topology를 확인합니다.
• 통제된 error는 error 분류와 normal sampling과 다른 보존 동작을 확인합니다.
• downstream call은 propagation과 parent-child 관계를 확인합니다.

Receiver, Upload, Guance UI를 따로 검증하기

“Trace가 보였다”라는 한 문장으로 세 failure domain을 합치지 않습니다.

1. DataKit receiver

datakit monitor --input ddtrace와 DataKit 운영 log에서 input이 enabled 상태이고 요청 구간에 새 error가 누적되지 않는지 확인합니다. 필요하면 Guance no-data troubleshooting을 사용해 startup, collector, listener, time, network, DataWay 문제를 분리합니다.

2. DataKit에서 선택한 Guance site까지

DataKit architecture 문서는 local collector, DataWay, Guance center를 분리합니다. Local receiver가 healthy해도 upload 성공을 보장하지 않습니다. Workspace credential을 증거에 복사하지 말고 DataWay egress, proxy, time synchronization, queue와 error signal을 확인합니다.

3. Guance Trace Explorer

의도한 workspace와 시간 범위에서 Guance Trace Explorer를 열고, 변경 전에 기록한 정확한 Canary identity로 필터링합니다.

최소 합격 증거는 다음과 같습니다.

• 테스트 구간에 비어 있지 않은 Trace ID가 하나 이상 존재
• service, env, version이 실제 emitted identity와 일치
• entry span에서 resource, duration, status, error 상태 확인 가능
• 알려진 downstream 관계가 존재하거나 누락 이유를 설명 가능
• 통제된 error를 error Trace로 찾을 수 있음
• 테스트 요청 동안 SDK와 receiver sampling rule이 바뀌지 않음

URL, 고객 식별자 또는 request attribute가 포함된 원본 screenshot을 그대로 공유하지 않습니다. Sanitised evidence reference를 남깁니다. 양쪽의 요청 집합과 sampling 조건이 같지 않다면 단순 Trace count는 비교 증거가 아닙니다.

설정을 무작위로 바꾸지 말고 Layer별로 배제하기

한 번에 변수 하나만 바꿉니다. 세 설정을 동시에 바꾼 뒤 Trace가 나타나면 무엇이 원인이었는지 알 수 없고, 동일한 rollback을 신뢰할 수 없습니다.

DDTrace와 OpenTelemetry 서비스의 Trace Context 유지하기

Mixed environment에서는 수신은 성공하지만 topology가 끊길 수 있습니다. Datadog Trace Context Propagation 문서는 Datadog, W3C tracecontext, B3 관련 설정을 설명하지만, 지원 default와 environment variable은 언어와 version에 따라 달라질 수 있습니다.

DataKit에는 DDTrace와 OpenTelemetry 경로를 연결하기 위한 설정이 있습니다.

[[inputs.ddtrace]]
  endpoints = ["/v0.3/traces", "/v0.4/traces", "/v0.5/traces"]
  compatible_otel = true
  trace_128_bit_id = true

compatible_otel=true는 span ID와 parent ID의 표현을 OpenTelemetry 연계에 맞추고, trace_128_bit_id는 DDTrace metadata의 상위 bit가 있을 때 전체 ID를 조합하는 데 사용됩니다. 그러나 설정을 켰다는 사실은 호환성 증거가 아닙니다. DDTrace 계측 upstream에서 OpenTelemetry 계측 downstream까지 통과하는 요청 하나를 보내 실제 parent-child chain을 확인합니다.

모든 service의 propagator를 한 번에 바꾸지 않습니다. 한 call path씩 이동하고, 실패하면 이전 inject/extract 설정으로 돌아갈 수 있어야 합니다.

Sampling과 Tag Cardinality를 같은 조건으로 유지하기

SDK sampling과 DataKit receiver sampling은 독립적입니다. SDK가 절반을 남기고 receiver가 남은 절반 중 절반을 남긴다면, 어느 한쪽의 “50% sample”과 같지 않습니다. Error와 rare resource 처리까지 두 layer를 모두 기록합니다.

DataKit DDTrace 문서는 DataKit 1.22.0부터 top-level tag가 필요한 field를 customer_tags allowlist에 넣는 방식을 설명합니다. User ID, request ID, session ID처럼 cardinality가 높은 값은 승격하지 않습니다. 검색할 수 있다는 이유만으로 모든 field를 top-level tag로 만들 필요는 없습니다.

한국에서 Region과 Data Residency를 확인할 때의 경계

Application에서 DataKit까지의 hop은 가능하면 같은 host, cluster 또는 통제된 network segment 안에 둡니다. DataKit에서 DataWay 또는 Guance site로 가는 outbound path는 별도입니다. 다음 항목을 change record에 남깁니다.

관련 가이드한국 Datadog 가격 계산 가이드: AP1 요금과 예시 (2026)→

• Canary workload와 DataKit의 실제 cloud region, cluster, VPC와 network 경계
• DataKit이 사용하는 DataWay 또는 site와 outbound proxy 경로
• 국경 간 전송, 암호화, retention, backup, disaster recovery와 subprocessors에 대한 계약상 요구
• Korea 외 지역으로 전송이 가능한 데이터 범위와 금지된 attribute
• Workspace의 실제 region, SLA, support와 data handling 조건을 승인한 담당자

Datadog Sites 문서는 AP1의 location을 일본으로 표시합니다. 정리하면 Datadog AP1 Japan ≠ Korea입니다. 한국 사용자가 AP1을 사용한다는 사실만으로 한국 내 데이터 저장, 한국 전용 contract 또는 한국 내 processing을 증명할 수 없습니다. 조직이 실제 선택한 Datadog site와 계약 조건을 별도로 확인합니다.

Guance OpenAPI endpoint 목록은 Asia Pacific Region 1을 Singapore로 표시합니다. 마찬가지로 Guance AP1 Singapore ≠ 계약으로 확인된 한국 data residency입니다. 이 공개 label은 한국 계약의 모든 storage와 backup 위치, processing path, feature availability 또는 법적 적합성을 자동으로 증명하지 않습니다. ko-KR locale이나 Singapore endpoint를 근거로 “한국 데이터 국내 보관”이라고 쓰지 않습니다. 계약, regional team, security와 legal review를 통해 확인합니다.

OpenTelemetry는 첫 테스트가 아니라 다음 결정으로 분리하기

DDTrace receiver를 바꾸는 일과 계측을 OpenTelemetry로 다시 만드는 일은 다른 결정입니다. 첫 Canary의 질문은 “현재 DDTrace Trace로 Guance에서 실제 장애 조사 경로를 재현할 수 있는가?”입니다. 이 질문에 답한 뒤에만 DDTrace를 유지할 서비스, OpenTelemetry로 옮길 서비스, collection tier 변경 여부를 정합니다.

OpenTelemetry Collector는 telemetry를 받아 처리하고 exporter로 보낼 수 있으며, Collector configuration은 여러 exporter와 pipeline 구성을 설명합니다. OTLP 단계에서 제한적인 병렬 평가를 만들 수 있지만, queue, retry, egress, ingestion, storage와 failure mode가 추가됩니다. Multiple exporter는 zero-loss delivery나 무료 duplication을 뜻하지 않습니다.

DataKit으로 OTLP를 받을 때는 TrueWatch OpenTelemetry integration에서 실제 DataKit version, protocol, port와 /otel path를 확인합니다. 일반 DDTrace payload를 OTLP endpoint로 보내거나 Preview 기능을 모든 언어의 migration bridge로 취급하지 않습니다.

Rollback은 기존 Datadog 경로의 새 Trace까지 확인해야 끝난다

1. 테스트 전에 저장한 destination, port 또는 URL, sampling과 propagation 설정을 Canary deployment에 복구합니다.
2. 승인된 절차로 Canary 서비스만 재시작하거나 재배포합니다.
3. 기존 backend에서 새 Trace가 도착하고 service, env, version, downstream span이 정상인지 확인합니다.
4. Guance 쪽으로 새 Trace가 더 이상 들어오지 않는지 확인합니다. Buffer에 남은 데이터의 지연은 따로 기록합니다.
5. 기존 경로가 안정된 뒤에만 테스트용 DataKit 설정과 임시 network permission을 정리합니다.

일반적인 Datadog Agent 경로라면 테스트 전 실제 값으로 기록한 host와 DD_TRACE_AGENT_PORT=8126, 또는 기존 DD_TRACE_AGENT_URL이 rollback 기준입니다. Default를 추측하지 말고 실행 중이던 effective value를 복구합니다. DD_TRACE_ENABLED=false는 tracing을 끌 뿐 Datadog으로 다시 보내지 않으므로 기본 rollback 방법이 아닙니다.

Datadog Agent, 기존 설정, dashboard 또는 monitor는 rollback 검증이 끝나기 전에 삭제하지 않습니다. 전체 deployment의 광범위한 rollback을 먼저 실행하면 DDTrace destination과 무관한 변경까지 되돌릴 수 있으므로, destination 변경을 독립된 diff로 관리합니다.

30일 평가에서 확인할 합격 조건

Trace 하나를 본 것만으로 production migration을 결정하지 않습니다. 대표적인 load, error와 deployment를 포함하는 기간에 다음을 설명할 수 있어야 합니다.

설명할 수 없는 항목은 공개 자료에 명시되지 않음으로 남기고 전체 서비스 확장을 중단합니다. 단순히 시간을 더 보내는 것이 아니라 공개 자료에 명시되지 않음을 하나씩 검증해야 합니다.

현재 공개 자료에 명시되지 않음과 이 문서가 하지 않는 주장

아래 항목은 공식 문서 검토만으로 확인되지 않았습니다.

• 한국 사용 환경의 정확한 언어, runtime, DDTrace tracer와 DataKit version 조합
• 각 tracer에서 실제 적용되는 destination 변수 우선순위와 payload compatibility
• Remote configuration, admission injection 또는 custom transport의 영향
• Datadog contract, sampling, retention과 custom setting
• Dashboard, monitor, SLO, security, RUM, Synthetic, log, profiling과 history migration
• Datadog AP1 Japan과 한국 고객 contract의 실제 data handling 조건
• Guance AP1 Singapore label과 한국 고객 contract의 data residency, backup, processing 조건
• SaaS와 private deployment의 feature, SLA와 support 조건 동등성

따라서 이 페이지는 “drop-in replacement”, “완전 호환”, “one-click migration”, “zero downtime”, “no data loss”, “자동 migration”, “기본 dual write” 또는 “항상 더 저렴함”을 주장하지 않습니다. 비용 비교는 workload, signal scope, sampling, retention, region과 반전 사례를 함께 공개하는 별도 가격 페이지에서만 다룹니다.

Datadog 가격 query에 대해 별도로 측정된 데이터는 한국 Datadog 가격 페이지의 owner evidence이며, 이 기술 migration 페이지의 검색 수요로 가져오지 않습니다. 따라서 가격 query의 Volume을 이 페이지의 예상 traffic이나 primary keyword evidence로 사용하지 않습니다.

Alternatives, 가격과 APM 평가로 연결하기

한국 Datadog 평가 cluster의 각 페이지는 역할이 다릅니다.

1. 한국 Datadog 대안 가이드는 어떤 운영 조건에서 대안을 검토할지와 POC 범위를 설명합니다.
2. 한국 Datadog 가격 가이드는 공개 가격, workload input과 계산 경계를 다룹니다.
3. 이 페이지는 기존 DDTrace 계측을 유지한 단일 서비스 Trace Canary, 검증과 rollback만 다룹니다.

세 질문의 증거가 모두 준비되면 Guance APM의 제품 범위와 함께 topology, security, regional requirement, rollout 순서를 검토합니다. Canary 성공은 다음 서비스를 평가할 근거일 뿐, 전체 Datadog platform을 제거할 권한이 아닙니다.

공식 자료와 검증 기록

변경 가능성이 있는 기술 사실은 2026년 8월 1일에 다음 1차 자료와 대조했습니다.

1. TrueWatch Docs — DDTrace — DataKit receiver port, endpoint, listener, collector scope, sampling, tag와 Trace Context 설정.
2. Guance Docs — DDTrace — Guance DataKit DDTrace collector 설정과 environment variable.
3. Datadog Docs — Add the Datadog SDK — 언어별 tracer와 destination 설정 entry point.
4. Datadog Docs — Python Library Configuration — DD_TRACE_AGENT_URL 우선순위 예시.
5. Datadog Docs — Trace Context Propagation — Datadog, W3C와 B3 inject/extract 설정.
6. Datadog Docs — Sites — AP1 location이 일본이라는 공개 표기와 site 독립성.
7. Guance Docs — DataKit Monitor — collector 상태 확인.
8. Guance Docs — DataKit Architecture — collector, DataWay와 Guance center 경계.
9. Guance Docs — No Data Troubleshooting — startup, collector, network와 upload 문제 분리.
10. Guance Docs — Trace Explorer — Guance에서 Trace를 찾고 검증하는 경로.
11. Guance Docs — OpenAPI Endpoints — Asia Pacific Region 1의 Singapore label과 그 label이 증명하지 않는 계약상 범위.
12. OpenTelemetry — Collector와 Collector Configuration — receiver, processor, exporter와 pipeline.
13. TrueWatch Docs — OpenTelemetry — DataKit OTLP port, path와 protocol 제약.

업데이트 기록