Cloud & DevOps

모니터링과 옵저버빌리티 — 실전 구축 가이드

로그, 메트릭, 트레이스 기반의 관측 가능성 구축 방법을 정리한다. OpenTelemetry 설정, Grafana·Prometheus·Loki 스택 구성, 알림 정책과 대시보드 설계 실전 가이드를 포함한다.

2026-02-26

한 줄 요약: 모니터링은 '무엇이 문제인가'를 알려주고, 옵저버빌리티는 '왜 문제인가'까지 알려준다. 로그/메트릭/트레이싱의 3가지 신호를 수집해야 한다.

프로덕션 서비스 운영에서 장애 감지와 원인 분석의 핵심인 옵저버빌리티 스택 구축법을 정리한다. Prometheus, Grafana, OpenTelemetry, Sentry 등 도구의 역할과 실전 설정을 다룬다.

옵저버빌리티의 3기둥

Logs: 무엇이 일어났는가 (이벤트 기록). Metrics: 얼마나 일어났는가 (수치 데이터). Traces: 어떤 경로로 일어났는가 (요청 추적). 셋을 조합해야 문제의 전체 그림이 보입니다.

옵저버빌리티의 3대 축: 로그(Logs)는 이벤트의 상세 기록이다. 에러 메시지, 요청 파라미터, 스택 트레이스를 포함한다. 메트릭(Metrics)은 시계열 숫자 데이터다. CPU 사용률, 응답 시간 p95, 초당 요청 수(RPS) 등. 트레이싱(Traces)은 하나의 요청이 여러 서비스를 거치는 경로를 추적한다. 마이크로서비스 환경에서 병목을 찾는 핵심 도구다.

도구 스택: 메트릭 수집은 Prometheus, 시각화는 Grafana, 로그 수집은 Loki 또는 ELK(Elasticsearch+Logstash+Kibana), 트레이싱은 Jaeger 또는 Tempo. OpenTelemetry(OTel)는 이 3가지 신호를 하나의 SDK로 수집하는 표준이다.

OpenTelemetry Node.js 초기화
// tracing.ts
import { NodeSDK } from '@opentelemetry/sdk-node';
import { OTLPTraceExporter } from
  '@opentelemetry/exporter-trace-otlp-http';

const sdk = new NodeSDK({
  traceExporter: new OTLPTraceExporter({
    url: 'http://otel-collector:4318/v1/traces'
  }),
  instrumentations: [getNodeAutoInstrumentations()]
});
sdk.start();

알림 설계 원칙

알림이 너무 많으면 '알림 피로(Alert Fatigue)'가 발생해 중요한 알림을 놓치게 된다. 원칙 1: 즉각 대응이 필요한 알림만 Slack/PagerDuty로 보낸다. 원칙 2: SLO(Service Level Objective) 기반으로 알림을 설정한다 — 예: '응답 시간 p99가 5분 동안 2초 초과'. 원칙 3: 모든 알림에 대응 가이드(runbook)를 링크한다.

시작 추천: 처음에는 Sentry(에러 모니터링) + Grafana Cloud(무료 플랜으로 메트릭/로그/트레이싱 통합)로 시작하라. 이 두 도구만으로 대부분의 중소 규모 서비스의 옵저버빌리티 요구를 충족할 수 있다.

모니터링옵저버빌리티로그메트릭트레이스

모니터링과 옵저버빌리티 — 실전 구축 가이드

옵저버빌리티의 3기둥

추천 도구 스택

알림 설계 원칙

관련 포스트