[Monitoring] 홈서버 모니터링 & Down 알람 보내기(Slack, Oracle Cloud)

 

 

홈서버 모니터링 & Down 시 알람보내기

이전 포스팅에서 Grafana + Prometheus 로 각종 위험 알람들을 Slack 으로 보내는 인프라를 구축했었다

https://lucas-owner.tistory.com/106

[Grafana/Prometheus] 모니터링 알람 설정 (Slack, 원격지 서버 수집{Oracle Cloud})

 

하지만 이것들은 모두 홈서버 위에서 동작중인 서비스들로 막상 홈서버가 Down 되게 된다면? 

해당 인프라들은 동작하지도 않을것이고 서버가 Down 되었다는 사실도 홈서버의 서비스들이 먹통이 되었을경우 인지하게 될 수 밖에 없다. 

 

 

그렇기에 홈서버를 감시하는 또다른 외부 인프라(서비스)가 필요하게 된다.

이전 포스팅에도 잠깐 언급되었던 Oracle Cloud 서버 1대가 필자에게는 알맞은 외부 자원이기에 

이를 활용하여 홈서버 Down 감지 알람 구축을 해보도록 하겠다.

 

 

 

1. 계획

우선 오라클 클라우드 서버는 1개의 vcpu, 1GB Ram 사양으로 매우 작은 사양의 자원을 갖고 있고 

서버내부에서 운용하는 Nginx 만으로도 가끔 위험할때가 존재하기에 

grafana 나 다른 알람 서비스를 올리기에는 부담이 되었다. 

 

즉 적은 자원사용으로 운용되어, 서버에 무리를 주지 않아야 한다.

또한 기존의 슬랙채널로 알람을 보낼 수 있어야 한다 라는 2가지 필수 요건을 갖고 있다. 

 

추가로 홈서버는 외부에서의 요청을 엄격하게 필터링중인 상태인데

(포트 한정오픈, 웹서버 제외 모든 IP 요청 거부, 등등)

VPN 이나 Tunneling 같이 복잡한(추가해야하는) 서비스를 사용 하지 않는것을 요건으로 정했다.

 

---

 

- Shell Script & Crontab

 

역시 Linux 에서 가장 가벼우면서 간단하게 요건을 만족시킬 수 있는 방법으로 Shell Script + Crontab 활용으로 계획했다.

주기적으로 실행 할 수 있으며(상태체크), 적은 자원 소모를 만족하는 방법이었다.

 

 

뒷부분에 추가할 내용이지만 간단하게 설명하면, 홈서버에 Health Check API 를 두고 주기적으로 200ok 응답을 받으면 정상

그렇지 않다면 비정상 판단 -> 알람 전송 흐름이다.

 

 

 

2. Health Check 감지 프로그램 구성

우선 감지 프로그램에서 필요한 구성 파일은 3개이다. (실제 생성2개) 

 

• 실행 스크립트: 실제 홈서버 헬스체크 + 알람 전송
• 환경 파일: 실행 스크립트 내에서 사용할 환경파일
• 상태 파일: 알람 중복전송을 방지하는 파일, 실제로 생성하지 않고 프로그램이 관리하도록 함

환경 파일을 별도로 분리하는 이유는, 실행 스크립트를 Root 에게만 권한을 준다해도 혹시나 악의적인 입력을 통해 보안 문제가 발생할것을 방지하는 이유에서이다.

 

 

우선 서버 내에 해당 파일들이 위치할 디렉토리를 생성 후 root 계정에게만 권한을 주도록 하겠다. 

mkdir /opt/home-health

sudo chown -R root:root /opt/home-health
sudo chmod 700 /opt/home-health

 

 

 

- 환경설정 파일

그리고 환경 설정 파일을 생성해주도록 하겠다.

내용은 각자의 상황에 맞게 추가해주도록 하자

sudo nano /opt/home-health/home-health.env

HEALTH_URL="IP:PORT/health"
SLACK_WEBHOOK_URL="SLACK URL"


# root 권한
sudo chown root:root /opt/home-health/home-health.env
sudo chmod 600 /opt/home-health/home-health.env

헬스체크 하게될 서버와 path 를 지정하고, 알람을 보낼 슬랙 URL 을 저장하는 파일이다. 

그리고 root 계정에게만 권한을 부여하도록 하자. 

 

 

 

- 실행 스크립트

이제 실제 작업들을 수행할 스크립트 파일을 생성해보도록 하자. 

필자의 경우 딱 1번만 알람을 전송하고 그 이후에도 서버가 Down 된것을 감지해도 알람을 보내지 않도록 구성했다. 

 

sudo nano /opt/home-health/check-home-health.sh

# 파일 내부에 내용 넣기

sudo chown root:root /opt/home-health/check-home-health.sh
sudo chmod 700 /opt/home-health/check-home-health.sh

파일 생성 이후 내용을 먼저 넣든, 나중에 넣든 상관없다. 

환경설정 파일과 동일하게 root 계정에게만 권한을 부여하자. 

다만 실행이 가능해야 하기에 700 으로 부여하도록 하자.

 

 

- 스크립트 내부 내용

#!/bin/bash

set -euo pipefail

source /opt/home-health/home-health.env

STATE_FILE="/opt/home-health/home-health-down"

if /usr/bin/curl -k -fsS --max-time 5 "$HEALTH_URL" > /dev/null; then
    rm -f "$STATE_FILE"
    exit 0
fi

if [ -f "$STATE_FILE" ]; then
    exit 0
fi

HOSTNAME="$(hostname)"
NOW="$(date '+%Y-%m-%d %H:%M:%S')"

MESSAGE="🚨 홈서버 DOWN 감지
- 시간: ${NOW}
- 체크 서버: ${HOSTNAME}
- 대상: ${HEALTH_URL}"

if /usr/bin/curl -sS --max-time 10 -X POST "$SLACK_WEBHOOK_URL" \
  -H 'Content-type: application/json' \
  --data "{\"text\":\"${MESSAGE}\"}" > /dev/null; then

    touch "$STATE_FILE" # slack 전송 완료 후 상태파일 생성
fi

 

스크립트의 실행 흐름은 아래와 같다.

정상
↓
장애 발생
↓
[상태파일 없음]
↓
Slack 1회 전송
↓
상태파일 생성
↓
장애 지속
↓
Slack 안 보냄
↓
서버 복구
↓
상태파일 삭제
↓
다음 장애 시 다시 1회 전송

 

즉 주기적으로 서버의 응답을 기반으로 서버의 Down 여부를 체크후 슬랙으로 알람 전송

상태파일 생성으로 이후 감지되어도 알람 발송하지 않음. 

다만 복구 되면 상태파일 삭제 의 흐름이다.

 

 

- 테스트

sudo /opt/home-health/check-home-health.sh

 

쉘스크립트를 실제로 실행시켜, 정상 작동하는지 판단하자. 

필자의 경우 응답이 발생하지 않는 오류상황을 부여하였고 테스트가 성공적으로 진행 되었다. 

 

 

 

- Cron 등록 & 테스트

스크립트가 정상 실행 되는것을 확인 했으니, 자동으로 주기적 실행을 하도록 해야한다. 

Cron 을 사용하여 15분 마다 해당 스크립트를 실행 시키도록 하겠다. 

 

sudo crontab -e 

*/15 * * * * /opt/home-health/check-home-health.sh


# check
sudo crontab -l

Crontab 에 등록, 실제 등록이 되었는지 확인이다. 

 

이후 로그를 통해 실제로 크론이 돌았는지 확인 할 수 있다. 

 

 

 

번외 (Health Check API) 

Health Check 만을 위한 서비스를 구성하는것은 너무 과하다고 생각을 했고 

홈서버 제일 앞단에 존재하는 Gateway 의 Actuator 에서 제공하는 Health Check EndPoint 는 오픈하기 싫었다. 

혹여나 오픈하더라도 특정 IP 만을 상대로 열려야 하는데 그것을 구성하는것보다 간단한 방법을 사용하기로 했다. 

 

필자는 Gateway 로 Spring Cloud Gateway 를 사용중이며 운영중인 서비스에 맞게 구성하여 사용중인 상태다.

 

단순하게 Gateway 에 Health Check API 만을 위한 RestController 를 생성하고

Oracle 서버에서 보낸 요청이 아니면 응답을 전부 Reject 하는것으로 구성하였다. 

 

오라클 서버의 IP 가 아니면 모든 요청을 거부하기 때문에 홈네트워크 내부에 위치하는 개발pc 또한 Reject 하는 것을 확인할 수 있다.

 

물론 공격자가 어떻게든 공격을 할 수 있겠지만, 필자는 UFW/iptables 로 방화벽을 하나 더 두었기도 하고 여러개의 방화벽을 

더 두었지만 완벽한 방어를 위해 어떻게든 막아보도록 하자.