MyObservability

Introduction

OpenTelemetry is open-source, vendor agnostic and works with multiple Observability platforms at the same time. Implementing tracing steps:

• Instrument your application
• Collect and process the data
• Store and visualize the data

OpenTelemtry Overview

The OpenTelemetry project aims to provide a vendor agnostic way to instrument and collect your data. It 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.

• Instrumentation
  • Manual
  • Automatic
• Components
• Collectors
• Propagators
• Sampling
• Protocol
• Extension

Instrumentation

The data from the application can be generated using either automatic or manual (or a mix) instrumentation.

To instrument your application with OpenTelemetry, go to the OpenTelemetry repository, and pick the language for your application and follow the instructions.

• Manual Instrumentation: Manual instrumentation is when you write specific code for your application.
• Auto Instrumentation: Using the auto-instrumentation can be a good first step as this is simple, easy, and doesn’t require many code changes.

Propagation

Propagation is the mechanism that moves data between services and processes.

Sampling

Sampling is a mechanism to control the noise and overhead by reducing the number of samples of traces collected and sent to the backend.

OpenTelemetry can perform sampling depending on the amount of traces/traffic you want to send. (ie. take only 10% of the traces).

Components

OpenTelemetry can be further divided into other logical components that comprise the typical OTel solution. They are

1. APIs: In charge of gathering the telemetry and all the data that is part of it.
2. SDKs: get this data out of the current observed process to another entity for analysis
3. OTLP: Opentelemetry Protocol is telemetry data exchange protocol.
4. Collector: is a vendor-agnostic proxy that can receive, process, and export telemetry data.

Because they are separate, they allow us to decouple what is observed (API) to how it is handled (SDK). </br>

Collectors

The collector’s entire job can be broken down into three different stages:

1. Receive telemetry data
2. Process telemetry data
3. Export telemetry data

Receive telemetry data

How data gets into the collector (Push or pull based).

Process telemetry data

Once the data is received , the collector can process the data.

List of Processors

Ex: “batch” processor

The batch processor accepts spans, metrics, or logs and places them into batches. Batching helps better compress the data and reduce the number of outgoing connections required to transmit the data. This processor supports both size and time based batching.

Ex: processors: batch:

Processors are enabled via pipelines within the service section.

service: traces: receivers: [opencensus, jaeger] processors: [batch] exporters: [opencensus, zipkin]

Export telemetry data

An exporter is a component of OpenTelemetry and is how data gets sent to different systems/back-ends. OpenTelemetry comes with a variety of exporters.

In the exporters section, you can add destinations.

Extensions

Extensions are available primarily for tasks that do not involve processing telemetry data. Examples of extensions include health monitoring, service discovery, and data forwarding. Extensions are optional.

Ex: extensions: health_check: pprof: zpages: memory_ballast: size_mib: 512

OpenTelemetry Roadmap

Even though Telemetry is widely used, not all functionalities it support. OpenTelemetry has a road map to provide following features in near future.

• Logs
• Client Instrumentation (RUM)
• Code profiling

OpenTelemetry Architecture

OpenTelemetry architecture is designed to provide a standardized approach to collecting, transmitting, and processing telemetry data from applications and services.

---

Next Chapter: Recommended Setup

Main Page: Click Here

---