Open-Source Observability · open-telemetry

opentelemetry-cpp

OpenTelemetry C++ is the official C++ client library for OpenTelemetry, a vendor-neutral framework for collecting traces, metrics, and logs from applications. It supports C++14, C++17, and C++20 and is marked as stable across all three signals, making it suitable for production observability instrumentation.

Talk to DEV.co Discuss Implementation

Source: GitHub — github.com/open-telemetry/opentelemetry-cpp

1.3k

GitHub stars

581

Forks

C++

Primary language

Apache-2.0

License (OSI-approved)

Key facts

Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.

Field	Value
Repository	open-telemetry/opentelemetry-cpp
Owner	open-telemetry
Primary language	C++
License	Apache-2.0 — OSI-approved
Stars	1.3k
Forks	581
Open issues	237
Latest release	v1.27.0 (2026-05-13)
Last updated	2026-07-08
Source	https://github.com/open-telemetry/opentelemetry-cpp

What opentelemetry-cpp is

A standards-compliant, vendor-neutral instrumentation library providing APIs and SDKs for distributed tracing, metrics, and logs in C++ applications. Supports CMake and Bazel builds across Linux, macOS, and Windows platforms; implements the OpenTelemetry specification and integrates with standard exporters and processors.

Quickstart

Get the opentelemetry-cpp source

Clone the repository and explore it locally.

terminalbash

1git clone https://github.com/open-telemetry/opentelemetry-cpp.git2cd opentelemetry-cpp3# follow the project's README for install & configuration

Need it deployed, integrated, or customized instead? DEV.co ships production installs.

Best use cases

Microservices observability

Instrument distributed C++ services to collect traces, metrics, and logs in a vendor-neutral way, enabling cross-service correlation and debugging without vendor lock-in.

High-performance systems monitoring

Add telemetry to latency-sensitive C++ applications (gaming engines, financial systems, real-time processing) with minimal overhead via pluggable processors and exporters.

Multi-cloud deployments

Standardize observability across cloud providers and on-premise infrastructure by using OpenTelemetry as the common instrumentation layer, then routing signals to any backend (Jaeger, Datadog, New Relic, etc.).

Implementation considerations

Requires CMake or Bazel build system integration; verify compatibility with your existing build toolchain and supported C++ standard (C++14 minimum).
Spans, metrics, and logs are stable but integration point selection (exporters, processors, samplers) should be validated against your observability backend.
Instrumentation is manual by default; plan for code-level changes to add telemetry annotations throughout your codebase.
Consider processor and exporter choice upfront: batch vs. immediate, in-process vs. network, to balance latency, throughput, and resource usage.
Test with realistic traffic loads to measure CPU, memory, and network overhead before production deployment.

When to avoid it — and what to weigh

C-only projects — This library is C++ only; the project explicitly does not support C. Use a C instrumentation library if your application is written in C.
Embedded or severely memory-constrained systems — OpenTelemetry C++ has runtime overhead and dependency requirements. Highly embedded systems with extreme memory limits may require lighter-weight alternatives.
Vendor-specific proprietary instrumentation already locked in — If you depend on proprietary instrumentation hooks and cannot change exporters, switching to OpenTelemetry may require rework that is not justified for immediate ROI.
No observability backend infrastructure — OpenTelemetry is an instrumentation layer; it requires a backend (Jaeger, Prometheus, Grafana, or commercial APM) to ingest and visualize signals. Do not adopt without a defined backend strategy.

License & commercial use

Licensed under Apache License 2.0 (Apache-2.0), an OSI-approved permissive license permitting commercial use, modification, and distribution with standard liability disclaimers.

Apache-2.0 is a permissive open-source license that allows commercial use, redistribution, and modification. No license review or fee is required for commercial deployment. However, as with any OSS library, review the dependency tree (documented in Dependencies.md) for license compatibility with your commercial product.

DEV.co evaluation signals

Editorial assessment — not user reviews. Directional, with an explicit confidence level.

Signal	Assessment
Maintenance	Active
Documentation	Adequate
License clarity	Clear
Deployment complexity	Moderate
DEV.co fit	Strong
Assessment confidence	High

Security considerations

FOSSA security and license scanning integrated (badges shown). OpenSSF Scorecard evaluation available. Typical C++ concerns apply: buffer overflows, dependency vulnerabilities, and input validation are incumbent on integrators and dependency maintainers. No security audit details or CVE data provided in the data. Verify dependency security posture independently via FOSSA or similar tools.

Alternatives to consider

OpenTelemetry Java (and other language-specific implementations)

If your observability strategy spans polyglot services, language-specific implementations (Java, Python, Go, etc.) offer native integration, though operational consistency requires cross-language standardization.

Jaeger C++ client library

Jaeger-native instrumentation without full OpenTelemetry abstraction. Simpler if vendor lock-in to Jaeger is acceptable; tighter coupling and less flexibility for multi-backend scenarios.

Proprietary APM SDKs (Datadog, New Relic, etc.)

Some vendors provide native C++ SDKs with tighter backend integration and feature richness. Trade-off: vendor lock-in vs. turnkey integration and support.

Software development agency

Build on opentelemetry-cpp with DEV.co software developers

Adopt OpenTelemetry C++ to instrument your applications with vendor-neutral traces, metrics, and logs. Start with the getting started guide, evaluate exporter options for your backend, and pilot with a non-critical service.

Talk to DEV.co

Related open-source tools

Surfaced by semantic similarity across the DEV.co open-source index.

opentelemetry-rust opentelemetry-dotnet opentelemetry-js

Related on DEV.co

Explore the category and the services that help you build with it.

Open-Source Observability API Development DevOps Cloud Deployment Talk to DEV.co

opentelemetry-cpp FAQ

Do I need to modify all my code to use OpenTelemetry C++?

Manual instrumentation is required; the library does not auto-instrument. Typical adoption involves adding span/metric/log calls at key application points. Auto-instrumentation support is currently limited and requires specific libraries (e.g., via middleware or plugin systems).

Which C++ standard should I target?

C++14 is the minimum supported version. C++17 and C++20 are also fully supported. Target the highest standard your build environment and dependencies allow for best compatibility and performance.

What is the performance impact?

Overhead depends on sampling rate, processor choice, and exporter configuration. Batch processors with sampling are recommended for production. Real-world impact varies; benchmark with your specific workload and exporter before production rollout.

Can I use OpenTelemetry with legacy C++11 or C applications?

No. C++14 is the minimum. For legacy C++11 projects, upgrading the standard or using a different observability approach is necessary. C is not supported.

Software developers & web developers for hire

DEV.co is a software development agency delivering custom software development services to companies building on open source. Our software developers and web developers design, integrate, and ship production systems — spanning web development, APIs, AI, data, and cloud. If opentelemetry-cpp is part of your open-source observability roadmap, our team can implement, customize, migrate, and maintain it.

Standardize observability across your C++ services

Talk to DEV.co Schedule a Consultation