서버 가동 시간을 모니터링하고 알림을 설정하는 방법

"가동 시간 모니터링"이 실제로 의미하는 것

가동 시간 모니터링은 서로 다른 두 가지 질문에 답하며, 신뢰할 수 있는 서비스를 운영하려면 두 가지 모두가 필요합니다.

• 내 서버가 외부에서 접속 가능한가? (외부/블랙박스 모니터링) — 인터넷을 통해 접속하는 실제 클라이언트가 정상적인 응답을 받는가?
• 내 서버가 내부적으로 건강한가? (내부/화이트박스 모니터링) — CPU, 메모리, 디스크, 그리고 Nginx, MySQL 또는 애플리케이션 프로세스와 같은 개별 서비스.

외부 점검은 사용자가 체감하는 장애를 잡아냅니다. 내부 점검은 그 원인 — 디스크가 가득 차는 것, 폭주하는 프로세스, 스왑 스래싱(swap thrashing) — 을 종종 장애로 번지기 전에 잡아냅니다. 이 가이드는 Linux VPS에서 두 가지를 모두 설정하고, 몇 초 안에 여러분에게 도달하는 알림까지 구성합니다. 명령어는 Skyline Cloud 서버의 Ubuntu 22.04/24.04 또는 Debian를 기준으로 하며, AlmaLinux/RHEL의 경우 패키지 이름을 그에 맞게 조정하세요.

1단계 — 외부 가동 시간 점검

가장 간단한 외부 점검은 서버가 아닌 다른 머신에서 보내는 HTTP 요청입니다. 사이트가 응답하는지 확인하려면 두 번째 호스트(또는 노트북)에서 다음을 실행하세요.

curl -sS -o /dev/null -w "HTTP %{http_code} in %{time_total}s\n" \
  https://example.com/

정상적인 결과는 HTTP 200 in 0.184s와 같이 표시됩니다. 코드를 작성하지 않고 지속적으로 모니터링하려면 UptimeRobot과 같은 호스팅형 점검 도구나 Uptime Kuma와 같은 자체 호스팅 도구를 사용하세요. 자체 호스팅은 모니터링 데이터를 왕국(Kingdom) 내에 보관하므로 PDPL 및 NCA 준수에 유용합니다.

Uptime Kuma는 Docker를 사용해 별도의 작은 VPS(감시 대상 서버에서는 절대 실행하지 마세요)에서 실행하세요.

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

http://<monitor-ip>:3001을 열고 관리자 계정을 생성한 다음 Add New Monitor를 클릭하세요.

• Monitor Type: HTTP(s)
• URL: https://example.com/health (홈페이지가 아니라 가벼운 상태 점검 엔드포인트를 사용하세요)
• Heartbeat Interval: 60초
• Retries: 2 (한 번의 일시적 오류로 알림이 발생하는 것을 방지)
• Accepted Status Codes: 200-299

웹 서버가 페이지를 반환하는지만이 아니라, 애플리케이션 및 데이터베이스가 모두 정상인지를 확인하는 전용 /health 엔드포인트를 항상 모니터링하세요.

2단계 — node_exporter와 점검 스크립트를 활용한 내부 상태

단일 서버라면 완전한 Prometheus 스택은 필요하지 않습니다. cron이나 systemd 타이머로 실행하는 짧은 스크립트만으로 핵심을 모두 다룰 수 있습니다. /usr/local/bin/health-check.sh를 생성하세요.

#!/usr/bin/env bash
set -euo pipefail

THRESH_DISK=90      # percent
THRESH_MEM=90       # percent
WEBHOOK="https://hooks.example.com/your-webhook"

alert() {
  curl -fsS -X POST -H 'Content-Type: application/json' \
    -d "{\"text\":\"[$(hostname)] $1\"}" "$WEBHOOK" || true
}

# Disk usage on /
disk=$(df --output=pcent / | tail -1 | tr -dc '0-9')
[ "$disk" -ge "$THRESH_DISK" ] && alert "Disk at ${disk}% on /"

# Memory usage
mem=$(free | awk '/Mem:/ {printf "%d", $3/$2*100}')
[ "$mem" -ge "$THRESH_MEM" ] && alert "Memory at ${mem}%"

# Critical service must be active
for svc in nginx mysql; do
  systemctl is-active --quiet "$svc" || alert "Service $svc is DOWN"
done

실행 권한을 부여하고 테스트하세요.

sudo chmod +x /usr/local/bin/health-check.sh
sudo /usr/local/bin/health-check.sh

로깅과 누락된 실행 처리 측면에서 cron보다 더 신뢰할 수 있는 systemd 타이머로 스케줄을 설정하세요. /etc/systemd/system/health-check.service를 생성하세요.

[Unit]
Description=Server health check

[Service]
Type=oneshot
ExecStart=/usr/local/bin/health-check.sh

그리고 /etc/systemd/system/health-check.timer를 생성하세요.

[Unit]
Description=Run health check every 2 minutes

[Timer]

[Install]
WantedBy=timers.target

활성화하세요.

sudo systemctl daemon-reload
sudo systemctl enable --now health-check.timer
systemctl list-timers health-check.timer

더 풍부한 지표와 이력을 원한다면, CPU, 메모리, 디스크, 네트워크를 9100번 포트에서 지표로 노출하는 Prometheus node_exporter를 설치하세요.

sudo apt update && sudo apt install -y prometheus-node-exporter
sudo systemctl enable --now prometheus-node-exporter
curl -s http://localhost:9100/metrics | head

지표가 공개되지 않도록 localhost에 바인딩하거나 방화벽에서 9100번 포트를 제한하세요.

sudo ufw allow from <monitor-ip> to any port 9100 proto tcp

3단계 — 실제로 여러분에게 도달하는 알림

알림은 빠르게, 그리고 둘 이상의 채널을 통해 도착할 때만 유용합니다. 하나의 공급자가 장애를 일으켜도 알림이 끊기지 않도록 최소 두 개의 채널을 구성하세요.

알림 이메일은 적절한 SMTP 릴레이를 통해 보내세요 — 서버가 다운되면 경고를 보낼 수 없으므로 모니터링 대상 서버 자체의 메일에는 절대 의존하지 마세요. 비즈니스 이메일 호스팅이나 임의의 SMTP 공급자를 사용하세요. msmtp 기반의 최소 이메일 알림 예시입니다.

sudo apt install -y msmtp msmtp-mta
printf 'Subject: ALERT %s\n\n%s\n' "$(hostname)" "Disk high" \
  | msmtp -a default you@example.com

Uptime Kuma에서는 Settings → Notifications(Email/SMTP, Slack, Telegram 또는 일반 웹훅)에서 알림을 추가하고 각 모니터에 연결하세요.

4단계 — 임계값을 조정하고 알림 피로를 피하세요

잘못된 알림은 알림이 없는 것보다 더 나쁩니다 — 사람들이 무시하는 법을 배우기 때문입니다. 다음 규칙을 따르세요.

• 일시적인 오류를 무시하기 위해 알림을 보내기 전에 2회 이상 점검이 실패하도록 요구하세요(Retries 설정).
• 모든 내부 지표가 아니라, HTTP 5xx나 높은 지연 시간처럼 사용자가 체감하는 증상에 대해 알림을 보내세요.
• 합리적인 임계값을 설정하세요: 디스크 90%, 메모리 90% 지속, 평소 p95를 초과하는 지연 시간.
• 문제가 해소되는 시점을 알 수 있도록 복구 알림을 보내세요.
• 매월 알림을 검토하고, 거짓 경보를 낸 것은 삭제하거나 조정하세요.

전체 파이프라인 검증하기

알림에 의존하기 전에 알림 경로를 처음부터 끝까지 테스트하세요. 임계값을 일시적으로 낮추거나 비핵심 서비스를 중지하세요.

sudo systemctl stop nginx        # triggers the service-down alert
# confirm the alert arrives, then:
sudo systemctl start nginx

알림이 몇 분 이내에 받은 편지함과 채팅에 도착한다면, 여러분의 모니터링은 실제로 작동하는 것입니다. 테스트하지 않은 알림 파이프라인은 모니터링이 없는 것과 마찬가지입니다.

마무리

이제 여러분은 외부 가동 시간 점검, systemd 타이머와 node_exporter를 통한 내부 상태 모니터링, 그리고 실제로 검증한 다중 채널 알림을 갖추게 되었습니다. 모니터링 호스트는 감시 대상 서버와 분리해서 유지하고, PDPL 및 NCA 준수를 위해 데이터를 왕국 내에 보관하며, 트래픽이 증가함에 따라 임계값을 다시 검토하세요.

애플리케이션과 모니터링 스택을 함께 호스팅할 신뢰할 수 있는 왕국 내 VPS가 필요하신가요? 현지 아랍어 지원과 투명한 가격으로 제공됩니다. Skyline Cloud 계정을 만들고 몇 분 안에 배포하세요.