1. 개요
“모니터링 되고 있다” 는 말이 로그만 쌓아두는 걸 뜻하는 경우도, 대시보드에 그래프만 떠 있는 걸 뜻하는 경우도 있다. 관측성(observability)은 보통 로그(log)·메트릭(metric)·트레이스(trace) 세 가지 축으로 얘기한다. 이번 편은 이 셋이 각각 뭘 답해주는 도구인지, 그리고 왜 하나만 있어서는 부족한지를 정리한다.
2. 핵심 내용
2-1. 메트릭: “지금 시스템이 어떤 상태인가”
메트릭은 시간에 따라 숫자로 집계된 값이다. CPU 사용률, 요청 수, 에러율, p99 지연시간 같은 것들이다. 개별 요청 하나하나를 남기지 않고 숫자만 집계하기 때문에 저장 비용이 싸고, 대시보드와 알림(alert)을 걸기에 가장 좋다. “지난 5분간 5xx 비율이 5% 를 넘었다” 같은 알림은 메트릭이 답한다.
단점은 왜 그런지는 말해주지 않는다는 것이다. 에러율이 올라간 건 알 수 있지만, 어떤 요청이 왜 실패했는지는 메트릭만으로는 못 본다.
2-2. 로그: “그 순간 무슨 일이 있었나”
로그는 특정 시점에 발생한 이벤트를 텍스트로 남긴 기록이다. 예외 스택 트레이스, 요청 파라미터, 에러 메시지가 여기 들어간다. 메트릭이 “에러율이 올라갔다” 고 알려주면, 그 시간대 로그를 뒤져서 실제로 어떤 예외가 터졌는지 확인하는 식으로 쓴다.
문제는 마이크로서비스 환경에서는 요청 하나가 여러 서비스를 거치는데, 로그는 서비스별로 따로 쌓인다는 것이다. 어떤 요청이 A 서비스에서 B, C 서비스로 넘어가면서 느려졌는지 로그만으로 추적하려면, 서비스마다 로그를 열어서 시간과 요청 ID 를 손으로 맞춰봐야 한다.
2-3. 트레이스: “요청이 어디를 거쳐서 어디서 느려졌나”
트레이스는 요청 하나가 여러 서비스를 거치는 전체 경로를 하나의 단위로 묶어서 보여준다. 요청이 시작될 때 trace ID 를 하나 발급하고, 요청이 다음 서비스로 넘어갈 때마다 이 ID 를 헤더에 실어 전파한다. 각 서비스는 자기가 처리한 구간을 span 이라는 단위로 기록하고, 나중에 이 span 들을 trace ID 로 묶으면 “게이트웨이 10ms → 인증 서비스 5ms → 주문 서비스 450ms → DB 쿼리 420ms” 처럼 요청이 어디서 시간을 다 썼는지 한눈에 보인다.
메트릭이 “느려졌다” 를, 로그가 “이런 에러가 났다” 를 답한다면, 트레이스는 “정확히 어느 구간에서” 를 답한다.
2-4. 왜 셋 다 있어야 하나
셋은 서로 대체재가 아니라 보완재다. 실제 장애 대응 흐름을 순서대로 보면 이렇다.
- 메트릭 알림으로 “5xx 비율이 올라갔다” 는 걸 안다. (뭔가 이상하다)
- 그 시간대 트레이스를 봐서 어느 서비스, 어느 구간에서 지연이나 에러가 몰렸는지 좁힌다. (어디서)
- 그 서비스의 그 시점 로그를 열어서 정확히 어떤 예외, 어떤 파라미터였는지 확인한다. (왜)
메트릭만 있으면 알림은 받아도 원인 파악이 로그 전체를 뒤지는 수작업이 되고, 로그만 있으면 애초에 뭐가 이상한지 알림을 걸기가 애매하다. 트레이스 없이 로그와 메트릭만 있으면 마이크로서비스 환경에서 “어디서” 를 찾는 단계가 제일 오래 걸린다.
실제로 이 세 가지를 한 파이프라인으로 모으는 작업에서 자주 걸려 넘어지는 지점은 수집기 설정이다. OpenTelemetry Collector 계열 에이전트로 메트릭·로그·트레이스를 한 번에 모으는 구성을 많이 쓰는데, 프로세서 이름 하나가 배포판마다 달라서 설정 파일은 문법상 정상인데 파드만 계속 죽는 경우가 있다. DoEatFit 을 단일 서버에서 k3s 로 옮긴 글에서도 관측 스택을 Prometheus/Grafana LXC 에서 Alloy 를 거쳐 중앙 스택으로 보내는 구조로 바꾼 얘기가 나오는데, 이런 구성 변경 자체가 수집기 설정의 미묘한 차이 때문에 조용히 깨지기 쉬운 지점이다. ArgoCD 의 sync 는 YAML 문법만 검사하지 그 안의 프로세서 이름이 실제로 존재하는지는 모르기 때문에, 잘못된 설정이 배포까지는 통과하고 파드 로그를 열어봐야 원인이 보이는 경우가 종종 있다.
3. 마무리
요약
- 메트릭은 “지금 상태가 이상한가”, 로그는 “그 순간 무슨 일이 있었나”, 트레이스는 “요청이 어디를 거쳐 어디서 느려졌나” 를 답한다.
- 셋은 서로 대체재가 아니라 장애 대응의 서로 다른 단계(감지 → 범위 좁히기 → 원인 확인)를 담당한다.
- 관측 파이프라인의 수집기 설정은 문법 검사를 통과해도 조용히 깨질 수 있어, 배포 후 실제 파드 상태까지 확인해야 한다.
다음은 8편: CI·CD 파이프라인, 단계별로 뭘 하는 건가 다.