Operations | Monitoring | ITSM | DevOps | Cloud

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

OpAMP for OpenTelemetry: Managing Collector Fleets and Introducing the New OpAMP Gateway Extension

Today, Bindplane is launching the OpAMP Gateway Extension in alpha — a new component that extends OpAMP fleet management into network-segmented and firewalled environments where direct agent-to-server connectivity is not possible. It also addresses fleet scaling by fanning many agent connections into a small upstream pool, reducing connection load on the OpAMP server. We also hope to donate the OpAMP Gateway Extension upstream to the OpenTelemetry project and welcome community contributions.

Native OpenTelemetry inside Alloy: Now you can get the best of both worlds

We're big proponents of OpenTelemetery, which has quickly become a new unified standard for delivering metrics, logs, traces, and even profiles. It's an essential component of Alloy, our popular telemetry agent, but we're also aware that some users would prefer to have a more "vanilla" OpenTelemetry experience.

Claude Agent SDK Monitoring & Observability with OpenTelemetry and SigNoz

Learn how to implement monitoring and observability for the Claude Agent SDK using OpenTelemetry and SigNoz. In this video, we walk through instrumenting your Claude-based agents, capturing traces, metrics, and logs, and visualizing everything in SigNoz for real-time insights. You’ll learn how to debug agent behavior, identify latency bottlenecks, and monitor performance in production environments.

Routing OpenTelemetry logs to Sentry using OTLP

If you've already instrumented your app with OpenTelemetry, you don't have to rip it out to use Sentry. Two environment variables and your logs start flowing into Sentry, no SDK changes, no re-instrumentation. Here's how to set it up in a sample app, and when the native Sentry SDK might be the better call.

Generating metrics from traces with cardinality control: A closer look at HyperLogLog in Tempo

While tracing is a critical component of any observability strategy, metrics — especially RED metrics (request rate, error rate, and duration) — are widely considered the gold standard for monitoring service health. Tempo, the open source, easy-to-use, and highly scalable distributed tracing backend, is well known in the OSS community for storing and querying traces. It can also, however, generate RED metrics directly from those traces using the optional metrics-generator component.

OpenTelemetry traces for Bitbucket Pipelines via webhooks

Continuous delivery is only as good as your ability to understand what’s happening inside your pipelines. When a build is slow, flaky, or burning through capacity, you need more than a green/red status and a wall of logs — you need traces. Bitbucket Pipelines now exposes pipeline execution as OpenTelemetry (OTel) traces via webhook events. This lets you stream detailed pipeline spans into your own observability stack and correlate them with the rest of your system. This post walks through.

Behind the magic of auto-instrumentation (Grafana OpenTelemetry Community Call)

You add the OpenTelemetry Java agent, restart your app - and like magic, observability appears. But is it really magic? What’s actually enabled by default? What telemetry should you expect to see? What’s missing? And what might you want to tweak, tune, or even turn off?
Sponsored Post

SAP Application Performance Monitoring (APM): Beyond Generic Metrics

Your enterprise APM tool shows SAP is using 90% CPU. The dashboard turns red. An alert fires. Now what? You open Dynatrace. You see the Java Virtual Machine metrics for your NetWeaver stack. You see HTTP response times for your Fiori apps. You see a spike in database calls. None of this tells you why VA01 takes 45 seconds to create a sales order. None of this tells you which custom ABAP report is consuming memory. None of this explains the short dump that crashed your pricing routine. This is the gap between generic APM and true SAP application performance monitoring. Your enterprise tools see the symptoms.

Claude Code + OpenTelemetry: Per-Session Cost and Token Tracking

I was looking at our Claude Code spend in the Anthropic console the other day. Aggregate cost, aggregate tokens — no breakdown by developer, no breakdown by session. I knew my Hackathon team had been using it heavily on building out new features for the OpenTelemetry Distro Builder. But heavily how? I had no idea. Turns out Claude Code has been emitting OpenTelemetry signals the whole time. Per-session cost, token counts, every tool call it makes on your codebase.