1. Modes de déploiement du Collector #
Agent, gateway, sidecar.
Choisir #
| Mode | Usage 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 |
| StatefulSet | scraping Prometheus réparti avec le Target Allocator |
| Sidecar | un 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-namespaceUn 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, -goAu 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 #
| Composant | Apport |
|---|---|
processeur k8sattributes | ajoute k8s.pod.name, k8s.namespace.name, k8s.deployment.name, k8s.node.name, labels et annotations à toutes les données |
receiver kubeletstats | CPU, 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 Allocator | ré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=true4. Exploiter en production #
Les points de vigilance.
Check-list #
memory_limiteren premier processeur et limites de ressources sur chaque Collector.- Gateway en plusieurs réplicas avec
loadbalancingpar 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.
Mon suivi
Connectez-vous pour suivre votre progression et prendre des notes. Se connecter
Articles recommandés
Les concepts fondamentaux d'OpenTelemetry : signaux, ressources, contexte et maturité
Le vocabulaire indispensable d'OpenTelemetry : les quatre signaux, API et SDK, ressource et instr...
Collector OpenTelemetry : connecteurs, extensions et observabilité du Collector
Aller plus loin avec le Collector : connecteurs (spanmetrics, servicegraph, count, routing, failo...
Les conventions sémantiques OpenTelemetry (semconv) : nommer la télémétrie
Comprendre et appliquer les conventions sémantiques OpenTelemetry : attributs de ressource, HTTP,...
Les traces OpenTelemetry en profondeur : spans, statuts, événements, liens et échantillonnage
Maîtriser le signal trace : anatomie d'une trace distribuée, span et SpanKind, attributs, statut ...
Les métriques OpenTelemetry : instruments, temporalité, histogrammes et exemplars
Maîtriser le signal métrique : MeterProvider, instruments synchrones et asynchrones (Counter, UpD...
Les logs avec OpenTelemetry : modèle de données, appenders, corrélation et collecte
Maîtriser le signal log : modèle de données LogRecord, Logs Bridge API et appenders (Logback, Log...
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...
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...