企业官网建设流程全解析

1. 阶段回顾：我们从哪里来到哪里去
2. 大模型链路追踪体系全景
3. 落地路线图（五步走）
4. 埋点规范与统一标签
5. 告警与 SLO 设计
6. 成本与性能的平衡
7. 避坑清单与团队最佳实践
8. 下一步演进方向

1. 阶段回顾：我们从哪里来到哪里去

第 46 阶段用 20 篇内容，构建了一条完整的"大模型调用链路追踪 + SkyWalking 排查线上性能"能力线。前 15 篇打基础（SkyWalking 原理、Agent 接入、Trace/拓扑/告警、大模型专属埋点），本阶段（16-20 篇）把它升级为生产级可观测体系：

• **第 16 篇**：接入 Prometheus/Grafana，建立"指标 + 链路"双维度观测。
• **第 17 篇**：打通 ELK，实现 Trace 与 Log 的双向全链路日志追溯。
• **第 18 篇**：用一个真实大模型超时案例，把三件套用起来完成定位。
• **第 19 篇**：把定位沉淀为"观测→方案→改造→验证→沉淀"的性能优化闭环。
• **第 20 篇（本篇）**：站在落地视角，给出体系全景、路线图与最佳实践。

一句话总结本阶段价值：**从"会看一条 Trace"进化到"用指标发现、用链路定位、用日志还原、用闭环优化"的工程化体系**。

2. 大模型链路追踪体系全景

完整的体系由四层组成，自底向上：

数据流向：应用 → Agent 上报 → OAP（链路+指标）→ 一份给 SkyWalking UI 做链路下钻，一份经 `/prometheus` 给 Prometheus 做指标，日志经 Filebeat → ES 供 Kibana 按 tid 检索。三者通过 `trace_id` 与统一标签（`service/model/endpoint`）关联。

应用 ─Agent─> OAP ──> SkyWalking UI (链路/拓扑)
│
└─/prometheus─> Prometheus ─> Grafana (指标大盘)
日志 ─Filebeat─> Logstash ─> ES ─> Kibana (tid 检索)
所有组件通过 trace_id + service/model 标签互链

3. 落地路线图（五步走）

不要一上来追求完美，建议分五步渐进落地：

1. **第一步：Agent 全量接入**。所有涉及大模型调用的服务挂 SkyWalking Agent，确保 `trace_id` 贯通。
2. **第二步：大模型专属埋点**。在 LLM 调用 SDK 外层用 `@Trace` / OTel 手动埋点，打 `model/retry_count/first_token_ms/token_cost` 标签。
3. **第三步：指标+日志打通**。OAP 开 Prometheus 暴露，Grafana 建大模型大盘；日志注入 `tid` 进 ELK。
4. **第四步：告警与下钻**。配置 SLO 告警（P99、重试率），SkyWalking ↔ Kibana 双向跳转。
5. **第五步：闭环优化机制**。把"观测→改造→验证→沉淀"写入发布规范，形成常态化。

每一步都应有可验证的产出（如"Grafana 能看到 P99"），而不是停留在配置层面。

4. 埋点规范与统一标签

团队必须统一埋点规范，否则跨服务关联会失效。建议的强制标签：

// 大模型调用统一 Span 标签规范
@Trace(operationName = "LLM.Infer")
public String infer(String prompt, String model) {
ActiveSpan.tag("model", model); // 模型名
ActiveSpan.tag("retry_count", "0"); // 重试次数
ActiveSpan.tag("first_token_ms", "0"); // 首字耗时
ActiveSpan.tag("token_cost", "0"); // Token 消耗(异步回填)
ActiveSpan.tag("session_id", sessionId); // 业务维度
return doInvoke(prompt);
}

统一标签清单：

注意：标签值必须是低基数的（如 `model` 取几个固定值），切忌把整段 Prompt 当标签值，否则 SkyWalking 索引爆炸。

5. 告警与 SLO 设计

告警要分层，避免"告警疲劳"：

• **指标层（Grafana）**：P99 > 2s 持续 5 分钟；重试率 > 5%；错误率 > 1%。
• **链路层（SkyWalking）**：慢端点 TopN 日报；错误链路 100% 留存。
• **日志层（ELK）**：ERROR 日志突增；包含 `timeout`/`blocked` 关键词突增。

SLO 建议（大模型客服场景参考）：

slo:
latency_p99: 3s # 端到端 P99
first_token_p95: 800ms # 首字体验
availability: 99.5% # 成功率
retry_rate: 5% # 重试率上限

用错误预算（Error Budget）管理：当周错误预算耗尽，冻结非必要发布，优先稳定性。

6. 成本与性能的平衡

大模型场景可观测性本身有成本，需要平衡：

• **链路采样**：错误 100% 存，正常按 5%~10% 采样，避免 ES 存储爆炸。
• **日志脱敏**：Prompt/回答只存哈希或摘要，不全文，控制成本 + 合规。
• **指标预聚合**：P99 用 Recording Rule 预计算，Grafana 直查，降低 Prometheus 负载。
• **Token 指标**：只记 `counter` 速率不记明细，避免高基数。

# SkyWalking 采样配置示例
agent:
sample_n_per_3_secs: 20 # 每3秒采样条数
force_sample_error_segment: true # 错误链路强制采样

7. 避坑清单与团队最佳实践

**高频坑位清单**

**团队最佳实践**

• 每个涉及 LLM 的服务必须有 SkyWalking Agent + 统一埋点，CI 卡点检查。
• 发布大模型相关变更必须灰度，观察 P99 + 重试率两个核心指标。
• 建立"大模型性能优化 checklist"，上线前逐项核对。
• 每月做一次链路复盘，清理慢端点、冗余 Span。
• 新同学入职先读本阶段 20 篇，作为排障手册。

8. 下一步演进方向

体系建好后，还有几个演进方向：

• **eBPF 无侵入追踪**：用 SkyWalking Rover 做网络层追踪，覆盖未接入 Agent 的组件。
• **LLM 专属可观测**：接入 Token 级、Prompt 级、幻觉率等更细指标，向 LLMOps 演进。
• **AIOps 根因推荐**：基于历史链路训练，异常时自动推荐根因 Span。
• **全链路压测**：用链路数据驱动容量规划与自动扩缩容（HPA 按 P99）。

**阶段结语**：第 46 阶段教会你的不只是一套工具，而是一种"用可观测数据驱动性能优化"的工程思维。当线上再出现"大模型变慢"，你已能胸有成竹地：看指标圈范围、下钻链路定慢点、搜日志还原现场、改代码闭环优化。这，就是资深 Java 工程师与线上性能问题周旋的底气。

**第 46 阶段全系列完。**