Uptime Kuma vs Netdata vs Prometheus, 소규모 서버엔 뭘 써야 할까

"그냥 서버 안 죽었는지만 알고 싶은데, 뭘 깔아야 하죠?"

VPS 한두 대, 혹은 사무실 구석의 온프렘 서버 몇 대를 굴리다 보면 새벽에 서비스가 죽었는데 아침에야 알게 되는 사고를 한 번쯤 겪습니다. Datadog 같은 SaaS는 호스트당 월 과금이라 1인 개발자에겐 부담이고, 무료 셀프호스팅 도구를 검색하면 Uptime Kuma, Netdata, Prometheus가 줄줄이 나오는데 다 비슷해 보여 선택 마비에 빠지죠.

이 글은 "모니터링이란 무엇인가" 같은 개념 설명을 하지 않습니다. 당신 상황(서버 대수·필요한 지표·운영 여력)에 셋 중 무엇이 정답인지 5분 안에 골라주고, 그대로 복붙해 설치·알림 연동까지 끝내는 게 목표입니다. 먼저 결론부터 보시죠.

한눈에 비교 + 상황별 추천 분기

위 표가 와닿지 않는다면, 아래 세 갈래에서 본인 케이스를 바로 찾으세요.

① 단순 업/다운 + 알림만 원함 → Uptime Kuma

• 이런 사람: "웹사이트·API가 살아있는지, 죽으면 텔레그램으로 알려주기만 하면 됨."
• 이건 포기해야 함: CPU·메모리·디스크 같은 시스템 내부 지표는 못 봄. Kuma는 외부에서 핑·HTTP를 찌르는 외형 감시 도구입니다.

② 단일 서버 실시간 상세 지표 → Netdata

• 이런 사람: "한 대짜리 서버의 CPU·디스크 I/O·네트워크를 초 단위로 들여다보고 싶다."
• 이건 포기해야 함: 여러 서버를 한 화면에 묶어 장기 추세를 분석하기엔 부족(클라우드 연동 없이는 노드별 분산). 기본 메모리 점유도 가볍지 않음.

③ 여러 서버 + 장기 지표·그래프·확장 → Prometheus + Grafana

• 이런 사람: "서버 3대 이상, 6개월 전 디스크 추세까지 보고 알림 규칙을 코드로 관리하고 싶다."
• 이건 포기해야 함: 설치·운영 학습 곡선. 컴포넌트가 많고 디스크 관리도 직접 해야 합니다.

실무 경험담: 저는 서버 2대 시절 Kuma만 썼고, 5대로 늘면서 Prometheus를 추가했습니다. 처음부터 Prometheus를 깔았다면 운영 부담에 지쳐 모니터링 자체를 방치했을 겁니다. 작게 시작하는 게 거의 항상 정답입니다.

5분 설치 + 알림 연동 실전 (3종 복붙 가이드)

Uptime Kuma — docker 한 줄

docker run -d --restart=always \
  -p 3001:3001 \
  -v uptime-kuma:/app/data \
  --name uptime-kuma \
  louislam/uptime-kuma:1

브라우저에서 http://서버IP:3001 접속 → 계정 생성 → Add New Monitor로 감시할 URL 등록. 알림은 Settings → Notifications → Setup Notification에서:

• 텔레그램: @BotFather로 봇 생성 후 받은 Bot Token 입력, https://api.telegram.org/bot<토큰>/getUpdates로 Chat ID 확인해 입력.
• 슬랙: Slack Incoming Webhook URL을 그대로 붙여넣기.

등록 후 Test 버튼을 누르면 첫 알림이 바로 옵니다.

Netdata — one-line 설치

wget -O /tmp/netdata-kickstart.sh https://get.netdata.cloud/kickstart.sh && \
  sh /tmp/netdata-kickstart.sh --stable-channel --disable-telemetry

설치되면 http://서버IP:19999에서 즉시 대시보드가 뜹니다. 알림은 /etc/netdata/health_alarm_notify.conf 편집:

# 슬랙
SEND_SLACK="YES"
SLACK_WEBHOOK_URL="https://hooks.slack.com/services/XXX/YYY/ZZZ"
DEFAULT_RECIPIENT_SLACK="#alerts"

# 텔레그램
SEND_TELEGRAM="YES"
TELEGRAM_BOT_TOKEN="123456:ABC-DEF..."
DEFAULT_RECIPIENT_TELEGRAM="-1001234567890"

저장 후 sudo systemctl restart netdata, 테스트는 sudo su -s /bin/bash netdata 후 /usr/libexec/netdata/plugins.d/alarm-notify.sh test.

Prometheus + Grafana — docker-compose

# docker-compose.yml
services:
  prometheus:
    image: prom/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.retention.time=15d'
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prom-data:/prometheus
    ports: ["9090:9090"]
  node_exporter:
    image: prom/node-exporter
    ports: ["9100:9100"]
  alertmanager:
    image: prom/alertmanager
    volumes:
      - ./alertmanager.yml:/etc/alertmanager/alertmanager.yml
    ports: ["9093:9093"]
  grafana:
    image: grafana/grafana
    ports: ["3000:3000"]
    volumes:
      - grafana-data:/var/lib/grafana
volumes:
  prom-data:
  grafana-data:

# prometheus.yml
global:
  scrape_interval: 30s
rule_files:
  - alert.rules.yml
alerting:
  alertmanagers:
    - static_configs:
        - targets: ['alertmanager:9093']
scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets: ['node_exporter:9100']

# alert.rules.yml
groups:
  - name: basic
    rules:
      - alert: InstanceDown
        expr: up == 0
        for: 1m
        labels: { severity: critical }
        annotations: { summary: "인스턴스 {{ $labels.instance }} 다운" }
      - alert: DiskAlmostFull
        expr: (1 - node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) > 0.8
        for: 5m
        labels: { severity: warning }
        annotations: { summary: "디스크 80% 초과" }

# alertmanager.yml
route:
  receiver: 'slack'
receivers:
  - name: 'slack'
    slack_configs:
      - api_url: 'https://hooks.slack.com/services/XXX/YYY/ZZZ'
        channel: '#alerts'
  # 텔레그램을 쓰려면 아래로 교체
  # telegram_configs:
  #   - bot_token: '123456:ABC-DEF...'
  #     chat_id: -1001234567890

docker compose up -d 후 Grafana(:3000, admin/admin)에서 Prometheus를 데이터소스로 추가하고 대시보드 ID 1860(Node Exporter Full)을 import하면 끝납니다.

현실 점검: 리소스 오버헤드 & 흔한 함정

세 도구 모두 "공짜"지만 운영 비용은 다릅니다. 1코어/1GB VPS 기준으로 정리하면:

• Prometheus 디스크 폭증: 기본 retention 15일도 메트릭 카디널리티가 높으면 수 GB로 불어납니다. scrape_interval을 15초→30s로 늘리고, --storage.tsdb.retention.time=15d(또는 retention.size=2GB)로 상한을 두세요. 1GB VPS에서는 Prometheus+Grafana 동시 구동이 빠듯하므로 swap 확보를 권합니다.
• Netdata 메모리 점유: 기본 1초 수집이라 가볍다고 보기 어렵습니다. /etc/netdata/netdata.conf에서 [db] update every = 2로 늘리고 dbengine 모드의 dbengine multihost disk space MB를 제한하면 RAM 점유를 200MB 안쪽으로 잡을 수 있습니다.
• Uptime Kuma의 한계: CPU/RAM/디스크 같은 시스템 지표를 자체 수집하지 못합니다. 외형 감시 전용이라는 점을 잊으면 "왜 디스크 알림이 안 오지?"로 헤맵니다.

참고로 OpenTelemetry로 수렴하는 큰 흐름이 있지만, 소규모 1~5대 환경엔 아직 과합니다. node_exporter + Grafana 조합이 사실상 표준이니 그걸로 충분합니다.

결론: 단계적 성장 경로 + 최종 한 줄 추천

가장 흔하고 견고한 조합은 Kuma(외형 감시) + Netdata 또는 Prometheus(내부 지표) 병행입니다. 사용자 입장의 "서비스 살아있나"는 Kuma가, 내부 자원 상태는 Netdata/Prometheus가 맡습니다.

성장 경로는 이렇게 잡으세요:

1. 서버 1~2대: Uptime Kuma로 시작 → 죽으면 알림 받기.
2. 상세 지표 필요: Netdata 추가 → 단일 서버 실시간 진단.
3. 3대 이상·장기 추세: Prometheus+Grafana 도입. 이때 Netdata를 http://서버IP:19999/api/v1/allmetrics?format=prometheus 엔드포인트로 노출하면 Prometheus가 그대로 스크랩할 수 있어 두 도구를 자연스럽게 잇습니다.

최종 한 줄 처방

• "죽었는지만 알면 됨" → Uptime Kuma
• "한 대를 깊게 보고 싶음" → Netdata
• "여러 대·장기·확장" → Prometheus + Grafana

자주 묻는 질문 (FAQ)

Q. Uptime Kuma로 CPU·메모리도 볼 수 있나요? A. 기본적으로는 안 됩니다. Kuma는 외부에서 핑/HTTP로 살아있는지 확인하는 외형 감시 도구라, 시스템 내부 지표는 Netdata나 Prometheus(node_exporter)를 함께 써야 합니다.

Q. Netdata와 Prometheus 중 하나만 골라야 한다면? A. 서버가 1~2대이고 실시간 진단이 목적이면 Netdata, 3대 이상이고 장기 추세·알림 규칙 코드 관리가 필요하면 Prometheus+Grafana를 추천합니다.

Q. 1GB짜리 VPS 한 대에 셋 다 깔아도 되나요? A. 권장하지 않습니다. Prometheus+Grafana만으로도 메모리가 빠듯합니다. 1GB라면 Kuma + Netdata(수집 주기 2초로 조정) 정도가 현실적인 한계입니다.