You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the Android SDK syncs the clock used for OTel timestamps once at startup. This is good, but could potentially be problematic for apps running a long time.
Related, the Android emulator VM does a terrible job of keeping time. The system clock appears to run slow over time, and it doesn't itself correct to NTP. Thus, over 48h, I saw the clock slip 20s. This is unlikely to happen in a real device (which typically uses NTP or cellular clocks and generally has to maintain an accurate clock for auth purposes), but it highlights a potential problem.
This manifests itself in Kibana with a notable visual gap between trace data collected at the RUM device vs. related trace data collected from backend services (in distributed tracing scenarios).
Ideally, it seems, the Android SDK would periodically resync the NTP-based clock used for stamping OTel data. Maybe time-based (e.g., once/hour or once/min)?
The text was updated successfully, but these errors were encountered:
Currently, the Android SDK syncs the clock used for OTel timestamps once at startup. This is good, but could potentially be problematic for apps running a long time.
Related, the Android emulator VM does a terrible job of keeping time. The system clock appears to run slow over time, and it doesn't itself correct to NTP. Thus, over 48h, I saw the clock slip 20s. This is unlikely to happen in a real device (which typically uses NTP or cellular clocks and generally has to maintain an accurate clock for auth purposes), but it highlights a potential problem.
This manifests itself in Kibana with a notable visual gap between trace data collected at the RUM device vs. related trace data collected from backend services (in distributed tracing scenarios).
Ideally, it seems, the Android SDK would periodically resync the NTP-based clock used for stamping OTel data. Maybe time-based (e.g., once/hour or once/min)?
The text was updated successfully, but these errors were encountered: