Go flight recorder 如何保留故障前后的运行轨迹

Go 服务的慢请求常常不是在触发告警的那一刻才开始的：某个 goroutine 可能早已持有锁、等待网络或阻塞在调度队列里。普通 runtime/trace.Start 适合测试和短命令，但长时间运行的 Web 服务无法等故障发生后再启动追踪。Go flight recorder 的做法是持续把最近一段执行轨迹保留在内存中，发现异常时再把这段故障前窗口写成快照。

官方地址：https://go.dev/blog/flight-recorder

一、flight recorder 保存的是故障前窗口

flight recorder 使用执行追踪数据，但不把从进程启动以来的全部内容写入文件，而是缓存最近几秒的轨迹。程序检测到超时、健康检查失败或队列延迟升高时，可以立即请求快照，拿到“问题发生前正在做什么”的证据。

这和持续采样所有实例不同：后者需要保存大量通常没有异常的数据；flight recorder 把诊断重点放在单个实例检测到故障前后的窄窗口。它适合定位延迟尖峰、锁等待、goroutine 互相等待等“发生过但已经结束”的问题。

二、按故障窗口配置 MinAge 与 MaxBytes

MinAge 应覆盖你想回看的时间，不能只填一个刚好等于超时时间的值。比如 5 秒超时，触发前可能还有排队和依赖调用，先保留约 10 秒更容易看出因果。MaxBytes 则限制内存占用，繁忙服务的 trace 产生速度可能很高，最终值要结合实例内存和触发频率压测。

fr := trace.NewFlightRecorder(trace.FlightRecorderConfig{
    // 保留足够长的故障前窗口，示例按 5 秒超时预留 10 秒。
    MinAge: 10 * time.Second,
    // 这是内存预算，避免诊断组件挤压业务堆空间。
    MaxBytes: 16 

配置过小会让快照缺少触发点之前的上下文；配置过大则会放大每个实例的内存成本。先按一个实例灰度，并把快照大小、写出耗时和磁盘剩余空间纳入监控。

三、慢请求出现时只写出一次快照

触发条件应该来自服务已有的信号，例如请求耗时超过阈值。快照写出可能与多个慢请求同时发生，所以需要 sync.Once 做单次保护。写入成功后再停止 recorder，避免后续请求继续改变这次诊断窗口。

var snapshotOnce sync.Once

func writeSnapshot(fr *trace.FlightRecorder, path string) {
    snapshotOnce.Do(func() {
        // 只允许一次触发，防止多个慢请求并发写同一个文件。
        file, err := os.Create(path)
        if err != nil {
            log.Printf("create trace snapshot: %v", err)
            return
        }
        defer file.Close() // 关闭文件，确保句柄及时释放
        if _, err := fr.WriteTo(file); err != nil {
            log.Printf("write trace snapshot: %v", err)
            return
        }
        // 快照完成后停止滚动记录，保留本次故障窗口。
        fr.Stop()
        log.Printf("trace snapshot written: %s", path)
    })
}

// 在请求结束处检查阈值，异步写出避免阻塞响应路径。
if fr.Enabled() && time.Since(start) > 100*time.Millisecond {
    go writeSnapshot(fr, "snapshot.trace")
}

示例中的文件名只适合单实例演示。生产环境要使用带实例标识和时间的临时文件，再由专门上传或归档逻辑转移，避免多个进程、容器重启或只读文件系统互相覆盖。

四、用 go tool trace 读取快照

拿到 snapshot.trace 后运行：

# 用 Go 工具链启动本地 trace 分析服务。
go tool trace snapshot.trace

先看 STATS 中的线程、堆和 goroutine 概况，再看 PROCS 了解 goroutine 如何映射到处理器。遇到明显空档时放大时间区域，然后沿 flow events 追踪哪个 goroutine 让另一个 goroutine 开始运行或继续等待。执行追踪包含 goroutine 创建、阻塞、唤醒、系统调用和 GC 等事件，适合把“慢”还原为可定位的等待关系。

例如一个报告 goroutine 在循环里对每个 bucket 加锁，却把 Unlock 放在循环体中的 defer，锁就会拖到整个函数返回才释放。trace 看到的不是一句抽象的“性能下降”，而是其他 goroutine 在同一段时间被这条关系阻塞。

五、生产环境的文件、频率与隐私边界

flight recorder 是诊断工具，不是持续日志系统，也不能保证每次故障都能留下完整快照。遇到没有写权限、进程被强制终止或窗口设置过短时，仍要依靠指标、日志和 profile 互相补足。

相关问题

flight recorder 会保存整个进程生命周期吗？

不会。它主要保留最近一段执行轨迹，触发时导出故障前窗口，避免长期服务产生无限增长的 trace 文件。

为什么快照里看不到最早的阻塞原因？

通常是 MinAge 太短或 MaxBytes 太小。先扩大窗口和预算，再根据实例内存做灰度调整。

可以每个慢请求都写一个 trace 吗？

不建议。使用单次触发和冷却策略，先保存最有代表性的窗口，再把指标与日志用于判断是否需要下一次采集。