Authenticated requests for health_checks and Prometheus Metric Scraping?

Questions / Help
2

Aren’t Fly.io docs just the best? :wink:

If you read in between the lines of the blog posts (which is where Fly engs write docs) on Fly Metrics, you’d see that by declaring a [metrics] port that which is not exposed to fly-proxy (via [[services]] internal_port section of the app’s fly.toml), the corresponding prometheus path isn’t going to be reachable from the Internet. See:

You can export stats on the default Go HTTP handler (they’ll be exposed) or on a private handler on a different port or address; either way, you tell us about your metrics in fly.toml

From: Hooking up Fly Metrics.

In another blog post, Fly engs go:

In each Firecracker instance, we run our custom init, which launches the user’s application. Our Nomad driver, our init, and Firecracker conspire to establish a vsock — a host Unix domain socket that presents as a synthetic virtio device in the guest — that allows init to communicate with the host; we bundle node-exporter-type JSON stats over the vsock for Nomad to collect and relay to Vicky [the TSDB that stores metrics].

The Firecracker… VMs are all IP-addressable. If you like (and you should!), you can expose a Prometheus exporter in your app, and then tell us about it in your fly.toml

So, there is apparently a lot of Fly-specific plumbing (which only Fly’s code can do) going on before app metrics can be scraped. And so, I don’t think there’s really a need for auth.

That said, I’m not privy to the exact Fly Metrics architecture or how it has evolved (since the blog posts were written) to know for sure. Prudent to wait for Fly engs to blog to confirm this one way or the other…