用 httpsnoop 无损包装 http.ResponseWriterGo HTTP 指标采集的正确姿势以 inngest 实践为例【免费下载链接】inngestThe leading workflow orchestration platform. Run stateful step functions and AI workflows on serverless, servers, or the edge.项目地址: https://gitcode.com/GitHub_Trending/in/inngest导读本指南围绕 Go 生态中专门用于捕获 HTTP 指标响应状态码、响应耗时、写入字节数的库httpsnoop展开讲解其无损包装http.ResponseWriter的核心设计——它既能拦截Write、WriteHeader等方法的调用以采集指标又完整保留原ResponseWriter实现的全部附加接口避免破坏应用中依赖http.Flusher、http.Hijacker、http.Pusher等接口的正常逻辑。文章会带你从CaptureMetrics的快速上手一路深入到WrapHooks的底层原理并结合开源工作流编排平台 inngest 在 pkg/api/metrics.go 中的真实接入方式读完你即可在自己的 HTTP 服务中实现零副作用、开销可忽略的请求指标埋点。本文基于 inngest 仓库 vendored 的 httpsnoop 源码展开相关文件位于 vendor/github.com/felixge/httpsnoop/核心实现见 capture_metrics.go 与 wrap_generated_gteq_1.8.go。为什么给 ResponseWriter 加个包装如此危险在 Go 中http.ResponseWriter是一个接口而真实的响应写入器往往不只是http.ResponseWriter。以 Go 1.8 为例底层实现还常常附带以下附加接口附加接口用途http.Flusher刷新缓冲区HTTP/1.1 与 HTTP/2 下均可能用到SSE 流式响应依赖它http.CloseNotifier通知客户端连接关闭Go 1.20 起已废弃但历史代码仍存在http.Hijacker劫持底层 TCP 连接WebSocket 升级等场景依赖http.PusherHTTP/2 Server Pushio.ReaderFrom从io.Reader直接拷贝数据到响应体io.Copy针对它做优化问题在于中间件/包装器想拦截Write、WriteHeader就必须自定义一个结构体实现http.ResponseWriter接口而一旦这么做这个包装结构体默认不会实现上面这些附加接口——应用层如果对这些接口做了类型断言w.(http.Flusher)包装后就会断言失败从而产生难以排查的细微 bug比如流式响应不再 flush、WebSocket 握手失败。两种常见的暴力解法各有隐患只实现http.ResponseWriter的朴素包装隐藏了所有附加接口破坏依赖这些接口的应用逻辑一次性实现全部附加接口的结构体一方面当底层ResponseWriter并没有实现某个接口时你很难伪造其行为例如没有底层连接可劫持时Hijack根本无法工作另一方面应用可能会因为检测到这些接口的存在而改变行为例如检测到io.ReaderFrom就改用io.Copy假装支持反而更危险。httpsnoop 给出的方案非常直接先探测底层ResponseWriter到底实现了哪些附加接口再返回一个只实现完全一致接口集合的包装结构体。这正是 wrap_generated_gteq_1.8.go 里Wrap函数做的事。快速上手用 CaptureMetrics 记录每个请求httpsnoop 对外暴露的最上层 API 是CaptureMetricsREADME 中给出的典型用法是把它包在一个http.HandlerFunc里对任意 handler 做日志/指标采集// myH 是应用已有的 http.Handler可能是 http.ServeMux 或任何路由 var myH http.Handler // wrappedH 包装 myH为每个请求记录日志 wrappedH : http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { m : httpsnoop.CaptureMetrics(myH, w, r) log.Printf( %s %s (code%d dt%s written%d), r.Method, r.URL, m.Code, m.Duration, m.Written, ) }) http.ListenAndServe(:8080, wrappedH)运行后每个请求会输出类似GET /api/events (code200 dt12.3ms written512)的日志。这段代码之所以能安全运行是因为CaptureMetrics内部走的是Wrap返回的包装器与传入的w实现了完全相同的接口集合后续链路中任何类型断言都不会因包装而失效。核心 API 拆解Metrics 结构与三个 Capture 入口Metrics是采集结果的数据结构定义在 capture_metrics.gotype Metrics struct { // Code 是第一次传给 WriteHeader 的 HTTP 状态码 // 如果从未调用 WriteHeader则默认取 200。 Code int // Duration 是执行 handler 所花费的时间。 Duration time.Duration // Written 是 Write 或 ReadFrom 成功写入的字节数。 // 注意ResponseWriter 直接写入底层连接的数据如响应头不计入 // 因此 Written 通常约等于响应体大小。 Written int64 }三个捕获入口对应三种使用场景// 入口 1handler 风格最常用 func CaptureMetrics(hnd http.Handler, w http.ResponseWriter, r *http.Request) Metrics // 入口 2函数风格适用于不用 http.Handler 接口的应用 func CaptureMetricsFn(w http.ResponseWriter, fn func(http.ResponseWriter)) Metrics // 入口 3方法风格允许自定义起始 Metrics 对象并可多次累加 func (m *Metrics) CaptureMetrics(w http.ResponseWriter, fn func(http.ResponseWriter))从源码可以看出三者的关系CaptureMetrics只是CaptureMetricsFn的语法糖内部包一层hnd.ServeHTTP(ww, r)而CaptureMetricsFn会先初始化m : Metrics{Code: http.StatusOK}再调用方法版入口。也就是说从未调用WriteHeader时默认记 200这一语义就体现在这里capture_metrics.go。(*Metrics).CaptureMetrics的实现则揭示了采集的核心逻辑capture_metrics.go用time.Now()记录开始时间handler 返回后通过m.Duration time.Since(start)累加耗时通过WriteHeader钩子记录状态码且仅当code不在 100~1991xx 信息响应范围内且尚未记录过时才覆盖m.Code天然处理了多次调用WriteHeader的情况通过Write与ReadFrom两个钩子累加写入字节数。底层原理Wrap 与 Hooks 的接口保真设计CaptureMetrics的一切都建立在Wrap之上。Wrap的签名与语义如下wrap_generated_gteq_1.8.gofunc Wrap(w http.ResponseWriter, hooks Hooks) http.ResponseWriter它的行为分两步探测接口集合对w依次做http.Flusher、http.CloseNotifier、http.Hijacker、io.ReaderFrom、http.Pusher五个接口的类型断言得到 5 个布尔值按组合返回包装结构体5 个布尔值共有 2^5 32 种组合源码用switch逐一展开 32 个分支每个分支返回一个匿名结构体按需嵌入Unwrapper、http.ResponseWriter以及命中的附加接口最终{rw, rw, ...}的多重赋值让rw同时以多种身份实现这些接口。换句话说无论底层实现了哪几个附加接口包装结果恰好也实现这几个不会多、不会少。这也是为什么Wrap与CaptureMetrics能够做到对应用无感。Hooks是这一切的拦截器集合可把它理解为针对目标方法的一层中间件wrap_generated_gteq_1.8.gotype Hooks struct { Header func(HeaderFunc) HeaderFunc // 拦截 Header() WriteHeader func(WriteHeaderFunc) WriteHeaderFunc // 拦截 WriteHeader(code) Write func(WriteFunc) WriteFunc // 拦截 Write(b) Flush func(FlushFunc) FlushFunc // 拦截 Flush() CloseNotify func(CloseNotifyFunc) CloseNotifyFunc Hijack func(HijackFunc) HijackFunc ReadFrom func(ReadFromFunc) ReadFromFunc Push func(PushFunc) PushFunc // 仅 Go 1.8 生成版本包含 }每个钩子的形态都是func(原始方法) 包装后的方法以Write为例rw.Write会先取底层w的Write若h.Write非空则用钩子改写它再调用改写后的函数wrap_generated_gteq_1.8.go。CaptureMetrics就是这套钩子机制的官方示例它只挂了WriteHeader、Write、ReadFrom三个钩子其余钩子留空即原样透传。两个值得注意的细节钩子只作用于底层真实存在的方法Wrap返回的结构体只会包含探测命中了的接口因此针对未支持方法的钩子会被天然忽略版本差异由构建标签隔离仓库同时维护两份生成代码——wrap_generated_gteq_1.8.go// build go1.85 个附加接口、32 种组合与 wrap_generated_lt_1.8.go// build !go1.8不含http.Pusher16 种组合。两份文件头部都标注Code generated by httpsnoop/codegen; DO NOT EDIT.说明全部组合分支是由代码生成器展开的这正是为了穷举所有接口组合、杜绝遗漏。边界情况处理三处容易被忽视的坑README 明确列举了 httpsnoop 会妥善处理的三个边界场景这也是手写包装器最容易出错的地方WriteHeader从未被调用此时Metrics.Code保持初始化时的默认值 200http.StatusOKWriteHeader被多次调用钩子内部用headerWritten标志位保证只有第一次且非 1xx的状态码被记录Write/ReadFrom一旦发生也会置位该标志符合 Gonet/http的语义并发调用与 handler 返回后的调用Duration以time.Since(start)在fn返回后计算而Code、Written的累加基于钩子闭包即使响应在ServeHTTP返回之后才被后续 goroutine 写入如异步 flush只要走的是同一个包装器上的方法统计依然生效。已知限制与 Unwrap 兜底方案README 坦诚地列出了这个包的天花板Go 标准库未来若新增附加接口当前生成的包装结构体可能遗漏作者在文档中请求社区反馈应用自定义的接口第三方框架在ResponseWriter上扩展的接口无法被自动保真。针对第二种情况httpsnoop 提供了Unwrap作为兜底// Unwrap 从零层或多层 httpsnoop 包装中取出底层的 http.ResponseWriter func Unwrap(w http.ResponseWriter) http.ResponseWriter { if rw, ok : w.(Unwrapper); ok { // 递归直到拿到非 Unwrapper 的真实对象 return Unwrap(rw.Unwrap()) } return w }Unwrapper接口Unwrap() http.ResponseWriter嵌入在每一种包装结构体中Unwrap递归剥壳后你就可以对真实ResponseWriter做任意类型断言访问 httpsnoop 没有覆盖的接口。从源码结构看这其实借鉴了 Go 1.13 起errors.Unwrap的惯例让包装可以被层层解包。性能单请求开销约 500ns可忽略不计README 中给出了作者机器上的基准测试结果BenchmarkBaseline-8 20000 94912 ns/op BenchmarkCaptureMetrics-8 20000 95461 ns/opCaptureMetrics相对裸 handler 的开销约为500ns/请求README 同时指出该数值处于基准测试的误差范围内因此可以合理认为其引入的开销绝对可以忽略。之所以这么低从源码看原因有二Wrap的接口探测只是 5 次零成本类型断言而钩子链只是多包了一层函数调用并无额外分配。实战参考inngest 如何在 API 网关层接入 httpsnoop最后看一个真实的生产级用法。inngest 将 httpsnoop 作为 vendored 依赖位于 vendor/github.com/felixge/httpsnoop/在 pkg/api/metrics.go 中实现了一个基于 chi 路由的指标中间件func (m metricsMiddleware) Middleware(next http.Handler) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { ctx : r.Context() m : httpsnoop.CaptureMetrics(next, w, r) tags : map[string]any{ method: r.Method, route: chi.RouteContext(ctx).RoutePattern(), status: m.Code, } metrics.IncrHTTPAPIRequestsCounter(ctx, metrics.CounterOpt{ PkgName: metricsPkgName, Tags: tags, }) metrics.HistogramHTTPAPIDuration(ctx, m.Duration.Milliseconds(), metrics.HistogramOpt{ PkgName: metricsPkgName, Tags: tags, }) metrics.HistogramHTTPAPIBytesWritten(ctx, m.Written, metrics.HistogramOpt{ PkgName: metricsPkgName, Tags: tags, }) }) }这段代码展示了CaptureMetrics的三个典型集成要点一次捕获、三处使用m.Code、m.Duration、m.Written分别喂给请求计数、耗时直方图、写入字节数直方图三类指标语义化标签method、route来自 chi 的RoutePattern、status组成多维标签支撑按接口维度的细粒度观测零侵入nexthandler 拿到的w是接口保真的包装器inngest 庞大的 API v2/工作流执行链路如流式响应、WebSocket、长轮询不会因埋点而行为改变。如果你的服务同样基于net/http生态chi、gin 的http.ResponseWriter兼容层、http.ServeMux等都可以照搬这套中间件 CaptureMetrics模式若你的应用不使用http.Handler接口则改用CaptureMetricsFn传入闭包即可。Licensehttpsnoop 以 MIT 协议开源许可文本见 vendor/github.com/felixge/httpsnoop/LICENSE.txt可自由用于商业与非商业项目。【免费下载链接】inngestThe leading workflow orchestration platform. Run stateful step functions and AI workflows on serverless, servers, or the edge.项目地址: https://gitcode.com/GitHub_Trending/in/inngest创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/18 2:05:07 · 阅读 1.2k 用 httpsnoop 无损包装 http.ResponseWriter：Go HTTP 指标采集的正确姿势（以 inngest 实践为例）
用 httpsnoop 无损包装 http.ResponseWriterGo HTTP 指标采集的正确姿势以 inngest 实践为例【免费下载链接】inngestThe leading workflow orchestration platform. Run stateful step functions and AI workflows on serverless, servers, or the edge.项目地址: https://gitcode.com/GitHub_Trending/in/inngest导读本指南围绕 Go 生态中专门用于捕获 HTTP 指标响应状态码、响应耗时、写入字节数的库httpsnoop展开讲解其无损包装http.ResponseWriter的核心设计——它既能拦截Write、WriteHeader等方法的调用以采集指标又完整保留原ResponseWriter实现的全部附加接口避免破坏应用中依赖http.Flusher、http.Hijacker、http.Pusher等接口的正常逻辑。文章会带你从CaptureMetrics的快速上手一路深入到WrapHooks的底层原理并结合开源工作流编排平台 inngest 在 pkg/api/metrics.go 中的真实接入方式读完你即可在自己的 HTTP 服务中实现零副作用、开销可忽略的请求指标埋点。本文基于 inngest 仓库 vendored 的 httpsnoop 源码展开相关文件位于 vendor/github.com/felixge/httpsnoop/核心实现见 capture_metrics.go 与 wrap_generated_gteq_1.8.go。为什么给 ResponseWriter 加个包装如此危险在 Go 中http.ResponseWriter是一个接口而真实的响应写入器往往不只是http.ResponseWriter。以 Go 1.8 为例底层实现还常常附带以下附加接口附加接口用途http.Flusher刷新缓冲区HTTP/1.1 与 HTTP/2 下均可能用到SSE 流式响应依赖它http.CloseNotifier通知客户端连接关闭Go 1.20 起已废弃但历史代码仍存在http.Hijacker劫持底层 TCP 连接WebSocket 升级等场景依赖http.PusherHTTP/2 Server Pushio.ReaderFrom从io.Reader直接拷贝数据到响应体io.Copy针对它做优化问题在于中间件/包装器想拦截Write、WriteHeader就必须自定义一个结构体实现http.ResponseWriter接口而一旦这么做这个包装结构体默认不会实现上面这些附加接口——应用层如果对这些接口做了类型断言w.(http.Flusher)包装后就会断言失败从而产生难以排查的细微 bug比如流式响应不再 flush、WebSocket 握手失败。两种常见的暴力解法各有隐患只实现http.ResponseWriter的朴素包装隐藏了所有附加接口破坏依赖这些接口的应用逻辑一次性实现全部附加接口的结构体一方面当底层ResponseWriter并没有实现某个接口时你很难伪造其行为例如没有底层连接可劫持时Hijack根本无法工作另一方面应用可能会因为检测到这些接口的存在而改变行为例如检测到io.ReaderFrom就改用io.Copy假装支持反而更危险。httpsnoop 给出的方案非常直接先探测底层ResponseWriter到底实现了哪些附加接口再返回一个只实现完全一致接口集合的包装结构体。这正是 wrap_generated_gteq_1.8.go 里Wrap函数做的事。快速上手用 CaptureMetrics 记录每个请求httpsnoop 对外暴露的最上层 API 是CaptureMetricsREADME 中给出的典型用法是把它包在一个http.HandlerFunc里对任意 handler 做日志/指标采集// myH 是应用已有的 http.Handler可能是 http.ServeMux 或任何路由 var myH http.Handler // wrappedH 包装 myH为每个请求记录日志 wrappedH : http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { m : httpsnoop.CaptureMetrics(myH, w, r) log.Printf( %s %s (code%d dt%s written%d), r.Method, r.URL, m.Code, m.Duration, m.Written, ) }) http.ListenAndServe(:8080, wrappedH)运行后每个请求会输出类似GET /api/events (code200 dt12.3ms written512)的日志。这段代码之所以能安全运行是因为CaptureMetrics内部走的是Wrap返回的包装器与传入的w实现了完全相同的接口集合后续链路中任何类型断言都不会因包装而失效。核心 API 拆解Metrics 结构与三个 Capture 入口Metrics是采集结果的数据结构定义在 capture_metrics.gotype Metrics struct { // Code 是第一次传给 WriteHeader 的 HTTP 状态码 // 如果从未调用 WriteHeader则默认取 200。 Code int // Duration 是执行 handler 所花费的时间。 Duration time.Duration // Written 是 Write 或 ReadFrom 成功写入的字节数。 // 注意ResponseWriter 直接写入底层连接的数据如响应头不计入 // 因此 Written 通常约等于响应体大小。 Written int64 }三个捕获入口对应三种使用场景// 入口 1handler 风格最常用 func CaptureMetrics(hnd http.Handler, w http.ResponseWriter, r *http.Request) Metrics // 入口 2函数风格适用于不用 http.Handler 接口的应用 func CaptureMetricsFn(w http.ResponseWriter, fn func(http.ResponseWriter)) Metrics // 入口 3方法风格允许自定义起始 Metrics 对象并可多次累加 func (m *Metrics) CaptureMetrics(w http.ResponseWriter, fn func(http.ResponseWriter))从源码可以看出三者的关系CaptureMetrics只是CaptureMetricsFn的语法糖内部包一层hnd.ServeHTTP(ww, r)而CaptureMetricsFn会先初始化m : Metrics{Code: http.StatusOK}再调用方法版入口。也就是说从未调用WriteHeader时默认记 200这一语义就体现在这里capture_metrics.go。(*Metrics).CaptureMetrics的实现则揭示了采集的核心逻辑capture_metrics.go用time.Now()记录开始时间handler 返回后通过m.Duration time.Since(start)累加耗时通过WriteHeader钩子记录状态码且仅当code不在 100~1991xx 信息响应范围内且尚未记录过时才覆盖m.Code天然处理了多次调用WriteHeader的情况通过Write与ReadFrom两个钩子累加写入字节数。底层原理Wrap 与 Hooks 的接口保真设计CaptureMetrics的一切都建立在Wrap之上。Wrap的签名与语义如下wrap_generated_gteq_1.8.gofunc Wrap(w http.ResponseWriter, hooks Hooks) http.ResponseWriter它的行为分两步探测接口集合对w依次做http.Flusher、http.CloseNotifier、http.Hijacker、io.ReaderFrom、http.Pusher五个接口的类型断言得到 5 个布尔值按组合返回包装结构体5 个布尔值共有 2^5 32 种组合源码用switch逐一展开 32 个分支每个分支返回一个匿名结构体按需嵌入Unwrapper、http.ResponseWriter以及命中的附加接口最终{rw, rw, ...}的多重赋值让rw同时以多种身份实现这些接口。换句话说无论底层实现了哪几个附加接口包装结果恰好也实现这几个不会多、不会少。这也是为什么Wrap与CaptureMetrics能够做到对应用无感。Hooks是这一切的拦截器集合可把它理解为针对目标方法的一层中间件wrap_generated_gteq_1.8.gotype Hooks struct { Header func(HeaderFunc) HeaderFunc // 拦截 Header() WriteHeader func(WriteHeaderFunc) WriteHeaderFunc // 拦截 WriteHeader(code) Write func(WriteFunc) WriteFunc // 拦截 Write(b) Flush func(FlushFunc) FlushFunc // 拦截 Flush() CloseNotify func(CloseNotifyFunc) CloseNotifyFunc Hijack func(HijackFunc) HijackFunc ReadFrom func(ReadFromFunc) ReadFromFunc Push func(PushFunc) PushFunc // 仅 Go 1.8 生成版本包含 }每个钩子的形态都是func(原始方法) 包装后的方法以Write为例rw.Write会先取底层w的Write若h.Write非空则用钩子改写它再调用改写后的函数wrap_generated_gteq_1.8.go。CaptureMetrics就是这套钩子机制的官方示例它只挂了WriteHeader、Write、ReadFrom三个钩子其余钩子留空即原样透传。两个值得注意的细节钩子只作用于底层真实存在的方法Wrap返回的结构体只会包含探测命中了的接口因此针对未支持方法的钩子会被天然忽略版本差异由构建标签隔离仓库同时维护两份生成代码——wrap_generated_gteq_1.8.go// build go1.85 个附加接口、32 种组合与 wrap_generated_lt_1.8.go// build !go1.8不含http.Pusher16 种组合。两份文件头部都标注Code generated by httpsnoop/codegen; DO NOT EDIT.说明全部组合分支是由代码生成器展开的这正是为了穷举所有接口组合、杜绝遗漏。边界情况处理三处容易被忽视的坑README 明确列举了 httpsnoop 会妥善处理的三个边界场景这也是手写包装器最容易出错的地方WriteHeader从未被调用此时Metrics.Code保持初始化时的默认值 200http.StatusOKWriteHeader被多次调用钩子内部用headerWritten标志位保证只有第一次且非 1xx的状态码被记录Write/ReadFrom一旦发生也会置位该标志符合 Gonet/http的语义并发调用与 handler 返回后的调用Duration以time.Since(start)在fn返回后计算而Code、Written的累加基于钩子闭包即使响应在ServeHTTP返回之后才被后续 goroutine 写入如异步 flush只要走的是同一个包装器上的方法统计依然生效。已知限制与 Unwrap 兜底方案README 坦诚地列出了这个包的天花板Go 标准库未来若新增附加接口当前生成的包装结构体可能遗漏作者在文档中请求社区反馈应用自定义的接口第三方框架在ResponseWriter上扩展的接口无法被自动保真。针对第二种情况httpsnoop 提供了Unwrap作为兜底// Unwrap 从零层或多层 httpsnoop 包装中取出底层的 http.ResponseWriter func Unwrap(w http.ResponseWriter) http.ResponseWriter { if rw, ok : w.(Unwrapper); ok { // 递归直到拿到非 Unwrapper 的真实对象 return Unwrap(rw.Unwrap()) } return w }Unwrapper接口Unwrap() http.ResponseWriter嵌入在每一种包装结构体中Unwrap递归剥壳后你就可以对真实ResponseWriter做任意类型断言访问 httpsnoop 没有覆盖的接口。从源码结构看这其实借鉴了 Go 1.13 起errors.Unwrap的惯例让包装可以被层层解包。性能单请求开销约 500ns可忽略不计README 中给出了作者机器上的基准测试结果BenchmarkBaseline-8 20000 94912 ns/op BenchmarkCaptureMetrics-8 20000 95461 ns/opCaptureMetrics相对裸 handler 的开销约为500ns/请求README 同时指出该数值处于基准测试的误差范围内因此可以合理认为其引入的开销绝对可以忽略。之所以这么低从源码看原因有二Wrap的接口探测只是 5 次零成本类型断言而钩子链只是多包了一层函数调用并无额外分配。实战参考inngest 如何在 API 网关层接入 httpsnoop最后看一个真实的生产级用法。inngest 将 httpsnoop 作为 vendored 依赖位于 vendor/github.com/felixge/httpsnoop/在 pkg/api/metrics.go 中实现了一个基于 chi 路由的指标中间件func (m metricsMiddleware) Middleware(next http.Handler) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { ctx : r.Context() m : httpsnoop.CaptureMetrics(next, w, r) tags : map[string]any{ method: r.Method, route: chi.RouteContext(ctx).RoutePattern(), status: m.Code, } metrics.IncrHTTPAPIRequestsCounter(ctx, metrics.CounterOpt{ PkgName: metricsPkgName, Tags: tags, }) metrics.HistogramHTTPAPIDuration(ctx, m.Duration.Milliseconds(), metrics.HistogramOpt{ PkgName: metricsPkgName, Tags: tags, }) metrics.HistogramHTTPAPIBytesWritten(ctx, m.Written, metrics.HistogramOpt{ PkgName: metricsPkgName, Tags: tags, }) }) }这段代码展示了CaptureMetrics的三个典型集成要点一次捕获、三处使用m.Code、m.Duration、m.Written分别喂给请求计数、耗时直方图、写入字节数直方图三类指标语义化标签method、route来自 chi 的RoutePattern、status组成多维标签支撑按接口维度的细粒度观测零侵入nexthandler 拿到的w是接口保真的包装器inngest 庞大的 API v2/工作流执行链路如流式响应、WebSocket、长轮询不会因埋点而行为改变。如果你的服务同样基于net/http生态chi、gin 的http.ResponseWriter兼容层、http.ServeMux等都可以照搬这套中间件 CaptureMetrics模式若你的应用不使用http.Handler接口则改用CaptureMetricsFn传入闭包即可。Licensehttpsnoop 以 MIT 协议开源许可文本见 vendor/github.com/felixge/httpsnoop/LICENSE.txt可自由用于商业与非商业项目。【免费下载链接】inngestThe leading workflow orchestration platform. Run stateful step functions and AI workflows on serverless, servers, or the edge.项目地址: https://gitcode.com/GitHub_Trending/in/inngest创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考