You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@flink.apache.org by long ha dac <vo...@yahoo.com> on 2022/04/05 10:51:38 UTC

Flink metric

Hi,I'm trying to work with monitoring a job on Flink. Just a simple process: a data source from kafka joining with a data stream table (load from database).I've already enabled the latency tracking like the instruction from: https://nightlies.apache.org/flink/flink-docs-release-1.14/docs/ops/metrics/#end-to-end-latency-trackingWhat I want to ask here is: The latency mean of the operator is about 100ms however the throughput is about 300 records/second (this value I got from the metric of the operator: 300 records/second for both records in and records out). What I understand about the latency tracking is: this value only measured the waiting time, so normally it should be less than the real latency of the operator. So how could it process 300 records/second (about 3ms for 1 message) with the latency tracked mean is 100ms ?
Thanks in advanced.

Re: Flink metric

Posted by Robert Metzger <me...@gmail.com>.
Hi,

multiple records are in the system at the same time, because Flink is
buffering records in various components, for efficiency reasons. That's why
you see that an individual record might have a latency of ~100ms, while
Flink is processing many more messages.


On Tue, Apr 5, 2022 at 12:54 PM long ha dac <vo...@yahoo.com> wrote:

> Hi,
> I'm trying to work with monitoring a job on Flink. Just a simple process:
> a data source from kafka joining with a data stream table (load from
> database).
> I've already enabled the latency tracking like the instruction from:
> https://nightlies.apache.org/flink/flink-docs-release-1.14/docs/ops/metrics/#end-to-end-latency-tracking
> What I want to ask here is: The latency mean of the operator is about
> 100ms however the throughput is about 300 records/second (this value I got
> from the metric of the operator: 300 records/second for both records in and
> records out). What I understand about the latency tracking is: this value
> only measured the waiting time, so normally it should be less than the real
> latency of the operator. So how could it process 300 records/second (about
> 3ms for 1 message) with the latency tracked mean is 100ms ?
>
> Thanks in advanced.
>