What is OpenTelemetry (OTel)?

A practical OpenTelemetry implementation uses several related components. APIs and SDKs provide instrumentation in supported languages. Semantic conventions standardize names and meanings for common telemetry, so a field like http.response.status_code carries the same meaning across services. The OpenTelemetry Protocol defines how telemetry can be transported. The Collector can receive, process, enrich, sample, and export telemetry to one or more compatible backends.

The Collector often provides substantial operational value by centralizing telemetry processing and export. Applications send telemetry to it in one format, and it handles filtering, sampling, enrichment, and routing to destinations.

Vendor-specific agents and proprietary instrumentation can couple telemetry collection to a particular backend. OpenTelemetry provides a standardized alternative, building on earlier projects such as OpenTracing and OpenCensus.

• Portability: use standardized instrumentation and export it to compatible backends, subject to differences in backend features and data models.
• Consistency: semantic conventions make telemetry comparable across services and languages.
• Ecosystem support: broad library and framework instrumentation, including automatic instrumentation for common stacks.
• Reduced coupling: lower switching costs than instrumentation written directly against one vendor.

OTel is a large specification with a wide surface area, and configuring it well takes real effort. Sampling strategy, context propagation across service boundaries, and resource attribution are all areas where defaults are workable and rarely optimal.

Support and stability vary by signal and language implementation; check the current OpenTelemetry support matrix for the languages in use rather than assuming uniform coverage.

A vendor agent is often easier to install and tightly integrated with that vendor's backend, sometimes with proprietary features that work out of the box.

Standardized instrumentation and Collector pipelines can reduce the amount of re-instrumentation required when changing backends. A migration may still require changes to exporters, dashboards, queries, alerting, retention policies, and vendor-specific features. Teams already invested in a vendor agent commonly migrate incrementally, running both during the transition.