There is more to Distributed Tracing with Jaeger than just capturing machine data as with metrics, or tailing log files. To start, you should read this primer. In this article, I will walk you through the initial principles you’ll need before executing anything within your codebase. This is going to focus on Node.js, as slight differences and concerns exist for browser applications.

Grafana Tempo, the recently announced distributed tracing backend, relies on integrations with other data sources for trace discovery. Tempo’s job is to store massive amounts of traces, place them in object storage, and retrieve them by ID. Logs and other data sources allow users to quickly and more powerfully jump directly to traces than ever before. Previously we investigated discovering traces with Loki and exemplars.

This post aims to provide a very simple beginner’s guide to Jaeger + OpenTracing instrumentation for Go applications (the terms “application” and “service” is used interchangeably in this document) via a working example. If you are new to instrumentation, I recommend that you first read this post for a practical introduction to instrumentation for Jaeger and OpenTracing. You can also get more info on using logs in Go.

Every journey in distributed tracing starts with instrumenting an application to emit or extract trace data from each service as they execute. There are many ways to instrument, including the use of SDKs and pre-configured frameworks, and many protocols for transmitting the trace data to the analysis tool.

We at Sumo Logic believe in an open, flexible, community-driven approach to collecting observability data. Those reasons are outlined in one of my recent blogs. In that publication, I share the belief that an application’s observability gains traction from the fact that telemetry signals are designed, composed, and produced by an application developer/vendor in compliance with industry standards, and are not a proprietary, black box component of the monitoring vendor.

We’ve released support for tracing header interoperability in all of our Beelines. This means you can now mix and match distributed services instrumented with Beelines or with OpenTelemetry, and your traces will be preserved in Honeycomb!

Back in March, we introduced the Grafana Cloud Agent, a subset of Prometheus built for hosted metrics. It uses a lot of the same battle-tested code as Prometheus and can save 40 percent on memory usage. Ever since the launch, we’ve been adding features to the Agent. Now, there’s a clustering mechanism, additional Prometheus exporters, and support for Loki. Our latest feature: Grafana Tempo! It’s an easy-to-operate, high-scale, and cost-effective distributed tracing system.

Implementing distributed tracing is fast becoming a fundamental expectation when building modern (distributed) systems. However, this is yet another thing for developers to learn, and configuring distributed tracing on Kubernetes is hard, right? Actually, no. Getting started with Jaeger on Kubernetes has never been easier.

Yesterday we were excited to announce Logz.io Distributed Tracing, the most recent addition to our Cloud-Native Observability Platform. This is such a special launch for us because it makes Logz.io the only place where engineers can use the best open source monitoring tools for logs, metrics, and traces – known as the ‘three pillars’ to observability – together in one place.

Today was a monumental day for Logz.io and our entire community. There is nothing more inspiring than seeing how people use the technology we’ve built to enhance their businesses. At ScaleUP 2020, our first ever global user conference, we hosted an exciting day of technical, customer-led sessions with our community. We also had the privilege of unveiling some ground-breaking new solutions and enhancements to our end-to-end cloud-native observability platform.