Prometheus와 Grafana, 각각 뭘 하는 녀석인가
Prometheus -- 데이터를 수집하는 엔진
Prometheus는 시계열 데이터베이스(TSDB)다. 쉽게 말하면, 일정 간격으로 서버들한테 "너 지금 상태 어때?" 하고 물어보고(Pull 방식), 그 응답을 저장하는 역할이다. PromQL이라는 자체 쿼리 언어로 데이터를 조회할 수 있고, Alertmanager와 연동하면 특정 조건에서 슬랙이나 이메일로 알림도 보내준다.
Grafana -- 데이터를 보여주는 대시보드
Grafana는 시각화 도구다. Prometheus가 모아둔 데이터를 그래프, 게이지, 히트맵 등 다양한 형태로 보여준다. Prometheus 웹 UI만으로도 그래프를 볼 수 있긴 한데, Grafana의 대시보드를 한 번 써보면 다시는 돌아갈 수 없다. 팀원들한테 공유하기도 편하다.
왜 이 둘을 같이 쓰는가
Prometheus는 수집과 저장에 특화되어 있고, Grafana는 시각화에 특화되어 있다. 서로의 약점을 정확히 보완하는 조합이라 업계 표준처럼 쓰인다. CNCF(Cloud Native Computing Foundation) 프로젝트이기도 해서 Kubernetes 환경과의 궁합도 최고다.
2026년 6월 기준 Prometheus 최신 안정 버전은 3.12.0(2026-05-28 출시)이다. 2.0 이후 7년 만에 나온 메이저인 3.0이 2024년 11월에 공개되면서 큰 변화가 있었다. Grafana는 2026년 4월 GrafanaCON에서 Grafana 13이 발표됐고 최신은 13.0.2(2026-06-02)다.
버전을 고정해 쓰는 게 안전하다. Prometheus 3.12는 2026년 7월 9일 지원 종료(EOS)가 예정돼 있으니, 새로 설치한다면 그 시점의 최신 패치 버전을 확인하고 올리자.
실전 구축 가이드 -- Docker Compose로 한 방에
구성 파일 준비
가장 빠른 방법은 Docker Compose를 사용하는 것이다. docker-compose.yml에 Prometheus, Grafana, 그리고 Node Exporter(서버 메트릭 수집기)를 정의한다. Prometheus의 설정 파일인 prometheus.yml에는 스크레이프 대상(targets)을 지정하는데, Node Exporter의 엔드포인트를 넣어주면 된다. 포트는 Prometheus 9090, Grafana 3000, Node Exporter 9100이 기본값이다.
Prometheus 스크레이프 설정
prometheus.yml의 핵심은 scrape_configs 섹션이다. scrape_interval을 15초로 잡고, static_configs에 모니터링할 서버 주소를 넣는다. 서버가 추가될 때마다 타겟을 추가하면 되는데, 나중에 서버가 많아지면 Service Discovery(SD) 기능을 쓰는 게 훨씬 편하다. AWS EC2 SD, Kubernetes SD 등 다양한 옵션이 있다.
Grafana 데이터소스 연결과 대시보드 임포트
Grafana에 접속한 뒤 Data Sources에서 Prometheus를 추가한다. URL에 http://prometheus:9090을 넣고 Save & Test를 누르면 끝이다. 대시보드는 처음부터 만들 필요 없다. Grafana 공식 대시보드 마켓플레이스에서 Node Exporter Full(ID: 1860)을 임포트하면 CPU, 메모리, 디스크, 네트워크 지표가 한눈에 보이는 대시보드가 바로 세팅된다.
Prometheus 3.x에서 달라진 것 (2026년 기준)
3.0 메이저 업데이트로 신규 구축 환경이라면 챙겨둘 만한 변화가 꽤 생겼다. 핵심만 정리하면 다음과 같다.
- OpenTelemetry(OTLP) 메트릭 직접 수신 -- 별도 컬렉터 없이 Prometheus가 OTLP 메트릭을 받을 수 있다. 엔드포인트는
/api/v1/otlp/v1/metrics이며, 기본은 비활성이라 명시적으로 활성화해야 한다. 다만 프로덕션에서는 Prometheus가 직접 받기보다 OpenTelemetry Collector를 중간 계층으로 두는 구성이 권장된다. - Remote Write 2.0 -- 네이티브 히스토그램, exemplar, 메타데이터가 기본 포함되며 전송량이 약 60% 감소한다. 단,
enable_http2의 기본값이 false로 바뀐 점은 알아두자. - 네이티브 히스토그램 -- 지수형 버킷을 쓰는 네이티브 히스토그램이 기본 적용돼, 고정 버킷보다 적은 비용으로 더 정밀한 분포를 본다.
- 메트릭·라벨 이름 UTF-8 전체 허용 -- 이름 규칙이 UTF-8 전체로 확장돼 도트(.) 등을 포함한 이름도 다룰 수 있다.
- 웹 UI 전면 개편 -- Mantine 기반으로 새로 단장됐고 트리뷰와 PromQL 쿼리를 풀어 설명해 주는 'Explain' 탭이 추가됐다.
2.x에서 올릴 때 제거·변경된 항목이 있다. --web.enable-remote-write-receiver는 --web.enable-feature=remote-write-receiver 방식으로 바뀌었고, promql-at-modifier·promql-negative-offset 플래그는 이제 기본 동작이라 제거됐다. PromQL 함수 holt_winters는 double_exponential_smoothing으로 개명됐으니 알림 규칙·대시보드 쿼리를 점검하자.
실제 사용하면서 깨달은 꿀팁
Alertmanager 연동을 미루지 말자. "나중에 하지 뭐" 하다가 새벽 3시에 디스크 100%로 서비스가 죽을 수 있다. 디스크 사용률 85% 이상, CPU 90% 이상 5분 지속, 메모리 사용률 90% 이상 -- 이 세 가지 알림은 최소한으로 걸어둬야 한다. 슬랙 웹훅 연동하면 핸드폰으로 바로 확인할 수 있다.
Prometheus 메트릭에 붙는 레이블(label)의 이름 규칙을 팀 내에서 먼저 정해둬야 한다. env=production인지 environment=prod인지, service=api인지 app=api-server인지 -- 이게 통일이 안 되면 나중에 PromQL 쿼리 짤 때 정말 고생한다. 대시보드 전체를 두 번 다시 만든 경험이 있다.
Prometheus 기본 데이터 보관 기간은 15일이다. 운영 초기엔 괜찮지만, 월간 트렌드를 보고 싶다면 --storage.tsdb.retention.time=90d로 늘려줘야 한다. 단, 디스크 용량을 반드시 계산해야 한다. 메트릭이 많으면 하루에 수 GB씩 쌓인다. 장기 보관이 필요하면 Thanos가 가장 무난한 선택이다. 3.x의 Remote Write 2.0을 쓰면 전송량이 줄어 원격 스토리지 연동 비용도 같이 내려간다.
장단점 비교
| 구분 | 장점 | 단점 |
|---|---|---|
| 비용 | 완전 오픈소스, 무료로 사용 가능 | 자체 서버 운영 비용 발생 (인프라 + 인력) |
| 확장성 | Kubernetes 네이티브, SD 기능으로 대규모 대응 | 단일 Prometheus 인스턴스는 수평 확장 불가 |
| 생태계 | Exporter가 수백 종 존재 (MySQL, Redis, Nginx 등) | 로그 수집은 별도 도구(Loki 등) 필요 |
| 쿼리 | PromQL이 강력하고 유연함 | PromQL 학습 곡선이 있음 |
| 시각화 | Grafana 대시보드가 매우 직관적이고 공유 편리 | 대시보드가 많아지면 관리 포인트 증가 |
| 운영 | Pull 방식이라 모니터링 대상 추가/제거가 유연 | 방화벽 환경에서 Pull이 어려울 수 있음 (Pushgateway로 해결) |
유료 솔루션 대비 어떤가
Datadog이나 New Relic 같은 SaaS 모니터링 서비스와 비교하면, Prometheus Grafana 조합은 초기 세팅에 시간이 좀 더 걸린다. 하지만 서버 대수가 늘어나도 추가 비용이 없다는 게 결정적인 차이다. 월 서버 20대 이상 운영한다면 비용 차이가 상당히 벌어진다. 다만 팀에 인프라 담당자가 없다면 관리형 SaaS가 오히려 효율적일 수 있으니 상황에 맞게 판단하자.
Grafana 13의 새 무기 (2026년 기준)
2026년 6월 기준 최신인 Grafana 13에서 대시보드 운영 방식이 한층 편해졌다. 스키마 v2 기반의 Dynamic Dashboards가 정식 기능이 되어 변수에 따라 패널 구성을 유연하게 바꿀 수 있고, Git Sync 2-way가 GA로 승격돼 대시보드를 Git과 양방향 동기화하며 코드처럼 관리할 수 있다. AI 비서인 Grafana Assistant도 오픈소스 버전까지 개방돼, 쿼리 작성이나 대시보드 구성을 도와준다. 참고로 12 버전부터 AngularJS가 완전히 제거됐으니, 오래된 패널 플러그인을 쓰던 환경이라면 업그레이드 전 호환성을 확인하자.
마무리 -- 누구에게 추천하는가
강력 추천 대상
- 서버 3대 이상 운영 중인 스타트업 개발팀 -- 서버가 늘어날수록 모니터링 비용 부담 없이 확장할 수 있다.
- Kubernetes를 사용하거나 도입 예정인 팀 -- 쿠버네티스 생태계와 가장 자연스럽게 통합된다.
- DevOps 역량을 키우고 싶은 주니어 엔지니어 -- Prometheus Grafana 모니터링은 DevOps 면접에서 거의 필수로 물어보는 주제다.
- 모니터링 SaaS 비용을 줄이고 싶은 중소기업 -- 월 수십만 원 이상 아낄 수 있다.
이런 경우엔 다른 선택을
- 인프라 전담 인력이 없는 소규모 팀 -- 관리 부담이 있으므로 Datadog이나 CloudWatch 같은 관리형 서비스가 나을 수 있다.
- 로그 중심 모니터링이 더 중요한 경우 -- ELK 스택이나 Grafana Loki를 먼저 고려해보자.
직접 구축하고 운영해본 입장에서 솔직히 말하면, 초반 삽질은 좀 있다. 하지만 한 번 세팅해두면 서버 상태가 한눈에 들어오는 그 경험은 정말 값어치가 있다. 새벽에 알림 받고 장애를 사전에 막았을 때의 안도감은 직접 겪어봐야 안다.
