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

STORM-3186: Customizable configuration for metric reporting interval #3132

Merged
merged 3 commits into from
Dec 4, 2023

Conversation

jainrish
Copy link
Contributor

No description provided.

@agresch
Copy link
Contributor

agresch commented Sep 27, 2019

This looks fine, except I'm not clear why this is only modified for ConsolePreparableReporter.

Copy link
Contributor

@srdo srdo left a comment

Choose a reason for hiding this comment

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

Looks good. Left a comment.

@jainrish
Copy link
Contributor Author

This looks fine, except I'm not clear why this is only modified for ConsolePreparableReporter.

@agresch I have modified it for CsvPreparableReporter.java as well. These are the only two classes which had hardcoded reporting for 10 seconds.

@agresch
Copy link
Contributor

agresch commented Sep 27, 2019

Thanks. I also see ScheduledStormReporter using REPORT_PERIOD and REPORT_PERIOD_UNITS for setting this. Just wondering if we should switch that as well for consistency? I like the clarity of this change better. @srdo have any thoughts on this?

@srdo
Copy link
Contributor

srdo commented Sep 27, 2019

I think the ScheduledStormReporter classes are for the metrics reporters for the workers (the parts topologies can hook into), while this is for the daemons. I think having separate parameters makes sense, as the worker metrics config is topology level, while this new setting is at the cluster level.

Don't have an opinion on whether we should add a parameter for setting the time unit as well, do you think it would be useful?

As an aside, we really should rename StormMetricsRegistry. We have StormMetricRegistry for the workers, and StormMetricsRegistry for the daemons. It's easy to mix them up.

@jainrish
Copy link
Contributor Author

I think the ScheduledStormReporter classes are for the metrics reporters for the workers (the parts topologies can hook into), while this is for the daemons. I think having separate parameters makes sense, as the worker metrics config is topology level, while this new setting is at the cluster level.

Don't have an opinion on whether we should add a parameter for setting the time unit as well, do you think it would be useful?

As an aside, we really should rename StormMetricsRegistry. We have StormMetricRegistry for the workers, and StormMetricsRegistry for the daemons. It's easy to mix them up.

@srdo Let me know if its required to have a configuration for time unit as well. I would like to work on it.

@srdo
Copy link
Contributor

srdo commented Sep 28, 2019

@jainrish If you think a configuration for time unit would be useful, feel free to add it. Up to you whether to do it in this PR or in a later issue.

@jainrish
Copy link
Contributor Author

@jainrish If you think a configuration for time unit would be useful, feel free to add it. Up to you whether to do it in this PR or in a later issue.

@srdo I will prefer to do it in a separate issue. Let me know if I should raise the jira.

@srdo
Copy link
Contributor

srdo commented Sep 30, 2019

@jainrish Feel free.

@srdo
Copy link
Contributor

srdo commented Sep 30, 2019

Looks good, just a few minor nits left:

Please add the default setting to https://github.com/apache/storm/blob/master/conf/defaults.yaml. That way it's visible to users what the default is. Then you can remove the default value from the Java classes.

Copy link
Contributor

@Ethanlm Ethanlm left a comment

Choose a reason for hiding this comment

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

Overall looks good to me. Thanks for contribution. Left some minor comments

@rzo1 rzo1 merged commit ec2afb4 into apache:master Dec 4, 2023
18 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants