RousselTMLEARNING

Article · Opentelemetry : de la découverte à l'expertise

Les métriques en profondeur

1. Le modèle des métriques #

MeterProvider, meters, instruments.

De la mesure au point exporté #

Le code enregistre des mesures sur des instruments créés par un meter. Le SDK les agrège (somme, histogramme, dernière valeur) par combinaison d'attributs, puis un metric reader les exporte périodiquement (60 s par défaut, OTEL_METRIC_EXPORT_INTERVAL).

from opentelemetry import metrics
meter = metrics.get_meter("shop.checkout", "1.4.0")
commandes = meter.create_counter("shop.orders", unit="{order}", description="Commandes validées")
duree = meter.create_histogram("http.server.request.duration", unit="s")
commandes.add(1, {"shop.payment.method": "card"})
duree.record(0.183, {"http.request.method": "POST", "http.route": "/orders", "http.response.status_code": 201})

Les instruments #

Choisir un instrument
Un mauvais choix d'instrument donne des graphiques faux : une file d'attente n'est pas un Counter.
InstrumentSynchroneAsynchrone (observable)Agrégation par défaut
Counteradd() dans le codeObservableCounter (lire un total existant)somme monotone
UpDownCounteradd(+1/-1)ObservableUpDownCountersomme non monotone
Histogramrecord()—histogramme
Gaugeset()ObservableGauge (callback à chaque export)dernière valeur

2. Temporalité et histogrammes #

Deux notions qui surprennent.

Cumulative ou delta #

Temporalité
Prometheus attend du cumulatif ; certains backends SaaS préfèrent le delta.
export OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE=cumulative   # ou delta, lowmemory
À savoir : Le processeur deltatocumulative du Collector convertit le delta en cumulatif avant un envoi vers Prometheus.

Histogrammes #

TypePrincipeAtout
Explicitebornes fixées (par défaut 0, 5, 10, 25… 10000)compatible partout
Exponentielbornes calculées automatiquement à partir d'une échelleprécis sur toute la plage sans réglage ; correspond aux histogrammes natifs Prometheus
Erreur Courante : Les bornes par défaut sont en millisecondes « historiques » : pour une durée en secondes (unit="s"), définissez des bornes adaptées par une vue (0.005, 0.01, 0.025… 10) ou utilisez l'histogramme exponentiel.

3. Vues et cardinalité #

Contrôler ce qui est produit.

Les vues #

from opentelemetry.sdk.metrics import MeterProvider
from opentelemetry.sdk.metrics.view import View, ExplicitBucketHistogramAggregation, DropAggregation
provider = MeterProvider(metric_readers=[reader], views=[
    View(instrument_name="http.server.request.duration",
         aggregation=ExplicitBucketHistogramAggregation([0.01, 0.05, 0.1, 0.25, 0.5, 1, 2.5, 5])),
    View(instrument_name="http.server.request.duration", attribute_keys={"http.request.method", "http.route", "http.response.status_code"}),
    View(instrument_name="db.client.connection.*", aggregation=DropAggregation()),   # supprimer des métriques inutiles
])

Cardinalité #

Chaque combinaison distincte d'attributs crée une série. 5 méthodes × 50 routes × 10 codes = 2 500 séries par instance. Un attribut user.id multiplie ce nombre par le nombre d'utilisateurs : le backend sature et la facture explose.

Bonne Pratique : Sur les métriques, n'utilisez que des attributs bornés (route, méthode, code, région). Les identifiants vont sur les spans et les logs.

4. Exemplars et Prometheus #

Relier une métrique à une trace.

Exemplars #

Un exemplar est un point de mesure particulier conservé avec son trace_id : sur un pic de latence p99, on clique sur l'exemplar et on ouvre la trace exacte d'une requête lente. Le filtre OTEL_METRICS_EXEMPLAR_FILTER=trace_based (défaut) n'enregistre que les mesures faites dans un span échantillonné.

Vers Prometheus #

OpenTelemetryPrometheus
shop.orders (Counter, unit {order})shop_orders_total
http.server.request.duration (Histogram, unit s)http_server_request_duration_seconds_bucket, _sum, _count
attribut http.routelabel http_route
ressource service.namelabels job / instance et métrique target_info
# Prometheus 3 accepte l'OTLP nativement
prometheus --web.enable-otlp-receiver      # point d'entrée : /api/v1/otlp/v1/metrics
# ou dans le Collector : exportateur prometheusremotewrite, ou prometheus (scrape)

📄 Les métriques OpenTelemetry : instruments, temporalité, histogrammes et exemplars →

Mon suivi

  • ⏱ Durée estimée : ≈ 6 min

Connectez-vous pour suivre votre progression et prendre des notes. Se connecter

✉️ Poser une question

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...