Beszel — 가벼운 self-hosted 서버 모니터링 허브와 에이전트

Beszel은 여러 서버의 시스템 상태, Docker/Podman 컨테이너 통계, 디스크·GPU·네트워크·온도 지표를 한 화면에서 추적하는 경량 모니터링 프로젝트다.

핵심 구조는 중앙 Hub + 각 서버의 Agent이며, PocketBase 기반의 인증·데이터 저장·웹 UI와 Go 기반 수집 에이전트를 결합한다.

 

캡션: Beszel의 대표 화면. 왼쪽은 여러 시스템을 비교하는 대시보드, 오른쪽은 단일 시스템의 CPU·메모리·디스크·네트워크·컨테이너 지표를 보여준다.

---

Quick Links

구분	링크
GitHub Repository	henrygd/beszel
공식 문서	beszel.dev
Quick Start	Getting Started
Hub 설치	Hub Installation
Agent 설치	Agent Installation
REST API	REST API
알림 설정	Notifications
OAuth/OIDC	OAuth / OIDC
GPU 모니터링	GPU Monitoring
S.M.A.R.T. 모니터링	S.M.A.R.T.
GitHub Discussions	Discussions
Releases	Releases
Demo / Paper	공식 README와 문서 기준으로 별도 공개 데모 링크 또는 논문 링크는 확인되지 않았다.

분석 메모: GitHub Wiki 경로는 별도 위키 콘텐츠가 아니라 저장소 루트로 리다이렉트된다.
따라서 문서 분석은 README와 공식 문서 사이트인 beszel.dev를 중심으로 수행했다.

---

Executive Summary

Beszel의 방향성은 명확하다.

Prometheus, Grafana, Loki, node-exporter, cAdvisor처럼 여러 컴포넌트를 조합하는 대형 관측성 스택 대신, 작고 빠르게 설치 가능한 self-hosted 서버 모니터링 도구를 제공한다.

운영자가 얻는 가치는 다음 세 가지로 요약된다.

1. 빠른 배포: Hub와 Agent를 Docker/Podman 또는 단일 바이너리로 설치할 수 있다.
2. 간단한 운영 모델: Hub는 UI·인증·저장·알림을 담당하고, Agent는 로컬 머신에서 지표를 수집한다.
3. 충분히 넓은 지표 범위: CPU, 메모리, 디스크, 네트워크, Docker/Podman, GPU, S.M.A.R.T., 온도, 배터리, systemd 서비스까지 커버한다.

대신 Beszel은 고카디널리티 애플리케이션 메트릭, 분산 트레이싱, 로그 검색, 복잡한 PromQL 질의 같은 영역을 대체하려는 프로젝트는 아니다.

소규모 서버 팜, 홈랩, 연구실 GPU 서버, 사내 edge node, self-hosted 서비스 모니터링에 특히 잘 맞는다.

---

Key Features

1. 여러 시스템을 한 화면에서 비교하는 경량 대시보드

Beszel의 첫 화면은 등록된 시스템들을 카드 형태로 보여준다.

각 시스템 카드에는 상태, CPU, 메모리, 디스크, 네트워크, Docker/Podman 컨테이너 상태 같은 핵심 지표가 압축되어 표시된다.

사용자는 전체 인프라의 이상 징후를 빠르게 찾고, 문제가 있는 시스템을 클릭해 상세 차트로 내려갈 수 있다.

캡션: 전체 시스템 대시보드. 여러 서버의 상태와 주요 지표를 같은 화면에서 비교할 수 있어, 홈랩이나 소규모 클러스터의 운영 상태를 빠르게 파악하는 데 적합하다.

2. 단일 시스템 상세 모니터링: CPU, 메모리, 디스크, 네트워크, 온도, GPU

단일 시스템 화면은 시계열 차트 중심으로 구성된다.

CPU 사용률, 메모리, 디스크 사용량, Disk I/O, 네트워크 대역폭, 온도, GPU 사용량 등이 함께 표시된다.

일반적인 VPS 모니터링뿐 아니라 GPU 워크스테이션, 로컬 연구 서버, 컨테이너 기반 self-hosted 서비스 운영에도 유용하다.

캡션: 단일 시스템 상세 화면. CPU·메모리·디스크·네트워크·온도·GPU·Docker 컨테이너 통계를 같은 맥락에서 볼 수 있다.

3. Docker/Podman 컨테이너 통계 통합

Beszel Agent는 호스트의 Docker API 또는 Podman 환경을 통해 컨테이너별 CPU, 메모리, 네트워크, 상태 정보를 수집한다.

이 기능은 self-hosted 서비스 운영자에게 특히 중요하다.

예를 들어 하나의 서버에서 reverse proxy, database, queue, AI inference server, workflow runner를 동시에 운영할 때, 전체 시스템 부하만으로는 병목 컨테이너를 찾기 어렵다.

Beszel은 시스템 차트와 컨테이너 차트를 같은 상세 화면에 배치해 원인 추적 시간을 줄인다.

 

실무적으로는 다음 상황에서 효과가 크다.

• 특정 컨테이너가 CPU를 장시간 점유하는 경우
• 데이터베이스 또는 벡터 DB 컨테이너가 메모리를 과다 사용하는 경우
• AI inference 컨테이너가 GPU와 네트워크를 동시에 압박하는 경우
• 백업·크롤링·ETL 컨테이너가 Disk I/O를 급격히 증가시키는 경우

4. 알림과 notification channel 통합

Beszel은 CPU, 메모리, 디스크, 네트워크, 온도, load average, system status 등 다양한 조건에 대한 알림을 제공한다.

알림 채널은 Shoutrrr URL schema를 기반으로 하며, 이메일, webhook, Telegram 등 여러 서비스와 연결할 수 있다.

 

캡션: 알림 설정 화면. 이메일과 webhook 등 notification channel을 설정해 시스템 임계치 초과 또는 상태 변경에 대응할 수 있다.

5. 간단한 onboarding: 관리자 생성, 시스템 추가, Agent 연결

초기 구동 후에는 Hub 웹 UI에서 관리자 계정을 만든다.

이후 Add System 화면에서 모니터링 대상 서버를 등록하고, Hub가 제공하는 KEY, TOKEN, HUB_URL 또는 socket 설정을 Agent 설치 명령에 반영한다.

캡션: 첫 실행 시 관리자 계정을 생성하는 화면. Beszel Hub는 사용자 인증과 권한 관리를 PocketBase 기반으로 처리한다.

캡션: Add System 화면. 로컬 Agent를 Unix socket으로 연결하거나, 원격 Agent에 전달할 공개 키와 토큰을 확인할 수 있다.

6. SSH mode와 WebSocket mode를 모두 지원하는 Hub–Agent 통신

Beszel의 운영상 장점은 Hub와 Agent 간 통신 방식이 단일하지 않다는 점이다.

• SSH mode: Hub가 Agent의 SSH server로 접속한다. Agent의 기본 listen port는 45876이다.
• WebSocket mode: Agent가 Hub의 /api/beszel/agent-connect endpoint로 먼저 연결한다.
  NAT, 방화벽, 사설망, Cloudflare Tunnel 같은 환경에서는 Agent-initiated 방식이 운영상 편리하다.

보안 측면에서는 공개 키, 토큰, fingerprint, signature challenge를 조합해 인증을 수행한다.

따라서 단순히 HTTP endpoint만 열어 두는 구조보다 운영 통제 지점이 명확하다.

7. GPU, S.M.A.R.T., systemd, 배터리까지 확장되는 시스템 지표

README와 공식 문서 기준으로 Beszel이 지원하는 지표 범위는 일반적인 CPU·메모리·디스크를 넘어선다.

GPU 사용량·온도·메모리·전력, S.M.A.R.T. 디스크 상태, systemd 서비스 상태, 배터리, 온도 센서, extra filesystem까지 다룬다.

 

이 범위는 연구실·개발팀의 실사용 환경과 잘 맞는다.

예를 들어 의료 AI 모델 학습 서버에서는 GPU 온도와 전력, Bioinformatics pipeline 서버에서는 디스크와 I/O, autonomous agent runner 서버에서는 CPU·메모리·컨테이너 상태가 핵심이다.

Beszel은 이런 이종 지표를 하나의 대시보드로 묶는다.

---

Tech Stack

버전 및 주요 구성

레이어	기술	버전 / 비고
Backend / Hub	Go	go.mod 기준 Go 1.26.1; 개발 문서는 Go 1.25.1+ 요구
Hub runtime	PocketBase	v0.36.8; 인증, collections, API, 내장 DB·파일·관리 기능의 기반
Agent metrics	gopsutil	v4.26.3; CPU, memory, host, load, disk, network 등 시스템 지표 수집
Hub–Agent transport	SSH, WebSocket, CBOR/JSON	gliderlabs/ssh, lxzan/gws, fxamacker/cbor 사용
CLI	Cobra	Hub/Agent command, update, health, fingerprint 등 subcommand 구성
Notification	Shoutrrr	Email, webhook, Telegram 등 다양한 notification URL schema 지원
Web UI	React	19.1.2
Web build	Vite	7.1.3
Language	TypeScript	5.9.2
Styling	Tailwind CSS	4.1.12
UI primitives	Radix UI	dialog, popover, select, tooltip 등 UI 컴포넌트 기반
Charting	Recharts	2.15.4
Frontend data	PocketBase JS SDK	0.26.2
i18n	Lingui	다국어 메시지 관리
Formatting / Linting	Biome	2.2.4
Package manager	Bun 또는 Node	공식 개발 문서 기준 Bun 1.1+ 또는 Node 18+

저장소 언어 비중

GitHub의 언어 통계 기준으로 Beszel은 Go 비중이 가장 높다.

이는 Hub와 Agent 모두 핵심 로직이 Go로 구현되어 있기 때문이다.

TypeScript는 웹 UI에 집중되어 있고, Shell/PowerShell은 설치·배포·스크립트 보조 역할을 맡는다.

• Go: 약 91% 이상
• TypeScript: 약 3%대
• Shell / PowerShell: 설치 스크립트와 운영 보조
• CSS / Makefile / 기타: UI 스타일과 빌드 자동화

---

Architecture

캡션: 공식 README와 소스 구조를 바탕으로 재구성한 Beszel 아키텍처. 저장소에서 별도 공식 아키텍처 다이어그램 이미지는 확인되지 않아, Hub–Agent 흐름과 주요 모듈을 분석자가 도식화했다.

1. Hub: PocketBase를 내장한 중앙 제어 지점

Hub는 Beszel의 중심이다. 단순한 reverse proxy나 static dashboard가 아니라, PocketBase application을 내장해 사용자 인증, collection, API, 알림, 시스템 레코드 관리를 수행한다.

코드 구조상 internal/hub에는 Hub 서버 초기화, 시스템 연결, WebSocket 처리, API 등록, update check, heartbeat, transport 관련 모듈이 배치되어 있다.

 

Hub의 책임은 다음과 같다.

• 웹 UI 제공
• PocketBase 기반 사용자·인증·collection 관리
• 시스템 등록과 상태 추적
• Agent와의 SSH 또는 WebSocket 통신
• 수집된 지표 저장과 보존 기간 관리
• 알림 조건 평가와 notification dispatch
• 자동 백업, 업데이트 확인, health endpoint 제공

2. Agent: 로컬 머신의 실제 metric collector

Agent는 모니터링 대상 서버에서 실행된다.

단일 바이너리 또는 컨테이너로 배포되며, 로컬 시스템에서 CPU, memory, disk, network, load, sensor, GPU, Docker, systemd, S.M.A.R.T. 정보를 수집한다.

 

Agent 코드 구조는 기능별로 잘 분리되어 있다.

경로 / 파일군	역할
agent/agent.go	Agent 초기화, metric gather, manager 구성
agent/connection_manager.go	WebSocket 연결과 SSH server lifecycle 관리
agent/client.go	Hub로 연결하는 WebSocket client, token/fingerprint 인증
agent/server.go	SSH server, public key authentication, CBOR/JSON response 처리
agent/system.go, cpu.go, disk.go, network.go	시스템 지표 수집
agent/docker.go	Docker API 기반 컨테이너 통계 수집
agent/gpu_*.go	Nvidia, AMD, Intel GPU collector
agent/smart.go	smartctl 기반 S.M.A.R.T. 디스크 상태 수집
agent/systemd.go	systemd service 상태 수집

3. 두 가지 통신 모드: SSH와 WebSocket

Beszel의 Hub–Agent 통신은 운영 환경에 따라 두 가지 패턴으로 사용할 수 있다.

SSH mode

Hub가 Agent에 SSH로 접속해 지표를 요청한다.

Agent는 기본적으로 :45876에서 SSH server를 열며, Hub의 공개 키를 통해 접근을 제한한다.

이 방식은 Hub가 Agent에 직접 접근 가능한 네트워크에서 단순하다.

WebSocket mode

Agent가 Hub로 먼저 연결한다.

이 방식은 사설망, NAT, 방화벽, Cloudflare Tunnel, Tailscale 등에서 유리하다.

Agent는 HUB_URL과 TOKEN을 사용해 Hub의 /api/beszel/agent-connect endpoint로 연결하고, Hub 검증 이후 지표 요청을 처리한다.

4. 데이터 흐름

1. 운영자가 Hub UI에서 시스템을 추가한다.
2. Hub가 Agent 설치에 필요한 KEY, TOKEN, HUB_URL 또는 socket 설정을 제공한다.
3. Agent가 로컬 metric collector를 초기화한다.
4. Hub가 SSH로 Agent에 접근하거나, Agent가 WebSocket으로 Hub에 연결한다.
5. Agent가 시스템·컨테이너·디스크·GPU·서비스 지표를 수집해 Hub로 전달한다.
6. Hub가 PocketBase collection에 데이터를 저장하고 UI 차트에 반영한다.
7. 알림 조건을 만족하면 Shoutrrr 기반 notification channel로 알림을 전송한다.

5. Source Code Structure 요약

디렉터리	분석 요약
agent/	시스템 지표 수집, Docker/GPU/S.M.A.R.T./systemd collector, SSH server, WebSocket client
internal/hub/	PocketBase 기반 Hub, API, WebSocket, transport, heartbeat, system manager
internal/site/	React + Vite + TypeScript 기반 웹 UI
internal/entities/	Hub와 Agent가 공유하는 data structure, stats payload, system entity
internal/alerts/	알림 조건 평가와 notification dispatch
internal/records/	metric record 저장, aggregation, retention logic
internal/users/	사용자 관리와 auth 관련 로직
internal/migrations/	PocketBase schema migration
supplemental/	배포·설치·운영 보조 자료

---

Usage & Setup

1. Hub 설치: Docker Compose 기본 형태

공식 문서는 Hub를 Docker/Podman 또는 바이너리로 설치하는 방식을 제공한다. Docker Compose 기준 최소 구성은 다음 패턴이다.

services:
  beszel:
    image: henrygd/beszel:latest
    container_name: beszel
    restart: unless-stopped
    ports:
      - 8090:8090
    volumes:
      - ./beszel_data:/beszel_data

구동 후 브라우저에서 Hub에 접속해 관리자 계정을 생성한다.

docker compose up -d

2. 시스템 추가와 Agent 설치 명령 확인

Hub UI의 Add System 화면에서 대상 서버의 이름, host, port, transport, key, token을 설정한다.

UI는 Docker 또는 binary 설치 명령을 보여주므로, 운영자는 대상 서버에서 해당 명령을 실행하면 된다.

캡션: Add System 화면의 설치 명령 예시. Docker 또는 binary 방식으로 Agent를 배포할 수 있으며, Hub가 필요한 key와 token을 함께 안내한다.

3. Agent 설치: Docker Compose 예시

원격 서버에서 Docker Agent를 실행하는 일반적인 형태는 다음과 같다.

실제 값은 Hub의 Add System 화면에서 제공되는 값을 사용한다.

services:
  beszel-agent:
    image: henrygd/beszel-agent:latest
    container_name: beszel-agent
    restart: unless-stopped
    network_mode: host
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./beszel_agent_data:/var/lib/beszel-agent
    environment:
      LISTEN: 45876
      KEY: "<hub_public_key>"
      TOKEN: "<universal_or_system_token>"
      HUB_URL: "https://<your-beszel-hub>"

docker compose up -d

4. 로컬 Agent와 Unix socket

Hub와 Agent를 같은 머신에서 함께 운영할 때는 Unix socket 기반 연결을 사용할 수 있다.

이 방식은 로컬 연결에서 포트 노출을 줄이고, Docker Compose 내에서 Hub와 Agent를 더 안전하게 묶는 데 적합하다.

 

핵심 개념은 다음과 같다.

• Hub 컨테이너와 Agent 컨테이너가 같은 socket volume을 공유한다.
• Add System 화면에서 host를 /beszel_socket/beszel.sock 같은 socket path로 설정한다.
• Agent는 LISTEN=/beszel_socket/beszel.sock 또는 문서가 제시하는 socket 설정으로 실행된다.

5. 바이너리 설치

공식 문서는 Hub와 Agent를 바이너리로 설치하는 경로도 제공한다.

Docker를 쓰지 않는 서버나 systemd로 직접 관리하려는 환경에서는 이 방식이 더 적합할 수 있다.

 

Hub는 예를 들어 다음 흐름으로 설치한다.

curl -sL https://get.beszel.dev/hub | bash
./beszel serve --http "0.0.0.0:8090"

 

Agent는 다음 형태로 실행할 수 있다.

curl -sL https://get.beszel.dev | bash
./beszel-agent \
  -key "<hub_public_key>" \
  -token "<token>" \
  -url "https://<your-beszel-hub>"

systemd service로 등록하면 재부팅 후에도 안정적으로 복구된다.

6. 등록 완료 확인

Agent가 정상 연결되면 Hub의 시스템 목록에서 새 시스템이 녹색 상태로 표시된다.

이 상태가 된 뒤부터 시계열 차트와 컨테이너 통계가 쌓인다.

캡션: 새 시스템이 정상 연결된 상태. 녹색 표시는 Hub가 Agent와 통신하며 메트릭을 수집할 수 있음을 의미한다.

7. 개발 환경 실행

소스 코드를 수정하거나 UI/Agent/Hub를 동시에 개발하려면 공식 개발 문서의 흐름을 따른다.

# Hub 개발 서버
make dev-hub

# Agent 개발 실행
make dev-agent KEY="<key>" TOKEN="<token>" HUB_URL="http://localhost:8090"

# Web UI 개발 서버
make dev-server

 

또는 세 프로세스를 한 번에 실행한다.

make -j dev KEY="<key>" TOKEN="<token>" HUB_URL="http://localhost:8090"

---

운영 관점 체크리스트

네트워크

• Hub UI와 API는 기본적으로 8090 포트를 사용한다.
• SSH mode를 사용하면 Agent의 45876 포트가 Hub에서 접근 가능해야 한다.
• NAT나 사설망 환경에서는 WebSocket mode가 더 단순하다.
• reverse proxy를 사용할 때는 WebSocket upgrade가 정상 처리되어야 한다.

보안

• 운영 환경에서는 TLS와 reverse proxy를 적용한다.
• KEY, TOKEN, HUB_URL은 secret으로 취급한다.
• 외부 공개 서버에서는 password auth disable, OAuth/OIDC, MFA, IP 제한을 고려한다.
• Docker socket을 Agent에 mount하는 경우 컨테이너 권한 모델을 이해해야 한다.
  Docker socket은 사실상 호스트 제어 권한에 가깝다.

데이터와 백업

• beszel_data는 반드시 영속 volume으로 관리한다.
• 자동 백업 기능을 사용하더라도 백업 저장 위치와 retention을 별도로 점검한다.
• 모니터링 데이터는 장기 보존할수록 저장소가 증가하므로 retention 정책을 환경에 맞게 설정한다.

GPU / S.M.A.R.T.

• Nvidia GPU는 NVML 또는 nvidia-smi 계열 collector가 필요할 수 있다.
• AMD/Intel GPU는 문서의 collector와 권한 요구 사항을 확인해야 한다.
• S.M.A.R.T.는 smartctl과 device 접근 권한이 필요하다.
• 컨테이너 Agent에서 S.M.A.R.T.를 쓰려면 장치 mount 또는 권한 상승이 필요할 수 있다.

---

Personal Insights

1. 의료 AI 관점

의료 AI 개발 환경은 GPU 서버, NAS, annotation server, inference API, model registry, experiment tracker가 혼재한다.

Beszel은 이 환경에서 인프라 건강 상태를 빠르게 확인하는 lightweight control plane으로 유용하다.

특히 다음 지점이 강점이다.

• GPU 사용량·온도·전력 지표로 inference node의 과열이나 자원 고갈을 조기에 감지할 수 있다.
• Docker 기반 의료 AI 서비스에서 모델 서버, database, queue, frontend 컨테이너를 같은 화면에서 비교할 수 있다.
• OAuth/OIDC와 multi-user 구조를 활용하면 연구자, 엔지니어, 운영자에게 접근 권한을 분리할 수 있다.
• 시스템 이상을 webhook으로 전달해 incident workflow나 Slack/Teams 알림과 연계할 수 있다.

다만 Beszel 자체가 의료 데이터 보호 솔루션은 아니다.

PHI/PII가 포함된 로그를 수집하지 않도록 운영 정책을 세워야 하며, reverse proxy TLS, 접근 제어, audit trail, 백업 암호화는 별도 보안 체계로 보강해야 한다.

2. Bioinformatics 관점

Bioinformatics pipeline은 CPU, 메모리, Disk I/O, network throughput에 민감하다.

특히 WGS/WES alignment, variant calling, single-cell RNA-seq, metagenomics, long-read assembly처럼 장시간 실행되는 작업에서는 시스템 병목이 결과 지연으로 이어진다.

Beszel의 장점은 pipeline 자체를 변경하지 않고도 서버 상태를 관찰할 수 있다는 점이다.

• Disk I/O 차트로 BAM/CRAM/FASTQ 처리 중 병목을 확인할 수 있다.
• 메모리 사용량으로 Nextflow/Snakemake job의 resource request가 적절한지 판단할 수 있다.
• 네트워크 차트로 NAS 또는 object storage 접근 병목을 추정할 수 있다.
• GPU 지표로 basecalling, protein structure, deep learning 기반 분석 작업의 자원 점유를 확인할 수 있다.

한계도 명확하다.

Beszel은 job-level metadata를 직접 이해하지 않는다.

즉, “어떤 sample, 어떤 rule, 어떤 container image가 병목을 만들었는가”까지 자동으로 추적하지는 않는다.

이 부분은 Nextflow Tower, Snakemake report, MLflow, custom webhook, PocketBase API 연동으로 보완하는 구조가 적합하다.

3. Autonomous Agent 개발 관점

Autonomous Agent 시스템은 장시간 실행, 다중 tool call, browser automation, vector database, local LLM, remote inference API를 조합한다.

이런 시스템은 작은 메모리 누수나 runaway process가 누적되어 서버 전체를 불안정하게 만들 수 있다.

Beszel은 agentic application 운영에서 다음과 같은 guardrail 역할을 할 수 있다.

• Agent runner 컨테이너별 CPU·메모리 사용량을 추적한다.
• Browser automation worker가 비정상적으로 증가하는 상황을 감지한다.
• Vector DB나 embedding service의 메모리 압박을 확인한다.
• GPU inference node의 온도·전력·메모리 점유를 관찰한다.
• webhook 알림을 통해 orchestration layer에 self-healing trigger를 줄 수 있다.

기술적으로도 Beszel의 Agent 구조는 autonomous system의 telemetry sidecar 설계에 참고할 만하다.

단일 바이너리, 로컬 collector, Hub 검증, WebSocket fallback, CBOR payload, fingerprint 인증을 조합해 작고 이식성 높은 observability agent를 구성했다는 점이 좋다.

향후 agentic workload에 더 깊게 맞추려면 다음 확장이 유용하다.

• custom metric plugin
• process tree 기반 resource attribution
• LLM inference queue depth, token throughput, latency metric
• task/run/session 단위 태깅
• REST API 또는 PocketBase collection을 통한 외부 workflow 이벤트 주입

GitHub Discussions에서도 plugin agent, S.M.A.R.T., GPU, Podman, Cloudflare Tunnel, reconnection 등 운영형 이슈가 활발히 다뤄지고 있어, Beszel은 단순 toy project라기보다 실제 사용자 기반이 있는 경량 모니터링 도구로 평가할 수 있다.

---

Fit / Not Fit

Beszel이 잘 맞는 경우

• 홈랩, 소규모 서버 팜, 연구실 GPU 서버
• Docker/Podman 기반 self-hosted 서비스 모니터링
• 복잡한 Prometheus/Grafana 스택이 부담스러운 환경
• NAT 뒤의 서버를 Agent-initiated WebSocket으로 모니터링하고 싶은 경우
• 시스템 지표와 컨테이너 지표를 빠르게 시각화하려는 팀

Beszel이 덜 맞는 경우

• 대규모 Kubernetes cluster의 high-cardinality metric 분석
• 애플리케이션 내부 custom metric과 PromQL 중심 운영
• 분산 tracing, 로그 검색, APM이 필요한 production SaaS 환경
• 엄격한 compliance audit trail이 필요한 의료/금융 운영 환경
• job-level pipeline metadata나 experiment-level metric이 필수인 연구 플랫폼

---

Image & Asset Map

파일	출처	설명하는 기능
figures/대표_대시보드와_시스템_화면.png	README asset	Beszel의 전체 UI 컨셉: 대시보드와 시스템 상세 화면
figures/대시보드_전체_시스템.png	공식 문서 screenshot	여러 시스템을 비교하는 dashboard 기능
figures/시스템_상세_메트릭.png	공식 문서 screenshot	단일 시스템의 CPU, Docker, memory, disk, bandwidth, temperature, GPU chart
figures/알림_설정.png	공식 문서 screenshot	notification channel과 alert 설정 화면
figures/초기_관리자_계정_생성.png	공식 문서 screenshot	첫 실행 후 admin user 생성 단계
figures/시스템_추가_소켓_키_토큰.png	공식 문서 screenshot	Add System에서 socket, key, token을 설정하는 단계
figures/시스템_추가_설치_방법.png	공식 문서 screenshot	Agent 설치 명령 확인 단계
figures/새_시스템_등록_완료.png	공식 문서 screenshot	Agent 연결 성공 후 시스템이 정상 상태로 표시되는 화면
figures/아키텍처_데이터_흐름.png	분석자 재구성	README, 공식 문서, 소스 코드 구조를 바탕으로 정리한 Hub–Agent 데이터 흐름

---

분석 기준

이 문서는 다음 자료를 기준으로 작성했다.

• https://github.com/henrygd/beszel
• https://github.com/henrygd/beszel/blob/main/README.md
• https://beszel.dev/guide/what-is-beszel
• https://beszel.dev/guide/getting-started
• https://beszel.dev/guide/hub-installation
• https://beszel.dev/guide/agent-installation
• https://beszel.dev/guide/developer-guide
• https://beszel.dev/guide/security
• https://beszel.dev/guide/rest-api
• https://beszel.dev/guide/notifications
• https://beszel.dev/guide/gpu
• https://beszel.dev/guide/smart
• https://github.com/henrygd/beszel/discussions
• 주요 소스: go.mod, Makefile, beszel.go, agent/, internal/hub/, internal/site/, internal/entities/

분석 시점 기준 저장소의 최신 릴리스와 문서 버전은 v0.18.7로 확인했다.