-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add default tags only for a specific group #19
Conversation
@@ -9,6 +9,10 @@ class Group | |||
|
|||
param :name | |||
|
|||
def default_tags |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably should be a different name since this doesn't include the default_tags of the global scope?
if group | ||
Yabeda::Tags.tag_group(group)[name] = value | ||
else | ||
Yabeda.default_tags[name] = value |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I considered updating Yabeda.default_tags
itself to be a hash of hashes and let nil be the key that accessed top level tags.
Hi! Thank you very much for the pull request! While I'm generally like the idea and want this feature to be in Yabeda, I will probably will leave some notes about API and implementation, but not today. I will take more thorough look in a few days. |
No rush on this one. I do like the idea of this functionality, but API is important. One thought I had was if groups can be nested. If so, the storage of the default tags for a given group seems more appropriate on the group. It seems like in that case then Additionally:
Some of these things made the idea a lot more complex, so I just opted to KISS with this PR. I don't mind expanding the scope and doing more changes if that is better though. |
I like nested yabeda/lib/yabeda/dsl/class_methods.rb Lines 31 to 37 in bd3b49f
However, not nested calls looks useful too. For example if someone would like to add some tags to all sidekiq-related metrics from |
lib/yabeda/dsl/class_methods.rb
Outdated
@@ -58,8 +58,12 @@ def histogram(*args, **kwargs, &block) | |||
# | |||
# @param name [Symbol] Name of default tag | |||
# @param value [String] Value of default tag | |||
def default_tag(name, value) | |||
::Yabeda.default_tags[name] = value | |||
def default_tag(name, value, group: nil) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can use this and it will work 😃
def default_tag(name, value, group: nil) | |
def default_tag(name, value, group: @group) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've pushed up a new commit (to maybe make reviewing easier). I'll squash prior to merge if it all looks good.
Some thoughts as I was working onit:
- I created a group object with a
name
ofnil
to account for the global group. with_tags
can nestwith_tags
- Named
group
's continue to be a child of the global group. Current code doesn't support deeper nesting, andYabeda.group1.group2.some_gauge.set({}, 5)
feels verbose/complicated (and probably not needed). - I got into some weird states on testing when trying to remove methods so I tried to make
Yabeda.reset!
a bit more resilient and comprehensive (so a bad test doesn't break every subsequent test). - I got the feeling that a group instance could be the evaluation context for the DSL. A group having default_tags and having metrics already feels very similar to the
Yabeda
module. If this was done, then arbitrary nesting of groups becomes easier. - The two register calls for groups and metrics was a bit confusing since they both call each other.
@@ -7,7 +7,7 @@ class Histogram < Metric | |||
option :buckets | |||
|
|||
def measure(tags, value) | |||
all_tags = ::Yabeda::Tags.build(tags) | |||
all_tags = ::Yabeda::Tags.build(tags, group) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be worth extracting this to Metric
since all three metrics have this? I don't have a good name for it since we already have tags
for just the keys.
@@ -17,15 +17,15 @@ class Metric | |||
|
|||
# Returns the value for the given label set | |||
def get(labels = {}) | |||
values[::Yabeda::Tags.build(labels)] | |||
values[::Yabeda::Tags.build(labels, group)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I ran into some confusion at first that I thought group
would be an instance of Group
as opposed to a symbol.
@Envek Any feedback or other thoughts? |
Sorry, couldn't get to it. I definitely want this feature to be in Yabeda. Hopefully will be able to review it later this week. |
lib/yabeda/group.rb
Outdated
if name | ||
Yabeda.groups[nil].default_tags.merge!(@default_tags) | ||
else | ||
@default_tags.dup | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While concept of implicit global group looks reasonable, such places to distinguish global tags from group-local ones are looking very weird.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure what you mean by 'such places?'
Looking back at this again, I think the handling of groups leaves room for user error/confusion. Given the curerent implementation of def group(group_name)
@group = group_name
return unless block_given?
yield
@group = nil
end We can configure sibling groups Yabeda.configure do
group :g1
# config
group :g2
# config
end or attempt to have nested groups Yabeda.configure do
group :g1 do
# config
group :g2 do
# config
end
# more g1 config
end The nested groups are really the same as the first situation where we create two siblings. Both default_tags and looking up metrics would be handled the same in both cases with an additional surprise that the 'more g1 config'j would apply to the global scope. I think that it would be good to raise an exception or at least warn when someone attempts to nest two groups to prevent the issue until there is a need for deeper nesting? |
Yeah, groups are somewhat messy, but it is apparently outside of scope for this pull request. Let's discuss it in #20 |
I pushed one more commit right into this pull request (yep, “allow edits from maintainers” checkbox allows to do such things) which effectively removes global group usage (but it is still there). Do you like these edits? Let's discuss! |
Yeah, this looks good to me. |
Released in 0.9.0. Thank you! |
This would fix #16