What you will learn in this TP
- Create spans with the SDK
- Report errors, events and links
- Query with TraceQL and sample
Introduction #
What you will learn in this section
- Create spans with the SDK
- Report errors, events and links
- Query with TraceQL and sample
Context. The order service has no auto-instrumented library for its business logic. You instrument it by hand to see an order's steps, its payment errors and its batch processing.
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: 50 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. Initialise the SDK
Why? The TracerProvider holds the resource and exporter; the BatchSpanProcessor sends in batches.
Install the SDK and the OTLP/HTTP exporter, then writeotel_setup.pyconfiguring the resource (service.name,service.version,deployment.environment.name) and export.3. Create a business trace
Why? Spans named per step, with SpanKind and convention-compliant attributes, make the trace readable by every tool.
Writecommande.py: a root spantraiter commandeand three children (stock as CLIENT with database attributes, computation, payment), an event, and a payment error one time in three withrecord_exceptionand ERROR status.4. Explore and query with TraceQL
Why? TraceQL filters on span structure and attributes: one query finds the traces that matter.
In Grafana, open Explore > Tempo. Run the queries below, open a failed trace and find the event and exception of thepayerspan.5. Link a batch job with links
Why? A batch processing items from several traces cannot have several parents: use links.
Writelot.py: three independent "reception" traces, then afacturer lotspan linked to all three. Find the links in the span details.6. Sample
Why? Ratio sampling reduces volume; parentbased ensures a trace is kept or dropped as a whole.
Re-runcommande.pywith 20% sampling and compare the number of traces received; check no trace is partial. Explain why Collector tail sampling would be better to keep all errors.
Difficulty level : ●●●○○ (3/5)
My progress
Sign in to track your progress and take notes. Sign in
Recommended Articles
Instrumenter ses applications pour Jaeger avec OpenTelemetry
Envoyer des traces à Jaeger avec OpenTelemetry : auto-instrumentation (Java, Python, Node.js), SD...
Corréler traces, métriques, logs et profils avec OpenTelemetry
Relier les quatre signaux pour diagnostiquer vite : ressource commune, trace_id dans les logs, ex...
Envoyer des traces vers Tempo : instrumentation OpenTelemetry et Alloy
Produire et acheminer des traces vers Tempo : auto-instrumentation Python/Java/Node, SDK manuel, ...
Bonnes Pratiques OpenTelemetry (OTel) : Le Guide de l'Observabilité Moderne
Maîtrisez OpenTelemetry grâce à nos conseils d'experts : implémentation du Collector, respect des...
Les profils, le quatrième signal d'OpenTelemetry : profilage continu et corrélation avec les traces
Comprendre le nouveau signal profile d'OpenTelemetry : profilage continu, flame graphs, modèle de...
Grafana Tempo ou Jaeger : quel backend de traces choisir ?
Comparatif détaillé de Grafana Tempo et Jaeger : architecture, stockage, recherche, langage de re...
Tempo : générer des métriques à partir des traces (service graph, span metrics, exemplars)
Activer le metrics-generator de Tempo : service graphs, span metrics RED, remote write vers Prome...
Instrumenter ses applications pour Pyroscope : SDK, Alloy et eBPF
Envoyer des profils à Pyroscope depuis Go, Java, Python et Node.js avec les SDK, collecter les po...
Projet fil rouge : les quatre signaux de l'OpenTelemetry Demo dans la stack Grafana
Un projet fil rouge qui traverse les formations d'observabilité : déployer l'OpenTelemetry Demo, ...