Uptime Kuma로 홈서버 모니터링하기 : 내 서비스가 살아 있는지 한눈에 확인하는 방법
도입
지난 글에서는 홈서버 모니터링을 시작하기 전에 무엇을 관찰해야 하는지 살펴보았습니다.
CPU와 메모리 사용량, 디스크 공간, Docker 컨테이너 상태, 실제 서비스의 응답 상태처럼 홈서버를 운영하면서 확인해야 할 항목은 생각보다 다양합니다.
그런데 서비스가 하나둘 늘어나기 시작하면 새로운 문제가 생깁니다.
WordPress가 정상적으로 열리는지 확인합니다.
n8n에 접속해 봅니다.
다른 Docker 서비스가 있다면 그것도 하나씩 확인합니다.
서비스가 한두 개라면 어렵지 않습니다. 브라우저를 열고 직접 접속해 보면 됩니다.
하지만 홈서버를 계속 운영하면서 서비스가 늘어나면 매번 하나씩 접속해서 상태를 확인하는 일도 반복 작업이 됩니다.
저 역시 여기에서 궁금증이 생겼습니다.
내가 매번 하나씩 접속하지 않아도 여러 서비스의 상태를 한곳에서 확인할 수 없을까?
이번에 사용해 볼 도구가 Uptime Kuma입니다.
Uptime Kuma를 이용하면 등록한 서비스에 주기적으로 접근해 정상적으로 응답하는지 확인하고, 그 결과를 하나의 화면에서 관찰할 수 있습니다.
이번 글에서는 Docker를 이용해 Uptime Kuma를 설치하고, WordPress와 n8n을 모니터링 대상으로 등록해 보겠습니다.
그리고 단순히 초록색 상태 화면을 확인하는 데서 끝내지 않고, 테스트 환경에서 서비스가 중단되었을 때 상태가 어떻게 바뀌고 다시 복구되는지도 살펴보겠습니다.
※ 다이어그램은 실제 홈서버 모니터링 구성 과정을 바탕으로 AI 도구를 활용해 제작했으며, 최종 구성과 내용은 운영자가 직접 검수했습니다.
출처: 디지털 장난감
본문
① Uptime Kuma는 무엇을 하는 도구일까?
Uptime Kuma라는 이름을 처음 들었을 때는 조금 어려운 서버 관리 도구라고 생각했습니다.
하지만 이번 실습에서 필요한 기능만 놓고 보면 개념은 비교적 단순합니다.
등록해 둔 서비스에 일정한 간격으로 접근해 정상적으로 응답하는지 확인하고, 그 결과를 화면에 보여주는 셀프 호스팅 모니터링 도구입니다.
예를 들어 WordPress 주소를 등록했다고 가정해 보겠습니다.
Uptime Kuma는 설정한 주기에 따라 해당 주소에 접근합니다.
정상적인 응답을 받으면 Up 상태로 기록합니다.
정상적인 응답을 받지 못하면 Down 상태로 기록할 수 있습니다.
이 과정이 반복되면서 현재 상태뿐 아니라 일정 기간의 상태 변화와 응답 시간도 확인할 수 있습니다.
등록한 서비스 확인
↓
응답 결과 기록
↓
Up 또는 Down 상태 표시
↓
시간에 따른 상태 변화 관찰
사람이 매번 브라우저를 열어 하나씩 접속해 보는 일을 일정 부분 대신해 주는 것입니다.
물론 이것이 홈서버의 모든 문제를 분석해 주는 것은 아닙니다.
CPU가 왜 높아졌는지 원인을 찾아주거나, WordPress 내부의 모든 기능을 검사해 주는 것도 아닙니다.
이번 글에서는 Uptime Kuma의 역할을 서비스가 응답하고 있는지 확인하는 첫 번째 관찰 창구 정도로 이해하고 시작하겠습니다.
② 오늘 만들 구조부터 살펴보자
이번에 만들 구조는 복잡하지 않습니다.
Intel N100 홈서버
↓
Docker
↓
Uptime Kuma 컨테이너 실행
↓
WordPress 상태 확인
+
n8n 상태 확인
↓
대시보드에서 상태 변화 관찰
이미 홈서버에서 Docker를 사용하고 있다면 Uptime Kuma 역시 하나의 컨테이너로 추가할 수 있습니다.
이 구조의 장점은 확인할 장소가 하나 생긴다는 것입니다.
기존에는 WordPress를 확인하기 위해 WordPress에 접속하고, n8n을 확인하기 위해 n8n에 접속했습니다.
Uptime Kuma를 구성한 뒤에는 우선 대시보드에서 등록한 서비스의 상태를 확인할 수 있습니다.
문제가 발견되면 그때 해당 서비스의 로그와 컨테이너 상태를 더 자세히 살펴보는 방식으로 접근할 수 있습니다.
③ 같은 홈서버 안에 모니터링 도구를 설치해도 될까?
설치하기 전에 한 가지 생각해 볼 부분이 있습니다.
이번 실습에서는 Uptime Kuma를 WordPress와 n8n이 실행되고 있는 같은 홈서버에 설치합니다.
그렇다면 이런 질문이 생길 수 있습니다.
홈서버 자체가 완전히 꺼지면 Uptime Kuma도 같이 꺼지는 것 아닌가?
맞습니다.
같은 홈서버에서 실행되는 Uptime Kuma는 홈서버 전체가 꺼지거나 네트워크 연결이 완전히 끊어지면 함께 접근할 수 없게 됩니다.
따라서 이번 구성은 외부의 독립된 위치에서 홈서버 전체의 생존 여부를 감시하는 완전한 외부 모니터링 구조와는 다릅니다.
이번 실습의 목적은 우선 다음과 같습니다.
- 여러 서비스의 응답 상태를 한곳에서 확인하기
- 개별 서비스의 상태 변화를 관찰하기
- 장애와 복구 기록 확인하기
- 모니터링의 기본 구조 이해하기
처음부터 완벽한 모니터링 환경을 만들기보다, 현재의 홈서버 안에서 서비스 상태를 관찰하는 것부터 시작해 보겠습니다.
④ Uptime Kuma 작업 디렉터리 만들기
먼저 Uptime Kuma의 설정 파일과 데이터를 관리할 작업 공간을 준비합니다.
터미널에서 다음 명령어를 실행합니다.
mkdir -p ~/uptime-kuma
cd ~/uptime-kuma첫 번째 명령어는 홈 디렉터리 아래에 uptime-kuma 디렉터리를 만듭니다.
두 번째 명령어는 방금 만든 디렉터리로 이동합니다.
이제 이 위치에 Docker Compose 설정 파일을 작성하겠습니다.
⑤ compose.yaml 파일 만들기
텍스트 편집기를 이용해 compose.yaml 파일을 만듭니다.
nano compose.yaml다음과 같이 작성합니다.
services:
uptime-kuma:
image: louislam/uptime-kuma:1
container_name: uptime-kuma
volumes:
- ./uptime-kuma-data:/app/data
ports:
- "3001:3001"
restart: unless-stopped처음 보면 짧은 설정이지만 몇 가지 중요한 내용이 들어 있습니다.
⑥ Compose 설정은 무엇을 의미할까?
image
image: louislam/uptime-kuma:1Uptime Kuma 컨테이너를 만들 때 사용할 이미지와 태그를 지정합니다.
container_name
container_name: uptime-kuma컨테이너 이름을 uptime-kuma로 지정합니다.
나중에 컨테이너 상태를 확인하거나 로그를 볼 때 이름을 쉽게 찾을 수 있습니다.
volumes
volumes:
- ./uptime-kuma-data:/app/dataUptime Kuma의 데이터를 호스트의 디렉터리에 연결합니다.
모니터 설정과 사용자 설정 등의 데이터를 컨테이너 외부에 유지하기 위한 부분입니다.
컨테이너는 삭제하고 다시 만들 수 있습니다.
하지만 데이터까지 함께 사라지면 등록했던 모니터링 설정을 다시 구성해야 할 수 있습니다.
Docker 서비스를 운영할 때는 컨테이너와 데이터의 수명을 구분해서 생각하는 것이 중요합니다.
ports
ports:
- "3001:3001"홈서버의 3001번 포트와 Uptime Kuma 컨테이너의 3001번 포트를 연결합니다.
설치 후 브라우저에서 홈서버의 IP 주소와 3001번 포트를 이용해 접속할 수 있습니다.
restart
restart: unless-stopped컨테이너가 예기치 않게 종료되거나 Docker 서비스가 다시 시작될 때 자동 재시작을 시도하도록 설정합니다.
다만 관리자가 명시적으로 컨테이너를 중지한 경우에는 자동으로 다시 시작하지 않는 방식입니다.
⑦ Uptime Kuma 컨테이너 실행하기
설정 파일을 저장했다면 컨테이너를 실행합니다.
docker compose up -d-d 옵션은 컨테이너를 백그라운드에서 실행하도록 합니다.
실행 후 상태를 확인합니다.
docker compose ps또는 전체 Docker 컨테이너 목록에서 확인할 수 있습니다.
docker psuptime-kuma 컨테이너가 실행 중인지 확인합니다.
만약 정상적으로 실행되지 않는다면 로그를 확인합니다.
docker compose logs --tail=100실시간으로 로그 변화를 보고 싶다면 다음과 같이 확인할 수 있습니다.
docker compose logs -f로그 확인을 종료할 때는 Ctrl + C를 누릅니다.
⑧ 브라우저에서 첫 접속하기
컨테이너가 정상적으로 실행되었다면 브라우저에서 접속합니다.
형식은 다음과 같습니다.
http://홈서버IP:3001예를 들어 홈서버의 내부 IP 주소가 192.168.0.100이라면 다음과 같은 형태가 됩니다.
http://192.168.0.100:3001첫 접속에서는 Uptime Kuma에서 사용할 관리자 계정을 만듭니다.
여기서 한 가지 구분할 점이 있습니다.
Uptime Kuma의 관리자 계정은 Ubuntu나 Debian의 Linux 사용자 계정과 별개입니다.
홈서버에 SSH로 접속할 때 사용하는 계정과 Uptime Kuma 웹 화면에 로그인하는 계정은 서로 다른 역할을 합니다.
관리자 계정을 만든 뒤 로그인하면 대시보드 화면을 확인할 수 있습니다.
처음에는 등록된 모니터가 없기 때문에 비어 있는 화면이 보일 수 있습니다.
이제 실제 서비스를 하나씩 추가해 보겠습니다.
⑨ 첫 번째 모니터 등록 : WordPress
첫 번째 대상으로 WordPress를 등록해 보겠습니다.
Uptime Kuma에서 새 모니터 추가 메뉴를 선택합니다.
모니터 유형은 일반적인 웹서비스의 경우 HTTP(s)를 선택할 수 있습니다.
이름에는 구분하기 쉬운 이름을 입력합니다.
WordPressURL에는 실제로 확인할 WordPress 주소를 입력합니다.
내부 네트워크 주소를 확인할 것인지, 외부에서 사용하는 도메인을 확인할 것인지는 모니터링 목적과 네트워크 구성에 따라 달라질 수 있습니다.
이번 실습에서는 Uptime Kuma 컨테이너가 실제로 접근할 수 있는 주소를 사용해야 합니다.
모니터링 간격도 확인합니다.
간격이 너무 짧으면 불필요하게 요청 횟수가 늘어날 수 있고, 너무 길면 장애 발견이 늦어질 수 있습니다.
처음에는 기본 설정을 사용하면서 동작 방식을 이해한 뒤 자신의 환경에 맞게 조정하는 편이 좋습니다.
설정을 저장하면 Uptime Kuma가 대상 주소를 확인하기 시작합니다.
정상적으로 응답하면 Up 상태로 표시됩니다.
⑩ Uptime Kuma는 무엇을 확인하고 있을까?
화면에 초록색 Up 표시가 나타나면 단순히 정상이라고 생각하고 넘어가기 쉽습니다.
하지만 여기에서 실제로 어떤 일이 일어나는지 이해해 두는 것이 좋습니다.
Uptime Kuma는 설정된 간격에 따라 등록한 주소로 요청을 보냅니다.
그리고 설정한 검사 방식과 조건에 따라 응답 결과를 기록합니다.
설정된 확인 시간 도착
↓
대상 주소에 요청
↓
응답 확인
↓
상태 기록
↓
다음 확인 시간까지 대기
↓
다시 확인
이 과정이 반복됩니다.
그래서 현재 상태뿐 아니라 시간이 지나면서 Up과 Down 상태가 어떻게 변했는지도 관찰할 수 있습니다.
월요일 글에서 이야기했던 한 번의 상태 확인과 시간에 따른 변화 관찰의 차이가 실제 도구 안에서 구현되는 것입니다.
⑪ 두 번째 모니터 등록 : n8n
WordPress 등록이 끝났다면 같은 방식으로 n8n도 추가해 보겠습니다.
새 모니터를 추가하고, n8n을 확인할 수 있는 주소를 입력합니다.
여기에서도 중요한 것은 Uptime Kuma에서 실제로 접근 가능한 주소를 사용해야 한다는 점입니다.
WordPress 등록 과정과 기본 구조는 비슷합니다.
첫 번째 모니터를 등록할 때는 각 항목의 의미를 배우는 과정이었다면, 두 번째 등록부터는 같은 구조를 반복하면서 익힐 수 있습니다.
서비스가 더 늘어난다면 같은 방식으로 하나씩 추가할 수 있습니다.
예를 들어 앞으로 홈서버에 다른 웹서비스가 추가된다면 모니터링 목적에 맞는 방식으로 등록하여 하나의 화면에서 상태를 관찰할 수 있습니다.
이제 대시보드에는 WordPress와 n8n의 상태가 각각 표시됩니다.
확인할 장소가 하나로 모이기 시작했습니다.
⑫ 일부러 장애 상황을 만들어 보면 무엇을 알 수 있을까?
모니터링 도구를 설치한 뒤 정상 상태만 보고 있으면 실제로 어떤 방식으로 동작하는지 이해하기 어려울 수 있습니다.
그래서 중요한 운영 서비스를 중단하지 않는 범위에서 테스트용 서비스나 실습 환경을 이용해 상태 변화를 확인해 보는 것도 도움이 됩니다.
예를 들어 테스트용 컨테이너를 Uptime Kuma에 등록했다고 가정해 보겠습니다.
서비스 정상 실행
↓
Uptime Kuma에서 Up 확인
↓
테스트 서비스 중지
↓
다음 확인 주기에 응답 실패
↓
Down 상태 기록
↓
테스트 서비스 재시작
↓
Up 상태 복귀
이 과정을 직접 보면 Uptime Kuma가 단순히 현재의 초록색 화면만 보여주는 것이 아니라 상태 변화를 기록하고 있다는 것을 이해하기 쉽습니다.
중요한 운영 서비스의 장애 테스트는 무리하게 진행하지 않고, 영향 범위를 알고 있는 테스트 환경에서 진행하는 것이 좋습니다.
⑬ 초록색 Up이라고 모든 것이 정상일까?
여기서 반드시 구분해야 할 부분이 있습니다.
Uptime Kuma에서 WordPress가 Up으로 표시되었다고 가정해 보겠습니다.
이것은 설정한 모니터링 조건에서 WordPress 주소가 정상적으로 응답했다는 의미로 이해해야 합니다.
하지만 다음과 같은 문제까지 모두 없다는 뜻은 아닙니다.
- 특정 플러그인 기능의 오류
- 관리자 화면의 일부 기능 문제
- 데이터베이스 내부의 특정 쿼리 문제
- 예약 작업 실패
- 로그인 이후 특정 기능의 오류
n8n도 마찬가지입니다.
n8n 웹 화면이 정상적으로 응답한다고 해서 모든 Workflow가 성공적으로 실행되고 있다는 뜻은 아닙니다.
개별 Workflow의 실행 실패는 별도의 실행 기록과 로그를 확인해야 합니다.
Uptime Kuma의 Up은 설정한 검사 조건에 정상적으로 응답했다는 의미이지, 서비스 내부의 모든 기능이 정상이라는 것을 보증하는 것은 아닙니다.
이 구분은 중요합니다.
모니터링 도구가 보여주는 결과를 과도하게 해석하지 않아야 하기 때문입니다.
⑭ 서비스가 Down으로 표시되면 어디부터 확인할까?
모니터링의 목적은 빨간색 화면을 보는 데 있지 않습니다.
Down 상태를 발견했을 때 다음 확인으로 연결되어야 합니다.
1단계. 실제로 접속 가능한지 확인
브라우저나 적절한 클라이언트에서 대상 서비스에 직접 접근해 봅니다.
2단계. 컨테이너 상태 확인
docker ps대상 컨테이너가 실행 중인지 확인합니다.
3단계. 컨테이너 로그 확인
Compose 프로젝트 디렉터리에서는 다음과 같이 확인할 수 있습니다.
docker compose logs --tail=100컨테이너 이름을 알고 있다면 해당 컨테이너의 로그를 직접 확인할 수도 있습니다.
docker logs --tail=100 컨테이너이름4단계. 네트워크 경로 확인
내부 주소와 외부 도메인 중 어떤 경로를 모니터링하고 있는지 확인합니다.
DNS, 리버스 프록시, 방화벽, 포트 연결 등 경로 중간의 문제일 수도 있습니다.
Uptime Kuma는 문제의 원인을 모두 해결해 주는 도구가 아니라, 어디에서 확인을 시작해야 하는지 알려주는 첫 번째 신호가 될 수 있습니다.
⑮ 확인할 장소가 하나 생긴다는 것
처음에는 모니터링 도구의 장점을 복잡한 그래프에서 찾으려고 했습니다.
CPU 그래프가 움직이고, 메모리 숫자가 바뀌고, 여러 지표가 한 화면에 나타나는 모습을 떠올렸습니다.
하지만 서비스를 직접 운영하는 입장에서는 더 단순한 장점도 있었습니다.
확인할 장소가 하나 생긴다는 것.
WordPress를 확인하기 위해 WordPress에 접속하고, n8n을 확인하기 위해 n8n에 접속하는 대신 우선 하나의 화면에서 서비스 상태를 살펴볼 수 있습니다.
이상한 신호가 보이면 그때 해당 서비스로 들어가 더 자세히 확인합니다.
서비스가 늘어날수록 이런 구조의 의미도 조금씩 커질 수 있습니다.
운영 철학
모니터링 도구의 역할은 모든 문제를 대신 해결하는 것이 아니라, 흩어진 서비스의 상태를 한곳에서 관찰하고 다음 확인을 시작할 수 있도록 돕는 데 있습니다.
운영노트
처음에는 서비스 상태를 확인하려면 직접 브라우저를 열었습니다.
WordPress를 열어보고, n8n에 들어가 보고, 문제가 없는 것 같으면 창을 닫았습니다.
서비스가 몇 개 없을 때는 이것도 충분한 방법입니다.
하지만 홈서버에 새로운 서비스를 하나씩 추가하다 보면 확인해야 할 곳도 함께 늘어납니다.
그리고 매번 직접 접속하는 일 역시 반복 작업이 됩니다.
Uptime Kuma를 사용하면서 제가 가장 먼저 느낀 장점은 복잡한 분석 기능보다 확인할 장소가 하나 생겼다는 점이었습니다.
물론 대시보드가 모두 초록색이라고 해서 서버 내부의 모든 것이 완벽하다고 생각하지는 않습니다.
WordPress의 특정 기능이 실패할 수도 있고, n8n의 개별 Workflow에서 오류가 발생할 수도 있습니다.
그래서 저는 Uptime Kuma를 모든 문제를 해결하는 도구라기보다 문제가 있는 곳을 찾아가기 위한 첫 번째 관찰 창구로 보는 편이 더 맞다고 생각합니다.
| 기존 확인 방식 | Uptime Kuma 구성 후 | 다음 행동 |
|---|---|---|
| WordPress 직접 접속 | 대시보드에서 응답 상태 확인 | 이상 시 서비스 직접 점검 |
| n8n 직접 접속 | 대시보드에서 응답 상태 확인 | 실행 기록과 로그 확인 |
| 현재 상태만 확인 | 상태 변화 기록 관찰 | 장애 발생 시점 확인 |
| 서비스별 개별 확인 | 한 화면에서 우선 확인 | 문제 서비스부터 상세 점검 |
에디터의 해석노트
좋은 모니터링의 시작은 많은 것을 보는 것이 아니라 확인해야 할 장소를 줄이는 것일 수 있습니다.
서비스가 하나일 때는 직접 접속하면 됩니다.
하지만 서비스가 늘어나면 각각의 주소와 상태를 기억하고 하나씩 확인해야 합니다.
Uptime Kuma는 홈서버의 모든 문제를 분석하는 도구는 아닙니다.
하지만 흩어져 있는 서비스의 상태를 한곳에서 바라볼 수 있게 해줍니다.
그리고 이상한 신호가 발견되면 그다음 단계로 이동할 수 있습니다.
서비스에 직접 접속해 보고, 컨테이너 상태를 확인하고, 로그를 읽고, 네트워크 경로를 살펴보는 것입니다.
그런 의미에서 모니터링 화면은 문제 해결의 종착점이라기보다 문제 탐색의 출발점에 가깝다고 생각합니다.
참고 링크 (References)
- Uptime Kuma 공식 프로젝트 문서 및 설치 안내
- Docker Documentation : Docker Compose
- Docker Documentation : Container Logs
- Docker Documentation : Restart Policies
- n8n Documentation : Logging and Monitoring
트러블슈팅
문제 1. Uptime Kuma 화면에 접속되지 않는다
먼저 컨테이너 상태를 확인합니다.
docker compose ps컨테이너가 실행되지 않았다면 로그를 확인합니다.
docker compose logs --tail=100컨테이너가 실행 중이라면 포트 연결과 접속 주소를 확인합니다.
이번 구성에서는 호스트의 3001번 포트와 컨테이너의 3001번 포트를 연결했습니다.
다른 서비스가 이미 같은 호스트 포트를 사용하고 있다면 포트 충돌 여부를 확인해야 합니다.
문제 2. 컨테이너가 계속 재시작된다
먼저 반복 재시작 여부를 확인하고 로그를 살펴봅니다.
docker ps -adocker compose logs --tail=100설정 파일의 오타, 데이터 디렉터리 접근 문제, 이미지 실행 오류 등 실제 로그에 나타나는 원인을 확인해야 합니다.
로그를 확인하지 않고 컨테이너를 계속 다시 만드는 것은 원인 파악에 도움이 되지 않을 수 있습니다.
문제 3. WordPress가 정상인데 Down으로 표시된다
먼저 Uptime Kuma에 등록한 URL이 정확한지 확인합니다.
그리고 Uptime Kuma가 실행되는 환경에서 해당 주소에 실제로 접근할 수 있는지 확인해야 합니다.
브라우저에서는 접속되더라도 컨테이너 내부의 네트워크 경로에서는 같은 주소가 다르게 동작할 수 있습니다.
내부 IP, 외부 도메인, 리버스 프록시 경로 중 무엇을 검사하고 있는지 구분해야 합니다.
문제 4. n8n 화면은 열리는데 Down으로 표시된다
등록한 URL과 모니터링 방식을 확인합니다.
리다이렉트, 인증 구조, 리버스 프록시 설정 등에 따라 단순한 주소 등록만으로 기대한 결과가 나오지 않을 수도 있습니다.
먼저 실제 응답 상태를 확인하고, Uptime Kuma의 검사 조건이 현재 서비스 구조와 맞는지 살펴봅니다.
문제 5. 재설치 후 설정이 사라졌다
Compose 설정의 데이터 볼륨 연결 상태를 확인합니다.
이번 예제에서는 다음과 같이 호스트 디렉터리와 컨테이너 데이터 디렉터리를 연결했습니다.
volumes:
- ./uptime-kuma-data:/app/data컨테이너를 새로 만들더라도 호스트 쪽 데이터가 유지되고 올바르게 다시 연결되어야 기존 설정을 계속 사용할 수 있습니다.
중요한 운영 환경에서는 단순히 볼륨을 연결하는 것에서 끝내지 않고 해당 데이터의 백업 방법도 별도로 준비하는 것이 좋습니다.
문제 6. 홈서버가 꺼졌는데 알림을 받지 못했다
Uptime Kuma가 같은 홈서버에서 실행되고 있다면 서버 전체가 꺼질 때 모니터링 도구도 함께 멈춥니다.
따라서 홈서버 전체의 정전, 인터넷 단절, 하드웨어 장애까지 외부에서 감지하려면 홈서버와 독립된 외부 모니터링 위치가 필요합니다.
이번 구성은 우선 홈서버 내부의 개별 서비스 상태를 관찰하고 모니터링 구조를 익히는 단계입니다.
| 문제 | 먼저 확인할 것 | 다음 확인 방향 |
|---|---|---|
| 웹 화면 접속 불가 | 컨테이너 상태 | 로그와 포트 확인 |
| 반복 재시작 | docker ps -a | 오류 로그 확인 |
| WordPress Down | 등록 URL | 컨테이너 접근 경로 확인 |
| n8n Down | 응답 상태 | 인증·프록시 구조 확인 |
| 설정 데이터 사라짐 | 볼륨 연결 | 호스트 데이터 확인 |
| 서버 전체 장애 감지 실패 | 모니터링 위치 | 외부 독립 감시 구조 검토 |
핵심 체크포인트 10
- Uptime Kuma는 등록한 서비스의 응답 상태를 주기적으로 확인할 수 있다.
- Docker Compose를 이용해 홈서버에 구성할 수 있다.
- 데이터 디렉터리를 연결하면 설정과 기록을 컨테이너 외부에 유지할 수 있다.
- WordPress와 n8n 같은 웹서비스를 각각 모니터링 대상으로 등록할 수 있다.
- 현재 상태뿐 아니라 Up과 Down의 상태 변화를 관찰할 수 있다.
- 중요한 운영 서비스의 장애 테스트는 무리하게 진행하지 않는다.
- 같은 서버의 Uptime Kuma는 서버 전체 장애를 외부에서 감시하는 구조와 다르다.
- Up 표시는 설정한 검사 조건의 성공을 의미하며 모든 내부 기능의 정상을 보증하지 않는다.
- Down 상태를 발견하면 서비스 접속, 컨테이너 상태, 로그, 네트워크 경로 순으로 확인할 수 있다.
- 모니터링 도구는 문제 해결의 종착점이 아니라 문제를 발견하는 출발점이다.
마무리
월요일 글에서는 홈서버 모니터링이 단순히 현재 숫자를 확인하는 것이 아니라 평소와 다른 변화를 발견하는 과정이라고 이야기했습니다.
이번에는 그 개념을 실제 도구로 옮겨 보았습니다.
Uptime Kuma를 Docker로 설치하고 WordPress와 n8n을 등록하면 여러 서비스의 상태를 하나의 화면에서 확인할 수 있습니다.
서비스가 정상적으로 응답하는지 보고, 상태 변화가 발생했는지 관찰하고, 문제가 발견되면 더 자세한 확인 단계로 이동할 수 있습니다.
물론 Uptime Kuma 하나로 홈서버의 모든 문제를 알 수 있는 것은 아닙니다.
초록색 Up 표시가 서비스 내부의 모든 기능을 보증하는 것도 아니고, 같은 홈서버에 설치한 모니터링 도구가 서버 전체의 장애를 외부에서 감시해 주는 것도 아닙니다.
하지만 홈서버 운영의 첫 모니터링 도구로는 분명한 역할이 있습니다.
흩어진 서비스 상태를 한곳에서 바라볼 수 있게 해준다는 것.
저에게는 이것이 모니터링의 첫 번째 변화였습니다.
다음 글에서는 서비스가 Down으로 표시되거나 Docker 컨테이너가 반복적으로 재시작될 때, 어디에서부터 원인을 찾아가야 하는지 로그를 중심으로 하나씩 살펴보겠습니다.
'코어-테크 : 트러블 슈팅 노트' 카테고리의 다른 글
| 홈서버는 왜 모니터링해야 할까? 장애가 나기 전에 봐야 하는 신호들 (0) | 2026.07.06 |
|---|---|
| 자동화의 첫걸음은 도구가 아니었다 : 반복되는 일을 발견하는 방법 (0) | 2026.07.05 |
| 내 홈서버는 얼마나 잘 버티고 있을까? 서비스 가동률을 확인하는 방법 (0) | 2026.07.04 |
| Webhook이 뭐길래? n8n 자동화가 시작되는 첫 번째 연결 (0) | 2026.07.03 |
| n8n을 설치했다고 끝이 아니다 : 처음 하면 좋은 초기 튜닝 7가지 (0) | 2026.07.02 |
