[Infra] Prometheus와 Grafana로 우리 서비스의 개선점과 에러 찾기

들어가며

현재 소마를 진행하며 유저를 모으고! 돈도 벌 수 있고, 6개월 동안 애정을 담아 만들 수 있는 서비스를 기획하기 위해 정말 고군분투 중이다.

애정을 담아 만들 서비스의 CPU나 메모리는 어떠한지 혹은 DB 연결 풀은 괜찮은지 파악하며 개발을 진행해야, 어느정도 리소스를 할당해야 할지 결정하고 예측할 수 있다고 생각한다!

특히 우리가 만들 서비스의 핵심 API는 응답시간이 매우 중요해질 것 같기에, 그 상황별 응답시간을 한눈에 보기좋게 정리한다면 향후 기획적 기술적 개선에 큰 도움이 될 것이라고 확신한다. 그런 의미에서 매트릭을 수집하고 보여주는 대표적인 오픈소스인 Prometheus와 Grafana를 알아보려고 한다~!

본문으로

Monitoring vs Observability ?

제대로 들어가기전에 모니터링에 대해 구글링하다보면 Monitoring과 Observability라는 용어가 혼용된다. 둘 다 시스템 상태를 보는 것처럼 들리기 때문이다. 하지만 두 개념은 다른 개념이다.

Monitoring은 시스템에 문제가 생겼는지 감지하는 활동이다. 예를 들어 CPU 사용률이 급격히 증가했는지, 메모리가 부족해졌는지, API 응답 시간이 길어졌는지, 에러율이 증가했는지를 확인하는 것이다. 즉, Monitoring은 “지금 서비스가 정상인가?”, “문제가 발생했는가?”에 답하는 데 가깝다.

반면 Observability는 문제가 발생했을 때 그 원인을 추적할 수 있도록 시스템 내부 상태를 드러내는 능력에 가깝다. 일반적으로 Observability는 다음 세 가지 요소로 설명된다.

Metrics	숫자로 표현되는 시계열 데이터	CPU 사용률, 메모리 사용량, 요청 수, 에러율
Logging	프로그램 내부에서 남긴 로그	“주문 생성 실패”, “DB 연결 실패”
Tracing	요청이 여러 서비스나 함수 사이를 어떻게 흘러갔는지 추적	A API → B 서비스 → DB 호출 흐름

Logging과 Tracing도 중요하지만, 이번에 다루는 Prometheus와 Grafana는 이 중에서도 주로 Metrics 수집과 시각화에 초점을 둔다.

(나중에는 완성도 있는 Observability가 있는 서비스를 만들어야지~!)

Whitebox vs Blackbox ?

모니터링을 이야기할 때 Whitebox와 Blackbox라는 개념도 자주 나온다. 인프라 관련 질문에서 꽤 자주 등장할 수 있는 부분이다. 결론 먼저 말하자면 아래와 같다.

Blackbox Monitoring
→ 시스템 내부를 모른 채 외부에서 상태를 확인한다.

Whitebox Monitoring
→ 시스템 내부 지표를 직접 보고 상태를 확인한다.

예를 들어 어떤 서버에 HTTP 요청을 보내서 200 OK가 오는지만 확인한다면 Blackbox Monitoring에 가깝다.

[모니터링 서버] ── 요청 ──> [서비스]
        <── 200 OK ──

반면 Whitebox Monitoring은 서버 내부의 CPU, 메모리, 디스크, 네트워크, 애플리케이션 지표 등을 직접 확인한다.

[서버 내부]
├── CPU 사용률
├── Memory 사용량
├── Disk 사용량
├── Network I/O
└── Application Metrics

Prometheus는 대표적인 Whitebox Monitoring 도구라고 볼 수 있다.
서버 내부에서 노출한 지표를 수집하고, 그 지표를 바탕으로 시스템 상태를 유추할 수 있기 때문이다.

네이버 키고 운영자 도구를 키면 대부분 Blackbox Monitoring의 느낌이다~!

그래서 Prometheus, Granfana, Expoter가 뭔데?!

처음에는 Prometheus, Exporter, Grafana의 역할이 헷갈릴 수 있다. 간단히 정리하면 다음과 같다.

Exporter
→ 서버 지표를 /metrics로 노출한다.

Prometheus
→ /metrics를 주기적으로 수집하고 저장한다.

Grafana
→ Prometheus 데이터를 조회해서 대시보드로 보여준다.

그렇다면 전체 흐름은 아래처럼 정리할 수 있다. (정확한 포트는 커스터마이징 가능~!)

[Server / Node]
      |
      | 시스템 지표 수집
      v
[Node Exporter : 9100/metrics]
      |
      | HTTP GET Scraping
      v
[Prometheus : 9090]
      |
      | PromQL Query
      v
[Grafana Dashboard]

흐름은 알겠고... 자세히 하나씩 풀어보자

Exporter

Exporter는 노드, 즉 인스턴스 쪽에 설치된다. (서버 운영체제별로 다르니 확인 꼭 필요!)
서버의 CPU, 메모리, 디스크, 네트워크 같은 정보를 수집해서 Prometheus가 읽을 수 있는 형태로 노출한다.

http://서버IP:9100/metrics

이 주소에 접근하면 Prometheus가 이해할 수 있는 key-value 형태의 데이터가 노출된다.

node_cpu_seconds_total{cpu="0",mode="idle"} 12345.67
node_memory_MemAvailable_bytes 123456789
node_filesystem_avail_bytes{mountpoint="/"} 987654321

Prometheus

Prometheus는 Exporter의 /metrics 주소로 주기적으로 HTTP GET 요청을 보낸다.

Prometheus ── GET ──> 서버IP:9100/metrics

그리고 가져온 데이터를 내부 시계열 DB에 저장한다.
이후 PromQL이라는 쿼리 언어를 사용해서 원하는 지표를 조회할 수 있다.

Granfana

Grafana는 Prometheus를 Data Source로 연결한 뒤, Prometheus에 쿼리를 날리고 그 결과를 그래프와 대시보드로 보여준다.

Grafana
   ↓
Prometheus에 PromQL 질의
   ↓
결과를 그래프, 차트, 대시보드로 시각화

Metrics 수집 방식: Push vs Pull

Metrics를 수집하는 방식은 크게 Push 방식과 Pull 방식으로 나눌 수 있다.

풀 ~~?

Pull 방식은 모니터링 서버가 각 노드에 직접 요청해서 지표를 가져오는 방식이다.

Prometheus가 대표적인 Pull 방식의 모니터링 도구다. Prometheus는 Exporter에게 주기적으로 HTTP 요청을 보낸다. 이 과정을 Scraping이라고 한다.
그리고 /metrics 경로에 노출된 데이터를 가져와 내부 시계열 DB에 저장한다.

[Prometheus] ── GET /metrics ──> [Exporter]
[Prometheus] <── metrics ────── [Exporter]

Pull 방식의 장점은 모니터링 서버가 수집 주기와 대상을 통제하기 쉽다는 점이다. 매트릭이 궁금한 대상에게 필요한 주기로 가져올 수 있고, 각 노드는 지표를 노출하기만 하면 된다.

다만 Prometheus가 수집할 대상, 즉 Node나 Exporter의 위치를 알고 있어야 한다. -> Node가 너무 많아지면 모니터링 서버가 알아야할 책임이 너무 커진다!

푸쉬~~?

Push 방식은 반대로 각 노드가 모니터링 서버에 직접 데이터를 보내는 방식이다.

[Node A] ── push metrics ──> [Monitoring Server]
[Node B] ── push metrics ──> [Monitoring Server]
[Node C] ── push metrics ──> [Monitoring Server]

이 방식은 노드들이 알아서 데이터를 밀어 넣는 구조다.(푸쉬푸쉬 베이베)
모니터링 서버 입장에서는 모든 노드의 세부 위치를 직접 Scraping 대상으로 관리하지 않아도 되는 장점이 있다.

다만 많은 노드가 동시에 데이터를 밀어 넣으면 모니터링 서버에 부하가 몰릴 수 있다.

오픈소스는 언제나 바뀌기 마련이니! 이러한 Pull, Push 방식의 장단점을 이해하고 상황에 맞는 기술을 적용하자!

Exporter에 대해 더 깊게 알아보자.

Exporter는 데이터를 계속 쌓아두는 저장소가 아니다. Exporter는 현재 시점의 시스템 상태를 읽어서 /metrics로 노출하는 역할에 가깝다.

[서비스 서버]
├── 실제 애플리케이션
├── DB Client
├── Nginx
└── Exporter

이때 Exporter가 데이터를 계속 쌓다가 서비스보다 더 많은 리소스를 사용하게끔 가능하다면, 운영 중인 서비스에 악영향을 줄 수 있다.

극단적으로는 OS의 리소스 경쟁 상황에서 서비스 프로세스나 Exporter 둘 중 하나가 죽을 수도 있다. (OS의 우선순위 선점~!)

그래서 Exporter는 데이터를 무한히 저장하는 구조가 아니라, 필요한 순간의 상태를 스냅샷처럼 노출하는 방식이 적절하다.

Exporter의 역할
잘못된 방향: 데이터를 계속 저장하고 큐잉한다.
올바른 방향: 현재 상태를 읽어 /metrics로 노출한다.

모니터링도 중요하지만, 더 중요한 것은 실제 서비스가 안정적으로 동작하는 것이지 않겠는가!

그렇다면 Exporter는 어떻게 시스템 정보를 가져올까?!?

Node Exporter 같은 도구는 운영체제에서 제공하는 정보를 읽어서 지표로 변환한다.

리눅스에서는 /proc, /sys 같은 경로를 통해 CPU, 메모리, 디스크, 네트워크, 프로세스 관련 정보를 확인할 수 있다.

Linux System
├── /proc
├── /sys
└── kernel에서 제공하는 시스템 정보
        ↓
   Node Exporter
        ↓
   /metrics로 노출

비유하자면 우리가 작업 관리자나 제어판에서 CPU 사용률, 메모리 사용량을 확인하는 것처럼, Exporter도 운영체제가 제공하는 시스템 정보를 읽어서 Prometheus가 이해할 수 있는 형식으로 바꿔주는 것이다.

Exporter를 꺼진 사실은 바로 알 수 없다!!

Exporter를 껐다고 해서 Grafana 대시보드에 즉시 반영되는 것은 아니다. 왜냐하면 Prometheus는 일정 주기마다 Exporter의 /metrics를 Scraping하기 때문이다.

00:00 Prometheus Scraping
00:30 Exporter 종료
01:00 다음 Scraping 시도
01:00 실패 감지

만약 Scraping 주기가 1분이라면, Exporter가 죽은 뒤 최대 1분 정도 지나서야 Prometheus가 이상을 감지할 수 있다.

즉, 장애 발생 시점과 감지 시점 사이에는 간격이 생길 수 있다. 그래서 중요한 서비스라면 Scraping 주기, Alert 기준, 대시보드 표시 방식까지 함께 고민해야 한다.

Golden Signal: 우리 팀은 무엇을 봐야할까?

모니터링을 시작하면 볼 수 있는 지표가 정말 많다. CPU, 메모리, 디스크, 네트워크, 요청 수, 응답 시간, 에러 수, GC, DB 커넥션, 스레드 수 등 끝이 없다.

Google SRE에서는 대표적으로 다음 네 가지 지표를 중요하게 본다. 이를 Golden Signal이라고 부른다. (거의 SRE측면에서 바이블이라고 불린다..)

https://sre.google/sre-book/monitoring-distributed-systems/#xref_monitoring_golden-signals

Google SRE monitoring ditributed system - sre golden signals

Monitoring Distributed Systems Written by Rob EwaschukEdited by Betsy Beyer Google’s SRE teams have some basic principles and best practices for building successful monitoring and alerting systems. This chapter offers guidelines for what issues should in

sre.google

Golden Signals
├── Traffic
├── Latency
├── Errors
└── Saturation

사실 보면 너무나 당연한 말이다... 왜 이렇게 포괄적이고 당연한 말을 Golden Signal이라고 표현할까?

중요한 지표는 서비스의 성격에 따라 달라진다.

결제 서비스
→ 결제 실패율
→ 결제 응답 시간
→ 결제 중복 처리 여부
→ PG 연동 실패율

검색 / 포털 서비스
→ 1초 이내 렌더링
→ 검색 응답 시간
→ 메인 페이지 로딩 시간

게임 서비스
→ Latency
→ 동시 접속자 수
→ 서버 Tick 지연
→ 네트워크 끊김

결국 중요한 것은 팀에서 중요하게 보는 지표를 정하라는 것이다!(바이블 특.. 보편적인 것만 말함!)

이번 프로젝트에서 우리팀에서 중요하게 볼 지표를 정해보자!!

마지막으로

결론은 아래처럼 프로메테우스로 수집하는 것을 Granfana로 보여주는 플로우까지는 구축했는데,,, 아직 서비스가 개발 된 것은 아니라 더이상 크게 진행할 것은 없다!

그래도 요즘 서비스 개발은 너무 빠르게 할 수 있으니, 개발 진행이 된다면 빠르게 붙혀서 기획적 기술적 개선을 바라보자.

이번 기회에 이렇게 모니터링 플로우를 구축해봤는데, 괜히 좀 멋있고(?) 그렇다. 이런 좋은 느낌을 우리 프로젝트에 적용해서 좋은 의사소통 증거로 사용될 수 있는 매트릭을 수집해보자! 아자자~! 파이팅!

'Infra' 카테고리의 다른 글

[Infra] Container 딥다이브 - Linux Kernel에서 시작하는 Docker 자세히 알아보기 (0)	2026.05.28
[Infra] 모니터링 서버 도입 전에 할 수 있는 부하 테스트와 성능 병목 확인(Amazon CodeGuru Profiler + k6 스트레스 테스트) (0)	2026.05.24
[Infra] 인스턴스 연결성 검사 실패 문제. 메모리가 부족하면 ssh 연결도 막힌다. (0)	2026.02.21
[Infra] Blue/Green 무중단 배포 (Docker, Nginx, GitHub Actions) 구현해보기 (5)	2025.11.21

들어가며

본문으로

Monitoring vs Observability ?

Whitebox vs Blackbox ?

그래서 Prometheus, Granfana, Expoter가 뭔데?!

Exporter

Prometheus

Granfana

Metrics 수집 방식: Push vs Pull

풀 ~~?

푸쉬~~?

Exporter에 대해 더 깊게 알아보자.

그렇다면 Exporter는 어떻게 시스템 정보를 가져올까?!?

Exporter를 꺼진 사실은 바로 알 수 없다!!

Golden Signal: 우리 팀은 무엇을 봐야할까?

마지막으로

'Infra' 카테고리의 다른 글

티스토리툴바