[
https://issues.apache.org/jira/browse/FLINK-3950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15436541#comment-15436541
]
ASF GitHub Bot commented on FLINK-3950:
---------------------------------------
Github user zentol commented on the issue:
https://github.com/apache/flink/pull/2374
I've thought about the interface for a bit, and my conclusion is that a
Meter should only return a single rate with a relatively small time unit, like
a minute or maybe even less.
Here's why: Generally we expect users of the metric system to use a
metric-oriented backend like graphite/ganglia etc. to store their metrics. Now,
assuming that a 1 minute rate is regularly reported they should be able to
derive whatever rate their want (as long as it is greater than 1 minute) from
the time-series of the 1 minute rate.
Moving these responsibilities into the metric backend simplifies things on
our end. We only have to calculate a single rate (=> less overhead) and all
meters would expose the same rate.
While a configurable meter or one that exposes multiple rates _could_ work
in user-code it falls flat in regards to the system metrics for which users
have no way to decide which rate to calculate. Any configuration here would be
done on a per-cluster basis, which means that it a) can't be changed without
restarting the cluster and b) would not work in multi-user environments without
calculating all rates all the time.
> Add Meter Metric Type
> ---------------------
>
> Key: FLINK-3950
> URL: https://issues.apache.org/jira/browse/FLINK-3950
> Project: Flink
> Issue Type: Sub-task
> Components: Core
> Reporter: Stephan Ewen
> Assignee: Ivan Mushketyk
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
