--- topic: 观测体系 canonical: true date: 2026-06-21 --- # 运维域 · 线上观测体系设计 > 绘境AI 线上观测体系的 canonical 设计稿,回答线上服务跑起来之后靠什么持续看见它、靠什么在它出问题时被叫醒。它补的是运维主档 [README §4](README.md) 立位、但一直留白的那一块:主档 §1.3/§1.4 回答了"部署后跑一遍冒烟门确认健康"和"健康到 ≥99.5% 可用性才算达标",但"线上持续靠什么观测、5xx 飙升靠什么发现、生成失败率掉了谁告诉你"这一问,现行只有一个秒级冒烟门加一个可用性数字撑着,配不上一个要对外服务的平台。 > **给谁看**:搭观测栈和埋点的工程师、值守线上的人、做生成质量与成本对账的人、关心可用性达标证据的创始人。 > **边界**:本稿只管观测本身——采集怎么埋、看板告警怎么分工、admin 怎么进大盘。观测栈的部署落点与 k8s 迁移强相关:创始人 2026-06-21 已定本阶段上 k8s、观测栈随服务一起往 k8s 收(见 [k8s迁移.md](k8s迁移.md))。本稿按那份迁移档的目标形态设计——观测栈落在 mini-desktop 单节点 k3s 的 `observability` namespace;k3s 就绪前可先以 mini-desktop 裸 docker-compose 过渡。埋点产出标准 OTLP,与后端组件的部署方式在 OTLP 协议这个接口上解耦,所以"先 docker-compose 过渡、后随 k8s 收编"对应用侧埋点零改动。k8s 怎么迁、迁到什么形态属 k8s迁移.md,本稿不展开。 --- ## 1. 现状:有一半客户端地基,但大半没接线、没后端 后端的观测地基处于"零件在、没装上"的状态,逐件核对如下,把"现在已经有什么"和"还得新建什么"分清楚,免得把蓝图当现状。 yudao 框架层有一个 `huijing-spring-boot-starter-monitor` starter,它里面的零件状态参差不齐: - `TraceFilter`:**已实现、能用**。每个响应回写一个 `trace-id` 头(`TraceFilter.java`,header 名就是小写 `trace-id`,不是 `X-Trace-Id`)。但它取的 traceId 来自 SkyWalking 的 `TracerUtils.getTraceId()` → `TraceContext.traceId()`;SkyWalking agent 不在席时,这个值是占位串而非真实 traceId。这条是"trace_id 从入口注入"那条规范的落脚点,但要真出一个能串链路的 traceId,得先把它对齐到下面要新建的 OTel trace context。 - `@BizTrace` 注解 + `BizTraceAspect` 切面:**注解和切面类都在,但 AOP 当前被禁用**。`HuijingTracerAutoConfiguration` 里注册切面的 `@Bean`(`bizTracingAop()` / `tracer()`)是注释掉的(源码 line 28–40,带 `TODO 后续换 opentelemetry` 的注释),所以 `@BizTrace` 现在贴上去不会织入任何埋点。要用得先取消注释并验证 AOP 织入——但既然要换 OTel,更可能是直接用 OTel 的手动 span 取代它,而不是去启用这套绑 SkyWalking 的旧切面。 - `HuijingMetricsAutoConfiguration`:**类在,给指标打 `application=<服务名>` 公共标签**;`micrometer-registry-prometheus` 作为 `optional` 依赖带进了 starter。 - SkyWalking `apm-toolkit-*`(含 logback 集成)和 `spring-boot-admin-starter-client`:同样以 `optional` 依赖躺着,默认不启用。 关键的一条事实:**这个 monitor starter 没有进生成主线的部署单元**。线上跑的单体是 `huijing-server`(`HuijingServerApplication` 聚合 `game-module-aigc-server` 等十几个业务模块),它的 pom 里没有 `huijing-spring-boot-starter-monitor`(该 starter 只被 gateway/infra/pay/system/bpm 等模块引了)。所以 `TraceFilter`/`@BizTrace`/`HuijingMetricsAutoConfiguration` 这套地基,**对 aigc 这条生成主链路的运行进程而言,classpath 上根本没有**——要用,得先在 `huijing-server`(或 aigc-server)的 pom 里引入。 生成主线那一侧倒是真有一段已落地的观测信号:aigc-server 已经引入 `spring-ai-alibaba-graph-core` + `spring-ai-alibaba-starter-graph-observation`(SAA v1.1.2.2,见 aigc-server pom),SAA 裸图编排在 `ObservationRegistry` 非空时挂上 graph-core 自带的 `GraphObservationLifecycleListener`(生产代码 `SaaStudioGraph.build` 已接,`AigcExecutorConfiguration` 软取 Micrometer `ObservationRegistry`,缺则降级 NOOP),**每个图节点发一条 `spring.ai.alibaba.graph.node.` 的 Micrometer observation,带 trace 和耗时,失败反映在指标里**(见 [`.agents/skills/saa-graph-orchestration.md`](../../../.agents/skills/saa-graph-orchestration.md) §5)。这是后端唯一一段已经在以 Micrometer 标准产出、且依赖已就位的观测信号——缺的只是一个把它收走的后端,以及一个非 NOOP 的 `ObservationRegistry`(后者要 Spring Boot actuator/micrometer 装配在席才有,而 actuator 也还没引)。**口径**:这段 SAA 节点 observation 是**已落地的遗留信号**——生成框架已于 2026-06-25 收敛到 AgentScope、SAA 降为最低优先级,所以它是现存 SAA 实现的观测地基,先按现状接进来、待生成主线迁到 AgentScope 后再按新框架重挂;观测栈与生成框架经 OTLP 在协议层解耦,这段信号的接入不受框架收敛影响,下文凡说"SAA 节点 observation"均按此理解。 前端那侧是另一种现状:studio 已经有业务遥测(性能 / 游玩 / 会话),事件经 `/app-api` 落进 `game_telemetry_event`,聚合成 `game_telemetry_game_stat`,再回灌游戏热度和质量分(见 [后端数据模型 §2.3](../后端/数据模型.md))。这条业务数据回路和"前端页面在真实用户浏览器里加载多慢、报了什么 JS 错"这种前端可观测性是两回事,后者现在完全没有。 缺口归纳成三条: 1. **没有任何遥测后端在收数据**。Micrometer 指标没人 scrape,trace 没地方落,日志还是各进程自己的文件。蓝图里画过的 Prometheus / Grafana / Jaeger 三个容器,MVP 现实从未起过(历史回收判定 运维基建-001)。 2. **采集标准不统一,且和创始人选定的不一致**。现状脚手架是 SkyWalking + Micrometer 两套各走各的;创始人 2026-06-21 定的是 **OpenTelemetry(OTel)一套统一 trace / metrics / log**。这不是补一个后端就完,而是要把采集标准收敛到 OTel。 3. **告警是一张纯文档表,没有一根通道真接上**。`security-and-reliability.md` §6 把 P0–P3 升级链和触发条件写全了(P1=5xx>2% 或生成成功率<70%),但飞书/钉钉 webhook 谁配、P0 电话怎么打,全是空头承诺(历史回收判定 运维基建-004)。预算里留了 ¥500/月给监控/备份,但这笔钱对应的能力一直是空的(运维基建-027)。 这份设计要做的,就是把这三条补成真东西:引入 OTel 统一采集、把已有的 SAA 图节点 observation 和后续新埋的指标接进去、给 Grafana + 夜莺喂上数据、把告警通道接通、并在 admin 开一个进大盘的入口。下面 §3 凡涉及新建的契约面(后端 pom 依赖、新增指标埋点、admin 路由与查询接口),会单列 contract-first 清单,讲清"现在没有、要新建什么"。 --- ## 2. 设计目标 观测体系做成之后,要能回答四个层次的问题,且每一层都有人(或告警)在看: - **基础设施层**:每台机器、每个进程的 CPU / 内存 / 磁盘 / GC,够不够、会不会 OOM、磁盘会不会涨满。 - **服务层**:后端各 API 的 QPS / 错误率 / P95 延迟,可用性够不够 ≥99.5%,达标用 error budget 说话而不是拍脑袋。 - **业务层**:生成成功率(≥80% 是验收线,也是最关键的业务健康指标)、生成 P50/P95 耗时、队列积压、广告/分账链路有没有断、生成成本有没有失控。 - **前端层**:真实用户那边首屏多慢(P75<3s 目标)、JS 报错率、关键交互(刷流、点生成)的成功率。 配套的硬目标: - **采集统一**:trace / metrics / log 三件都经 OTel 一套标准产出,trace_id 从网关入口贯穿到 SAA 节点和 new-api 调用,一个 trace_id 能把"一句话生成游戏"这条链从前端点击串到模型返回。 - **关键告警必达**:可用性、错误率、生成失败率三类告警必须真能把人叫醒(不是只在看板上变红)。 - **admin 一键进盘**:运营和排查从后台点一下就进监控大盘,不用各记各的 Grafana 地址、各自登录。 - **埋点与部署解耦**:观测栈按 k8s迁移.md 落在 mini-desktop k3s 的 observability namespace,k3s 就绪前先 docker-compose 过渡(见 §4)。无论过渡形态还是 k3s 形态,后端那侧的埋点(OTel agent + 语义约定)一行不用改,只换观测组件的部署方式——埋点是应用内的事,观测后端是部署的事,两者在 OTLP 协议这个接口上对接。 --- ## 3. 方案 ### 3.1 整体形态:OTel 采集 + 三类后端 + Grafana/夜莺双看板 观测体系是一条"采集 → 管道 → 存储 → 看板/告警"的链。创始人点名的组件是 OTel(采集和管道)、Prometheus(存指标)、Grafana 和夜莺(Nightingale,在最上面分工做看板与告警);trace 后端和日志后端创始人没点具体哪个,本稿给倾向并标"选型待定"(见 §6)。整条链的形态如下。 ```mermaid flowchart TB subgraph SRC["采集侧(被观测的进程)"] BE["huijing 后端单体
OTel Java Agent 自动注入
+ Micrometer 指标 + SAA 节点 observation"] FE["game-studio / game-admin 前端
OTel Web SDK(可选,后期)
页面性能 / JS 错误 / 前端 trace"] HOST["主机/中间件
node-exporter · MySQL/Redis exporter"] end subgraph PIPE["管道:OTel Collector(统一入口)"] COL["OTel Collector
OTLP 收 trace/metrics/log
批处理 / 脱敏 / 路由"] end subgraph STORE["存储后端(各管一类)"] PROM["Prometheus
指标时序"] TRC["trace 后端
Tempo / Jaeger(选型待定)"] LOG["日志后端
Loki 等(选型待定)"] end subgraph VIEW["看板与告警"] GRAF["Grafana
统一看板(trace/metrics/log 三联查)"] N9E["夜莺 Nightingale
告警规则引擎 + 通知分发
P0–P3 升级链落地"] end ADMIN["game-admin 控制台
观测入口 / 观测大图"] BE -->|OTLP| COL FE -->|OTLP/HTTP| COL HOST -->|scrape| PROM COL -->|metrics| PROM COL -->|trace| TRC COL -->|log| LOG PROM --> GRAF TRC --> GRAF LOG --> GRAF PROM -->|查询/拉取| N9E N9E -->|webhook| NOTIFY["飞书 / 钉钉 / 短信 / 电话"] ADMIN -->|嵌入 + SSO 免登| GRAF ADMIN -.->|告警概览 API| N9E ``` 几个选型决定要讲清为什么: **为什么 OTel Collector 居中,而不是各组件直连后端。** 让每个被观测进程直接把数据推给各自的后端(指标推 Prometheus、trace 推 Jaeger),会把后端地址、协议、脱敏逻辑全硬编码进每个应用,上 k8s 或换后端就得改一圈。中间放一个 OTel Collector 当统一入口,应用只认一个 OTLP 端点,**脱敏、批处理、采样、路由全在 Collector 这一层做**——手机号/token 脱敏这条规范(`security-and-reliability.md` §6)就落在 Collector 的 processor 里集中执行,而不是指望每个埋点点各自记得脱敏。换后端、上 k8s 时,改 Collector 的导出配置即可,应用零改动。这正是"先单体可跑、后平滑上 k8s"能成立的技术支点。 **为什么后端用 OTel Java Agent,而不是继续用 SkyWalking toolkit。** 现状脚手架里那套 SkyWalking `apm-toolkit-*` 是 yudao 自带的,但它和 Micrometer 是两条平行的采集路,且不是创始人选定的标准。OTel 的 Java Agent 能**零代码自动织入** Spring MVC / JDBC / Redis / HTTP client 的 span,同时通过 OTel 的 Micrometer bridge 把现有的 Micrometer 指标(含已经在产出的 `spring.ai.alibaba.graph.node.*` 那批 SAA 节点 observation)一并收走。所以采用 OTel Agent = 自动 trace + 收编现有指标,**一步把两条平行路收敛成一条**;SkyWalking 那套 toolkit 退役为不启用(依赖留着不删,免得动 yudao 框架层,但 profile 里不开)。这是这份设计里唯一一个"用框架现成的 vs 换标准"的实质取舍,理由是创始人定了 OTel,且 OTel 能向后兼容地把 Micrometer 那部分一起带走,换的成本低、收益是采集口径统一。 **为什么是 Grafana 和夜莺两套,各管什么。** 这两个不是冗余,是分工: - **Grafana = 看(read-only 的眼睛)**。它是统一看板层,把 Prometheus 的指标、trace 后端的链路、日志后端的日志接成数据源,做成大盘,支持"从一条慢请求的指标点进它的 trace、再点进这段时间的日志"这种三联下钻。admin 一键进的"监控大盘"就是 Grafana。 - **夜莺 Nightingale = 叫(会响的告警)**。夜莺是国产的告警规则引擎加值班/通知分发系统,中文生态、飞书钉钉接入顺手,正好补上"告警通道一根没接"这个最大的空。它从 Prometheus 拉指标算告警规则,把 `security-and-reliability.md` §6 那张 P0–P3 升级链表**变成真的规则和真的通知**(P0 电话、P1 短信+群、P2/P3 群)。 简言之 Grafana 负责"你主动去看时看得清",夜莺负责"你没在看时它把你叫来"。两者都从同一份 Prometheus 指标取数,口径一致。(注:Grafana 自带 alerting,夜莺也能做看板,功能上有重叠;这里按创始人选定的分工——Grafana 主看板、夜莺主告警——各取所长,不强行二选一。) ### 3.2 后端怎么埋:Agent 兜底 + 关键链路手动加 span 后端埋点分两层,自动的兜底广度、手动的补关键链路的深度。 **自动层 = OTel Java Agent。** 启动时挂一个 `-javaagent:opentelemetry-javaagent.jar`,配好 OTLP 端点和服务名,它自动给每个 HTTP 入口、每次 JDBC 查询、每次 Redis 调用、每次出网 HTTP(含调 new-api 的那次)生成 span 并串成 trace。这一层不改一行业务代码,就把"一个请求经过了哪些 SQL、哪些下游、各花多久"全画出来。 这里有一个必须解决的双 traceId 问题。现有的 `TraceFilter` 回写的响应头是 `trace-id`(小写),它的值来自 SkyWalking 的 `TracerUtils.getTraceId()`;而 OTel agent 走的是 W3C `traceparent` 标准、生成自己的 traceId。如果两套并存而不打通,响应头回的 `trace-id` 和 Grafana 里 OTel trace 的 traceId 会是两个不同的值,前端拿着 `trace-id` 去 Grafana 查不到对应链路。统一成一根的方向是:启用 OTel agent 后,把 `TraceFilter` 回写的来源从 SkyWalking 的 `TracerUtils` 换成 OTel 当前 span 的 traceId(`Span.current().getSpanContext().getTraceId()`),让响应头里的 `trace-id` 就是 OTel 的 traceId。这样前端报错时带回的 trace_id 能直接在 Grafana 里查到对应后端链路。具体改 `TraceFilter` 取数来源、还是用 OTel 的 baggage/响应头注入扩展,**待核**(见 §6 第一条)。 **手动层 = 给生成链路补结构化 span 和业务指标。** 自动 agent 看得见"调了 new-api 花了 8 秒",但看不见"这是生成的第几步、过了几道门、就绪分多少"——这些业务语义得手动埋。其中 SAA 图节点这一段地基已经在:每个节点已发 `spring.ai.alibaba.graph.node.` observation(依赖已就位,见 §1),只要接上非 NOOP 的 ObservationRegistry,这些自动变成 trace 里的 span。但下面这几个**关键业务指标目前在代码里全部零命中,是要新建的埋点,不是已有数据**——它们需要在对应的 Worker / 控制平面类里补 `MeterRegistry`(或 OTel `Meter`)的计数/计时注册调用后才会有数据。各指标的设计口径(都打成 Micrometer/OTel metrics,带 `template`、`model`、`source` 维度标签): - `gen_task_total{status}` —— 生成任务总数按终态分(对齐 `game_aigc_task.status`:2 成功 / 3 失败 / 4 超时 / 5 取消),**生成成功率 = success / (success+fail+timeout)**,作为 P1 告警(<70% 触发)和验收线(≥80%)的取数源。埋点位:任务终态回填处(`AigcTaskServiceImpl` / Worker 写终态那一步)。 - `gen_duration_seconds` —— 生成耗时分布(histogram),出 P50/P95,对齐"P50<60s、P95<180s"的硬指标。埋点位:Worker 一局生成的起止。 - `gen_queue_depth` —— 队列积压(全局在飞 = queued+running)。**取数口径要对齐控制平面的真实实现**:背压阈值是 `AigcControlPlaneProperties.queueDepthLimit`,代码里当前是占位值 **50**(注释明确"占位值,需确认",不是蓝图里画过的 500);超阈值时走业务码 `AIGC_BACKPRESSURE_REJECTED`(`1_101_001_002`),**HTTP 仍 200、body.code 非 0,不产生 HTTP 429/503**(见 [开闸验收门-W-G1](../架构/生成引擎/验收门.md) 决策E,以及 `ErrorCodeConstants` 注释)。所以这个指标的告警语义是"在飞数逼近 `queueDepthLimit`",不是"返回 429 的次数"。埋点位:控制平面 `enqueueWithControlPlane` 背压判定处。 - `gen_gate_fail_total{gate}` —— 九门各门失败计数,从 `game_aigc_task.trace_json`(九门轨迹账本)那条信息里出,定位是哪道门在拖低成功率。埋点位:九门校验节点。 - `llm_cost_cents` / `llm_cache_hit_rate` —— 生成成本与前缀缓存命中率。**成本数据源待薄片落地**:后端代码现在没有任何读取 new-api 计费日志(`logs.quota`)的逻辑——`logs.quota 权威对账`目前只是 `SaaGraphDispatcher` 里的一句注释和 旧 memorys 死库(已删,git 可查) 的一个待建薄片设想,不是已接通的链路。要把成本做成实时指标,得先落地一个读 new-api `logs.quota` 的薄片把成本拉出来,再注册成指标。**缓存命中率掉到 50% 以下要告警**(历史回收判定 运维基建-003 的成本早期哨兵,缓存因 few-shot 字节漂移失效会让成本翻几倍)。 > **contract-first(新建项清单)**:生成链路要接观测,跨模块面的新增物有三类——① **后端依赖**:`huijing-server`(或 aigc-server)pom 引入 OTel 相关依赖(actuator + micrometer + OTel Java Agent 走启动参数,不进 pom 也可),让 `ObservationRegistry` 非 NOOP;② **指标埋点**:上面五个指标在对应 Worker/控制平面/九门节点类补 `MeterRegistry` 注册调用(纯应用内新增,不动契约 yaml/DB);③ **成本薄片**:新建读 `logs.quota` 的成本采集薄片(单独一件事,见上)。这三类都是"现在没有、要新建",落地前观测大盘上的生成指标全是空的。 接好之后,生成这条最值钱的链路既有 trace(一次生成的完整时间轴 + 每个节点)、又有 metrics(成功率/耗时/积压/成本的趋势与告警),trace 和 metrics 经同一个 trace_id 关联。下面这张图把"一句话生成游戏"的 trace 贯穿画出来: ```mermaid flowchart LR U["前端点击
生成游戏"] -->|traceparent 注入| GW["网关入口
TraceFilter 起 root span"] GW --> AIGC["aigc 服务
建 game_aigc_task"] AIGC --> SAA["SAA 裸图编排
每节点一条 observation span"] SAA -->|node: brief| N1["..."] SAA -->|node: gen_source| N2["调 new-api
OTel agent 自动 span"] N2 --> NAPI["new-api 网关 → 便宜 LLM"] SAA -->|node: nine_gates| N3["九门校验
gen_gate_fail 指标"] SAA --> BUILD["build-from-source
编译产物"] AIGC -. "终态回填 status
gen_task_total{status}" .-> METRIC[("指标:成功率/耗时/成本")] style METRIC fill:#1a2b3c,color:#fff ``` 一个落地约束要写在这里:**埋点开关默认关、经 profile 显式打开,失败绝不影响主流程**。OTel agent 和指标上报都不能因为 Collector 挂了就拖垮生成——agent 走异步批量上报、Collector 不可达时本地丢弃(对齐 SDK 降级铁律里 Telemetry 类"上报失败静默丢弃、稳定性>数据完整性"的精神,见 `security-and-reliability.md` §7)。这条保证了观测栈本身是旁路,挂了不咬主链路。 ### 3.3 前端怎么埋:先收 JS 错误与首屏,trace 打通靠 traceparent 前端可观测性分两步走,因为它和已有的业务遥测要划清边界,别重复造。 业务遥测(谁玩了哪款、留存多少)继续走现有的 `/app-api/telemetry` → `game_telemetry_event` 那条,不动。**新增的是"前端运行健康"这一类**:页面首屏耗时(对齐 P75<3s)、JS 运行时报错、关键接口(刷流、生成、发布)的失败率。这部分用 OTel 的 Web SDK 采集,经 OTLP/HTTP 推给同一个 Collector。 更要紧的是把前后端 trace **连成一根**:前端发起后端请求时,在请求头注入 OTel 的 `traceparent`(W3C trace context 标准头),后端 agent 认这个头、把后端 span 挂到同一个 trace 下。这样一次"点生成 → 后端建任务 → SAA 跑图 → 调模型"的全过程是一个 trace,从用户浏览器一直串到模型返回。生成失败时,前端拿到的 trace_id 能在 Grafana 里直接查到这次生成卡在哪个节点、哪道门、调模型报了什么——这是排障效率的关键。 前端这块**排在后端之后做**:后端 + 基础设施的观测是 ≥99.5% 可用性达标的直接证据,优先级最高;前端运行健康是体验优化,价值真实但不卡可用性目标,放第二批(见 §4)。 ### 3.4 告警:把文档表变成夜莺的规则和通道 告警是这份设计里"从无到有"最实的一块。`security-and-reliability.md` §6 那张 P0–P3 表现在是纯文档,夜莺要把它落成三样东西:**规则(什么条件触发)、分级(P0/P1/P2/P3)、通道(怎么通知、多久响应)**。逐级对应: | 级别 | 触发条件(夜莺规则,取数自 Prometheus) | 通道 | 响应时限 | |---|---|---|---| | **P0** | 服务不可用(health 探测连续失败 / 整机宕)、数据丢失、安全事件 | 电话 + 短信 + 群 | 5 分钟 | | **P1** | `5xx 占比 > 2%` 持续 N 分钟 / **生成成功率 < 70%** / 支付异常 | 短信 + 群 | 15 分钟 | | **P2** | `API P95 > 800ms` / 在飞数逼近 `queueDepthLimit`(当前占位 50)/ 错误率上升 / **缓存命中率 < 50%** | 群通知 | 1 小时 | | **P3** | 非核心模块降级 / 日志异常增长 / 磁盘水位 > 80% | 群通知 | 工作时间 | 三类创始人点名的关键告警都在表里有家:**可用性**走 P0(health 连续失败)、**错误率**走 P1(5xx>2%)、**生成失败率**走 P1(成功率<70%)。另外把两条历史回收清单里悬空的哨兵补进来:**缓存命中率<50%**(成本早期哨兵,运维基建-003)进 P2,**磁盘水位>80%**(运维基建-021,mini-desktop 上 staging+构建产物+jar 备份+批跑证据会涨满磁盘、满了 MySQL 直接挂)进 P3。 通道落地有一条务实的分期:**MVP 阶段先接飞书/钉钉群机器人 webhook 把 P0–P3 全打通**(这是零成本、当天能接的),P0 的"电话+短信"依赖短信网关/电话服务,**随真实化的支付/短信能力一起接**(现在 P0 先用群里 @所有人 + 短信兜底,电话留接口)。这条避免了"因为电话通道没接就说告警没做"——先把群通知接通,贵的通道按需补。 webhook 密钥(飞书/钉钉群机器人的 webhook URL 与签名 secret)按内网阶段铁律落进 [`docs/内网凭据与端点.md`](../../内网凭据与端点.md),和 `NEWAPI_KEY` 同处,**不走环境变量**——内网阶段地址和密钥统一进项目文档,夜莺配告警通道时从那份凭据档取。 ### 3.5 admin 观测入口:从无到有的一整套(现状是零) 先讲现状:**这一块现在完全是空的,要整套新建**。`game-admin/src` 下没有任何观测/监控相关的路由、菜单或 Vue 组件(现有的 `infra/redis monitor` 是 yudao 自带的 Redis 监控,与本设计无关),后端也没有任何给 admin 用的观测查询接口。所以"控制台一键进监控大盘"不是接一根线,而是要补齐前端、后端、嵌入安全三件,缺一不可。 创始人要的入口落在 game-admin 上(Vue3 + Element Plus),做法是在控制台新建一个"观测"菜单,底下两块: - **观测大图**:一个嵌入页,把 Grafana 的核心大盘(可用性 / 错误率 / 生成成功率 / 关键链路)以 iframe 或 Grafana 的 embed 方式嵌进 admin,运营点一下就看见全局健康,不用记 Grafana 地址。**注意 iframe 嵌入不是写个 `