당신은 VoyraCloud VPS에서 사전 설치된 애플리케이션 이미지를 선택하고, 개인 SSH 터널을 통해 첫 번째 관리자를 생성한 다음, 운영하는 서비스에 대한 모니터를 추가하여 Uptime Kuma를 자체 호스팅할 수 있습니다. 이 이미지는 지속적인 Uptime Kuma 시작점을 제공하며, 공용 액세스, 신뢰할 수 있는 HTTPS, 알림, 백업, 업데이트, 용량 계획 및 사고 대응은 귀하의 통제 하에 유지됩니다.
TL;DR
- VoyraCloud Uptime Kuma 애플리케이션 이미지는 Cloud VPS 및 Residential IP VPS에서 사전 설치된 모니터링 대시보드를 제공합니다.
- 포트
3001은 기본적으로127.0.0.1에 바인딩되어 있으므로, 초기화되지 않은 설정 페이지를 인터넷에 노출하는 대신 SSH 터널을 통해 첫 번째 관리자를 생성하십시오. - Uptime Kuma는 HTTP, HTTPS, TCP, 핑, DNS, WebSocket, 푸시, 키워드 및 JSON 쿼리 모니터를 포함한 다양한 모니터 유형을 지원합니다.
- 공용 대시보드 또는 상태 페이지 액세스는 귀하의 도메인, WebSocket 업그레이드를 지원하는 리버스 프록시 및 브라우저 신뢰 HTTPS를 필요로 합니다.
- 구성, 사용자, 모니터링 기록, 알림 및 상태 페이지는 로컬 지속 저장소의
/app/data에 저장됩니다. 재부팅 지속성은 백업이 아닙니다. - 20개의 모니터와 60초 간격의 작업 부하는 이미지의 초기 검증 프로필이며, 무제한 모니터 보장이나 자신의 작업 부하를 측정하는 대체물이 아닙니다.
- 같은 VPS에서 모니터링하는 것은 중요한 맹점을 가지고 있습니다: 만약 그 VPS, 그 지역 또는 그 네트워크 경로가 실패하면 Uptime Kuma가 경고를 보낼 수 없을 수 있습니다.
Uptime Kuma란 무엇인가요?
Uptime Kuma는 웹사이트, API, 네트워크 서비스 및 귀하가 제어하는 대시보드에서 접근 가능한 기타 엔드포인트를 확인하기 위한 오픈 소스, 자체 호스팅 모니터링 애플리케이션입니다. 이 애플리케이션은 체크 결과 및 응답 정보를 기록하고, 서비스 기록을 제공하며, 관리자가 구성한 통합을 통해 알림을 보낼 수 있습니다.
공식 Uptime Kuma 프로젝트는 HTTP(S), TCP, HTTP(S) 키워드, HTTP(S) JSON 쿼리, WebSocket, 핑, DNS 레코드, 푸시 및 Docker 컨테이너 모니터링과 같은 모니터 유형을 지원합니다. 또한 여러 상태 페이지, 인증서 정보, 핑 차트, 이중 인증, 프록시 지원 및 다양한 알림 통합을 제공합니다.
자체 호스팅은 다음과 같은 경우에 유용합니다:
- 자신의 서버 관리 하에 있는 모니터링 대시보드.
- 모니터 구성, 사용자, 기록 및 상태 페이지에 대한 제어.
- 여러 웹사이트, API 또는 네트워크 서비스를 확인하는 간단한 방법.
- 이미 사용하는 알림 제공자와 연결할 수 있는 옵션.
- 작은 VPS에서 지속적으로 실행할 수 있는 모니터링 도구.
이 방식으로 배포된 Uptime Kuma는 관리되는 모니터링 서비스가 아닙니다. 귀하는 VPS, 액세스 제어, 업그레이드, 백업, 알림 자격 증명 및 응답 프로세스를 소유합니다. 또한 하나의 모니터링 위치가 귀하에게 중요한 서비스에 대한 충분한 가시성을 제공하는지 결정해야 합니다.
VoyraCloud 애플리케이션 이미지로 어떻게 시작하나요?
Uptime Kuma를 자체 호스팅하는 가장 빠른 방법은 애플리케이션 이미지로 지원되는 VoyraCloud VPS를 생성하고, 로컬 SSH 터널을 통해 첫 번째 설정을 완료하는 것입니다. Uptime Kuma를 수동으로 설치할 필요는 없지만, 모니터를 구성하기 전에 관리자를 안전하게 생성해야 합니다.
- Uptime Kuma를 위한 VoyraCloud 페이지를 열고 VPS 구매 흐름을 계속 진행합니다.
- 적격한 Cloud VPS 또는 Residential IP VPS 계획을 선택한 후, 해당 제품에서 현재 제공되는 지역을 선택합니다.
- 이미지 섹션에서 Uptime Kuma가 선택되었는지 확인한 후, VPS를 생성합니다.
- VPS 리소스와 애플리케이션이 준비될 때까지 기다립니다.
- 리소스 세부정보를 열고 애플리케이션 섹션을 찾습니다.
- 표시된 SSH 터널 명령을 복사합니다. 이 패턴을 따릅니다:
ssh -p <ssh-port> -L 3001:127.0.0.1:3001 <ssh-user>@<server-ip>7. 해당 SSH 세션을 열어 두고 다음 주소로 이동합니다:
http://127.0.0.1:30018. 공식 Uptime Kuma 설정 페이지를 완료하고 고유한 관리자 사용자 이름과 강력한 비밀번호를 생성합니다.
9. 로그인하고 테스트 모니터를 하나 생성하여 대시보드에 체크가 나타나는지 확인합니다.
10. VPS를 한 번 재시작하고 Uptime Kuma가 자동으로 돌아오며 계정, 모니터 및 기록이 유지되는지 확인합니다.
브라우저 주소는 로컬이지만 애플리케이션은 VPS에서 실행됩니다. SSH는 귀하의 로컬 포트 3001을 암호화된 연결을 통해 서버의 127.0.0.1:3001으로 전달합니다. SSH 세션을 종료하면 터널이 닫히고, Uptime Kuma는 중단되지 않습니다.
귀하의 컴퓨터가 이미 로컬 포트 3001을 사용하고 있다면, 원격 목적지를 변경하지 않고 다른 로컬 포트를 선택하십시오:
ssh -p <ssh-port> -L 33001:127.0.0.1:3001 <ssh-user>@<server-ip>그런 다음 브라우저에서 http://127.0.0.1:33001를 열 수 있습니다. 원격 측은 127.0.0.1:3001로 유지하십시오.
SSH 사용자 이름과 포트는 귀하의 리소스에 표시된 것을 사용하고 root와 포트 22를 가정하지 마십시오.
애플리케이션 이미지에는 무엇이 포함되어 있나요?
애플리케이션 이미지는 사전 설치된 지속적인 Uptime Kuma 인스턴스를 포함하지만, VPS를 관리되는 모니터링 서비스로 변환하지는 않습니다. 생산 사용을 계획할 때 다음 경계가 중요합니다.
| 애플리케이션 이미지에서 제공 | 사용자 관리 또는 포함되지 않음 |
|---|---|
| 이미지에 승인된 Uptime Kuma 안정 릴리스 | 자동 애플리케이션 업그레이드 |
| Cloud VPS 또는 Residential IP VPS 운영 환경 | 관리 서버 관리 |
| 정상 VPS 재시작 후 서비스 복구 | 고가용성 또는 자동 장애 조치 |
127.0.0.1:3001에서의 로컬 전용 액세스 | 공용 포트 3001 노출 |
| 공식 첫 번째 관리자 설정 흐름 | 미리 생성된 관리자 또는 고정 비밀번호 |
지속적인 로컬 /app/data 저장소 | 자동 오프서버 백업 |
| 모니터링 대시보드, 기록, 알림 및 상태 페이지 기능 | 미리 구성된 타사 알림 계정 |
| 리소스 세부정보의 SSH 터널 지침 | 도메인 등록, 리버스 프록시 또는 신뢰할 수 있는 HTTPS |
| 사용자 제어 모니터 구성 | 보장된 탐지 정확도 또는 경고 전달 |
| 오픈 소스 라이선스 하의 Uptime Kuma | 전달 후 Uptime Kuma의 VoyraCloud 유지 관리 |
이 이미지는 고정된 관리자 자격 증명, 인증 모드, 알림 비밀, 도메인, 인증서 또는 공용 관리 엔드포인트를 포함하지 않습니다. 이는 첫 번째 액세스를 비공식적으로 유지하고 초기화되지 않은 계정 생성 페이지를 인터넷에 직접 노출하는 것을 피합니다.
어떤 모니터 유형을 사용해야 하나요?
각 Uptime Kuma 모니터 유형은 테스트해야 하는 레이어에 따라 선택하십시오. 성공적인 핑이 웹사이트, API 또는 애플리케이션이 올바르게 작동함을 증명하지는 않습니다. 유용한 모니터링 세트는 사용자-facing 레이어와 선택된 종속성을 확인하며, 하나의 일반적인 하트비트에 의존하지 않습니다.
| 모니터 유형 | 검증할 수 있는 것 | 중요한 제한 사항 |
|---|---|---|
| HTTP 또는 HTTPS | URL이 응답하고 예상 상태를 반환함 | 성공적인 응답이 여전히 잘못된 내용을 포함할 수 있음 |
| 키워드 | 응답에 예상 텍스트가 포함되거나 제외됨 | 텍스트 검사는 모든 비즈니스 기능을 검증하지 않음 |
| JSON 쿼리 | API 응답이 예상 값을 포함함 | 쿼리는 실제 응답 구조와 일치해야 함 |
| TCP 포트 | 네트워크 서비스가 연결을 수락함 | 열린 포트가 애플리케이션이 건강하다는 것을 증명하지 않음 |
| 핑 | 호스트가 ICMP에 응답함 | ICMP가 필터링될 수 있으며, 응답이 애플리케이션이 작동함을 증명하지 않음 |
| DNS 레코드 | 해결자가 예상 레코드를 반환함 | 하나의 해결자 뷰가 전 세계 전파를 나타내지 않을 수 있음 |
| WebSocket | WebSocket 엔드포인트에 도달할 수 있음 | 모든 메시지 흐름을 검증하지 않음 |
| 푸시 | 작업 또는 원격 프로세스가 자신의 하트비트를 보고함 | 누락된 푸시는 해당 작업을 위한 경고 창이 필요함 |
| 인증서 정보 | 인증서 상태 및 만료 정보 | 갱신은 여전히 귀하의 인증서 프로세스에 의존함 |
공용 웹사이트의 경우, 실용적인 세트는 HTTPS 체크, 의미 있는 콘텐츠에 대한 키워드 또는 JSON 체크, 인증서 만료 체크를 포함할 수 있습니다. VPS에서 접근할 수 있는 내부 서비스의 경우, TCP 또는 HTTP 체크가 인프라 가시성을 추가할 수 있습니다. 예약된 작업의 경우, 푸시 모니터가 예상 하트비트가 도착하지 않을 때를 감지할 수 있습니다.
모두 같은 이유로 실패하는 여러 모니터를 생성하고 이를 독립적인 증거로 취급하는 것을 피하십시오. 모니터 설계는 실제 실패 모드를 반영해야 합니다: DNS, TLS, 네트워크 도달성, 애플리케이션 응답, 콘텐츠 정확성 및 백그라운드 작업 완료.
20 모니터 검증 프로필은 무엇을 의미하나요?
20 모니터 프로필은 초기 이미지 구성에 대한 보수적인 수용 작업 부하이며, 최대 용량 약속이 아닙니다. 계획된 검증은 24시간 동안 60초 간격으로 20개의 모니터를 사용한 후 VPS 재시작 및 지속성 확인을 포함합니다.
이 검증은 좁은 질문에 답하기 위한 것입니다: 자격이 있는 초기 구성으로 소규모 Uptime Kuma 설치를 메모리 부족 이벤트, 데이터베이스 잠금, 예기치 않은 컨테이너 재시작 또는 정의된 작업 부하 하에서 데이터 손실 없이 실행할 수 있습니까? 이는 동일한 계획이 다음을 지원할 수 있음을 증명하지 않습니다:
- 무제한 모니터.
- 매우 짧은 체크 간격.
- 큰 응답 본문 또는 비싼 JSON 쿼리.
- 많은 동시 사용자 또는 공용 상태 페이지 방문자.
- 저장소 증가 없이 긴 보존 기간.
- 많은 알림 볼륨.
- 호스트 소켓에 접근하는 Docker 모니터링.
- 같은 VPS를 공유하는 추가 애플리케이션.
실제 리소스 사용은 모니터 유형, 간격, 시간 초과, 응답 크기, 기록 보존, 알림 동작, 대시보드 활동 및 서버의 다른 소프트웨어에 따라 달라집니다. 측정된 세트로 시작하고 CPU, 메모리, 디스크 사용, 데이터베이스 동작 및 체크 지속 시간을 관찰한 다음, 실제 작업 부하가 필요할 때 더 큰 자격이 있는 VoyraCloud VPS 구성으로 이동하십시오.
구매 흐름 최소값을 보편적인 크기 권장 사항으로 해석하지 마십시오. 이는 검증된 시작 프로필에 대한 자격 게이트입니다.
Uptime Kuma를 안전하게 게시하려면 어떻게 해야 하나요?
Uptime Kuma를 전용 도메인 또는 서브도메인, WebSocket 지원 리버스 프록시 및 브라우저 신뢰 HTTPS를 통해 게시하되, 포트 3001은 로컬호스트에 바인딩된 상태로 유지하십시오. 장기 SSH 터널 액세스는 관리자가 대시보드에만 필요하고 공용 상태 페이지가 필요하지 않을 때도 유효합니다.
공식 Uptime Kuma 리버스 프록시 가이드는 애플리케이션이 WebSocket을 사용하고 프록시가 Upgrade 및 Connection 헤더를 전달해야 한다고 설명합니다. 또한 Uptime Kuma는 /uptime-kuma와 같은 일반 URL 서브디렉토리 아래에서 호스팅되는 것을 지원하지 않으며, status.example.com과 같은 전용 호스트 이름을 사용해야 합니다.
일반적인 Nginx 위치 블록은 다음을 포함합니다:
location / {
proxy_pass http://127.0.0.1:3001;
proxy_http_version 1.1;
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 Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}이 스니펫은 프록시 경로만 다룹니다. 호스트 이름, 신뢰할 수 있는 TLS 인증서, 인증서 갱신, HTTP-HTTPS 리디렉션, 방화벽 및 액세스 정책을 별도로 구성해야 합니다. 적용하기 전에 선택한 리버스 프록시의 현재 공식 예제를 확인하십시오.
다음과 같은 프로덕션 체크리스트를 사용하십시오:
- 전용 호스트 이름에 대한 DNS 레코드를 생성합니다.
3001/tcp가 공용 인터넷에서 사용할 수 없도록 유지합니다.- 리버스 프록시를
127.0.0.1:3001에 도달하도록 구성합니다. - WebSocket 업그레이드 헤더를 보존합니다.
- 일반 브라우저에서 신뢰할 수 있는 인증서를 설치합니다.
- 일반 HTTP를 HTTPS로 리디렉션합니다.
- 대시보드가 WebSocket 오류 없이 업데이트되는지 확인합니다.
- 로그인, 로그아웃, 모니터 업데이트 및 상태 페이지를 테스트합니다.
- 공용 액세스가 필요 없는 경우 관리 호스트 이름을 제한합니다.
- 프록시 및 방화벽 경로가 올바른 경우에만 신뢰할 수 있는 프록시 설정을 검토합니다.
신뢰할 수 있는 HTTPS는 자격 증명과 세션 트래픽을 전송 중에 보호하지만, 약한 관리자 비밀번호나 구식 서버를 보호하지는 않습니다. SSH를 강화하고, 권한을 제한하며, 적절한 경우 이중 인증을 활성화하고, 운영 체제와 리버스 프록시를 유지 관리하십시오.
알림 및 상태 페이지는 어떻게 작동하나요?
알림 및 상태 페이지는 초기화 후 구성하는 기능입니다. 이미지는 타사 계정, 자격 증명, 전달 보장 또는 공용 도메인을 포함하지 않습니다. Uptime Kuma는 많은 알림 방법을 지원하지만, 각 제공자는 고유한 계정, 가용성, 가격, 한계 및 전달 동작을 가지고 있습니다.
공식 알림 방법 문서는 제공자별 설정 참조를 제공합니다. 팀이 소유한 통합만 추가하고, 자격 증명을 신중하게 저장하며, 의존하기 전에 테스트 알림을 보내십시오. 성공적인 테스트는 그 순간 하나의 메시지가 작동했음을 증명하지만, 미래의 전달을 보장하지는 않습니다.
각 중요한 모니터에 대해:
- 누가 경고를 받을지 결정합니다.
- 서비스에 적합한 체크 간격 및 재시도 정책을 설정합니다.
- 하나 이상의 사용자 소유 알림 방법을 구성합니다.
- 실패 및 복구 알림을 테스트합니다.
- 온콜 담당자가 메시지에 따라 행동할 수 있는지 확인합니다.
- 모니터가 실패를 보고할 때 수행할 작업을 문서화합니다.
상태 페이지는 선택한 모니터 상태 및 사고 정보를 공유할 수 있게 해줍니다. 모든 내부 모니터를 노출할 필요는 없습니다. 고객이 이해할 수 있는 방식으로 서비스를 그룹화하고, 민감한 호스트 이름이나 내부 토폴로지를 게시하지 않으며, 공용 액세스를 위해 자신의 도메인과 안전한 프록시 경로를 사용하십시오.
모든 알림 통합이 무료라고 가정하지 마십시오. 일부 서비스는 요금을 부과하거나 사용을 제한하거나 API를 변경하거나 추가 구성을 요구할 수 있습니다. VoyraCloud는 이러한 타사 계정을 제공하지 않으며, 제공자가 메시지를 수락하거나 전달할 것이라고 보장할 수 없습니다.
Uptime Kuma 데이터는 어떻게 저장되고 백업되나요?
Uptime Kuma는 애플리케이션 상태를 /app/data 아래에 유지하며, 이는 지속적인 로컬 저장소에 있어야 하고 실행 중인 VPS와 별도로 백업되어야 합니다. 공식 설치 지침은 POSIX 파일 잠금을 위한 파일 시스템 지원을 요구하며, NFS와 일반적으로 관련된 파일 잠금 문제에 대해 경고합니다.
지속적인 데이터에는 다음과 같은 항목에 필요한 데이터베이스 및 애플리케이션 상태가 포함됩니다:
- 관리자 및 사용자 설정.
- 모니터 정의.
- 모니터링 기록.
- 알림 구성.
- 상태 페이지.
- 유지 관리 일정.
- 기타 인스턴스 설정.
정상 VPS 재부팅은 해당 데이터를 보존하고 애플리케이션을 재시작해야 합니다. 이 동작은 지속성이며, 재해 복구가 아닙니다. 우발적인 삭제, 데이터베이스 손상, 자격 증명 유출, 업그레이드 실패, 저장소 손실 또는 VPS 삭제는 유일한 복사본을 제거할 수 있습니다.
더 안전한 백업 루틴은 다음과 같습니다:
/app/data에 매핑된 실제 로컬 Docker 볼륨 또는 로컬 디렉터리를 식별합니다.- VPS 외부의 목적지에 백업을 예약합니다.
- 선택한 백업 방법이 일관된 데이터베이스 복사를 요구할 때 Uptime Kuma를 정지하거나 일시 중지합니다.
- 전체 데이터 세트를 복사하며, 내보낸 모니터 목록만 복사하지 않습니다.
- 운영 세부정보 및 알림 자격 증명을 포함할 수 있으므로 백업을 암호화하고 보호합니다.
- 하나 이상의 복구 지점을 유지합니다.
- 별도의 테스트 인스턴스에 복원하고 계정, 모니터, 기록, 알림 및 상태 페이지를 확인합니다.
- 백업과 관련된 애플리케이션 버전을 기록합니다.
이 이미지를 위해 라이브 /app/data 디렉터리를 NFS에 두지 마십시오. 원격 백업 목적지는 복사된 백업 아티팩트에 적합하며, 활성 데이터베이스를 네트워크 파일 시스템에서 직접 실행하는 것과는 다릅니다.
같은 서버 모니터링 맹점은 무엇인가요?
Uptime Kuma 인스턴스는 자신의 컴퓨팅, 네트워크 또는 알림 경로를 제거하는 실패를 신뢰성 있게 보고할 수 없습니다. Uptime Kuma가 모니터링하는 웹사이트와 동일한 VPS에서 실행되는 경우, VPS 장애가 경고가 전송되기 전에 웹사이트와 모니터를 모두 중단시킬 수 있습니다.
모니터링되는 서비스가 다른 서버에 있더라도, 하나의 Uptime Kuma 위치는 여전히 하나의 네트워크와 하나의 지역에서 이를 관찰합니다. 로컬 ISP 경로, 지역 네트워크 문제, DNS 해결자 차이 또는 방화벽 정책은 모든 사용자의 경험을 나타내지 않고 그 뷰에 영향을 줄 수 있습니다.
결과에 따라 배포를 사용하십시오:
| 모니터링 필요 | 적절한 접근 방식 |
|---|---|
| 소규모 서비스에 대한 편리한 대시보드 | 하나의 자체 호스팅 Uptime Kuma 인스턴스가 충분할 수 있습니다 |
| 다른 VPS에서 서비스 모니터링 | 실용적일 경우 모니터링 서버의 장애 도메인 외부에 Uptime Kuma를 배치합니다 |
| 지역 도달성 차이 감지 | 여러 위치에서 독립적인 체크를 사용합니다 |
| 모니터링 VPS의 장애 동안 경고 | 외부 하트비트 또는 독립적인 모니터링 서비스를 추가합니다 |
| 고가용성 모니터링 | 별도의 다중 시스템 모니터링 아키텍처를 설계합니다 |
애플리케이션 이미지는 분산 모니터링, 고가용성 또는 독립 외부 검사를 제공하지 않습니다. 이를 하나의 모니터링 지점으로 간주하고, 놓친 경고가 비즈니스에 중대한 영향을 미칠 경우 독립적인 커버리지를 추가하십시오.
Uptime Kuma를 어떻게 업데이트해야 하나요?
Uptime Kuma를 신중하게 업데이트하려면 공식 릴리스 지침을 확인하고, /app/data를 백업하며, 의존하기 전에 새 버전을 검증하십시오. VoyraCloud는 VPS가 생성된 후 고객 인스턴스를 자동으로 업그레이드하지 않습니다.
설치된 주요 버전 및 배포 방법에 적용되는 공식 Uptime Kuma 업데이트 지침를 따르십시오. 업데이트 전에:
- 릴리스 노트 및 마이그레이션 요구 사항을 읽습니다.
- 현재 실행 중인 애플리케이션 버전을 기록합니다.
/app/data의 오프서버 백업을 생성하고 검증합니다.- 충분한 여유 디스크 공간을 확인합니다.
- 중요한 모니터링 인스턴스를 위한 유지 관리 창을 계획합니다.
- 검토되지 않은 플로팅 태그 대신 특정 승인된 버전을 사용합니다.
- 업데이트된 인스턴스를 시작하고 로그를 검토합니다.
- 관리자 로그인, 여러 모니터 유형, 알림, 상태 페이지 및 재시작 복구를 테스트합니다.
- 릴리스에서 설명된 데이터베이스 변경 사항과 호환되는 롤백 계획을 유지합니다.
컨테이너 이미지를 되돌리는 것만으로는 항상 충분하지 않다고 가정하지 마십시오. 주요 버전 마이그레이션은 애플리케이션 데이터를 변경할 수 있으므로, 복구에는 사전 업데이트 데이터 백업과 이전 이미지 버전이 필요할 수 있습니다.
운영 체제 업데이트, Docker 업데이트, 리버스 프록시 업데이트 및 인증서 갱신은 별도의 책임입니다. 현재 Uptime Kuma 컨테이너가 서버의 나머지를 최신 상태로 유지하지 않습니다.
피해야 할 일반적인 실수
대부분의 Uptime Kuma 배포 실수는 초기화를 노출하거나, 하나의 모니터링 위치를 과대평가하거나, 지속 저장소를 완전한 운영 계획으로 간주하는 것에서 발생합니다. 이러한 오류를 피하십시오:
- 관리자를 생성하기 전에 포트
3001을 게시하는 것. 로컬호스트에 두고 SSH 터널을 사용하십시오. - 대시보드를 공용 HTTP로 두는 것. 모든 공용 액세스에 대해 신뢰할 수 있는 HTTPS를 사용하십시오.
- WebSocket 프록시 헤더를 잊는 것. 인터페이스는 로드될 수 있지만 올바르게 업데이트되지 않을 수 있습니다.
- 서브디렉토리 아래에서 호스팅하는 것. 전용 도메인 또는 서브도메인을 사용하십시오.
- 활성
/app/data를 NFS에서 실행하는 것. 호환 가능한 로컬 저장소에 두십시오. - 재부팅 지속성을 백업이라고 부르는 것. 테스트된 복사본을 VPS 외부에 저장하십시오.
- 상태 페이지가 독립적인 모니터링을 생성한다고 가정하는 것. 이는 동일한 Uptime Kuma 인스턴스에 의해 제공됩니다.
- VPS를 자신만으로 모니터링하는 것. 전체 서버 장애는 서비스와 모니터를 모두 침묵시킬 수 있습니다.
- 20개의 모니터를 보장된 최대값 또는 최소값으로 취급하는 것. 이는 정의된 검증 작업 부하일 뿐, 보편적인 용량 결과가 아닙니다.
- 알림 전달이 보장된다고 기대하는 것. 제공자의 가용성, 자격 증명, 할당량, 라우팅 및 모니터링 호스트 모두 중요합니다.
- 소유자가 없는 모든 통합을 활성화하는 것. 누군가가 테스트하고 응답하는 채널만 구성하십시오.
- 복원 가능한 데이터 복사본 없이 업데이트하는 것. 버전을 변경하기 전에 전체 애플리케이션 데이터를 백업하십시오.
자주 묻는 질문
Uptime Kuma를 수동으로 설치하지 않고 자체 호스팅할 수 있나요?
예. VoyraCloud 애플리케이션 이미지는 적격한 Cloud VPS 또는 Residential IP VPS에서 사전 설치된 Uptime Kuma 인스턴스를 제공합니다. 여전히 첫 번째 관리자를 생성하고, 모니터를 추가하고, 알림을 구성하며, 보안, 업데이트, 백업 및 공용 액세스를 관리해야 합니다.
서버 IP 대신 http://127.0.0.1:3001이 표시되는 이유는 무엇인가요?
로컬 주소는 초기화되지 않은 관리자 설정 페이지가 인터넷에 직접 노출되는 것을 방지합니다. 컴퓨터에서 SSH 터널을 설정하고 세션을 열어 두고, 로컬 URL로 이동하십시오. 터널은 귀하의 브라우저 연결을 VPS의 Uptime Kuma로 안전하게 전달합니다.
포트 3001을 인터넷에 직접 노출할 수 있나요?
직접 노출은 권장되는 프로덕션 경로가 아닙니다. 서비스를 로컬호스트에 바인딩하고, 전용 호스트 이름, WebSocket 지원, 신뢰할 수 있는 HTTPS 및 적절한 액세스 정책을 갖춘 리버스 프록시를 사용하십시오. 애플리케이션 이미지는 자동으로 해당 공용 경로를 구성하지 않습니다.
Uptime Kuma에 무료 SMS, 이메일, Slack 또는 기타 알림 서비스가 포함되어 있나요?
아니요. Uptime Kuma는 많은 알림 제공자와 통합할 수 있지만, 제공자 계정 및 자격 증명을 공급하고 관리해야 합니다. 타사 가격, 할당량, 가용성 및 메시지 전달은 애플리케이션 이미지 외부에 있으며 변경될 수 있습니다.
1GB VPS가 Uptime Kuma에 충분한가요?
정의된 이미지 검증이 통과한 후에만 적격한 시작점일 수 있지만, 실제 용량은 귀하의 작업 부하에 따라 달라집니다. 초기 프로필은 24시간 동안 60초 간격으로 20개의 모니터를 사용합니다. 더 많은 모니터, 더 짧은 간격, 더 큰 응답, 더 긴 기록, 추가 서비스 또는 더 많은 대시보드 사용이 더 많은 메모리, CPU 및 저장소를 요구할 수 있습니다.
Uptime Kuma는 고가용성 또는 외부 모니터링을 제공하나요?
아니요. 이 이미지는 하나의 VPS에서 하나의 자체 호스팅 Uptime Kuma 인스턴스를 제공합니다. 고가용성, 분산 체크 및 독립 외부 모니터링은 추가 시스템 및 아키텍처가 필요하며 포함되지 않습니다.
Uptime Kuma가 자신의 VPS가 실패하면 경고하나요?
그럴 수 없습니다. 경고를 전송하는 프로세스가 VPS 또는 그 네트워크 경로와 함께 실패할 수 있습니다. Uptime Kuma 호스트의 실패를 감지하는 것이 중요할 경우 외부 하트비트 또는 독립적인 모니터링 위치를 사용하십시오.
무엇을 백업해야 하나요?
지속적인 데이터 전체를 /app/data에 매핑하고 복구 복사본을 VPS 외부에 저장하십시오. 백업을 보호하십시오. 이는 모니터링 구성 및 알림 비밀을 포함할 수 있으며, 복사된 파일 세트가 사용 가능하다고 가정하기보다는 복원을 테스트하십시오.
VoyraCloud는 Uptime Kuma를 자동으로 업데이트하나요?
아니요. 새로운 VPS 리소스는 생성 시 이미지에 승인된 애플리케이션 버전을 받으며, 이후 업데이트는 고객이 관리합니다. 공식 업그레이드 지침을 검토하고, /app/data를 백업하고, 의존하기 전에 업데이트된 인스턴스를 테스트하십시오.
결론
Uptime Kuma를 자체 호스팅하여 간단한 모니터링 대시보드, 구성 가능한 체크, 알림 및 상태 페이지를 자신의 관리 하에 원할 때 시작하십시오. SSH 터널을 통해 비공식적으로 시작하고, 실제 실패 모드를 중심으로 모니터를 설계하며, /app/data를 지속적인 로컬 저장소에 두고, VPS 외부에 백업하고, 공용 액세스가 필요할 때만 신뢰할 수 있는 HTTPS와 함께 WebSocket 지원 리버스 프록시를 추가하십시오.
하나의 인스턴스는 많은 소규모 모니터링 요구에 유용하지만, 여전히 하나의 관찰 지점과 하나의 실패 도메인으로 남아 있습니다. Uptime Kuma 호스트 자체, 지역 도달성 또는 경고 연속성이 반드시 커버되어야 할 경우 독립적인 모니터링을 추가하십시오.
VoyraCloud의 Uptime Kuma 애플리케이션 이미지를 사용하여 사전 설치된 VoyraCloud VPS 환경에서 시작하면서 액세스, 데이터, 알림 및 운영을 귀하의 통제 하에 유지하십시오.