자체 모니터링: Uptime Kuma

머신의 제어판은 CPU, 트래픽, 메모리 그래프를 보여주지만, 사이트가 응답하는지 데이터베이스가 살아 있는지는 알 수 없어요. 이를 위해서는 직접 감시자를 두어야 해요. Uptime Kuma가 가장 간단한 선택이에요. 컨테이너 하나, 웹 인터페이스, 수십 가지 알림 방식이면 충분해요.

설치

services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    container_name: uptime-kuma
    restart: unless-stopped
    volumes:
      - ./data:/app/data
    ports:
      - "127.0.0.1:3001:3001"

docker compose up -d

포트를 로컬 인터페이스에 바인딩한 것은 의도된 설정이에요. 모니터링 패널을 외부에 노출하면 안 되니까요. 인증서와 비밀번호를 갖춘 웹 서버를 통해 접속하거나, SSH 터널을 통해 접속하세요.

ssh -L 3001:127.0.0.1:3001 root@<machine-address>

그다음 브라우저에서 http://localhost:3001로 이동하세요. 첫 번째 사용자가 관리자가 돼요.

무엇을 모니터링할까

작게 시작하세요. 그렇지 않으면 알림에 파묻혀 버려요.

• 각 사이트 홈페이지의 HTTP 검사 — 응답 코드와 시간.
• 응답 내 키워드 검사를 포함한 주요 API의 HTTP 검사. 페이지가 200을 반환해도 오류를 표시할 수 있어요.
• 데이터베이스나 게임 서버의 TCP 포트.
• 인증서 만료 — Kuma가 만료 N일 전에 경고해 줘요.
• 예약 작업을 위한 푸시 검사: 스크립트가 성공적으로 실행된 후 고유 주소로 요청을 보내고, 그렇지 않으면 알림을 받아요. 예약 작업과 잘 어울려요.

60초 간격이면 거의 항상 충분해요. 재시도는 2-3회로 설정하세요. 그렇지 않으면 네트워크 패킷 하나만 유실돼도 잘못된 경보가 울려요.

사이트 모니터링을 그 사이트가 있는 머신에 두지 마세요. 머신이 다운되면 감시자도 함께 다운되어 상황을 전혀 알 수 없어요. 외부 사이트의 경우 Kuma를 별도 머신에 두고, 이 머신에서는 내부 서비스 검사만 하세요.

알림

Telegram 봇이나 Discord 웹훅을 설정하고 알림 섹션에 추가하세요. 이메일 채널은 사용하지 마세요. 머신의 25, 465, 587 포트로 나가는 연결은 요청에 따라 열리기 전까지 차단되어 있고, Kuma의 이메일은 그냥 발송되지 않아요 — 메일 서버를 참고하세요.

유용한 습관:

• "다운"과 "인증서 만료"에 대해 별도 채널을 사용하세요. 첫 번째는 즉시 대응이 필요하고, 두 번째는 일주일 내에 처리하면 돼요.
• 복구 알림을 활성화하세요. 이것이 없으면 장애가 끝났는지 알 수 없어요.
• 설정 중 테스트 메시지를 보내세요. 문제의 절반은 잘못된 토큰 때문이고, 실제 장애가 발생해야 그 사실을 알게 돼요.

리소스 및 유지 관리

컨테이너는 150-250 MB 메모리로 충분하며 VDS-1에서 편안하게 실행돼요. 데이터베이스는 검사 기록과 함께 커져요. 설정에서 보존 기간을 90-180일로 지정하세요. 그렇지 않으면 1년 후 파일이 기가바이트 단위로 커져요 — 디스크 공간을 참고하세요.

./data 디렉터리에 서비스의 전체 상태가 저장돼요. 백업에 포함하세요. 서른 개가 넘는 검사를 손으로 복원하는 건 즐겁지 않아요.

흔한 실수

• 도메인 대신 IP 주소로 검사하기. 인증서와 가상 호스트가 검사되지 않고, DNS 장애도 감지되지 않아요.
• 너무 민감한 임계값. 2초 초과할 때마다 알림이 오면 사람들은 알림을 읽지 않게 돼요.
• 비밀번호 없이 패널을 외부에 노출하기. 주소, 포트, 서비스 이름 등 전체 인프라가 드러나요.