[
https://issues.apache.org/jira/browse/STORM-2006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15400128#comment-15400128
]
ASF GitHub Bot commented on STORM-2006:
---------------------------------------
Github user HeartSaVioR commented on the issue:
https://github.com/apache/storm/pull/1595
@abhishekagarwal87
1. I think new type of metrics consumer should refer the new metrics
feature which addresses our concerns on current metrics. Aggregation is just a
one of them so I don't want to introduce new type of metrics consumer without
consideration of other things. It doesn't mean I started working for the new
metrics feature, just like a hotfix for current metrics feature.
2. Worker+component combination is what this PR is trying to achieve.
`convertMetricsTupleMapKeyedByTaskInfo` is for that. You can see that I only
change the task id and timestamp in TaskInfo, and use TaskInfo to aggregate the
values, which means metrics from different components are not aggregated to
same list.
I also don't think aggregated metric value is useful if they are aggregated
from various components.
3. Yes I'm aware of it, and that's why I introduce `eviction` of the metric
points.
Btw, in that care, metric value would be flawed anyway. It is already out
of control so we should focus how to not making this situation instead of how
to correct the value.
And triggering (sending metrics tick tuple to tasks) can't guarantee this.
As we were talking about metrics from user@ and dev@ list, there're a lot
of things to correct from current metrics feature. Things are coupled each
other so this is also not easy to fix them one by one. Let's move out to the
new metrics feature rather than saying them with current metrics.
> 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)
