Enabling Tracing from Mobile Clients

[Alan Cooke]

Hi,

Looking for advice in order to enable tracing from mobile clients through to backend systems.

Is there reference implementations on iOS or Android that I can look at?

When thinking about ID clashing, we have a large user base and want to ensure that id's don't clash.

Another topic that has been discussed in our team, is managing difference in times when it comes to specifying spans.

Thanks in advance for any help.

Alan

[Ben Sigelman]

Hi Alan,

Sorry for the delay, I'm way behind on email but flagged this a while back.

LightStep's iOS and Android SDKs are OSS (though not particularly interesting!). There are a few things that make tracing from mobile particularly interesting/challenging in my experience:

• Clock synchronization is a much bigger problem due to high network latencies and large innate clock skew on the devices. There's no silver bullet, though using known happens-before relationships on client and server can help to collar any uncertainty about device clocks, especially when considered across multiple traces.
• Buffering data is trickier since it's not-okay to keep the device radio on all of the time. Most sophisticated organizations I know like to flush all of their telemetry data in one fell swoop (not just tracing). This rarely turns into a profound problem, but it's definitely tricky.
• Since clients can't really be trusted, you have a choice between assuming that attackers don't really care about messing with your latency / telemetry data or cryptographically signing ids and adding a bunch of complexity. Depending on your business needs, hopefully you can tolerate the former, but it's a topic worth considering.

The id collision concerns you brought up don't worry me very much since trace assembly is typically time-bound as well, and with 64bit ids it takes an awful lot of data to get into birthday paradox territory given a restricted time range. There's also the question of how catastrophic it is for there to be a collision every once in a while... almost all production tracing systems are sampling-based (i.e., extremely lossy!) from the get-go, so it's worth thinking through the business impact of a potential ~monthly trace collision (or whatever it is for your traffic volume).

Hope this helps?

Ben

--
You received this message because you are subscribed to the Google Groups "Distributed Tracing Workgroup" group.
To unsubscribe from this group and stop receiving emails from it, send an email to distributed-tra...@googlegroups.com.
To post to this group, send email to distribut...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/distributed-tracing/330a030c-cb65-4399-a668-3e505d206f98%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alois Reitbauer]

Alan,

full disclosure, I am working for Dynatrace. The problems you are looking at are handled by all tracing and APM providers out of the box. The only thing you need to take care of is to add custom tracing points that will not be instrumented automatically. 

Time synchronization will be handled by regularly syncing with the backend using a beacon signal for example. 

When talking about IDs which IDs do you refer to? Is this about call IDs or user IDs. If is is call IDs you can create distinct IDs per device. You could use a UUID or if you want to be 100 sure you request a new ID the first time your application launches on a device. The rest should then be straightforward. Again this is something that would automatically be handled by commercial implementations.