[ 
https://issues.apache.org/jira/browse/STORM-2006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15398329#comment-15398329
 ] 

ASF GitHub Bot commented on STORM-2006:
---------------------------------------

Github user HeartSaVioR commented on the issue:

    https://github.com/apache/storm/pull/1595
  
    @ptgoetz 
    That consensus was made with context `breaking change for 1.x`. Sure if we 
introduce breaking change in 1.x we need to support the old one. But if we go 
on introducing breaking change only for next major version, I don't think we 
must follow our consensus.
    
    We even could introduce completely different way like JStorm. In JStorm 
metrics are sent to Nimbus, and plugin to external storage is also there, so it 
might not be topology specific. In this case we could not provide the 
translation shim, but I don't think it matters if we introduce the change for 
next major version.
    
    When we talk about new API I'd like to focus the new one, not considering 
how to support the old one. For me, this change is more suited to the old one. 
There's another level to aggregate, component level, and it might be more 
preferred thing. Why I take worker level aggregation instead of component level 
aggregation is that it's only possible way to achieve with not breaking current 
design. That's why we should not consider about old one while designing new one.


> 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)

Reply via email to