Names are only constructed once; when the dumper is notified of the new
metric.
We don't have to use scopeFormats; we can hard-code the scope assembly
into the ComponentMetricGroups. This way we don't need special behavior
in the dumper.
On 02.08.2016 16:29, Stephan Ewen wrote:
Regarding tr
Regarding transfer:
I think objects are fine, as long as they are not user-defined objects. We
can limit it to String and subclasses of Number.
Regarding traversal of groups:
I am still thinking here in terms of the paradigm that the metrics should
impact the regular system as little as possible.
Thank you for your feedback :)
Regarding names:
The Dumper does not create a MetricSnapshot. The Dumper creates a
list of key-value pairs; metric_name:value.
A (single) MetricSnapshot exists in the WebRuntimeMonitor, into
which the dumped list is inserted.
So the dumper creates a
The metrics transfer design document looks good to me. Thanks for your work
Chesnay :-)
I think the benefit of registering the metrics at the MetricDumper is that
we don't have to walk through the hierarchy of metric groups to collect the
metric values. Indeed, this comes with increased costs at s
Hi!
Thanks for writing this up. I think it looks quite reasonable (I hope I
understood that design correctly)
There is one point of confusions left for me, though: The MetricDumper and
MetricSnapshot: I think it is just the names that confuse me here.
It looks like they define a way to query the
Hello,
I just created a new FLIP which aims at exposing our metrics to the
WebInterface.
https://cwiki.apache.org/confluence/display/FLINK/FLIP-7%3A+Expose+metrics+to+WebInterface
Looking forward to feedback :)
Regards,
Chesnay Schepler
