OpenTelemetry JAVA¶
OpenTelemetry Java Agent는 JVM -javaagent 파라미터를 통해 런타임에 바이트코드를 삽입합니다. 비즈니스 코드를 수정할 필요 없이 일반적인 Java 웹 프레임워크, HTTP 클라이언트, JDBC, RPC, 메시지 큐 및 JVM Runtime 등의 텔레메트리 데이터를 수집할 수 있습니다.
이 문서에서는 DataKit의 OpenTelemetry 수집기를 사용하여 Trace와 Metric을 수신합니다. 애플리케이션 로그는 로컬 파일에 기록되며, DataKit의 logging 수집기가 이를 읽어 Guance로 전달합니다:
Java 애플리케이션 + OpenTelemetry Java Agent -- OTLP Trace/Metric --> DataKit --> Guance
Java 애플리케이션 -- trace_id/span_id 포함 로그 파일 --> DataKit logging --> Guance
사전 준비 사항¶
- Java 8 이상;
- DataKit이 설치되어 있고, 대상 Guance 워크스페이스에 연결되어 있어야 함;
- Java 애플리케이션에서 DataKit으로 네트워크 접근 가능: OTLP/HTTP는 DataKit HTTP 포트
9529사용, OTLP/gRPC는 기본적으로4317사용; - Java Agent가 대상 프레임워크 또는 컴포넌트에 대해 자동 계측 지원을 제공해야 함.
1. OpenTelemetry 수집기 활성화¶
호스트에 설치된 DataKit¶
DataKit 설치 디렉터리의 conf.d/opentelemetry로 이동합니다. 수집기 설정 파일이 아직 없으면 샘플 파일을 복사합니다:
opentelemetry.conf에 최소한 다음 수신 설정이 포함되어 있는지 확인합니다:
[[inputs.opentelemetry]]
# Guance에서 사용자 정의 속성을 태그로 유지하려면 여기에 화이트리스트를 추가하십시오.
# 속성 이름의 점은 밑줄로 변환됩니다. 예: team.name -> team_name.
customer_tags = ["team", "project"]
[inputs.opentelemetry.http]
http_status_ok = 200
trace_api = "/otel/v1/traces"
metric_api = "/otel/v1/metrics"
[inputs.opentelemetry.grpc]
addr = "127.0.0.1:4317"
max_payload = 16777216
위 설정은 다음 수신 주소를 모두 활성화합니다:
| 프로토콜 | 데이터 유형 | DataKit 수신 주소 |
|---|---|---|
| OTLP/HTTP + Protobuf | Trace | http://<DataKit-IP>:9529/otel/v1/traces |
| OTLP/HTTP + Protobuf | Metric | http://<DataKit-IP>:9529/otel/v1/metrics |
| OTLP/gRPC | Trace, Metric | http://<DataKit-IP>:4317 |
이 문서에서는 OTLP를 통해 애플리케이션 로그를 전송하지 않으므로 logs_api를 설정할 필요가 없습니다. 로그 파일 수집은 3. 로그 수집 및 트레이스 연결에서 설정합니다.
애플리케이션과 DataKit이 동일한 호스트에 있지 않은 경우, gRPC의 addr을 애플리케이션이 접근할 수 있는 수신 주소(예: 0.0.0.0:4317)로 변경해야 합니다. 또한 실제 배포 환경에 맞게 DataKit HTTP 수신 주소, 방화벽 또는 기타 네트워크 액세스 제어를 조정합니다. OTLP 수신 포트를 공용 네트워크에 직접 노출하지 마십시오.
DataKit을 재시작하여 설정을 적용합니다:
DataKit HTTP 서비스에 접근 가능한지 확인합니다:
2. 애플리케이션에 OpenTelemetry 연결¶
Java Agent 다운로드¶
OpenTelemetry 공식 저장소에서 최신 버전의 Java Agent를 다운로드합니다:
sudo mkdir -p /opt/opentelemetry
sudo curl -fL \
https://github.com/open-telemetry/opentelemetry-java-instrumentation/releases/latest/download/opentelemetry-javaagent.jar \
-o /opt/opentelemetry/opentelemetry-javaagent.jar
OpenTelemetry Java Instrumentation 릴리스 페이지에서 사용 가능한 버전을 확인할 수 있습니다. 프로덕션 환경에서는 검증된 Agent 버전을 고정하고, 업그레이드 전에 릴리스 노트를 확인하고 회귀 테스트를 수행하는 것이 좋습니다.
환경 변수로 시작하기¶
다음은 OTLP/HTTP + Protobuf 예시입니다. OTEL_EXPORTER_OTLP_ENDPOINT는 기본 주소이며, Java Agent는 Trace 및 Metric에 대해 자동으로 /v1/traces, /v1/metrics를 추가하여 최종적으로 DataKit의 /otel/v1/* 라우트에 매핑됩니다. 로그는 파일 수집을 통해 처리되므로 OTEL_LOGS_EXPORTER=none으로 유지하여 동일한 로그가 중복 전송되지 않도록 해야 합니다.
export JAVA_TOOL_OPTIONS="-javaagent:/opt/opentelemetry/opentelemetry-javaagent.jar"
export OTEL_SERVICE_NAME="order-service"
export OTEL_RESOURCE_ATTRIBUTES="env=prod,version=1.0.0,team=backend"
export OTEL_TRACES_EXPORTER="otlp"
export OTEL_METRICS_EXPORTER="otlp"
export OTEL_LOGS_EXPORTER="none"
export OTEL_EXPORTER_OTLP_PROTOCOL="http/protobuf"
export OTEL_EXPORTER_OTLP_ENDPOINT="http://127.0.0.1:9529/otel"
export OTEL_PROPAGATORS="tracecontext,baggage"
java -jar app.jar
JAVA_TOOL_OPTIONS는 해당 환경에서 시작되는 모든 JVM에 적용됩니다. 동일한 시작 환경에 다른 Java 프로세스가 있는 경우, 다음 섹션의 명시적 -javaagent 파라미터를 사용하여 잘못된 주입을 방지하는 것이 좋습니다.
JVM 파라미터로 시작하기¶
시스템 속성은 -jar 앞에 위치해야 합니다:
java -javaagent:/opt/opentelemetry/opentelemetry-javaagent.jar \
-Dotel.service.name=order-service \
-Dotel.resource.attributes=env=prod,version=1.0.0,team=backend \
-Dotel.traces.exporter=otlp \
-Dotel.metrics.exporter=otlp \
-Dotel.logs.exporter=none \
-Dotel.exporter.otlp.protocol=http/protobuf \
-Dotel.exporter.otlp.endpoint=http://127.0.0.1:9529/otel \
-Dotel.propagators=tracecontext,baggage \
-jar app.jar
OTLP/gRPC 사용하기¶
OTLP/gRPC로 변경하려면 프로토콜과 주소만 변경하면 됩니다. gRPC 주소에는 /v1/traces와 같은 HTTP 경로를 추가할 수 없습니다:
export OTEL_EXPORTER_OTLP_PROTOCOL="grpc"
export OTEL_EXPORTER_OTLP_ENDPOINT="http://127.0.0.1:4317"
Tomcat¶
<CATALINA_BASE>/bin/setenv.sh에서 환경 변수와 Agent 파라미터를 설정합니다:
export CATALINA_OPTS="$CATALINA_OPTS -javaagent:/opt/opentelemetry/opentelemetry-javaagent.jar"
export OTEL_SERVICE_NAME="order-service"
export OTEL_RESOURCE_ATTRIBUTES="env=prod,version=1.0.0"
export OTEL_TRACES_EXPORTER="otlp"
export OTEL_METRICS_EXPORTER="otlp"
export OTEL_LOGS_EXPORTER="none"
export OTEL_EXPORTER_OTLP_PROTOCOL="http/protobuf"
export OTEL_EXPORTER_OTLP_ENDPOINT="http://127.0.0.1:9529/otel"
저장 후 Tomcat을 재시작합니다. 다른 애플리케이션 서버도 -javaagent를 실제 JVM 시작 파라미터에 추가하고, 동일한 JVM에서 Agent가 한 번만 로드되도록 해야 합니다.
3. 로그 수집 및 트레이스 연결¶
OpenTelemetry Log 방식을 사용하여 애플리케이션 로그를 전송하지 않는 경우, 애플리케이션에서 로그를 로컬 파일에 기록하고 DataKit의 logging 수집기가 파일 로그를 수집하도록 할 수 있습니다. 이 방식을 사용할 때는 OTEL_LOGS_EXPORTER를 none으로 설정하거나 JVM 파라미터로 -Dotel.logs.exporter=none을 설정하여 OpenTelemetry Log Exporter를 비활성화하고, 동일한 로그가 다른 경로를 통해 중복 전송되지 않도록 해야 합니다.
OpenTelemetry Java Agent는 현재 Span의 다음 필드를 Logback 또는 Log4j 로그 이벤트의 MDC(Mapped Diagnostic Context) 복사본에 자동으로 주입합니다:
trace_id: 현재 Trace ID;span_id: 현재 Span ID;trace_flags: W3C Trace Flags.
애플리케이션은 OpenTelemetry 로그 의존성을 추가하거나 비즈니스 코드를 수정할 필요 없이, 로그 형식에서 이러한 MDC 필드를 참조하기만 하면 됩니다. DataKit이 파일에서 로그를 수집한 후 Pipeline을 통해 trace_id와 span_id를 로그 필드로 추출하면, Guance에서 로그와 트레이스를 연결할 수 있습니다.
!!! note
유효한 Span의 컨텍스트에서 생성된 로그만 트레이스 필드를 포함합니다. 애플리케이션 시작 로그, 스케줄러 로그 또는 계측이 적용되지 않은 비동기 작업 로그에는 `trace_id`와 `span_id`가 없을 수 있으며, 이는 정상적인 현상입니다. 필드 이름은 Java Agent가 주입하는 `trace_id`, `span_id`, `trace_flags`를 사용해야 하며, `traceId`로 변경하거나 ID를 수동으로 생성하지 마십시오.
Logback 파일 쓰기¶
Logback 1.0 이상은 Java Agent의 MDC 자동 계측을 지원합니다. 다음 내용을 logback.xml 또는 logback-spring.xml에 추가하고, 실제 환경에 맞게 로그 디렉터리를 수정합니다:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<property name="LOG_DIR" value="/opt/order-service/logs"/>
<property name="LOG_PATTERN"
value="%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} [trace_id=%X{trace_id} span_id=%X{span_id} trace_flags=%X{trace_flags}] - %msg%n"/>
<appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
<file>${LOG_DIR}/application.log</file>
<rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
<fileNamePattern>${LOG_DIR}/application.%d{yyyy-MM-dd}.%i.log.gz</fileNamePattern>
<maxFileSize>100MB</maxFileSize>
<maxHistory>7</maxHistory>
<totalSizeCap>5GB</totalSizeCap>
</rollingPolicy>
<encoder>
<pattern>${LOG_PATTERN}</pattern>
<charset>UTF-8</charset>
</encoder>
</appender>
<root level="INFO">
<appender-ref ref="FILE"/>
</root>
</configuration>
Spring Boot 애플리케이션이 이미 기본 Logback 설정을 사용 중인 경우, application.properties에서 파일 출력을 활성화하고 파일 로그 형식을 재정의할 수도 있습니다:
logging.file.name=/opt/order-service/logs/application.log
logging.pattern.file=%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} [trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags}] - %msg%n
Log4j 2 파일 쓰기¶
Log4j 2.7 이상은 Java Agent의 컨텍스트 데이터 자동 계측을 지원합니다. 다음 내용을 log4j2.xml 또는 log4j2-spring.xml에 추가합니다:
<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="WARN">
<Properties>
<Property name="LOG_DIR">/opt/order-service/logs</Property>
<Property name="LOG_PATTERN">%d{yyyy-MM-dd HH:mm:ss.SSS} [%t] %-5p %c{36} [trace_id=%X{trace_id} span_id=%X{span_id} trace_flags=%X{trace_flags}] - %m%n%throwable</Property>
</Properties>
<Appenders>
<RollingFile name="FILE"
fileName="${LOG_DIR}/application.log"
filePattern="${LOG_DIR}/application.%d{yyyy-MM-dd}.%i.log.gz">
<PatternLayout pattern="${LOG_PATTERN}"/>
<Policies>
<TimeBasedTriggeringPolicy/>
<SizeBasedTriggeringPolicy size="100 MB"/>
</Policies>
<DefaultRolloverStrategy max="7"/>
</RollingFile>
</Appenders>
<Loggers>
<Root level="info">
<AppenderRef ref="FILE"/>
</Root>
</Loggers>
</Configuration>
위 두 설정 모두 생성되는 로그의 첫 번째 줄 형식은 동일합니다. 예를 들면:
2026-08-12 10:20:30.123 [http-nio-8080-exec-1] INFO c.e.OrderController [trace_id=4bf92f3577b34da6a3ce929d0e0e4736 span_id=00f067aa0ba902b7 trace_flags=01] - order created
DataKit 파일 수집 설정¶
애플리케이션이 있는 호스트에 /usr/local/datakit/conf.d/logging/java_otel.conf를 생성합니다:
[[inputs.logging]]
logfiles = ["/opt/order-service/logs/*.log"]
source = "java"
service = "order-service"
pipeline = "java_otel.p"
character_encoding = "utf-8"
# Java 예외 스택 트레이스를 해당 로그에 병합합니다. 날짜로 시작하는 행을 새 로그로 간주합니다.
enable_multiline = true
multiline_match = '''^\d{4}-\d{2}-\d{2}'''
remove_ansi_escape_codes = true
from_beginning = false
[inputs.logging.tags]
env = "prod"
version = "1.0.0"
service, env, version은 Java Agent의 OTEL_SERVICE_NAME 및 OTEL_RESOURCE_ATTRIBUTES와 일치해야 합니다. 또한 DataKit 실행 사용자는 로그 디렉터리에 대한 탐색 권한이 있어야 하며, 로그 파일에 대한 읽기 권한이 있어야 합니다.
그런 다음 /usr/local/datakit/pipeline/java_otel.p를 생성합니다:
grok(_, "%{TIMESTAMP_ISO8601:time} \\[%{DATA:thread_name}\\] %{LOGLEVEL:status}%{SPACE}%{NOTSPACE:class_name} \\[trace_id=%{DATA:trace_id} span_id=%{DATA:span_id} trace_flags=%{DATA:trace_flags}\\] - %{GREEDYDATA:msg}")
default_time(time)
이 Pipeline은 MDC의 값을 로그 최상위 필드 trace_id, span_id, trace_flags로 추출합니다. trace_id와 span_id는 Guance에서 로그와 트레이스를 연결하는 데 필요한 핵심 필드입니다.
DataKit을 재시작하여 로그 수집 설정과 Pipeline을 적용합니다:
로그 파일 경로, 로그 형식 또는 필드 순서가 변경되면 logfiles, multiline_match 및 Pipeline 규칙을 함께 수정해야 합니다. 파일 수집 옵션에 대한 자세한 내용은 DataKit 로그 수집을 참조하십시오.
4. 데이터 전송 파라미터¶
Java Agent는 환경 변수, JVM 시스템 속성 및 설정 파일을 지원합니다. 우선 순위는 높은 순서부터 JVM 시스템 속성, 환경 변수, 설정 파일입니다. 시스템 속성을 환경 변수로 변환할 때는 이름을 대문자로 바꾸고 .와 -를 _로 대체합니다. 예를 들어 otel.service.name은 OTEL_SERVICE_NAME에 해당합니다.
기본 파라미터¶
| 환경 변수 | JVM 시스템 속성 | 설명 | 권장 값 또는 예시 |
|---|---|---|---|
OTEL_SERVICE_NAME |
otel.service.name |
서비스 이름; 설정되지 않은 경우 기본값은 unknown_service:java입니다. |
order-service, 프로덕션 환경에서는 명시적으로 설정해야 합니다. |
OTEL_RESOURCE_ATTRIBUTES |
otel.resource.attributes |
리소스 속성, 쉼표로 구분된 key=value 형식. |
env=prod,version=1.0.0,team=backend |
OTEL_TRACES_EXPORTER |
otel.traces.exporter |
Trace 내보내기 도구. | DataKit으로 전송할 때는 otlp로 설정; 비활성화 시 none으로 설정. |
OTEL_METRICS_EXPORTER |
otel.metrics.exporter |
Metric 내보내기 도구. | JVM/Runtime 메트릭을 전송할 때는 otlp로 설정; 비활성화 시 none으로 설정. |
OTEL_LOGS_EXPORTER |
otel.logs.exporter |
로그 내보내기 도구. | 이 문서에서는 DataKit이 로그 파일을 수집하므로, 중복 전송을 방지하기 위해 고정적으로 none으로 설정. |
OTEL_PROPAGATORS |
otel.propagators |
서비스 간 컨텍스트 전파 형식. | 기본값 tracecontext,baggage; 전체 트레이스에서 호환성을 유지해야 함. |
OTEL_SDK_DISABLED |
otel.sdk.disabled |
OpenTelemetry SDK 비활성화. | 기본값 false. 긴급 차단 시 true로 설정. |
OTEL_JAVAAGENT_ENABLED |
otel.javaagent.enabled |
Java Agent 비활성화 또는 활성화. | 기본값 true. |
OTEL_JAVAAGENT_CONFIGURATION_FILE |
otel.javaagent.configuration-file |
Java Agent properties 설정 파일 경로. | /etc/otel/otel.properties |
service.name은 Guance에서 서비스 소속을 식별하는 데 사용됩니다. env와 version도 함께 설정하여 환경 및 버전별로 필터링할 수 있도록 권장합니다. 다른 사용자 정의 리소스 속성은 DataKit customer_tags 화이트리스트에 추가해야 태그로 유지되며, 속성 이름의 .는 _로 변환됩니다.
OTLP 파라미터¶
| 환경 변수 | JVM 시스템 속성 | 설명 | 권장 값 또는 예시 |
|---|---|---|---|
OTEL_EXPORTER_OTLP_PROTOCOL |
otel.exporter.otlp.protocol |
모든 신호의 OTLP 프로토콜. | http/protobuf 또는 grpc. Java Agent 2.x는 기본적으로 http/protobuf를 사용하지만, 명시적으로 설정하는 것이 좋습니다. |
OTEL_EXPORTER_OTLP_ENDPOINT |
otel.exporter.otlp.endpoint |
모든 신호에 공통으로 사용되는 기본 주소. | HTTP: http://datakit-host:9529/otel; gRPC: http://datakit-host:4317. |
OTEL_EXPORTER_OTLP_TRACES_ENDPOINT |
otel.exporter.otlp.traces.endpoint |
Trace에만 사용되는 주소, 공통 주소보다 우선. | HTTP: http://datakit-host:9529/otel/v1/traces. |
OTEL_EXPORTER_OTLP_METRICS_ENDPOINT |
otel.exporter.otlp.metrics.endpoint |
Metric에만 사용되는 주소, 공통 주소보다 우선. | HTTP: http://datakit-host:9529/otel/v1/metrics. |
OTEL_EXPORTER_OTLP_HEADERS |
otel.exporter.otlp.headers |
모든 OTLP 요청에 포함되는 요청 헤더, 여러 값은 쉼표로 구분. | x-tenant=tenant-a; DataKit expected_headers와 일치해야 함. |
OTEL_EXPORTER_OTLP_COMPRESSION |
otel.exporter.otlp.compression |
OTLP 요청 압축 방식. | 호스트 간 전송 시 gzip으로 설정 가능. |
OTEL_EXPORTER_OTLP_TIMEOUT |
otel.exporter.otlp.timeout |
단일 내보내기 타임아웃, 단위 밀리초. | 기본값 10000. |
통합 endpoint와 특정 데이터 유형의 endpoint가 동시에 존재하는 경우, 특정 데이터 유형의 설정이 우선합니다. 예를 들어 OTEL_EXPORTER_OTLP_TRACES_ENDPOINT가 설정되면 Trace는 더 이상 OTEL_EXPORTER_OTLP_ENDPOINT를 사용하지 않습니다.
DataKit의 OTLP/HTTP 수집은 Protobuf만 지원하므로 http/protobuf를 사용하고 http/json은 사용하지 마십시오. HTTP의 통합 endpoint를 사용할 때는 http://<DataKit-IP>:9529/otel로 설정해야 합니다. 특정 데이터 유형의 독립 endpoint를 설정하는 경우, /otel/v1/<signal> 전체 경로를 포함해야 합니다.
샘플링 및 배치 전송 파라미터¶
| 환경 변수 | JVM 시스템 속성 | 설명 | 기본값 또는 예시 |
|---|---|---|---|
OTEL_TRACES_SAMPLER |
otel.traces.sampler |
Trace 헤더 샘플러. | 기본값 parentbased_always_on; 비율 샘플링은 parentbased_traceidratio 사용 가능. |
OTEL_TRACES_SAMPLER_ARG |
otel.traces.sampler.arg |
샘플러 파라미터. | 0.1은 루트 Trace의 10%를 샘플링함을 의미. |
OTEL_BSP_SCHEDULE_DELAY |
otel.bsp.schedule.delay |
Span 배치 내보내기 간격, 단위 밀리초. | 기본값 5000. |
OTEL_BSP_MAX_QUEUE_SIZE |
otel.bsp.max.queue.size |
내보낼 Span 대기열 상한. | 기본값 2048. |
OTEL_BSP_MAX_EXPORT_BATCH_SIZE |
otel.bsp.max.export.batch.size |
배치당 최대 내보내기 Span 수. | 기본값 512, 대기열 상한보다 클 수 없음. |
OTEL_BSP_EXPORT_TIMEOUT |
otel.bsp.export.timeout |
Span 배치 내보내기 타임아웃, 단위 밀리초. | 기본값 30000. |
OTEL_METRIC_EXPORT_INTERVAL |
otel.metric.export.interval |
Metric 내보내기 간격, 단위 밀리초. | 기본값 60000. |
프로덕션 환경에서는 트래픽과 데이터 예산에 따라 샘플링 비율을 설정해야 합니다. 애플리케이션 측 헤더 샘플링과 DataKit 측 샘플링이 동시에 활성화되면 최종 유지율이 중첩되어 감소하므로, 샘플링 위치를 통합적으로 계획해야 합니다.
로그 및 디버그 파라미터¶
| 환경 변수 | JVM 시스템 속성 | 설명 | 기본값 또는 예시 |
|---|---|---|---|
OTEL_JAVAAGENT_LOGGING |
otel.javaagent.logging |
Agent 자체 로그 출력 방식. | 기본값 simple; 옵션: none, application. |
OTEL_JAVAAGENT_DEBUG |
otel.javaagent.debug |
상세한 Agent 디버그 로그 출력. | 기본값 false; 문제 해결 시에만 임시로 true로 설정. |
OTEL_JAVAAGENT_LOGGING은 Java Agent 자체의 진단 로그를 제어하며, 애플리케이션 로그 수집 방식과는 관련이 없습니다. 이 문서의 애플리케이션 로그는 DataKit이 파일에서 수집하므로 OTEL_LOGS_EXPORTER는 none으로 유지해야 합니다.
연결 확인¶
- 애플리케이션을 시작하고 표준 오류 출력에
opentelemetry-javaagent - version이 나타나고 OTLP export 오류가 없는지 확인합니다. - 웹 프레임워크, HTTP 클라이언트 또는 데이터베이스를 거치는 애플리케이션 인터페이스를 요청하고, 동시에 요청 처리 코드에서 애플리케이션 로그를 생성합니다.
- 로그 파일을 확인하여 요청 범위 내의 로그에 비어 있지 않은
trace_id와span_id가 포함되어 있는지 확인합니다:
- HTTP를 사용하여 전송하는 경우, DataKit 호스트에서 OTLP 수신 로그를 확인합니다:
/otel/v1/traces 또는 /otel/v1/metrics의 POST 요청이 응답 코드 200과 함께 나타나면 DataKit이 데이터를 수신한 것입니다.
- Guance의 '로그' 탐색기로 이동하여
service:order-service로 검색하고, 요청 로그 하나를 열어trace_id,span_id가 필드로 추출되었는지 확인합니다. 그런 다음 로그 상세 정보의 연결된 트레이스 링크를 통해 해당 Trace를 확인합니다. 또는 '애플리케이션 성능 모니터링(APM) > 트레이스'로 이동하여service:order-service로 검색하고 트레이스에 연결된 로그를 확인할 수도 있습니다.
Trace가 생성되지 않는 경우, 임시로 OTEL_JAVAAGENT_DEBUG=true를 추가하고 애플리케이션을 재시작하여 Agent 로드, 계측 매칭, endpoint, 프로토콜 및 네트워크 오류를 확인합니다. 로그는 있지만 트레이스 필드가 없는 경우, 로그가 유효한 Span 범위 내에서 생성되었는지, 실제 사용 중인 로그 설정 파일에 MDC 형식이 포함되어 있는지, 애플리케이션에서 해당 로그 프레임워크의 자동 계측을 비활성화하지 않았는지 확인해야 합니다. 파일에 트레이스 필드가 있지만 Guance에 표시되지 않는 경우, DataKit 파일 읽기 권한, 로그 경로 및 Pipeline 매칭 결과를 확인해야 합니다. 문제 해결 후에는 대량의 로그와 추가 성능 오버헤드를 방지하기 위해 debug를 비활성화해야 합니다.