What you will learn in this TP
- Send continuous profiles
- Read a flame graph
- Link spans and profiles
Introduction #
What you will learn in this section
- Send continuous profiles
- Read a flame graph
- Link spans and profiles
Context. A discount service is slow and CPU-hungry, but its traces only show a long span. You add the fourth signal to find the responsible line.
Prerequisites: Docker and Python 3.10 or later; the grafana/otel-lgtm stack (Collector, Tempo, Loki, Prometheus, Pyroscope and Grafana in one container) · Estimated time: 45 min
Hands-on #
Guided steps, with their solution.
1. Start the observability stack
Why? A single image provides an OTLP Collector and every backend: focus on the signal.
Startgrafana/otel-lgtm, create a Python environment and point exporters to OTLP/HTTP port 4318.2. A slow service
Why? The code has a classic flaw: a regular expression recompiled and costly string building on every call.
Install the Pyroscope SDK and its OpenTelemetry integration, then writeremises.py: traces to Tempo, profiles to Pyroscope with the same service name, and thePyroscopeSpanProcessor.3. Read the flame graph
Why? The flame graph shows where CPU is really spent, without adding a single span.
In Explore > Pyroscope (or Drilldown > Profiles), select theremisesapplication and the CPU type. Identify the widest plateaus and the share ofcode_valideandre.compile.4. From span to profile
Why? The span processor tags samples with the span_id: you get the profile of one specific request.
In Tempo, open a longcalculer remisetrace and use Profiles for this span. If the link does not appear, configure Trace to profiles in the Tempo data source (Pyroscope source, CPU type).5. Fix and compare
Why? The profile proves an optimisation's effect instead of assuming it.
Compile the expression once at module level and replace concatenation with';'.join(). Restart, then compare both periods with Pyroscope's Diff view and span duration in Tempo.6. Place OpenTelemetry profiles
Why? The Pyroscope SDK is a proven solution; the OTLP Profiles signal aims to unify collection but is not stable yet.
Check the profiles signal status page on opentelemetry.io and the OpenTelemetry eBPF profiler documentation. Write in three lines what replacing the SDK with the eBPF profiler and a Collector would take, then stop the stack.
Difficulty level : ●●●○○ (3/5)
My progress
Sign in to track your progress and take notes. Sign in
Recommended Articles
Grafana Alloy: Log Management with Loki
Discover how to configure Grafana Alloy to read log files, journald, or network streams, process ...
Grafana Alloy: Trace Management with Tempo
Dive into distributed trace processing. Learn how to ingest OTLP, Jaeger, or Zipkin traces with G...
Grafana Alloy: Continuous Profiling with Pyroscope
Discover how to configure continuous profiling in your environments using Grafana Alloy and Pyros...
Grafana Alloy: Advanced Deployment and Clustering
Learn how to manage large-scale Grafana Alloy deployments. Configure Clustering mode for high ava...
Grafana Assistant: AI at the service of observability
Discover Grafana Assistant, the artificial intelligence integrated into Grafana Cloud. Learn how ...
Grafana Alloy vs OpenTelemetry Collector: Which One Should You Choose?
A detailed comparison between Grafana Alloy and the OpenTelemetry Collector. Discover the strengt...
Grafana Alloy vs Dynatrace ActiveGate: Which to choose?
Comparison between Grafana Alloy and Dynatrace ActiveGate. Understand the fundamental differences...
Application Protection
Learn how to secure your backends against abuse and common attacks. A practical guide to Rate Lim...