Github user zentol commented on the issue:
https://github.com/apache/flink/pull/4826
So here's the thing: The port of the metric itself is good, and exactly
what i want ð . What I'm unsatisfied with is the naming of the metric, but
that isn't the fault of this PR but a limitation in the metric system.
The way the metric is named is inconsistent. The source task is encoded in
the metric name with it's ID, but the target task is encoded in the scope as
either ID or name, based on the scope format. (maybe reverse the order but you
get the idea i hope).
The conclusion i arrived at is that this metric should not be registered at
the task level (which just doesn't support the notion of a metric describing 2
tasks) but at the job level instead (where we can do whatever we want in
regards to tasks).
This would, in principal, allow us to have this identifier:
```myjob.latency.source.ABCDE.target.DEFGH.latency_p95```
But this still isn't satisfactory, because it is still hardly usable for
key-value reporters, where we want to filter latencies based on the source or
target, for which we need something like this:
```
logical scope: job.task.latency.latency_p95:
tags:
job_name = myjob
source = ABCDE
target = DEFGH
```
For this to work however we first have to implement FLINK-7692 to support
custom key-value pairs.
As such I would like to delay merging this PR by a week or 2 until the
aforementioned feature is implemented, so we don't iterate through 3 different
versions.
---
