Operations | Monitoring | ITSM | DevOps | Cloud

If a checkout slows down or an API call fails, why can the cause stay hidden for so long while every service dashboard looks fine? One customer click in a microservices setup may hit a gateway and a few backend services first, then a queue or a database. Every hop logs its own events, yet none of those logs points back to the original request. Distributed tracing was created to solve exactly this. Zipkin arrived early, as one of the first open-source tracers.

This post is about a recent change to the Sentry JavaScript SDKs. If you don’t use Sentry with JavaScript, it may still be useful as a look at how we made the change and why. In the Sentry JavaScript SDK v11, we rebuilt how our tracing integrations work. While we still support the OpenTelemetry standard (described in more detail below), we now instrument your dependencies with a code transformer instead of using the OpenTelemetry instrumentation classes as we did in previous versions.

If you’ve built your telemetry pipelines around OpenTelemetry Collectors, you’ve already invested in a collector distribution, YAML configuration, and a deployment model that fits your infrastructure. As that deployment grows, managing it means keeping shared configuration consistent, accommodating different workloads, and understanding whether your collectors are healthy. Fleet Management in Grafana Cloud brings those tasks together in one place.