<issue_start><issue_comment>Title: Allow apps to provide const labels for the builtin metrics provided by the client bindings.
username_0: It would be nice for an app to be able to provide its own const labels for metrics the client bindings export, e.g. `go_memstats_alloc_bytes_total`. For example, i have a dashboard that tries to show the amount of memory allocated per request, and doing this currently is painful. I had to add a dummy metric containing the const labels, and do:
```
(rate(go_memstats_alloc_bytes_total[30s]) * on (job, instance) group_left(elem) border_base_labels) 
/ on(job,instance) (sum(rate(border_input_pkts_total[30s])) by(job,instance))
```

If `go_memstats_alloc_bytes_total` instead already had the relevant const labels that would be a lot simpler to write and understand.

Doing this seems simple enough. I have a PoC here: https://github.com/username_0/client_golang/tree/binding_labels (with some hard-coded const labels just for testing). I'm happy to clean it up and send as a PR if you agree with the aim :)
<issue_comment>username_1: That sounds like you want target labels. I'm also unclear what the above query is trying to do, that multiplication seems redundant.
<issue_comment>username_0: Ok, that was a bad example :)

To give a little context, we use `elem` (aka "element ID") to identify a service instance. To have a grafana graph show (for example) the cpu usage for each element, we need to add the `elem` label to the `process_cpu_seconds_total` builtin metric, so that it can be used in the legend. We do this by having a `base_labels` metric with the `elem` label, and a value of 1, which we can then use like this:
```
rate(process_cpu_seconds_total[30s]) * on (job,instance) group_left(elem) border_base_labels{elem="elemid"}
```
Yes, it would be possible to use metric relabelling to do this on scrape, but that's strictly worse than having the metrics have the appropriate labels when they are exported in the first place. It would be nice if we could tell users "here's where our software exports prom metrics" and not also have to give them a blob of prom relabelling rules so that the labels are easy to work with.
<issue_comment>username_2: @username_0 You can do what you want with https://godoc.org/github.com/prometheus/client_golang/prometheus#WrapRegistererWith , i.e. create a registry on your own, wrap it with `WrapRegistererWith(prometheus.Labels{"elem": elemid})`, and then register the usual default collectors (like https://godoc.org/github.com/prometheus/client_golang/prometheus#NewGoCollector ) with the wrapped registry.

___However___ the fact that you _can_ do this doesn't mean you _should_ do this. See the doc comment for https://godoc.org/github.com/prometheus/client_golang/prometheus#WrapRegistererWith , which explicitly says it is not meant to add the same label to all metrics exposed.
<issue_comment>username_2: Expanding on target labels: Whatever service discovery (SD) mechanism you use also knows how to identify instances. The Prometheus config gives you many ways of extracting target labels from the information provided by the SD. That's where an identifying label for a service instance should come from.

Of course, perhaps Brian and myself just don't understand your use case properly. For that case, you can just do what you want as presented above. But please keep our words in mind to find out in time before you shoot yourself into the foot.

In any case, there is no feature missing in the client library, one way or the other, so I'm closing this issue now.

Discussions of how to configure Prometheus best should better happen in the usual community channels like on IRC (as it has already happened a bit) and on the [prometheus-users mailing list](https://groups.google.com/forum/#!forum/prometheus-users).<issue_closed>