“서버가 느려요”는 쓸모없는 버그 보고입니다. 그래프를 열어 장애 사흘 전부터 메모리가 계속 올라갔다는 걸 확인할 수 있다면 이야기가 달라집니다. 바로 그것을 Prometheus와 Grafana가 제공합니다. 모든 서버의 CPU, RAM, 디스크, 네트워크를 15초마다 기록하고, 거슬러 올라가며 볼 수 있는 그래프로 그려 줍니다. 전용의 작은 VPS에 두면 운영 서버가 쓰러져도 계속 지켜봅니다.
구성 요소
- node_exporter: 지켜보려는 모든 서버에서 실행하며, 9100번 포트로 시스템 지표를 제공합니다.
- Prometheus: 모니터링 VPS에서 그 지표를 수집(스크레이프)하고 저장합니다.
- Grafana: HTTPS 뒤에 두는 대시보드입니다.
- 선택적으로 Alertmanager나 Grafana 알림을 써서 임계값을 넘으면 메시지를 받습니다.
필요한 것
- Micro-IP(월 $10, 2 vCPU, RAM 2 GB, 25 GB)로 서버 한두 다스를 지켜볼 수 있습니다. 호스트가 더 많거나, 사용자 지정 앱 지표가 있거나, 몇 달치를 보관해야 한다면 Small-IP입니다.
- 모니터링 서버용 전용 IPv4: Grafana는 HTTPS로 제공되고, 대상 서버는 9100번 포트에 고정 주소 하나만 허용할 수 있습니다.
1. 각 대상 서버의 node_exporter
apt install -y prometheus-node-exporter
# allow only the monitoring server to scrape it
ufw allow from 203.0.113.10 to any port 9100 proto tcp
203.0.113.10을 모니터링 VPS의 주소로 바꾸세요. 9100번을 전 세계에 열어 두면 안 됩니다. 서버에 대한 정보가 많이 새어 나갑니다.
2. 모니터링 VPS의 Prometheus와 Grafana
apt update && apt install -y docker.io docker-compose-v2 caddy
mkdir -p /opt/monitoring && cd /opt/monitoring
cat > prometheus.yml <<'EOF'
global:
scrape_interval: 15s
scrape_configs:
- job_name: nodes
static_configs:
- targets: ['198.51.100.21:9100', '198.51.100.22:9100']
EOF
cat > compose.yml <<'EOF'
services:
prometheus:
image: prom/prometheus
volumes: [ "./prometheus.yml:/etc/prometheus/prometheus.yml:ro", "prom:/prometheus" ]
command: [ "--config.file=/etc/prometheus/prometheus.yml", "--storage.tsdb.retention.time=15d", "--web.enable-remote-write-receiver" ]
ports: [ "127.0.0.1:9090:9090" ]
restart: unless-stopped
grafana:
image: grafana/grafana
volumes: [ "grafana:/var/lib/grafana" ]
ports: [ "127.0.0.1:3000:3000" ]
restart: unless-stopped
volumes: { prom: {}, grafana: {} }
EOF
docker compose up -d
Grafana 앞에 HTTPS를 둡니다.
echo 'grafana.example.com {
reverse_proxy 127.0.0.1:3000
}' > /etc/caddy/Caddyfile && systemctl reload caddy
로그인(admin / admin 후 변경)하고, http://prometheus:9090을 Prometheus 데이터 소스로 추가한 뒤, 커뮤니티 대시보드 “Node Exporter Full”(ID 1860)을 가져옵니다. 1분 정도면 완전한 시스템 대시보드가 생깁니다.
NAT 요금제의 서버
NAT 서버는 개인 SSH 포트에서만 들어오는 연결을 받으므로, Prometheus가 그 익스포터를 스크레이프할 수 없습니다. 방향을 뒤집으세요. NAT 머신에서 Prometheus를 에이전트 모드로 실행하고, 이미 원격 쓰기를 받고 있는 모니터링 서버(위의 --web.enable-remote-write-receiver 플래그)로 밀어 넣습니다.
# /etc/prometheus/agent.yml on the NAT server
scrape_configs:
- job_name: self
static_configs: [ { targets: ['127.0.0.1:9100'] } ]
remote_write:
- url: https://prom-push.example.com/api/v1/write
9090번을 그대로 여는 대신, 그 수신 엔드포인트는 Caddy를 통해 basic auth와 함께 공개하세요.
솔직한 메모
Prometheus는 풀(pull) 방식입니다. 직접 관리하는 서버 무리에는 훌륭하지만 NAT 뒤에 있는 것에는 불편해서 에이전트 방식이 필요합니다. 로컬 스토리지는 수년치 이력을 위한 것이 아니므로, 장기 보관이 필요하면 나중에 원격 스토리지를 추가하세요. 그리고 대시보드는 가치의 절반일 뿐입니다. 첫날 최소 세 가지 알림(디스크 85% 초과, 메모리 압박, 대상 다운)을 설정하지 않으면, 무언가 이미 망가진 뒤에야 그래프를 보게 됩니다.
관련
- 가동 시간 모니터링용 VPS(Uptime Kuma): 장애 알림과 상태 페이지
- UFW 방화벽 설정 방법
- VPS에는 RAM이 얼마나 필요할까요?
댓글
아직 댓글이 없습니다. 첫 번째가 되세요.