本站在允许 JavaScript 运行的环境下浏览效果更佳


解决 umami api 延迟问题(如何修改开源项目代码并构建 docker 镜像-以 umami 为例)

现象

umami版本为 v2.10.2
如果未来版本依然没有更改的话那这个问题应该还是存在

解决-umami-api延迟问题-umami-api文档.png

当使用 GET /api/websites/{websiteId}/active 这个 API 的时候,发现有至少 1 分钟以上的延迟,经过一个简单的测试脚本,发现本地刷新就存在延迟。

解决过程的大纲

笔者向项目提出了 issue

解决-umami-api延迟问题-提出的issue.png

项目的管理人员建议笔者修改 /src/components/metrics/ActiveUsers.tsx 来解决这个问题

解决-umami-api延迟问题-需要修改的代码.png

可以看到这是需要修改的地方,默认的刷新时间是 60 秒

那么解决问题的过程就很明了了,自己构建个新的

如果你懒得折腾,那就直接用笔者的构建完成的就好了
docker pull ghcr.io/howiehz/umami:postgresql-latest
docker pull ghcr.io/howiehz/umami:mysql-latest

因为笔者要自用,所以每次 tag 出来个新版本都会构建的,除非哪天官方提供可以直接降低这里刷新延迟的选项,那笔者就会删掉这个仓库
如果没跟上新版本,可以发个邮件给站长

省流版解决问题流程,如果要解决这个问题直接看这个列表就好了,下文是笔者解决问题的过程详细记录

  1. fork 项目
  2. 修改代码
  3. 利用项目的 github action 自动构建镜像
  4. docker 拉取位于 github package 的镜像
  5. 替换原来 docker-compose 内的镜像地址,再重新部署 Umami
  6. 检查一路上可能导致延迟的东西

坑:

  1. 记得去查看个人全部仓库的页面-package-你的项目-package settings-里允许项目action提交镜像,不然会 403error
  2. 记得要把镜像改为 public,(在上一步的时候就顺手解决,不然等下 pull image "ghcr.io..." 会报错 Unauthorized)
  3. 多吉云,cloudflare cdn 缓存时间不会影响,1panel 反代缓存需要关闭

碎碎念:踩的坑不算多也不算少,坑1, 2的解决过程都放在在启动action前,请先......章节里了,求助万能的群友也没法,最后搜索+摸索搞出来了,卡了几个小时(时间都花在尝试各种token上了,还是没用,以为是权限问题,结果是权限问题)。如果是第一次用gh的这功能,可能会遇到,特别是遇到前一天晚上不需要这些设置过程,玄学的直接构建成功的情况下(哭)
这构建一次接近20min,真的折磨人

docker pull image ghcr.io... Unauthorized不是令牌问题,而是 package 可见性问题。
action push package 403 不是 token 问题,而是 package action 是否运行编辑的问题。
详情请看在启动action前,请先......章节

fork项目

解决-umami-api延迟问题-fork项目.png

解决-umami-api延迟问题-fork项目-创建fork.png

基本操作,无需多言

修改代码

在你创建的项目网页后直接加上 edit/master/src/components/metrics/ActiveUsers.tsx 即可直接跳转编辑(未来版本可能有修改,请以最新版本为准,如文章未及时更新,可发邮件联系站长)

例:笔者创建仓库地址为 https://github.com/HowieHz/umami/,直接进入https://github.com/HowieHz/umami/edit/master/src/components/metrics/ActiveUsers.tsx

解决-umami-api延迟问题-修改文件.png

把圈 1 的地方改为你需要的秒数,单位是毫秒,默认是60000就是 60 秒,笔者更改为1000即为 1 秒。
修改完成后点击绿色的 Commit changes... 按钮

解决-umami-api延迟问题-修改文件-提交commit.png

弹出的页面再点击Commit changes即可完成提交

在启动action前,请先......

之前构建的时候一切顺利,在笔者要写这篇教程的时候重新拉取仓库然后构建,就会反复报403错误
翻了半天终于找到了这个解决方案
原讨论链接:Random 403 errors when pushing to GHCR · Issue #463 · docker/build-push-action (github.com)

解决-umami-api延迟问题-解决action403问题.png

按照revolunet (Julien Bouquillon)大神提供的地址就能进入设置页面

https://github.com/orgs/[XXX]/packages/container/[YYY]/settings

按照上面的地址,把[xxx]换成你的用户名,[YYY]换成项目名
比如笔者fork之后,仓库是HowieHz/umami,
那笔者就进入https://github.com/orgs/HowieHz/packages/container/umami/settings

解决-umami-api延迟问题-解决action403问题-2.png

再按照onedr0p图片中标记的,先Add Repository,把你仓库加上,然后把规则选为Write或者Admin

顺便在下面把package可见性改为Public不然等下pull image "ghcr.io..."会报错Unauthorized

解决-umami-api延迟问题-解决无法pull问题.png

解决-umami-api延迟问题-解决无法pull问题-2.png

利用项目action自动构建镜像

解决-umami-api延迟问题-修改好文件-进入action.png

解决-umami-api延迟问题-允许使用action.png

修改好直接点击Actions,会出现一个让你启用项目Action的提示,直接点击绿色大按钮进入下一步

解决-umami-api延迟问题-action页面.png

进入此页面后我们选择左侧的Create docker images (manual)

解决-umami-api延迟问题-运行action.png

之后选择Run workflow,在Version随便填入一个你心仪的版本号,之后点击下面绿色的Run workflow
刷新网页后会出现创建的workflow,点这个workflow的标题进入查看详情

解决-umami-api延迟问题-等待action运行.png

解决-umami-api延迟问题-等待action运行2.png

点击左边Jobs下面的项目,如果你用的是mysql就点后面括号mysql的,如果是postgresql的就点后面括号postgresql

解决-umami-api延迟问题-等待action运行3.png

等待第三步变成√就好了,第四步上传到docker.io注定是会失败的,因为没进行配置,如果有需要可以进行配置

如果觉得最后总体任务是X很烦人,那可以先去.github/workflows/cd-manual.yml把提交到docker的这一段删了

解决-umami-api延迟问题-删除多余的工作流.png

最后就是全绿完成构建了,可以看到构建时间大概需要18min

解决-umami-api延迟问题-完成action构建png.png

docker拉取位于github package的镜像

返回你项目的主页,你会在release下看到package,点进去

解决-umami-api延迟问题-package寻找.png

下面蓝色的标签都可以点,进入对应版本,有对应的镜像的拉取指令可以直接复制

没特殊需求直接用下面的指令拉取就好了
docker pull ghcr.io/[用户名]/[仓库名]:postgresql-[构建时填的版本号]
docker pull ghcr.io/[用户名]/[仓库名]:mysql-[构建时填的版本号]
笔者的构建
docker pull ghcr.io/howiehz/umami:postgresql-2.10.2
docker pull ghcr.io/howiehz/umami:mysql-2.10.2

解决-umami-api延迟问题-package界面.png

比如按照下面的步骤,就能找到postgresql专适用于不同平台的拉取指令

解决-umami-api延迟问题-package界面-2.png

解决-umami-api延迟问题-package界面-3.png

解决-umami-api延迟问题-package界面-4.png

重新部署umami

笔者使用1panel部署umami,所以直接进入编排修改就好了

解决-umami-api延迟问题-1panel重新部署.png

修改image:后面的字符为上一步docker pull后面的字符就可以了
建议先拉取镜像再在这里修改,这样就没有后台下载的过程,直接部署的比较快
修改完点击确认,新的镜像就已经在部署了

解决-umami-api延迟问题-1panel重新部署-2.png

检查一路上可能导致延迟的东西

cdn相关不论缓存多久都不影响

1panel这个反向代理里面的缓存需要关掉

解决-umami-api延迟问题-检查1panel延迟.png

1panel的反向代理里面的缓存开了1s都会导致玄学的延迟,之前的相当于白折腾,所以不论如何都要关掉。如下图(u1检测公网,u3检测内网),缓存设置为1s。u3变成0了,u1还是1。缓存关闭再开启,u1神奇的从0变成了1,按照缓存过期的说法,那也应该是0才对。(1panel版本:v1.10.2-lts

解决-umami-api延迟问题-1panel缓存测试.png

网站拉取api的js代码也要记得缩短拉取时间,笔者设置的是5s

检测成果的时候到了

笔者用python写了段检测代码,可以试试

第一步,获取token,下面代码三处[]内的内容替换后执行

import requests
import json
url = "[ 你的umami网站,要带https:// ]/api/auth/login"
requestData={
    "username": "[你的账号]",
    "password": "[你的登录密码]"
}
header = {
            "content-type": "application/json",
        }
res = requests.post(url=url, data=json.dumps(requestData), headers=header)
print(res.text)

输出如图

解决-umami-api延迟问题-输出token.png

红色涂抹的地方我们不用在意,重点关注第一段"token" :后第一段引号内的内容,复制下来
替换下面这段代码的"Authorization": "Bearer {你的token}" 注意:Bearer和你的token中要间隔一个空格
把其余部分的{}替换掉,就可以运行代码了

import requests
import json
import time
url = "{外网umami完整地址}/api/websites/{网站的id}/active"
url3 = "{内网umami直连完整地址}/api/websites/{网站的id}/active"
header={
"Accept": "application/json",
"Authorization": "Bearer {你的token}"
}
while True:
res = requests.get(url=url, data=json.dumps(data), headers=header)
print("u1"+res.text)
res = requests.get(url=url3, data=json.dumps(data), headers=header)
print("u3"+res.text)
time.sleep(0.5)

运行上面这段程序的时候,打开一个浏览器,进入你的网站,然后用手机进入你的网站
输出的u1和u3后面的数字应该同时变化才是最好的,如果u3变化了,u1还迟迟没有变化。那就要检查下网络速度了,或者是否有潜在的其他延迟来源

像下图u1和u3变化几乎同时,那就没问题

解决-umami-api延迟问题-检测结果.png

解决-umami-api延迟问题-检测结果2.png

你问为什么访问人数就立马上升,但是人离开人数还不下降呢
让我们重新看看官方文档的说明

解决-umami-api延迟问题-官方文档2.png

我们可以看到官方文档的原话就是Number of unique visitors within the last 5 minutes
翻译一下就是:最近五分钟内的独立访问人数

如果要改成当下的即时人数,那还需要进一步修改,但这里就已经满足笔者需求了,所以就不进行下一步修改了

结语

解决问题了,舒服