搭建个人博客之后，除了把网站跑起来，我还会自然地产生一个问题：到底有没有人访问我的网站？
比如一篇文章发出去之后，有没有人点开？访问来源是搜索引擎、社交平台，还是直接输入域名？大家更常看哪些页面？手机访问多，还是电脑访问多？
这些问题靠服务器日志当然也能分析，但服务器日志太原始了，不适合日常查看。所以我给博客接入了一个访问统计工具：Umami
Umami 是什么
Umami 是一个开源的网站访问统计工具，可以理解成一个更轻量、更注重隐私的 Google Analytics 替代品。
它的作用是统计网站访问数据，比如：
- 页面浏览量
- 访客数量
- 实时访客
- 访问来源
- 访问设备
- 浏览器
- 操作系统
- 国家和地区
- 热门页面
- 自定义事件
对个人博客来说，这些信息已经足够用了。
我不需要特别复杂的商业分析，也不需要广告转化漏斗。我只是想知道：我的博客有没有人看，大家主要看哪些内容，访问大概来自哪里。
为什么不用服务器日志
服务器日志能记录每一次请求，比如访问了哪个 URL、IP 是什么、状态码是多少。但它的问题是太底层了。
一次网页访问可能会产生很多请求：HTML、CSS、JS、图片、字体、接口都可能被记录进去。如果直接看 Nginx 日志，很难快速知道一篇文章到底被多少人看过。
而 Umami 做的是偏产品视角的访问统计。它关心的是页面访问和用户行为，不是每一个静态资源请求。
简单来说：
服务器日志：适合排查问题
Umami：适合观察访问情况
这两者不是互相替代，而是用途不同。
Umami 的工作原理
Umami 的接入方式很简单。它会给每个网站生成一段统计脚本，大概长这样：
<script
defer
src="https://umami.example.com/script.js"
data-website-id="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx">
</script>把这段代码放到网站页面里之后，用户访问页面时，浏览器会加载这个脚本。脚本执行后，会把当前页面地址、来源、设备信息等统计数据发送到 Umami 服务端。
整个流程大概是这样：
用户访问博客页面
↓
页面加载 Umami 统计脚本
↓
脚本收集页面访问数据
↓
发送到 Umami 服务端
↓
Umami 写入数据库
↓
后台看统计报表所以 Umami 统计的前提是：页面里必须成功加载这段统计脚本。
如果某个页面没有注入脚本，或者脚本被浏览器插件拦截，那这次访问就不会被 Umami 记录。
技术架构
Umami 本身是一个 Web 应用，整体架构比较清晰：
浏览器统计脚本
↓
Umami Web 服务
↓
数据库
↓
统计后台前端页面负责展示统计面板，后端负责接收访问事件、处理数据、查询报表，数据库负责保存访问记录和网站配置。
常见自部署方案一般会包含两个核心部分：
Umami 应用容器
数据库容器数据库通常使用 PostgreSQL，也可以根据版本和部署方式选择其他支持的数据库。
如果部署在自己的服务器上，常见结构会像这样：
Nginx / 反向代理
↓
Umami 服务
↓
PostgreSQL 数据库再给 Umami 绑定一个子域名，比如：
umami.lovexfan.com这样以后就可以通过这个地址进入统计后台，也可以通过这个地址加载统计脚本。
技术栈
Umami 使用的是比较典型的现代 Web 技术栈。
它主要涉及：
Node.js
Next.js
React
Prisma
PostgreSQL / MySQL
Docker
JavaScript / TypeScript
如果用 Docker 部署，维护起来会比较方便。应用、数据库、环境变量都可以通过 docker-compose.yml 管理。
对我这种个人站长来说，Docker 部署的好处是清晰：Umami 是一个独立服务，不会和 Halo 主站混在一起。后续升级、迁移、备份也更容易控制。
它能统计哪些数据
Umami 后台里比较常看的数据有几个。
第一个是访问量。它会展示页面浏览量、访客数、访问次数等指标。这样我可以知道博客整体有没有人在看。
第二个是热门页面。这个很适合博客场景。我可以看到哪些文章访问最多，哪些页面基本没人看。后续写文章时，也能大概判断读者更关心什么内容。
第三个是访问来源。比如访客是从搜索引擎进来的，还是从别的网站链接进来的，或者是直接访问域名。
第四个是设备和浏览器。它会展示访客使用的是手机、电脑，浏览器是 Chrome、Safari 还是 Edge，操作系统是 Windows、iOS、Android 等。
第五个是实时访客。这个功能比较直观，可以看到当前有没有人正在访问网站。
效果展示
和 Uptime Kuma 的区别
我之前也部署了 Uptime Kuma，但它和 Umami 不是一类东西。
Uptime Kuma 是用来监控网站是否正常运行的。它会定时请求我的网站，检查网站有没有挂，响应速度是多少，状态码是否正常。
Umami 是用来统计真实用户访问的。它关心的是谁访问了哪些页面、访问来源是什么、热门文章是哪几篇。
可以简单理解成：
Uptime Kuma：网站活着吗？
Umami：网站有没有人看？所以这两个工具是互补关系。
Uptime Kuma 负责可用性监控，Umami 负责访问数据统计。一个偏运维，一个偏内容分析。
为什么我选择 Umami
我选择 Umami 主要有几个原因。
第一，它开源，可以自部署。数据存在自己的服务器和数据库里，不完全依赖第三方平台。
第二，它界面比较简洁。对个人博客来说，我不需要太重的商业分析系统，Umami 的报表刚好够用。
第三，它相对注重隐私。相比一些传统统计工具，Umami 默认更轻量，也更适合个人网站。
第四，它接入简单。只需要在网站里注入一段脚本，就可以开始统计访问数据。
第五，它适合和 Halo 这类博客系统配合。只要主题或后台支持代码注入，就可以把统计脚本放到全站页面里。
使用时需要注意什么
Umami 不是部署上去就会自动知道网站流量的。
它必须依赖统计脚本。只有用户访问的页面加载了 Umami 脚本，Umami 才能记录到这次访问。
所以如果后台一直显示 0，通常要检查几个地方：
网站页面里有没有成功注入统计脚本。
data-website-id是否填对。script.js地址是否能正常访问。浏览器控制台有没有请求报错。
是否被广告拦截插件拦截。
Umami 服务端和数据库是否正常运行。
反向代理是否正确转发了请求。
另外，Umami 只能统计接入之后的数据。它不会自动补全历史访问量。也就是说，在接入脚本之前发生的访问，不会出现在 Umami 后台里。
还有一点，Umami 统计的是前端脚本触发的访问，不等于服务器收到的全部请求。爬虫、接口请求、图片请求、被拦截脚本的访问，都可能不会体现在 Umami 里。
所以 Umami 的数据更适合用来看趋势，而不是当成绝对精确的服务器请求数量。
在博客里的作用
对我的博客来说，Umami 最大的作用是让我知道内容有没有被看到。
比如我写技术文章、建站记录、日常分享之后，可以通过 Umami 看：
哪篇文章访问多
访问主要来自哪里
移动端用户多不多
搜索引擎有没有带来流量
最近网站访问趋势怎么样这些数据可以帮助我调整博客内容方向。
如果某些技术文章访问比较多，说明这类内容对别人有帮助。
如果某些页面几乎没人访问，就可以考虑优化标题、导航或者内容质量。
如果移动端访问很多，就要更重视手机端阅读体验。
总结
Umami 对个人博客来说，是一个很合适的访问统计工具。
它不负责监控网站是否宕机，也不负责提升网站速度。它的核心价值是告诉我：我的网站有没有人访问，用户主要看了什么，从哪里来，用什么设备访问。
我的博客现在大概是这样的分工：
Halo：负责文章内容
CloudFlare-ImgBed：负责图片托管
Uptime Kuma：负责可用性监控
Umami：负责访问统计这样每个工具负责一件事，结构会比较清晰。
对个人站长来说，Umami 不是必须品，但它确实能让博客从“自己写给自己看”，慢慢变成一个可以观察、可以优化、可以持续运营的网站。