OpenTelemetry C++: A Stable Client for Traces, Metrics, and Logs in Native Code

What This Client Actually Solves

OpenTelemetry C++ is the official client for instrumenting native applications with OpenTelemetry. It solves the problem of getting traces, metrics, and logs out of C++ code and into a backend without tying that code to a specific vendor. The project status is marked stable across all three signals, which is a meaningful milestone for a language where telemetry libraries often lag behind their Java or Go counterparts. The intended audience is application owners and library authors who need to add observability to C++ codebases, whether they are building a small library or a large service. The README points to a getting started guide and reference documentation on readthedocs, and the examples/simple directory shows a minimal program instrumenting a library with a console exporter. That example is the clearest entry point for someone evaluating the client.

How the Client Is Organized and What It Ships

The repository is structured around the three OpenTelemetry signals: traces, metrics, and logs. Each signal has its own API and SDK components, and the code is built around processors and exporters. The README's example uses a simple processor and a console exporter, which is the minimal pipeline: you create a span or metric, send it through a processor, and the exporter writes it out. The actual data flow is not described in detail in the supplied material, but the presence of processors and exporters indicates a pipeline architecture similar to other OpenTelemetry implementations. The project also ships build files for both CMake and Bazel, which is a practical decision for a C++ library that needs to fit into different build ecosystems. The README does not list the full set of exporters or processors available, so you would need to check the documentation for the complete inventory.

C++ Standard Support and Platform Coverage

The client supports C++14, C++17, C++20, and C++23, with exceptions noted in individual README files. That is a broad range, which is good for adoption in older codebases that have not moved to modern C++. The project explicitly states that supporting the C programming language is not a goal, so any C codebase would need a different solution. The CI pipeline builds and tests on Ubuntu 22.04 and 24.04, macOS 14 and 15, and Windows Server 2022 and 2025, with both x86-64 and arm64 architectures covered. The build types vary: CMake is used on all platforms, while Bazel is tested on Ubuntu 24.04, macOS 15, and Windows Server 2022. This gives a reasonable assurance that the code compiles on mainstream platforms, but it does not guarantee support for less common architectures or older compiler versions. The README claims that the code should build on all platforms having a C++ compiler with the supported standards, but that is a general statement, not a tested guarantee.

Getting It Running: Bazel and CMake

For Bazel users, the path is straightforward. The project is available in the Bazel Central Registry, and the README shows the exact line to add to your MODULE.bazel file: bazel_dep(name = "opentelemetry-cpp", version = "x.y.z"). You replace x.y.z with the latest version from the BCR page. For CMake, the README refers to INSTALL.md, which is not included in the supplied material, so the exact CMake commands are not visible here. The examples/simple directory contains build files for both CMake and Bazel, which gives you a working reference for how to link the library. The dependency requirements are documented in docs/dependencies.md, which you should consult before integrating, especially for license compliance. The README does not show a minimal CMake snippet, so you will need to read INSTALL.md or the example build files to get the exact commands.

A Genuine Limitation: Spec Compliance Is Partial

The project is marked stable across all three signals, but that does not mean it implements every part of the OpenTelemetry specification. The README points to a spec compliance matrix to understand which portions have been implemented. This is a critical caveat. If your use case depends on a specific specification feature, such as a particular semantic convention or a trace context propagation format, you need to verify it is implemented in this client. The compliance matrix is the authoritative source, but it is not included in the README, so you must check it separately. Another limitation is the lack of C language support. If your project is a C library or has a C API, this client will not work for you. The README is explicit about this, but it is easy to overlook when evaluating a C++ client.

Alternatives and How They Differ

The main alternative for C++ observability is the OpenTracing C++ library, which predates OpenTelemetry and focuses only on traces. The core difference is scope: OpenTracing C++ does not handle metrics or logs, so you would need separate libraries for those signals. OpenTelemetry C++ aims to unify all three, which reduces the number of dependencies in your codebase. Another alternative is to use a vendor-specific SDK, such as the one from a cloud provider, which may offer tighter integration with that vendor's backend but locks you into a proprietary API. The trade-off is between a standard, multi-vendor API and a more specialized, possibly more feature-rich vendor SDK. The choice depends on whether you value portability over vendor-specific features.

Maintenance, Upgrades, and Licensing

The project is under active maintenance, with recent releases every two to three months: v1.28.0 in July 2026, v1.27.0 in May 2026, and v1.26.0 in March 2026. This cadence means you should expect regular updates, which is good for bug fixes but also means you need to track release notes for breaking changes. The README mentions a weekly community meeting and a public Google doc for meeting notes, which indicates an open governance process. The license is Apache-2.0, which is permissive for commercial use, but you should check the dependencies.md file for the licenses of third-party dependencies, as the README specifically references it for OSS dependencies and license requirements. That file is not included in the supplied material, so you cannot assess the full license implications without reading it. The project also has a FOSSA badge for license and security scanning, which suggests some automated checking, but the details are not in the README.

Editorial conclusion

Adopt OpenTelemetry C++ if your project needs native observability across traces, metrics, and logs and you can live with the spec compliance gaps that remain. Do not adopt it if you need C language support, which the project explicitly excludes, or if your build environment falls outside the CI-tested platforms listed in the README. Before committing, verify the exact spec compliance status for the signals you care about against the compliance matrix, and check the latest release notes for any breaking changes in the version you plan to use. The project is stable, but stability across all three signals does not mean every specification feature is implemented.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes