 qian
|
211148a0af
|
improve(workbench):优化工作台页面
|
2026-08-31 23:29:21 +08:00 |
|
|
chengqian
|
bdfd1b6567
|
feat(ui):管理后台新增工作台，可便捷查看告警信息
|
2026-08-31 20:07:15 +08:00 |
|
|
chengqian
|
958f6c4d75
|
type(relay):修正测试代码里面的函数名为纯英文
|
2026-08-28 17:40:24 +08:00 |
|
|
chengqian
|
96bcd3e46f
|
fix(channel):修复渠道更新key后无法立即生效
|
2026-08-28 16:55:28 +08:00 |
|
|
qian
|
e8dfe9499d
|
improve(log):优化日志输出
|
2026-08-27 23:36:20 +08:00 |
|
|
chengqian
|
dd02bf4ac3
|
feat(admin): 渠道列表/详情展示最差模型，暴露被均值摊薄的单模型故障
渠道健康分是各模型 succ_ewma 的均值，单个模型全挂会被其余健康模型摊薄——10 个
健康模型 + 1 个挂掉仍能算出 90 分绿灯，而这恰是模型级熔断要隔离的典型场景。
补一个最差项：ChannelRuntimeStates 遍历目录快照时顺带取每个渠道 succ_ewma 最小的
模型，按 succ^α×100 折算为与渠道分同口径的健康分。
不落库、不加列：catalog 内存快照已逐 (渠道,模型) 持有 SuccEwma，遍历它即可，零额外
I/O；数据是调度器同源的 5 秒刷新值，比 5 分钟落盘快照更新鲜。取最小值也天然免疫冷
模型问题——无上报的模型读作满分 1.0，永远不会被选为最差项。
byModel 是 map，遍历顺序随机，同分时按模型名取小者打破平局，否则全部模型满分时
每次请求返回的模型名都会跳变。
前端：列表页健康度列在最差项低于 80（健康档）时补一行「⚠ 模型名 分数」，详情页
健康度字段同理；disabled / testing 渠道不在目录快照，不展示。
|
2026-08-27 21:59:45 +08:00 |
|
|
chengqian
|
a5e2ecf527
|
fix(dispatch): 渠道健康聚合只统计有真实上报的模型，降级时保留库中旧值
渠道展示分是目录内全部模型 succ_ewma 的算术平均，而无流量模型读到的是乐观默认满分。
20 个模型的渠道死掉 1 个（succ→0.05）仍能算出 avgSucc≈0.95、91 分绿灯，恰好掩盖了
模型级熔断要隔离的典型场景。改为只统计 HasHealth 的模型；全渠道无真实上报时
Counted=0，保留库中上一次的分数而不是用默认满分覆盖历史结论。
Redis 读失败（Degraded）时跳过落盘并打 Warning：照常落盘会把全渠道健康分刷成 100，
连带 chn_health_snapshots 把假象写进历史趋势，事故期间的曲线反而全绿。自动禁用判定
一并跳过——该操作不可逆，不能基于不可信读值触发。
聚合逻辑抽成纯函数 aggregateChannelHealth 以便单测；另新增 RequestHealthSnapshot
按需重算入口（维护循环消费，满则丢弃由下一轮兜底），供渠道测试/重置健康度接入。
健康上报是 fire-and-forget，重算前等 500ms 让 worker 落完 Redis。
|
2026-08-27 21:59:43 +08:00 |
|
|
chengqian
|
3f3fc43856
|
fix(dispatch): 健康读值区分「无数据」与「读失败」，Redis 降级不再清零健康记忆
ReadRuntime 此前对「该模型没有流量」和「Redis 读失败」返回同样的乐观默认值
succ=1，调用方无从分辨。后果是 catalog.Rebuild 会用这批默认值重建快照，把上一轮
真实的 EWMA 覆盖掉——注释声称的 last-known 语义实际没有兑现，Redis 抖一下全渠道
healthFactor 集体回满分。
RuntimeReadout 新增 HasHealth（确有真实上报，脏值/精确 0/字段缺失都不算）与
Degraded（读失败，读值整体不可信）两个标记；Rebuild 在 Degraded 时沿用上一份快照的
健康读值，无历史可沿用才保持乐观默认（新实例启动即遇 Redis 故障不应把全渠道判死）。
|
2026-08-27 21:59:43 +08:00 |
|
|
chengqian
|
3035fa118c
|
fix(dispatch): 修复 HMGET 判空失效导致冷渠道健康分被读成 0
ReadRuntime 用 `!vals[0].IsNil()` 判断 HMGET 结果是否存在，但 gredis 把 Redis
nil 数组元素包装成非 nil 空 gvar（IsNil() 恒为 false、Float64() 静默返回 0），
导致所有从未被真实流量访问过的渠道×模型被读成健康 0 分而非默认满分 1.0：管理
后台渠道健康度全线坍缩（如某渠道 (1.0+0)/2 → 0.5²×100=25 长期不动），调度侧
healthFactor 同样归零，冷模型路由权重被压死。
GET/HGET 单值回复的 IsNil() 正常，仅数组回复有此坑；仓库内 HMGET 调用点仅
ReadRuntime 与 readBreaker 两处，后者因默认值 BreakerClosed 恰为零值而侥幸
无害，一并改为按字符串判空。
- ReadRuntime：TrimSpace 判空 + ParseFloat 值域校验（succ 取 0<f<=1，EWMA
由正数衰减而来不会精确到达 0，精确 0 视为异常数据）
- 回归测试：key 不存在须回落默认值、空串/非法值/精确 0 防御
- 通用规则写入 goframe-conventions.md 框架使用错误记录
同时补齐探测与健康分的可观测性（本次排查绕行三次的直接原因是全链路静默）：
- [ChannelProbe] 探测全流程：轮次起止、模型与上游映射、结果、是否上报健康
- [ChannelHealth] 健康分变化：EWMA 变化点（Outcome.Probe 区分探测/真实流量
来源）、快照落盘含各模型 succ 明细、维护轮次覆盖摘要
- 快照落库失败由 Debug 升为 Warning（此前静默，健康分冻结无从定位）
- 探测目标不在调度目录时告警（该场景健康分不落盘且渠道不参与调度）
- 变化类日志按「分数实际移动」触发，稳态降为 Debug，避免生产流量刷屏
|
2026-08-27 21:59:42 +08:00 |
|
|
chengqian
|
d2e3794e3a
|
fix(channel):修复渠道健康分数一直下降的问题
|
2026-08-26 16:49:25 +08:00 |
|
|
chengqian
|
330d02f19d
|
feat(channel):渠道详情页显示模型监控信息
|
2026-08-19 18:34:21 +08:00 |
|
|
chengqian
|
949957755e
|
fix(channel):修复渠道调度问题，单模型异常不再影响整个渠道
|
2026-08-19 18:34:20 +08:00 |
|
|
chengqian
|
bf7123148e
|
feat(model):responses协议和chat的优化处理
|
2026-08-14 18:14:11 +08:00 |
|
|
qian
|
540817a6a7
|
feat(channel):新增渠道调度状态显示
|
2026-08-08 09:09:07 +08:00 |
|
|
qian
|
c7d15d82a4
|
improve(admin):优化管理功能搜索条件
|
2026-08-04 22:50:57 +08:00 |
|
|
Qian
|
2ef5a40c26
|
新的调度方式 (#14)
重构模型渠道调度系统
|
2026-08-01 22:55:08 +08:00 |
|