Both Grafana Tempo and Jaeger are tools aimed at distributed tracing for microservice architecture. Jaeger was released as an open-source project by Uber in 2015, while Tempo is a newer product announced in October 2020. Jaeger is a popular open-source tool that graduated as a project from Cloud Native Computing Foundation. Grafana Tempo is a high-volume distributed tracing tool deeply integrated with other open-source tools like Prometheus and Loki.

We’re excited to bring you relational fields, a new feature that allows you to query spans based on their relationship to each other within a trace. Previously, queries considered spans in isolation: You could ask about field values on spans and aggregate them based on matching criteria, but you couldn’t use any qualifying relationships about where and how the spans appear in a trace.

In the complex world of microservices and distributed systems, achieving transparency and understanding the intricacies and inefficiencies of service interactions and request flows has become a paramount challenge. Distributed tracing is essential in understanding distributed systems. But distributed tracing, whether manually applied or auto-instrumented, is usually rather coarse-grained.

OpenTelemetry has emerged as a key open source tool in the observability space. And as organizations use it to manage more of their telemetry data, they also need to understand how to make it work across their various environments. This guide is focused on scaling the OpenTelemetry Collector deployment across various Linux hosts to function as both gateways and agents within your observability architecture.

As we’ve already shared, Elastic is committed to helping OpenTelemetry (OTel) succeed, which means, in some cases, building distributions of language SDKs. Elastic is strategically standardizing on OTel for observability and security data collection. Additionally, Elastic is committed to working with the OTel community to become the best data collection infrastructure for the observability ecosystem.

You're probably familiar with the concept of real user monitoring (RUM) and how it's used to monitor websites or mobile applications. If not, here's the short version: RUM requires telemetry data, which is generated by an SDK that you import into your web or mobile application. These SDKs then hook into the JS runtime, the browser itself, or various system APIs in order to measure performance.

In the complex world of modern distributed systems, observability is vital. Observability allows engineers to understand what's happening within their systems, debug issues rapidly, and proactively ensure optimal application performance. OpenTelemetry has emerged as a powerful, vendor-neutral solution to address the challenges of observability across different technologies and environments.

Last week we introduced Grafana Alloy, our distribution of the OpenTelemetry Collector with built-in Prometheus pipelines and support for metrics, logs, traces, and profiles. We’re excited to see the community embrace Alloy, and we want to help them use and scale it as easily as possible. Many developers that need to deploy and manage software across several hosts turn to Ansible for its ease of use and versatility.

This article touches on how we at Birdie handled our transition from logs towards using OpenTelemetry as the primary mechanism for achieving world-class observability of our systems.

While OpenTelemetry (OTel) supports a wide variety of data sources and is constantly evolving to add more, there are still many data sources for which no receiver exists. Thankfully, OTel contains receivers that accept raw data over a TCP or UDP connection. This blog unveils how to leverage Linux Command Line Interface (CLI) tools, creating efficient data pipelines for ingestion through OTel's TCP receiver.