RousselTMLEARNING

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

OpenTelemetry sur Kubernetes

1. Modes de déploiement du Collector #

Agent, gateway, sidecar.

Choisir #

Architecture OpenTelemetry sur Kubernetes
L'agent par nœud collecte et enrichit ; la gateway échantillonne, route et exporte.
ModeUsage typique
DaemonSet (agent)un Collector par nœud : réception OTLP locale, logs des pods, métriques kubelet et hôte, ajout des métadonnées Kubernetes
Deployment (gateway)point central : tail sampling, routage, authentification, export vers les backends
StatefulSetscraping Prometheus réparti avec le Target Allocator
Sidecarun Collector dans chaque pod : isolation forte, mais coûteux

2. L'OpenTelemetry Operator #

Gérer collecteurs et instrumentation par CRD.

Installer #

kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.16.2/cert-manager.yaml
kubectl apply -f https://github.com/open-telemetry/opentelemetry-operator/releases/latest/download/opentelemetry-operator.yaml
# ou : helm install opentelemetry-operator open-telemetry/opentelemetry-operator -n opentelemetry-operator-system --create-namespace

Un Collector #

apiVersion: opentelemetry.io/v1beta1
kind: OpenTelemetryCollector
metadata: { name: agent, namespace: observability }
spec:
  mode: daemonset
  config:
    receivers:
      otlp: { protocols: { grpc: { endpoint: 0.0.0.0:4317 }, http: { endpoint: 0.0.0.0:4318 } } }
    processors:
      memory_limiter: { check_interval: 1s, limit_percentage: 80, spike_limit_percentage: 25 }
      k8sattributes: {}
      batch: {}
    exporters:
      otlp: { endpoint: gateway-collector.observability:4317, tls: { insecure: true } }
    service:
      pipelines:
        traces: { receivers: [otlp], processors: [memory_limiter, k8sattributes, batch], exporters: [otlp] }

Auto-instrumentation #

apiVersion: opentelemetry.io/v1alpha1
kind: Instrumentation
metadata: { name: defaut, namespace: shop }
spec:
  exporter: { endpoint: http://agent-collector.observability:4318 }
  propagators: [tracecontext, baggage]
  sampler: { type: parentbased_traceidratio, argument: "0.25" }
  resource: { addK8sUIDAttributes: true }
# puis, dans le template du pod :
metadata:
  annotations:
    instrumentation.opentelemetry.io/inject-java: "true"     # ou -python, -nodejs, -dotnet, -go

Au démarrage du pod, l'Operator ajoute un init container qui copie l'agent du langage, et positionne les variables OTEL_* (nom du service déduit du déploiement, attributs Kubernetes). Aucune modification de l'image n'est nécessaire.

Erreur Courante : L'injection n'a lieu qu'à la création du pod : après avoir ajouté l'annotation ou modifié la ressource Instrumentation, redémarrez les déploiements (kubectl rollout restart).

3. Métadonnées et métriques Kubernetes #

Enrichir et compléter.

k8sattributes et récepteurs #

ComposantApport
processeur k8sattributesajoute k8s.pod.name, k8s.namespace.name, k8s.deployment.name, k8s.node.name, labels et annotations à toutes les données
receiver kubeletstatsCPU, mémoire, réseau, volumes par pod et conteneur
receiver k8s_clusterétat des objets (déploiements, pods en échec, nœuds)
receiver k8sobjectsévénements Kubernetes sous forme de logs
Target Allocatorrépartit les cibles Prometheus entre plusieurs Collectors
Bonne Pratique : Le processeur k8sattributes a besoin de droits RBAC en lecture sur les pods, namespaces et ReplicaSets : l'Operator et le chart Helm les créent, une installation manuelle doit les ajouter.

Charts Helm #

helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
helm install agent open-telemetry/opentelemetry-collector -n observability --create-namespace \
  --set mode=daemonset --set image.repository=otel/opentelemetry-collector-k8s \
  --set presets.kubernetesAttributes.enabled=true \
  --set presets.logsCollection.enabled=true \
  --set presets.kubeletMetrics.enabled=true

4. Exploiter en production #

Les points de vigilance.

Check-list #

  • memory_limiter en premier processeur et limites de ressources sur chaque Collector.
  • Gateway en plusieurs réplicas avec loadbalancing par TraceID si tail sampling.
  • Télémétrie interne des Collectors supervisée (refus, échecs d'envoi, file d'attente).
  • Versions de l'Operator, du Collector et des agents alignées et mises à jour ensemble.
  • Ressources Instrumentation par namespace pour adapter l'échantillonnage à chaque équipe.

📄 OpenTelemetry sur Kubernetes : Operator, auto-instrumentation et Collector →

Mon suivi

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

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

✉️ Poser une question

Articles recommandés

Bonnes pratiques Grafana Pyroscope : collecte, labels, analyse et coûts

Check-list de production pour le profiling continu avec Pyroscope : choix du mode de collecte, la...

Alertmanager : rôle, architecture et cycle de vie d'une alerte

Ce que fait Alertmanager entre Prometheus et vos équipes : déduplication, regroupement, routage, ...

Écrire de bonnes règles d'alerte Prometheus (et les tester)

Concevoir des alertes utiles : alerter sur les symptômes, choisir for et les seuils, labels de sé...

Routage, regroupement et récepteurs dans Alertmanager

L'arbre de routage d'Alertmanager : matchers, group_by, group_wait, group_interval, repeat_interv...

Silences, inhibitions et intervalles de temps dans Alertmanager

Réduire le bruit des alertes : silences ponctuels avec amtool, règles d'inhibition (une alerte cr...

Haute disponibilité et exploitation d'Alertmanager

Monter un cluster Alertmanager hautement disponible (gossip), configurer Prometheus pour tous les...

Grafana Alerting et gestion des astreintes

Créer des alertes dans Grafana (règles, points de contact, politiques de notification), les provi...

Bonnes pratiques d'alerting : Prometheus, Alertmanager et astreinte

Check-list pour un alerting efficace : règles sur les symptômes, sévérités, routage par équipe, r...

SRE : SLI, SLO et SLA expliqués simplement

Les fondamentaux de l'ingénierie de la fiabilité (SRE) : différence entre SLI, SLO et SLA, choix ...