Repository navigation
feat(dashboard): 监控大盘改版,体检判定挪到服务端算,并把入口归入后台管理 - #211
Merged
Merged
Conversation
大盘原本是深色霓虹皮肤加七张等权 KPI 卡,跟产品其余页面不像一套;首屏也没有 结论,用户得自己在一堆数字里找哪个有问题。改成顶部一条判定条先给结论,下面 体检表列出八项检查(指标、当前值、阈值、迷你趋势、状态),点某一行就地展开 趋势大图和相关日志。配色收成灰橙红三档。 判定逻辑从页面 JS 挪到 app/services/metrics_checks.py:单位换算、阈值比较、 「没有样本」和「样本值是 0」的区分都只有服务端分得清。挪的过程中查出三个 真实缺陷——熔断器状态是小写枚举而判定表写的是大写,熔断中的实例会被显示成 正常;延迟接口给秒而阈值按毫秒读,P95 检查永远不会触发;LLM 一次都没调用 时成功率是 0%,拿去比阈值会被判成严重。三条都补了回归测试。
监控大盘一直在 /dashboard 上挂着,但后台导航里没有它,运维只能手动敲地址。 在导航清单里加一条「监控大盘」,放系统组。 它是壳外的独立页面(后端直出 HTML,经 rewrite 同源暴露),所以不进面包屑, 侧边栏用原生 a 标签整页跳转——Next 的客户端路由要的是 RSC 载荷,后端给的是 整页 HTML。清单新增 standalone 标记把这件事显式记下来。
写清判定为什么放服务端(单位、枚举大小写、没有样本与值为 0 的区别都只有 服务端分得清)、改版方向、入口归入后台管理的做法,以及推翻旧笔记里「避免 新增导航项」那条便利性理由的理由。
独立复核跑完五条定向变异后,又挖出判定之外的几处,一并修掉: 错误率和连接池两行的趋势跟当前值不是一个口径——当前值是比率,趋势画的却是 累计个数,纵轴还会把「37 次」标成「37.0%」;运行时状态卡里自己抄了一份 阈值和熔断状态映射,跟服务端判定各执一词;认不出来的熔断状态值被默认判成 正常;阈值文案写「< 500ms 合格」而实现是等于阈值也算合格;慢查询拿进程启动 至今的累计计数去比固定阈值,跑久了必然超标;读不到慢查询计数时回落成 0, 把「没取到」说成「一次都没有」;汇总里「判不出档位」的项被算进了通过数。 顺带把新端点补进 metrics 的鉴权测试参数表,并给判定口径补齐这几处的用例。
把判定搬到服务端只是搬走了第一份口径,前端留着阈值、状态映射或另算一份趋势 就会重新长出第二份。写进笔记的是这条教训,以及逐条修了什么。
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
背景
内置监控大盘
/dashboard(后端直出 HTML)一直挂在系统里,但有三个问题叠在一起:改了什么
判定口径挪到服务端(
app/services/metrics_checks.py新增)体检项的定义(阈值、单位、严重程度映射、「有没有样本」的判据)与判定全部在服务端,
GET /api/v1/metrics/checks返回每项的当前值、展示串、阈值说明、状态与计数汇总。前端只负责把结论画出来。原因有三件只有服务端知道的事:
closed/open/half_open,写错大小写就把熔断判成「正常」沿用本仓库已有做法(前端体验指标的阈值与 p75 口径同样真源在 service 层)。
大盘改版
入口归入后台管理
frontend/src/lib/admin-nav.ts新增「监控大盘」(系统组)。它是壳外独立页面(后端直出 HTML,经 rewrite 同源暴露),因此:inShell: false——那个页面没有壳内顶栏,不进面包屑;standalone: true——侧边栏用原生<a>整页跳转,Next 客户端路由要的是 RSC 载荷,后端给的是整页 HTML。独立复核
复核者跑了 5 条定向变异(熔断状态大小写、P95 秒→毫秒换算、LLM 零调用当有样本、关掉
invert分支、阈值比较>改>=),全部被测试抓到——判定规则本身没问题。复核另外挖出判定之外的几处,已全部修掉并补用例:
Verification
backend/tests/test_metrics_checks.pybackend/tests/test_metrics_auth.pymake layeringcd backend && uv run ruff check . && uv run ruff format --check .cd frontend && npx tsc --noEmitcd frontend && npm run test:coverage不做
services/metrics_alerting.py已有服务端告警)。closes #209