Tags/dimensions is something we would like to support. Also for Prometheus/Wavefront/Influx, etc. Needs some thinking on where to do this and how to keep back compat for statsd.

@mrice32 This might be relevant to your interests.

Didn't know that Prometheus/Wavefront/Influx supported tags as well. Changed the title of this issue to be more generic.

Thanks folks!

+1 We will definitely need this feature for our internal monitoring as well.

This one will need some design thought. When someone firmly signs up to work on it we can figure out what to do here. @mrice32 if that's you, let's chat at some point.

Yes, that will be me. Sounds good.

OK ping me offline when you are ready to work on this and we can chat and hopefully come back to this thread with a design proposal. Anyone else feel free to weigh in here with thoughts.

I just synced up with @mrice32 and after some brainstorming this is what I'm thinking about at a high level for this:

• We will always need to retain backcompat for stat backends that don't supporting tagging.
• Instead of having tagging/not-tagging be built throughout the code, it would be better if tagging is orthogonal to the main stats.
• We propose adding the ability to specify tag extraction via effectively regex capture expressions. For example cluster..foo.bar.baz would capture the cluster name as a tag.
• Because of how heavily cached stats are, we can do tag extraction when stats are first created (for some of the dynamic stats we might want to have them pre-cached on the scope also).
• Then when stats are sent to sinks, sinks will have access to full hierarchical name, as well as tag extracted name.

I think this approach balances efficiency, user configuration, and backcompat.

Please comment!