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.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
