For this OTel in minute, we wanted to step back a bit and start with what is OpenTelemetry? If we navigate to the OpenTelemetry website, we find a quote summarizing it “OpenTelemetry is a collection of APIs, SDKs, and tools. Use it to instrument, generate, collect, and export telemetry data (metrics, logs, and traces) to help you analyze your software’s performance and behavior“ OpenTelemetry is generally available across several languages and is suitable for production use.”
It’s a bit of a mouthful and OpenTelemetry is really a pretty broad project with many different components – so when someone asks you, are you using OpenTelemetry (or OTel for short) – it’s natural to ask what part?
Let’s take a look at the pieces and break them down a bit into what we call “the 3Cs of OpenTelemetry”.
Perhaps the 1st thing that comes to mind when we talk about OpenTelemetry starts with our 1st “C” which is for “Code” or instrumenting our code using the OTel APIs and SDKs. With support for a wide range of languages, we can either instrument our code and business logic manually, or for some of those languages, leverage so called “zero code” instrumentation which leverages various techniques or hooks such as monkey patching or eBPF, typically adding instrumentation to the underlying libraries you’re using for example.
Our second C involves the collection of telemetry, and refers to another significant component of the project called the “OTel collector” – the collector can receive, enrich, transform and route telemetry to a wide range of existing observability backends and products – and can collect data locally from a host for example sometimes referred to as an “agent” deployment mode, or sit in the middle of your telemetry flows a little bit like a traditional network router or switch, sometimes referred to as a “Gateway” deployment type. What’s perhaps less well known is that the collector can actually receive and optimize telemetry from the observability products you already have – for example DataDog, the Grafana LGTM stack, New Relic or a host of others – in other words, you can use the collector even if you don’t have any OTel instrumentation in your code yet – in fact this “swiss army knife” as it were, can help with your ongoing consolidations and migrations, including migrating to OTel based code instrumentation itself! It can be a great place to start with the OpenTelemetry project.
Finally, we have our 3rd C for Configure, which is basically a set of tooling to help us deploy and operate the previous 2 Cs – for example a K8s operator to help us deploy zero code (or auto instrumentation) to applications or pods on our K8s clusters, example Helm charts to help us deploy the OTel collector in various modes, even tooling for FaaS or functions as a service, for example Lambda layers to inject zero code instrumentation for common runtimes, and even spin up a lightweight collector in a function.
All of the three Cs are supported by various specifications and protocols – APIs and SDKs to support code instrumentation, protocols such as OTLP – the OpenTelemetry protocol to support the export and transmission of telemetry to the collector or observability backends, and a protocol called OpAMP (the Open Agent Management Protocol) for managing the health and configurations of your collectors at scale, sometimes known as “Fleet Management”.
And finally, a thread if you like running through the 3Cs called semantic conventions, common naming for different kinds of operations and data like Generative AI or CI/CD for example – these are powerful conventions that provide common meaning to our data, and enable us correlate it across signal types.
Well that’s OpenTelemetry – just remember the 3Cs of “code”, “collect” and “configure” – and when someone asks you if you’re using OpenTelemetry or OTel, ask back which part? Until next time.
Back
