You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@beam.apache.org by "Beam JIRA Bot (Jira)" <ji...@apache.org> on 2021/05/03 17:20:00 UTC

[jira] [Commented] (BEAM-11832) Time correction by NTP sync can skew metrics

    [ https://issues.apache.org/jira/browse/BEAM-11832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17338507#comment-17338507 ] 

Beam JIRA Bot commented on BEAM-11832:
--------------------------------------

This issue was marked "stale-P2" and has not received a public comment in 14 days. It is now automatically moved to P3. If you are still affected by it, you can comment and move it back to P2.

> Time correction by NTP sync can skew metrics
> --------------------------------------------
>
>                 Key: BEAM-11832
>                 URL: https://issues.apache.org/jira/browse/BEAM-11832
>             Project: Beam
>          Issue Type: Bug
>          Components: runner-dataflow
>            Reporter: Minbo Bae
>            Priority: P3
>         Attachments: clock_correction.png
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> GCE VM time can be corrected by NTP sync. If this happens,`System.currentTimeMillis()` can set back to the past. You may see this [^clock_correction.png] in Cloud Logging for time correction. 
> The rolled back clock can cause skewed metrics. For example, `ExecutionStateSampler` uses `System.currentTimeMillis` [1]. I guess we can mitigate this issue using `System.nanoTime` for elapsed times (maybe not perfect as per [2]).
> [1] [https://github.com/apache/beam/blob/v2.27.0/runners/core-java/src/main/java/org/apache/beam/runners/core/metrics/ExecutionStateSampler.java#L42]
> [2] [https://bugs.openjdk.java.net/browse/JDK-6458294]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)