Wolf-Monitor

Lightweight self-hosted server monitoring, inspired by komari-monitor-rs. A live overview grid plus a per-server detail page with real-time charts; bilingual UI (Traditional Chinese / English); login-required by default with an optional public guest view.

Two parts:

  ┌─────────────┐   ws / http   ┌──────────────┐   SQL    ┌────────────┐
  │  wolf-node  │ ────────────► │ wolf-master  │ ───────► │ PostgreSQL │
  │  (Go probe) │   metrics     │  (Next.js)   │  upsert  │  (remote)  │
  └─────────────┘               └──────┬───────┘          └────────────┘
   CPU · mem · disk                    │ SSR + poll
   disk IO · network                   ▼
                                    browser dashboard

• Node collects metrics every few seconds and reports them. It speaks WebSocket by default (lowest latency) or HTTP as a fallback for deployments that can't hold a persistent connection.
• Master authenticates each node with a shared node token (generated at setup), writes the latest state + a history row to PostgreSQL, and serves a live dashboard.

• Master: self-host with pnpm start:ws — one process serves the dashboard and the node WebSocket on a single port. Put it behind Cloudflare / any reverse proxy if you need TLS, geo-routing, or DDoS protection.
• Node: cross-compile for Linux/Windows (GOOS=... go build) and run as a systemd service / Windows service. Use transport: http to /api/report if your master sits behind something that can't proxy WebSockets.

See node/README.md and master/README.md for full details.

CPU usage · memory (used/total, swap) · disk usage (used/total) · disk IO read & write (bytes + per-second) · network (sent/recv + up/down speed) · load average · uptime · TCP connections · process count.

Configured from the dashboard Settings page, evaluated on a schedule (driven by node reports + self-host loop), and delivered via Telegram and/or webhook:

• Load alerts — CPU/RAM/DISK ≥ threshold for a time-ratio over a window (e.g. CPU ≥ 80% for 80% of 15 min), per-server or all.
• Offline alerts — per-server, with a grace period; notifies on drop and on recovery.
• Latency monitors — selected nodes probe a target over TCP/ICMP on an interval (allowlist or blacklist of servers); results shown on the /latency page and each server's detail Network tab.

Self-hosted, so rotation and backup are on the operator. Quick reference:

• Rotate a node token — Settings → Servers → Rotate token, then restart that node with the new -t value.
• Rotate CRON_SECRET — update the env var on the host and redeploy; in-flight /api/cron/* calls with the old secret will 401.
• Rotate DATABASE_URL credentials — rotate at the postgres provider, update the env var, redeploy; nodes reconnect automatically.
• Rotate Telegram / webhook tokens — Settings → Notifications, paste new values; old ones stop sending immediately.
• Invalidate all admin sessions — psql "$DATABASE_URL" -c "DELETE FROM sessions;" then have operators log in again.
• Backup postgres — pg_dump -Fc "$DATABASE_URL" > wolf-$(date +%F).dump; restore with pg_restore -d "$DATABASE_URL" --clean --if-exists <file>. History is pruned to 30d, so backup cadence should match your RPO.
• Binary integrity — verify sha256sum of the downloaded wolf-node against the value on the GitHub Releases page before installing.

Report vulnerabilities via GitHub Security Advisories. Best-effort triage; this is a solo-maintained MIT project.

MIT © LangYa466