관측 가능성: 로그, 트레이스, 메트릭

관측 가능성이란

관측 가능성(observability)은 시스템이 밖으로 내보내는 신호만으로 내부 상태를 추론할 수 있는 정도다. 모니터링이 "미리 정한 지표가 정상인가"를 본다면, 관측 가능성은 "처음 보는 장애가 왜 일어났는가"에 답할 수 있게 한다. 그 신호의 세 기둥이 로그, 트레이스, 메트릭이다.

세 기둥 비교

세 신호는 따로 볼 때보다 이어질 때 힘이 크다. 메트릭 알림으로 이상을 알아채고, 트레이스로 느린 구간을 찾고, 그 구간의 로그로 원인을 읽는다. 이를 위해 로그에 트레이스 ID를 함께 남긴다.

각 신호의 수집 구조

로그

flowchart LR
  app["앱"] -->|"구조화 로그: JSON"| col["수집기(에이전트)<br/>Filebeat, Fluent Bit"]
  col --> proc["처리·파싱<br/>Logstash"]
  proc --> store["저장·색인<br/>Elasticsearch"]
  store --> view["검색·대시보드<br/>Kibana"]

• 팀마다 형식이 다르면 수많은 로그에서 키워드로 찾을 수 없다. 표준 로그 형식(타임스탬프, 레벨, 서비스 이름, 트레이스 ID, 메시지)을 정해 모든 팀이 따른다.
• 양이 가장 많으므로 보존 기간과 레벨을 정해 비용을 관리한다.
• 서버 한 대의 로그를 셸 명령으로 훑는 법은 자주 쓰는 리눅스 명령어 지도에 있다.
• 수집기도 감시 대상이다. 서버마다 도는 로그 에이전트가 죽거나 막히면 로그가 조용히 사라지고, 로그가 없으니 알아채지도 못한다. 에이전트를 서비스 디스커버리에 등록해 살아 있는 목록을 자동으로 관리하고, 에이전트별 입력·출력 처리량을 지표로 수집해 「입력은 있는데 출력이 0」, 「처리량이 평소의 절반 이하」 같은 조건에 알림을 건다.

로그를 쓰는 규칙

트레이스

트레이스는 스팬(span) 의 트리다. 스팬 하나가 "서비스 B의 DB 조회, 120ms" 같은 한 구간이고, 요청이 서비스 경계를 넘을 때 트레이스 ID를 헤더(W3C traceparent)로 넘겨 같은 트레이스로 묶는다. 요청이 많은 서비스는 일부만 저장하는 샘플링을 쓴다.

메트릭

flowchart LR
  prom["Prometheus"] -->|"scrape"| app["앱 /metrics"]
  prom -->|"규칙 평가"| am["Alertmanager"]
  am --> notify["메일·SMS·Slack"]
  prom -->|"query"| graf["Grafana 대시보드"]

메트릭 하나는 이름 + 라벨 + (시각, 값) 목록이다. http_requests_total{service="order", status="500"}처럼 라벨 조합마다 별도 시계열이 생기므로, 사용자 ID처럼 값이 무한한 것을 라벨에 넣으면 시계열 수(카디널리티)가 폭발한다.

무엇을 잴지는 층마다 다르다. 서비스 층은 요청 수·오류율·지연(RED: Rate, Errors, Duration), 자원 층은 사용률·포화·오류(USE)를 기본으로 본다. 런타임 층은 언어마다 고유한 지표가 있다. Node.js라면 다음이다.

프로세스 지표만으로는 사용자가 실제로 접속되는지 모르므로, 여러 지역에서 외부 검사(아래 합성 모니터링)를 함께 둔다.

OpenTelemetry: 세 신호를 한 표준으로

OpenTelemetry(OTel)는 로그·트레이스·메트릭을 수집하는 벤더 중립 표준이다. 앱은 OTel SDK로 계측하고, OTel Collector가 받아 가공한 뒤 원하는 백엔드(Prometheus, Jaeger, 상용 APM)로 보낸다. 백엔드를 바꿔도 앱 계측 코드는 그대로라서, 처음부터 들일수록 이득이다(스타트업 인프라 선택 원칙).

메트릭 수집: 풀 vs 푸시

어느 쪽이 정답인지는 정해져 있지 않다. 풀 모델에서 짧은 배치 작업은 Pushgateway에 결과를 밀어 넣고 Prometheus가 그곳을 긁는 식으로 섞어 쓴다.

풀 모델과 서비스 디스커버리

서버가 수시로 늘고 줄면 수집 대상 목록을 파일로 관리할 수 없다. 서비스가 자신을 서비스 디스커버리(쿠버네티스 API, Consul, ZooKeeper 등)에 등록하면 수집기가 목록을 받아 온다.

sequenceDiagram
  participant C as 수집기
  participant D as 서비스 디스커버리
  participant S as 각 서비스
  C->>D: 1. 대상 목록과 설정(수집 주기, IP, 타임아웃, 재시도) 조회
  C->>S: 2. HTTP GET /metrics
  Note over S: 클라이언트 라이브러리가 엔드포인트를 노출
  alt 대상이 바뀌면
    D->>C: 3. 디스커버리가 변경을 알림
  else 또는
    C->>D: 3. 수집기가 주기적으로 다시 조회
  end

푸시 모델의 고전적인 예가 Graphite다. collectd·statsd 같은 수집기가 네임스페이스 값 타임스탬프 한 줄을 Carbon 데몬(평문 2003 포트)에 보내면, 고정 크기 시계열 파일 형식 Whisper에 저장하고 Graphite-Web이 HTTP로 그래프와 데이터를 내준다. Grafana는 원래 Graphite용 대시보드로 시작했다. 지금은 풀 방식의 Prometheus와 Grafana가 주류이고 Graphite는 레거시로 남아 있다.

메트릭 저장소: 왜 시계열 DB인가

메트릭 데이터의 접근 패턴은 일반 업무 데이터와 다르다.

검증된 시계열 DB가 많으므로 저장소를 직접 만들거나 범용 DB를 억지로 맞추지 않는다.

합성 모니터링: 사용자 화면으로 확인하기

로그·메트릭·트레이스는 내 시스템 안의 신호다. 결제 대행 페이지, 제휴사 이벤트 페이지처럼 남이 운영하는 외부 링크가 깨져도 사용자에게는 내 서비스의 장애로 보인다. 이런 곳은 합성 모니터링(synthetic monitoring), 곧 스크립트가 사용자처럼 주기적으로 접속해 결과를 확인하는 방식으로 지킨다.

해결 비용이 영향보다 큰 특정 대상은 감시에서 잠시 빼는 판단도 필요하다. 한 브라우저 엔진만 쓰면 다른 엔진 사용자의 문제를 놓치므로 여러 엔진(Playwright의 Chromium·WebKit·Firefox)으로 넓힐 수 있다.

정리

• 메트릭으로 알아채고, 트레이스로 위치를 찾고, 로그로 원인을 읽는다. 셋을 트레이스 ID로 잇는다.
• 로그는 표준 형식, 메트릭은 라벨 카디널리티, 트레이스는 샘플링이 비용의 핵심이다.
• 계측은 OpenTelemetry 같은 표준에 붙여 백엔드를 바꿀 수 있게 둔다.
• 메트릭 수집은 풀과 푸시 중 하나를 고르되 짧은 작업처럼 맞지 않는 경우를 섞어 처리하고, 대상 목록은 서비스 디스커버리에 맡긴다.
• 쓰기 위주·시간 창 질의라는 접근 패턴 때문에 메트릭은 시계열 DB에 둔다.

관련 노트: 쿠버네티스 위 웹 서비스의 요청 경로와 구성 요소, 스타트업 인프라 선택 원칙, 배포 전략, 대규모 트래픽에서 서비스를 지키는 설계, 자주 쓰는 리눅스 명령어 지도, 서버 장애 진단 패턴