关于端到端的延迟监控

[13051111332]

Hi Everyone：
      现在了解到的官方提供的LatencyMarker机制，不建议在生产上使用，而且也不参与算子内部逻辑，只能粗略估算出延迟，所以关于端到端的延迟监控，大家有什么更好的方案吗？

[wpp]

这个延迟，只是给一个参考意义吧，



--
Sent from: http://apache-flink.147419.n8.nabble.com/

[金则林]

每一条records处理过程中透传开始时间，在sink算子通过metrics上报opentsdb、Prometheus
<http://www.baidu.com/link?url=t2GJ4Iu0yQaVGLn0xzo6ppUrk3POkrOw7PnXnolEwXYZAEFurdxbJstjj7wRXfKEE5TFTOruqtziEB8M2heZ1A3e_8b39wZueqZYLVR6KSK>
等时间序列数据库，最后通过grafana等可视化工具展示。

wpp <[hidden email]> 于2021年1月28日周四 下午2:53写道：

> 这个延迟，只是给一个参考意义吧，
>
>
>
> --
> Sent from: http://apache-flink.147419.n8.nabble.com/
>

[Jessica J.Wang]

官方的LatencyMarker 表示的是数据的流通性， 他和数据是在同一个pipeline 中顺序处理的，如果你的算子都是同步的情况
是可以反应出数据的真实处理延迟，生产上是可以使用的，但是 延迟粒度 metrics.latency.granularity 最好调整成 single或者
operator ,防止latency上报太多 压垮服务


但当你的算子是个异步 用AsyncWaitOperator实现的话，因为latencyMarker并没有像watermark一样
addToWorkQueue,直接处理上报metrics,所以延迟信息就不准确了

所以自己做端到端延迟的话，可以flink sql source 层 抽取其event time时间往下游发送，insert into sink的时候
，写一个udf (currenttime-eventime) 计算其延迟时间，写到外部数据库中，sink最好是influxdb之类的,方便统计






--
Sent from: http://apache-flink.147419.n8.nabble.com/

[13051111332]

谢谢大家，清楚了


| |
13051111332
|
|
[hidden email]
|
签名由网易邮箱大师定制


在2021年01月28日 17:56，Jessica.J.Wang<[hidden email]> 写道：
官方的LatencyMarker 表示的是数据的流通性， 他和数据是在同一个pipeline 中顺序处理的，如果你的算子都是同步的情况
是可以反应出数据的真实处理延迟，生产上是可以使用的，但是 延迟粒度 metrics.latency.granularity 最好调整成 single或者
operator ,防止latency上报太多 压垮服务


但当你的算子是个异步 用AsyncWaitOperator实现的话，因为latencyMarker并没有像watermark一样
addToWorkQueue,直接处理上报metrics,所以延迟信息就不准确了

所以自己做端到端延迟的话，可以flink sql source 层 抽取其event time时间往下游发送，insert into sink的时候
，写一个udf (currenttime-eventime) 计算其延迟时间，写到外部数据库中，sink最好是influxdb之类的,方便统计






--
Sent from: http://apache-flink.147419.n8.nabble.com/

[JasonLee]

hi

可以在消费 kafka 的时候获取到数据进入 kafka 的时间戳 然后在最终的 sink 的时候再获取一个时间戳 自己定义一个 metric
上报最终的耗时



-----
Best Wishes
JasonLee
--
Sent from: http://apache-flink.147419.n8.nabble.com/