요청이 어느 구간에서 느려지거나 실패하는지를 보는 분산 트레이싱 스택이다. observability 네임스페이스에서 돈다.
앱(Python, 자동계측) ─ OTLP 4317/4318 ─ otel-gateway(2 replica)
│ batch·k8sattributes·resource
▼
Tempo(72h 보존) ── Grafana(Tempo 데이터소스, tempo:3200)
│ 스팬 메트릭 remote-write
▼
Prometheus(traces_spanmetrics_*) → platform-api-apm 대시보드
Instrumentation/OpenTelemetryCollector CRD 관리.memory_limiter → k8sattributes → resource → batch, 내보내기 → Tempo :4317. 트레이스 파이프라인만 활성(메트릭/로그 off).Instrumentation platform-python): 앱은 otel-gateway.observability.svc:4317/4318로 스팬 전송. 샘플링 100%(parentbased_traceidratio=1), 전파 tracecontext/baggage/b3.OTelGatewayUnavailable.service_graphs+span_metrics를 켜고, Prometheus로 remote-write(/api/v1/write) → traces_spanmetrics_calls_total, ..._latency_bucket 생성.tempo.observability.svc:3200)로 트레이스를 조회하고, 스팬 메트릭은 Prometheus에서 읽어 platform-api-apm 대시보드(요청율·에러율·p95)를 그린다.TempoUnavailable, APM 기반 PlatformAppServerErrorRateHigh/LatencyP95High.opentelemetry-operator → otel-collector(otel-gateway) → tempo → apm(Instrumentation). prod 전용.온보딩 트랙 3부. 관측과 SRE
이전: 로그 - Loki와 Alloy · 다음: Grafana, Loki, Tempo 1차 장애 확인 절차 (Manual) · 전체 경로: 시작하기: 신입 온보딩