You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The query editor will provide hints for classic histogram metrics by showing the function histogram_quantile. But, when a user selects a native histogram, none of the native histogram functions are shown as hints.
If we know a metric is of a certain type, we can show a hint.
Currently there is no metadata available for native histograms so we have little to differentiate them from classic. (See grafana/alloy#547).
We know classic histograms always end in _bucket, _sum, or _count like cortex_request_duration_seconds_bucket
And a native histogram metric would have everything but the suffix. cortex_request_duration_seconds
One suggestion is that if we know there is a classic histogram available, we can identify it, remove the suffix and create a collection of native histogram metric names. We could then compare any selected metric to that collection to identify it as a native histogram. This is not as nice as simply checking the metadata for the type, but it is one idea.
*update: The above idea will not work because classic histograms will be removed and there will be nothing to compare native histograms to.
What we are left with is a metric name with no clear frontend way to identify it's type. Another solution is to create a resource-like call that queries a chosen metric and parses the response to identify the metric as a native histogram, then return this information to the frontend to provide the hint. This would not be scalable to apply to all metrics but it could provide us the hint.
We discussed this with Beorn yesterday and the best information and API currently is the metadata endpoint. If it has the type==histogram and the series doesn't end in _bucket, _count or _sum, you can be reasonably sure that it is a native histogram.
The text was updated successfully, but these errors were encountered:
The query editor will provide hints for classic histogram metrics by showing the function
histogram_quantile
. But, when a user selects a native histogram, none of the native histogram functions are shown as hints.Classic histogram
Native histogram
Native histogram function hints should include
histogram_avg no documentation link yet, just merged: prometheus/prometheus#13467
histogram_count
histogram_sum
histogram_fraction
histogram_stddev
histogram_stdvar
How to differentiate classic and native?
If we know a metric is of a certain type, we can show a hint.
Currently there is no metadata available for native histograms so we have little to differentiate them from classic. (See grafana/alloy#547).
We know classic histograms always end in
_bucket
,_sum
, or_count
likecortex_request_duration_seconds_bucket
And a native histogram metric would have everything but the suffix.
cortex_request_duration_seconds
One suggestion is that if we know there is a classic histogram available, we can identify it, remove the suffix and create a collection of native histogram metric names. We could then compare any selected metric to that collection to identify it as a native histogram. This is not as nice as simply checking the metadata for the type, but it is one idea.*update: The above idea will not work because classic histograms will be removed and there will be nothing to compare native histograms to.
What we are left with is a metric name with no clear frontend way to identify it's type. Another solution is to create a resource-like call that queries a chosen metric and parses the response to identify the metric as a native histogram, then return this information to the frontend to provide the hint. This would not be scalable to apply to all metrics but it could provide us the hint.**Additional update: use metadata and test with vanilla Prometheus see slack for more context https://raintank-corp.slack.com/archives/C02UC0KCSF4/p1713424061722829?thread_ts=1708519355.394509&cid=C02UC0KCSF4
The text was updated successfully, but these errors were encountered: