Absolute labels for specific metric types (is this a thing?)

Hello everyone

I’m responsible for part of the integration with Prometheus within my organization. Basiclaly, once a client connects their Prometheus instance to our service, we get access to the list of all metrics they have stored.

In summary: My job is to automate some query creation in promQL to build other, more insightfull metrics, but I’m having some conceptual doubts which i feel should be pretty easy to answer by someone with some experience.

*From my standpoint, how can i distinguish an histogram from a summary? Is it by its labels? Meaning summaries always have “quantile” labels and histograms always have “le” labels, (meaning less or equal to).

I’m making this assumption based on the prometheus self-monitorization metric list (which i use as an example bellow).

I’d just like to understand how much of this is internal to prometheus and and how much is open to changes according to each one’s configuration.

If these label keys are configurable by each one’s personal configuration, than is there a way to distinguish between summaries and histograms at all from my standpoint? Something that’s true regardless of the configuration / instrumentation procedure?

If you feel that, there’s a piece of documentation that I’m missing here (or an article or something) please share, I’ve been digging into the docs, but haven’t found particular answers for this.

E.g.

Sumary metric

prometheus_engine_query_duration_seconds{slice="inner_eval",quantile="0.5"}
prometheus_engine_query_duration_seconds{slice="inner_eval",quantile="0.9"}
prometheus_engine_query_duration_seconds{slice="inner_eval",quantile="0.99"}
 (...)

Histogram metric

metricprometheus_http_request_duration_seconds_bucket{handler="/-/ready",le="0.1"}
prometheus_http_request_duration_seconds_bucket{handler="/-/ready",le="0.2"}
prometheus_http_request_duration_seconds_bucket{handler="/-/ready",le="0.4"}
(...)

Happy coding everyone ^.^

“le” is hardcoded in some PromQL function, quantile, quantile_over_time.

Overall, I’d suggest try to keep the semantics as close as the best practices you have found.

On disk however, every line is considered a different metric. We expose the type in API, but I do not think it is persisted on disk.