OpenTelemetry vs. OpenCensus

OpenCensus and OpenTelemetry are two popular observability solutions. Read on to understand the similarities, differences, and capabilities of both. 

What is OpenCensus?

OpenCensus is an open-source observability framework with instrumentation tools, metrics, and trace collection libraries. It provides a metrics library that allows developers to capture various metrics types, a tracing library for end-to-end visibility into request flow across services in distributed systems, and vendor-neutral exporters compatible with different observability backends.

OpenCensus also provides an optional central exporter service—OpenCensus Agent—which aggregates telemetry data and sends it to pre-configured exporters.  

OpenCensus Features

Some of OpenCensus’ features are explained below.

APIs

OpenCensus has an array of vendor-neutral APIs—including stats, tracing, and tags—for defining and capturing (custom) metrics and distributed traces and adding spans and other metadata to traces for contextualization. 

Context Propagation

As OpenCensus enables the tracking and correlating of telemetry data across different components and services, it also ensures that relevant contextual information—such as request or session IDs—remains attached to the data. 

Sampling

OpenCensus’ sampling feature provides statistically accurate data processing, filtering, and grouping to ease navigation during analysis. Via sampling, developers can configure data collection rates and ensure that collected data does not throttle the telemetry pipeline. These enable OpenCensus to limit telemetry traffic, balance data collection costs, and reduce storage costs. 

Exporters

OpenCensus exporters automatically transform and send telemetry data to users’ preferred telemetry backends—such as Prometheus, Zipkin, and Jaeger—for visualization and analysis. While OpenCensus exporters support various backends, the backend chosen will determine the instrumentation language and the telemetry type to be exported.

Language Support

OpenCensus offers libraries and SDKs for multiple programming languages, including Java, Go, Node.js, Python, PHP, C/C++, and Erlang, allowing developers to instrument applications regardless of the language of your codebase.

What is OpenTelemetry?

OpenTelemetry (OTel) is an open-source framework that combines features from OpenTracing and OpenCensus into a fit-for-all framework for telemetry data collection and export. 

OpenTelemetry Features

OpenTelemetry incorporates OpenCensus’ most important features (discussed earlier) and adds the following for improved observability. 

Automatic Instrumentation

With OTel, you can initialize signal providers to capture metrics, traces, and logs—as well as accompanying metadata—without modifying the application codebase. 

Logging

Beyond metrics and traces, OTel allows you to capture logs to provide contextual information on application errors and events to enhance your understanding of application behavior.

Language-Specific SDKs

OpenTelemetry provides Software Development Kits (SDKs) and instrumentation libraries that support popular programming languages, making it easier to instrument applications for telemetry collection and more.

Context Propagation

OpenTelemetry enables automatic context propagation, meaning that when a request flows through microservices, the context (including trace and span IDs) is automatically propagated.

Extensibility

OpenTelemetry offers extension points and a flexible architecture that supports custom instrumentation and exporters, making it adaptable regardless of application requirements and environments.

Comparing OpenCensus with OpenTelemetry

While OpenCensus and OpenTelemetry share certain features and goals, they have essential differences, as presented in the table below. 

Choosing between OpenCensus and OTel

Choosing between OpenTelemetry and OpenCensus is a question of security and functionalities because, as of July 2023, OpenCensus is no longer maintained and any security vulnerabilities that are found will not be patched. Additionally, OpenCensus has laid the foundation for instrumenting metrics and traces, while OpenTelemetry builds upon that foundation to provide a more comprehensive observability solution.

If you are starting a new project or currently using OpenCensus, consider adopting or migrating to OpenTelemetry, as it offers a secure, comprehensive, and future-oriented approach to observability in distributed systems.  

Migrating from OpenCensus to OpenTelemetry

OpenTelemetry enhances tracing accuracy by requiring parent spans to be specified during child span creation. This approach is more robust than OpenCensus, which allows flexible parent span specification after initialization. While this change may require adjustments when migrating from OpenCensus APIs, it leads to more consistent and reliable trace hierarchies in distributed systems.

If you are currently using OpenCensus and want to migrate to OpenTelemetry, below is an overview of the migration steps and the language version support.

Language Version Support

For easy migration, OpenTelemetry provides backward compatibility bridges for several programming languages. Below is an overview of the language version supports for OpenCensus and OpenTelemetry.

Migration Overview

To migrate from OpenCensus to OpenTelemetry, follow the steps below. Code samples are provided using the Docker version.

Step 1: Update Dependencies

Open your project's dependency file (e.g., pom.xml for Java, go.mod for Go) and replace OpenCensus dependencies with corresponding OpenTelemetry dependencies. For Java with Maven, update your pom.xml:

<!– OpenCensus -->
<dependency>
    <groupId>io.opencensus</groupId>
    <artifactId>opencensus-api</artifactId>
    <version>0.27.0</version>
</dependency>

<!-- OpenCensus Exporter -->
<dependency>
    <groupId>io.opencensus</groupId>
    <artifactId>opencensus-exporter-trace-stdout</artifactId>
    <version>0.27.0</version>
</dependency>

<!-- Replace with OpenTelemetry dependencies -->

Step 2: Replace Code Usage

Update your code to use the OpenTelemetry API and replace the OpenCensus code with equivalent OpenTelemetry calls.

For Java:

// OpenCensus
import io.opencensus.trace.Tracer;
import io.opencensus.trace.Tracing;

// ...

Tracer tracer = Tracing.getTracer();
tracer.spanBuilder("my-span").startSpan().end();

// Replace with OpenTelemetry
import io.opentelemetry.api.trace.Tracer;
import io.opentelemetry.api.Trace;
import io.opentelemetry.api.OpenTelemetry;

// ...

Tracer tracer = OpenTelemetry.getTracerProvider().get("your-instrumentation-library-name");
tracer.spanBuilder("my-span").startSpan().end();

For Go:

// OpenCensus
import "go.opencensus.io/trace"

// ...

tracer := trace.New("your-instrumentation-library-name")
span := tracer.StartSpan("my-span")
defer span.End()

// Replace with OpenTelemetry
import (
    "go.opentelemetry.io/otel"
    "go.opentelemetry.io/otel/trace"
    "context"
)

// ...

tracer := otel.GetTracerProvider().Tracer("your-instrumentation-library-name")
ctx, span := tracer.Start(context.Background(), "my-span")
defer span.End(ctx)

For Python:

# OpenCensus
from opencensus.trace import Tracer

# ...

tracer = Tracer()
with tracer.span(name="my-span"):
    pass

# Replace with OpenTelemetry
from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.trace import Tracer

# ...

trace.set_tracer_provider(TracerProvider())
tracer = trace.get_tracer("your-instrumentation-library-name")

with tracer.start_as_current_span("my-span"):
    pass

Step 3: Update Instrumentation

Update custom instrumentation or exporters to corresponding OpenTelemetry API and exporters using language and case-specific code. 

Update Imports:

Replace imported OpenCensus packages with equivalent OpenTelemetry packages. For example, in Java, you might replace io.opencensus.trace.Tracer with io.opentelemetry.api.trace.Tracer.

Replace API Calls:

Update instrumentation code to use equivalent OpenTelemetry API calls by replacing method calls, function invocations, or class instantiations with their OpenTelemetry counterparts. For example, replace Tracer.startSpan() with tracer.spanBuilder().startSpan().

Configure Exporters:

Update custom exporters set up in your instrumentation code with compatible OpenTelemetry exporters by modifying configuration settings or updating the initialization code for the exporters.

Step 4: Test and Verify

Run your application with the updated code and ensure the desired telemetry data is captured and exported successfully to your chosen backend. 

Conclusion

OpenCensus and OpenTelemetry offer potent methods for collecting and analyzing telemetry data in modern distributed systems. However, OpenCensus is now deprecated, while OpenTelemetry is the recommended observability platform, as it captures more telemetry data types, offers an extensible, comprehensive observability solution, and has ongoing support. 

FAQs

Can OpenCensus and OpenTelemetry be used together?

Yes, but this is not recommended since the former has been deprecated. Moreover, OpenTelemetry supports legacy systems instrumented using OpenCensus and offers an easy-to-use migration path for OpenCensus users. 

How does OpenTelemetry differ from other observability frameworks?

OpenTelemetry offers a more standardized and overarching approach to collecting telemetry data. It provides a unified set of APIs and instrumentation libraries and supports several observability backends. 

How does OpenTelemetry handle security and privacy concerns?

OpenTelemetry has massive industry support, enabling it to follow industry-standard security practices. It supports secure telemetry data transmission via encryption, provides authentication and access control mechanisms, and supports redaction and scrubbing of sensitive information to ensure privacy.

What are the benefits of using OpenTelemetry in a microservices architecture? And does it support cloud environments like Kubernetes and AWS?

OpenTelemetry allows you to trace requests across distributed systems. It also supports Kubernetes, AWS services, Google Cloud Platform, Azure, and other cloud providers. These integrations allow you to collect telemetry data from services running in these environments and gain insights into their performance.