- 我的帖子已经打上 开源推广 标签： 是
- 我的开源项目完整开源，无未开源部分： 是
- 我的开源项目已链接认可 LINUX DO 社区： 是
- 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是
- 以上选择我承诺是永久有效的，接受社区和佬友监督： 是
以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出
节前开源了第一版的 CPA 使用统计和 Codex 账号巡查，但核动力作者又更新了一个大的，后续版本将完全移除使用统计，看到不少佬在找代替方案，所以假期抽空搞了一个新的版本解决这个问题。
【5月3日更新】解决 CPA 移除使用统计方法：CPA-Manager，支持请求监控统计和 codex 账号巡检
开发调优
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 5 月 3…
有个前置问题大家可能比较关心为什么现在需要一个完整服务，而不是只配置一个面板地址？
以前管理面板本质上是一个静态 HTML 页面，CPA 把它下载下来并托管到 /management.html，浏览器直接访问 CPA 的 Management API 就能完成大部分管理操作。
但请求监控这件事不一样。
上游 CPA 已经移除了原来内存聚合的 /usage、/usage/export、/usage/import 这类接口。现在只能消费 CPA 的 RESP 用量队列，然后把请求事件持久化下来。
这件事不能只靠浏览器里的静态页面稳定完成，原因是：
- 浏览器页面关掉后就不能继续收集请求
- 用量队列需要一个常驻消费者
- 请求记录需要落盘，否则重启或刷新后历史数据会丢
- 长期统计、导入导出、失败分析、费用预估都需要后端存储支撑
- 浏览器直接连队列还会遇到 CORS、TLS、网络拓扑和权限问题
所以现在多了一个 Usage Service。它完成下面的事情：
CPA RESP 用量队列 → Usage Service → SQLite → 管理面板请求监控
也就是说，面板还是面板，但“请求监控和历史统计”需要一个长期运行的服务来兜底。
如果你只是想改配置、看日志、管理 Auth 文件，原来的面板模式仍然能用。
如果你想要稳定的请求监控、历史用量和 Docker 持久化统计，就推荐使用完整 Docker 方案。
项目地址：https://github.com/seakee/CPA-Manager
Docker 镜像：seakee/cpa-manager:latest
项目关键截图
详细使用方法见项目说明文档CPA-Manager/README_CN.md at main · seakee/CPA-Manager · GitHub
最后
如果对佬们有帮助，欢迎点个 Star，也欢迎提 issue 或 PR。
PS：之前帖子里有佬反馈了 UI、部署、数据持久化和账号巡检相关问题，这两天也陆续补了一些功能
2 个帖子 - 2 位参与者