가이드

작성자 Matt Connor 2026-07-15 · 업데이트됨 2026-07-24

Uptime Kuma Docker 설치 및 VPS 구축 가이드

Q: Telegram 또는 이메일로 알림을 받는 방법은 무엇입니까?

Settings의 Notifications 메뉴에서 채널을 추가한 후, 각 monitor에 연결하십시오. Telegram의 경우 @BotFather를 사용하여 bot을 생성하고 https://api.telegram.org/bot /getUpdates에서 chat.id을 읽어오십시오. 이메일의 경우, SSL에는 465를 사용하고, 제공업체가 2단계 인증을 사용하는 경우 STARTTLS에는 앱 비밀번호와 함께 587을 사용하십시오. Test를 눌러 메시지가 정상적으로 도착하는지 확인한 후 사용하십시오.

Q: Uptime Kuma로 cron job이나 backup script를 모니터링할 수 있습니까?

가능합니다. 그것이 Push monitor의 역할입니다. Uptime Kuma가 URL을 제공하며, 스크립트 마지막에 curl를 호출하여 성공했을 때만 신호를 보냅니다. 작업이 실패하거나 서버가 다운되면 heartbeat가 전달되지 않으며, 설정된 간격이 지나면 알림이 발생합니다. 외부 체크 방식으로는 스크립트 내부를 확인할 수 없으므로, 예약된 작업의 실제 실행 여부를 확인하는 가장 확실한 방법입니다.

Docker를 사용하여 Uptime Kuma를 설치하고 웹사이트, DNS, cron job을 모니터링하십시오. 오보를 방지하기 위해 대상 서버와 분리된 VPS에서 실행하는 최적의 아키텍처와 Telegram 알림 설정 방법을 상세히 설명합니다.

구축 목표

이 시스템은 외부에서 다른 서버와 웹사이트를 감시하는 단일 소형 컨테이너입니다. 대상이 응답을 중단하면 즉시 email, Telegram, Discord 또는 webhook을 통해 알림을 보냅니다. Uptime Kuma는 SQLite 파일을 사용하는 단일 Node 프로세스입니다. 따라서 256-512 MB의 RAM 환경에서도 원활하게 작동합니다. 실시간 대시보드, 이력 그래프, 공개 상태 페이지를 제공합니다. 설치는 10줄의 Compose 파일로 완료됩니다. 중요한 점은 실행 위치와 테스트 시 알림이 실제로 작동하는지 여부입니다. 알림이 전달되는지 검증되지 않은 모니터링 도구는 없는 것보다 못합니다. 아무것도 감시하지 못하면서 보호받고 있다는 착각만 주기 때문입니다.

장애가 발생해도 모니터링이 가능한 위치에서 실행하십시오

이 결정은 전체 시스템의 성패를 결정하므로 가장 먼저 고려해야 합니다. Uptime Kuma를 모니터링 대상과 동일한 서버에서 실행하지 마십시오. 모니터링 대상 서버에서 모니터링이 실행되면, 서버가 다운되거나 메모리가 부족해지는 상황에서 모니터링 도구도 함께 중단됩니다. 이 경우 알림을 전혀 받을 수 없습니다. 모니터링 도구가 응답하지 않는 상태는 모든 서비스가 정상인 상태와 구분할 수 없습니다. 서버가 작동 중일 때도 주의할 점이 있습니다. localhost를 모니터링할 때 모니터링 도구가 대상 서버의 CPU를 공유하면, 부하가 급증할 때 체크 시간이 초과될 수 있습니다. 이로 인해 실제 서비스는 정상임에도 대상 상태가 down으로 표시되는 오보가 발생합니다.

따라서 Uptime Kuma는 모니터링 대상과 다른 VPS에서 실행하십시오. 가급적 다른 제공업체나 다른 리전을 사용하는 것이 좋습니다. 사용자가 서비스를 이용하는 방식과 동일하게, 즉 공용 인터넷을 통해 hostname으로 접속하는 환경을 구축하십시오. 저렴한 인스턴스로도 충분하며, 작은 모니터링 VPS 하나로 모든 서버를 감시할 수 있습니다. Kuma 자체의 장애를 감지하려면, 다른 곳에서 cron을 통해 push heartbeat를 전송하도록 설정하십시오.

Prerequisites and sizing

Docker Engine 및 Compose v2 plugin이 설치된 신규 Ubuntu 24.04 VPS가 필요합니다. 패키지는 버전이 낮은 docker.io 배포판 패키지 대신 Docker 공식 apt repository에서 설치해야 합니다.
256 MB RAM은 소수의 모니터링에 적합합니다. 수십 개의 모니터링 항목과 reverse proxy를 안정적으로 운영하려면 512 MB에서 1 GB의 RAM이 권장됩니다. 체크 주기 사이의 CPU 사용률은 매우 낮습니다.
TLS 및 공개 상태 페이지가 필요한 경우에만 도메인과 DNS A 레코드(예: VPS를 가리키는 status.example.com)가 필요합니다. 프라이빗 인스턴스는 DNS 없이 VPN 또는 SSH tunnel을 사용할 수 있습니다.
알림을 보낼 외부 네트워크 연결이 필요합니다. SMTP(메일 서비스용) 또는 HTTPS(Telegram 및 Discord용)가 필요합니다.

The Compose file

이 내용을 /srv/uptime-kuma/compose.yaml에 저장하십시오.

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

volumes:
  kuma-data:

서비스를 실행하고 첫 부팅 과정을 확인하십시오:

sudo mkdir -p /srv/uptime-kuma
# save the file above as /srv/uptime-kuma/compose.yaml, then:
cd /srv/uptime-kuma && sudo docker compose up -d
sudo docker compose logs -f uptime-kuma

정상적으로 시작되면 Listening on 3001 로그가 기록된 후 중단됩니다. 해당 파일에는 의도적인 설정이 세 가지 포함되어 있습니다.

3001:3001이 아닌 127.0.0.1:3001:3001입니다. Docker는 ufw가 패킷을 확인하기 전에 DNAT 규칙을 통해 포트를 공개합니다. 따라서 3001:3001을 그대로 사용하면 방화벽 설정과 관계없이 대시보드가 공용 인터넷에 노출됩니다. loopback에 바인딩하면 리버스 프록시만 외부로 노출되어 보안이 유지됩니다. 프록시를 거치지 않고 self-hosted WireGuard VPN을 통해 3001에 직접 접속할 수도 있습니다.

/app/data에 지정된 named volume입니다. Uptime Kuma의 모든 데이터(SQLite 데이터베이스, 모니터링 항목, 알림 설정, 상태 페이지 로고)는 이곳에 저장됩니다. 이 볼륨을 분실하면 관리자 화면이 초기화됩니다. 따라서 이 데이터는 반드시 백업해야 합니다.

이미지 태그를 :2으로 고정했습니다. 이는 현재의 안정적인 버전입니다. 복사하기 전에 Docker Hub에서 최신 major 버전을 확인하십시오. 프로젝트에서 권장하지 않는 latest과 같은 moving tag는 사용하지 마십시오. 이 이미지의 major 버전 업데이트는 일방향 데이터베이스 마이그레이션을 수반하므로, 일반적인 pull 과정에서 의도치 않게 발생해서는 안 됩니다.

주의 사항: /app/data은 POSIX file lock을 지원하는 파일 시스템에 위치해야 합니다. 로컬 Docker volume은 사용 가능합니다. NFS를 사용하면 SQLite 데이터베이스가 손상되어 SQLITE_BUSY 및 database disk image is malformed 오류가 발생하므로 네트워크 공유를 사용하지 마십시오.

First run: create the admin account

https://status.example.com 프록시를 통해 인스턴스에 접속하거나, SSH 터널을 사용하십시오. ssh -L 3001:127.0.0.1:3001 user@your-vps를 실행한 후 http://localhost:3001를 엽니다. 첫 페이지는 관리자 사용자 이름과 비밀번호를 설정하는 양식입니다. 기본 로그인 정보는 제공되지 않습니다. 실제 비밀번호를 설정하십시오. 이 대시보드는 모니터링 중인 모든 항목의 내부 주소와 토큰에 접근할 수 있습니다. 비밀번호를 잊어버린 경우, 브라우저가 아닌 호스트에서 재설정하십시오:

sudo docker compose exec uptime-kuma npm run reset-password

알림 채널을 먼저 추가하고 테스트하십시오

모니터를 추가하기 전에 알림을 설정하십시오. 그래iving 각 모니터를 생성할 때 채널을 바로 연결할 수 있습니다. Settings > Notifications > Setup Notification으로 이동하십시오. 각 채널의 Test 버튼을 사용하여 메시지가 정상적으로 수신되는지 확인하십시오. 테스트되지 않은 알림은 설정이 조용히 실패하는 두 번째로 흔한 원인입니다.

Email (SMTP). host, port, encryption, username, password, From, To를 입력하십시오. 가능한 조합은 "Secure"를 TLS/SSL로 설정한 465 또는 STARTTLS를 사용하는 587입니다. Gmail 및 2단계 인증을 사용하는 대부분의 서비스에서는 app password를 생성해야 합니다. 일반 계정 비밀번호를 사용하면 Error: Invalid login: 535-5.7.8 Username and Password not accepted 오류가 발생합니다.

Telegram. @BotFather에게 /newbot을(를) 보내고 bot token을 복사하십시오. chat ID를 얻으려면 새 봇에게 메시지를 한 번 보낸 후, https://api.telegram.org/bot<token>/getUpdates를 열어 JSON에서 chat.id을(를) 확인하십시오. 메시지를 한 번도 보내지 않은 봇은 getUpdates이(가) 비어 있어 메시지를 보낼 수 없습니다.

Discord. 해당 채널에서 Edit Channel > Integrations > Webhooks > New Webhook를 실행하십시오. 생성된 URL을 복사하여 Discord 알림 설정에 붙여넣으십시오.

Generic webhook. Slack incoming webhook, 커스텀 엔드포인트, 홈 오토메이션 훅 등 기타 서비스에 사용합니다. Webhook 유형은 지정된 URL로 JSON 페이로드를 POST합니다. 포함된 Apprise 통합 기능은 목록에 있는 90여 개의 다른 서비스 대부분을 지원합니다.

모니터 추가 (한 번에 한 유형씩)

Add New Monitor를 클릭합니다. 유형을 선택한 후 Friendly Name, Check Interval(60초 권장), Retries(연속 실패 횟수; 패킷 하나로 알림이 발생하지 않도록 2 또는 3으로 설정), 그리고 알림 설정을 지정합니다. 사용하는 유형은 다음과 같습니다.

HTTP(s). 전체 URL을 사용합니다. 상태 코드가 정상 범위이면 "up" 상태입니다(기본값은 200-299이며, 301 또는 401이 정상인 경우 Accepted Status Codes에서 범위를 넓히십시오). 웹사이트 및 API 모니터링의 핵심 기능입니다.
HTTP(s) - Keyword. HTTP 요청과 동일하지만, 본문에 특정 문자열이 포함되어야 "up" 상태로 간주합니다(Invert가 해제된 경우). 이 기능은 사이트가 "Error establishing a database connection"을 출력하며 200 OK를 반환할 때 유용합니다. 일반 HTTP 체크는 이를 정상으로 판단할 수 있습니다.
TCP Port. 호스트와 포트에 대한 TCP 연결을 확인합니다. HTTP가 아닌 서비스에 사용합니다. 예: 22번 포트의 SSH, 5432번 포트의 Postgres, 25번 포트의 SMTP 서버, 게임 서버 등.
Ping. ICMP echo를 사용하여 도달 가능성과 지연 시간을 확인합니다. 비용이 저렴합니다. 단, 많은 네트워크와 클라우드 방화벽이 ICMP를 차단하므로, Ping 모니터가 "down" 상태를 나타내면 "호스트 다운"이거나 "공급업체가 Ping을 차단함"을 의미할 수 있습니다. TCP 모니터로 교차 검증하십시오.
DNS. 지정한 리졸버를 통해 레코드(A, AAAA, MX, TXT 등)를 확인합니다. 응답 값을 검증할 수 있어 등록업체나 DNS 장애를 조기에 감지할 수 있습니다.
Push. 내부에서 외부로 알림을 보내는 방식이며, 다음 섹션에서 다룹니다.

Push (heartbeat) 모니터를 이용한 cron job 모니터링

위에서 언급한 모든 모니터는 외부에서 서비스 내부로 접속하는 방식입니다. Push 모니터는 반대로 작동합니다. Uptime Kuma가 대기하고 있으면, job이 Uptime Kuma를 호출하여 실행되었음을 알립니다. 이는 백업이나 cron을 감시하는 유일한 확실한 방법입니다. HTTP 체크는 URL의 응답 여부만 알 수 있지만, 작업의 완료 여부는 오직 해당 job만 알 수 있기 때문입니다.

Push 유형의 모니터를 생성합니다. Uptime Kuma는 다음과 같은 고유 URL을 생성합니다:

https://status.example.com/api/push/j8Xa2Kd9Qe?status=up&msg=OK&ping=

Heartbeat Interval을 job의 실행 주기보다 약간 더 길게 설정합니다. 그 다음, 스크립트의 끝에 다음 한 줄을 추가하여 작업이 성공했을 때만 호출되도록 합니다:

#!/usr/bin/env bash
set -euo pipefail
# ... your backup or job runs here; set -e aborts on any failure ...
curl -fsS --retry 3 "https://status.example.com/api/push/j8Xa2Kd9Qe?status=up&msg=backup+ok&ping="

job이 실패하면 set -e이 curl 실행 전에 중단됩니다. 서버가 다운된 경우에도 curl은 실행되지 않습니다. 어떤 경우든 heartbeat가 중단되며, 설정된 interval-plus-retries 기간이 지나면 Uptime Kuma는 모니터 상태를 down으로 변경하고 알림을 보냅니다. 해당 push token은 비밀로 취급하십시오. 토큰을 가진 사람은 누구나 정상 상태인 것처럼 속일 수 있습니다.

공개 상태 페이지 구축하기

상태 페이지는 고객용 뷰입니다. 대시보드를 노출하지 않고 어떤 서비스가 작동 중인지와 최근 이력을 보여줍니다. Status Pages로 이동하여 New Status Page를 클릭합니다. 이름을 입력하고 slug(/status/main와 같은 공개 경로)를 지정합니다. "Websites" 또는 "APIs"와 같은 그룹에 원하는 monitor를 드래그하여 추가합니다. 로고와 짧은 설명을 추가한 후 Save를 클릭합니다. 또한 페이지를 전용 도메인에 연결하여 status.example.com가 직접 서비스하도록 설정할 수 있습니다.

두 가지 주의 사항이 있습니다. 상태 페이지는 특정 서비스의 존재 여부와 작동 상태를 공개하므로, 공개해도 괜찮은 monitor만 추가하십시오. 대시보드는 로그인 후에만 접근할 수 있지만, 상태 페이지는 의도적으로 공개되어 있으며 인증이 필요하지 않습니다.

TLS를 적용한 리버스 프록시 설정 및 websockets 주의 사항

공개 인스턴스의 경우, TLS와 호스트 이름을 적용하기 위해 loopback에 바인딩된 컨테이너 앞에 리버스 프록시를 배치하십시오. 가장 흔히 발생하는 문제는 Uptime Kuma의 UI가 실시간 Socket.IO 앱이라는 점입니다. 따라서 프록시가 WebSocket 연결을 upgrade해야 합니다. 이 설정을 누락하면 페이지는 로드되지만 연결은 되지 않습니다. 대시보드는 "Connecting..." 상태로 머물며, 실시간 상태 업데이트가 이루어지지 않고 브라우저 콘솔에 WebSocket connection to 'wss://.../socket.io/...' failed 오류가 표시됩니다.

nginx와 certbot을 설치한 후, loopback 포트로 프록시를 전달하는 vhost를 작성하십시오. 우선 80 포트로 설정한 뒤 certbot을 통해 TLS를 추가하십시오. 인증서 발급, 갱신 타이머 및 관련 오류 유형은 issuing Let's Encrypt certificates with certbot and nginx에서 다룹니다.

sudo apt install -y nginx certbot python3-certbot-nginx

이 내용을 /etc/nginx/sites-available/status.example.com로 저장하십시오. 다음 두 줄의 WebSocket 설정이 가장 중요합니다:

server {
    listen 80;
    server_name status.example.com;

    location / {
        proxy_pass http://127.0.0.1:3001;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 3600s;
    }
}

사이트를 활성화하고 설정을 테스트하십시오. 그 다음 certbot을 사용하여 443 포트에서 대기하도록 블록을 재작성하고, 인증서를 적용하며, HTTP-to-HTTPS 리다이렉트를 추가하십시오:

sudo ln -s /etc/nginx/sites-available/status.example.com /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
sudo certbot --nginx -d status.example.com

Upgrade와 Connection "upgrade" 설정이 핵심이며, proxy_read_timeout 3600s은 nginx가 장시간 유지되는 소켓을 끊지 않도록 합니다. certbot은 이 두 설정을 생성된 443 블록에 복사합니다. 하나의 프록시 뒤에서 여러 컨테이너를 운영 중이라면, routing them through Traefik with automatic TLS를 통해 컨테이너 라벨로 동일한 작업을 수행할 수 있으며, 기본적으로 WebSocket upgrade를 전달합니다.

vhost 전체에 basic-auth를 적용하지 마십시오. 그렇게 하면 공개 상태 페이지와 /api/push 엔드포인트까지 차단됩니다. Uptime Kuma의 내장 로그인 기능을 사용하십시오. 인터넷에 노출되는 경우 fail2ban watching for repeated failed logins를 추가하십시오. 대시보드를 공개할 필요가 없다면 프록시를 제거하고 VPN을 통해 접속하십시오.

올바른 Certificate-expiry monitoring 방법

HTTP(s) monitor를 사용하면 TLS certificate 만료 전에 경고를 받을 수 있습니다. Certificate Expiry Notification을 체크하면 Uptime Kuma가 설정된 일수 전에 알림을 보냅니다. 다음 두 가지 실수는 잘못된 결과를 초래합니다.

첫째, IP가 아닌 hostname으로 모니터링하십시오. SNI가 없는 요청은 서버의 default certificate를 가져오므로 Hostname/IP does not match certificate's altnames 오류가 발생합니다.

둘째, 만료 경고를 받고 싶은 monitor에서는 Ignore TLS/SSL Error를 체크하지 마십시오. 이 옵션은 self-signed internal hosts (unable to verify the first certificate, DEPTH_ZERO_SELF_SIGNED_CERT)를 위한 것입니다. 이 옵션을 활성화하면 Uptime Kuma가 certificate 만료를 포함하여 모든 certificate 검사를 중단합니다.

Backups: it is one directory

모든 데이터가 /app/data에 저장되므로, 백업은 컨테이너가 중지된 상태에서 해당 볼륨을 복사해야 합니다. 그래야 SQLite 파일의 일관성이 유지됩니다:

cd /srv/uptime-kuma
sudo docker compose stop
sudo docker run --rm \
  -v uptime-kuma_kuma-data:/data \
  -v /var/backups/kuma:/backup \
  alpine tar czf /backup/kuma-$(date -u +%Y%m%dT%H%M%SZ).tgz -C /data .
sudo docker compose start

Compose는 볼륨 이름 앞에 프로젝트 디렉토리명을 접두사로 붙입니다. 따라서 먼저 docker volume ls | grep kuma 명령어로 볼륨의 실제 이름을 확인하십시오. 그 다음, 생성된 tarball 파일을 서버 외부로 복사하십시오. 동일한 VPS 내에 백업을 두는 것은 복사본일 뿐 진정한 백업이 아닙니다. 복구 과정은 이와 반대입니다. 스택을 중지하고, 빈 /app/data 볼륨에 압축을 푼 뒤, 스택을 다시 시작하십시오.

Upgrades

Upgrades는 image pull 방식으로 진행됩니다:

cd /srv/uptime-kuma
sudo docker compose pull
sudo docker compose up -d

새 컨테이너는 첫 실행 시 모든 database migration을 수행합니다. docker compose logs -f를 확인하십시오. image를 pull하기 전에 위의 백업을 수행하십시오. 또한 major tag 범위를 유지해야 합니다. :1에서 :2로의 이동은 일방향 migration이므로, 먼저 백업을 수행하고 release notes를 확인하십시오.

Failure modes, with the strings you will see

localhost를 대상으로 하는 모니터의 허위 "down" 상태. 모니터에 timeout of 48000ms exceeded 또는 connect ETIMEDOUT 오류가 발생하며 빨간색으로 표시되지만, 실제로는 노트북에서 서비스 응답이 확인됩니다. Uptime Kuma가 실행 중인 호스트와 동일한 호스트를 대상으로 설정한 경우입니다. CPU 또는 메모리 급증으로 인해 체크 프로세스가 자원을 할당받지 못한 것이지, 대상 서비스의 문제가 아닙니다. 모니터링 대상을 별도의 VPS로 변경하고 공용 hostname을 대상으로 설정하십시오.

connect ECONNREFUSED 127.0.0.1:443 (또는 모든 port). 해당 port에서 대기 중인 프로세스가 없습니다. 서비스가 중단되었거나, 127.0.0.1가 서버가 아닌 container인 상태에서 container 내부의 localhost를 모니터링하고 있는 것입니다. loopback이 아닌 공용 hostname을 모니터링하십시오.

이메일 테스트 중 Invalid login: 535-5.7.8 Username and Password not accepted. SMTP 자격 증명이 잘못되었습니다. 또는 제공업체에서 app-specific password를 요구하는데 일반 계정 password를 입력한 경우입니다. app password를 생성하여 입력하십시오.

이메일 테스트 중 connect ETIMEDOUT 또는 queryA ETIMEDOUT <host>. port가 잘못되었거나, 제공업체가 outbound SMTP를 차단한 상태입니다. 465 또는 587 설정이 Secure/STARTTLS 설정과 일치하는지 확인하십시오. 또한 host에서 nc -vz smtp.example.com 587를 사용하여 테스트하십시오. 많은 제공업체가 outbound 25를 차단하며, 일부는 요청 전까지 submission port를 차단합니다.

이메일 테스트 중 self signed certificate 또는 unable to verify the first certificate. SMTP 서버의 인증서가 Node에서 신뢰할 수 없는 인증서입니다. 임시방편으로 해결하려 하지 말고 mail server의 인증서를 수정하십시오.

Dashboard가 "Connecting..." 상태에서 멈추고, console에 WebSocket connection ... failed가 표시됨. reverse proxy가 WebSocket을 upgrade하지 못하고 있습니다. nginx에 Upgrade 및 Connection "upgrade" header를 추가하거나, Traefik 또는 Caddy와 같이 해당 header를 기본적으로 전달하는 proxy를 사용하십시오. HTML은 일반 HTTP GET 방식이므로 로드되지만, 실시간 socket에는 upgrade가 필요합니다.

인증서 만료 모니터가 경고를 보내지 않거나 잘못된 경고를 보냄. Ignore TLS/SSL Error가 체크되어 인증서 확인이 비활성화되었거나, 모니터링 대상이 IP 주소여서 SNI 누락으로 인해 잘못된 인증서를 읽어 Hostname/IP does not match certificate's altnames 오류가 발생하는 경우입니다. 체크를 해제하고 hostname으로 모니터링하십시오.

로그에 SQLITE_BUSY 또는 database disk image is malformed 발생. /app/data volume이 적절한 file locking을 지원하지 않는 filesystem(주로 NFS)에 있습니다. 이를 local Docker volume으로 이동하고 백업에서 복구하십시오.

FAQ

Uptime monitor를 어디에서 실행해야 합니까?

모니터링 대상 서버와 다른 서버에서 실행하십시오. 가급적 다른 제공업체나 다른 지역(region)을 권장합니다. 사용자와 동일하게 공용 인터넷을 통해 hostname으로 대상에 접속해야 합니다. 모니터링 대상과 동일한 서버에서 실행하면, 서버 장애 시 모니터링도 함께 중단됩니다. 또한 대상 호스트의 부하가 높으면 정상적인 서비스도 중단된 것으로 오판할 수 있습니다. 별도의 작은 VPS를 사용하면 이 두 문제를 모두 방지할 수 있습니다.

Telegram 또는 이메일로 알림을 받는 방법은 무엇입니까?

Settings의 Notifications 메뉴에서 채널을 추가한 후, 각 monitor에 연결하십시오. Telegram의 경우 @BotFather를 사용하여 bot을 생성하고 https://api.telegram.org/bot<token>/getUpdates에서 chat.id을 읽어오십시오. 이메일의 경우, SSL에는 465를 사용하고, 제공업체가 2단계 인증을 사용하는 경우 STARTTLS에는 앱 비밀번호와 함께 587을 사용하십시오. Test를 눌러 메시지가 정상적으로 도착하는지 확인한 후 사용하십시오.

Uptime Kuma로 cron job이나 backup script를 모니터링할 수 있습니까?

가능합니다. 그것이 Push monitor의 역할입니다. Uptime Kuma가 URL을 제공하며, 스크립트 마지막에 curl를 호출하여 성공했을 때만 신호를 보냅니다. 작업이 실패하거나 서버가 다운되면 heartbeat가 전달되지 않으며, 설정된 간격이 지나면 알림이 발생합니다. 외부 체크 방식으로는 스크립트 내부를 확인할 수 없으므로, 예약된 작업의 실제 실행 여부를 확인하는 가장 확실한 방법입니다.

Uptime Kuma와 Zabbix 중 무엇을 실행해야 합니까?

Uptime Kuma는 "외부에서 접속이 가능한가, 그리고 알림이 오는가"라는 질문에 대해 거의 자원을 소모하지 않고 10분 만에 답을 주며, status page도 제공합니다. CPU, memory, disk 트렌드와 같은 상세 지표나 전체 시스템 임계값(thresholds)을 수집하지는 않습니다. 이를 위해서는 a full Zabbix monitoring server와 같은 에이전트 기반의 더 무거운 도구가 필요하며, 많은 사용자가 두 가지를 모두 사용합니다. 무엇을 설치할지 아직 결정하지 못했습니까? our roundup of what to self-host in 2026에서 모니터링 도구의 맥락을 파악할 수 있습니다.

#uptime-kuma#monitoring #docker #self-hosting#status-page