Video Summary and Transcription
Showcasing adding observability with OpenTelemetry. Benefits of extensive telemetry data for insights. Contrasting uninstrumented, manual, and automatic instrumented apps. Example of instrumenting fetch calls for telemetry signals. Technique for modifying functions without core updates. Using JS proxy as a modern approach for patching. OpenTelemetry standardizes instrumentation with APIs and tools. Example of setting up OpenTelemetry with instrumentations.
1. Adding Observability with OpenTelemetry
Showcasing adding observability with OpenTelemetry. Benefits of extensive telemetry data for insights. Contrasting uninstrumented, manual, and automatic instrumented apps. Example of instrumenting fetch calls for telemetry signals.
I want to show you how you can add observability to your application with just one line of code. Who has worked with OpenTelemetry before? Maybe a quick show of hands? Oh, yeah, not too many, but still quite a few. OpenTelemetry is an open source framework which provides a standardized set of tools and APIs for collecting, processing, and exporting telemetry data.
Why do we need that? There is the notion that the more information you have, the closer you are to the truth and the more wisdom and power you gain from it. Mapped to OpenTelemetry or to observability, this would mean that the more signals your application is emitting, the more aggregated telemetry data you have and the more insights and actions you can take out of it. Let's look at three examples. First one would be an uninstrumented app. Basically a black box because it doesn't emit anything. Second would be a manually instrumented app where you, the developer, is deciding which signals you want to send to the observability backend.
And third is kind of the sweet spot where we have an automatically instrumented app, meaning you just write the application code and some library or SDK is magically gathering the telemetry data behind the scenes and sending it to your backend. Let's look into this a bit more in detail with the example of fetch. An uninstrumented fetch call would be a basic fetch call. It fetches data and then life goes on. Manually instrumented fetch call in the case of OpenTelemetry would look something like this. You have a tracer which is an OTEL component which starts a span.
A span is just a word for a single operation that is timed and that measures things. So here we start the span, we call fetch, and whenever the fetch call ends, we end the span and that's how we measure it. You see there's quite a lot of code to maintain. So let's look at the sweet spot where we want to land. An automatically instrumented app where we just import our SDK, we call init, and then we use fetch as we have always done before. Let's maybe look behind the scenes of this init call. How can we behind the scenes make fetch emit these telemetry signals? We do this by using a technique called monkey patching which many of you are probably aware of.
2. Modifying Functions with OpenTelemetry
Technique for modifying functions without core updates. Using JS proxy as a modern approach for patching. OpenTelemetry standardizes instrumentation with APIs and tools. Example of setting up open telemetry with instrumentations.
It is a technique where we modify a module or a function and we extend the functionality without updating the core functionality of it during runtime. In the case of fetch, this could look something like this. Since we're still in JavaScript world, we can basically do what we want. So we just take the global fetch, store it away, and then override the global fetch with the tracer that we've seen earlier. So every time in the user code we call fetch now, it will be traced automatically.
A more modern way of doing this would be to use a JS proxy which you can think of basically as a middleman between the function or module you want to patch and the code that is calling it. How does OTL come into play here? As I mentioned earlier, open telemetry provides a standardized way of doing things. By this, I mean tools and APIs like this instrumentation base class that you can see on top which we just extend for our custom instrumentation.
There is some scaffolding around, so we want to specify which module we want to patch. We can specify a version range. But then the important part is marked in red here, where we basically do what we've just seen before, monkey patching, a specific functionality of a module that we want to trace. So, coming back to our init call. This would be a very basic example on how open telemetry setup could look like. It includes several building blocks. It's not too important what we're using here at the moment, but the important thing is the register instrumentations call that is marked in red. Here you see we provide an array of instrumentations.
Comments