为什么我要用 Umami 替代 Matomo，作为我网站的流量监控工具？原因说来也简单，就发生在这个炎热的周日。我偶然发现，Matomo 的 MySQL 数据库居然膨胀到了惊人的 600MB+，而我的主站数据库不过几十兆，这体量差距实在令人震惊。考虑到目前网站流量并不大，Matomo 的“庞大”是在没啥必要，很多功能都用不上。
其实在最初选择自托管统计工具时，我就认真对比过 Umami 和 Matomo。平心而论，后者功能强大得多，即便不依赖任何付费插件，Matomo 的功能性和可扩展性都可以碾压 Umami，特别是实时监控功能，堪称秒级同步。当年我刚搭建好那一套系统时，尽管网站没什么流量，但能实时看到访客的每一步操作，体验还是非常爽的…🤣
当然，那会儿我也顺带评估过百度统计、Microsoft Clarity，甚至对比过宝塔面板附带的流量监控模块——但那玩意儿极其不准，几乎无法使用。综合来看，Matomo 的数据最靠谱，准确性也最高。但现在看来，我觉得看统计也没啥意义，Matomo 那夸张的资源占用就尤为碍眼了。嗯，是该换换了。
我感觉 Umami 会把爬虫的抓取也统计进“访客”数据里。在同一时间段内，百度统计显示的访客数量是 65，结合来源（referrer）分析，这个数字看起来更合理一些。就“真实访客”而言，百度的数据准确性明显更高，此前我用 Matomo 时，统计结果也大致与百度相符。
而现在再对比 Clarity 的录制回放（顺带一提，它现在统计的数据也偏高不少），很多访问停留时间只有两三秒，从页面行为来看，基本可以排除是正常用户访问。综合判断，Umami 的访客数据确实有些虚高，应该是把一部分非人类流量也算进去了。
上图是宝塔后台的流量统计，可以看到，它统计的访问数又高出一个量级——而我这博客，按理说根本不可能有这么高的流量。更离谱的是，它显示的蜘蛛访问只有 1570 次，但人类访客却在早上 8 点之前就已经超过 3700 次……照这个算法，我岂不是已经成了“大站”了？
当然，不是的，不是的。结合我之前写的「SYN Flood 攻击防范：自动化脚本的实现与分享」那篇文章的分析，我强烈怀疑这些所谓的“访客”中，大量是嗅探器流量、甚至是 AI 蜘蛛的爬取请求。这些工具不像传统搜索引擎蜘蛛那样会规范标识自己，更容易被统计系统误判为“真实用户”。
看来又要把我的 ipset 防御套装重新拿出来用了……控制访问、限制并发、过滤异常 IP，该上的都得上…还有 EdgeOne。
1. Umami 的安装方式
在决定使用 Umami 之前，我也花了一些时间研究它的部署方式。作为一个轻量级的开源项目，Umami 提供了多种安装方式，既适合技术小白快速上手，也支持具备一定运维能力的用户进行更灵活的自定义部署。
Umami 是一个基于 Node.js 与 PostgreSQL 构建的现代化网页分析工具。它采用服务端渲染架构（Next.js），前后端集成一体，因此部署时并不需要像 Matomo 那样额外配置 PHP 环境或其他繁杂组件。默认情况下，Umami 支持连接 PostgreSQL 和 MySQL 两种数据库，但官方更推荐使用 PostgreSQL，稳定性和性能表现更好。
1.1 直接源码部署（Node.js + Nginx + 数据库）
这种方式适合对 Node.js 环境和 Linux 运维有一定经验的用户。部署过程需要你：
- 安装 Node.js（建议使用 LTS 版本）
- 安装 PostgreSQL（或 MySQL，但不推荐）
- 克隆 Umami 的源码仓库
- 执行
npm install安装依赖 - 修改
.env文件，配置数据库连接信息 - 运行
npm run build和npm start启动服务 - 配置 Nginx 反向代理到 Umami 的端口，比如默认是 3000
- 设置 SSL（如使用 Let's Encrypt）和防火墙策略等
整个过程和部署一个完整的 Node.js Web 应用类似，比较灵活，但也意味着维护成本更高，出错的可能性也更大。
1.2 使用 Docker 安装 Umami（推荐方式）
相比直接部署，使用 Docker 是更加推荐的方式，尤其适合已经使用宝塔面板或在服务器上有 Docker 环境的用户。Umami 官方维护了一个非常清晰的 docker-compose.yml，可以一键拉起前端、后端、数据库三大组件。
部署步骤大致如下：
- 安装 Docker 和 Docker Compose（宝塔面板可通过插件安装）
- 克隆 Umami 官方仓库，进入
umami/docker目录 - 编辑
docker-compose.yml（如有自定义需求，比如更换端口、修改数据库密码） - 执行
docker-compose up -d启动容器 - 浏览器访问
http://your-server-ip:3000，默认用户名密码为admin / umami - 后续可通过配置 Nginx 或宝塔反向代理，实现绑定域名、开启 HTTPS
使用 Docker 的好处在于省去了大量环境配置的麻烦，一切都由容器完成隔离与管理，同时也便于日后升级和迁移。你只需关注数据备份和服务状态即可，非常适合个人站长或轻量级需求场景。
2. 我是怎么安装的？
好吧！我特么两种方式都试了，而且真是折腾得够呛……现在就让我慢慢讲来。当时我想着，直接运行在系统层面可能性能更好一点，数据也更可控，所以就傻乎乎地选择了源码部署，一通编译、排错，看起来“高级”又“自由”。而官方文档呢？只写了几行命令，看上去轻轻松松，简简单单，仿佛谁都能搞定……然而，事实完全不是那么回事。
2.1 编译安装与磁盘危机
真正的苦难从这一步开始。我部署用的是 MySQL 数据库，打算继续用稳定运行的 5.6.6，本以为没问题，库都建好了，连环境变量也配置妥当了。结果在最后初始化时系统突然报错：必须使用 MySQL 5.7 或以上版本。我瞬间傻眼，这时已经折腾了小半天，但我晓得数据库可不要轻易动……所以直接放弃。
回滚恢复原来的 Matomo 数据库得了。然后刚才编译 Node.js、安装 Yarn 的过程中消耗了接近 3GB 的空间，加上现在导入、解压备份数据库等操作，直接把系统盘干到崩溃边缘，MySQL 直接被卡死，启动不了，网站彻底挂了！
我真没夸张，系统盘的使用率飙到了 99%，几乎一点空隙都没剩。没办法，我只好紧急清理系统日志、Nginx 日志之类的垃圾，勉强腾出了 2GB，让 MySQL 勉强能启动，好歹先把网站恢复再说。
接下来我继续清理，把大约 5GB 的资料文档转移到了挂载的数据盘，同时也顺手删掉了不少陈旧无用的文件。即便如此，数据盘的使用率依然高达 81%。我没停下，又开始清理系统里的各种旧日志、不再使用的软件残留。在此期间，还折腾了一番 Syncthing 的配置文件，为了迁移同步目录的真实路径，一路翻文件、改配置……😂
但这些努力总算没白费。一番操作下来，系统盘的使用率终于降到了 64%，算是给自己的一点小鼓励。虽然这一上午折腾得精疲力尽，但看到系统恢复如初、空间变得清爽，心情也随之明朗了不少。想到这儿，我下定决心：既然都折腾到这份上了，那就干脆装到底——Umami，我非装不可！
2.2 升级数据库遇到的波折
接下来，我开始着手升级 MySQL 数据库。首先是备份数据，然后制作了磁盘快照（事实证明：磁盘快照才是最牛逼的备份方式，真不是开玩笑）。因为宝塔面板中还存在数据库列表，系统提示无法直接卸载，只能手动 rm -rf 删除旧版本，我照做了。然后开始编译新版本的 MySQL。你可能会问：为啥非得编译？——因为宝塔提示说“编译版更稳定，性能稍好一点”，我当时就信了……这大概是强迫症吧！
这段时间正好是中午，我边吃饭边等编译，差不多一个多小时后编译完成，继续开干。第一步自然是恢复各个站点的数据库。数据是能恢复的，但 WordPress 死活连不上数据库。我一时搞不清楚原因，只觉得可能是编译方式有问题、数据库配置错了，再加上中途还被人打扰，我就脑袋一热，直接点了回滚磁盘快照。结果又是一小时编译重来一遍……
等我冷静下来才发现问题的根本其实非常“低级”——宝塔面板中保存的数据库信息（并非数据本身，而是数据库名称、用户名、密码等）在新版 MySQL 中并没有同步迁移过去。于是我按之前的记录，手动新建了一模一样的数据库和用户，并导入备份文件，一切立刻恢复如初。
说来也怪，不知道是不是心理作用，MySQL 升级到 5.7.4 之后，网站整体感觉确实比之前顺畅了一点，响应也快了些。那一瞬间我都忍不住笑了出来，真的是笑中带泪啊 🤣🤣🤣
我重新鼓起劲，继续初始化 Umami。结果，意想不到的事又来了：系统提示数据库需为 MySQL 8.0 以上版本。我当场破防：刚才还要求必须是 5.7，结果我费了老半天终于升级完，现在又要更高版本？！我特么……
我断然拒绝再次升级。一来这活太累太耗时间，二来我的这台 2C4G 的 ECS 本身性能就有限，跑 MySQL 8 也未必合适。至此，我再次萌生了放弃的念头……但事已至此，岂能轻言放弃？搞！继续搞！搞到天黑也要搞！💪💪💪
2.3 使用 Docker compose 安装
大家都知道，用 Docker 安装应该是最省心的方式之一。理论上是这样没错，但实际操作中我又踩雷了！由于众所周知的原因，在大陆访问 Docker 官方资源经常会遇到问题。因此，网上流传着各种加速镜像，我自己也早就替换成了阿里云分配的官方镜像源，按理说拉取镜像不该有什么问题。
但不知道为什么，Umami 所需的镜像就是死活拉不下来。我试了多个网上推荐的镜像源，不是 404 就是 TLS 错误（最近 GFW 的封锁简直是史诗级加强）。甚至 ChatGPT 都建议我去阿里云自建一个镜像仓库再推送，这操作量太离谱了吧，我哪有这个精力！
折腾了半天，主程序镜像我总算拉下来了，但 PostgreSQL 镜像还没搞定。我当时灵机一动，想着能不能复用我部署 Awesome TTRSS 时的 PostgreSQL 容器，毕竟这样还能省点磁盘和内存资源。试了试，确实有点复杂，特别是数据库初始化和端口映射略显混乱，后期运维估计更麻烦，最后我决定放弃这个“优化”。
最终我想到一个曲线救国的办法：借助远端的 RackNerd 先拉取镜像，然后打包，再通过 SFTP 下载到本地，再上传到阿里云这边，使用 docker load 加载进本地 Docker。最后，再执行 docker-compose up -d，Umami 总算装上了！
测试了一下，Umami 启动速度确实很快。接下来绑定域名、配置反向代理啥的全是熟悉的流程，不在话下。
3. 最后总结
Umami 这个小程序，其实没啥特别可讲的，简单、清爽、部署不复杂，官方还提供了在线 demo，足够让人快速了解它的界面和功能。要比功能丰富，当然远远比不过 Matomo，毕竟后者可是敢和 Google Analytics 对标的产品。
我后期可能会考虑把百度统计也下掉（是的，其实我一直用得最多的是百度统计，因为说实话，我觉得它的数据还挺准的）。至于更精细的用户行为分析，我打算继续搭配使用 Microsoft Clarity，毕竟它的可视化回放和热力图真的很香。
最后我想说的是——能跑就先用着，别瞎几把折腾，太费神了！尤其是像我这样子一搞就是一整天，真的是心力交瘁。工具是用来辅助工作的，不是拿来耗尽自己精力的。折腾适可而止，轻量够用就行……
JYC统计，付费的，真正看得到实时在线的访客在干啥，哈哈。