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

HowieHz

2024-03-25

开源网站-Github 领域-DevOps 🌍简体中文

109

现象

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 出来个新版本都会构建的，除非哪天官方提供可以直接降低这里刷新延迟的选项，那笔者就会删掉这个仓库
如果没跟上新版本，可以发个邮件给站长

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

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

坑:

记得去查看个人全部仓库的页面-package-你的项目-package settings-里允许项目action提交镜像，不然会 403error
记得要把镜像改为 public，（在上一步的时候就顺手解决，不然等下 pull image "ghcr.io..." 会报错 Unauthorized）
多吉云，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
翻译一下就是：最近五分钟内的独立访问人数

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

结语

解决问题了，舒服