Glossary

OpenTelemetry

OpenTelemetry: definition

OpenTelemetry is an open-source observability framework that provides APIs, SDKs, instrumentation, a Collector and specifications for telemetry. It is designed to help applications generate and move signals such as traces, metrics and logs without requiring every application to implement a proprietary telemetry format.

Core components

  • APIs and SDKs let applications create and process telemetry.
  • Instrumentation can be manual or automatic depending on language and framework support.
  • The Collector receives, processes and exports telemetry through configurable pipelines.
  • OTLP is the OpenTelemetry Protocol used to transport telemetry.
  • Semantic conventions define common attribute names for services, HTTP, databases and other domains.

What portability means in practice

OpenTelemetry can reduce coupling at the instrumentation layer, but it does not make observability backends identical. Storage, query languages, alerting, sampling, pricing and visualization still differ. Some vendor-specific features may also require proprietary agents or attributes.

Collector architecture

A Collector can centralize batching, filtering, redaction, sampling or routing. That can simplify application code and make backend changes easier, but the Collector itself becomes operational infrastructure that needs capacity, configuration and monitoring.

What to test with a backend

  • Which OpenTelemetry signals are accepted.
  • Whether OTLP is supported directly and over which transports.
  • How resource and span attributes map into the backend.
  • Whether exemplars, logs correlation and semantic conventions survive ingestion.
  • What happens to unsupported fields or high-cardinality attributes.

Common mistakes

Do not interpret “supports OpenTelemetry” as a single yes/no capability. Test the exact language SDK, collector path, signal and backend features you plan to use. Also standardize service naming early; portability does not help if teams emit inconsistent resource identities.

Related concepts

Short answer

OpenTelemetry standardizes important parts of telemetry instrumentation and transport. It can improve portability and consistency, but you still need to test signal coverage, attribute mapping, collector operations and backend-specific behavior.

Practical checklist

  • Test the exact signal and language SDK you plan to use.
  • Verify OTLP endpoints, resource mapping and semantic conventions.
  • Treat the Collector as production infrastructure if you depend on it.
  • Check which backend features still require vendor-specific instrumentation.

Sources and further reading