Implement tags in Statsd backend creating additional metrics

[jruere]

Would it make sense that for a given metric A, using tags, to create additional metrics for each tag?

For example, for calls:

incr('A')
incr('A', tags=dict(tag1=value1, tag2=value2))
incr('A', tags=dict(tag2=value2))

It would generate metrics:

• A.count = 3
• A.tagged.tag1.value1.count = 1
• A.tagged.tag2.value2.count = 2

[willkg]

This sounds interesting.

Maybe we should make it an optional behavior? If we did that, then maybe the statsd backend has an option "convert_tags_to_keys" which when False would ignore tags and when True would do what you're doing above.

Maybe we need to either constrain or convert values so that they conform to appropriate keys?

Maybe it makes sense to send all the combinations? So:

incr('A', tags=dict(tag1=value1, tag2=value2)

would actually send:

• A.tagged.tag1.value1.count = 1
• A.tagged.tag2.value2.count = 1
• A.tagged.tag1.value1.tag2.value2.count = 1

That gets kind of crazy with more than 2 tags, but it would let you graph tags independent of one another.

Maybe it helps to step back and figure out the use cases here? If someone is using the statsd backend, what would they be using tags for and what does the generated data need to look like in order for it to be useful?

[jruere]

Bear in mind we would be creating new metrics on different values too, so 1 metric with 1 tag could result in many server metrics, as many as values there could be. Tags are a cool feature. If I have a webapp, I could pass all query string parameters as tags in addition to the user and the web server id. This would allow me to aggregate data in any way. Implementing this feature using all the possible combination of metrics worries me about the number of combinations there could be. I'd prefer to tell the user, use all tags you want, it will not be dangerous but you can do different things in different backends. "convert_tags_to_keys" and normalizing values sounds as a good idea.

…

On 15/05/17 16:58, Will Kahn-Greene wrote: This sounds interesting. Maybe we should make it an optional behavior? If we did that, then maybe the statsd backend has an option "convert_tags_to_keys" which when False would ignore tags and when True would do what you're doing above. Maybe we need to either constrain or convert values so that they conform to appropriate keys? Maybe it makes sense to send all the combinations? So: |incr('A', tags=dict(tag1=value1, tag2=value2) | would actually send: * A.tagged.tag1.value1.count = 1 * A.tagged.tag2.value2.count = 1 * A.tagged.tag1.value1.tag2.value2.count = 1 That gets kind of crazy with more than 2 tags, but it would let you graph tags independent of one another. Maybe it helps to step back and figure out the use cases here? If someone is using the statsd backend, what would they be using tags for and what does the generated data need to look like in order for it to be useful? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#21 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABPSxqlJrfCm6Ki5kdJSAbC3YFK5KtQEks5r6Fn5gaJpZM4NafEA>.

[willkg]

@jsocol (maintainer of statsd) pointed to this:

https://statsd.readthedocs.io/en/latest/tags.html

We should take that into account when figuring out what to do here.