search

w3c / trace-context-protocols-registry

Trace Context Protocols Registry
https://w3c.github.io/trace-context-protocols-registry/
0 stars 4 forks source link

Tracing propagation over plain TLS #5

Open james-callahan opened 5 years ago

james-callahan commented 5 years ago

We're looking into how we can extend tracing IDs to plain TLS connections. I'm looking into adding a TLS extension via e.g. openssl custom extension apis.

Has anyone been considering something similar?

If there is anyone else interested, I'd like to see if we can get a TLS extension ID registered for tracing.

falenn commented 5 years ago

Can you elaborate on the purpose of tracing IDs in TLS extensions? Is the purpose to widen the trace aperture or something else? Thanks.

james-callahan commented 5 years ago

Can you elaborate on the purpose of tracing IDs in TLS extensions?

To add tracing propagation for protocols that otherwise may not have a way to inject metadata. Outside of creating a TCP/IP header (which middle-boxes will undoubtedly make untenable to deploy) it seems to me that injecting them into the TLS layer as an extension will be the easiest way to get wide adoption.

falenn commented 5 years ago

have you thought about where traced spans are emitted? Ok, going a little more down the rabbit hole, do you see spans as always collected through effectively an opt-in process or is there a place for directing export? Assuming we continue factoring tracing out of commodity code, do we see span emission as "built-in" to future infrastructure? Thanks for entertaining the speculation.

james-callahan commented 5 years ago

have you thought about where traced spans are emitted?

On a personal level: we intend to emit them from Kong which is a proxy. The key thing though is allowing applications to propagate them.

falenn commented 5 years ago

Started looking into Kong. As a service gateway, would you consider Kong performing all tracing? If Kong were used more like a service mesh - a.k.a, service calls looping back through the gateway, then the gateway could trace all calls synthetically. I've actually built this in the past using an F5 BigIP appliance (LTM) - with this sidecar approach, the gateway or the mesh does all of the exporting. Micro services only need to create child spans when acting as composites. Is this what you're thinking?

james-callahan commented 5 years ago

As a service gateway, would you consider Kong performing all tracing?

It can perform tracing, but it can't propagate trace contexts on behalf of services (as it doesn't know that a given incoming request corresponds to a given outgoing request).

What it can do though is inject a trace context into anything that doesn't have one.

If Kong were used more like a service mesh - a.k.a, service calls looping back through the gateway, then the gateway could trace all calls synthetically

The next Kong release includes support for service mesh (see https://konghq.com/blog/introducing-kong-support-for-service-mesh-deployments/ ). However it can already be deployed as an internal API gateway today.

Micro services only need to create child spans when acting as composites. Is this what you're thinking?

Not only when acting as composites: they may be originating new requests themselves.