为延迟尖峰配置低开销 flight recorder

长时间运行的 Go 服务遇到偶发延迟尖峰时，等问题发生后再调用 trace.Start 往往已经晚了。更合适的做法是提前启动 Flight Recorder，让它在内存中循环保留最近一段 execution trace；当请求超过阈值时，再把这段窗口写成快照。

官方资料：https://go.dev/blog/flight-recorder

低开销的关键不是把缓冲区设得越小越好，而是让 MinAge 覆盖一次异常的前后文，再用 MaxBytes 约束内存，并用 sync.Once 防止尖峰期间重复写盘。

先按故障窗口选择保留范围

持续 execution trace 适合测试或短命令，但在线服务无法一直把完整轨迹写到文件。Flight Recorder 仍在收集 trace，只是把最近的数据保存在内存里；触发时通过 WriteTo 固化某个时间窗口。

MinAge 表示希望可靠保留的时间长度。比如接口通常在 5 秒内超时，可以先把它设为 10 秒左右；若问题只持续几百毫秒，就不必把窗口盲目放大。MaxBytes 是缓冲上限，用来防止高负载服务因诊断数据扩大内存预算。

用有限缓冲启动 Flight Recorder

下面的初始化把“保留多久”和“最多占多少内存”分开配置。服务生命周期结束时调用 Stop，避免后台收集继续存在。

package main

import (
    "log"
    "runtime/trace"
    "time"
)

func newRecorder() *trace.FlightRecorder {
    fr := trace.NewFlightRecorder(trace.FlightRecorderConfig{
        MinAge:   10 * time.Second, // 覆盖一次 5 秒级超时的前后文
        MaxBytes: 8 

这里的数值只是起点：高吞吐服务应结合实例内存和 trace 产生速度压测；不能把“低开销”理解成零成本，也不能用一个固定的 MaxBytes 覆盖所有部署规格。

在延迟阈值处只写出一次快照

快照动作放在请求已经完成计时的位置，避免每次慢请求都创建文件。sync.Once 让同一进程只处理第一次触发，写盘错误也要记录，便于区分“没有触发”和“触发但保存失败”。

var snapshotOnce sync.Once

func captureSnapshot(fr *trace.FlightRecorder, path string) {
    snapshotOnce.Do(func() {
        file, err := os.Create(path)
        if err != nil {
            log.Printf("create trace snapshot failed: %v", err) // 权限或目录错误要留痕
            return
        }
        defer file.Close() // 关闭文件让快照完整落盘

        if _, err := fr.WriteTo(file); err != nil {
            log.Printf("write trace snapshot failed: %v", err) // 不把写盘失败误判成无尖峰
            return
        }
        fr.Stop() // 快照完成后停止继续占用诊断缓冲
        log.Printf("trace snapshot saved: %s", path)
    })
}

func observeLatency(fr *trace.FlightRecorder, started time.Time) {
    if fr.Enabled() && time.Since(started) > 120*time.Millisecond {
        go captureSnapshot(fr, "latency-spike.trace") // 异步写盘，避免阻塞响应收尾
    }
}

示例省略了 HTTP handler 的业务代码，但触发点应使用同一请求的开始时间和完成时间。若快照文件名需要按实例区分，应在外层注入唯一目录；不要在 captureSnapshot 内用时间戳绕过 Once。

快照落盘后的排查边界

先确认 fr.Enabled() 仍为真，再确认 WriteTo 的目标目录可写。快照成功后可用 go tool trace latency-spike.trace 打开执行轨迹，重点观察 goroutine 的阻塞、唤醒和相互影响；它不是 CPU profile，不能只盯着函数耗时排名。

# 使用 Go 工具链打开已落盘的执行轨迹
go tool trace latency-spike.trace

生产环境还要明确三条边界：服务重启会丢失内存中的历史；过小的 MinAge 可能截断根因之前的等待；只保存第一份快照意味着后续尖峰不会自动生成第二个文件。若要长期收集多次事件，应在外层设计轮换、采样和权限控制，而不是简单移除 sync.Once。

相关问题

Flight Recorder 会替代所有 pprof 吗？不会。它记录 execution trace 的调度和协作线索，适合回答“延迟前发生了什么”；CPU、堆和 goroutine profile 仍用于各自的热点与资源问题。

为什么快照文件为空或打不开？优先检查目标目录权限、WriteTo 返回的错误、文件是否在进程退出前关闭，以及 trace 是否在触发前已经启动。

阈值应该设多大？以业务 SLO 和尖峰持续时间为基准，先覆盖一次异常的完整上下文，再用日志或指标调整，不要直接照搬示例中的 120 毫秒。