Hello. My name is Hart Hoover manager of Kubernetes Education at VMware. In this course, we'll go through open tracing and discuss options you have when deciding on tools. Per application logging and metric monitoring have their place, but neither can reconstruct the elaborate journeys that transactions take as they propagate across the distributed system. If you are using Kubernetes on more than one node, you are using a distributed system. Traces are used to watch your request as it flows through the system so engineers can get a view of how parts of the system perform. Open tracing is an API specification and associated frameworks and libraries to implement a tracing solution.

When we discuss distributed tracing, we are usually discussing these three things, spans, traces, and tags. A span is the primary building block of a trace, representing an individual unit of work done in the distributed system. A trace is a collection of spans across multiple distributed services. Each component of the distributed system contributes a span, a named timed operation representing a piece of the workflow into the overall trace. When we want to get data from our traces, for context, we use tags. Tags are key value pairs that enable user defined annotation of spans in order to query, filter, and comprehend trace data.

It's important to know how your application works and how services talk to each other within your application. In this example, I'm running an e-commerce platform with a UI built from a suite of services, a product service, a review service, and a user account service. If one of these services' databases are degraded and front end requests start to fail, you need to know how requests flow through your system. Adding tracing to an application may require you to use a library from the OpenTracing project to instrument your code. OpenTracing maintains nine language specific SDKs that work with your application code for tracing. Alternatively, many frameworks exist that benefit from having open tracing built into the framework, where tracing can just be turned on with a few lines of code for the application. These listed here have framework SDKs and there are many more on GitHub as part of the OpenTracing community.

Once your application is generating traces, you need a system that collects and visualizes trace data for your teams so you can get context from it. Several tools and services are out there that support the OpenTracing API and specification, including open source projects you can run yourself or even managed services. Once your application is generating traces, you need a system that collects and visualizes this trace data for your team. Several tools and services are out there that support the OpenTracing API and specification, including open source projects you can run yourself or managed services. This is an example trace from one such project called CNCF Jaeger. Jaeger is a CNCF project and here, we are seeing a trace made up of many spans, each from one part of a distributed system. At the top of the chart, we can see the overall trace and how long the entire request took to complete, where the spans below show how long each individual service took to respond.

Thank you very much. In the next video, you'll see me working with Jaeger inside of a Kubernetes cluster. Thank you.