metrics, logs, traces란 무엇이며, 언제 각각을 사용하나요?

Question

IT Interview Practice · Accepted Answer

이들은 **observability의 세 기둥**입니다. 서로 다른 질문에 답합니다: metrics는 무언가 잘못되었다는 **사실**을, logs는 **무엇이** 일어났는지를, traces는 분산 흐름에서 시간이나 오류가 **어디로** 갔는지를 알려줍니다.

## 세 기둥

```text
METRICS  시간에 따른 집계 숫자 (counter, gauge, histogram)
         → 저렴, 낮은 cardinality, 추세 & ALERTING에 적합
         → 예: error rate = 2%, p99 latency = 800ms

LOGS     상세 정보를 담은 개별 timestamped 이벤트 (보통 구조화된 JSON)
         → 특정 request를 DEBUGGING하기 위한 풍부한 맥락
         → 예: {"level":"error","user":123,"msg":"payment declined"}

TRACES   여러 service를 가로지르는 한 request의 경로, span별 타이밍 포함
         → latency 분해와 어디서 호출이 실패하는지를 보여줌
         → 예: checkout 800ms = api 50ms + db 700ms + email 50ms
```

## 언제 각각을 쓰는가 — 하나의 인시던트

```text
1. METRIC alert: "checkout p99 latency가 2s로 급등"   → 문제가 있다는 것을 앎
2. 느린 request를 TRACE: 2s 중 1.8s가 inventory service에서 소요
                                                     → 어디인지 앎
3. 그 시각 inventory service의 LOGS: "slow query: missing index"
                                                     → 무엇이 일어났는지 앎
```

Metrics는 증상과 시간 창으로 좁혀주고, traces는 service나 호출로 국소화하며, logs는 정확한 원인을 줍니다. metrics 없이 logs로 바로 가는 것은 깜깜이로 뒤지는 것입니다.

## 비용과 cardinality

Metrics는 집계되므로 대규모에서도 저렴하게 유지됩니다 — 항상 켜진 dashboard와 alert에 이상적입니다. Logs와 traces는 이벤트 단위라 비싸므로, 보통 **sampling**되고 조사 중 필요할 때 쿼리됩니다.

## 왜 중요한가

잘못된 기둥을 쓰면 시간을 낭비합니다: 원시 logs로는 효과적으로 alert를 걸 수 없고(너무 노이즈가 많고 비쌈), 집계 metric으로는 특정 실패 request를 debug할 수 없습니다. metrics가 탐지하고, traces가 국소화하며, logs가 설명한다는 것을 알면 "무언가 잘못됐다"에서 근본 원인까지 빠르고 반복 가능한 경로를 얻습니다.

세 기둥

언제 각각을 쓰는가 — 하나의 인시던트

비용과 cardinality

왜 중요한가

관련 질문