[
https://issues.apache.org/jira/browse/STORM-2006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15397779#comment-15397779
]
ASF GitHub Bot commented on STORM-2006:
---------------------------------------
Github user ptgoetz commented on the issue:
https://github.com/apache/storm/pull/1595
@HeartSaVioR I don't think I was very clear in articulating my proposal.
What I'm saying is rather than making this a configuration switch, make it
dynamic based on what interface the consumer implements. So it would involve:
1. Leave `IMetricsConsumer` as-is, but deprecated.
2. Introduce a new interface for aggregated metrics (e.g.
`IAggregateMetricsConsumer`)
3. At runtime, look at which interface the registered consumer implements,
and alter the logic based on that (rather than a configuration switch)
With that we would have both backward compatibility and a new presumably
cleaner API for aggregated metrics. The internals my not be pretty, but that
would be invisible to the user.
From the discussion thread you pointed out, there seems to be consensus
around such an approach:
Quoting @revans2:
> On 1.x we add in a new API for both reporting metrics and collecting in
parallel to the old API. We leave IMetric and IMetricsConsumer in place but
deprecated. As we move internal metrics over from the old interface to the new
one, we either keep versions of the old ones in place or we provide a
translation shim going from the new to the old.
Quoting @abhishekagarwal87:
> Sounds good. Having two separate metric reporters may be confusing but it
is better than breaking the client code.
Quoting you:
> Personally I'm also in favor of maintaining old API (but deprecated) and
adding new API. It's ideal way, and that's what many projects are trying to
do, and so on
the other project I'm also maintaining.
> Storm metrics feature improvement: support per-worker level metrics
> aggregation
> -------------------------------------------------------------------------------
>
> Key: STORM-2006
> URL: https://issues.apache.org/jira/browse/STORM-2006
> Project: Apache Storm
> Issue Type: Improvement
> Components: storm-core
> Affects Versions: 1.1.0
> Reporter: Jungtaek Lim
> Assignee: Jungtaek Lim
>
> Storm provides per-task level metrics which could be huge when topology has a
> number of tasks.
> Task level metric is useful for determining load balance between tasks, but
> it doesn't need to be time-series fashion.
> Before introducing topology level component like TopologyMaster for JStorm,
> we can utilize SystemBolt to aggregate task level metrics to per-worker level
> metrics.
> We should provide options and this feature should be turned off by default to
> keep backward compatibility.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
