Uptime Kuma가 “서비스가 살아있는지 아닌지”를 확인하는 도구라면, Grafana와 Prometheus 조합은 한 단계 더 깊이 들어가 “서버가 지금 얼마나 힘든 상태인지”를 시계열 데이터로 보여주는 정교한 모니터링 스택이에요. 처음에는 설정이 다소 복잡하지만, 한 번 구축해두면 홈서버 상태를 훨씬 입체적으로 파악할 수 있어요. 그렇다면 Grafana와 Prometheus로 홈서버 지표 대시보드를 구축한다는 게 실제로 어떤 작업일까요?
Prometheus: 지표를 수집하고 저장하는 엔진
Prometheus는 지정된 주기마다(기본 15초 등) 여러 대상으로부터 지표를 “가져오는(pull)” 방식으로 동작하는 시계열 데이터베이스예요. CPU 사용률, 메모리 점유율, 디스크 I/O, 네트워크 트래픽 같은 지표가 시간에 따라 어떻게 변하는지를 계속 기록해요.
Prometheus 자체는 각 서버나 서비스의 지표를 직접 읽어오지 못하고, 각 대상에 설치된 “Exporter”라는 작은 에이전트가 지표를 Prometheus가 읽을 수 있는 형식으로 노출해줘야 해요. 대표적으로 서버 하드웨어 지표를 노출하는 node_exporter, Docker 컨테이너별 자원 사용량을 노출하는 cAdvisor 등이 널리 쓰여요.
Grafana: 수집된 데이터를 시각화
Grafana는 Prometheus에 쌓인 데이터를 그래프, 게이지, 히트맵 등 다양한 형태의 대시보드로 시각화하는 도구예요. 커뮤니티가 이미 만들어놓은 수천 개의 공유 대시보드 템플릿(예: “Node Exporter Full” 대시보드)을 ID 하나만 입력해 그대로 불러올 수 있어, 처음부터 직접 대시보드를 디자인하지 않아도 바로 그럴듯한 결과를 얻을 수 있어요.
기본 스택 구성
이 스택도 Docker Compose로 Prometheus, Grafana, node-exporter 세 컨테이너를 함께 띄우는 게 가장 일반적인 구성이에요.
services:
prometheus:
image: prom/prometheus:latest
volumes:
- ./prometheus.yml:/etc/prometheus/prometheus.yml
- prometheus_data:/prometheus
ports:
- "9090:9090"
grafana:
image: grafana/grafana:latest
ports:
- "3000:3000"
volumes:
- grafana_data:/var/lib/grafana
node-exporter:
image: prom/node-exporter:latest
ports:
- "9100:9100"
volumes:
prometheus_data:
grafana_data:prometheus.yml 설정 파일에 각 exporter의 주소를 “scrape target”으로 등록해두면, Prometheus가 주기적으로 해당 주소에서 지표를 수집하기 시작해요.
알림 규칙으로 사후 대응에서 사전 대응으로
단순히 대시보드를 눈으로 보는 것을 넘어, Prometheus의 Alertmanager 컴포넌트를 함께 구성하면 “디스크 사용률이 90%를 넘으면”, “CPU 온도가 80도를 초과하면” 같은 조건에 따라 자동으로 Telegram, Discord, ntfy 등으로 알림을 받을 수 있어요. 문제가 실제로 서비스 장애로 이어지기 전에 미리 조치할 수 있다는 게 이 스택의 진짜 가치예요.
Uptime Kuma와의 역할 분담
두 도구는 경쟁 관계가 아니라 상호 보완적이에요. Uptime Kuma는 “지금 서비스가 응답하는가”라는 이진 상태를 빠르고 간단하게 확인하는 데 최적화되어 있고, Grafana+Prometheus는 “왜 느려지고 있는가, 자원이 어떻게 소모되고 있는가”를 깊이 있게 분석하는 데 강점이 있어요. 많은 홈랩 운영자가 두 스택을 함께 운영하며, 먼저 Uptime Kuma의 알림으로 문제를 인지하고 Grafana 대시보드에서 근본 원인을 진단하는 워크플로우를 써요.
데이터 보관 기간과 디스크 사용량 고려
Prometheus는 기본적으로 모든 시계열 데이터를 디스크에 계속 쌓기 때문에, 오래 운영할수록 저장 공간을 차지해요. --storage.tsdb.retention.time 옵션으로 보관 기간(예: 30일)을 설정해 무한정 쌓이지 않도록 관리하는 게 일반적이에요. 장기 보관이 필요하다면 Thanos나 Mimir 같은 장기 저장 솔루션을 추가로 고려할 수 있지만, 홈랩 규모에서는 과한 경우가 대부분이에요.
결론
Grafana와 Prometheus 조합은 홈서버 모니터링의 정점이라 할 수 있어요. 설정 난이도가 있는 만큼 처음 시작하는 단계보다는, 여러 서비스를 이미 운영하며 “이제 좀 더 정교하게 서버 상태를 파악하고 싶다”는 단계에 이른 사용자에게 자연스러운 다음 단계로 추천할 만해요.
자주 묻는 질문
Q1. Uptime Kuma가 있는데 Grafana/Prometheus도 따로 필요한가요?
네, Uptime Kuma는 서비스 생존 여부만 빠르게 확인하는 데 최적화되어 있고, Grafana/Prometheus는 왜 느려지는지 원인을 깊이 분석하는 데 강점이 있어 두 스택은 경쟁이 아니라 상호 보완 관계예요.
Q2. Prometheus가 서버 지표를 어떻게 가져오나요?
각 대상에 설치된 node_exporter, cAdvisor 같은 Exporter 에이전트가 지표를 노출하면, Prometheus가 정해진 주기마다 이를 가져오는(pull) 방식으로 수집해요.
Q3. 대시보드를 처음부터 직접 만들어야 하나요?
아니요, 커뮤니티가 이미 만들어둔 수천 개의 공유 대시보드 템플릿을 ID 하나만 입력해 그대로 불러올 수 있어 처음부터 디자인할 필요가 없어요.
Q4. 디스크 사용률이 위험한 수준이면 자동으로 알림을 받을 수 있나요?
네, Alertmanager를 함께 구성하면 디스크 사용률이나 CPU 온도 같은 조건에 따라 Telegram, Discord 등으로 자동 알림을 받을 수 있어요.
Q5. 데이터를 무한정 쌓아둬도 되나요?
권장하지 않아요. `--storage.tsdb.retention.time` 옵션으로 보관 기간을 설정해두지 않으면 저장 공간을 계속 차지하므로, 보통 30일 정도로 제한하는 게 일반적이에요.
댓글
첫 번째 댓글을 남겨보세요!
Homepage로 홈랩 서비스 대시보드 한 화면에 모으기
서비스가 늘어날수록 북마크만으로는 감당이 안 되는 홈랩 환경에서, Homepage 대시보드로 모든 서비스와 상태를 한 화면에 모아 관리하는 방법을 소개합니다.
Homepage
Uptime Kuma로 내 서비스 상태 직접 모니터링하기
홈서버에서 돌아가는 여러 셀프호스팅 서비스가 살아있는지 한눈에 확인하고 장애를 알림받는 Uptime Kuma 구축법을 정리합니다.
Uptime KumaMealie로 레시피와 장보기 목록 셀프호스팅하기
여기저기 저장해둔 요리 레시피가 흩어져 사라지는 문제를, Mealie로 직접 운영하는 레시피 관리 서버와 자동 장보기 목록 기능으로 해결하는 방법을 소개합니다.
Mealie