Multica 自建实例 Usage 页面用量显示为零怎么排查【免费下载链接】multicaMake humans and AI agents work as one team — open-source and self-hostable.项目地址: https://gitcode.com/GitHub_Trending/mu/multica你在自建self-host的 Multica 实例上执行过 agent 任务但 Web 端 Usage 页面的用量显示为零。Usage 与 Runtime 仪表盘并不直接读取每次运行的原始用量而是读取派生表task_usage_hourly按小时聚合的 UTC 桶这张表由 SQL 函数rollup_task_usage_hourly()填充。自 MUL-2957 起这个 rollup 由 backend 进程内的调度器在每个副本上运行调度审计记录在sys_cron_executions表新装实例不需要你额外配置 pg_cron。所以“页面为零”通常是三层之一出了问题原始表task_usage没有数据、rollup 表没被填充、或 backend 内置调度器没在正常执行。以下按这个顺序排查适用于 Docker Compose 或 Kubernetes 部署的自建实例数据库为 PostgreSQL 17。先核对原始用量数据与 rollup 表连接到实例的 multica 数据库执行compose 栈中数据库名、用户名默认都是multica密码由.env中POSTGRES_PASSWORD决定SELECT count(*) FROM task_usage; SELECT count(*) FROM task_usage_hourly;判断方式task_usage本身为空没有可聚合的原始用量页面没有数据可显示问题不在 rollup 链路而在任务/用量上报一侧。task_usage有行、task_usage_hourly为空rollup 没有被成功执行或填充继续下一步查调度记录。查调度器在sys_cron_executions里的执行记录Usage 页面的数据来源是否在工作看这张审计表即可SELECT plan_time, status, attempt, runner_id, error_code, error_msg, started_at, finished_at FROM sys_cron_executions WHERE job_name rollup_task_usage_hourly ORDER BY plan_time DESC LIMIT 20;backend 的每个副本每 30 秒尝试认领当前 5 分钟粒度的 UTC 计划唯一键保证多副本部署只有一个赢家、不会双写。如果这里没有新记录落下来或者status为失败且error_code/error_msg有内容说明内置调度器没有正常工作先确认所有 migration 都已应用。手动执行一次 rollup区分 SQL 问题与调度问题在数据库里直接跑一次SELECT rollup_task_usage_hourly();执行后再查一次task_usage_hourly的行数。如果手动执行后数据正常说明 rollup 函数本身可用问题出在 backend 的内置调度上例如 migration 未完整应用、backend 未运行新版本如果手动执行也报错错误信息会直接指向 SQL 层的问题。两点限制需要注意手动 SQL 只补齐这一次 rollup不会恢复调度调度问题仍需在 backend 侧解决。按 102 号迁移 的实现每次 tick 的回补窗口上限是一天watermark 落后很多时每次只推进一天。历史数据缺口应该用专门的 backfill 命令补而不是反复手动调用。migration 103 卡住升级refusing to drop legacy daily rollups如果你的 backend 在启动时报refusing to drop legacy daily rollups说明 migration 103 的 fail-closed 保护被触发它要求task_usage_hourly已经追上task_usage的历史才允许删除旧的天级 rollup 管道。正常情况下无需干预——migrate up在应用 103 之前会自动执行按月分片的幂等 backfill空库直接跳过有历史的库按月补完再继续详见 103 号迁移的注释 与 SELF_HOSTING.md。如果 backend 仍然启动失败说明自动 backfill 没完成例如仍在使用 MUL-2957 之前的二进制或 SQL 是直接执行而不是通过migrate up应用的。手动恢复路径Docker Compose 部署docker compose -f docker-compose.selfhost.yml exec backend \ ./backfill_task_usage_hourly --sleep-between-slices2sKubernetes 部署kubectl -n multica exec deploy/multica-backend -- \ ./backfill_task_usage_hourly --sleep-between-slices2s或者在源码目录中运行DATABASE_URL换成你的实际连接串SELF_HOSTING_ADVANCED.md 给出的示例为postgres://multica:multicalocalhost:5432/multica?sslmodedisablecd server DATABASE_URLpostgres://... go run ./cmd/backfill_task_usage_hourly常用参数--dry-run只预览不写入--sleep-between-slices在月度分片之间加停顿以降低对繁忙实例的读压力生产库有多年历史时文档建议加上--months-back N只补最近 N 个月必须搭配--force-partial因为跳过的更早桶会被永久放弃。命令按月分片、幂等中断后直接重跑即可它持有 advisory lock 4246与服务端的定时 rollup 互斥不会产生重复或不一致的数据。补完后重启 backend确认/readyz中migrations为ok。验证恢复结果按顺序确认三件事调度记录恢复落盘——最近应有连续的SUCCESS行SELECT plan_time, status, runner_id, finished_at FROM sys_cron_executions WHERE job_name rollup_task_usage_hourly AND status SUCCESS ORDER BY plan_time DESC LIMIT 5;task_usage_hourly有行重跑开头的 count 查询。健康检查接口正常文档示例返回为{status:ok,checks:{db:ok,migrations:ok}}curl -i https://api.example.com/readyz其中api.example.com换成你的 API 实际地址。/health只说明 API 进程在响应/readyz才会检查数据库和 migration 状态验证时用后者。边界与兼容路径rollup 由 backend 内置调度器执行不需要自己配置 pg_cron如果旧部署里还注册了调用SELECT rollup_task_usage_hourly()的 pg_cron 任务或外部 cron / K8s CronJob它们仍是受支持的兼容路径函数内部持有 advisory lock 4246与内置调度器共存不会双写但文档明确不再推荐。确认内置调度器在sys_cron_executions里稳定产出 SUCCESS 行之后再考虑用SELECT cron.unschedule(rollup_task_usage_hourly) ...移除冗余条目。rollup_task_usage_hourly()只处理它开始运行之后的新桶。从v0.3.4升级到v0.3.5且库里已有数月用量历史时需要 backfill 命令补齐历史桶——这正是 migration 103 守卫存在的场景。相关文档troubleshooting 章节Usage shows zero与Migration 103 blocks an upgrade两节、Usage Dashboard Rollup 参考。【免费下载链接】multicaMake humans and AI agents work as one team — open-source and self-hostable.项目地址: https://gitcode.com/GitHub_Trending/mu/multica创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考