# Why OpenTelemetry Exists — OpenTelemetry

Source: https://www.skillbyai.com/en/opentelemetry/f-why

> Instrument once, send anywhere.

## Vendor-neutral observability

Before OpenTelemetry (OTel), each monitoring vendor had its own agents and libraries, so switching tools meant re-instrumenting code. OpenTelemetry, a Cloud Native Computing Foundation (CNCF) project formed by merging OpenTracing and OpenCensus, defines common **APIs**, **SDKs**, a wire protocol (**OTLP**) and **semantic conventions** for telemetry. You instrument code once and can send data to open-source backends (Jaeger, Prometheus, Grafana Tempo and Loki) or commercial ones. OpenTelemetry does not store or visualise data itself.

## One standard for telemetry

OpenTelemetry standardises how applications produce and ship traces, metrics and logs, independent of any vendor.

![Three ideas: why OpenTelemetry, signals, architecture.](assets/figures/opentelemetry/section-1-map.svg) — Figure 1.1 — Purpose, signals and architecture.

## A universal power adapter

Instead of carrying a different charger for every country, you carry one plug and swap only the adapter at the wall. OpenTelemetry is the plug; exporters are the adapters.

## Separate instrumentation from backend choice

Keep vendor-specific code out of applications; choose and change backends in Collector configuration.

**Quiz:** What does OpenTelemetry NOT provide?

- [ ] The OTLP protocol
- [ ] APIs and SDKs for instrumentation
- [x] A storage and visualisation backend
- [ ] Semantic conventions

*Answer:* A storage and visualisation backend. You bring a backend such as Jaeger, Tempo or a vendor.