可观测性与错误追踪：日志、Trace 与告警闭环

三者互补：
  指标 → 发现「服务慢了」（报警）
  日志 → 查「哪个请求慢」（明细）
  追踪 → 追「慢在哪一环」（调用链）

监控：你知道要问什么（预设指标）→ 看仪表盘
可观测性：你不知道要问什么 → 随时下钻（日志+追踪+上下文）
关键：上下文（context）——每个日志带 requestId、user、service 维度

// 反例：无法检索
console.log('order created: ' + orderId)

// 正例：结构化 + 上下文
console.log(JSON.stringify({
  level: 'info',
  event: 'order.created',
  orderId,
  userId,
  requestId,      // 贯穿全链路
  service: 'orders-api',
  latencyMs: 123
}))

// 中间件生成并传播 requestId
export async function middleware(request: Request) {
  const requestId = request.headers.get('x-request-id') || crypto.randomUUID()
  request.headers.set('x-request-id', requestId)
  return NextResponse.next({ request })
}
// 每个函数日志都带 requestId → 全链路可串

debug：开发期用，生产不开（量大）
info ：关键事件（创建/更新/登出）
warn ：可恢复异常（重试/降级）
error：真实故障（带 stack + 上下文）
采样：高频 info 按比例采样，error 全量

统一采集：Logs/Metrics/Traces 统一 API 与协议
自动埋点：SDK 自动捕获 HTTP/DB/消息
导出：OTLP 协议导出到任意后端（Jaeger/Tempo/Datadog/自建）

// 初始化 OTel（Node.js）
import { NodeSDK } from '@opentelemetry/sdk-node'
import { getNodeAutoInstrumentations } from '@opentelemetry/auto-instrumentations-node'

const sdk = new NodeSDK({
  traceExporter: new OTLPTraceExporter({ url: process.env.OTEL_EXPORTER }),
  instrumentations: [getNodeAutoInstrumentations()]
})
sdk.start()

import { trace } from '@opentelemetry/api'

const tracer = trace.getTracer('payment')
export async function processOrder(orderId: string) {
  const span = tracer.startSpan('order.process')
  span.setAttribute('order.id', orderId)
  try {
    // ... 业务
    span.setStatus({ code: SpanStatusCode.OK })
  } catch (e) {
    span.setStatus({ code: SpanStatusCode.ERROR })
    span.recordException(e)
    throw e
  } finally {
    span.end()
  }
}

OTel 的价值是「一次埋点、任意后端」——避免锁定供应商
迁移后端只改 exporter 配置，埋点代码不动

挑战：函数实例瞬灭，日志散落各地
解法：平台日志（CloudWatch/Workers Logs）+ 结构化 → 聚合到集中存储
      用 requestId/version 维度检索

// 记录冷启动（模块级一次性）
const started = Date.now()
let coldStart = false
if (!globalThis.__warm) {
  globalThis.__warm = true
  coldStart = true
}
// 日志带 coldStart 标记 → 聚合看冷启动占比

边缘函数 → API → DB/第三方，每跳都是独立实例
需要 trace context（W3C traceparent）传播：
  HTTP 头带 traceparent → 下游续接 span
边缘平台（Vercel/Cloudflare）逐步内置 trace 支持

前端打包后堆栈全是压缩代码 → 用 Sourcemap 还原源码
步骤：
  1. 构建时生成 .map（不上传到 CDN，仅上传监控平台）
  2. 错误上报带堆栈 → 平台用 map 还原
  3. 关联用户/版本/路径 → 定位

// 前端错误上报（示意）
window.addEventListener('error', (e) => {
  fetch('/api/track', {
    method: 'POST',
    body: JSON.stringify({
      message: e.message,
      stack: e.error?.stack,   // 压缩堆栈 → 平台还原
      path: location.pathname,
      version: __BUILD_ID__
    })
  })
})

后端 error 日志 → 聚合平台 → 按「签名」分组（同错误合并计数）
签名 = 堆栈首几行哈希 → 快速看「哪个错误影响多少人」

P0（核心功能全挂）→ 立即告警 + 自动回滚
P1（局部功能异常）→ 告警 + 排查
P2（低影响）      → 日报合并处理
P3（噪音）        → 采样/静默

SLO（服务目标）：如「P95 延迟 < 500ms，99% 请求成功」
SLI（度量）：错误率、延迟、可用性
SLO 是「可量化的质量契约」→ 触发时即告警

好的告警：指向问题、可行动、不噪音
规则示例：
  错误率 5xx > 1%（5 分钟）→ 告警
  P95 延迟 > 基线 2 倍（10 分钟）→ 告警
  SLO 烧钱率 > 阈值 → 告警

反模式：告警疲劳（阈值过敏感）→ 会被忽略

告警 → 定位（日志+追踪下钻）→ 修复 → 验证 → 复盘
闭环要求：每条告警有「runbook」（如何排查）

观测层：日志 + 指标 + 追踪（OTel 统一采集）
分析层：聚合、分组、下钻（requestId 串链路）
决策层：告警 + SLO + 看板
行动层：回滚 / 降级 / 扩容 / 修复
反馈层：复盘 → 补指标 / 补告警 → 持续改进

核心链路：用户请求 → 边缘（trace）→ 函数（log+metric）→ 数据库（span）
→ 平台聚合 → 报警 → 定位 → 修复

1. 全站埋点（OTel + RUM）
2. 集中日志（结构化 + requestId）
3. 关键指标看板（错误率/P95/可用性）
4. SLO + 分级告警
5. Sourcemap 还原 + 签名聚合
6. 告警 runbook + 自动回滚兜底

日志量指数增长 → 存储贵
Trace 全量采样 → 昂贵
告警噪音 → 人效下降

日志可能含 PII（用户信息）→ 脱敏后再存储
保留策略符合合规（GDPR 等）→ 限 TTL
敏感字段不进日志（密码/token）