Today, we are launching a new Grafana Labs product, Grafana Enterprise Traces. Powered by Grafana Tempo, our open source distributed tracing backend,.and built by the maintainers of the project, this offering is an exciting addition to our growing self-managed observability stack tailored for enterprises.

After years of helping developers monitor and debug their production systems, we couldn’t help but notice a pattern across many of them: they roughly know that metrics and traces should help them get the answers they need, but they are unfamiliar with how metrics and traces work, and how they fit into the bigger observability world. This post is an introduction to how we see observability in practice, and a loose roadmap for exploring observability concepts in the posts to come.

I am honored to be able to talk about Splunk’s investment and commitment to the OpenTelemetry project. I would like to take this opportunity to talk about the latest in the OpenTelemetry community, as well as the instrumentation and data collection distributions available from Splunk. Be sure to read through the whole post, as you will find some roadmap information too!

I joined Grafana Labs as a software engineer in October to help build out a team focused on OpenTelemetry, and within a few weeks, I was promptly encouraged to run for a seat on the OpenTelemetry board. Every year, the OpenTelemetry community holds elections for a few seats on the Governance Committee board, which oversees the project at large. The results of this year’s elections are now available, and I am glad to share that I have been elected to serve on the board!

When managing distributed environments, we find ourselves challenged with looking for different ways to understand performance better. Telemetry data is critical for solving such a challenge and helping DevOps and IT groups understand these systems’ behavior and performance. To get the most from telemetry data, it has to be captured and analyzed, then tagged to add relevant context, all while being sure to maintain the security and efficiency of user and business data.

The primary goal of OpenTelemetry (OTEL) is to offer vendor-neutral ways of application instrumentation such that customers are able to switch between Telemetry backends. There are three main components of OpenTelemetry: OpenTelemetry SDK, OpenTelemetry API, and OpenTelemetry Collector. In this blog, we will be covering the architecture, deployment, and best practices of consuming an OTEL collector.

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.

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.

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.