用 Prometheus 扩展 HTTP/3 网络探测能力

Slack Engineerin15 小时前

分享到

背景：HTTP/3 迁移带来的可观测性缺口

Slack 此前采用混合方式进行网络测量：一部分覆盖内部流量，例如 AWS 可用区之间的通信；另一部分覆盖外部流量，例如从公网进入其基础设施的访问。相关工具包括商业 SaaS 可观测性产品，以及内部团队长期构建的定制化网络测试方案。

在边缘层开始推出 HTTP/3 支持后，一个关键问题出现了：缺少客户端侧可观测性。

HTTP/3 构建在 QUIC 传输协议之上，使用 UDP，而不是传统的 TCP。这一底层传输方式的变化，使得既有监控工具和 SaaS 方案无法直接对新的 HTTP/3 端点进行探测并采集指标。

当时存在两个明显限制：

调研过的 SaaS 可观测性工具都不支持开箱即用的 HTTP/3 探测。
内部使用的 Prometheus Blackbox Exporter 是监控体系的重要组成部分，但它没有原生 QUIC 支持。

如果无法探测新基础设施中的大量 HTTP/3 端点，团队就难以获得所需的客户端侧视角，也无法有效监控是否回退到 HTTP/2，或准确测量往返时延。

方案：为 Blackbox Exporter 增加 QUIC 支持

实习生 Sebastian Feliciano 负责界定范围、实现功能，并最终将 QUIC 支持贡献给 Prometheus Blackbox Exporter。

选择 HTTP 客户端

第一步是选择一个支持 QUIC 的 HTTP 客户端。经过评估，团队选择了 quic-go 作为新功能的基础。选择它的原因包括：

在多个开源技术中已有较广泛使用；
对 Go 语言中创建 HTTP 客户端提供较好的支持。

集成方式大致如下：

http3Transport := &http3.Transport{
	TLSClientConfig: tlsConfig,
	QUICConfig:      &quic.Config{},
}

client = &http.Client{
	Transport: http3Transport,
}

保持 Blackbox Exporter 的可组合性

实现新逻辑时，Sebastian 需要遵循 Blackbox Exporter 既有架构，确保新增能力仍然符合原有配置模式。最终结果是：Prometheus 中具备了可配置的 HTTP/3 探测能力。

这项能力被提交到开源项目后，也为其他正在采用 HTTP/3、但缺少探测能力的团队提供了可复用方案。

集成：在内部系统中先落地

开源功能合入通常需要时间，尤其是涉及新特性时。由于实习周期有限，Sebastian 没有等待上游流程完全结束，而是设计了一套内部系统，利用新增能力对 HTTP/3 端点进行探测。

这让团队能够在实际迁移过程中提前获得监控数据，而不是等到工具链完全成熟后再开始观察。

运维收益

统一视图

团队现在可以在 Grafana 中同时查看 HTTP/1.1、HTTP/2 和 HTTP/3 指标，便于与其他遥测数据进行关联和对比。

更可靠的告警

新的探测能力使团队可以围绕 HTTP/3 端点的健康状况和性能建立更可靠的告警。

更容易定位问题

当所有数据集中到同一个观测体系中后，HTTP/3 性能与其他指标之间的关联更容易建立，问题排查也更快。

对开源社区的价值

这项贡献不仅服务于内部迁移，也补上了 Prometheus 生态中对 HTTP/3 探测能力的一个缺口。随着 QUIC 和 HTTP/3 继续普及，类似能力对于大规模网络监控会越来越重要。

后续可能改进方向

团队提到，未来还可以继续增强相关能力，例如：

SNI 路由测试

验证边缘基础设施是否正确处理 SNI 扩展。对于共享 IP 场景，例如 CDN 或多租户负载均衡器，客户端请求特定主机名时，网关需要正确路由到目标后端，并返回匹配的 SSL 证书，以避免错误路由。

端到端路径可视化

不只判断服务是否可用，而是从监控代理到服务端点逐跳展示网络路径。这样可以更直观地定位延迟升高或丢包发生的位置。

经验总结

1. 先监控，再迁移

在迁移前把可观测性做好，可以让迁移过程更快、更可控。虽然行业趋势正在走向 QUIC，但团队仍然需要通过实际观测来验证长期投入的价值。

2. 开源贡献会产生复利

当新的关键协议出现，而现有工具链尚未完全支持时，补齐能力不仅能解决自身问题，也能让社区中的其他使用者受益。

3. 给实习生足够空间

Sebastian 的主动性和问题解决能力推动了这项工作落地，也让团队更直接地看到了黑盒监控在 QUIC 迁移中的价值。