 Blizzard
|
218fba559c
|
feat(observability): slog 日志带 trace_id，与链路双向互跳
新增 sundynix-shared/otelx/slog.go：traceHandler 包装 slog.Handler，凡 ctx 有
活跃 span 的 slog.InfoContext(ctx,...) 自动注入 trace_id/span_id；SetupSlog(服务名)
装全局 JSON slog（service 标签 + LOG_LEVEL 控级）并设默认；TraceID(ctx) 辅助取 hex。
- 三个服务 main 启动调 otelx.SetupSlog。
- gateway 访问日志 Observe() 改用 slog.InfoContext(c.Request.Context(),...)（删旧
accessLogger）→ 每条 HTTP 日志带 trace_id。
- dispatcher orchestrator.Handle 的 received/done/error 改 ctx-aware slog → 任务
执行日志带 trace_id。
- otelx 单测 5 例（注入/无 span 不注入/With() 后仍生效/级别解析）。
- production_readiness.md 1.1：可观测性三件套（metrics+logs带trace_id+traces）闭环。
验证：dispatcher「task done」日志 trace_id 拿去 Jaeger /api/traces/<id> 命中同一条
11 span/3 服务链路；gateway 访问日志亦带同一 trace_id。四模块 build+vet+test 全绿。
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
2026-06-24 12:41:33 +08:00 |
|
|
Blizzard
|
a2d184b7ec
|
feat(observability): OpenTelemetry 全链路追踪（Jaeger + NATS 跨总线传播）
新增 sundynix-shared/otelx：otelx.Init(ctx,服务名) 注册 W3C 传播器 + OTLP/HTTP
批量导出（默认 localhost:4318，docker 里的 Jaeger）；OTEL_SDK_DISABLED=true 关导出。
Jaeger 不在线 / 导出器构建失败都不阻断启动（可观测性是增益而非依赖）。
- NATS 跨进程传播（无现成中间件）：bus/trace.go 的 natsHeaderCarrier + inject/extract，
PublishTask/CallTool 注入 traceparent，ConsumeTasks/ServeTool 抽出续上 → 链路跨总线连成一棵树。
- 埋点：gateway 挂 otelgin（HTTP server span，链路根）；dispatcher task.execute →
node.<kind>（每节点，nctx 下传使工具/LLM 挂到节点下）→ llm.stream/llm.generate；
bus 自动出 tool.call(client)↔tool.serve(server) 成对跨服务 span。
- docker-compose 加 jaeger all-in-one（UI :16686，OTLP :4318）。
- 依赖修复：otlptracehttp 触发 genproto 单体(旧)vs 拆分模块 ambiguous import（milvus 拉旧版），
pin genproto 至后拆分版（go.work 工作区全局生效）。
- production_readiness.md 1.1 更新为「已实现」。
验证：真实 input→retriever→agent 任务在 Jaeger 出 14 span / 3 服务的完整树，
跨 NATS（publish→consume）、跨服务（tool.call→tool.serve）均连通，
瓶颈 kb_search 692ms、llm 1597ms 一眼可见；四模块 build+vet+test 全绿。
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
2026-06-24 11:35:08 +08:00 |
|
|
Blizzard
|
46ef3df221
|
feat(security): LLM api_key 端到端加密（AES-256-GCM，磁盘+线缆均密文）
新增 sundynix-shared/secrets：AES-256-GCM，密钥由 SUNDYNIX_SECRET_KEY 经
SHA-256 派生；密文带 enc:1: 版本前缀，历史明文行自动透传（下次保存升级为密文）。
- 网关 SaveModel 加密落库；ListModels/TestModel 解密后脱敏/探测；
空或脱敏占位的 api_key 视为「未改」→ 沿用库内既有密文（不二次加密）。
- 密文经 NATS 原样下发；消费方解密集中在 bus 层 decryptConfig
（RequestConfig + SubscribeConfigUpdated）→ dispatcher/mcp-go 零改动。
- secrets.MustHaveKeyInProd()：生产未设 SUNDYNIX_SECRET_KEY 直接 fatal，
gateway/dispatcher/mcp-go 启动各调一次（三服务须配相同密钥）。
- 修复 store.SaveModel 整行 Save 把 active 清零的旧 bug：改 Select(...).Updates
只覆盖可编辑列，改 key 不再顺手取消模型激活。
- secrets 单测：往返/空串/随机 nonce/错密钥 fail-closed/历史明文透传。
- production_readiness.md 2.1 更新为「已落地」。
验证：DB 列由明文 sk-…(35) → 密文 enc:1:…(90)；dispatcher 从密文广播解密后
model config set；真实任务 √256→16、12×12→144 打通 DeepSeek（非降级桩）。
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
2026-06-24 10:36:34 +08:00 |
|
|
Blizzard
|
9f2a059ce2
|
docs: 项目分析与生产演进蓝图
|
2026-06-23 20:52:41 +08:00 |
|