Coordination around Trace Context work

[AloisReitbauer]

We are currently starting a new WG that will deal with specifications around interoperability of trace data[1] across vendors. While not currently part of your specs, I see it related to the work you are doing around server timing.

Interested to get your thoughts how we should collaborate. It would be a huge step forward in the industry if I could start a trace context already in the browser.

Looking forward to hearing your thoughts.

[1] https://w3c.github.io/distributed-tracing/report-trace-context.html

[colinbendell]

fwiw, we use Server-Timing in this way to pass service-request-ids, or essential artifacts between service layers. parent layers consume, add and/or scrub ST at each layer. The goal is to:
a) reduce log-join efforts by capturing the request-id from each dependent service so that you can concretely link telemetry/logs from the parent to the child service
b) add the most details about the child service so as to avoid the log join in the first place. (eg: debug attributes or dependency keys from the db)
c) of course timing data - so that parent can compare timing from child self-reported timing as a hint of infrastructure issues vs. application issues

[toddreifsteck]

@cvazac We are reviewing this on 10/25/2018 at TPAC 2018 to discuss next steps.

[yoavweiss]

Discussed as part of TPAC F2F meeting.

Closing, but feel free to open more specific issues if/when they arise.