Ethan is a principal software engineer at Cars.com where he focuses on platform architecture, scalability, and performance. In previous roles he has run the gamut from product development, management, security, infrastructure, and data engineering.
Distributed tracing is an essential component to well-instrumented, modern day applications where requests often span across network boundaries and services. Tracing across HTTP services is a relatively common form of distributed tracing and generally works by passing contextual information about a trace in HTTP headers. The OpenTelemetry Specification incorporates a concept known as ““Context Propagation”” that describes this type of mechanism for passing context about an ongoing trace to other services and processes, regardless of where they are running. In OpenTelemetry, we can create our own ““Propagators”” to pass this context along in novel ways that aren’t just sending contextual information in HTTP headers.
So what does that have to do with the BEAM? On the BEAM, we are constantly crossing process boundaries. Once we’ve instrumented our applications with traces, we now have the need to pass trace context across those process boundaries. That means we are dealing with a form of distributed traces all of the time –– even if those processes are running on the same machine!
The need for novel ways to pass trace context along for distributed traces on the BEAM doesn’t end there. What if you want distributed traces on messages being passed between distributed Erlang nodes? If you’re sending a message to a GenServer running on another node, how do you propagate your trace context along from the caller node? How about tying together producers and consumers in a GenStage pipeline? And what about working with LiveView – what if you want to tie client and server spans together in a single trace?
In this talk we’ll explore the concepts needed to tackle these problems and point out some of the sharp edges you may want to avoid.
TALK OBJECTIVES:
TARGET AUDIENCE: