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
Arize en production : Phoenix auto-hébergé, Arize AX, sécurité, coûts et monitoring
Passer en production : Phoenix avec PostgreSQL et authentification, OpenTelemetry Collector devan...
Bonnes pratiques Arize et OpenInference
Check-list pour l'observabilité et l'évaluation des applications LLM : instrumentation OpenInfere...
Architecture de la plateforme Datadog : sites, organisations, clés et modèle de données
Comprendre l'architecture de Datadog : sources de données (agent, intégrations cloud, SDK, OpenTe...
Datadog sur Kubernetes : Operator, Cluster Agent et Autodiscovery
Superviser Kubernetes avec Datadog : Datadog Operator et ressource DatadogAgent, Cluster Agent, A...
Dashboards et notebooks Datadog : widgets, template variables et bonnes pratiques
Concevoir des dashboards Datadog utiles : types de widgets, template variables, groupes, Powerpac...
Métriques Datadog avancées : types, agrégations, cardinalité et Metrics without Limits
Maîtriser les métriques Datadog : types (count, rate, gauge, histogram, distribution), agrégation...
Logs Datadog avancés : index, filtres d'exclusion, Flex Logs, archives et Sensitive Data Scanner
Maîtriser coût et conformité des logs Datadog : pipelines et processeurs, index et rétention, fil...
APM Datadog avancé : échantillonnage, rétention, profiler et Software Catalog
Aller plus loin avec l'APM Datadog : contrôle d'ingestion et échantillonnage, filtres de rétentio...
RUM et Synthetic Monitoring avec Datadog : synthetic transaction monitoring et expérience utilisateur
Mesurer l'expérience utilisateur avec Datadog : RUM navigateur et mobile, Core Web Vitals, Sessio...