Björn Rabenstein

Try it with smaller gaps, if you can still prove the point (that it estimates the stddev/stdvar correctly). Maybe the original gaps were chosen because it make the calculation very...

In principle, the testing framework should fully support `NaN` and `±Inf`, as those are just normal values for PromQL. Something like `{{sum:+Inf ...` or `{{sum:NaN count:NaN ...` should just work,...

> Also I assume in promql testing framework Histograms are by default FloatHistogram, So I think TestNativeHistogramRate and TestFloatHistogramRate will be same. Yes, I believe so. Whenever the PromQL engine...

Thank you very much. I'm on vacation this week, but this is high on my list once I'm back in action.

Note that #13999 might get merged very soon, and it will create merge conflicts. I think they will be easy to solve.

Could you verify what protocol is actually used in the Prometheus scrape? (I believe this particular aspect of OpenMetrics should be implemented correctly in Prometheus, and my suspicion here is...

> How can I verify which protocol is used? For ground truth, I would use a packet sniffer like tcpdump or Wireshark.

I have reproduced the issue now. tl;dr: @link2xt is right. The UI isn't properly creating a type hint for counters ingested via OpenMetrics. This is a UI issue. The UI...

Some musings about the question if the metadata API is behaving correctly: I think it's really problematic that the exposition format now determines how a counter is represented in the...

> I suppose we should make the metadata endpoint match the expected Prometheus name when exposing OM metrics output for counters. So you would say we should change the example...