Skip to content
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

Ability to change metrics setting for individual adapter #37

Merged

Conversation

Keallar
Copy link
Contributor

@Keallar Keallar commented Aug 12, 2024

Ability to change metric settings for individual adapters

Copy link
Member

@Envek Envek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey, thank you very much for your pull request!

Can you please tell more about your use case? What are you doing and why some metrics need to use only one adapter of many (and what are these?)

I believe we can figure out some nice API based on your insights.

Some thoughts:

  • Maybe option should be not only on metric but also on group level? So e.g. all rails/sidekiq/(your app) metrics can be limited to a single adapter?
  • Probably metric object should be responsible for calculation of the list of adapters it should be reported to.

Let's discuss!

.gitignore Outdated
@@ -1,5 +1,6 @@
/.bundle/
/.yardoc
/.idea/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please don't add non-project related files to project gitignore. Set up and use global gitignore file on your machine instead. See https://docs.github.com/en/get-started/getting-started-with-git/ignoring-files#configuring-ignored-files-for-all-repositories-on-your-computer

Suggested change
/.idea/

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I'll fix it

@@ -14,6 +14,7 @@ class Metric
option :per, optional: true, comment: "Per which unit is measured `unit`. E.g. `call` as in seconds per call"
option :group, optional: true, comment: "Category name for grouping metrics"
option :aggregation, optional: true, comment: "How adapters should aggregate values from different processes"
option :adapter, optional: true, comment: "Which adapter apply the indicator settings."
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's reword comment a bit for clarity:

Suggested change
option :adapter, optional: true, comment: "Which adapter apply the indicator settings."
option :adapter, optional: true, comment: "Monitoring system adapter to register metric in and report metric values to (other adapters won't be used)"

@@ -20,7 +20,7 @@ def measure(tags, value = nil)

all_tags = ::Yabeda::Tags.build(tags, group)
values[all_tags] = value
::Yabeda.adapters.each do |_, adapter|
::Yabeda.adapters.each_value do |adapter|
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't adapters also be filtered here? (and in other metric types)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, you are right! Adapters should be filtered

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe metric itself should have adapters method (that will default to all registered adapters unless limiting option specified)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll try to add it

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe we also need to test a case when adapter is registered, but metrics doesn't use it (so we need to have at least two adapters declared in spec file)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, you are right

@@ -115,6 +116,15 @@ def register_group_for(metric)

group.register_metric(metric)
end

def register_metric_for_adapters(metric)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel that this some of this logic should be in Metric class.

@Keallar
Copy link
Contributor Author

Keallar commented Aug 21, 2024

Hello! Thanks for your review!
To be honest, theres is no specific case, I just wanted to help in the development of the library that I and other uses.
About your thoughts:

  1. Good idea! I'll add this in the next commit
  2. I didn't quite understand this sentence. Can you please describe it more detail

@Keallar
Copy link
Contributor Author

Keallar commented Sep 23, 2024

@Envek, I've fixed all!

@Keallar Keallar requested a review from Envek September 30, 2024 11:23
Envek added 2 commits October 1, 2024 14:43
* master:
  Switch to RubyGems Trusted publishing in CI release workflow [ci skip]
  Update CI for rubocop and fix lint issues
  fix: railtie loading to prevent calling methods that have not yet been defined (yabeda-rb#38)
@Envek
Copy link
Member

Envek commented Oct 1, 2024

Hey @Keallar, thanks for improving the pull request!

I edited your pull request further a bit: moved more logic into Yabeda::Metric class. What do you think?

@Keallar
Copy link
Contributor Author

Keallar commented Oct 1, 2024

Hi @Envek, yes, it looks better this way. I liked your solution to define the adapters method in the Metric class.
Thanks for your improving!

@Keallar
Copy link
Contributor Author

Keallar commented Oct 1, 2024

But i need to add and fix some test cases

@Keallar
Copy link
Contributor Author

Keallar commented Oct 1, 2024

I've done

@Envek Envek merged commit 901e83f into yabeda-rb:master Oct 1, 2024
@Keallar
Copy link
Contributor Author

Keallar commented Oct 1, 2024

Thanks for cooperation!

@Envek
Copy link
Member

Envek commented Oct 2, 2024

Released in 0.13.0, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants