VPS에 Grafana + Prometheus 모니터링 스택 구축하기 (Docker Compose 가이드)

Prometheus와 Grafana가 무엇인지 아직 잘 모르겠다면, 다음 글을 먼저 읽어 보세요: Prometheus와 Grafana 비교. 차이를 이미 알고 있다면, 둘을 함께 실행하는 방법은 다음과 같습니다.

이 글은 실제 구축을 다루는 후속편입니다. Docker Compose로 VPS 한 대에 Prometheus, Grafana, Node Exporter를 배포하고, Caddy로 Grafana 앞단에 HTTPS를 붙이고, Node Exporter Full 대시보드(ID 1860)를 가져오고, WireGuard로 두 번째 VPS의 메트릭을 수집하는 방법까지 설명합니다.

2026년 4월의 최초 테스트는 Ubuntu 24.04 LTS에서 Docker Engine 27.x와 Docker Compose v2.30으로 진행했습니다. 아래 설정에 고정된 버전은 그 이후 현재 지원되는 릴리스로 갱신했습니다. 호스트 5대를 대상으로 한 그 테스트에서 허브는 유휴 상태에서 약 300 MB, 지속적으로 수집하는 동안에는 530~650 MB의 RAM을 사용했습니다.

요약

• 허브 VPS는 Prometheus, Grafana, Node Exporter를 하나의 Compose 스택으로 실행하고, Caddy는 호스트에 직접 설치해 리버스 프록시로 씁니다.
• Prometheus와 Grafana는 127.0.0.1에만 바인딩합니다. 외부 접근은 자동 HTTPS가 적용된 Caddy를 거칩니다.
• 서버를 더 추가하려면 각 서버에 Node Exporter를 설치하고 다음 파일에 항목을 덧붙이면 됩니다: prometheus.yml.
• 허브와 스포크 사이의 네트워크 경로로는 WireGuard를 권장합니다. 서버들이 이미 같은 사설 네트워크에 있다면 사설 네트워킹도 잘 동작합니다.
• 아래 다섯 대 호스트 테스트에는 2 GB VPS로 충분했지만, 이는 호스트 수에 따른 고정 규칙이 아니라 기준점으로 보시기 바랍니다.

무엇을 구축하게 되는가

완성했을 때 구성이 대략 어떤 모습인지 살펴봅시다.

                 +-------------------+
                 |  Your laptop      |
                 +---------+---------+
                           | HTTPS
                           v
+--------------------------+----------------------------+
| MONITORING HUB VPS    (2 GB RAM starting point) |
|  Caddy        (reverse proxy, auto HTTPS)             |
|  Grafana      (port 3000, only via Caddy)             |
|  Prometheus   (port 9090, internal only)              |
|  Node Exporter (port 9100, scraped on localhost)      |
+----+---------------------------------+----------------+
     |                                 |
     | scrape over WireGuard           | scrape over WG
     v                                 v
+----+--------+                  +-----+-------+
|  App VPS 1  |                  |  App VPS 2  |
|  Node Expo. |                  |  Node Expo. |
+-------------+                  +-------------+

모니터링 스택 전체는 허브 VPS 한 대에 올립니다. 감시하려는 나머지 VPS에는 Node Exporter만 돌립니다. 허브의 Prometheus가 각 서버에서 메트릭을 가져오고, Grafana가 시각화하며, Caddy가 HTTPS를 처리합니다.

필요한 것

이 구성을 그대로 따라 하려면 허브로 쓸 Ubuntu VPS 한 대, 도메인, 그리고 sudo 권한이 필요합니다.

• Ubuntu 24.04 LTS를 실행하는 RAM 2 GB 이상의 VPS.
• VPS의 공인 IP를 가리키는 A 레코드가 설정된 도메인 이름(예: grafana.example.com). HTTPS에 필요합니다.
• SSH를 통한 root 또는 sudo 접근 권한.

이 가이드 전체에서 grafana.example.com은 실제로 모니터링 VPS로 연결한 서브도메인으로 바꿔 주세요. Grafana 환경 변수, DNS 확인, Caddyfile에 모두 같은 도메인을 사용합니다.

서버 한 대만 감시하면 되고 아직 HTTPS가 필요 없다면, 리버스 프록시 부분을 빼고 기존 VPS에서 Compose 스택을 그대로 실행해도 됩니다. 나머지 내용은 그대로 적용됩니다.

1단계: 서버 준비

sudo 권한이 있는 사용자로 허브 VPS에 SSH 접속합니다. 먼저 시스템을 업데이트하세요.

sudo apt update && sudo apt upgrade -y

공식 Docker 저장소에서 Docker Engine과 Compose 플러그인을 설치합니다.

# Install prerequisites
sudo apt install -y ca-certificates curl gnupg lsb-release

# Add Docker's official GPG key
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \
  sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# Add the Docker repository
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
  https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

둘 다 설치됐는지 확인합니다.

docker --version
docker compose version

두 명령 모두 오류 없이 버전을 출력해야 합니다. Docker Engine과 Compose의 정확한 버전은 설치 시점에 공식 저장소가 제공하는 것에 따라 달라집니다.

sudo usermod -aG docker $USER

계속하기 전에 로그아웃했다가 다시 로그인해야 새 그룹 소속이 적용됩니다. docker 그룹은 사실상 root 수준 권한을 주므로, 신뢰할 수 있는 관리자만 추가하세요.

모니터링 허브에서 SSH, HTTP, HTTPS를 허용하도록 UFW를 설정합니다. 80번 포트는 HTTP에서 HTTPS로의 리디렉션과 ACME 검증을 담당합니다. Grafana 자체는 Caddy 뒤에 그대로 둡니다.

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status

3000, 9090, 9100 포트를 공개 인터넷에 열지 마세요. 모니터링 서비스가 127.0.0.1에서만 대기하는 데는 이유가 있습니다.

2단계: Compose 스택

스택과 Prometheus 설정을 담을 디렉터리를 만듭니다.

mkdir -p ~/monitoring/prometheus
cd ~/monitoring

Compose 파일을 작성합니다.

# ~/monitoring/docker-compose.yml
services:
  prometheus:
    image: prom/prometheus:v3.13.2
    container_name: prometheus
    restart: unless-stopped
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.path=/prometheus'
      - '--storage.tsdb.retention.time=15d'
      - '--web.enable-lifecycle'
      - '--web.listen-address=127.0.0.1:9090'
    volumes:
      - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml:ro
      - prometheus_data:/prometheus
    network_mode: host
  node-exporter:
    image: prom/node-exporter:v1.12.1
    container_name: node-exporter
    restart: unless-stopped
    pid: host
    network_mode: host
    command:
      - '--path.rootfs=/host'
      - '--web.listen-address=127.0.0.1:9100'
      - '--collector.filesystem.mount-points-exclude=^/(dev|proc|sys|var/lib/docker/.+|var/lib/kubelet/.+)($$|/)'
    volumes:
      - '/:/host:ro,rslave'
  grafana:
    image: grafana/grafana:13.1.3
    container_name: grafana
    restart: unless-stopped
    environment:
      - GF_SECURITY_ADMIN_USER=admin
      - GF_SECURITY_ADMIN_PASSWORD=${GRAFANA_ADMIN_PASSWORD}
      - GF_USERS_ALLOW_SIGN_UP=false
      - GF_SERVER_ROOT_URL=https://grafana.example.com
      - GF_SERVER_HTTP_ADDR=127.0.0.1
    volumes:
      - grafana_data:/var/lib/grafana
    network_mode: host
    depends_on:
      - prometheus
volumes:
  prometheus_data:
  grafana_data:

이제 Prometheus 설정을 작성합니다.

# ~/monitoring/prometheus/prometheus.yml
global:
  scrape_interval: 15s
  evaluation_interval: 15s
  external_labels:
    monitor: 'monitoring-hub'
scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['127.0.0.1:9090']
  - job_name: 'node'
    static_configs:
      - targets: ['127.0.0.1:9100']
        labels:
          host: 'monitoring-hub'

Grafana 관리자 비밀번호를 담은 .env 파일을 만듭니다. 강력한 비밀번호를 쓰고, 이 파일은 git에 커밋하지 마세요.

cat > ~/monitoring/.env <<'EOF'
GRAFANA_ADMIN_PASSWORD='replace-with-a-strong-password'
EOF
chmod 600 ~/monitoring/.env

위 옵션 중 몇 가지는 한 줄씩 설명할 가치가 있습니다.

• --web.listen-address=127.0.0.1:9090 는 Prometheus가 호스트의 루프백 인터페이스에서만 대기하도록 만듭니다. 덕분에 9090 포트는 공개 네트워크에 노출되지 않으면서도 Grafana와 로컬 관리 작업에서는 계속 접근할 수 있습니다.
• --web.enable-lifecycle 는 다음을 활성화합니다: POST /-/reload. 덕분에 컨테이너를 재시작하지 않고도 Prometheus 설정 변경을 적용할 수 있습니다.
• pid: host, network_mode: host, 호스트 루트 바인드 마운트, 그리고 --path.rootfs=/host 는 컨테이너로 실행되는 Node Exporter가 자기 컨테이너 환경만 보는 대신 필요한 호스트 컨텍스트를 얻도록 해 줍니다.
• GF_USERS_ALLOW_SIGN_UP=false 는 방문자가 스스로 Grafana 계정을 만드는 것을 막습니다. 그렇다고 Grafana가 비공개가 되지는 않습니다. 로그인 페이지는 여전히 Caddy를 통해 공개적으로 접근할 수 있습니다.

팁: 수동 설치를 건너뛰고 싶다면, Cloudzy에서 원클릭으로 Grafana 와 Prometheus 배포할 수 있습니다. Prometheus 배포는 Node Exporter도 함께 설치할 수 있습니다.

3단계: 첫 실행과 확인

스택을 띄웁니다.

cd ~/monitoring
docker compose up -d

몇 초 기다린 뒤 컨테이너 세 개가 모두 실행 중인지 확인합니다.

docker compose ps

세 서비스 모두 running 상태로 나와야 합니다.

노트북에서 SSH 터널을 열어 Prometheus 타깃 페이지를 확인합니다.

ssh -L 9090:localhost:9090 your-user@your-vps-ip

그런 다음 브라우저에서 http://localhost:9090/targets에 접속합니다. 타깃 두 개가 모두 UP 상태로 보여야 합니다:

prometheus            UP    http://127.0.0.1:9090/metrics
node                  UP    http://127.0.0.1:9100/metrics

둘 중 하나라도 DOWN이면 '자주 겪는 문제' 절로 넘어가세요. 둘 다 UP이 되기 전에는 진행하지 마세요.

타깃 확인이 끝나면 터널을 닫습니다. VPS 외부에서는 이 SSH 터널을 통해서만 Prometheus에 접근할 수 있습니다. 다음 단계에서는 Grafana를 HTTPS로 공개합니다.

4단계: Caddy로 HTTPS 리버스 프록시 구성

Caddy는 단일 바이너리이고 HTTPS를 자동으로 처리합니다. 사이트 하나짜리 리버스 프록시라면 설정이 같은 일을 하는 Nginx 블록보다 짧습니다.

공식 저장소에서 Caddy를 설치합니다.

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | \
  sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | \
  sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo chmod o+r /usr/share/keyrings/caddy-stable-archive-keyring.gpg
sudo chmod o+r /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install -y caddy

다음 단계로 넘어가기 전에 grafana.example.com의 DNS A 레코드가 VPS 공인 IP를 가리키는지 확인하세요. 그렇지 않으면 ACME 검증이 실패합니다.

dig +short grafana.example.com
# Should print the VPS public IP

Caddyfile을 편집합니다.

# /etc/caddy/Caddyfile
grafana.example.com {
    reverse_proxy 127.0.0.1:3000
    encode gzip
}

Caddy를 리로드합니다.

sudo systemctl reload caddy

도메인이 서버를 가리키고 80번과 443번 포트에 접근할 수 있으면, Caddy가 ACME를 통해 공개적으로 신뢰되는 TLS 인증서를 자동으로 발급하고 갱신합니다. 브라우저에서 https://grafana.example.com에 접속하면 유효한 HTTPS 연결로 Grafana 로그인 페이지가 보여야 합니다. admin 계정과 .env 파일의 비밀번호로 로그인하세요.

5단계: Prometheus를 데이터 소스로 추가하고 대시보드 1860 가져오기

Grafana UI에서 다음 경로로 이동합니다: 연결 > 데이터 소스 > 데이터 소스 추가 를 선택합니다: Prometheus.

URL을 다음과 같이 설정합니다:

http://127.0.0.1:9090

이 구성에서 Grafana와 Prometheus는 호스트 네트워크를 공유하고, Prometheus는 루프백에서만 대기합니다. 다음을 클릭하세요: Save & test . 그리고 Grafana가 Prometheus API를 조회할 수 있는지 확인합니다. "Successfully queried the Prometheus API"라는 메시지가 보여야 합니다.

이제 대시보드를 가져옵니다. Node Exporter Full(rfmoz가 만든 ID 1860)은 Node Exporter 메트릭용으로 널리 쓰이는 커뮤니티 대시보드입니다. CPU, 메모리, 디스크 I/O, 네트워크, 파일 디스크립터를 다루고, 호스트가 노출하는 경우 하드웨어 온도까지 보여 줍니다. job과 instance 변수도 있어서 허브 앤 스포크 구조에서 손댈 필요 없이 그대로 동작합니다.

이동 대시보드 > 신규 > 대시보드 가져오기로 이동해 대시보드 ID 1860을 입력하고, Prometheus 데이터 소스를 선택한 뒤 가져오면 됩니다.

Node Exporter 타깃이 UP이 되면 대시보드에 데이터가 채워질 것입니다. 대시보드 1860은 일부 패널에서 선택 사항인 systemd와 processes 컬렉터의 메트릭도 쓰기 때문에, 패널 하나가 비어 있다고 해서 반드시 타깃에 문제가 있는 것은 아닙니다.

6단계: 두 번째 VPS 추가하기 (허브 앤 스포크)

Node Exporter를 시작하기 전에, 바인딩하려는 사설 IP가 두 번째 VPS에 실제로 존재하는지 확인하세요. WireGuard를 쓴다면 WireGuard 설정을 먼저 끝내야 합니다.

두 번째 VPS에서는 1단계의 Docker 설치 부분만 따라 Docker를 설치하되, 모니터링 때문에 80이나 443 포트를 열지는 마세요. 그런 다음 Node Exporter만 실행합니다.

mkdir -p ~/node-exporter
cd ~/node-exporter

cat > docker-compose.yml <<'EOF'
services:
  node-exporter:
    image: prom/node-exporter:v1.12.1
    container_name: node-exporter
    restart: unless-stopped
    pid: host
    command:
      - '--path.rootfs=/host'
      - '--web.listen-address=10.10.0.2:9100'  # bind to the private monitoring IP, never 0.0.0.0
    volumes:
      - '/:/host:ro,rslave'
    network_mode: host
EOF

docker compose up -d

10.10.0.2를 이 서버의 모니터링용 사설 IP로 바꾸세요. WireGuard를 쓴다면 해당 WireGuard IP를, Cloudzy 사설 네트워크를 쓴다면 VPS의 사설 인터페이스 IP를 넣습니다. 이 VPS에서 UFW가 이미 켜져 있다면 모니터링 허브만 Node Exporter에 접근하도록 허용하세요. 예를 들어 허브의 사설 IP가 10.10.0.1이라면:

sudo ufw allow proto tcp from 10.10.0.1 to any port 9100
sudo ufw status

10.10.0.1을 허브의 실제 사설 IP로 바꾸세요. UFW가 꺼져 있어도 명시적으로 지정한 --web.listen-address 덕분에 Node Exporter는 여전히 공개 인터페이스에 노출되지 않지만, 그 사설 네트워크에 접근할 수 있는 다른 장비들도 9100 포트에 도달할 수 있습니다.

허브와 스포크 사이의 네트워크 경로로 좋은 선택지 두 가지:

1. WireGuard 네트워크. 모든 VPS가 WireGuard 네트워크에 참여하고, Prometheus는 사설 IP를 수집합니다. 초기 WireGuard 설정만 끝내면 가장 안전한 방식입니다. 저희는 WireGuard 를 원클릭 배포로 제공하고 있으며, 설정 튜토리얼도 준비돼 있습니다 .
2. Cloudzy 사설 네트워크. 같은 리전에 있는 Cloudzy VPS 인스턴스에는 동서 트래픽용 사설 인터페이스가 제공되므로, 별도의 WireGuard 터널을 만들지 않고 그 주소를 그대로 수집 대상으로 삼을 수 있습니다.

읽기

VPS에서 WireGuard VPN 설치하기 | Ubuntu 가이드

두 번째 VPS에서 Node Exporter가 돌아가고 사설 IP로 접근 가능해지면, 다음 파일의 기존 node 잡을 교체합니다: prometheus.yml 허브의 해당 파일에서 아래 블록으로 바꾸면 됩니다.

# Update the existing 'node' job in ~/monitoring/prometheus/prometheus.yml
  - job_name: 'node'
    static_configs:
      - targets: ['127.0.0.1:9100']
        labels:
          host: 'monitoring-hub'
      - targets: ['10.10.0.2:9100']
        labels:
          host: 'app-vps-1'
          tier: 'production'

컨테이너를 재시작하지 않고 Prometheus를 리로드합니다.

curl -X POST http://localhost:9090/-/reload

3단계의 SSH 터널을 다시 열고 http://localhost:9090/targets에 접속합니다. 새 타깃이 UP으로 보여야 합니다. Node Exporter Full 대시보드를 열어 상단의 instance 변수를 새 서버로 바꾸면 해당 서버의 그래프가 나타납니다.

리소스 사용량과 업그레이드 시점

이 수치는 호스트 5대를 감시하던 2 GB Ubuntu VPS에서 2026년 4월에 진행한 최초 테스트에서 나온 값입니다. 이 워크로드의 기준점으로 보되, 더 새로운 릴리스에 대한 확정적인 사이징 보장으로 받아들이지는 마세요.

허브의 메모리나 디스크 여유가 빠듯해지기 시작하면 업그레이드하세요. 호스트 수만 놓고 판단하는 것은 좋지 않은 기준입니다. 시리즈 카디널리티, 활성화한 컬렉터, 수집 주기, 보존 기간이 모두 사용량을 바꾸기 때문입니다. 장기 중앙 저장이 필요하다면 Prometheus는 원격 스토리지 연동을 지원합니다. VictoriaMetrics가 Prometheus 호환 선택지 중 하나입니다.

자주 겪는 문제

가장 자주 나타나는 일곱 가지 문제와 해결책입니다.

1. Prometheus가 공개 인터넷에서 접근 가능한 경우. 9090:9090처럼 단순히 포트를 매핑하면 Prometheus가 전 세계에 노출됩니다. 해결책: 위에서 보여 준 대로 Prometheus 커맨드에 --web.listen-address=127.0.0.1:9090 를 그대로 유지하세요. 그러면 Prometheus는 호스트의 루프백 인터페이스에서만 대기합니다.
2. Grafana 데이터 소스가 Prometheus에 접근하지 못하는 경우. 이 스택은 호스트 네트워킹을 쓰므로 Grafana는 http://127.0.0.1:9090으로 Prometheus에 접근할 수 있습니다. Prometheus가 실행 중이고 여전히 루프백에서 대기하는지 확인하세요.
3. Node Exporter 대시보드에 "No data"가 표시되는 경우. 흔한 원인은 세 가지입니다. (a) Prometheus가 타깃을 수집하지 않고 있습니다. /targets. (b) 대시보드 변수의 job 레이블이 스크레이프 설정의 job_name 값과 일치하지 않습니다. (c) 방화벽이 허브와 타깃 사이의 9100 포트를 막고 있습니다.
4. Grafana 관리자 비밀번호가 그대로 admin/admin 인 채로 운영 환경에 올라가 있는 경우. 설정 GF_SECURITY_ADMIN_PASSWORD 를 첫 실행 전에 .env 파일에서 설정하세요. 이미 놓쳤다면 첫 로그인 때 비밀번호를 바꾸고 회원가입을 비활성화하면 됩니다.
5. Caddy가 "ACME challenge failed"를 내는 경우. DNS A 레코드가 아직 전파되지 않았거나 80번 포트가 막혀 있습니다. ufw allow 80,443/tcp를 실행하고 DNS 전파를 기다린 다음 sudo systemctl reload caddy를 실행하세요. 전파 여부는 dig +short 로 확인할 수 있습니다.
6. Prometheus 디스크가 가득 차는 경우. 카디널리티가 높은 레이블이나 호스트가 많은 상황에서의 짧은 수집 주기는 볼륨을 빠르게 채웁니다. prometheus_tsdb_head_series 와 볼륨 크기를 지켜보세요. 완화책으로는 쓰지 않는 Node Exporter 컬렉터를 끄거나, scrape_interval 를 30s로 늘리거나, 보존 기간을 줄이는 방법이 있습니다.
7. 바인드 마운트 권한 오류. 이름 있는 볼륨 대신 호스트 디렉터리를 마운트하면, 컨테이너 UID(Prometheus는 65534, Grafana는 472)에 쓰기 권한이 있어야 합니다. 위 Compose 파일처럼 이름 있는 볼륨을 쓰면 이런 문제가 생기지 않습니다.

이 스택이 과한 경우

URL이 응답을 멈췄을 때 알림만 받으면 되는 상황이라면, 이 스택은 과합니다. Uptime Kuma 가 훨씬 가벼운 선택지입니다. 기본적인 가동 확인만 필요하다면 그걸로 충분합니다.

자주 묻는 질문

Prometheus와 Grafana의 차이는 무엇인가요?

Prometheus는 시계열 데이터베이스입니다. 설정한 주기로 대상에서 메트릭을 수집해 디스크에 저장하고 PromQL 질의에 응답합니다. Grafana는 Prometheus(및 다른 여러 데이터 소스)에 연결해 대시보드를 그려 주는 시각화 계층입니다. 거의 항상 둘 다 필요합니다. 수집과 저장은 Prometheus가, 표시는 Grafana가 맡습니다.

Prometheus + Grafana 구성에는 RAM이 얼마나 필요한가요?

VPS 한 대에서 Prometheus, Grafana, Node Exporter, 리버스 프록시를 돌리는 모니터링 허브는 유휴 상태에서 약 300 MB, 호스트 5대를 15초 간격으로 활발히 수집할 때 530~650 MB의 RAM을 사용합니다.

Grafana 하나로 여러 서버를 모니터링할 수 있나요?

네. 표준 구조는 허브 앤 스포크입니다. 허브 VPS의 Prometheus 인스턴스 하나가, 감시하려는 다른 모든 서버에서 도는 Node Exporter를 수집합니다. 허브의 Grafana는 그 하나의 Prometheus에만 질의합니다. Node Exporter Full 대시보드(ID 1860)에는 instance 변수가 있어서 대시보드 하나에서 서버를 골라 볼 수 있습니다.

Node Exporter에 가장 좋은 Grafana 대시보드는 무엇인가요?

이 구성에서는 Node Exporter Full(rfmoz가 만든 대시보드 ID 1860)이 든든한 기본 선택입니다. Node Exporter의 주요 호스트 메트릭을 다루고, 다중 서버 모니터링을 위한 job과 instance 변수도 지원합니다. 일부 패널은 선택 사항인 Node Exporter 컬렉터에 의존하므로, 패널 하나가 비어 있다고 해서 반드시 수집 대상에 문제가 있는 것은 아닙니다.

Grafana를 HTTPS로 어떻게 공개하나요?

Grafana를 127.0.0.1:3000에 바인딩해 실행하고, 그 앞에 HTTPS를 처리할 리버스 프록시를 두세요. 가장 간단한 선택은 Caddy입니다. 네 줄짜리 Caddyfile에 reverse_proxy 127.0.0.1:3000 와 도메인 블록만 넣으면 TLS 인증서 자동 관리까지 전부 처리됩니다.

Prometheus + Grafana는 상업적으로 무료인가요?

Prometheus는 Apache 2.0 라이선스를 따릅니다. Grafana OSS는 AGPLv3입니다. 수정하지 않은 Grafana OSS를 내부적으로나 상업적으로 사용하는 것은 허용되지만, 이를 수정하거나 배포하거나 수정본을 네트워크로 제공하면 AGPL에 따른 소스 공개 의무가 생길 수 있습니다. Grafana Enterprise와 Grafana Cloud는 별도의 상업 약관을 따릅니다.

언제 Prometheus에서 VictoriaMetrics로 옮겨야 하나요?

보존 기간이 길어지거나 시리즈 카디널리티가 높아지거나 Prometheus 인스턴스가 여러 개가 되어, 서버의 메모리와 디스크 예산 안에서 로컬 Prometheus TSDB를 운영하기가 버거워지면 VictoriaMetrics를 검토해 보세요. VictoriaMetrics는 Prometheus 데이터를 받을 수 있고 Prometheus 호환 질의 API를 제공하므로, 장기 저장소나 Grafana의 메트릭 백엔드로 쓸 수 있습니다. 고정된 RAM 임계치를 기준으로 갈아타지 말고, 자신의 워크로드로 직접 벤치마크해 보세요.