Expose the Gatherer and use new registry over prometheus default registry #7
Conversation
register.go
Outdated
|
|
||
| // Registrerer gets the registerer being used to register | ||
| // and deregister namespaces, metrics, etc with prometheus. | ||
| func Registrerer() prometheus.Registerer { |
There was a problem hiding this comment.
Is there a reason to expose this publicly?
There was a problem hiding this comment.
Actually, I just looked into it more and it can be solved in another way. It seems most libraries like to register metrics in init() w/ private vars (etcd in swarmkit for example). What can be done if those need to be exposed in say debug mode is use prometheus.Gathers (array of Gatherers) that supports combining metric families across the array.
Signed-off-by: Josh Horwitz <[email protected]>
eb9a343 to
f1898ae
Compare
|
@crosbymichael I removed |
| ) | ||
|
|
||
| // Gatherer returns the metric gatherer | ||
| func Gatherer() prometheus.Gatherer { |
There was a problem hiding this comment.
Ok, so now that these are exposed, how do you see us using them in the projects? Right now everything that is in this package is being used. There are no unused public APIs so I'm just trying to get an idea of how we are going to use this and the below function in our projects.
There was a problem hiding this comment.
Gatherer() is useful when we want to include the default registry in debug mode to export more metrics. Prometheus has a concept of Gatherers which is an []Gatherer and merges gatherers in Gather(). This would all you to combine the two registries in debug mode to export them all in /metrics.
The use case I have for Gather() is to allow sending metrics between workers & managers for aggregating container stats. Yes, you could always have the managers hit /metrics; however, the majority of those metrics potentially aren't valuable (containers not in services and daemon metrics). This would allow the worker to filter metrics to only tasks & send those over the wire saving bytes. Then you can aggregate all these in the manager and export them or send them back to a daemon for docker stats
|
ping @stevvooe Can you take a look plz? |
|
I see the use case of wanting to only reference the metrics coming through this package but I'd still like to register everything with the default prometheus registry. To tell you the trust, centralizing on a global in this package seems problematic. This package should mostly be about declaration and routing. I do see that the tests are much easier. If you look at some of my earlier tests in contribs to the prom repo, I had to decode to protos to test anything. @jhorwit2 What if we made the namespace implement |
|
@stevvooe why do you think we need to use the global prom registry. One of the problems what we have using it is that things like etcd metrics are automatically registered and show up in our output because someone imports an etcd package in our codebase. If we have our own instance of the registry we we can only output docker metrics |
|
@stevvooe Yea, having namespace implement the |
|
What i want to do is this. Have a global registry in this package that works behind the metrics.Register commands so that all docker projects can create and register their metrics and they are displayed via:
Then I want a sub registry and handler for container level metrics to replace docker stats that only shows container metrics at:
Being a new handler and a separate registry. |
|
@crosbymichael if that's what you want then it seems each namespace needs its own registry and to implement |
I just want to be a team player. I think the plan of having a central registry here is sufficient. My only concern would be that it may be complicated for docker to control the assembly of that registry. It may be better to have each upstream project export a registry and then assemble that in docker. |
|
@stevvooe yes ,i mean keep a central registry but don't use the prom packages one so that etcd and other metrics are added to it when we don't use it. Keep the Register method in this package the entrypoint for all upstream projects |
|
I think I have an idea that will make both of you happy 👼 . I'll update this PR. |
|
@jhorwit2 Are you planning to update this PR? |
|
@jhorwit2 any chance you could get this one back on track? |
closes #6
This PR provides a means to get the Registerer and Gatherer being used by the package. It also eliminates using the default prometheus registry. This means that things like the GC handler included in the default registry won't be exported on
/metricsorGather(). This gives support for the package to include it optionally (say debug mode in docker).Signed-off-by: Josh Horwitz [email protected]