트레이스

분산 트레이싱은 Prom 과 Loki 다음의 세 번째 L1 백엔드입니다. 그들처럼 ADR-014 를 따릅니다: edge 가 직접 push, 매니저는 쿼리만.

데이터 플레인

text

your apps (OTLP gRPC/HTTP)
    │
    ▼
edge:
  otelcol (subprocess plugin)
    └─ remote OTLP → tempo:4317
                          │
                          ├─ trace storage (S3-compatible blob)
                          │
                          └─ metrics_generator → traces_spanmetrics_*
                                                       │
                                                       ▼
                                                 prometheus:9090

otelcol 은 edge 에이전트 아래 플러그인으로 실행 (promtail 과 같은 감독 모델 — 로그 참고). 컬렉터는 호스트에서 gRPC (:4317) 와 HTTP (:4318) 둘 다 수락, 배치, HTTPS 로 클라우드의 Tempo 에 포워드.

앱은 Ongrid 를 알 필요 없음

애플리케이션의 OTel exporter 를 http://localhost:4318 (또는 gRPC 등가물) 로 가리키게 구성. 로컬 otelcol 이 인증 + 배치 + 클라우드로의 이동을 처리. Ongrid 제거 = 환경 변수 하나 제거 — 코드는 손 안 댐.

Spanmetrics generator

Compose 의 Tempo 배포는 metrics_generator 가 활성화. 모든 span 배치가 같은 Prom 으로 다시 배출되는 세 파생 메트릭을 생산:

Series	Source
`traces_spanmetrics_calls_total`	(service, operation, status_code) 당 카운터 하나
`traces_spanmetrics_latency_bucket`	span 지속시간 히스토그램
`traces_spanmetrics_size_bucket`	선택, 기본 off

이것이 트레이스 알림을 메트릭 알림처럼 느끼게 만드는 결정적 트릭: 알림 evaluator 가 Prom 을 쿼리, 데이터는 Tempo 에 산다.

알림 kind

`trace_latency`

json

{
  "kind": "trace_latency",
  "scope_type": "global",
  "conditions_json": {
    "service": "payments-api",
    "operation": "POST /v1/charge",
    "quantile": "p95",
    "window": "5m",
    "threshold_ms": 800
  }
}

다음으로 컴파일:

promql

histogram_quantile(
  0.95,
  sum by (le) (rate(traces_spanmetrics_latency_bucket{
    service_name="payments-api", span_name="POST /v1/charge"
  }[5m]))
) * 1000 > 800

operation 은 선택 — 서비스 전체 지연에는 떨어뜨림. compileTraceLatencyRule 참고.

지원 quantile: p50 / p95 (기본) / p99. 문자열 형태는 UI 폼 선택기가 간결하게 유지되도록 존재; 컴파일러가 histogram_quantile 이 원하는 float 로 매핑.

`trace_error_rate`

json

{
  "kind": "trace_error_rate",
  "scope_type": "global",
  "conditions_json": {
    "service": "payments-api",
    "window": "5m",
    "operator": ">",
    "threshold_pct": 1.0
  }
}

다음으로 컴파일:

promql

100 * (
  sum by (service_name) (rate(traces_spanmetrics_calls_total{
    service_name="payments-api", status_code="STATUS_CODE_ERROR"
  }[5m]))
  / sum by (service_name) (rate(traces_spanmetrics_calls_total{
    service_name="payments-api"
  }[5m]))
) > 1.0

STATUS_CODE_ERROR 리터럴은 spanmetrics generator 가 배출하는 것; 대체 span status 컨벤션은 자체 kind 가 필요.

도구

`query_traceql`

Tempo 의 TraceQL 엔드포인트로의 직접 통과 (query_traceql_basetool.go). 운영자가 특정 trace ID 를 요청할 때 investigator persona 가 사용 — 예: "지난 30 분 동안 payments-api 의 느린 trace 찾아."

text

{ resource.service.name="payments-api" } | duration > 800ms

기반 클라이언트는 internal/pkg/tracequery; 의도적으로 백엔드 분리된 패키지 이름 — Jaeger / Zipkin 클라이언트가 표면 이름 변경 없이 나중에 들어올 수 있음.

`correlate_incident`

Investigator persona 가 시작하는 composite 도구. 단일 fan-out 호출로 incident 의 발화 윈도우 주변 Prom + Loki + Tempo 신호를 풀. 4-5 순차 도구 호출을 하나로 줄임 — investigation 별 예산이 10 도구 호출일 때 중요.

correlate_incident_basetool.go 참고.

같이 보기

알림 — 규칙 kind.
Monitoring — 트레이스 알림이 쿼리하는 Prom 백엔드.
토폴로지 — Tempo 의 metrics_generator 가 자동으로 추론하는 서비스 간 엣지.
Telemetry 데이터 플레인 — 전체 ADR-014.

트레이스 ​

데이터 플레인 ​

Spanmetrics generator ​

알림 kind ​

trace_latency ​

trace_error_rate ​

도구 ​

query_traceql ​

correlate_incident ​

같이 보기 ​