LLM 시스템을 위한 관찰 가능성: 메트릭, 트레이스, 로그 및 프로덕션에서의 테스트

LLM 시스템은 전통적인 API 모니터링으로는 감지할 수 없는 방식으로 실패할 수 있습니다. 큐는 조용히 채워지고, GPU 메모리가 CPU가 바쁜 상태가 되기 훨씬 전에 포화 상태가 되며, 지연은 애플리케이션 계층이 아닌 배치 계층에서 급증합니다. 이 가이드는 LLM 추론 및 LLM 애플리케이션에 대한 종단간 관찰 전략 을 다룹니다:
측정해야 할 항목, Prometheus, OpenTelemetry, Grafana로 어떻게 기기를 설정할지, 그리고 텔레메트리 파이프라인을 대규모로 어떻게 배포할지에 대해 설명합니다.

TL;DR (최고경영자 요약)

LLM 시스템은 전통적인 “HTTP 지연 시간 + 오류율” 모니터링으로 설명할 수 없는 방식으로 퇴화합니다. LLM 시스템을 위한 프로덕션 등급의 관찰은 빠르고 방어적으로 다음과 같은 질문에 답해야 합니다:

• 사용자 경험에 문제가 있는지 (꼬리 지연 시간, 첫 토큰 생성 시간, 토큰 간 지연 시간, 오류 및 중단).
• 시간이 어디에 소요되는지 (대기열 vs 배치 vs 모델 실행; 검색/도구/안전 필터 vs 추론).
• 먼저 포화되는 요소는 무엇인지 (GPU 사용률 및 메모리 압력, KV-캐시/대기열 압력, CPU 토큰화).
• 비용과 용량이 어떻게 드리프트하는지 (요청당 토큰 수, GPU당 토큰/초, 캐시 히트율, 낭비된 생성).
• 텔레메트리가 안전하게 저장될 수 있는지 (프롬프트는 PII를 포함할 수 있음; 로그/속성에 민감한 정보 유출 방지).

가장 견고한 설계는 다중 신호 파이프라인입니다:

• 메트릭(Prometheus + PromQL; Thanos/Cortex/Mimir/VictoriaMetrics를 통한 선택적 장기 저장)으로 빠른 탐지 및 용량 계획.
• 트레이스(OpenTelemetry와 OTLP; Tempo/Jaeger/Zipkin/Elastic APM 등 백엔드)로 요청 수준의 인과 관계.
• 로그(Loki/Elastic/OpenSearch)로 컨텍스트, 트레이스와 연관된 것으로 설계된 저 카디널리티 메타데이터.
• 프로파일링(Grafana Pyroscope)으로 CPU/메모리 핫스팟 및 꼬리 지연 시간.
• 합성 + 부하 테스트(Grafana k6; 블랙박스 스타일의 탐지)로 사용자보다 먼저 회귀를 감지.
• SLO(SLOs)로 사용자 결과 측정 및 실행 가능한 알림 생성 (오류 예산, 연소율 스타일).

LLM 시스템에 대한 관찰이 다른 이유

범위 참고사항: 대상 LLM 프레임워크는 미지정입니다. 이 기사의 예제는 일반적인 서버/프레임워크(Triton, vLLM, TGI, LangChain/LangSmith)를 다루며, 동등한 메트릭 및 스팬으로 대체함으로써 다른 스택에도 적용 가능합니다.

LLM은 전통적인 웹 서비스와 다른 운영 행동을 도입합니다:

• 요청당 가변 작업: 토큰 수(입력/출력)가 넓게 변동되므로, “초당 요청 수"가 안정적으로 보일 수 있지만 토큰 처리량이 붕괴될 수 있습니다. TGI와 vLLM은 이 스타일의 모니터링을 지원하기 위해 토큰 및 토큰 지연 시간 관련 텔레메트리를 명시적으로 내보냅니다.
• 대기열 + 지속적인 배치: 처리량은 배치/대기열 규칙에 따라 달라지며, 대기열 크기와 배치 크기는 첫 번째 등급 지표가 됩니다(TGI는 두 가지 모두 제공).
• 스트리밍 UX: 사용자는 전체 응답 시간만큼 TTFT(첫 토큰 생성 시간)와 토큰 간 지연 시간에 관심이 있습니다. OpenTelemetry는 GenAI 세마포트 컨벤션에 따라 서버 TTFT/토큰당 시간을 표준화합니다.
• GPU 압력이 실패 모드를 지배: GPU 사용률과 GPU 메모리(포함 메모리 사용량)는 신뢰성에 핵심이며, NVIDIA의 DCGM 내보내기 도구는 Prometheus /metrics 엔드포인트에서 GPU 텔레메트리를 제공하기 위해 특별히 설계되었습니다.
• 다단계 파이프라인: 검색, 도구 호출, 안전 필터, 후처리는 종단간 지연 시간이 여러 스팬/대기열의 조합이 되므로 분산 트레이스와 주의 깊은 메트릭 설계가 필수입니다.

인기 있는 추론 서버의 구체적인 예는 이점을 강조합니다:

• NVIDIA Triton 추론 서버는 /metrics(일반적으로 :8002/metrics)를 통해 텍스트 형식의 메트릭을 제공하며, 메트릭을 활성화/비활성화하고 메트릭 포트를 선택할 수 있는 플래그를 제공합니다.
• vLLM은 vllm: 접두사를 사용하는 광범위한 Prometheus /metrics 엔드포인트를 제공하며, 문서에는 생성 토큰 수 및 첫 토큰 생성 시간과 같은 히스토그램의 카운터를 포함합니다.
• Hugging Face TGI는 대기열 크기, 배치 크기, 종단간 요청 지속 시간, 생성 토큰 수, 대기열 지속 시간을 포함하는 /metrics 엔드포인트를 문서화합니다.

핵심 관찰 작업 및 필요한 LLM 텔레메트리

LLM 시스템에 대한 관찰은 작업 → 신호 → 도구를 매핑하고, 처음부터 카디널리티와 샘플링을 제한하는 것이 가장 쉽게 구현됩니다.

메트릭: 온라인 서빙 시스템에 대해 Prometheus의 자체 기기 지침은 쿼리 수, 오류, 지연 시간을 핵심 메트릭으로 강조합니다. LLM은 이에 TTFT, 토큰당 처리량/지연 시간, 대기열 길이, 배치 크기, GPU 사용률로 확장됩니다.

트레이스: 트레이스는 검색/도구/안전/추론 단계에서 지연 시간 및 실패를 인과 관계로 연결하는 방법입니다. OpenTelemetry는 트레이스/내보내기를 벤더 중립적인 방식으로 내보내고 수집기 또는 백엔드로 텔레메트리를 전송하는 방법으로 프레임워크합니다.

로그: 로그는 인간이 읽을 수 있는 컨텍스트 및 “왜"를 제공하지만, 무제한 값을 인덱싱하는 것을 피해야 하면만 대규모로 사용 가능합니다(예: Loki는 라벨만 인덱싱하고 압축된 로그 청크를 오브젝트 스토리지에 저장).

프로파일링: 지속적인 프로파일링은 낮은 오버헤드 샘플링을 통해 생산 CPU/메모리 행동을 포착하며, Grafana Pyroscope는 이에 특별히 설정됩니다.

합성 테스트 및 부하 테스트: Grafana k6는 오픈소스 부하 테스트 도구이며, Grafana는 합성 모니터링이 k6를 기반으로 하며 단순한 프로토콜 검사를 넘어선다고 명시합니다.

SLO: Google의 SRE 지침은 SLO를 서비스 수준을 측정하는 SLI에 의해 정의된 목표 값/범위로 정의하며, SLO에 대한 알림에 대한 지침(정밀도/재현율/검출 시간의 트레이드오프)을 제공합니다.

핵심 LLM 메트릭 설계

OpenTelemetry GenAI 세마포트 컨벤션을 통한 표준화

OpenTelemetry는 GenAI 세마포트 컨벤션(상태: “개발”)을 제공하며, GenAI 메트릭에 대한 표준 이름을 제공합니다:

• gen_ai.client.token.usage 및 gen_ai.client.operation.duration
• gen_ai.server.request.duration, gen_ai.server.time_per_output_token, gen_ai.server.time_to_first_token

이 표준화는 “OpenTelemetry로 LLM 모델 모니터링” 전략의 이동 가능한 실용적인 레버입니다: 한 번 내보내고 나중에 OSS 또는 벤더 백엔드로 동일한 텔레메트리를 라우팅합니다.

텔레메트리 파이프라인 설계

끌기 vs 밀기

Prometheus는 끌기 중심입니다. 프로세스는 지원되는 노출 형식으로 메트릭을 노출하고, Prometheus는 구성된 스크래핑 작업에 따라 이를 스크래핑합니다.

밀기는 예외입니다. Prometheus의 “When to use the Pushgateway” 가이드는 Pushgateway를 제한된 경우에만 권장하며, Pushgateway README는 “Prometheus를 기반으로 한 모니터링 시스템으로 전환"할 수 없다고 강조합니다.

LLM에 특화된 실용적인 패턴:

• 끌기를 추론 서버/내보내기(Triton/vLLM/TGI 메트릭 엔드포인트; DCGM 내보내기; 노드 메트릭)에 사용.
• OTLP 밀기를 트레이스/로그/OTel 메트릭에 사용 (OpenTelemetry Protocol은 소스, 수집기, 백엔드 간의 전송/인코딩/배달을 정의).
• 리모트 라이트를 단일 Prometheus를 넘어 확장할 때 사용 (Prometheus는 리모트 라이트 튜닝 지침을 제공; Mimir/Thanos/Cortex는 장기 및/또는 HA 저장 옵션을 제공).

에이전트 vs 사이드카 vs 게이트웨이 수집기

OpenTelemetry는 에이전트 배포 패턴을 문서화하며, 텔레메트리는 애플리케이션과 함께 실행되거나 동일한 호스트에 실행되는 수집기(사이드카/DaemonSet)에 전송되고 내보내집니다.

Kubernetes의 경우, OpenTelemetry Operator(어노테이션 기반 주입)를 통해 사이드카 주입이 지원됩니다.

LLM 스택에 대한 실용적인 규칙:

• DaemonSet 에이전트를 호스트 수준의 풍부화 및 많은 포드 간 공유 파이프라인에 사용.
• 사이드카를 사용할 때는 엄격한 워크로드별 고립 또는 로컬 필터링(프롬프트가 민감한 데이터를 포함할 수 있는 경우 일반적)이 필요합니다.
• 게이트웨이 수집기를 사용하여 중심적인 꼬리 샘플링, 배치, 재시도 및 내보내기 분산을 사용.

샘플링 및 카디널리티 제어

OpenTelemetry는 꼬리 샘플링이 트레이스 기준을 사용하여 샘플링 결정을 허용한다고 명확히 합니다(머리 샘플링만으로는 불가능).

Prometheus의 기기 지침은 라벨 과잉 사용에 경고하며, 카디널리티를 낮추는 규칙을 제시하고, 잠재적 카디널리티가 약 100을 초과할 경우 메트릭 재설계를 권장합니다.

LLM에 특화된 “카디널리티 함정"을 조기에 금지해야 합니다:

• 프롬프트 텍스트, 응답 텍스트, 대화 ID, 요청 ID를 라벨/속성으로 사용.
• 도구 인자 블로브를 스팬 속성으로 사용.
• 무제한 “user_id” 라벨.

유한한 차원을 선호: model, model_family, endpoint, region, status_code, deployment, tenant(유한한 경우에만).

LLM 관찰 도구 비교

도구가 관찰 작업에 매핑된 경우

Grafana와 대체 시각화 도구 간 비교

• Grafana 대시보드는 데이터 소스(Loki 및 Mimir 포함)를 쿼리하는 패널로 구성되어 차트 및 시각화를 생성합니다.
• Kibana는 Elastic Stack 내 UI 레이어로 대시보드/시각화를 제공합니다.
• OpenSearch 대시보드는 OpenSearch에 대한 데이터 시각화 도구를 제공합니다.
• InfluxData의 문서는 Chronograf를 Influx 생태계 내 시각화 구성 요소로 정의합니다.

Prometheus와 대체 메트릭 백엔드 간 비교

• Prometheus 로컬 저장소 기본값: 보류 기간 플래그가 설정되지 않은 경우, 보류 기간은 15일로 기본값입니다(보류 기간/비용을 조기에 계획하세요).
• Grafana Mimir은 Prometheus 및 OpenTelemetry 메트릭을 위한 수평 확장, HA, 다중 테넌트 장기 저장 솔루션으로 설명됩니다.
• Thanos는 장기 저장 기능을 갖춘 고가용성 Prometheus 설정으로 설명됩니다.
• Cortex는 Prometheus 및 OpenTelemetry 메트릭을 위한 수평 확장, HA, 다중 테넌트 장기 저장 솔루션으로 설명됩니다.
• VictoriaMetrics Cloud는 Prometheus 리모트 라이트 통합을 통해 장기 저장을 문서화합니다.
• Amazon Managed Service for Prometheus는 인GESTION/쿼리 요구사항에 따라 확장되고 PromQL 및 리모트 라이트를 지원하는 관리형 제공을 설명합니다.

실용적인 구현 요리법

오늘부터 구현해야 할 메트릭 이름 및 유형

OpenTelemetry GenAI 세마포트 컨벤션(상태: 개발)은 즉시 표준화할 수 있는 메트릭 이름을 정의합니다:

• gen_ai.client.token.usage
• gen_ai.client.operation.duration
• gen_ai.server.request.duration
• gen_ai.server.time_per_output_token
• gen_ai.server.time_to_first_token

즉시 스크래핑할 수 있는 서버 측 예시:

• vLLM의 Prometheus 엔드포인트는 카운터(예: 생성 토큰 총 수) 및 히스토그램(TTFT)을 포함하고 model_name 라벨 전략을 문서화합니다.
• TGI는 대기열 크기, 요청 지속 시간, 생성 토큰, 토큰당 평균 시간을 포함하는 메트릭을 문서화합니다.
• Triton은 /metrics 노출 및 메트릭 토글을 문서화합니다.

LLM 지연 시간 및 처리량 대시보드를 위한 PromQL 예제

# 5분 동안의 애플리케이션 히스토그램에서 p95 종단간 지연 시간
histogram_quantile(
  0.95,
  sum(rate(llm_request_latency_seconds_bucket[5m])) by (le, model)
)

# 오류율 퍼센트 (5xx)
100 *
(
  sum(rate(llm_requests_total{status_code=~"5.."}[5m]))
  /
  sum(rate(llm_requests_total[5m]))
)

# 모든 모델에 걸쳐 토큰/초 (출력)
sum(rate(llm_tokens_total{direction="out"}[5m]))

# TGI 대기열 크기 (게이지)
max(tgi_queue_size) by (instance)

# vLLM TTFT p95
histogram_quantile(
  0.95,
  sum(rate(vllm:time_to_first_token_seconds_bucket[5m])) by (le, model_name)
)

Prometheus의 히스토그램 지침은 histogram_quantile()을 사용하여 서버 측 버킷에서 히스토그램 분위수를 계산한다고 설명합니다.

LLM 시스템을 위한 OpenTelemetry 기기 지침

• OTLP는 OpenTelemetry 프로토콜로, 텔레메트리가 소스, 수집기, 백엔드 간에 인코딩/전송되는 방식을 정의합니다.
• OpenTelemetry SDK 구성 문서는 OTEL_EXPORTER_OTLP_ENDPOINT(및 프로토콜 옵션)과 같은 환경 변수를 사용하여 텔레메트리를 내보내는 방법을 문서화합니다.
• OpenTelemetry Python contrib는 FastAPI 자동 및 수동 기기를 위한 지원을 문서화합니다.
• GenAI 세마포트 컨벤션은 OTEL_SEMCONV_STABILITY_OPT_IN을 통해 GenAI 컨벤션 이전에 대한 선택적 안정성 메커니즘을 포함합니다.

짧은 Python 예제: 메트릭 + 트레이스 + 로그

다음 코드 조각은 다음과 같이 보여줍니다:

• “Prometheus로 LLM 추론 모니터링"을 위한 Prometheus 메트릭 노출 (/metrics)
• OTLP를 통해 내보내는 OpenTelemetry 트레이스 (벤더 중립)
• 트레이스 컨텍스트와 연관된 구조화된 로그, 기본값은 원시 프롬프트를 로깅하지 않도록 설정됨

import logging
import time

from fastapi import FastAPI, Request
from pydantic import BaseModel

# Prometheus (끌기 기반 메트릭)
from prometheus_client import Counter, Histogram, generate_latest, CONTENT_TYPE_LATEST
from starlette.responses import Response

# OpenTelemetry (OTLP 트레이스)
from opentelemetry import trace
from opentelemetry.instrumentation.fastapi import FastAPIInstrumentor
from opentelemetry.sdk.resources import Resource
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.http.trace_exporter import OTLPSpanExporter

app = FastAPI(title="LLM 추론 API", version="1.0.0")
FastAPIInstrumentor.instrument_app(app)

# --- 로깅 (개인 정보 보호 기본값) ---
logger = logging.getLogger("llm")
logging.basicConfig(level=logging.INFO, format="%(message)s")

def trace_id_hex() -> str:
    span = trace.get_current_span()
    ctx = span.get_span_context()
    return format(ctx.trace_id, "032x") if ctx.is_valid else ""

# --- Prometheus 메트릭 ---
LLM_REQUESTS = Counter(
    "llm_requests_total",
    "LLM 요청 총 수",
    ["route", "status_code", "model"],
)
LLM_LATENCY = Histogram(
    "llm_request_latency_seconds",
    "종단간 LLM 요청 지연 시간 (초)",
    ["route", "model"],
    buckets=(0.1, 0.2, 0.35, 0.5, 0.75, 1, 1.5, 2, 3, 5, 8, 13),
)

# --- OpenTelemetry 트레이서 제공자 ---
resource = Resource.create({"service.name": "llm-inference-api"})
trace.set_tracer_provider(TracerProvider(resource=resource))
trace.get_tracer_provider().add_span_processor(
    BatchSpanProcessor(OTLPSpanExporter())  # OTEL_EXPORTER_OTLP_* 환경 변수를 통해 구성
)
tracer = trace.get_tracer(__name__)

class GenerateRequest(BaseModel):
    prompt: str
    model: str = "unspecified"
    max_tokens: int = 256

class GenerateResponse(BaseModel):
    model: str
    output: str
    latency_ms: int

@app.post("/v1/generate", response_model=GenerateResponse)
async def generate(req: GenerateRequest, request: Request):
    route = "/v1/generate"
    start = time.perf_counter()

    with tracer.start_as_current_span("llm.generate") as span:
        # 원시 프롬프트/출력을 로깅하지 않도록 안전한 메타데이터를 내보내기
        span.set_attribute("gen_ai.request.model", req.model)
        span.set_attribute("gen_ai.request.max_tokens", req.max_tokens)

        # 실제 LLM 호출로 대체 (Triton/vLLM/TGI 클라이언트)
        time.sleep(0.15)
        output = "모델에서 안녕하세요."

        latency_s = time.perf_counter() - start
        LLM_LATENCY.labels(route=route, model=req.model).observe(latency_s)
        LLM_REQUESTS.labels(route=route, status_code="200", model=req.model).inc()

        logger.info(
            {
                "msg": "llm_request_complete",
                "trace_id": trace_id_hex(),
                "model": req.model,
                "latency_ms": int(latency_s * 1000),
                # 정책이 허용하지 않는 한 원시 프롬프트/출력을 포함하지 않도록 하세요.
            }
        )

        return GenerateResponse(model=req.model, output=output, latency_ms=int(latency_s * 1000))

@app.get("/metrics")
def metrics():
    return Response(generate_latest(), media_type=CONTENT_TYPE_LATEST)

배포, 확장, 보안 및 문제 해결

배포 옵션

확장 및 보유: 실용적인 제약

• Prometheus 로컬 저장소: 명시적인 크기/시간 플래그가 없으면 보유 시간은 15일로 기본값입니다.
• Prometheus 리모트 라이트: Prometheus는 “정상 기본값"을 넘어 확장하기 위한 리모트 라이트 조정을 문서화합니다.
• Grafana Tempo: 고규모 트레이스 백엔드로 설정되어 있으며, metrics-generator를 사용하여 스팬에서 메트릭 생성이 가능합니다(리모트 라이트를 Prometheus 데이터 소스로).
• Loki 저장소: Loki 문서는 라벨만 인덱싱하고 압축 청크 저장(오브젝트 스토리지)을 강조하며, 라벨 전략이 확장 및 비용에 중심입니다.

보안 및 개인 정보 보호: 프롬프트는 PII를 포함할 수 있음

OpenTelemetry의 보안 지침은 텔레메트리 수집이 예기치 않게 민감한/개인 정보를 포착할 수 있다고 강조하며, 이를 적절히 처리하는 책임은 사용자에게 있습니다.

Prometheus의 보안 모델은 Prometheus 엔드포인트가 공공 네트워크(예: 인터넷)에 노출되어서는 안 된다고 경고합니다. 왜냐하면 이는 모니터링 시스템에 대한 정보를 제공하기 때문입니다.

“LLM 시스템에 대한 관찰"을 안전하게 유지하는 운영적 개인 정보 보호 제어:

• 기본적으로 원시 프롬프트/응답을 로깅하지 않도록 하며, 토큰 수, 모델 이름, 지연 시간, 트레이스 ID를 대신 로깅합니다.
• 수집기/파이프라인에서 민감한 속성을 제거/삭제(수집기 수준의 필터링은 생태계 전반에 걸쳐 일반적인 접근 방식입니다).
• 로그/트레이스에 대해 RBAC 및 보유 정책을 강제 적용하고, 필요한 경우 민감한 데이터 스캐너를 고려하세요(예: 벤더는 텔레메트리에 대한 스캐너를 문서화합니다).

문제 해결 체크리스트

Grafana 대시보드에서 LLM 지연 시간이 잘못 보이는 경우, 다음 순서로 디버깅하세요:

• 인게이션 건강 상태
  • Prometheus: 스크래핑 성공 및 구성 의미를 검증(스프레스 구성은 스크래핑 작업/인스턴스를 정의).
  • OTLP: 내보내기 엔드포인트 구성 확인(SDK는 OTEL_EXPORTER_OTLP_ENDPOINT, 프로토콜 설정 사용).
• 스키마 불일치
  • 대시보드는 model을 기대하지만, 서버는 model_name(vLLM은 명시적으로 model_name 라벨을 문서화).
• 카디널리티 폭증
  • 누군가 요청 ID/프롬프트 해시로 라벨을 지정했음; Prometheus는 라벨셋이 RAM/CPU/디스크/네트워크 비용을 증가시키며, 카디널리티 지침을 제공.
• 히스토그램 오용
  • _bucket 시리즈에서 rate() 및 le와 함께 분위수를 계산하는 것을 보장하세요; Prometheus는 히스토그램 분위수 계산의 트레이드오프를 설명.
• 트레이스 샘플링 간격
  • 머리 샘플링이 너무 치밀하게 이루어지면 드문 느린/오류 트레이스가 사라짐; 꼬리 샘플링은 전체 트레이스 기준에 따라 “중요한” 트레이스를 유지.
• Tempo 스팬-메트릭 문제
  • Tempo 메트릭 생성기 및 스팬-메트릭을 사용하는 경우, 활성화 및 튜닝이 완료되었는지 확인(Tempo는 메트릭 생성기 및 스팬-메트릭 프로세서를 문서화; 생성기 문제에 대한 디버깅 존재).
• GPU 메트릭 누락
  • DCGM 내보내기가 배포되었고 /metrics가 접근 가능한지 확인(DCGM 내보내기는 Prometheus를 위한 HTTP를 통해 GPU 메트릭을 노출).

유용한 링크

• 관찰: 모니터링, 메트릭, Prometheus & Grafana 가이드
• Prometheus 모니터링: 설정 및 최선 실천
• LLM 성능: 벤치마크, 병목 현상 및 최적화
• LLM 호스팅: 로컬, 자가호스팅 및 클라우드 인프라 비교
• RAG 단계별 튜토리얼
• Prometheus 구성 문서
• Prometheus 노출 형식
• Prometheus 기기 지침 최선 실천
• Prometheus 메트릭 이름 지정
• Prometheus 히스토그램 및 요약
• Prometheus 알림 규칙
• Prometheus 알림 개요
• Alertmanager 구성
• Grafana 대시보드 JSON 모델
• Grafana 프로비저닝
• NVIDIA Triton 추론 서버 메트릭
• TorchServe 메트릭 API
• NVIDIA DCGM 내보내기
• kube-prometheus-stack Helm 차트
• Prometheus Operator 시작하기
• OpenTelemetry Prometheus 내보내기 명세
• Prometheus가 OTLP를 수신하는 방법
• LangSmith와 OpenTelemetry의 트레이스