Comment on page
A beginner’s guide to OpenTelemetry
- 1.Instrument the application using OpenTelemetry SDK.
- 2.Traces are sent to a (collector) agent.
- 3.The collector exposes ports 4317(gRPC) and/or 4318(http) using OTLP.
- 5.The Jaeger Query retrieves the traces and expose them to the Jaeger UI.
- 6.Jaeger UI provides a web based user interface that can be used to analyse traces.
This is good, because that means that we are not tied to any tool (or vendor). Not only can we use any programming language we want, but we can also pick and choose the storage backend, thus avoiding a potential buy in from commercial vendors.
It also means that developers can instrument their application without having to know where the data will be stored.
Defines how OpenTelemetry is used.
Defines the specific implementation of the API for a language.
As you can see from the image (at the top), in order to get trace data, we first need to instrument the application. To collect the trace data, we can use the OpenTelemetry SDK.
The trace data can be generated using either automatic or manual (or a mix) instrumentation.
One of the best ways to instrument applications is to use OpenTelemetry automatic instrumentation (auto-instrumentation). This approach is simple, easy, and doesn’t require many code changes.
Using auto-instrumentation libraries, means that you don’t need to write code for the trace information to be collected. In fact, OpenTelemetry offers an API and SDK that allows for easy
bootstrappingof distributed tracing into your software.
This is good to know if don’t have the necessary knowledge (or time) to create a tracing framework tailored for your application.
For example, running the following command will automatically instrument your python code.
opentelemetry-instrument python app.py
When you use auto instrumentation, a predefined sets off spans will be created for you and populated with relevant attributes.
Manual instrumentation is when you write specific code for your application. It’s the process of adding observability code to your application. This can more effectively suit your needs. For example, you can add attributes and events.
Once you have collected trace data, you need to send it somewhere.
OpenTelemetry Protocol (OTLP) specification describes the encoding, transport, and delivery mechanism of telemetry data between telemetry sources, intermediate nodes such as collectors and telemetry backends. source
The OTLP protocol describes how to encode and transmit telemetry data, which makes it a natural choice for data transport. Each language SDK provides an OTLP exporter you can configure to export data over OTLP. The OpenTelemetry SDK then transforms events into OTLP data.
The collector is a component of OpenTelemetry that collects trace data (spans, metrics, logs etc) process (pre-processes data), and exports the data (sends it off to a backend that you want to talk to).
The collector can be setup as an agent or as a gateway.
We usually first send traces to a (collector) agent. This (collector) agent handles the trace data from the instrumented application.
The (collector) agent can offload responsibilities that the client instrumentation otherwise need to handle. This includes batching, retry, encryption, compression and more.
You can also perform sampling here depending on the amount of traces/traffic you want to send. (ie. take only 10% of the traces).
You need to configure receivers (how data gets into the collector), which then transform the data (process) before sending it to one or more backends using exporters.
Here we configure a receiver (on the collector) that accepts OTLP data on port 4317 (gRPC). (You also need to configure your application to export over OTLP to use it)
otlp: protocols: grpc: endpoint: "0.0.0.0:4317"
The exporters converts OpenTelemetry protocol (OTLP) formatted data to their respective predefined back-end format and exports this data to be interpreted by the back-end or system.
It’s important to know that the OpenTelemetry collector does not provides their own backend.