[Prometheus & Grafana] Chapter 1. 왜 모니터링이 필요한가

참고: 이 글은 Prometheus (v3.2.1)와 Grafana 공식 문서를 기반으로 요약·정리한 내용입니다. 정확한 내용은 공식 문서를 참조해 주세요.

• Prometheus 공식 문서
• Grafana 공식 문서

---

1.1 장애의 비용과 모니터링의 가치

현대 IT 시스템은 복잡하다. 마이크로서비스 아키텍처, 컨테이너화, 클라우드 인프라의 도입으로 운영해야 할 구성 요소가 수십에서 수백 개에 달하는 환경이 일반적이다. 이러한 환경에서 장애가 발생하면 그 비용은 상상 이상으로 크다.

장애 비용의 구성

장애 비용은 단순히 서비스가 중단된 시간만을 의미하지 않는다.

• 직접적 비용: 서비스 중단으로 인한 매출 손실, SLA(Service Level Agreement) 위반에 따른 위약금
• 간접적 비용: 고객 이탈, 브랜드 신뢰도 하락, 엔지니어의 야간 대응에 따른 생산성 저하
• 기회 비용: 장애 대응에 투입된 인력이 신규 기능 개발에 참여하지 못하는 손실

Amazon의 경우, 1분의 다운타임이 약 $220,000의 매출 손실로 이어진다는 연구가 있다. 규모가 작은 서비스라 하더라도 장애의 반복은 조직에 큰 부담이 된다.

모니터링이 해결하는 문제

모니터링은 장애를 "예방"하고, 발생 시 "신속하게 감지"하며, "원인을 빠르게 파악"하는 세 가지 핵심 역할을 수행한다.

1. 사전 감지 (Proactive Detection): 디스크 사용률이 80%에 도달했을 때 알림을 보내, 100%에 도달하여 서비스가 중단되기 전에 대응할 수 있다.
2. 신속한 장애 인지 (Rapid Awareness): 사용자가 불만을 제기하기 전에, 에러율 급증을 자동으로 감지하여 엔지니어에게 알린다.
3. 원인 분석 (Root Cause Analysis): "서버가 느리다"는 증상에서 "특정 데이터베이스 쿼리의 지연"이라는 원인으로 빠르게 추적할 수 있다.

모니터링의 성숙도 모델

조직의 모니터링 역량은 다음 단계로 발전한다.

단계	설명	예시
Level 0	모니터링 없음	사용자 불만으로 장애 인지
Level 1	기본 가용성 확인	ping, 포트 체크
Level 2	메트릭 수집	CPU, 메모리, 디스크 사용률
Level 3	알림 자동화	임계값 기반 알림 발송
Level 4	대시보드 기반 운영	Grafana 대시보드로 실시간 모니터링
Level 5	옵저버빌리티	메트릭 + 로그 + 트레이스 통합 분석

이 학습서를 통해 Level 2에서 Level 4까지의 역량을 확보하는 것을 목표로 한다.

---

1.2 옵저버빌리티 3요소: 메트릭, 로그, 트레이스

옵저버빌리티(Observability)는 시스템의 외부 출력만으로 내부 상태를 파악할 수 있는 능력을 의미한다. 이를 구성하는 세 가지 핵심 신호(signal)가 있다.

메트릭 (Metrics)

메트릭은 숫자로 표현되는 측정값이다. 특정 시점의 시스템 상태를 수치화한 것으로, 시간에 따른 변화를 추적하기에 가장 적합하다.

특징:

• 저장 효율이 높다 (숫자 + 타임스탬프 = 매우 작은 데이터)
• 집계와 수학 연산이 가능하다 (평균, 합계, 백분위수 등)
• 시간 범위에 걸친 트렌드 분석에 적합하다

예시:

http_requests_total{method="GET", status="200"} = 15234
node_cpu_seconds_total{mode="idle"} = 82340.56

메트릭은 "무슨 일이 일어나고 있는가?"에 대한 답을 제공한다. Prometheus가 담당하는 영역이다.

로그 (Logs)

로그는 이벤트의 텍스트 기록이다. 구조화된(structured) 또는 비구조화된(unstructured) 형태로 시스템의 개별 이벤트를 기록한다.

특징:

• 풍부한 컨텍스트를 포함한다 (에러 메시지, 스택 트레이스 등)
• 저장 비용이 메트릭보다 높다
• 검색과 패턴 분석이 가능하다

예시:

2026-03-26 10:15:23 ERROR [PaymentService] Failed to process payment for user_id=12345: timeout after 30s

로그는 "왜 그런 일이 일어났는가?"에 대한 답을 제공한다. Loki, Elasticsearch 등이 담당한다.

트레이스 (Traces)

트레이스는 요청의 전체 경로를 추적한 기록이다. 마이크로서비스 환경에서 하나의 요청이 여러 서비스를 거치는 과정을 시각화한다.

특징:

• 서비스 간 호출 관계를 파악할 수 있다
• 각 단계의 소요 시간을 정확히 측정한다
• 병목 지점을 직관적으로 식별할 수 있다

예시:

[API Gateway] 2ms → [Auth Service] 5ms → [Order Service] 150ms → [DB Query] 145ms

트레이스는 "어디에서 시간이 소요되었는가?"에 대한 답을 제공한다. Jaeger, Tempo 등이 담당한다.

세 신호의 상호 보완

질문	적합한 신호
에러율이 얼마인가?	메트릭
어떤 에러가 발생했는가?	로그
에러가 어느 서비스에서 시작되었는가?	트레이스
지난 1시간 동안 요청량이 얼마나 증가했는가?	메트릭
특정 사용자의 요청이 왜 실패했는가?	로그 + 트레이스

공식 문서에서는 세 신호 중 메트릭에 집중한다. Prometheus로 메트릭을 수집하고, Grafana로 시각화하는 것이 핵심 내용이다.

---

1.3 Prometheus + Grafana 생태계 개요

Prometheus란?

Prometheus는 2012년 SoundCloud에서 개발되어 2016년 CNCF(Cloud Native Computing Foundation)의 두 번째 졸업 프로젝트가 된 오픈소스 모니터링 시스템이다.

핵심 특징:

• 다차원 데이터 모델: 메트릭 이름과 레이블(key-value 쌍)로 시계열을 식별
• PromQL: 다차원 데이터를 유연하게 조회하는 전용 쿼리 언어
• Pull 모델: HTTP를 통해 대상 시스템에서 메트릭을 가져온다
• 독립적 운영: 분산 스토리지에 의존하지 않는 단일 서버 아키텍처
• 서비스 디스커버리: Kubernetes, Consul 등과 연동하여 대상을 자동 탐지

Grafana란?

Grafana는 메트릭, 로그, 트레이스를 시각화하는 오픈소스 플랫폼이다.

핵심 특징:

• 풍부한 시각화: 25종 이상의 차트 유형
• 동적 대시보드: 템플릿 변수를 사용한 드롭다운 기반 필터링
• 알림: 조건 기반 알림 규칙과 다양한 알림 채널
• 탐색(Explore): 대시보드 없이 즉석에서 쿼리를 실행하고 결과를 확인
• 프로비저닝: 코드(YAML, Terraform)로 대시보드와 데이터소스를 관리

---

1.4 다른 모니터링 도구와의 비교

전통적인 모니터링 도구

도구	특징	Prometheus 대비
Nagios	체크 기반, 에이전트 방식, 1999년 출시	다차원 데이터 모델 없음, 확장성 제한
Zabbix	에이전트 기반, 풍부한 UI, 데이터베이스 저장	SQL 기반 쿼리로 복잡한 집계 어려움
Munin	그래프 중심, RRDtool 기반	레이블 개념 없음, 유연한 쿼리 불가

현대적인 모니터링 도구

도구	특징	Prometheus 대비
Datadog	SaaS, 풍부한 통합, 에이전트 방식	상용 서비스 (비용 발생), 벤더 종속
New Relic	APM 중심, SaaS	인프라 모니터링보다 애플리케이션 중심
InfluxDB + Telegraf	Push 모델, 범용 시계열 DB	SQL 유사 쿼리 (PromQL만큼 강력하지 않음)

Prometheus가 적합한 경우

• 순수한 숫자 기반 시계열 데이터 수집
• 기계(machine) 중심의 인프라 모니터링
• 동적 마이크로서비스 아키텍처
• 다차원적 수집과 쿼리가 필요한 환경

Prometheus가 부적합한 경우

"100% 정확도가 요구되는 경우, 예를 들어 요청 단위 과금(per-request billing)에는 적합하지 않다." - Prometheus 공식 문서

메트릭 수집에는 본질적으로 약간의 데이터 손실 가능성이 있으며, 이는 모니터링 목적으로는 무시할 수 있지만 금융 정산에는 적합하지 않다.