> I don't think anything is strictly reserved. As Bryan Boreham mentioned on > the issue, Prometheus simply prefixes `instance` and `job` with `exported_` > (unless `honor_labels` is set to true), so that is handled deliberately.
Cool, thanks for confirming. I think we have some restrictions to remove from the Ruby client in that case. > In other words: It's helpful if instrumentation libraries don't let you use a > `quantile` label on a summary or an `le` label on a histogram, but it's > totally fine to use those labels on a counter or gauge (or `quantile` on a > histogram and `le` on a summary). That makes sense. I just checked and we do reserve those two (`quantile` and `le`) in the appropriate contexts. I'm going have a quick check to make sure it doesn't break any assumptions we've made elsewhere in the client (I'm thinking about our on-disk metric storage for multi-process servers in particular) and then remove `instance` and `job` from the set of reserved labels. `pid` is going to be more complicated. Any type of metric can be configured to report a separate value for each process in a multi-process server (gauges do by default, but others can be confiured that way). I think we can loosen the restriction on `pid` to be dependent on the `aggregation` specified for the metric, but I want to be really sure I'm not introducing weird edge case bugs by doing so. I'm going to defer changes to `pid` to a future PR in the interest of fixing `instance` and `job` sooner. -- You received this message because you are subscribed to the Google Groups "Prometheus Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/08db5a98-cedc-4ae2-8d8d-da49648daa03n%40googlegroups.com.
