Observability의 3요소 - Metrics, Tracing, Logging

StrayCat·2026년 4월 13일

CS지식

목록 보기

29/32

출처 : https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html

모니터링,로깅에 대해 한창 학습 하던 중 좋은 인사이트가 되어 포스팅해봤다

요약하자면 "Metrics, Tracing, Logging은 상호 연결되어 있으며, 이들을 적절한 도구를 사용해 적절한 양을 분배, 설계하는 것이 Observability의 핵심이다"

Observability란?

모니터링(Monitoring)이 "지금 문제가 있는가?"를 실시간으로 감시하는 개념이라면,
옵저버빌리티(Observability, 관찰 가능성)는 "왜 이런 일이 생겼는가"를 찾아내는 데 초점을 맞춘다.

모니터링이 알람을 울리는 역할이라면, 옵저버빌리티는 그 이후의 진단 과정 전체를 포함한다.

Observability는 세 가지 핵심 요소로 구성된다.

Metrics - 집계 가능한 수치 데이터 (Aggregatable)
Logging - 개별 사건 기록 (Discrete Events)
Tracing - 요청 단위의 흐름 추적 (Request-Scoped)

Metrics - 숫자로 압축되는 데이터

Metrics는 시간의 흐름에 따라 하나의 수치로 집계되는 데이터다.

타입	설명	예시
Gauge	현재 상태값. 마지막 값이 현재를 대표 (last-write-win)	Queue에 쌓인 메시지 수: 42
Counter	누적 카운트. 단순 덧셈으로 집계	지금까지 들어온 HTTP 요청 수: 10,000
Histogram	분포. 시간 버킷으로 묶어 p50, p95, p99 등 통계값 산출	응답 시간: [10ms, 23ms, 8ms, 45ms ...]

핵심은 "Aggregatable"이라는 특성이다.
수천 건의 요청이 들어와도 결국 숫자 몇 개로 압축되어 표현된다.
그래서 저장 비용이 낮고, 요청과 무관한 시스템 상태(JVM heap 사용량, CPU 점유율 등)도 표현할 수 있다.

대표 시스템으로는 Prometheus + Grafana 조합이 가장 널리 쓰인다.

Logging - 사건 그 자체를 남기는 것

Logging은 개별 사건(Event)을 그대로 기록하는 것이다.

Application Log - 디버그/에러 추적
ex) [ERROR] 2026-04-14 NullPointerException at UserService.java:42
Audit Log - 감사 추적. "누가, 언제, 무엇을 했는가" (보안/규정 준수 목적)
ex) user_id=123이 2026-04-13 14:32에 주문 삭제 수행
Request Metadata - 요청 메타데이터
ex) IP: 123.45.67.89, User-Agent: Chrome, Status: 500

Metrics와 결정적으로 다른 점은 압축하지 않는다는 것이다.
요청 하나하나를 그대로 기록하기 때문에, 데이터 볼륨이 압도적으로 크다.
심한 경우 로그 데이터를 기록하는 트래픽이 실제 서비스 트래픽보다 많아지기도 한다.

그래서 운영 환경에서 DEBUG, INFO 레벨 로그를 함부로 켜두지 말라는 조언이 바로 이 맥락에서 나온다.
로깅은 전용 인프라인 ELK Stack (Elasticsearch + Logstash + Kibana)을 이용해 수집, 처리, 시각화한다.

Tracing - 요청 하나의 전체 여정 추적

Tracing은 하나의 요청이 시스템을 통과하는 전 과정을 추적하는 것이다.

사용자가 '주문' 버튼을 눌렀을 때,
API Gateway → Order Service → DB Query 까지 어느 구간에서 얼마나 걸렸는지를 따라간다.

개념	설명
Trace	요청 전체의 경로 (시작부터 끝까지)
Span	각 서비스/작업 단위 (Trace의 구성 단위)
Correlation ID	요청 단위의 공통 식별자. 분산 시스템에서 로그를 묶을 때 사용

키워드는 Request-Scoped, 즉 요청에 묶인 정보라는 점이다.
반드시 요청과 함께 시작하고 끝나기 때문에, 시스템 전반의 상태를 표현하는 데는 적합하지 않다.

대표 시스템으로는 Zipkin, Jaeger가 있으며, Spring Boot 환경에서는 Micrometer Tracing을 통해 비교적 쉽게 연동할 수 있다.

셋을 함께 쓰면 무엇이 가능한가

"서버가 느린데 원인이 뭐지?" 라는 상황을 예시로 생각해보자.

Metrics  → "p99 응답 시간이 500ms 이상으로 치솟고 있다"    → What (무슨 문제인가)
Tracing  → "order-service의 DB Query 구간에서 병목 발견"   → Where (어디서 문제인가)
Logging  → "Connection pool exhausted 에러 발생"           → Why (왜 문제인가)

이 흐름이 완성될 때 비로소 진단이 가능하다.
그리고 진단 이후에는 단계적인 대응이 가능해진다.

단기: HikariCP Pool 사이즈 조정
중기: 트랜잭션 범위 축소, Slow Query 개선
장기: 쓰기/읽기 DB 분리, Redis 캐싱 도입, Kafka 비동기 처리 전환

데이터 없이는 이 중 어느 단계도 근거 있는 판단을 내리기 어렵다.

세 개념의 경계는 생각보다 명확하지 않다

이 세 가지는 완전히 분리된 개념이 아니라, 서로 겹치는 영역이 있다.

Metrics ∩ Tracing - 요청별 지연 시간. 특정 요청의 응답 시간은 트레이싱이면서 동시에 집계 가능한 메트릭이기도 하다.
Tracing ∩ Logging - 요청 안에서 발생한 이벤트 로그. 특정 요청 흐름 내에서 남긴 에러 로그는 둘 다에 해당한다.
Metrics ∩ Logging - ELK의 rollup처럼, 로그를 집계해 수치화한 것. 이벤트를 모아 메트릭으로 표현하는 경우다.

그럼에도 이 셋을 구분해서 이해해야 하는 이유는, 필요한 상황에 적절한 도구를 선택하기 위해서다.
분리하려고가 아니라, 각각의 역할을 명확히 알아야 상황에 맞게 조합할 수 있다.

볼륨과 비용의 트레이드오프

세 가지 중 어느 것이 "더 좋다"는 개념은 없다.
데이터 볼륨과 운영 비용, 그리고 얻을 수 있는 정보의 깊이가 각각 다를 뿐이다.

	Metrics	Tracing	Logging
데이터 볼륨	낮음	중간	매우 높음
운영 비용	낮음	중간	높음
맥락의 깊이	낮음 (수치만)	중간	높음 (상세 이벤트)
요청과의 연관성	무관 가능	항상 연관	상황에 따라 다름

세 원이 모두 겹치는 영역, 즉 Request-Scoped이면서 Aggregatable이고 Event이기도 한 데이터는 설계 판단이 필요한 영역이다.
예를 들어 해당 데이터를 로깅 파이프라인으로 보내면 디테일을 얻는 대신 처리 비용이 올라가고, 메트릭으로 집계하면 비용은 낮아지지만 맥락을 잃는다.
이것도 하나의 트레이드오프다.