Remove namespace/subsystem

[fabxc]

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]

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]

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]

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
#240 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEuA8roZGyOyncosl1Ef1d2h3OlEqP94ks5qu53ogaJpZM4KJwR4
.

[beorn7]

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.