search

prometheus / client_golang

Prometheus instrumentation library for Go applications
https://pkg.go.dev/github.com/prometheus/client_golang
Apache License 2.0
5.43k stars 1.18k forks source link

Remove namespace/subsystem #240

Open fabxc opened 8 years ago

fabxc commented 8 years ago

They are internally concatenated to a plain metric name. The protobuf, which is always mentioned as the canonical representation of a metric, doesn't support it either. It's also an arbitrary hierarchy that's not generally applicable.

We essentially instrument at a higher abstraction level than we can ever get out the instrumentation. It's just overhead for developers and makes it hard to search code for metrics.

If users want the convenience strings.Join(hierarchry, "_") is something everyone can write their own helper for.

brian-brazil commented 8 years ago

As I've indicated elsewhere I'm not the biggest fan of namespace/subsystem due to greppability.

They are however heavily used, so we'd need to consider the deprecation path.

beorn7 commented 8 years ago

Deprecation path is easy. As the usage is optional, we could declare in deprecated right now, and remove it at any major release of the future. We just need to be positive about the eventual removal.

Is anybody in favor of keeping it? I guess Matt is. It's mostly his legacy (not meant in a derogatory way) after all.

Personally, I'm indifferent about it. I'm using it now and then, but it's not what I would like to see if thinking about 'real' namespacing (which is not just about breaking a name into components, but also the ability to be "in" a namespace where the corresponding name component would apply implicitly). Would be neat to connect the deprecation with plans how to do "real" namespacing.

fabxc commented 8 years ago

Well, I think our querying doesn't really provide a way to "enter" a namespace and I don't really see it as necessary. There are just too many metrics that change to frequently as that such strong referencing semantics would ever be valuable.

I was, and still am, in favor of allowing the period in metric names, so I can actually express the component hierarchies in my metric names. This has no semantic implications – it's just easier to read/less ambiguous.

On Thu, Sep 29, 2016 at 1:15 PM Björn Rabenstein notifications@github.com wrote:

Deprecation path is easy. As the usage is optional, we could declare in deprecated right now, and remove it at any major release of the future. We just need to be positive about the eventual removal.

Is anybody in favor of keeping it? I guess Matt is. It's mostly his legacy (not meant in a derogatory way) after all.

Personally, I'm indifferent about it. I'm using it now and then, but it's not what I would like to see if thinking about 'real' namespacing (which is not just about breaking a name into components, but also the ability to be "in" a namespace where the corresponding name component would apply implicitly). Would be neat to connect the deprecation with plans how to do "real" namespacing.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/prometheus/client_golang/issues/240#issuecomment-250438225, or mute the thread https://github.com/notifications/unsubscribe-auth/AEuA8roZGyOyncosl1Ef1d2h3OlEqP94ks5qu53ogaJpZM4KJwR4 .

beorn7 commented 8 years ago

I mark this for the 0.10 milestone as this would be the earliest possible moment to remove namespace/subsystem.

We could still decide to remove namespace/subsystem eventually but not in 0.10, i.e. I don't want to imply we need a final decision by then.

beorn7 commented 5 years ago

I guess https://godoc.org/github.com/prometheus/client_golang/prometheus#WrapRegistererWithPrefix is the final nail in the coffin. Whoever wants some kind of “programmatic” prefixing can use that wrapped registry to achieve their goal in a way more elegant way. Whoever wants explicit metric names for greppability won't use namespace/subsystem or any other kind of prefixing anyway.

So I'd say this will definitely be done in v0.10 (which will probably soon be renamed v2 due to the adoption of Go modules).

brian-brazil commented 5 years ago

If that's the case, then I'll look to remove it from Java when I do the general OM work as that's breaking anyway, and then Python too at some point.

jeffwidman commented 5 years ago

So is namespace/subsystem deprecated and will be deleted in the future?

It appears that way, but there's been no movement on this ticket since May 3rd and not seeing any mention of deprecation in the godocs.

beorn7 commented 5 years ago

They will never be removed from v1 of the library. They will be removed in v2 of the library, but v2 will break many other things anyway (and it would be very confusing to mark all changing things as deprecated – also, it will not be possible to write non-trivial code that works with both v1 and v2).

If you want to follow the most recent wisdom, do not use namespace and subsystem. From that perspective, they are deprecated.