After digging more into this, looks like the Prometheus.KestrelMetricServer doesnt support Gzip compression and thats as per the design. Here is the ISSUE from their github repo from 2019:
After considering this feature request, I have decided to reject it
from the backlog.
The reason is that there is already available the ASP.NET Core metric
server, which is significantly more flexible in what it supports,
allowing you to incorporate custom middleware (such as gzip) into the
pipeline. Please use the ASP.NET Core server for such scenarios.
The Kestrel server is kept at a minimal feature set in maintenance
mode and is unlikely to receive significant updates in future
versions.
As I see it, you have some work arounds:
WEB applications:
One possible workaround could be to use a reverse proxy, such as Nginx, to sit in front of your Kestrel server and handle the compression.
Use a different Prometheus exporter such as the Prometheus.AspNetCore package. It supports Gzip compression out of the box, so you would not need to make any additional configuration changes.
Console Applications
Manually handle the HTTP requests and responses by using the HTTPListener
Something like this:
var httpListener = new HttpListener();
httpListener.Prefixes.Add("http://localhost:9199/");
httpListener.Start();
while (httpListener.IsListening)
{
var myContext = httpListener.GetContext();
var myRequest = context.Request;
var myResponse = context.Response;
if (myRequest.Url.LocalPath == "/metrics")
{
var acceptEncoding = myRequest.Headers["Accept-Encoding"];
if (acceptEncoding != null && acceptEncoding.Contains("gzip"))
{
myResponse.Headers.Add("Content-Encoding", "gzip");
myResponse.OutputStream = new System.IO.Compression.GZipStream(response.OutputStream, System.IO.Compression.CompressionMode.Compress);
}