Slack faced a significant observability gap when rolling out HTTP/3 due to existing monitoring tools lacking QUIC support. This article details their solution: extending the Prometheus Blackbox Exporter to natively support HTTP/3 probing, enabling scalable, unified monitoring, and improved alerting across their infrastructure. It highlights the importance of observability in new protocol adoption and open-source contributions.
Read original on Slack EngineeringWhen Slack began rolling out HTTP/3 support, built on the QUIC transport protocol (which uses UDP instead of TCP), they encountered a critical observability gap. Their existing commercial SaaS offerings and custom internal tools, including the Prometheus Blackbox Exporter, lacked the capability to probe HTTP/3 endpoints. This meant they couldn't get client-side visibility for metrics like round-trip times or regressions, essential for monitoring the health and performance of their new infrastructure.
Why HTTP/3 and QUIC Pose a Monitoring Challenge
HTTP/3's reliance on QUIC (Quick UDP Internet Connections) fundamentally changes how network communication works at the transport layer. Traditional monitoring tools are often designed with TCP in mind, making them incompatible with UDP-based QUIC without specific support. This highlights a common system design challenge: adopting new protocols requires re-evaluating and potentially re-architecting supporting infrastructure like monitoring systems.
To address this, Slack chose to extend their existing Prometheus Blackbox Exporter (BBE). The core of the solution involved integrating a QUIC-capable HTTP client, specifically `quic-go` due to its widespread adoption and Go language support, into BBE's HTTP client structure. This allowed BBE to send probes over HTTP/3 and collect metrics from these endpoints.
http3Transport := &http3.Transport{
TLSClientConfig: tlsConfig,
QUICConfig: &quic.Config{},
}
client = &http.Client{
Transport: http3Transport,
}