Support for disabled metrics #1048

Merged
merged 4 commits into from Feb 15, 2017

Conversation

Projects
None yet
6 participants
@arteam
Member

arteam commented Jan 28, 2017

This is for based on the work of @phauer in #1008. The set of disabled metrics is implemented in ScheduledReporter, so all reporters have an opportunity to implement this feature, but it's not necessarily (for instance ConsoleReporter doesn't really need it). Along with the Graphite reporter, the Ganglia reporter is also updated to support of disabling sending metrics.

@arteam arteam changed the title from [WIP] Support for disabled metrics to Support for disabled metrics Feb 4, 2017

@jplock jplock added this to the 3.2.0 milestone Feb 7, 2017

@arteam

This comment has been minimized.

Show comment
Hide comment
@arteam

arteam Feb 7, 2017

Member

I think this should be good to merge. Could anybody give a review?

Member

arteam commented Feb 7, 2017

I think this should be good to merge. Could anybody give a review?

@ryantenney

This comment has been minimized.

Show comment
Hide comment
@ryantenney

ryantenney Feb 7, 2017

Member

Looks good, except that metric types are meter, timer, counter, gauge…

Member

ryantenney commented Feb 7, 2017

Looks good, except that metric types are meter, timer, counter, gauge…

@ryantenney

This comment has been minimized.

Show comment
Hide comment
@ryantenney

ryantenney Feb 7, 2017

Member

And is there a reason to go with disabledMetricTypes instead of enabledMetricTypes?

Member

ryantenney commented Feb 7, 2017

And is there a reason to go with disabledMetricTypes instead of enabledMetricTypes?

@jplock jplock added the feature label Feb 7, 2017

@arteam

This comment has been minimized.

Show comment
Hide comment
@arteam

arteam Feb 9, 2017

Member

And is there a reason to go with disabledMetricTypes instead of enabledMetricTypes?

I don't like the inverted logic too. But I think it makes sense from the the user's perspective. The user reports some metrics to its time-series database and sees that some of them are useless, because he/she doesn't use them. The user wants to disable them. For instance, Timer has 15 metrics, and most of them make sense; it would be strange to ask the user to pass a 14-sized set of metrics just to disable one.

Member

arteam commented Feb 9, 2017

And is there a reason to go with disabledMetricTypes instead of enabledMetricTypes?

I don't like the inverted logic too. But I think it makes sense from the the user's perspective. The user reports some metrics to its time-series database and sees that some of them are useless, because he/she doesn't use them. The user wants to disable them. For instance, Timer has 15 metrics, and most of them make sense; it would be strange to ask the user to pass a 14-sized set of metrics just to disable one.

@ryanrupp

This comment has been minimized.

Show comment
Hide comment
@ryanrupp

ryanrupp Feb 9, 2017

Is this only for the 3.2 branch or would it go into master/4.0 too? See the conversation in #837 and #178 - the idea that each "Metric" has a set of "Attributes" (name/value) off it. I'm not sure on the status of those but maybe instead of a MetricType enum, allow filtering by String based "attribute names" and just provide a helper class with the list of standard/known attribute names that currently exist (what is present in the MetricType enum currently). For 3.2 the enum makes sense as there's a fixed number of attributes, for 4.0 if #837 becomes a thing then this would just want to be changed to a String (suppose there'd be so many other breaking changes that it could just be worried about at that point). Anyway, thought of it when I saw the comment about "metric types".

ryanrupp commented Feb 9, 2017

Is this only for the 3.2 branch or would it go into master/4.0 too? See the conversation in #837 and #178 - the idea that each "Metric" has a set of "Attributes" (name/value) off it. I'm not sure on the status of those but maybe instead of a MetricType enum, allow filtering by String based "attribute names" and just provide a helper class with the list of standard/known attribute names that currently exist (what is present in the MetricType enum currently). For 3.2 the enum makes sense as there's a fixed number of attributes, for 4.0 if #837 becomes a thing then this would just want to be changed to a String (suppose there'd be so many other breaking changes that it could just be worried about at that point). Anyway, thought of it when I saw the comment about "metric types".

@ryantenney

This comment has been minimized.

Show comment
Hide comment
@ryantenney

ryantenney Feb 9, 2017

Member

@ryanrupp Good point. This would only go to 3.2, for exactly the reasons you mention. Also there will be some inversion of control with regard to reporters in v4 to make this sort of filtering easier to implement.

@arteam Ryan reminded me that we're calling these 'Attributes', can we rename MetricType and disabledMetricTypes to MetricAttribute and disabledMetricAttributes?

Member

ryantenney commented Feb 9, 2017

@ryanrupp Good point. This would only go to 3.2, for exactly the reasons you mention. Also there will be some inversion of control with regard to reporters in v4 to make this sort of filtering easier to implement.

@arteam Ryan reminded me that we're calling these 'Attributes', can we rename MetricType and disabledMetricTypes to MetricAttribute and disabledMetricAttributes?

@arteam

This comment has been minimized.

Show comment
Hide comment
@arteam

arteam Feb 9, 2017

Member

That's a good suggestion. Renamed MetricType to MetricAttribute.

Member

arteam commented Feb 9, 2017

That's a good suggestion. Renamed MetricType to MetricAttribute.

phauer and others added some commits Sep 23, 2016

Add option to disable metric types globally
(like all p999 across every metric). Allows fine-grained filtering of
sent metrics and therefore effective load reduction.
Add support for disabling some metrics from being reported
Add a facility to disable set of metrics which should not be reported to a
remote system. `ScheduledReporter` only saves them. The decision to
how to filter the metric is delegated to concrete reporters.
Rename MetricType to MetricAttribute
This is a more common terminology for this enumeration and it was
introduced earlier in #837.
@arteam

This comment has been minimized.

Show comment
Hide comment
@arteam

arteam Feb 15, 2017

Member

I fixed the build (it was affected by relevant changes from the 3.1 branch moved to 3.2), now it should be good to merge.

Member

arteam commented Feb 15, 2017

I fixed the build (it was affected by relevant changes from the 3.1 branch moved to 3.2), now it should be good to merge.

@ryantenney ryantenney merged commit e2493e9 into 3.2-development Feb 15, 2017

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details

@ryantenney ryantenney deleted the support_for_disabled_metrics branch Feb 15, 2017

@nguyenhoan

This comment has been minimized.

Show comment
Hide comment
@nguyenhoan

nguyenhoan Feb 19, 2017

Hi @phauer
We are a team of researchers from Iowa State, The University of Texs at Dallas and Oregon State University, USA. We are investigating common/repeated code changes.
We have four short questions regarding the change in the image below which is part of this commit.
image

Questions:

Q1- Is the change at these lines similar to any other changes (from other locations of the same commit or from other commits)? (yes, no, not sure)

Q2- Can you briefly describe the change and why you made it? (for example, checking parameter before calling the method to avoid a Null Pointer Exception)

Q3- Can you give it a name? (for example, Null Check)

Q4- Would you like to have this change automated by a tool? (Yes, No, Already automated)

The data collected from the answers will never be associated with you or your project. Our questions are about recurring code changes from the developer community, not about personal information. All the data is merged across recurring changes from GitHub repositories. We will publish aggregated data from the trends of the whole community.
We have a long tradition of developing refactoring tools and contributing them freely to the Eclipse, Netbeans, Android Studio under their respective FLOSS licenses. For example, look at some of our recently released refactoring tools: http://refactoring.info/tools/

Thank you,
Hoan Nguyen https://sites.google.com/site/nguyenanhhoan/
Michael Hilton http://web.engr.oregonstate.edu/~hiltonm/
Tien Nguyen http://www.utdallas.edu/~tien.n.nguyen/
Danny Dig http://eecs.oregonstate.edu/people/dig-danny

Hi @phauer
We are a team of researchers from Iowa State, The University of Texs at Dallas and Oregon State University, USA. We are investigating common/repeated code changes.
We have four short questions regarding the change in the image below which is part of this commit.
image

Questions:

Q1- Is the change at these lines similar to any other changes (from other locations of the same commit or from other commits)? (yes, no, not sure)

Q2- Can you briefly describe the change and why you made it? (for example, checking parameter before calling the method to avoid a Null Pointer Exception)

Q3- Can you give it a name? (for example, Null Check)

Q4- Would you like to have this change automated by a tool? (Yes, No, Already automated)

The data collected from the answers will never be associated with you or your project. Our questions are about recurring code changes from the developer community, not about personal information. All the data is merged across recurring changes from GitHub repositories. We will publish aggregated data from the trends of the whole community.
We have a long tradition of developing refactoring tools and contributing them freely to the Eclipse, Netbeans, Android Studio under their respective FLOSS licenses. For example, look at some of our recently released refactoring tools: http://refactoring.info/tools/

Thank you,
Hoan Nguyen https://sites.google.com/site/nguyenanhhoan/
Michael Hilton http://web.engr.oregonstate.edu/~hiltonm/
Tien Nguyen http://www.utdallas.edu/~tien.n.nguyen/
Danny Dig http://eecs.oregonstate.edu/people/dig-danny

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