我们使用“系统延迟”来检查Dataflow作业的运行状况。例如，如果我们看到系统延迟增加，我们将尝试了解如何降低此指标。有关此指标的问题很少。
数据项等待处理的最长时间
以上是我们在点击信息图标时在GCP控制台中看到的内容。在这种情况下，数据项意味着什么？流处理具有窗口化，事件时间与处理时间，水印等的概念。何时考虑等待处理的项目？例如，只是当消息到达而不管其状态如何？
我们尽量保持这个指标尽可能低，但我们没有任何建议我们应该保持多低。例如，我们是否有一些建议，例如保持系统滞后在20到30秒之间是最佳的。
系统滞后如何影响事件本身的延迟？
答案 0 :(得分：5)
根据正在执行的管道，有许多元素可能排队等待处理。这通常是在机器之间传递元素时，例如在GroupByKey内，尽管PubSub源也反映了最旧的未应用元素。
对于给定步骤（包括接收器），“系统延迟”测量到该步骤的最近输入队列中最旧元素的年龄。
在这种情况下出现尖峰并不罕见 - 元素在处理后被拉出队列，因此如果传递了许多新元素，则队列恢复到可管理的大小可能需要一段时间。重要的是系统滞后在这些峰值之后会回落。
接收器的延迟取决于几个因素：
可能更容易查看接收器的“数据水印”，它会报告接收器处理的（事件）时间点。