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.
---
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 infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
