Beszel로 가볍게 서버 모니터링하기
복잡한 모니터링 스택이 부담스럽다면 Hub와 Agent 구조부터 이해해보세요.
- Beszel 서버 모니터링은 시스템 자원과 Docker·Podman 컨테이너 상태를 비교적 간단한 구성으로 확인할 수 있는 오픈소스 플랫폼입니다.
- 구조는 중앙 관리 화면인 Hub와 각 서버의 정보를 수집하는 Agent로 나뉩니다.
- CPU, 메모리, 디스크, 네트워크, 온도, 시스템 상태 등에 대한 기록과 알림 기능을 제공합니다.
- 공식 문서에서는 Hub와 Agent 모두 Docker·Podman 또는 바이너리 방식으로 설치할 수 있도록 안내합니다.
- Grafana처럼 여러 데이터 소스를 조합하는 방식보다 설정 범위가 단순해 홈서버 상태를 빠르게 확인하고 싶은 사용자에게 잘 맞을 수 있습니다.
Beszel 서버 모니터링을 찾는 사람이라면 Grafana와 Prometheus처럼 강력한 모니터링 환경은 알고 있지만, 개인 홈서버에 구성하기에는 조금 복잡하다고 느꼈을 가능성이 큽니다.
서버 한두 대의 CPU와 메모리, 디스크, 네트워크 사용량을 보고 싶은데 데이터 수집 시스템과 쿼리, 대시보드까지 여러 구성 요소를 처음부터 만들어야 한다면 진입 장벽이 높게 느껴질 수 있습니다.
Beszel은 이런 상황에서 비교적 단순한 구조를 제공합니다. 공식 프로젝트는 Beszel을 Docker 통계, 기록 데이터, 알림 기능을 포함한 경량 서버 모니터링 플랫폼으로 소개합니다. :contentReference[oaicite:0]{index=0}
다만 “가볍다”는 표현을 인터넷의 특정 RAM 숫자로 단정하지는 않겠습니다. 실제 사용량은 서버 수, 수집하는 데이터, 컨테이너 수와 설치 방식에 따라 달라질 수 있습니다. 대신 공식적으로 확인되는 기능 범위와 구조를 중심으로 Beszel이 왜 단순하게 느껴지는지 살펴보겠습니다.
Beszel 서버 모니터링은 어떤 도구일까?
Beszel 서버 모니터링의 핵심 목적은 서버 상태를 한눈에 확인하는 것입니다. 공식 사이트에서는 시스템 자원뿐 아니라 Docker 또는 Podman 컨테이너의 CPU, 메모리, 네트워크 사용 이력도 확인할 수 있다고 안내합니다. :contentReference[oaicite:1]{index=1}
또한 CPU, 메모리, 디스크, 대역폭, 온도, 시스템 상태 등에 대해 설정 가능한 알림 기능을 제공합니다. 단순히 현재 숫자만 보여주는 것이 아니라 일정 기간의 기록과 상태 변화를 함께 볼 수 있다는 점이 특징입니다. :contentReference[oaicite:2]{index=2}
이런 구조는 홈서버 운영에서 꽤 실용적입니다. 예를 들어 서버가 평소보다 CPU를 많이 사용하는지, 메모리가 꾸준히 증가하는지, 저장공간이 얼마나 남았는지, 특정 Docker 컨테이너의 자원 사용량이 급격히 늘었는지를 하나의 관리 화면에서 확인할 수 있습니다.
추가 디스크도 모니터링할 수 있습니다. Beszel 공식 문서에서는 디스크, 파티션 또는 원격 마운트를 추가로 모니터링할 수 있다고 설명합니다. 다만 네트워크로 마운트된 드라이브에서는 I/O 통계를 얻을 수 없다는 제한도 명시하고 있습니다. :contentReference[oaicite:3]{index=3}
이처럼 Beszel의 장점은 별도의 대시보드 설계를 처음부터 하지 않아도 서버 모니터링에 자주 필요한 정보를 기본 인터페이스에서 바로 확인하기 쉽다는 데 있습니다.
Grafana처럼 사용자가 데이터 소스와 쿼리, 패널을 자유롭게 조합하는 방식은 확장성이 높지만 초보자에게는 처음 구성이 복잡할 수 있습니다. Beszel은 그보다 서버 상태 확인이라는 목적을 더 명확하게 잡고 있습니다.
Grafana가 “어떤 데이터를 어떻게 시각화할지 직접 설계하는 플랫폼”에 가깝다면 Beszel은 “서버 상태를 빠르게 확인하기 위한 완성된 관리 화면”에 더 가깝습니다. 어느 쪽이 더 좋다기보다 자유도와 단순함 중 무엇이 필요한지에 따라 선택이 달라집니다.
Beszel은 자동 백업과 멀티유저, OAuth/OIDC 인증, API 접근 같은 기능도 공식적으로 제공합니다. 서버 한 대만 보는 개인 환경뿐 아니라 여러 시스템을 관리하는 방향으로 확장할 수 있는 기능도 갖추고 있습니다. :contentReference[oaicite:4]{index=4}
Beszel Hub와 Agent 구조 이해하기
Beszel 서버 모니터링을 설치하기 전에 반드시 알아둘 개념은 Hub와 Agent입니다. Beszel은 하나의 프로그램만 모든 서버에서 독립적으로 실행하는 형태가 아니라 중앙 관리 역할과 데이터 수집 역할을 나눠놓았습니다.
Hub는 웹 인터페이스와 데이터를 관리하는 중심 서버입니다. 여러 시스템을 Hub에 등록하면 사용자는 Hub 화면에서 각 서버의 상태와 기록을 확인할 수 있습니다.
Agent는 모니터링할 서버에서 실행됩니다. 서버의 시스템 정보와 필요한 메트릭을 수집하고 Hub가 이를 확인할 수 있도록 연결하는 역할을 담당합니다.
홈서버 B — Beszel Agent
NAS / 추가 서버 — Beszel Agent
↓
Beszel Hub
↓
웹 브라우저에서 통합 상태 확인
서버가 한 대뿐이어도 구조는 같습니다. Hub와 Agent를 같은 시스템에서 함께 실행할 수 있으며, 공식 Getting Started 문서에서는 Hub와 로컬 Agent를 포함한 완전한 Docker Compose 예시도 제공합니다. :contentReference[oaicite:5]{index=5}
여러 서버가 있다면 각 서버에 Agent를 추가하고 하나의 Hub에서 모아서 볼 수 있습니다. 예를 들어 미니 PC 홈서버와 별도 NAS, 테스트 서버를 운영한다면 각 장비의 Agent가 데이터를 제공하고 Hub에서 전체 상태를 확인하는 식입니다.
Agent를 추가할 때 필요한 값
현재 Beszel 공식 Agent 설치 문서에서는 Agent 구성에 KEY, TOKEN, 필요에 따라 HUB_URL 같은 값을 사용합니다. KEY는 Hub에서 시스템을 추가할 때 표시되는 공개 키이고, TOKEN은 Agent 인증에 사용됩니다. :contentReference[oaicite:6]{index=6}
HUB_URL은 Agent가 Hub에 outgoing WebSocket 방식으로 연결할 때 사용하며, SSH 연결 방식에서는 필수 항목이 아니라고 공식 문서에서 설명합니다. :contentReference[oaicite:7]{index=7}
이 부분은 예전 설치 글과 차이가 있을 수 있으므로 현재 버전의 문서를 기준으로 설정해야 합니다. 특히 KEY만 넣는 오래된 예제가 있다면 현재 공식 문서의 TOKEN 요구 사항과 비교해서 확인하는 편이 좋습니다.
Beszel은 계속 개발되는 프로젝트이므로 Agent 연결 방식이나 필수 환경 변수가 예전 글과 달라질 수 있습니다. 현재 공식 문서에서는 KEY와 TOKEN을 필수 변수로 안내합니다. 설치할 때는 검색 결과의 오래된 Compose 파일보다 최신 공식 Agent Installation 문서를 우선하세요. :contentReference[oaicite:8]{index=8}
같은 서버에 Hub와 Agent가 있다면
Hub와 Agent를 모두 Docker로 같은 서버에서 실행할 때는 네트워크 구성도 주의해야 합니다. 공식 Common Issues 문서에서는 로컬 Agent 연결에서 단순히 localhost를 사용하는 방식이 동작하지 않을 수 있다고 설명합니다.
그 이유는 Hub와 Agent 컨테이너가 서로 다른 Docker 네트워크에 있을 수 있기 때문입니다. Beszel 공식 문서는 이런 로컬 구성에서 Unix socket을 사용하는 방식을 권장하며, 바로 사용할 수 있는 Compose 예시를 제공합니다. :contentReference[oaicite:9]{index=9}
Beszel을 처음 시험한다면 Hub와 Agent를 같은 홈서버에 설치해 기본 구조를 익힌 뒤 두 번째 서버를 추가해보세요. 한 대에서 먼저 성공하면 KEY·TOKEN·Agent 연결 방식이 어떻게 동작하는지 이해하기 쉽습니다.
Hub와 Agent를 나눈 구조는 여러 서버를 확장할 때 편리합니다. Hub 관리 화면은 한 곳에 두고 모니터링할 서버에 Agent만 추가하면 되기 때문입니다.
반대로 단일 홈서버 한 대만 사용한다고 해서 Agent 구조가 불필요한 것은 아닙니다. 실제 상태 데이터를 수집하는 역할과 이를 저장·표시하는 역할이 분리되어 있다는 점을 이해하면 설치 과정도 훨씬 명확해집니다.
Beszel의 Hub·Agent 구조는 “관리 화면 하나에 여러 서버를 붙인다”는 관점으로 이해하면 쉽습니다. 서버가 늘어나더라도 각각 독립적인 대시보드를 만드는 대신 Agent를 추가해 하나의 Hub에서 비교할 수 있다는 것이 핵심입니다.
Docker로 Beszel 설치하기
Beszel 서버 모니터링의 Hub와 Agent 구조를 이해했다면 이제 실제 홈서버에 설치해볼 차례입니다. Docker를 이미 사용하는 환경이라면 Hub와 Agent를 컨테이너로 구성할 수 있습니다.
Beszel 공식 문서에서는 Docker Compose를 이용한 설치 방법을 제공하며, Hub와 Agent를 같은 Compose 구성에서 실행하는 예제도 안내합니다.
먼저 작업할 디렉터리를 만들고 Compose 파일을 관리하면 이후 업데이트나 설정 확인이 편합니다.
mkdir beszel
cd beszelBeszel Hub만 먼저 실행하는 기본적인 Compose 구조는 다음처럼 이해할 수 있습니다.
services:
beszel:
image: henrygd/beszel
container_name: beszel
restart: unless-stopped
ports:
- "8090:8090"
volumes:
- beszel_data:/beszel_data
volumes:
beszel_data:Compose 파일을 저장했다면 다음 명령으로 실행할 수 있습니다.
docker compose up -d컨테이너가 정상적으로 실행됐는지는 다음 명령으로 확인할 수 있습니다.
docker ps문제가 발생했다면 로그도 확인해봅니다.
docker logs beszel설치가 완료되면 같은 내부 네트워크의 브라우저에서 홈서버 IP와 8090번 포트를 이용해 Hub에 접근할 수 있습니다.
http://서버-IP:8090예를 들어 서버 내부 IP가 192.168.0.50이라면 다음과 같은 형태입니다.
http://192.168.0.50:8090처음 Hub에 접속하면 계정을 생성하고 관리 화면으로 들어갈 수 있습니다. 이후 실제 서버 데이터를 가져오기 위해 모니터링 대상 시스템과 Agent를 연결합니다.
처음부터 Hub와 여러 Agent를 한꺼번에 구성하기보다 Hub 접속에 성공한 뒤 서버를 하나씩 추가하는 것이 좋습니다. 문제가 발생했을 때 Hub 문제인지 Agent 연결 문제인지 구분하기 쉬워집니다.
Agent도 Docker로 실행할 수 있다
모니터링 대상 서버에서는 Beszel Agent를 실행해야 합니다. 공식 문서에서는 Docker Compose, 단일 Docker 명령, 바이너리 설치 등 여러 방법을 안내합니다.
Docker 환경이라면 Agent 컨테이너를 사용해 구성할 수 있습니다. 다만 Agent를 실제로 연결할 때 필요한 KEY와 TOKEN 값은 Hub에서 시스템을 추가하는 과정에서 확인한 값을 사용해야 합니다.
따라서 인터넷에 있는 예제의 임의 값을 그대로 복사하면 안 됩니다.
Agent 인증에 필요한 값은 자신의 Beszel Hub에서 시스템을 추가하면서 확인해야 합니다. 블로그 예제에 실제 인증 값을 넣거나 다른 사용자의 값을 복사해서 사용하는 방식이 아닙니다.
또한 Docker 컨테이너 통계를 확인하려면 Agent가 Docker 정보를 읽을 수 있는 구성이 필요합니다. Docker 소켓을 직접 연결하는 구성은 편리하지만 높은 권한과 관련될 수 있으므로 보안 영향을 이해하고 사용해야 합니다.
Beszel 공식 문서에서는 Docker 환경에서 사용할 수 있는 socket proxy 구성도 안내하고 있으므로 외부 공개 서버나 보안을 더 엄격하게 관리하는 환경이라면 공식 Docker 설치 문서를 함께 확인하는 것이 좋습니다.
홈서버 모니터링 도구를 설치할 때 가장 중요한 것은 “화면이 열리는가?”만 확인하는 것이 아닙니다. 데이터 저장 위치, Agent 권한, Docker 접근 방식까지 이해해두면 업데이트와 장애 대응이 훨씬 쉬워집니다.
첫 번째 서버를 Beszel에 추가하는 법
Hub가 실행됐다면 이제 실제 모니터링 대상 서버를 추가해야 합니다. Beszel에서는 Hub에서 시스템을 등록하고 해당 시스템에 Agent를 설치해 연결하는 방식으로 구성합니다.
처음에는 현재 Beszel Hub가 설치된 홈서버 한 대를 등록해보는 것이 가장 이해하기 쉽습니다.
- Beszel Hub 로그인
- 새 시스템 추가
- 시스템 이름 입력
- Agent 연결 방식 확인
- Hub에서 KEY·TOKEN 등 필요한 값 확인
- 대상 서버에서 Agent 설치
- Agent 시작
- Hub에서 연결 상태 확인
시스템 이름은 서버가 여러 대로 늘어날 것을 생각해서 정하는 것이 좋습니다.
Server 1처럼 단순한 이름보다 서버의 역할을 나타내는 이름이 관리하기 쉽습니다.
HomeServer
MediaServer
NAS
RaspberryPi
MiniPC-01Agent가 정상적으로 연결되면 Hub에서 서버의 시스템 정보를 확인할 수 있고 시간이 지나면서 수집된 데이터가 기록됩니다.
연결되지 않는다면 무엇부터 확인할까?
Agent가 연결되지 않는다면 프로그램을 반복해서 재설치하기 전에 연결 구조부터 확인하는 것이 좋습니다.
먼저 Agent가 정상적으로 실행되고 있는지 확인합니다.
docker psAgent 컨테이너 로그도 확인할 수 있습니다.
docker logs beszel-agent그다음 KEY와 TOKEN이 Hub에서 제공된 값과 일치하는지, Agent와 Hub 사이의 네트워크 연결이 가능한지 확인합니다.
같은 서버인데 왜 localhost가 안 될까?
Docker를 처음 사용하는 경우 가장 헷갈리는 부분 중 하나입니다. Hub와 Agent가 같은 물리 서버에 있더라도 서로 다른 컨테이너라면 각 컨테이너에서 localhost는 자기 자신을 의미합니다.
즉 Hub 컨테이너 안에서 localhost를 입력한다고 자동으로 Agent 컨테이너를 가리키는 것은 아닙니다.
Beszel 공식 문서는 같은 서버에서 Hub와 Agent를 운영하는 경우 Unix socket을 사용하는 로컬 연결 구성을 권장하고 있습니다. 따라서 단순히 IP와 포트를 임의로 바꾸기보다 공식 로컬 Agent Compose 예제를 기준으로 구성하는 편이 안전합니다.
Docker에서
localhost는 “이 컴퓨터 전체”가 아니라 보통 “현재 컨테이너 자신”이라는 점을 기억해두세요. Beszel뿐 아니라 데이터베이스, 리버스 프록시, 모니터링 도구를 연결할 때도 자주 만나게 되는 개념입니다.두 번째 서버 추가는 훨씬 단순하다
첫 번째 Agent 연결에 성공했다면 두 번째 서버부터는 구조를 이해하기 쉬워집니다.
Hub에 새로운 시스템을 등록하고 해당 서버에서 Agent를 실행한 뒤 그 시스템에 맞는 인증 및 연결 설정을 적용하면 됩니다.
├─ HomeServer Agent
├─ NAS Agent
├─ Raspberry Pi Agent
└─ MiniPC Agent
이렇게 구성하면 각각의 서버에 별도의 모니터링 웹 UI를 만들 필요 없이 하나의 Beszel Hub에서 여러 장비의 상태를 확인할 수 있습니다.
홈랩이 커질수록 이런 중앙 관리 방식의 장점이 커집니다. 처음에는 미니 PC 한 대만 운영하더라도 나중에 NAS나 라즈베리파이 같은 장비가 추가됐을 때 같은 Hub에 연결할 수 있습니다.
Beszel을 처음 설치했다면 여러 서버를 추가하기 전에 첫 번째 서버의 CPU·메모리·디스크 데이터가 정상적으로 기록되는지 하루 정도 확인해보세요. 기본 수집이 정상이라는 것을 확인한 뒤 장비를 늘리면 문제 발생 지점을 훨씬 쉽게 찾을 수 있습니다.
Beszel에서 어떤 데이터를 확인할 수 있을까?
Beszel 서버 모니터링을 연결하고 시간이 지나면 단순한 현재 상태보다 서버의 변화 흐름이 더 중요해집니다. CPU가 순간적으로 높아진 것인지, 몇 시간 동안 계속 높은 상태인지에 따라 문제의 의미가 달라지기 때문입니다.
Beszel 공식 프로젝트는 시스템의 CPU, 메모리, 디스크, 네트워크 등의 상태를 기록하고, Docker 또는 Podman 컨테이너의 CPU·메모리·네트워크 사용 이력도 확인할 수 있도록 구성되어 있습니다.
따라서 홈서버를 열었을 때 가장 먼저 확인하기 좋은 항목은 CPU, 메모리, 저장공간입니다. 이 세 가지는 서버가 느려졌거나 새로운 서비스를 추가할 수 있을지 판단할 때 기본적인 기준이 됩니다.
예를 들어 평소에는 메모리를 많이 사용하지 않던 컨테이너가 특정 시점 이후 계속 높은 사용량을 유지한다면 해당 서비스를 우선적으로 확인할 수 있습니다.
반대로 CPU 사용량이 잠깐 올라갔다가 바로 정상으로 돌아왔다면 백업이나 미디어 처리처럼 일시적으로 부하가 발생한 작업일 수도 있습니다. 현재 숫자 하나보다 기록 데이터를 함께 보는 이유입니다.
Docker 컨테이너별 사용량도 확인한다
홈서버에서 Docker를 사용한다면 전체 시스템 사용률만 보는 것으로는 어떤 서비스가 자원을 많이 사용하는지 파악하기 어려울 수 있습니다.
Beszel은 Docker와 Podman 컨테이너의 CPU, 메모리, 네트워크 사용 이력을 추적할 수 있으므로 서비스 단위로 문제를 좁히는 데 활용할 수 있습니다.
예를 들어 전체 서버의 CPU 사용률이 높다면 먼저 Beszel의 컨테이너 데이터를 확인해 어떤 서비스의 사용량이 함께 증가했는지 비교해볼 수 있습니다.
새로운 셀프호스팅 앱을 설치했다면 설치 직후만 확인하지 말고 평상시와 실제 사용 중의 CPU·메모리 변화를 며칠 정도 관찰해보세요. 서버가 감당할 수 있는 서비스 규모를 판단하는 데 도움이 됩니다.
추가 디스크와 마운트도 확인할 수 있다
Beszel 공식 문서는 추가 디스크와 파티션, 원격 마운트를 모니터링하는 기능도 안내하고 있습니다. 운영체제 디스크와 별도로 데이터를 저장하는 홈서버라면 유용한 기능입니다.
Linux에서 어떤 디스크와 파티션이 연결되어 있는지 확인해야 한다면 다음 명령을 이용할 수 있습니다.
lsblk공식 Beszel 문서 역시 추가 디스크의 장치 이름과 마운트 지점을 확인할 때 lsblk를 활용하는 방법을 안내합니다.
다만 네트워크로 마운트한 드라이브에서는 I/O 통계를 얻을 수 없다는 제한이 공식 문서에 명시되어 있습니다. 따라서 NAS의 원격 공유를 마운트했다고 해서 로컬 디스크와 완전히 같은 정보가 나타난다고 기대해서는 안 됩니다.
GPU와 systemd 서비스까지 확장 가능
현재 Beszel 공식 문서에서는 지원되는 환경에서 GPU 사용률, 온도, 메모리와 전력 관련 데이터를 모니터링하는 기능도 안내합니다. Agent가 사용할 수 있는 GPU 모니터링 도구를 감지해 적절한 collector를 선택하는 구조입니다.
또한 systemd 서비스를 간단하게 확인하는 기능도 제공하며, 서비스의 상태와 CPU·메모리 사용량 등 기본적인 정보를 확인할 수 있습니다.
하지만 홈서버를 처음 구성한다면 이런 확장 기능을 모두 활성화할 필요는 없습니다. 우선 시스템과 Docker 컨테이너 상태부터 충분히 익힌 뒤 GPU나 systemd 모니터링이 실제로 필요한지 판단하는 편이 좋습니다.
Beszel의 장점은 처음부터 모든 데이터를 직접 설계하지 않아도 된다는 데 있습니다. CPU·메모리·디스크와 컨테이너 상태부터 시작하고, 실제 필요가 생겼을 때 추가 디스크·GPU·systemd 같은 기능을 확장하면 관리 화면도 복잡해지지 않습니다.
알림을 설정하면 매번 대시보드를 볼 필요가 없다
모니터링 시스템을 구축했더라도 관리자가 하루 종일 화면을 보고 있을 수는 없습니다. 그래서 Beszel은 CPU, 메모리, 디스크, 대역폭, 온도, 시스템 상태 등의 조건에 알림을 설정할 수 있습니다.
공식 알림 문서에서는 Settings → Notifications에서 알림 URL을 설정하고, 시스템 목록에서 Alert를 활성화하는 흐름을 안내합니다.
알림 전송은 Shoutrrr URL 형식을 이용하며 Discord, Slack, Telegram, ntfy 등 여러 서비스별 공식 설정 문서가 제공됩니다.
CPU가 잠깐 올라가는 것까지 모두 장애로 취급하면 알림이 너무 자주 발생할 수 있습니다. 대신 평상시 서버 사용 패턴을 먼저 확인하고 실제 대응이 필요한 조건을 기준으로 알림을 조정하세요.
Grafana 대신 Beszel이 잘 맞는 경우
Beszel 서버 모니터링을 검토하면서 가장 궁금한 것은 “이미 Grafana가 있는데 굳이 Beszel을 쓸 이유가 있을까?”일 수 있습니다.
두 도구는 겹치는 부분이 있지만 접근 방식이 다릅니다. Grafana는 다양한 데이터 소스에 연결하고 사용자가 직접 Query와 Panel을 조합해 원하는 대시보드를 설계할 수 있는 범용 시각화 플랫폼입니다.
Beszel은 서버와 컨테이너 상태를 확인하는 목적에 맞춘 화면과 수집 구조가 기본적으로 준비되어 있습니다. 즉 직접 설계하는 자유도보다 빠른 구축과 단순한 운영에 무게가 실립니다.
홈서버 한두 대의 CPU, 메모리, 디스크와 Docker 컨테이너 상태를 보고 싶은 사용자라면 Beszel의 구성만으로 목적을 달성할 수 있습니다.
특히 “Prometheus부터 설치하고 쿼리를 작성한 뒤 Grafana Panel을 직접 만드는 과정이 아직 부담스럽다”면 Beszel로 서버 상태를 먼저 확인해보는 것이 이해하기 쉽습니다.
반대로 여러 서비스에서 생성되는 다양한 메트릭을 하나의 화면에 모으거나, 쿼리를 직접 작성해서 원하는 방식으로 가공하고, 업무 목적에 맞춘 복잡한 대시보드를 만들어야 한다면 Grafana의 자유도가 더 중요할 수 있습니다.
그래서 두 프로그램을 반드시 하나만 선택해야 하는 것도 아닙니다. 간단한 서버 상태 확인에는 Beszel을 사용하고, 더 깊은 분석이 필요한 영역에는 별도의 Grafana 환경을 사용하는 식으로 역할을 구분할 수도 있습니다.
CPU·RAM·디스크·Docker 컨테이너 상태만 빠르게 보고 싶다면 Beszel부터 시작해보세요. 사용하면서 “이 데이터를 다른 메트릭과 조합하고 싶다”는 요구가 생길 때 Grafana·Prometheus 같은 구성을 학습해도 늦지 않습니다.
Uptime Kuma와도 목적이 다르다
Uptime Kuma와 Beszel도 비슷해 보이지만 확인하는 질문이 다릅니다. Uptime Kuma는 웹서비스나 네트워크 대상이 정상적으로 응답하는지 확인하는 업타임 모니터링에 적합합니다.
Beszel은 서버 내부에서 CPU·메모리·디스크·컨테이너 같은 자원 상태가 어떻게 변하고 있는지 확인하는 데 초점이 맞춰져 있습니다.
따라서 홈서버에서는 두 도구를 서로 대체하는 관계로만 볼 필요가 없습니다. Uptime Kuma로 “서비스가 살아 있는가?”를 확인하고 Beszel로 “서버 내부 자원이 어떤 상태인가?”를 확인하는 식으로 역할을 나눌 수 있습니다.
Uptime Kuma, Beszel, Grafana는 모니터링이라는 공통점이 있지만 목적이 다릅니다. 서비스 생존 확인은 Uptime Kuma, 간단한 서버 자원 관리는 Beszel, 자유로운 데이터 분석과 대시보드 설계는 Grafana라는 식으로 구분하면 선택하기 쉽습니다.
설치 후에는 백업과 업데이트도 관리한다
Beszel을 장기간 운영한다면 Hub 자체의 데이터 관리도 필요합니다. 공식 프로젝트는 데이터를 디스크 또는 S3 호환 스토리지로 저장하고 복원할 수 있는 자동 백업 기능을 제공합니다.
여러 서버를 연결하고 알림까지 설정했다면 Hub가 단순한 테스트 앱이 아니라 중요한 관리 도구가 됩니다. 따라서 업데이트 전에 현재 구성과 백업 상태를 확인하는 습관을 들이는 것이 좋습니다.
업데이트 알림 기능과 관련된 환경 변수도 공식 문서에 안내되어 있습니다. 다만 새 버전이 있다는 이유만으로 운영 중인 서버에 즉시 적용하기보다 변경 사항과 현재 백업 상태를 확인한 뒤 업데이트하는 편이 안전합니다.
Beszel Hub가 사라져도 실제 서버 데이터가 모두 없어지는 것은 아니지만 수집 이력과 설정을 다시 구성해야 할 수 있습니다. 대신 장기간 사용할 환경이라면 Beszel의 백업 기능과 Hub 데이터 저장 위치를 미리 확인해두세요.
자주 묻는 질문
모든 환경에서 일정한 자원 사용량 차이가 난다고 단정하기는 어렵습니다. Beszel 공식 프로젝트는 자신을 lightweight 서버 모니터링 플랫폼으로 설명하지만 실제 CPU·RAM 사용량은 서버와 컨테이너 수, 수집 기능에 따라 달라질 수 있습니다. 자신의 환경에서 docker stats 등으로 확인하는 것이 가장 정확합니다.
Beszel은 Hub가 관리 화면과 데이터를 담당하고 Agent가 서버 정보를 수집하는 구조입니다. 공식 Getting Started 문서에서는 Hub와 로컬 Agent를 같은 서버에서 구성하는 예시도 제공합니다.
가능합니다. Beszel은 Docker와 Podman 컨테이너의 CPU, 메모리, 네트워크 사용 이력을 추적하는 기능을 제공합니다. 데이터가 나타나지 않는다면 Agent의 Docker 접근 설정과 docker stats 결과를 함께 확인하세요.
가능합니다. 공식 문서는 CPU, 메모리, 디스크, 대역폭, 온도, 시스템 상태 등에 대한 Alert 기능을 안내하며, 알림 URL은 Settings → Notifications에서 구성할 수 있습니다.
가능합니다. 각 서버에 Agent를 구성하고 하나의 Hub에 시스템으로 등록하면 여러 장비의 상태를 중앙에서 확인할 수 있습니다. HomeServer, NAS, MiniPC처럼 역할에 맞는 이름을 지정해두면 관리하기 편합니다.
가능합니다. Uptime Kuma로 HTTP(S)나 Ping을 이용해 서비스 가용성을 확인하고, Beszel로 CPU·메모리·디스크와 컨테이너 자원을 확인하면 서로 다른 영역을 보완할 수 있습니다.
📖 핵심 용어 미니 사전
Beszel을 처음 사용할 때 자주 등장하는 용어를 간단히 정리했습니다.
Beszel의 중앙 관리 화면과 데이터를 담당하는 구성 요소입니다. 여러 서버의 Agent를 하나의 Hub에 연결할 수 있습니다.
모니터링 대상 서버에서 실행되어 시스템과 컨테이너의 정보를 수집하는 Beszel 구성 요소입니다.
CPU 사용률이나 메모리 사용량처럼 서버 상태를 수치로 표현한 데이터를 의미합니다.
CPU·메모리·디스크 등의 상태가 설정한 조건에 해당할 때 사용자에게 알려주기 위한 기능입니다.
저장장치가 제공하는 자체 상태 진단 정보입니다. Beszel은 지원되는 환경에서 S.M.A.R.T. 관련 모니터링 기능을 제공합니다.
🔗 공식 자료
📖 출처
- Beszel 공식 사이트 — 주요 기능, Docker·Podman 통계, Alert 및 자동 백업
- Beszel Docs — What is Beszel?
- Beszel Docs — Getting Started 및 Hub·Agent 구성
- Beszel Docs — Agent Installation 및 연결 방식
- Beszel Docs — Notifications 및 Alert 구성
- Beszel Docs — Additional Disks
- Beszel Docs — Common Issues 및 Docker 통계 문제 해결
- Beszel Docs — GPU Monitoring 및 Systemd Services
- Beszel Docs — Security 및 네트워크 요구사항
Beszel 서버 모니터링은 CPU·메모리·디스크·네트워크와 Docker 컨테이너 상태를 복잡한 대시보드 설계 없이 빠르게 확인하고 싶은 홈서버에 잘 맞습니다. Hub와 Agent 구조부터 시작해 서버 한 대를 먼저 연결하고, 실제 필요에 따라 알림·추가 디스크·GPU·여러 서버 관리로 확장하는 방식이 좋습니다.
