games-development-ai/docs/agent-specs/2026-07-05-全链路可观测性-OTel三信号全栈-设计.md

date, topic, status, sot-impact, 上级

date	topic	status	sot-impact	上级
2026-07-05	观测体系-阶段四落地	定稿(fable 主笔 · 双评审两轮修回:一轮 Codex+Opus 9+6 条、二轮 Opus 三条;创始人 2026-07-05 评审通过、§10 六项已拍)· 方向 B 全栈 OTel、落点 mini-infra 32G · 待实施(扩容窗口已过、可启动)	修订两份 canonical,实施收口后同批回写。①《观测体系》(docs/architecture/运维/观测体系.md):**订正 §1 现状把 monitor starter 说成「classpath 上根本没有」的旧断言**(实为经 system/infra 传递在席、只是 actuator/micrometer optional 未装、SkyWalking Bean 注释掉 = 在席但残缺);补全五面落地与埋点清单;告警件由夜莺改 Grafana 统一,牵动其 §3.4 告警规则、§3.5 admin 告警概览 API、§5.1 验收多段(推翻件选型,创始人 2026-07-05 已确认);脱敏 processor 补进 §5.1 可跑验收;成功率告警阈值(80% 达标线与预警线)口径回写时统一;admin 一键进盘拍定本期做、new-api 自动冻结阀拍定排下一期(本期只做通道巡检加告警)。②《k8s迁移》(docs/architecture/运维/k8s迁移.md,亦 canonical):落点从其规划的「mini-desktop 单节点 k3s observability namespace」反转为「mini-infra 扩内存后 docker-compose」——不止取代观测落点段,凡把观测栈算进 k3s 资源隔离的叙述(目标、拓扑、阶段规划、风险、验收各段)回写时逐段落地,免得留自相矛盾残句。两处改动面都以回写时对源核对为准。落点反转属横切一致性主人的灰色判断,已交创始人拍。	docs/architecture/运维/观测体系.md

全链路可观测性 · OpenTelemetry 三信号全栈 —— 落地设计(配置控制面阶段四)

1. 这份设计要解决的问题

到今天为止,这个平台对自己运行状态的了解是零散的。后端 game-cloud 那套 monitor starter 经 system 和 infra 两个模块传递进了线上单体,但它能提供的观测其实是残缺的:注册 SkyWalking 追踪切面的 Bean 整段被注释掉、只剩一个往响应头写 trace-id 的过滤器,而这个 trace-id 在没有 SkyWalking agent 的情况下是空串;真正出指标要的 actuator 和 micrometer 是 optional 依赖、并没有装,所以既没有 /actuator/prometheus 端点、SAA 图节点那条已经挂好的 observation 也因为拿到 NOOP 的 registry 而产不出信号。Python 生成线倒是已经在用 OpenTelemetry 的 SDK 发 trace——otel 的运行时依赖随 agentscope 传递装齐了,exporter 也是完整的,只是默认没配到一个能统一查询的地址,取不到地址就降级成不发。生成的成本、token、九门过门率、队列深度这些真正该盯的业务指标,眼下只落在产物目录的 json 文件和回调的 trace 字段里,没有一处能实时看、能告警、能跨服务串起来看。

一句话:信号源零散、能力残缺,没有一个收口的地方,更没有把「用户点一下到模型返回」这条链路端到端串起来的能力。

阶段四补的就是这一层。方向已经定了:用 OpenTelemetry 作统一标准,建一套三信号(指标 / 追踪 / 日志)全栈——OTel Collector 做统一入口,Prometheus 存指标,Tempo 存追踪(落在既有 MinIO 上),Loki 存日志,Grafana 做统一看板和告警。所有服务、两条生成路都把信号汇进同一个 Collector,才叫真正的「全链路一把梭」。

这份设计不是从白纸起,而且它牵动两份 canonical。 架构层已有一份 canonical 的《观测体系》把这套架构骨架画出来了(2026-06-21);另有一份 canonical 的《k8s迁移》把观测栈的落点规划在 mini-desktop 的单节点 k3s 上。本设计把抽象架构变成能施工的五面实施加埋点清单,并就三处与原稿不一致的地方(落点、告警件、以及原稿里两条不能丢的红线如何继承)给出理由和新结论。实施收口后,结论同批回写这两份 canonical。

2. 三个已拍的前提决策

方向 = 全栈 OTel 三信号(创始人 2026-07-05)。 不走「先指标后追踪」的分波保守路,也不复用已经死掉的 SkyWalking,而是一次把 Collector 加 Prometheus 加 Tempo 加 Loki 加 Grafana 的完整标准栈立起来。取的是完整和标准,认的是「现在省的事后面都会找你麻烦」。

落点 = mini-infra 加内存后落(创始人 2026-07-05)。 这里有一个必须讲清、而且牵动两份 canonical 的冲突:《观测体系》和《k8s迁移》都立过硬约束——观测栈绝不落 mini-infra,因为内存不够,《k8s迁移》进一步把它规划在 mini-desktop 的 k3s observability namespace、用 k8s 的 requests/limits 做资源隔离。实测数据是 mini-infra 总内存 15G,加内存前空闲只有 427Mi,可用的 7.3G 全是可回收的缓存,容器实占约 7.5G,其中 ragflow 独占 3.35G;再叠一套约 3 到 4G 的观测栈会把缓存吃光,ragflow 或生成负载一 spike 就 OOM,炸的是同机的 new-api、gitea 这些跨项目生产依赖。创始人在知道这笔内存账后,选择的不是压瘦硬塞、也不是拆到另一台,而是给 mini-infra 扩内存再落,理由是运维就近、一台管到底。

这个选择带来一个时序推论,恰好对本阶段有利:实施卡在硬件扩容窗口上,而设计不卡。 创始人要的本就是「先出设计」,那么设计现在就出、走完评审待命,等内存扩容窗口一到即可施工。

落点反转的代价要一起认下:内存维度解了,CPU 与 IO 争用、以及跨机拓扑没有自动解。 观测栈落 mini-infra 后,和 new-api、gitea、nacos、rocketmq、ragflow 同箱——这正是《k8s迁移》当初把它放 mini-desktop、用 k8s limits 隔离要躲的事。docker-compose 只有内存上限,一个失控的 Prometheus 或 Tempo 仍可能在 CPU 和 IO 上压到同箱的 new-api(而 new-api 是生成命脉)。所以本设计在 §5 面三额外要求观测容器设 CPU 限额、进程优先级低于 mini-infra 的生产件;并且拓扑是跨机的——Collector 和 Prometheus 在 mini-infra(100.64.0.8),被观测的 game-cloud 与两条生成线在别处,OTLP 上报和 scrape 抓取都过 Tailscale,余量和端点都按跨机算。

3. 现状与差距(摸底加亲验坐实,给施工一个准星)

五个组件面的真实状态,决定了每一面各自要补多少。这一节的每条断言都对源码亲验过,因为错一条实施就跑偏。

game-cloud 的观测能力是「starter 在席、但残缺」,不是「不存在」。 monitor starter 经 huijing-module-system-server 和 huijing-module-infra-server 两个模块传递进了线上单体 huijing-server(两个模块的 pom 都引了它)。但它在席不等于能用:SkyWalking 追踪的 Bean 整段被注释、只剩一个写响应头 trace-id 的过滤器,而这个 trace-id 取自 SkyWalking 的上下文、agent 不在时是空串;真正出指标要的 actuator 和 micrometer 是 optional、并没有随传递装进来,所以 /actuator/prometheus 端点不存在、Nacos 和 RocketMQ 和 Sentinel 的 micrometer 指标无处可出、aigc 那条已经挂好的 SAA 图节点 observation 也因为拿到的是 NOOP 的 ObservationRegistry 而产不出信号。这一面的结论是:starter 已在 classpath、但要上 OTel Java agent 自动织入 span,并引 actuator 加 micrometer 让那个 registry 不再是 NOOP、让指标端点成立;OTel 与既有(半死的)starter 是共存收编、不是从零装。

Python 生成线的 OTLP 现状要分两条线看,不能笼统说「依赖齐、重定向即可」——这一面第一轮评审我自己缝错过,亲验纠正。 依赖是真齐的:otel 全套(api、sdk、exporter-otlp 含 proto-http,1.43.0)随 agentscope 2.0.2 装进了 cheap-worker 的 venv,不单列 requirements 是对的依赖卫生——但装了依赖不等于在发 OTLP。真实现状:便宜档这条 MVP 主生成路,Service 与 CLI 两个入口都用 make_jsonl_sink 把每步 trace 直接写进产物目录的 trace.jsonl 文件,不产 OTLP span。 全仓唯一的 OTLP exporter 是 tier2 富游戏线专属的 studio_sink,可它有两点决定不能简单重定向:一是它发的目标是 AgentScope Studio 的私有端点(取环境变量,取不到即 no-op、默认关),不是通用 Collector;二是它自带私有 TracerProvider、给每步自造 root span、靠 gen-ai conversation id 归组,结构上就不读入站上下文。加上 tier2 本地并无独立 venv、studio_sink 惰性 import otel(源码自陈按无 wheel 环境设计),其运行 venv 的 otel 到位与否还要在扩容后的运行环境实测。所以这一面不是配个地址的十分钟活,是两条线各有一处真实接线:便宜档要新接一个 OTLP sink 让主路真产 span,tier2 的 studio_sink 要从发 Studio 改发 Collector、并放弃私有 root 接住入站 context——都落在 §5 面四。

但「重定向即可统一 trace」不成立——这是 Python 侧的真实拓扑决定的。 一次生成的真实链路是三跳不是两跳:Java 的 WorkerDispatchClient 用 JDK HttpClient 把 job 发给 Python 的 worker_service,worker_service 是一个裸的标准库 http.server、OpenTelemetry 对它没有自动埋点,worker 再用 httpx 打本机的 AgentScope Service(生成过程真正发生的进程——便宜档在这里现在只写 jsonl、还没有 OTLP span),最后用 urllib 回调 game-cloud。三个断点:worker_service 收到的 traceparent 没人提取;worker 打本机 Service 那一跳的 header 只有 X-User-Id、trace 上下文在此断,而生成 span 恰恰产在 Service 进程;tier2 的 studio_sink 用的是私有的 TracerProvider、给每个生成步起独立的 root span、靠 gen-ai 的 conversation id 属性归组,既不是父子 trace 树、也不读传入的上下文(而便宜档主路连 span 都还没有、是 jsonl)。所以光改端点,Tempo 里会是一堆按属性散落的 root span,挂不到 Java 的 trace 下——端到端一个 trace 串到底这个头号卖点,按「只改端点」实现不出来。要打通得改三处(见 §5 面四)。

deploy/infra 现在只有 Nacos 和 RocketMQ,观测栈是零。 观测栈的自然落点是新增一个 deploy/infra/observability/ compose。

业务指标的埋点在代码里是零命中。 生成成功率、耗时、队列深度、九门过门率、单次成本这些 MVP 要盯的指标,目前要么只落盘、要么只在回调的 trace 字段里,没有一个是以 metric 形式暴露的。

4. 目标架构

整套栈的形状是「多源汇一口、一口先脱敏再分三库、一板看到底」。

flowchart LR
  subgraph 源["信号源(全服务 + 两条生成路,跨机经 Tailscale)"]
    GC["game-cloud 单体(别处)<br/>OTel Java agent 自动 span<br/>+ actuator/micrometer 指标<br/>+ SAA 节点 observation(仅 saa 路)"]
    PY["Python 生成线(mini-desktop)<br/>便宜档主路 jsonl→新接 OTLP sink<br/>tier2 studio_sink 改发 Collector<br/>两路接入站 context(面四)"]
    INFRA["Nacos / RocketMQ / Sentinel<br/>micrometer 指标"]
  end

  COL["OTel Collector(mini-infra :4318)<br/>① 脱敏 processor(手机号/token,进库前最后一道)<br/>② 尾部采样 · 批量 · 重试"]

  subgraph 库["三信号存储(mini-infra 扩容后 · 存 MinIO)"]
    PROM["Prometheus<br/>指标 · 保留 7-15d"]
    TEMPO["Tempo<br/>追踪 · MinIO bucket"]
    LOKI["Loki<br/>日志 · 只收 WARN/ERROR · MinIO bucket"]
  end

  GRAF["Grafana<br/>统一看板 + 告警规则 + admin 一键进盘<br/>指标→trace→日志 三联下钻"]
  ALERT["飞书/钉钉 webhook"]

  GC -->|OTLP 过 Tailscale| COL
  PY -->|OTLP 过 Tailscale| COL
  INFRA -->|scrape 过 Tailscale| PROM
  COL --> PROM
  COL --> TEMPO
  COL --> LOKI
  PROM --> GRAF
  TEMPO --> GRAF
  LOKI --> GRAF
  GRAF --> ALERT

统一入口选 Collector,是为了把脱敏、采样、批量、重试这些横切策略收到一处。脱敏是进存储前的最后一道、也是安全红线:trace 的 span 属性里会带生成的输入输出内容和 token、日志里会有报错正文,不在 Collector 上把手机号和 token 脱敏,用户的 brief、prompt、可能的凭据就直接落进 Tempo 和 Loki——《观测体系》原稿把这条列为强制 processor,本设计继承、不能丢。追踪后端选 Tempo,是因为它和 Grafana、Prometheus 同体系、能三联下钻,而且用对象存储、可以复用既有 MinIO。

5. 五面落地

面一 · game-cloud 接入。 主路是 OTel Java agent:给 huijing-server 的启动加一个 -javaagent 参数,零代码自动织入 Spring MVC、JDBC、Redis、出网 HTTP(包括调 Python Service 和 new-api)的 span,一步拿到 Java 侧全链 trace 并在出网时自动注入 traceparent。为了让已经挂好的 SAA observation 从 NOOP 活过来、并让 Nacos/RocketMQ/Sentinel 的 micrometer 指标有处可出,给单体引入 actuator 加 micrometer 的 OTLP 或 prometheus registry。既有那套半死的 monitor starter 是共存收编:SkyWalking 的 toolkit 依赖留着不删(不动 yudao 框架层)、profile 里不启用,响应头过滤器的 trace-id 来源从 SkyWalking 换成 OTel 当前 span,让前端拿到的 trace-id 真能在 Grafana 里查到。

面二 · Python 生成线接 OTLP(是接线,不是重定向)。 依赖层面 cheap-worker venv 的 otel 全套已在、不用补 wheel;但如 §3,便宜档主路现在只写 jsonl、tier2 的 studio_sink 又发的是 Studio 私有端点,所以要两条线各接一处:便宜档在 jsonl sink 之外新接一个 OTLP span 发射(让主路真产 span 并发 Collector),tier2 的 studio_sink 把导出端点从 Studio 改成 Collector 的 OTLP/HTTP 入口、核对端口与 /v1/traces 口径、并按面四改掉私有 root;两条都要接住入站 context。再给 Python 侧补一个 OTLP 的 metrics exporter,把成本、token、耗时、门结果从「落盘等后端反推」升级成 metric 直发 Collector。

面三 · 部署编排与存储治理。 新增 deploy/infra/observability/ 一个 compose,把 Collector、Prometheus、Tempo、Loki、Grafana 五件起在 mini-infra(扩容后)。资源纪律要比 Nacos/RocketMQ 那套更严,因为同箱的是跨项目生产件:每个观测容器设死内存上限、同时设 CPU 限额并把进程优先级压到低于 mini-infra 的生产件,不让失控的 Prometheus/Tempo 在 CPU 和 IO 上挤兑 new-api。存储治理不能只写「存 MinIO」四个字——既有 MinIO 是 ragflow 共用实例、现有 bucket 只有 tier2 源文件,所以要给观测单独定 bucket 命名、保留期(Prometheus 7 到 15 天起步)、容量阈值配额、对象生命周期回收、MinIO 不可达时的降级(本地缓冲丢弃而非阻塞)、以及回滚时的删除策略。拓扑按跨机写、且分清拉推方向:OTLP 上报是被观测端(game-cloud、两条生成线,都在别处)主动推到 mini-infra 的 Collector;Prometheus 在 mini-infra、是它主动去 scrape 抓别处暴露的指标端点。推的端点、拉的目标各按跨机连通与余量算,别混成「都指 .8」。

面四 · 贯穿(三跳,不是两跳)。 把端到端一个 trace 串起来要改四处:Java 的 WorkerDispatchClient 出网时由 OTel agent 自动注入 traceparent(依赖面一先把 agent 装上,不是现成的);Python 的 worker_service 是裸 http.server,要手动用 propagator 从入站 header 提取 traceparent、建一个 server span;worker 打本机 AgentScope Service 那一跳的 httpx 请求要手动注入 traceparent;Service 侧让生成 span 接住这个传入的 context——便宜档主路现在是 jsonl、连 span 都没有,得先按面二让它产 OTLP span 再接 context,tier2 的 studio_sink 有 span 但私有 root、要改成读入站 context 建子 span——这样两条线的生成 span 才都挂在 Java 的 trace 下;回调 game-cloud 那跳同样手动注入、Java 入口提取。业务 traceId 与 W3C traceId 采「并存关联」——业务 traceId 作为 span 的一个属性保留(它承担产物归位和回调关联),W3C traceparent 负责跨语言贯穿,不强行升级业务 traceId 的格式。

面五 · 埋点。 见第 6 节。原则是能靠 agent 自动出的不手埋,只有业务语义的指标才手埋、且埋在终态收口处一次埋全。

6. 埋点清单(对着 MVP 指标)

MVP 指标	来源	信号	埋点方式	现状与注记
生成成功率 ≥80%	game-cloud aigc	metric	任务终态回填处埋 gen_task_total{status} counter	需新埋
生成耗时 P50/P95	worker / game-cloud	metric	gen_duration_seconds histogram;Python 已算 wallSec,导出	值有,需导出
队列深度	game-cloud 控制平面	metric	背压判定处埋 gen_queue_depth gauge	需新埋
九门过门率 / 各门失败	Python 九门 + 后端	metric	gen_gate_fail_total{gate},源 = verdict.guards / trace 字段	原始有,需聚合
单次生成成本 ¥	Python worker	metric	llm_cost,cost.compute 导出	⚠ 是 worker 按 token×倍率的自估值、非 new-api 权威计费流水;本期用它上指标可接受但须标降级,logs.quota 权威对账薄片保留为 follow-up,告警阈值留估算偏差余量
缓存命中率	Python worker	metric	llm_cache_hit_rate,cached token 导出	值有,需导出
服务可用性 ≥99.5%	game-cloud + Collector	metric	OTel agent 自动出 HTTP server 指标 + actuator health	需装 agent/actuator
feed 首屏 P75<3s	game-studio 前端	metric/RUM	现有业务遥测埋点已在;OTel 前端观测排三期	业务 RUM 有
new-api 多通道健康 + 批跑冻结阀	后台巡检 job	metric + 控制动作	巡检探活每通道 + 查 key 额度;可用通道掉到下限自动冻结后台批跑(2026-06 通道整批作废的直接教训,巡检与冻结阀是一套)	需新建;本期做通道巡检探活+健康指标/告警,自动冻结阀排下一期(§10.4 创始人拍)
全链路 trace	全链	trace	Java agent + Python 三跳 traceparent(面四)	便宜档主路写 jsonl 无 span、tier2 studio_sink 发 Studio 私有 root、Java 无 agent;三跳均未打通
集中日志(脱敏后)	全进程	log	Collector filelog / logback OTLP,trace_id 注入 MDC,只收 WARN/ERROR;进库前经脱敏 processor	需新建
脱敏 processor	Collector	安全红线	手机号/token 进 Tempo/Loki 前最后一道,继承《观测体系》§3.1/§5.2	必做,不能丢
SAA 图节点 span	game-cloud aigc	trace	装 micrometer 即活,但仅 dispatcher=saa 的 opt-in 进程内路有效;默认 http 路生成不跑 SAA 图、其 trace 来自 Python 线	依赖就位,限定路
admin 一键进盘	Grafana	运维入口	《观测体系》§2/§3.5 硬目标,本期落	本期做(§10.3 创始人拍)

7. 关键取舍

追踪后端 Tempo,不用 Jaeger。 同 Grafana 体系、三联下钻、存 MinIO 内存友好。

game-cloud 用 OTel Java agent 为主、micrometer bridge 收编存量。 一个参数拿全链、顺手把 SAA observation 和半死的 SkyWalking 收敛成一条 OTel。

告警件用 Grafana 统一告警,替下原稿的夜莺 Nightingale。 这是相对《观测体系》原稿的一处实质改动:既然看板已统一在 Grafana,再引夜莺会多一套要维护的组件和一份要对齐的规则,而 Grafana 自带告警规则加飞书/钉钉 webhook 已够覆盖 MVP 的阈值告警,少一个常驻件也少吃一份内存。夜莺的优势在大规模多租户告警治理,MVP 用不上。此项推翻原 canonical 的件选型,创始人 2026-07-05 评审已确认(§10.1),回写《观测体系》时落。

成本指标的权威级别是降级的,要认。 本期的 llm_cost 是 worker 自估值,不是 new-api 的实际计费流水;便宜档小于 ¥10、tier2 小于 ¥50 是硬预算,缓存漂移会让成本翻几倍,靠自估值做告警在 token 口径或倍率漂移时可能真花超了不报。所以本期标清「估值非权威」、留 logs.quota 对账薄片作 follow-up、告警阈值留余量。

采样、保留、资源上限即便扩了内存仍是纪律。 Collector 尾部采样(错误和慢 trace 全采、正常 5 到 10%),Tempo/Loki 存 MinIO,Prometheus 保留期起步 7 到 15 天,每个观测容器设内存和 CPU 双上限。扩内存是为了不 OOM,不是为了放任。

8. 旁路铁律与验收

观测栈挂掉,绝不能咬主链——硬红线。 OTel agent 异步批量上报,Collector 不可达时本地丢弃而非阻塞,埋点开关默认关、经 profile 显式开;Python 侧的 best-effort 已是既有铁律。

验收锚在六条可真跑的硬判据(继承《观测体系》§5.1、补回被弱化的几条):

1. 端到端 trace_id 一致:从响应头拿到 trace-id,能在 Grafana 里拉出贯穿 Java → Python worker → 本机 Service 生成 → 回调的单条 trace(正是 §5 面四要打通、最会断的那条)。
2. 告警真送达:造一条阈值越线(如成功率跌破 80% 或队列越限),Grafana 告警在约定时间内真落到飞书/钉钉群——换了告警件更要验这条。
3. 成本抽样对账:llm_cost 指标与一笔 new-api 实际扣费抽样比对,偏差在余量内。
4. 可用性 error budget 燃尽图与 health 探测对得上。
5. 停 Collector 主链不变:停掉 Collector 后生成主链行为不变、冒烟门全绿。
6. agent 性能量化:staging 挂 agent 压一轮,启动耗时差、P95/P99 请求耗时差、生成任务耗时差在阈值内,agent 的 queue/drop 指标可见——「冒烟绿」不足以发现 agent 注入的启动变慢和批量上报内存积压。
7. 脱敏真打码(安全红线,必须能跑):往一次生成的 brief / prompt 里注入构造的手机号和 token,跑完在 Tempo 的 span 属性和 Loki 的日志正文里都查不到明文、只见掩码——脱敏不能只写进「必做」叙述,要有这条能真跑的判据兜住,漏配即安全回退。

分波实施(每波都在扩容窗口之后,按依赖串):先起观测栈后端五件并自监控;再给 game-cloud 挂 agent 加 actuator;再重定向 Python 的 OTLP 加 metrics;再打通三跳 traceparent;最后落业务埋点、脱敏 processor、建看板和告警。前端 OTel Web SDK 排三期。

9. 风险与回滚

内存不是唯一的风险,CPU 和 IO 争用同样真:观测栈和 new-api 同箱,失控的 Prometheus/Tempo 可能在 CPU/IO 上压到生成命脉,所以每个观测容器的内存和 CPU 双上限、进程优先级低于生产件是上线即设、不留口子。第二个风险是 agent 注入对 game-cloud 启动和性能的影响,缓解是先在 staging 挂 agent 验启动加压一轮时延对比,确认开销可接受再上生产 profile(验收第 6 条兜)。第三是脱敏——trace 属性和日志正文里有用户内容,脱敏 processor 漏配就是安全回退,所以它是必做项、进验收。回滚极干净:观测是纯增量的旁路,回滚等于摘掉 agent 参数、关掉 Python 的 OTLP 地址、停观测栈 compose、按存储治理的删除策略清 MinIO bucket,主链和业务代码一行不受影响。

10. 创始人评审结论(2026-07-05 六项已拍)

1. 告警件用 Grafana 统一告警替下夜莺(§7)——✅ 拍定 Grafana 统一。看板已在 Grafana、自带告警规则加飞书/钉钉 webhook 已够覆盖 MVP 阈值告警、少一套常驻件;推翻《观测体系》canonical 的夜莺件选型,回写时落。
2. 落点反转同批改两份 canonical——✅ 落点 mini-infra 加内存(07-05 已两拍)。《观测体系》和《k8s迁移》回写是实施收口的执行动作,后者规划的 mini-desktop k3s observability 落点被本设计取代;属横切一致性主人的判断,随实施同批改。
3. admin 一键进盘本期做还是排期——✅ 本期做。《观测体系》§2 的硬目标,顺阶段四一起落,不让它在「五面」里蒸发成孤儿。
4. new-api 批跑冻结阀本期做还是排期——✅ 本期只做通道健康巡检加告警,自动冻结阀排下一期。命脉级的自动控制动作暂缓,本期先把通道可用性指标和告警这双眼睛装上;冻结阀作为已登记的 follow-up 保留,2026-06 通道整批作废的教训不丢。
5. 业务 traceId 与 W3C traceId 采并存关联(§5 面四)——✅ 并存关联。业务 traceId 作 span 属性保留(承担产物归位和回调关联),W3C traceparent 负责跨语言贯穿,不强升业务 traceId 的格式。
6. mini-infra 扩容目标规格——已实测坐实(2026-07-05 关机前):15G 机、空闲仅 427Mi、available 7.3G 全是可回收缓存、容器实占约 7.5G(ragflow 独占 3.35G 最大且 AI 件爱涨)、swap 4G 基本未用。观测栈带内存和 CPU 双上限约 3 到 4G 常驻。建议扩到 32G(下限:常驻约 11.5G 加约 20G 缓存与 spike 余量,干净解决 OOM)或 64G(一台管到底,给 ragflow 与生成负载的长期涨幅留头)。✅ 已扩容并复验(2026-07-05):创始人选 32G,mini-infra 从 15G 升到 31Gi 可用,复验整栈健康——used 6.7Gi、free 20Gi、available 24Gi(扩前仅 427Mi),12 容器全回来零异常退出(minio/mysql/postgres/redis/nginx/new-api 均 healthy),Nacos readiness 200。观测栈 3 到 4G 常驻装进 24Gi 余量绰绰有余、OOM 风险解除。本项收口:实施落 mini-infra、内存维度已备;CPU/IO 隔离纪律(§5 面三、§9)与跨机拓扑仍按设计执行。