The Current State of OpenTelemetry in .NET

OpenTelemetry vs. OpenTracing and the Future of Observability in .NET

In the past we’ve discussed why distributed tracing is becoming commonplace and the OpenTracing standard for instrumenting libraries and applications. In this post I want to touch on the emerging OpenTelemetry standard, which will become a common component used to instrument ASP.NET Core applications in the not too distant future.

OpenTelemetry logo

What is OpenTelemetry?

OpenTelemetry is the convergence of two competing tracing standards:

  • OpenTracing - developed by a community of APM vendors and library authors and
  • OpenCensus - developed by Google.

The goal is to provide a unified set of APIs library authors can include inside their applications in order to:

  • Propagate distributed tracing context, including the new W3C HTTP tracing standard;
  • Aggregate metrics (counters, meters, etc); and
  • Export metrics and trace data to a variety of different Application Performance Monitoring (APM) backends, which can be configured entirely by the application developer.

OpenTelemetry vs. OpenTracing

OpenTelemetry vs. OpenTracing

So what are the material differences between OpenTelemetry and OpenTracing? Why do we need another new standard?

The major technical differences are:

  1. OpenTelemetry’s core library is the Tracer implementation - the traces are created and correlated using OpenTelemetry calls and then only during the export process do the traces hit any vendor-specific code. This makes the performance of OpenTelemetry very consistent regardless of what vendors end-users choose. In contrast, with OpenTracing all of the real calls are done by a vendor-specific implementation of the OpenTracing APIs - so as a library author you could have a great set of benchmarks using a Zipkin OpenTracing library but not-so-great ones using a Jaeger OpenTracing library. I prefer OpenTelemetry’s approach here.
  2. OpenTelemetry supports metrics instrumentation in addition to tracing - a library author...

Akka.NET v1.4 is Available on .NET Standard 2.0

Akka.Remote Performance Improvements, Akka.Cluster.Sharding out of Beta, Akka.Cluster.Metrics, and More

As of this week, Akka.NET v1.4 is now fully available for users to use. We’ve published a detailed article on the Akka.NET website that describes what’s new in Akka.NET v1.4, but we wanted to capture some of the highlights here.

Akka.Cluster.Sharding and Akka.DistributedData are out of Beta

Akka.Cluster.Sharding has been used by Akka.NET users in production for years, mostly relying on the underlying Akka.Persistence storage engine to save all of the sharding state used to distributed entity actors evenly across the cluster.

Akka.Cluster.Sharding actor distribution

However, the reason why the module remained in beta for the past couple of years is because Akka.Cluster.Sharding’s alternate storage mode, Akka.DistributedData, which uses eventually consistent in-memory replication to manage cluster sharding state throughout an Akka.NET cluster, lacked a stable wire format and hadn’t been certified for production yet.

Introduction to Akka.Streams

Building High-Level Streaming Worklows in Akka.NET

The goal of this blog post is to give you a glimpse of the idea and basics behind Akka.Streams. What they are and why you may find them useful addition in your day to day job.

In short: Akka.Streams is a library build on top of Akka.NET, which allows you to consume and process potentially infinite streams of data in type-safe and resource-safe way.

To make it easier to visualize, let’s take an example: we have a queue (i.e. RabbitMQ), that sends us a documents, which we have to parse, turn into structured data and save in the database.