updated new namespacing to support suffixes instead of prefixes #215

Open
wants to merge 2 commits into
from

Projects

None yet

5 participants

@keen99
keen99 commented Dec 17, 2012

updated new namespacing to support suffixes instead of prefixes - allows easier grouping by incoming key.

configurable as an alternative to prefixes (except for statsd stats themselves)

david raistrick updated new namespacing to support prefixes instead of suffixes - all…
…ows easier grouping by incoming key
53cc84a
@keen99
keen99 commented Jan 8, 2013

found an interesting bug in carbon/whisper that could be hit with this patch.

if you send two keys through statsd:

gork as a gauge
gork.gauges as a [timer/counter/set]

carbon will create after statsd's magic:

statsd/gork/gauges.wsp
statsd/gork/gauges/counter/count.wsp
statsd/gork/gauges/counter/rate.wsp

the problem comes in that neither the graphite browser nor the graphite graphite engine can display gork/gauges.wsp at this point - the existence of the directory with the same name as the final part of the key blocks it.

renaming the directory (to remove the conflict) shows that the data itself is written out and not lost and is gauges.wsp is now graphable - but this could create significant confusion for any user who hasn't spent a lot of time under the hood.

I'll submit a patch shortly to suffix gauges with a gauges directory, the same as the other 3 data types.

@mrtazz
Member
mrtazz commented Jan 14, 2013

Can you give a good use case for this? It feels like it's making the storage paths much more confusing, especially since you can easily do wildcard matching in graphite.

@keen99
keen99 commented Jan 14, 2013

When my team and I first reviewed statsd (0.5.0 tag), and before the new prefix namespacing, we all found that the data structure that statsd used once it landed in carbon to be completely baffling. So we sat down and came up with a plan for what made sense for us and our data.... and wrote it. Then the prefix namespacing came in, so we rewrote it to work with that.

Wildcards are great, but they're only 1 level of dots deep.

We found it much easier to drill down (in graphite-web) and find the key we want (which could be any combination of hostname, game platform, application environment, etc) if the data were grouped by the keys -we- send, instead of being spread out (with prefix) into (for now! future would add more) 4 different trees. Particularly if we're using a mix of counters, sets, gauges, and timers for the same application.

to make one example (and noting that we're still building and testing, so primarily we're trying to build pieces that match things we already have)

One of our cacti poller boxes reports:

elapsed time for all pollers - timer
number of hosts - gauge
number of datasources - gauge
RRDS processed - gauge

so with prefix we'd have (off the top of my head):

statsd/timers/12345-uk2-r-c5/example/com/cacti/elapsedtime/[count,min,max,etc]
statsd/gauges/12345-uk2-r-c5/example/com/cacti/[hosts,datasources,rrds]

So when exploring for a stat, we have to drill down through two top level trees to associate the two pieces. If you didn't know how the data was being sent, you might never know to look in both trees.

Instead, with suffix, we get:

statsd/12345-uk2-r-c5/example/com/cacti/elapsedtime/timers/[count,etc]
statsd/12345-uk2-r-c5/example/com/cacti/rrds/gauges/gauge
statsd/12345-uk2-r-c5/example/com/cacti/datasources/gauges/gauge
statsd/12345-uk2-r-c5/example/com/cacti/hosts/gauges/gauge

So all data associated with the host, and the application, are in the same place.

May not work for everyone - obviously legacy and prefix work for someone! :) But seems like a worthwhile option. Leastwise it works so far for us!

@keen99 keen99 pushed a commit to keen99/statsd that referenced this pull request Jan 29, 2013
david raistrick Merge PR #215 -
     updated new namespacing to support prefixes instead of
     suffixes - allows easier grouping by incoming key
     configurable as an alternative to prefixes (except for
     statsd stats themselves)
0640c4f
@timbunce

I don't have a comment on this particular implementation, but I do agree that splitting by type near the top of the namespace tree makes working with the stats in graphite significantly harder.

@mheffner

One alternative to adding another mutually exclusive configuration mode, which seems like it could begin to get complicated, would be to add some type of metric name format string, like:

Original: metric_name_format: "{prefix}.{type_prefix}.{metric}.{stat}"
Suffix form: metric_name_format: "{prefix}.{metric}.{type_prefix}.{stat}"

@Savar
Savar commented May 17, 2013

Is there any update on this? We also came to the conclusion that it is much more logical to suffix it. The option would be great.

@keen99
keen99 commented May 24, 2013

happy to spend the time to update for a clean merge if wanted.. I don't disagree with mheffner's idea, either, but don't know that I'm up for that particular task.. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment