尧图网站建设 
很多人做网站最头疼的不是功能开发而是上线之后两眼一抹黑到底有没有人来看看了哪些页面服务器扛不扛得住出问题了怎么第一时间知道针对这些需求我一直在用一套开源组合拳来搞定网站统计用 umami服务器监控用 beszel。这两个都是开源项目一个管业务数据一个管机器状态配合起来基本覆盖了中小站点日常运维的所有核心需求。这篇文章就把我的完整搭建过程和踩坑经验分享出来希望能帮你少走弯路。1. 内容整体设计与思路拆解1.1 为什么网站统计和监控要一起做先说一个常见的误区很多人觉得网站统计和服务器监控是两码事统计是给运营看的监控是给运维看的小站点没必要都装。但实际运营下来你会发现这两个东西是强关联的。最典型的场景就是统计后台显示流量突然暴跌这时候你分不清是用户真的不来了还是服务器挂了导致请求根本没到达。如果只有统计没有监控你得先去登录服务器看进程、看负载、看带宽排查一圈才发现是磁盘满了或者数据库连接数爆了。反过来如果只有监控没有统计服务器一切正常但流量就是上不去你也定位不到是页面问题还是推广渠道问题。所以我的思路很直接统计工具负责回答“网站本身好不好用、有没有人用”监控工具负责回答“服务器撑不撑得住、什么时候会出问题”。两套数据拼在一起才能形成一个相对完整的判断闭环。再来说说为什么选开源方案。商业统计平台虽然接入简单但数据全部过第三方隐私合规上始终是个隐忧而且很多细粒度的事件追踪、自定义指标都藏在付费版里。自己用开源方案数据完全握在自己手里想怎么分析就怎么分析想接什么告警渠道就接什么渠道没有任何功能上的天花板。1.2 核心方案选型umami 和 beszel 分别解决什么问题标题里说的“3分钟搞定”主角其实是 umami。这是一款基于 Node.js 开发的轻量级网站统计分析工具界面清爽部署方式极其简单一条 Docker 命令就能把服务和数据库全部拉起来。它最大的特点是摒弃了传统统计工具那一套复杂的埋点配置你只需要在页面里塞一段几十行的 JavaScript 脚本访问数据就会自动回传。它对隐私也非常友好不依赖 Cookie所以不需要弹窗让用户确认“是否同意被追踪”这在欧洲那个 GDPR 合规环境下特别实用。Beszel 则是配套的服务器监控工具同样开源它和 umami 互补性非常强。Beszel 走的是轻量化路线程序本体就一个几百KB的二进制文件通过 SSH 协议采集目标服务器的 CPU、内存、磁盘、网络、温度等指标。你不需要在被监控的机器上额外安装任何 Agent 程序所有采集工作都通过在管理端发起 SSH 连接来完成这对多服务器环境非常友好也不用担心 Agent 兼容性问题。选型对比上我也补充一个个人结论如果是单站点、个人博客这类轻量需求整体方案中 umami 的轻便性远超 Matomo因为 Matomo 对 PHP 和 MySQL 环境的依赖较重而且不少统计功能绑定其付费插件如果是企业级多种站群或深度销售转化分析可以结合 Matomo 做补充但就我的使用体验来说umami 加自定义事件已经能覆盖绝大多数日常需求。1.3 这套组合的适用场景和边界明确一点这套方案的目标用户是个人站长、中小团队、SaaS 产品初期、博客作者、独立开发者。你要监控的不是几千台机器的集群而是几台到十几台服务器的规模。在这个范围内umami 加 beszel 可以说是体验和成本最为平衡的组合。但是如果你面对的是大规模分布式系统需要监控 Kubernetes 集群的容器编排状态需要做链路追踪、日志聚合分析那还是去用 Prometheus Grafana Loki 这样的全家桶更合适。umami 和 beszel 的设计哲学是“小而美”它们不会试图解决所有问题而是把核心问题解决得足够顺手。理解这个边界你才不会方案选型选到心态爆炸。2. 网站统计实操要点umami 的埋点部署与数据解读2.1 umami 部署的两种方式云端版和自托管版Umami 官方提供了一个在线托管服务 umami.cloud注册账号、创建站点、拿到跟踪代码三步就能完成接入。如果你不想折腾服务器也不想管数据库更新用云端版是最省心的一个月有几万的免费事件额度个人博客的流量完全够用。但既然是开源爱好者我更推荐自己动手部署。自托管的核心优势有两个数据不会经过任何第三方订阅费用为 0而且后期做二次开发、扩展事件上报字段都非常方便。部署方式推荐用 Docker Compose。umami 的官方仓库里提供了一份现成的 docker-compose.yml里面包含 umami 本体和 PostgreSQL 数据库两个服务。如果你正准备做冷备方案也可以把数据库这块替换成外部的 PostgreSQL 实例但初始入门阶段全部用容器化方案是上手成本最低的。2.2 埋点接入和页面代码解读新建一个站点之后umami 会分配一个唯一的网站 ID并生成一段类似下面这样的嵌入代码script async srchttps://your-domain.com/script.js>umami.track(download_click, { file: guide.pdf });第二个参数是自定义负载可以放置任意结构化信息比如商品 ID、点击位置、用户来源渠道等。这些自定义事件都会出现在后台的 Events 面板里配合过滤条件可以做很多精细化的行为分析。2.3 数据解读的常用口径接入之后后台默认展示几个核心指标访客数Unique Visitors、页面浏览量Pageviews、平均访问时长、跳出率、来源渠道和设备分布。这里特别说一下“访客数”和“页面浏览量”的区别。访客数按浏览器指纹去重同一个用户一天内打开 10 个页面访客数只算 1页面浏览量则算 10。这个口径和百度统计里的 UV/PV 是一致的理解了这两个指标你在判断内容质量时才有依据。跳出率这个指标要谨慎解读如果网站是博客类内容读者读完一篇文章就关掉跳出率高是正常的并不一定代表体验差。更值得关注的是“平均访问时长”和“访问深度”的组合如果平均访问时长很高但跳出率也很高说明读者确实认真看完了内容只是没有继续看下一篇的意愿这时候可以想想页底推荐文章和侧边栏的相关内容设计。2.4 统计数据的时效性和准确性说明很多用户会质疑开源统计项目的数据是否精准尤其会问“umami 的跟踪能 100% 抓到所有访问吗”。客观来说任何基于前端埋点的统计都会有一定偏差因为部分用户会启用广告过滤插件有的甚至 w 直接拦截所有第三方脚本。umami 因为脚本是自托管的和网站同源被拦截的概率相对低不少但也不是零损失。在解读数据时我更关注的是趋势变化而非绝对数值例如对比上周同期流量涨跌、对比不同渠道的转化差距用相对变化来指导决策这样哪怕数据有一些系统性偏差结论依然可靠。3. Beszel 监控服务配置全记录3.1 Beszel 的架构和安装方法Beszel 的安装方式分两部分服务端Hub和客户端Agent。服务端可以直接用官方提供的一条命令行启动也可以放在 Docker 里运行。我个人习惯把 Beszel 服务端和 umami 一起部署在同一台机器上通过两个不同的端口对外提供服务这样整体管理比较方便。客户端的接入有两种模式。一种是二进制模式在目标服务器上下载对应架构的可执行文件然后执行时带上服务端分配的密钥就能完成注册。另一种是 Docker 模式适合被监控的机器本身就跑着 Docker 的场景。两种模式都不需要开放额外的入站端口因为通信是客户端主动向服务端发起的这点和 Zabbix 那种需要被监控端主动装 Agent 并开放端口的模式完全不同。3.2 配置告警规则和通知渠道Beszel 默认的仪表盘已经能实时展示 CPU 使用率、内存占用、网络吞吐和磁盘 IO但这些数据如果只靠肉眼盯盘意义不大真正的作用在于告警。在 Beszel 后台可以设置基于阈值的告警规则比如 CPU 连续 5 分钟超过 90%、磁盘使用率超过 85%、内存剩余低于 500MB 等。告警渠道方面Beszel 支持 Telegram、Discord、Slack、Webhook 等方式。我个人最常用的是 Webhook 方式把告警转发到企业微信机器人或者钉钉群这样手机端能第一时间收到推送。配置 Webhook 时注意格式化字段不同渠道要求的 JSON 结构不一样Beszel 官方文档里给了 Telegram 和 Slack 的模板其他渠道照着改就行。3.3 从监控数据反推页面性能瓶颈这里分享一个实战案例。我的一个博客站点有一段时间页面打开速度特别慢umami 统计后台显示平均访问时长也在逐步下滑很多用户进来就关掉。我第一时间看了 Beszel 的监控曲线CPU 和内存都正常带宽也没有跑满但磁盘 IO 等待时间持续处于高位。顺着这条线索排查下去发现是 Docker 的 overlay2 层日志文件过大造成的性能下降清理了容器日志后问题很快解决。如果没有 Beszel 这套监控数据我很可能先去调 Nginx 配置、改 Redis 缓存折腾一圈才发现问题出在磁盘 IO 这块。所以监控工具的真正价值不只是“服务器挂了通知你”而是帮你把排查范围从“全栈盲猜”缩小到“精准定位”。4. 从零到一的落地实操服务部署与环境配置4.1 前置要求说明实操部分需要准备一台云服务器国内和海外厂商均可主流配置 1 核 1G 就足够跑 umami 和 beszel 全套服务。操作系统推荐 Debian 11 或 Ubuntu 22.04 LTS主要原因是这两个系统的默认内核版本对 Docker 和 Compose 的支持更友好遇到问题时的资料也更多。需要提前安装好的仅一个 Docker Engine 和 Docker Compose 插件注意这里建议直接装 Compose v2 插件版而不是老的 docker-compose 独立命令版因为命令格式和兼容性更省心详细安装步骤可以直接参照 Docker 官方文档这里不重复贴代码。安装完成后建议顺手给服务器配好基础防火墙把非必需端口收起来只留 22、80、443 等必要端口。域名部分需要准备一个解析到这台服务器的域名umami 面板和 Beszel 面板都通过子域名访问这样后续接 HTTPS 证书时会省掉很多麻烦。4.2 部署 umami 的完整过程首先创建专用目录和配置文件mkdir -p /opt/umami cd /opt/umami vi docker-compose.yml配置内容如下services: umami: image: ghcr.io/umami-software/umami:latest ports: - 3000:3000 environment: DATABASE_URL: postgresql://umami:umamidb:5432/umami DATABASE_TYPE: postgresql APP_SECRET: 替换为随机生成的长字符串 depends_on: - db restart: always db: image: postgres:16-alpine environment: POSTGRES_DB: umami POSTGRES_USER: umami POSTGRES_PASSWORD: 替换为高强度密码 volumes: - /opt/umami/data:/var/lib/postgresql/data restart: always执行docker compose up -d启动后打开浏览器访问http://服务器IP:3000就能看到 umami 的初始化界面。这里的APP_SECRET最好用openssl rand -base64 32生成不要直接复制我的示例值。PostgreSQL 的数据目录必须做持久化挂载否则容器重建后统计配置和站点设置全部丢失。第一次进入后台默认用户名是admin密码为umami登录后系统会强制要求修改。接下来创建站点、获取追踪代码、粘贴到前端页面头部整个流程两分钟内可以走完。4.3 部署 Beszel 并接入两台服务器Beszel 服务端我用一条 Docker 命令启动docker run -d --name beszel -p 9527:9527 -v /opt/beszel/data:/beszel/data henrygd/beszel启动成功后访问http://服务器IP:9527创建管理员账号。然后在控制台添加服务器的入口选择对应的平台架构、填入服务器 IP、SSH 端口和认证方式认证方式支持密码和密钥建议生产环境用密钥连接。被监控的服务器上只需要执行官方生成的一段 Agent 启动命令本质上就是下载对应架构的二进制并连接回 Beszel 服务端。命令执行完成后机器会出现在 Beszel 仪表盘列表里后续无需在被监控端做任何守护进程配置。4.4 配置反向代理和 HTTPS 证书直连 IP 加端口的方式只适合本地测试线上环境还是要靠域名加 HTTPS 来保证传输安全。Nginx 反向代理是最常见的方案因为 umami 和 Beszel 都要通过同一个 80/443 端口对外服务用 Nginx 按域名转发到不同后端端口可以简化证书配置和访问控制。给 umami 配置的 Nginx 配置文件示例如下server { listen 80; server_name stats.example.com; location / { proxy_pass http://127.0.0.1:3000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }Beszel 的配置类似监听同一个 80 端口但匹配不同域名转发到 9527 端口即可。Nginx 配置完成后用 certbot 免费申请并自动续期 Let‘s Encrypt 证书apt install certbot python3-certbot-nginx -y certbot --nginx -d stats.example.com -d monitor.example.com执行后证书会自动签发并写入对应的 Nginx server 块之后访问会自动跳转到 HTTPS。4.5 数据备份方案自托管方案里最不能省的就是备份。umami 的数据都存放在 PostgreSQL 里所以我写了一个简单的每日定时任务把数据库内容导出为一个 SQL 文件然后 rsync 到另一台机器上docker exec postgres容器名 pg_dump -U umami umami /backup/umami_$(date %F).sqlBeszel 的配置和数据则直接存在/opt/beszel/data目录下我每天凌晨用 tar 打包一份上传到对象存储整个操作下来不到 5 分钟。数据恢复也很直接umami 用 psql 导入 SQL 文件Beszel 直接解压覆盖目录重启容器一条命令的事。5. 常见问题与排查技巧实录5.1 常见问题速查表问题现象可能原因解决方案统计代码已部署但后台无数据页面脚本被浏览器缓存或代码中网站 ID 不匹配清缓存、检查> 开源组合拳：Umami+Beszel搭建网站统计与服务器监控
很多人做网站最头疼的不是功能开发而是上线之后两眼一抹黑到底有没有人来看看了哪些页面服务器扛不扛得住出问题了怎么第一时间知道针对这些需求我一直在用一套开源组合拳来搞定网站统计用 umami服务器监控用 beszel。这两个都是开源项目一个管业务数据一个管机器状态配合起来基本覆盖了中小站点日常运维的所有核心需求。这篇文章就把我的完整搭建过程和踩坑经验分享出来希望能帮你少走弯路。1. 内容整体设计与思路拆解1.1 为什么网站统计和监控要一起做先说一个常见的误区很多人觉得网站统计和服务器监控是两码事统计是给运营看的监控是给运维看的小站点没必要都装。但实际运营下来你会发现这两个东西是强关联的。最典型的场景就是统计后台显示流量突然暴跌这时候你分不清是用户真的不来了还是服务器挂了导致请求根本没到达。如果只有统计没有监控你得先去登录服务器看进程、看负载、看带宽排查一圈才发现是磁盘满了或者数据库连接数爆了。反过来如果只有监控没有统计服务器一切正常但流量就是上不去你也定位不到是页面问题还是推广渠道问题。所以我的思路很直接统计工具负责回答“网站本身好不好用、有没有人用”监控工具负责回答“服务器撑不撑得住、什么时候会出问题”。两套数据拼在一起才能形成一个相对完整的判断闭环。再来说说为什么选开源方案。商业统计平台虽然接入简单但数据全部过第三方隐私合规上始终是个隐忧而且很多细粒度的事件追踪、自定义指标都藏在付费版里。自己用开源方案数据完全握在自己手里想怎么分析就怎么分析想接什么告警渠道就接什么渠道没有任何功能上的天花板。1.2 核心方案选型umami 和 beszel 分别解决什么问题标题里说的“3分钟搞定”主角其实是 umami。这是一款基于 Node.js 开发的轻量级网站统计分析工具界面清爽部署方式极其简单一条 Docker 命令就能把服务和数据库全部拉起来。它最大的特点是摒弃了传统统计工具那一套复杂的埋点配置你只需要在页面里塞一段几十行的 JavaScript 脚本访问数据就会自动回传。它对隐私也非常友好不依赖 Cookie所以不需要弹窗让用户确认“是否同意被追踪”这在欧洲那个 GDPR 合规环境下特别实用。Beszel 则是配套的服务器监控工具同样开源它和 umami 互补性非常强。Beszel 走的是轻量化路线程序本体就一个几百KB的二进制文件通过 SSH 协议采集目标服务器的 CPU、内存、磁盘、网络、温度等指标。你不需要在被监控的机器上额外安装任何 Agent 程序所有采集工作都通过在管理端发起 SSH 连接来完成这对多服务器环境非常友好也不用担心 Agent 兼容性问题。选型对比上我也补充一个个人结论如果是单站点、个人博客这类轻量需求整体方案中 umami 的轻便性远超 Matomo因为 Matomo 对 PHP 和 MySQL 环境的依赖较重而且不少统计功能绑定其付费插件如果是企业级多种站群或深度销售转化分析可以结合 Matomo 做补充但就我的使用体验来说umami 加自定义事件已经能覆盖绝大多数日常需求。1.3 这套组合的适用场景和边界明确一点这套方案的目标用户是个人站长、中小团队、SaaS 产品初期、博客作者、独立开发者。你要监控的不是几千台机器的集群而是几台到十几台服务器的规模。在这个范围内umami 加 beszel 可以说是体验和成本最为平衡的组合。但是如果你面对的是大规模分布式系统需要监控 Kubernetes 集群的容器编排状态需要做链路追踪、日志聚合分析那还是去用 Prometheus Grafana Loki 这样的全家桶更合适。umami 和 beszel 的设计哲学是“小而美”它们不会试图解决所有问题而是把核心问题解决得足够顺手。理解这个边界你才不会方案选型选到心态爆炸。2. 网站统计实操要点umami 的埋点部署与数据解读2.1 umami 部署的两种方式云端版和自托管版Umami 官方提供了一个在线托管服务 umami.cloud注册账号、创建站点、拿到跟踪代码三步就能完成接入。如果你不想折腾服务器也不想管数据库更新用云端版是最省心的一个月有几万的免费事件额度个人博客的流量完全够用。但既然是开源爱好者我更推荐自己动手部署。自托管的核心优势有两个数据不会经过任何第三方订阅费用为 0而且后期做二次开发、扩展事件上报字段都非常方便。部署方式推荐用 Docker Compose。umami 的官方仓库里提供了一份现成的 docker-compose.yml里面包含 umami 本体和 PostgreSQL 数据库两个服务。如果你正准备做冷备方案也可以把数据库这块替换成外部的 PostgreSQL 实例但初始入门阶段全部用容器化方案是上手成本最低的。2.2 埋点接入和页面代码解读新建一个站点之后umami 会分配一个唯一的网站 ID并生成一段类似下面这样的嵌入代码script async srchttps://your-domain.com/script.js>umami.track(download_click, { file: guide.pdf });第二个参数是自定义负载可以放置任意结构化信息比如商品 ID、点击位置、用户来源渠道等。这些自定义事件都会出现在后台的 Events 面板里配合过滤条件可以做很多精细化的行为分析。2.3 数据解读的常用口径接入之后后台默认展示几个核心指标访客数Unique Visitors、页面浏览量Pageviews、平均访问时长、跳出率、来源渠道和设备分布。这里特别说一下“访客数”和“页面浏览量”的区别。访客数按浏览器指纹去重同一个用户一天内打开 10 个页面访客数只算 1页面浏览量则算 10。这个口径和百度统计里的 UV/PV 是一致的理解了这两个指标你在判断内容质量时才有依据。跳出率这个指标要谨慎解读如果网站是博客类内容读者读完一篇文章就关掉跳出率高是正常的并不一定代表体验差。更值得关注的是“平均访问时长”和“访问深度”的组合如果平均访问时长很高但跳出率也很高说明读者确实认真看完了内容只是没有继续看下一篇的意愿这时候可以想想页底推荐文章和侧边栏的相关内容设计。2.4 统计数据的时效性和准确性说明很多用户会质疑开源统计项目的数据是否精准尤其会问“umami 的跟踪能 100% 抓到所有访问吗”。客观来说任何基于前端埋点的统计都会有一定偏差因为部分用户会启用广告过滤插件有的甚至 w 直接拦截所有第三方脚本。umami 因为脚本是自托管的和网站同源被拦截的概率相对低不少但也不是零损失。在解读数据时我更关注的是趋势变化而非绝对数值例如对比上周同期流量涨跌、对比不同渠道的转化差距用相对变化来指导决策这样哪怕数据有一些系统性偏差结论依然可靠。3. Beszel 监控服务配置全记录3.1 Beszel 的架构和安装方法Beszel 的安装方式分两部分服务端Hub和客户端Agent。服务端可以直接用官方提供的一条命令行启动也可以放在 Docker 里运行。我个人习惯把 Beszel 服务端和 umami 一起部署在同一台机器上通过两个不同的端口对外提供服务这样整体管理比较方便。客户端的接入有两种模式。一种是二进制模式在目标服务器上下载对应架构的可执行文件然后执行时带上服务端分配的密钥就能完成注册。另一种是 Docker 模式适合被监控的机器本身就跑着 Docker 的场景。两种模式都不需要开放额外的入站端口因为通信是客户端主动向服务端发起的这点和 Zabbix 那种需要被监控端主动装 Agent 并开放端口的模式完全不同。3.2 配置告警规则和通知渠道Beszel 默认的仪表盘已经能实时展示 CPU 使用率、内存占用、网络吞吐和磁盘 IO但这些数据如果只靠肉眼盯盘意义不大真正的作用在于告警。在 Beszel 后台可以设置基于阈值的告警规则比如 CPU 连续 5 分钟超过 90%、磁盘使用率超过 85%、内存剩余低于 500MB 等。告警渠道方面Beszel 支持 Telegram、Discord、Slack、Webhook 等方式。我个人最常用的是 Webhook 方式把告警转发到企业微信机器人或者钉钉群这样手机端能第一时间收到推送。配置 Webhook 时注意格式化字段不同渠道要求的 JSON 结构不一样Beszel 官方文档里给了 Telegram 和 Slack 的模板其他渠道照着改就行。3.3 从监控数据反推页面性能瓶颈这里分享一个实战案例。我的一个博客站点有一段时间页面打开速度特别慢umami 统计后台显示平均访问时长也在逐步下滑很多用户进来就关掉。我第一时间看了 Beszel 的监控曲线CPU 和内存都正常带宽也没有跑满但磁盘 IO 等待时间持续处于高位。顺着这条线索排查下去发现是 Docker 的 overlay2 层日志文件过大造成的性能下降清理了容器日志后问题很快解决。如果没有 Beszel 这套监控数据我很可能先去调 Nginx 配置、改 Redis 缓存折腾一圈才发现问题出在磁盘 IO 这块。所以监控工具的真正价值不只是“服务器挂了通知你”而是帮你把排查范围从“全栈盲猜”缩小到“精准定位”。4. 从零到一的落地实操服务部署与环境配置4.1 前置要求说明实操部分需要准备一台云服务器国内和海外厂商均可主流配置 1 核 1G 就足够跑 umami 和 beszel 全套服务。操作系统推荐 Debian 11 或 Ubuntu 22.04 LTS主要原因是这两个系统的默认内核版本对 Docker 和 Compose 的支持更友好遇到问题时的资料也更多。需要提前安装好的仅一个 Docker Engine 和 Docker Compose 插件注意这里建议直接装 Compose v2 插件版而不是老的 docker-compose 独立命令版因为命令格式和兼容性更省心详细安装步骤可以直接参照 Docker 官方文档这里不重复贴代码。安装完成后建议顺手给服务器配好基础防火墙把非必需端口收起来只留 22、80、443 等必要端口。域名部分需要准备一个解析到这台服务器的域名umami 面板和 Beszel 面板都通过子域名访问这样后续接 HTTPS 证书时会省掉很多麻烦。4.2 部署 umami 的完整过程首先创建专用目录和配置文件mkdir -p /opt/umami cd /opt/umami vi docker-compose.yml配置内容如下services: umami: image: ghcr.io/umami-software/umami:latest ports: - 3000:3000 environment: DATABASE_URL: postgresql://umami:umamidb:5432/umami DATABASE_TYPE: postgresql APP_SECRET: 替换为随机生成的长字符串 depends_on: - db restart: always db: image: postgres:16-alpine environment: POSTGRES_DB: umami POSTGRES_USER: umami POSTGRES_PASSWORD: 替换为高强度密码 volumes: - /opt/umami/data:/var/lib/postgresql/data restart: always执行docker compose up -d启动后打开浏览器访问http://服务器IP:3000就能看到 umami 的初始化界面。这里的APP_SECRET最好用openssl rand -base64 32生成不要直接复制我的示例值。PostgreSQL 的数据目录必须做持久化挂载否则容器重建后统计配置和站点设置全部丢失。第一次进入后台默认用户名是admin密码为umami登录后系统会强制要求修改。接下来创建站点、获取追踪代码、粘贴到前端页面头部整个流程两分钟内可以走完。4.3 部署 Beszel 并接入两台服务器Beszel 服务端我用一条 Docker 命令启动docker run -d --name beszel -p 9527:9527 -v /opt/beszel/data:/beszel/data henrygd/beszel启动成功后访问http://服务器IP:9527创建管理员账号。然后在控制台添加服务器的入口选择对应的平台架构、填入服务器 IP、SSH 端口和认证方式认证方式支持密码和密钥建议生产环境用密钥连接。被监控的服务器上只需要执行官方生成的一段 Agent 启动命令本质上就是下载对应架构的二进制并连接回 Beszel 服务端。命令执行完成后机器会出现在 Beszel 仪表盘列表里后续无需在被监控端做任何守护进程配置。4.4 配置反向代理和 HTTPS 证书直连 IP 加端口的方式只适合本地测试线上环境还是要靠域名加 HTTPS 来保证传输安全。Nginx 反向代理是最常见的方案因为 umami 和 Beszel 都要通过同一个 80/443 端口对外服务用 Nginx 按域名转发到不同后端端口可以简化证书配置和访问控制。给 umami 配置的 Nginx 配置文件示例如下server { listen 80; server_name stats.example.com; location / { proxy_pass http://127.0.0.1:3000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }Beszel 的配置类似监听同一个 80 端口但匹配不同域名转发到 9527 端口即可。Nginx 配置完成后用 certbot 免费申请并自动续期 Let‘s Encrypt 证书apt install certbot python3-certbot-nginx -y certbot --nginx -d stats.example.com -d monitor.example.com执行后证书会自动签发并写入对应的 Nginx server 块之后访问会自动跳转到 HTTPS。4.5 数据备份方案自托管方案里最不能省的就是备份。umami 的数据都存放在 PostgreSQL 里所以我写了一个简单的每日定时任务把数据库内容导出为一个 SQL 文件然后 rsync 到另一台机器上docker exec postgres容器名 pg_dump -U umami umami /backup/umami_$(date %F).sqlBeszel 的配置和数据则直接存在/opt/beszel/data目录下我每天凌晨用 tar 打包一份上传到对象存储整个操作下来不到 5 分钟。数据恢复也很直接umami 用 psql 导入 SQL 文件Beszel 直接解压覆盖目录重启容器一条命令的事。5. 常见问题与排查技巧实录5.1 常见问题速查表问题现象可能原因解决方案统计代码已部署但后台无数据页面脚本被浏览器缓存或代码中网站 ID 不匹配清缓存、检查>