从开始写博客，我一直使用 Umami 作为我的网站统计工具。
这款开源、轻量的统计工具，凭借其简洁的界面、准确的数据和开源的特性，成为了许多网站管理员和开发者的首选。然而，随着博客的流量逐渐增加，尤其是在 Umami 更新到 v2.11.0 之后，我遇到了一些问题，尤其是 实时数据滞后 变得明显，十分影响体验。
在这篇文章中，我将详细讨论我在使用 Umami 时遇到的问题、我的解决方案以及对新版本的看法。
一、为什么选择 Umami 作为网站统计工具？
最初，Umami 的简单性和轻量级的特性吸引了我。在我的旧服务器上，配置较低（1C1G）的情况下，Umami 能够应对大部分流量并准确提供基本的数据分析。随着流量逐渐增加，Umami 依然能满足我的需求。
然而，随着时间推移，我注意到在查询访问历史数据时，服务器的 CPU 使用率达到 100%，且等待时间明显增加，有时还会导致页面错误显示。很明显由于流量和数据量增大，服务器负载过高，影响了数据统计和展示速度。
下图是原服务器通过自助升级双核处理器后，依旧出现CPU满载导致的错误显示。
二、硬件升级
在意识到硬件性能不足时，我决定升级服务器。从最初的一台配置较低的 1C1G 服务器，我迁移到了 Netcup ARM 2000 G11 服务器，其配置如下：
- 10 vCore (ARM64)
- 16 GB RAM
- 512 GB NVMe
这个配置，应该不可能出现上述问题了吧。当然，单纯为了 Umami 而购买这么一台配置较高的服务器大家可能会说简直是暴殄天物，好吧，那就多部署一些 docker 项目玩玩。
三、遇到的新问题：Umami 实时数据滞后
然而，当我将 Umami 升级到最新版本 v2.15.1 后，遇到了一个新的问题：实时统计数据滞后。具体表现如下：
以下两张图片是晚上10:15 分截自兔哥博客 Umami 实时访问数据日志。其中第一张图片版本号为 v2.10.2，第二张图是截止 2024-12-30 发布的最新 v2.15.1 版本。
在统计日志页面，我发现新版本实时数据的延迟时间变长，通常滞后 10 到 20 分钟。即便流量峰值不大，实时数据也无法即时反映，且有时延迟甚至更久，影响了对实时流量的监控。
诚然新版本确实带来很多实用性的功能，而且根据开发者介绍数据也更加准确。但目前出现的问题，我个人很难继续使用。
v2.10.2 是最后一个功能较为简洁的版本， v2.11.0 之后加入了很多新的功能。
出现上述情况，起初我以为是服务器或其它配置问题导致。查询该项目 GitHub 问题反馈：实时数据滞后 ~20 分钟，发现遇到该问题的人挺多的。奇怪的是滞后问题也不一定 100% 出现。
四、新版本的数据准确性与问题
关于新版本，还有一个我不是很理解的地方：旧版本中如果一个访客访问多个页面，会以比较浅的颜色作为标识，且经过实测准确率较高。但新版本，当我以访客初次访问页面是就是深色，访问多个页面时同样时深色显示，给人的感觉就像是新的访客。
从图中上面的统计数据也可以看出，在这段时间内旧版本统计的访客仅有 76 人，而新版本统计的访客达 125 人，这 125 人当中肯定将其一人访问多个页面也视为新的访客。
虽然实时统计有较大差别，但在概览页面，似乎又显示正常，意思是新版本并没有将单一访客访问的多个页面也视为新的访客。
这点确实不能理解，还请明白的前辈们指点一下。
五、回退到旧版本：稳定解决实时数据滞后
为了恢复正常的统计效果，我决定回退到 Umami v2.10.2 版本，这是最后一个在实时数据处理上表现比较稳定的版本。通过找到旧版本的 docker-compose.yml 文件并重新部署，问题得到了有效解决。
services:
umami:
image: ghcr.io/umami-software/umami:postgresql-v2.10.2
ports:
- "3000:3000"
environment:
DATABASE_URL: postgresql://umami:umami@db:5432/umami
DATABASE_TYPE: postgresql
APP_SECRET: VkWvdZgxUQeUgnjT
TRACKER_SCRIPT_NAME: uuzinet
depends_on:
db:
condition: service_healthy
init: true
restart: always
healthcheck:
test: ["CMD-SHELL", "curl http://localhost:3000/api/heartbeat"]
interval: 5s
timeout: 5s
retries: 5
db:
image: postgres:15-alpine
environment:
POSTGRES_DB: umami
POSTGRES_USER: umami
POSTGRES_PASSWORD: umami
volumes:
- umami-db-data:/var/lib/postgresql/data
restart: always
healthcheck:
test: ["CMD-SHELL", "pg_isready -U $${POSTGRES_USER} -d $${POSTGRES_DB}"]
interval: 5s
timeout: 5s
retries: 5
volumes:
umami-db-data:- 稳定性恢复： 回到 v2.10.2 后，实时统计数据准确性恢复，数据查询与页面加载也变得更加流畅。
- 性能无明显问题： 在新的高性能服务器上，v2.10.2 的运行效率与准确性得到了保障。
虽然回退到旧版本解决了实时统计滞后问题，但 新版本的功能和数据准确性依然值得关注，我也希望开发者能在未来的更新中解决这些性能和数据处理上的问题。
六、总结与建议
对于那些使用 Umami 的网站管理员和开发者，我的经验总结如下：
- 新版本带来了更高的功能和数据准确性，但实时数据滞后问题较为明显。 如果对实时统计要求较高，可能需要回退到旧版本或等待未来的修复。
- 硬件升级和优化依然是解决高流量网站统计瓶颈的有效手段。 配置更高的服务器和增加内存、存储可以显著提高网站数据处理的效率。
通过这个问题的解决，我不仅提高了对 Umami 使用的理解，也帮助我的博客恢复了稳定、准确的流量统计。如果你也遇到了类似问题，不妨参考我的方法，尝试回退到稳定版本，或持续关注开发者对该工具的优化进展。
本文作者：兔哥
本文标题：网站统计工具 Umami 新版本实时统计数据滞后
本文链接：https://uuzi.net/umami-data-delay
本文标签：Umami,统计工具,网站统计,更新,数据
发布日期：2024年12月30日
更新日期：2024年12月30日
版权声明：兔哥原创内容，版权所有人为本网站作者，请勿转载，违者必究！
免责声明：文中如涉及第三方资源，均来自互联网，仅供学习研究，禁止商业使用，如有侵权，联系24小时内删除！
