Prometheus와 Grafana, 각각 뭘 하는 녀석인가
Prometheus -- 데이터를 수집하는 엔진
Prometheus는 시계열 데이터베이스(TSDB)다. 쉽게 말하면, 일정 간격으로 서버들한테 "너 지금 상태 어때?" 하고 물어보고(Pull 방식), 그 응답을 저장하는 역할이다. PromQL이라는 자체 쿼리 언어로 데이터를 조회할 수 있고, Alertmanager와 연동하면 특정 조건에서 슬랙이나 이메일로 알림도 보내준다.
Grafana -- 데이터를 보여주는 대시보드
Grafana는 시각화 도구다. Prometheus가 모아둔 데이터를 그래프, 게이지, 히트맵 등 다양한 형태로 보여준다. Prometheus 웹 UI만으로도 그래프를 볼 수 있긴 한데, Grafana의 대시보드를 한 번 써보면 다시는 돌아갈 수 없다. 팀원들한테 공유하기도 편하다.
왜 이 둘을 같이 쓰는가
Prometheus는 수집과 저장에 특화되어 있고, Grafana는 시각화에 특화되어 있다. 서로의 약점을 정확히 보완하는 조합이라 업계 표준처럼 쓰인다. CNCF(Cloud Native Computing Foundation) 프로젝트이기도 해서 Kubernetes 환경과의 궁합도 최고다.
실전 구축 가이드 -- 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, 메모리, 디스크, 네트워크 지표가 한눈에 보이는 대시보드가 바로 세팅된다.
실제 사용하면서 깨달은 꿀팁
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나 Cortex 같은 원격 스토리지 솔루션을 고려하는 것도 방법이다.
장단점 비교
| 구분 | 장점 | 단점 |
|---|---|---|
| 비용 | 완전 오픈소스, 무료로 사용 가능 | 자체 서버 운영 비용 발생 (인프라 + 인력) |
| 확장성 | Kubernetes 네이티브, SD 기능으로 대규모 대응 | 단일 Prometheus 인스턴스는 수평 확장 불가 |
| 생태계 | Exporter가 수백 종 존재 (MySQL, Redis, Nginx 등) | 로그 수집은 별도 도구(Loki 등) 필요 |
| 쿼리 | PromQL이 강력하고 유연함 | PromQL 학습 곡선이 있음 |
| 시각화 | Grafana 대시보드가 매우 직관적이고 공유 편리 | 대시보드가 많아지면 관리 포인트 증가 |
| 운영 | Pull 방식이라 모니터링 대상 추가/제거가 유연 | 방화벽 환경에서 Pull이 어려울 수 있음 (Pushgateway로 해결) |
유료 솔루션 대비 어떤가
Datadog이나 New Relic 같은 SaaS 모니터링 서비스와 비교하면, Prometheus Grafana 조합은 초기 세팅에 시간이 좀 더 걸린다. 하지만 서버 대수가 늘어나도 추가 비용이 없다는 게 결정적인 차이다. 월 서버 20대 이상 운영한다면 비용 차이가 상당히 벌어진다. 다만 팀에 인프라 담당자가 없다면 관리형 SaaS가 오히려 효율적일 수 있으니 상황에 맞게 판단하자.
마무리 -- 누구에게 추천하는가
강력 추천 대상
- 서버 3대 이상 운영 중인 스타트업 개발팀 -- 서버가 늘어날수록 모니터링 비용 부담 없이 확장할 수 있다.
- Kubernetes를 사용하거나 도입 예정인 팀 -- 쿠버네티스 생태계와 가장 자연스럽게 통합된다.
- DevOps 역량을 키우고 싶은 주니어 엔지니어 -- Prometheus Grafana 모니터링은 DevOps 면접에서 거의 필수로 물어보는 주제다.
- 모니터링 SaaS 비용을 줄이고 싶은 중소기업 -- 월 수십만 원 이상 아낄 수 있다.
이런 경우엔 다른 선택을
- 인프라 전담 인력이 없는 소규모 팀 -- 관리 부담이 있으므로 Datadog이나 CloudWatch 같은 관리형 서비스가 나을 수 있다.
- 로그 중심 모니터링이 더 중요한 경우 -- ELK 스택이나 Grafana Loki를 먼저 고려해보자.
직접 구축하고 운영해본 입장에서 솔직히 말하면, 초반 삽질은 좀 있다. 하지만 한 번 세팅해두면 서버 상태가 한눈에 들어오는 그 경험은 정말 값어치가 있다. 새벽에 알림 받고 장애를 사전에 막았을 때의 안도감은 직접 겪어봐야 안다.
