The latest News and Information on Distributed Tracing and related technologies.


Migrating from Jaeger client to OpenTelemetry SDK

A couple of years ago, the OpenTelemetry project was founded by the merger of two similarly aimed projects: OpenTracing and OpenCensus. One of the goals of this new project was to create an initial version that would “just work” with existing applications instrumented using OpenTracing and OpenCensus.

Instrumentation for C# .NET Apps with OpenTelemetry

OpenTelemetry is the recommended path today for instrumenting applications with tracing in a standard, vendor-agnostic and future-proof way. In fact, OpenTelemetry (nicknamed OTEL) encompasses all three pillars of observability: tracing, metrics, and logs. The tracing element of the specification is now stable with the rest following. This is innovative stuff! You can read more on OpenTelemetry and the current release state on this guide.

Auto-Instrumenting Python Apps with OpenTelemetry

In this tutorial, we will go through a working example of a Python application auto-instrumented with OpenTelemetry. To keep things simple, we will create a basic “Hello World” application using Flask, instrument it with OpenTelemetry’s Python client library to generate trace data and send it to an OpenTelemetry Collector. The Collector will then export the trace data to an external distributed tracing analytics tool of our choice.


Vendor Switching With OpenTelemetry (OTel)

You might already know that OpenTelemetry is the future of instrumentation. It’s an open-source and vendor-neutral instrumentation framework that frees you from the trap of using proprietary libraries simply to understand how your code is behaving. Best of all, you can instrument your applications just once and then take that instrumentation to any other backend system of your choice. This blog shows you exactly how to use OpenTelemetry to ✨break the vendor lock-in cycle.✨


The Future of Sumo Logic Observability

I have always found data collection to be a fascinating area of work at Sumo Logic. Collecting data is a critical first step for all the solutions we develop for our customers. After all, to observe the health and performance of your applications, you must first collect all relevant data. It's also an area that has seen some significant activities by the open-source community over the years, which is completely changing the landscape of observability as we know it.


What is OpenTelemetry: A guide to understanding OpenTelemetry and the way forward

OpenTelemetry is a vendor-neutral approach that enables DevOps and developers to collect performance metrics in a standardized manner. Currently a Cloud Native Computing Foundation (CNCF) sandbox project, OpenTelemetry was conceived by merging OpenCensus, Google's open-source method of collecting metrics and traces, and OpenTracing, a vendor-neutral API to collect traces.


What Is Distributed Tracing?

Modern software development is evolving rapidly, and while the latest innovations allow companies to grow through greater efficiency, there is a cost. Modern architectures are incredibly complex, which can make it challenging to diagnose and rectify performance issues. Once these issues affect customer experience, the consequences can be costly. So, what is the solution? Observability — which provides a visible overview of the big picture.


Intro to distributed tracing with Tempo, OpenTelemetry, and Grafana Cloud

I’ve spent most of my career working with tech in various forms, and for the last ten years or so, I’ve focused a lot on building, maintaining, and operating robust, reliable systems. This has led me to put a lot of time into researching, evaluating, and implementing different solutions for automatic failure detection, monitoring, and more recently, observability. Before we get started: What is observability?