1. Anatomie d'une trace #
Trace, span, contexte.
Trace et spans #
Une trace représente le parcours complet d'une requête. Elle se compose de spans : des opérations nommées, avec un début, une fin, un parent, des attributs, des événements et un statut. Tous les spans partagent le même trace_id (16 octets) ; chacun a son span_id (8 octets).
| Champ | Rôle |
|---|---|
| name | opération, à faible cardinalité : GET /users/{id} |
| trace_id, span_id, parent_span_id | structure de l'arbre |
| start / end | durée |
| kind | rôle du span dans l'échange |
| attributes | contexte (semconv) |
| events | faits horodatés pendant le span |
| links | relations avec d'autres traces |
| status | Unset, Ok ou Error |
SpanKind #
| Kind | Quand | Exemple |
|---|---|---|
| SERVER | réception d'une requête synchrone | handler HTTP, méthode gRPC |
| CLIENT | appel synchrone sortant | requête HTTP, requête SQL |
| PRODUCER | envoi d'un message asynchrone | publication Kafka, RabbitMQ |
| CONSUMER | traitement d'un message reçu | consommateur Kafka |
| INTERNAL | opération interne | calcul, étape métier |
2. Instrumenter manuellement #
Attributs, statut, événements, liens.
Créer des spans #
from opentelemetry import trace
from opentelemetry.trace import SpanKind, Status, StatusCode, Link
tracer = trace.get_tracer("shop.checkout", "1.4.0")
def payer(commande):
with tracer.start_as_current_span("payer commande", kind=SpanKind.INTERNAL) as span:
span.set_attribute("shop.order.id", commande.id) # attribut métier
span.set_attribute("shop.order.amount", commande.total)
span.add_event("fraude.verifiee", {"shop.fraud.score": 0.12})
try:
passerelle.debiter(commande)
except PaiementRefuse as exc:
span.record_exception(exc) # événement "exception"
span.set_status(Status(StatusCode.ERROR, "paiement refusé"))
raiseStatut et erreurs #
Le statut vaut Unset par défaut. On le passe à Error quand l'opération a échoué ; on ne met Ok que pour forcer un succès malgré une règle contraire. Pour HTTP, les conventions disent : côté serveur, seules les réponses 5xx sont des erreurs ; côté client, 4xx et 5xx le sont.
Erreur Courante : N'utilisez pas les attributs pour stocker des données volumineuses ou personnelles (corps de requête, e-mails) : coût, cardinalité et RGPD.
Liens #
Un lien relie un span à un ou plusieurs autres contextes sans relation parent-enfant : un traitement par lots qui agrège 100 messages venant de 100 traces différentes, ou une tâche asynchrone déclenchée par une requête. tracer.start_as_current_span("lot", links=[Link(ctx1), Link(ctx2)]).
3. Le pipeline des spans dans le SDK #
Processors, exportateurs, limites.
Span processors #
| Composant | Rôle |
|---|---|
| SimpleSpanProcessor | exporte chaque span à sa fin : uniquement pour le débogage |
| BatchSpanProcessor | regroupe et exporte par lots : à utiliser en production |
| Limites | OTEL_SPAN_ATTRIBUTE_COUNT_LIMIT, OTEL_SPAN_EVENT_COUNT_LIMIT protègent contre l'explosion de taille |
Arrêt propre #
Bonne Pratique : Appelezprovider.shutdown()(ouforce_flush()) à l'arrêt d'un processus court (job, fonction serverless) : sinon le dernier lot de spans est perdu.
4. Échantillonnage #
Garder les bonnes traces sans payer pour toutes.
Head et tail #
| Échantillonneur (SDK) | Comportement |
|---|---|
always_on / always_off | tout ou rien |
traceidratio | garde un ratio, calculé sur le trace_id (décision identique partout) |
parentbased_traceidratio | suit la décision du parent ; ratio pour les traces qui démarrent ici (recommandé) |
processors:
tail_sampling:
decision_wait: 10s
policies:
- { name: erreurs, type: status_code, status_code: { status_codes: [ERROR] } }
- { name: lentes, type: latency, latency: { threshold_ms: 1000 } }
- { name: reste, type: probabilistic, probabilistic: { sampling_percentage: 5 } }Erreur Courante : Le tail sampling exige que tous les spans d'une trace arrivent sur le même Collector : placez devant un Collector avec l'exportateur loadbalancing routé par TraceID.Interroger les traces #
{ resource.service.name = "checkout" && status = error }
{ span.http.route = "/orders" && duration > 500ms }
{ span.db.system.name = "postgresql" } | count() > 20 # traces qui font plus de 20 requêtes SQL (N+1)
{ resource.service.name = "frontend" } >> { resource.service.name = "payment" && status = error }Mon suivi
Connectez-vous pour suivre votre progression et prendre des notes. Se connecter
Articles recommandés
Thanos Store Gateway et Compactor : historique, downsampling et rétention
Servir l'historique avec le Store Gateway et optimiser le stockage avec le Compactor : compaction...
Thanos Ruler : règles et alertes sur la vue globale
Évaluer des règles d'enregistrement et d'alerte sur l'ensemble des clusters avec Thanos Ruler : c...
Thanos Receive : ingérer du remote write et gérer le multi-tenant
Utiliser Thanos Receive : mode push avec remote write, hashring, réplication, multi-tenancy, conf...
Déployer Thanos sur Kubernetes (kube-prometheus-stack, Helm et Operator)
Installer Thanos sur Kubernetes : sidecar via kube-prometheus-stack, secret objstore, Bitnami/kub...
Exploiter Thanos : supervision, performances, dépannage et alternatives
Bonnes pratiques d'exploitation Thanos : métriques et alertes clés, mixin, caches, limites, erreu...
Bonnes pratiques Elasticsearch : mappings, shards, cycle de vie et exploitation
Bonnes pratiques Elasticsearch : dimensionnement des shards, mappings explicites, templates, ILM,...
Bonnes pratiques Logstash : pipelines, performances, fiabilité et supervision
Bonnes pratiques Logstash : pipelines multiples, dissect plutôt que grok, conditionnels, persiste...
Bonnes pratiques Prometheus : métriques, cardinalité, règles et exploitation
Bonnes pratiques Prometheus : nommage des métriques, labels et cardinalité, intervalles de scrape...
Bonnes pratiques Grafana : dashboards, provisioning, performances et sécurité
Bonnes pratiques Grafana : conception de dashboards lisibles, variables, dashboards as code, prov...