사이트 무료 업타임 모니터링 붙이기

작성자:

서버가 죽어 있으면 큰일이라 외부 업타임 모니터링을 붙였다. 서버 바깥에서 1분마다 ddlabx.com을 두드려보고, 페이지에서 특정 키워드가 사라지면 디스코드로 즉시 알려주는 구조다. 흔히 쓰는 UptimeRobot 무료는 상업용 사이트를 금지해서 피했고, 무료·상업용 허용에 1분 감지가 되는 HetrixTools를 골랐다. 그런데 키워드를 DDlabx(마지막 x를 소문자)로 잘못 넣는 바람에, 멀쩡한 사이트가 4개 지역에서 “keyword not found” 다운으로 잡히는 사고(?)가 났다. 덕분에 다운·복구 알림이 실제로 오는지까지 한 번에 검증됐다.

왜 업타임 모니터링인가

내 서버가 Vultr 서울의 1 vCPU·RAM 2GB짜리 작은 인스턴스라는 점이다. PHP-FPM이 메모리를 물고 늘어지거나, 설정 한 줄 잘못 건드려 Nginx가 죽으면 사이트는 조용히 5xx를 뱉는다.

그래서 “죽고 나서 아는” 게 아니라 “죽은 지 1분 안에 아는” 장치가 필요했다. 이번 편은 서버를 튜닝하거나 복구하는 이야기가 아니다. 서버가 죽었다는 사실 자체를 즉시 감지하는, 가장 값싸고 위험 없는 안전장치를 붙이는 기록이다.

감시는 왜 서버 “바깥”에서 해야 하나

모니터링 도구를 감시 대상 서버 안에 깔면 근본적인 모순이 생긴다. 서버가 죽으면 그 안에 있던 감시 도구도 같이 죽어서, “나 죽었어”라는 알림 자체를 못 보낸다. 정전이 났는데 정전 경보기가 그 집 콘센트에 꽂혀 있는 격이다.

그래서 업타임 감시는 반드시 대상 밖에서 문을 두드려봐야 한다. 이번 편이 외부 SaaS를 쓰는 이유다. 남의 서버가 내 서버에 1분마다 접속을 시도하고, 응답이 없거나 이상하면 나에게 연락한다. 내 서버엔 아무것도 설치하지 않는다. 순수하게 바깥에서 GET 요청만 날리는 읽기 전용이라, 사이트에 주는 위험이 0이라는 점이 특히 마음에 들었다.

UptimeRobot을 안 쓴 이유

무료 업타임 모니터링 하면 보통 UptimeRobot을 떠올린다. 나도 그러려다 약관에서 걸렸다. UptimeRobot 무료 플랜은 2024년 하반기부터 개인·비상업용으로 제한됐고, 수익을 내는(혹은 내려는) 사이트를 감시하면 약관 위반으로 계정이 정지될 수 있다. 감시하려고 만든 계정이 정지당하는, 웃지 못할 상황을 피하려고 대안을 찾았다.

결국 고른 건 HetrixTools다. 무료 플랜에 상업용 제한이 없고, 모니터 여러 개를 1분 간격으로 돌릴 수 있으며, 디스코드·텔레그램·이메일 등 알림 채널이 넉넉하다. 나중에 문의 폼 메일을 붙일 때 유용한 블랙리스트 감시와 서버 자원 감시까지 딸려오는 것도 덤이었다.

Tip. “무료”만 보고 고르면 나처럼 약관에서 걸린다. 수익형 블로그라면 상업용 허용 여부를 먼저 확인하자. 무료·상업용 허용 조합으로는 HetrixTools 외에 StatusCake, BetterStack, Pulsetic 같은 선택지도 있다.

‘살아있음’을 무엇으로 판정할까 — 200으로는 부족하다

여기서 흔한 함정이 하나 있다. 대부분의 감시 도구는 기본적으로 “응답 코드가 200이면 정상”으로 본다. 그런데 워드프레스는 DB가 죽어도 겉으로는 200을 주는 경우가 있다. Nginx와 PHP는 살아 있는데 MariaDB만 뻗으면, 텅 빈(혹은 에러 메시지만 있는) 페이지에 버젓이 200이 찍힌다. 이러면 감시 도구는 “정상”이라 판단하고, 나는 사이트가 반쯤 죽은 줄도 모른다.

그래서 200 코드가 아니라, 페이지가 제대로 렌더링됐을 때만 나오는 문자열을 감시하기로 했다. 내 블로그는 헤더·푸터에 항상 DDlabX가 박혀 있으니 이걸 판정 키워드로 삼으면 된다. 이 글자가 사라지면 = 워드프레스가 제대로 못 그리고 있다 = 다운, 이라는 논리다.

본격적으로 붙이기 전에, 기준값부터 서버에서 직접 쟀다. 10번 연속 요청해 응답 코드와 응답시간을 확인한 것이다.

for i in $(seq 1 10); do
  curl -o /dev/null -s -w "%{http_code}  %{time_total}s\n" https://ddlabx.com/
  sleep 1
done

# 결과 (발췌)
200  0.020261s
200  0.021494s
200  0.024523s
200  0.040832s
200  0.021284s
# ... 10회 전부 200, 대부분 20~25ms (한 번만 40ms로 튐)

이어서 판정 키워드가 실제로 페이지에 있는지도 확인했다.

curl -s https://ddlabx.com/ | grep -c "DDlabX"
# → 여러 번 등장. 키워드로 쓰기에 충분하다.

붙이는 법 — 키워드 모니터 + 디스코드 웹훅

HetrixTools는 알림을 “Contact List”라는 묶음으로 관리하고, 그걸 모니터에 연결하는 구조다. 그래서 알림 통로(디스코드)를 먼저 만들고 → 감시 모니터를 등록하는 순서가 매끄럽다.

1) 디스코드 웹훅 만들어 Contact List에 연결

디스코드 서버에서 서버 설정 → 연동(Integrations) → 웹훅 만들기로 웹훅을 생성하고, 알림 받을 채널을 고른 뒤 웹훅 URL 복사를 누른다. 그 URL을 HetrixTools의 Contact List에 있는 “Slack / Discord / Mattermost / RocketChat” 칸에 붙여넣으면 끝이다. 붙인 뒤 “테스트 알림 전송”으로 디스코드에 메시지가 실제로 뜨는지 확인했다 — 잘 왔다.

보안 주의. 디스코드 웹훅 URL은 사실상 비밀번호다. 그 주소를 아는 사람은 누구나 그 채널에 글을 쓸 수 있다. 스크린샷을 공개할 일이 있으면 URL은 반드시 가리고, 노출됐다면 웹훅을 삭제 후 재발급하자.

2) 키워드 업타임 모니터 등록

새 Website Monitor를 추가하고 아래처럼 채웠다.

  • Website Link: https://ddlabx.com/
  • Keyword: DDlabX — 이게 핵심. 200이 아니라 이 글자로 살아있음을 판정한다.
  • Contact List: 방금 만든 디스코드 리스트(이메일도 함께 넣어 이중화)
  • Locations: 고를 수 있는 만큼 여러 지역(뉴욕·런던·싱가포르·도쿄 등)

멀쩡한 사이트가 “다운”이라고 알림이 왔다

여기서 사고가 났다. 감시가 진짜로 동작하는지 시험하려고 키워드를 잠깐 바꿨는데, 하필 DDlabX를 DDlabx(마지막 X를 소문자)로 잘못 저장했다. 그러자 곧바로 디스코드에 다운 알림이 떴다.

ddlabx.com is now DOWN
Noticed at: 2026-07-28 14:43:37 (UTC 09:00)
Encountered errors:
New York: keyword not found
London: keyword not found
Singapore: keyword not found
Tokyo: keyword not found

이상했다. 방금 grep으로는 분명히 보였는데, 감시 도구는 4개 지역 전부 “keyword not found”라고 한다. 같은 URL을 봤는데 결과가 다르다. 원인은 대소문자였다. HetrixTools의 키워드 매칭은 대소문자를 구분한다. 페이지에 있는 건 DDlabX인데, 내가 찾으라고 한 건 DDlabx였으니 영원히 못 찾는다. 서버에서 재현해보면 명확하다.

curl -s https://ddlabx.com/ | grep -c "DDlabX"   # → 여러 개 (있음)
curl -s https://ddlabx.com/ | grep -c "DDlabx"   # → 0 (대소문자 달라 없음)

키워드를 다시 DDlabX로 되돌리자, 이번엔 복구 알림이 왔다.

ddlabx.com is now UP
Downtime: 5 min
Noticed at: 2026-07-28 14:48:33 (UTC 09:00)

결과적으로 인위적인 테스트보다 더 진짜 같은 시나리오가 됐다. “멀쩡히 돌던 사이트가 설정 실수로 죽었다가, 고치니 살아난” 실제 사건이고, 그 다운·복구 알림이 둘 다 디스코드로 정확히 도착했다. 감시-알림 파이프라인이 양방향으로 검증된 셈이다.

실측값

항목값
서버 로컬 응답(10회)전부 200, 20~25ms (최대 40ms)
감시 도구HetrixTools 무료 (상업용 허용)
무료 플랜 체크 간격[확인 필요] (문서상 1분)
외부 지역별 응답시간[확인 필요] — 뉴욕/런던/싱가포르/도쿄
판정 방식키워드 DDlabX (대소문자 구분)
테스트 다운 감지2026-07-28 14:43:37 (KST)
복구(UP) 감지2026-07-28 14:48:33 (KST), Downtime 5분
알림 채널디스코드 웹훅 + 이메일

※ [확인 필요] 항목은 대시보드 표시값을 실측해 추후 업데이트 예정. 추정으로 채우지 않는다.

한계와 트레이드오프

정직하게 짚자면, 이건 만능이 아니다.

  • 이건 예방도 복구도 아니다. 서버가 죽는 걸 막아주지 않는다. “죽었다”는 사실을 빨리 알려줄 뿐이다. 알림을 받아도 복구는 여전히 내 몫이다.
  • 감지에는 지연이 있다. 무료 플랜의 체크 간격과, 오탐을 줄이려 여러 지역에서 재확인하는 로직 때문에 “죽은 순간”과 “알림” 사이에 시차가 있다. 이번 다운도 확정까지 시간이 걸렸다.
  • 키워드 판정은 HTML만 본다. 자바스크립트로 그려지는 문자열은 감지 못 한다. 그리고 방금처럼 대소문자 한 글자에도 오탐이 난다. 판정 키워드는 실제 소스에 있는 정확한 표기로 넣어야 한다.
  • 외부 감시는 ‘무엇’이 아니라 ‘죽었다’만 안다. 왜 죽었는지(메모리? DB? 설정?)는 안 알려준다. 원인 추적은 서버 안쪽 로그와 자원 모니터링의 몫이다.

댓글 남기기