Facturation Datadog sur Kubernetes : de la ligne de facture à l'événement du cluster qui explique la dérive

Une facture Datadog peut augmenter alors que le cluster Kubernetes semble stable : mêmes services, même trafic, parfois même nombre moyen de nœuds. Elle s'explique en général par un rapprochement entre objets qui ne partagent ni unité, ni cadence, ni règle d'agrégation. Hosts, heures de conteneurs, gigaoctets ingérés, événements indexés, spans et métriques custom sont des compteurs distincts, et chacun réagit à un changement différent du cluster.

La méthode qui suit fait passer d'une hausse globale à une explication vérifiable : quelle ligne, quelle unité, quelle règle de calcul, quel premier intervalle de divergence (T0) et quel événement du cluster. Elle est présentée sans donnée client, avec une grille de réconciliation et des exemples chiffrés fictifs. Elle ne donne aucun prix : ceux qui s'appliquent figurent au bon de commande. Cette lecture est établie sur la documentation publique de facturation et de produit Datadog et sur la documentation de référence Kubernetes ; les pages officielles citées ont été vérifiées le 28 septembre 2026.

Identifier l'unité facturée avant de chercher la dérive

La première erreur consiste à traiter « host Datadog » comme une unité unique, puis à comparer la facture à un nombre de pods. Datadog facture par produit, chacun avec son unité, sa cadence de mesure et sa règle d'agrégation. À la date du 28 septembre 2026, la documentation indique que le cycle de facturation commence le premier du mois en UTC et que, sauf mention contraire dans le bon de commande, les frais portent sur l'usage de chaque mois calendaire. Toute comparaison se fait donc en UTC, par mois calendaire, bon de commande en main.

Un host d'infrastructure est une instance de système d'exploitation, physique ou virtuelle, surveillée par Datadog ; dans Kubernetes, c'est le nœud. Deux cas surprennent : les VM EC2, Google Cloud, Azure ou vSphere surveillées par une intégration cloud comptent aussi, même sans Agent ; et un Agent installé dans chaque conteneur fait compter chaque conteneur comme un host. Un APM host est un host sur lequel une application génère et envoie des traces. Pour Kubernetes, la documentation précise qu'APM et Continuous Profiler sont facturés par nœud et non par pod : répartir les mêmes pods tracés sur davantage de nœuds augmente les APM hosts, alors qu'ajouter des pods sur les mêmes nœuds augmente plutôt conteneurs, spans, journaux et séries.

Les allocations incluses (conteneurs et métriques par host, spans par host APM) figurent dans la documentation avec des valeurs par défaut ; la valeur applicable reste celle du contrat.

Le high-water mark : pourquoi quelques heures suffisent

Sur un plan HWMP (High Water Mark Plan), Datadog relève chaque heure le nombre de hosts, écarte en fin de mois le 1 % d'heures les plus hautes et facture le maximum des 99 % restants. Sur un mois de 720 heures, ce 1 % représente un peu plus de sept heures ; la règle d'arrondi n'est pas détaillée pour les hosts d'infrastructure. Pour les APM hosts, le tableau de la page de facturation APM précise que la neuvième mesure horaire la plus haute est facturée (la huitième en février) ; la même page et la page Pricing parlent aussi du 99e centile. Les deux lectures écartent environ huit heures ; la règle applicable se confirme sur le bon de commande. Un pic qui dure au total plus longtemps que ces quelques heures, même réparti sur plusieurs nuits, fixe le compte du mois entier.

Exemple fictif. Un cluster tourne sur 12 nœuds. À partir du 14, un pool dédié à un traitement par lots ajoute 10 nœuds chaque nuit, présents dans trois tranches horaires. Sur 17 nuits : 51 heures à 22 hosts, bien plus que les sept ou huit heures écartées. Le high-water mark passe de 12 à 22 hosts, alors que la moyenne horaire n'a augmenté que d'environ 0,7 host (51 × 10 / 720). Sur un plan hybride mensuel/horaire, la même activité se lirait en 510 heures de host au-delà d'un engagement couvrant les 12 nœuds permanents. Même événement, deux lectures : le plan se relève avant toute analyse.

Où lire l'usage du compte

• Usage Details : la vue All inclut de l'usage non facturable, comme les essais de produit ; la vue Billable, disponible sur la plupart des comptes, ne montre que l'usage qui contribue à la facture et le répartit entre engagements, allocations et usage à la demande. Les exports CSV donnent un détail horaire par produit et par organisation.
• Cost Summary : estimé du mois en cours, projection et historique. Une projection peut différer du coût finalisé ; l'historique arrive après la clôture, environ 16 jours après la fin du mois (permissions billing_read et usage_read).
• Datadog Costs, dans Cloud Cost Management : coûts quotidiens sans surcoût, 48 heures de délai, 15 mois d'historique, ventilés notamment par dimension_name, organization et pricing_category (engagé ou à la demande).

Relever la base de facturation avant l'analyse

Ce bloc se remplit sans interprétation. Chaque valeur cite un écran, un export ou un document daté ; « inconnu » vaut mieux qu'une règle supposée.

base_facturation:
  periode_utc: <debut>/<fin>                 # mois calendaire
  organisations: [<parent>, <enfants>]
  ligne_facture: <libellé exact>
  sku_et_plan: <SKU du bon de commande>, <HWMP | hybride | libellé contractuel>
  unite: <host | heure_conteneur | Go | million_evenements | million_spans | serie | nom_metrique | point>
  modele_metriques_custom: <Timeseries | Metric Name | sans objet>
  allocation_engagement_a_la_demande: <termes exacts ou inconnu>
  runtime_kubernetes: <standard | eks_fargate | gke_autopilot | autre>
  versions_agent: [<version par cluster>]
  preuves: [<export_csv>, <vue_billable>, <bon_de_commande>, <facture>]
  revue: <responsable et date>

Réconcilier nœuds et charges éphémères

Un instantané de kubectl get nodes ne reconstruit pas un mois. Datadog compte les hosts uniques de chaque heure : par construction, dans l'heure où un nœud est remplacé, l'ancien et le nouveau peuvent être comptés tous les deux. Un graphique lissé à huit workers peut masquer neuf identités successives. La collecte conserve donc l'UID, l'identifiant attribué par le fournisseur cloud (spec.providerID) et la date de création de chaque nœud, alignés sur les heures UTC.

# Inventaire des nœuds présents (lecture seule)
kubectl get nodes -o custom-columns='NOM:.metadata.name,UID:.metadata.uid,PROVIDER_ID:.spec.providerID,CREATION:.metadata.creationTimestamp'

# Pods du DaemonSet de l'Agent et leur nœud
kubectl -n <namespace-datadog> get pods -o wide

# Identité déclarée à Datadog et état des collecteurs
kubectl -n <namespace-datadog> exec <pod-agent> -c <conteneur-agent> -- agent hostname
kubectl -n <namespace-datadog> exec <pod-agent> -c <conteneur-agent> -- agent status

agent hostname affiche le nom d'hôte utilisé par l'Agent : c'est le lien entre nœud Kubernetes et host Datadog. En conteneur, l'Agent doit pouvoir accéder à l'API du kubelet, au point de métadonnées du fournisseur cloud et à l'API du runtime ; une erreur de nom d'hôte signale généralement qu'au moins l'un d'eux est inaccessible ; l'accès aux métadonnées cloud permet de rapprocher données de l'Agent et de l'intégration cloud. agent status ne vaut que pour l'instant de la capture : un Agent sain aujourd'hui ne prouve rien sur T0.

Identités en double et hosts hors cluster

Sur AWS, la documentation décrit des hosts en double lorsque l'Agent conteneurisé ne peut pas interroger le point de métadonnées EC2 : le nom qu'il résout diffère de l'identifiant d'instance collecté par l'intégration AWS. Correctif documenté lorsque les hosts imposent IMDSv2 : Agent 7.64.0 ou plus récent, ou DD_EC2_PREFER_IMDSV2=true avant cette version, et limite de sauts IMDS portée de 1 à 2. L'effet de ces doublons sur l'usage facturable n'est pas décrit : c'est une hypothèse à instruire avec Datadog. De même, une VM de bastion ou un pool d'intégration continue surveillés par l'intégration cloud entrent dans Infrastructure Hosts ; une grille bâtie sur kubectl seul les laissera en résiduel.

L'état courant de l'API ne raconte pas le mois : les Events Kubernetes ont une durée de conservation limitée, les Jobs terminés peuvent être supprimés par TTL (.spec.ttlSecondsAfterFinished), les nœuds retirés disparaissent. Les preuves du passé viennent de l'historique des instances chez le fournisseur, des journaux de l'autoscaler, de l'historique Git et des exports horaires Datadog.

Conteneurs : cinq minutes, une allocation par heure

Datadog relève les conteneurs par tranches de cinq minutes ; les douze relevés d'une heure sont moyennés, l'allocation du compte est déduite heure par heure, et l'usage à la demande du mois est la somme des dépassements horaires. L'allocation est le total des conteneurs inclus (par défaut 5 par host en offre Pro, 10 en Enterprise) et d'un éventuel engagement contractuel. La documentation chiffre elle-même l'effet d'un pic : 1 200 conteneurs à la demande pendant une tranche de cinq minutes valent 100 heures de conteneur. Quatre règles documentées évitent les faux diagnostics :

1. Une répartition inégale entre hosts ne crée pas de dépassement tant que le total reste dans l'allocation.
2. L'allocation suit le nombre de hosts : quand l'autoscaler ajoute des nœuds, elle augmente pendant ces mêmes heures.
3. Les conteneurs de l'Agent ne sont pas décomptés ; les pause containers sont exclus, avec les prérequis de version cités par la page (Agent 5.8 ou plus, 7.20 ou plus pour EKS). Sans inventaire des versions, l'exclusion reste une hypothèse.
4. Un conteneur en CrashLoopBackOff qui tourne plus de dix secondes compte dans la tranche, et chaque redémarrage porte un nouveau container_id.

Un pod étant un groupe d'un ou plusieurs conteneurs, les sidecars comptent : on compare les conteneurs démarrés et leur durée, pas les pods prêts.

Exemple fictif. Pendant une heure de traitement nocturne, 60 pods à deux conteneurs s'ajoutent aux 90 conteneurs permanents : 210 en moyenne sur l'heure. Avec 22 hosts en offre Enterprise, l'allocation de l'heure est de 220 : aucune heure à la demande. Placés sur les 12 nœuds permanents, les mêmes pods feraient tomber l'allocation à 120 et produiraient 90 heures de conteneur à la demande. Retirer des nœuds fait baisser une ligne et peut en faire monter une autre.

Certains runtimes sortent du modèle du nœud : ECS Fargate est facturé aux tâches surveillées simultanément, EKS Fargate aux pods surveillés simultanément, GKE Autopilot relève de la catégorie Serverless, et APM sur Fargate au nombre moyen de tâches qui envoient des traces par heure. Ces branches se réconcilient dans leur unité, sans workers fictifs.

Séparer ingestion et indexation des journaux et des traces

Journaux et traces ont chacun deux frontières facturables : ce qui entre et ce qui reste interrogeable. Une action sur l'une ne se lit pas sur l'autre.

Journaux

Datadog facture l'ingestion au volume total soumis au service Logs, en gigaoctets, et l'indexation par million d'événements, au tarif de la rétention choisie. La page de tarifs mentionne aussi Flex Logs, dont l'unité est le million d'événements stockés : une ligne de plus à réconcilier si le compte l'utilise.

Un journal entre dans le premier index dont le filtre lui correspond. Les journaux exclus sont retirés des index, mais passent toujours par le Live Tail et peuvent alimenter des métriques et être archivés ; il en va de même une fois le quota journalier d'un index atteint. Un filtre d'exclusion ou un quota agit donc sur l'indexation, pas sur l'ingestion. Réduire l'ingestion demande d'agir en amont : collecte, verbosité, regroupement multiline, doublons (les mêmes journaux collectés par l'Agent et par un expéditeur en sidecar, par exemple).

Pour dater, datadog.estimated_usage.logs.ingested_bytes suit le volume ingéré, et datadog.estimated_usage.logs.ingested_events compte tous les événements ingérés, exclus compris ; filtrée sur datadog_is_excluded:false, elle ne compte que les indexés, comme le recommande le guide de bonnes pratiques de Datadog. Une hausse des octets ingérés sans hausse des événements indexés désigne une source nouvelle ou plus bavarde, déjà filtrée à l'indexation.

Les métriques générées à partir des journaux sont facturées comme métriques custom, et la documentation déconseille de les regrouper par attributs non bornés (identifiants d'utilisateur, de requête, de session). Remplacer l'indexation d'un flux par une telle métrique déplace l'usage vers une autre ligne, à prévoir dans la grille. La verbosité touche aussi l'alerting.

Traces

APM produit trois lignes à ne pas fusionner : APM hosts, spans ingérés (gigaoctets), spans indexés (millions). Le sampling se décide dans la bibliothèque de tracing et dans l'Agent. Une règle définie dans la bibliothèque (DD_TRACE_SAMPLING_RULES ; DD_TRACE_SAMPLE_RATE est déprécié pour plusieurs langages) l'emporte sur l'Agent ; sinon, l'Agent calcule des taux pour atteindre une cible de 10 traces par seconde (DD_APM_TARGET_TPS), répartie entre services selon le trafic, et l'échantillonneur d'erreurs capte jusqu'à 10 traces par seconde par Agent (DD_APM_ERROR_TPS).

Sur Kubernetes, l'Agent tourne en DaemonSet, un par nœud, et ces cibles sont fixées par Agent. On en déduit que répartir les pods tracés sur davantage de nœuds peut augmenter le volume ingéré à trafic constant, lorsque les services s'en remettent aux taux de l'Agent. C'est une hypothèse, que la page Ingestion Control et datadog.estimated_usage.apm.ingested_bytes confirment ou écartent. Un trafic stable produit aussi plus d'octets si les spans s'alourdissent.

Après l'ingestion, les filtres de rétention décident des spans conservés 15 jours : les spans indexés. La documentation est explicite : ces filtres n'affectent pas ce que l'Agent collecte et envoie, et les spans retenus par le filtre de rétention intelligente ne comptent pas dans l'usage des spans indexés. Un changement de sampling agit sur l'ingestion, un changement de filtre de rétention sur l'indexation ; les deux se datent séparément.

Lire les métriques par leur cardinalité réelle

Avant toute analyse de cardinalité, il faut savoir quel modèle s'applique : la documentation décrit un modèle par cardinalité (SKU Timeseries) et un modèle par nom de métrique (SKU Metric Name), aux SKU mutuellement incompatibles. Le bon de commande dit lequel.

Modèle Timeseries : combinaisons réellement soumises

Une métrique custom y est identifiée par un nom et une combinaison de valeurs de tags, tag host compris. Seules les combinaisons effectivement soumises existent : on ne multiplie pas les cardinalités théoriques des tags, et un tag entièrement déterminé par un autre (une région par une zone) n'ajoute rien. L'usage mensuel est la somme des séries distinctes de chaque heure, divisée par le nombre d'heures du mois. La fréquence d'envoi et le nombre de requêtes n'y changent rien.

Exemple fictif, sur le modèle de celui de la documentation. checkout.duration reçoit quatre combinaisons ; deux hosts, deux routes et deux statuts en autoriseraient huit en théorie.

Le type applique ensuite son multiplicateur : une série par combinaison pour COUNT, RATE et GAUGE ; cinq par défaut pour un HISTOGRAM ; cinq pour une DISTRIBUTION, plus cinq si les percentiles sont activés. Ici : 4 séries en GAUGE, 20 en HISTOGRAM, 20 ou 40 en DISTRIBUTION.

Ce que Kubernetes change

Le tag host désigne le nœud : chaque rotation termine des séries et en ouvre d'autres, comme un tag de niveau pod (pod_name, container_id) à chaque rollout. Comme l'usage est une moyenne de comptages horaires, le poids d'une série dépend de sa durée de vie.

Exemple fictif. Le traitement nocturne émet une GAUGE batch.lignes_traitees étiquetée par pod_name : 60 pods, trois heures par nuit, 17 nuits, soit 3 060 heures-séries, environ 4 séries sur la moyenne du mois (3 060 / 720). À l'inverse, ajouter pod_name à une métrique permanente d'un Deployment de 40 pods, jusque-là étiquetée par host sur 12 nœuds, la fait passer de 12 à 40 séries chaque heure : environ 28 de plus sur la moyenne, avant multiplicateur. En modèle Timeseries, la cardinalité persistante pèse bien plus que les pics : l'inverse d'Infrastructure Hosts en HWMP.

Les allocations sont, elles aussi, liées aux hosts : la documentation cite par défaut 100 métriques ingérées et 100 indexées par host en offre Pro, 200 et 200 en Enterprise, mises en commun sur l'infrastructure. Moins de hosts, c'est moins d'allocation à usage constant.

Metrics without Limits : une ligne ingérée qui apparaît

Metrics without Limits dissocie ingestion et indexation : une configuration de tags, définie depuis Metrics Summary, détermine ce qui reste interrogeable. En modèle par cardinalité, seules les métriques configurées contribuent au volume ingéré, calculé sur tous les tags envoyés ; une métrique non configurée n'est facturée qu'à l'indexation. Une hausse de la ligne « ingérées » qui suit une campagne de configuration n'est donc pas une anomalie de collecte.

L'effet d'une configuration apparaît dans Top Custom Metrics 24 heures après son enregistrement ; Datadog recommande de le valider d'abord avec l'API d'estimation de cardinalité. Toute réduction se valide aussi avec les utilisateurs des tableaux de bord et des alertes : retirer une dimension utile au diagnostic est un compromis d'exploitation à rendre visible.

Modèle Metric Name : noms et points

Trois SKU s'y appliquent : un nom est facturé s'il a soumis plus de 100 points indexés dans le mois ; chaque nom facturé inclut 10 millions de points indexés, le surplus allant dans un dépassement mensuel commun ; les points ingérés sont facturés au-delà de cinq fois le volume indexé. Chaque nom est compté une fois par mois, et par défaut chaque point ingéré est aussi indexé. Metrics without Limits peut y réduire l'indexé, mais chaque point envoyé compte à l'ingestion. Le volume de points dépend alors de la fréquence d'envoi et du nombre de séries : le raisonnement par combinaisons ne s'applique pas.

Construire la grille de réconciliation à partir de T0

Dater avec Estimated Usage, conclure avec la vue Billable

Les compteurs de la grille ont chacun leur série d'usage estimé, proche du temps réel (colonne « Série de datation » ci-dessous) ; sur un compte multi-organisations, le champ from agrège les organisations enfants. Datadog qualifie ces métriques d'estimations qui ne correspondent pas toujours à l'usage facturable et indique un écart moyen de 10 à 20 % : elles datent et segmentent, elles ne chiffrent pas. L'autorité reste le SKU actif, la vue Billable ou l'export d'usage, les termes du compte et la facture.

Segmenter par équipe, environnement ou cluster se prépare : Usage Attribution accepte jusqu'à trois clés de tags, les rapports antérieurs gardent leurs anciens tags, et les variantes by_tag des métriques estimées prennent les tags configurés au prochain 00:00 UTC. Une attribution décidée à réception de la facture ne réécrit pas le mois écoulé.

Le chemin de réconciliation

Trois règles tiennent ce chemin. Aucune conversion entre hosts, heures de conteneur, octets, événements, spans ou séries, et encore moins en montant. T0 se cherche série par série, selon une règle de changement fixée à l'avance, jamais à la date de réception de la facture. Le résiduel reste dans son unité native : ni réparti au prorata, ni déclaré résolu.

La grille complète

Toutes les séries sont préfixées par datadog.estimated_usage.. Chaque hypothèse ouverte reçoit les mêmes champs : ligne et unité, segment et période UTC, T0, événement avec lien vers le diff ou l'opération, mécanisme, preuve, conclusion, résiduel, responsable et date de revue.

Exemple fictif complet

Compte fictif : plan HWMP, offre Enterprise avec allocations par défaut, un cluster sur des nœuds EC2, mois de trente jours. La facture du mois M est comparée à celle de M-1, en unités.

Deux T0 apparaissent. Le plus ancien, le 9, concerne les journaux et n'a rien à voir avec les hosts, qui divergent le 14 : le premier point de divergence n'est pas forcément la cause principale. Pour les hosts, l'historique Git date la création du pool, l'autoscaler et l'historique EC2 montrent les lancements nocturnes, et le high-water mark s'applique (51 heures à 22 hosts ou plus ; 23 à partir du 20 avec l'identité résiduelle). Le placement des pods tracés explique APM Hosts ; les conteneurs ne bougent pas, les nœuds ajoutés apportant leur allocation. Reste un host, une identité apparue le 20 hors de tout nœud connu : VM surveillée par l'intégration AWS ou identité en double. Tant que rien n'est prouvé, elle reste en résiduel.

Les options se comparent ensuite dans leurs unités, sans chiffrage d'économie. Désactiver l'instrumentation du CronJob ramène APM Hosts à 12, pas Infrastructure Hosts. Placer le traitement sur les nœuds permanents ramène les hosts à 12, mais produit 90 heures de conteneur à la demande par heure de traitement, 4 590 sur le mois, avec un risque de contention. Passer sous le seuil du 1 % n'est réaliste que pour un événement ponctuel : trois heures par nuit le dépassent dès la troisième nuit. Le choix est un arbitrage d'exploitation, pas une ligne de facture.

Clore ou transmettre

L'analyse est close lorsque chaque ligne a une base contractuelle, une fenêtre, une preuve et un résiduel nul ou explicitement accepté. Sinon, le dossier part au Customer Success Manager, que la documentation désigne pour les questions de facturation : compte, produit et unité, période UTC, exports, identités techniques, changements datés et résiduel, sans mélanger les compteurs. Si la réponse modifie une règle, la base est versionnée et la réconciliation rejouée.

Sources officielles et limites de lecture

Cette lecture n'établit ni le montant dû, qui relève de la facture et du bon de commande, ni qu'un écart soit une erreur de facturation : elle produit des hypothèses et des preuves. Les allocations, seuils et libellés cités sont des valeurs par défaut que le contrat peut modifier. Deux conséquences sont des déductions des règles documentées, à confirmer sur le compte : le chevauchement horaire lors d'un remplacement de nœud et l'effet du nombre d'Agents sur les spans ingérés.

La même discipline s'applique aux factures cloud : « Coût facturé, coût amorti, crédits : réconcilier des montants AWS qui ne tombent jamais juste » la détaille pour l'export CUR 2.0 et Cost Explorer, et « FinOps, c'est quoi ? Définition 2026, méthode et par où commencer » la replace dans une démarche d'ensemble. Pour appliquer cette grille à un compte Datadog et à ses clusters, voir la page Audit FinOps : expliquer la facture.

Sources

1. Billing, Datadog, https://docs.datadoghq.com/account_management/billing/, consulté le 28/09/2026.
2. Pricing (documentation de facturation), Datadog, https://docs.datadoghq.com/account_management/billing/pricing/, consulté le 28/09/2026.
3. APM Billing, Datadog, https://docs.datadoghq.com/account_management/billing/apm_tracing_profiler/, consulté le 28/09/2026.
4. Containers Billing, Datadog, https://docs.datadoghq.com/account_management/billing/containers/, consulté le 28/09/2026.
5. Custom Metrics Billing, Datadog, https://docs.datadoghq.com/account_management/billing/custom_metrics/, consulté le 28/09/2026.
6. Metric Name Pricing for Custom Metrics, Datadog, https://docs.datadoghq.com/account_management/billing/metric_name_pricing/, consulté le 28/09/2026.
7. Metrics without Limits, Datadog, https://docs.datadoghq.com/metrics/metrics-without-limits/, consulté le 28/09/2026.
8. Estimated Usage Metrics, Datadog, https://docs.datadoghq.com/account_management/billing/usage_metrics/, consulté le 28/09/2026.
9. Usage Details, Datadog, https://docs.datadoghq.com/account_management/plan_and_usage/usage_details/, consulté le 28/09/2026.
10. Usage Attribution, Datadog, https://docs.datadoghq.com/account_management/billing/usage_attribution/, consulté le 28/09/2026.
11. Cost Details (Cost Summary et Cost Chargebacks), Datadog, https://docs.datadoghq.com/account_management/plan_and_usage/cost_details/, consulté le 28/09/2026.
12. Datadog Costs (Cloud Cost Management), Datadog, https://docs.datadoghq.com/cloud_cost_management/datadog_costs/, consulté le 28/09/2026.
13. Log Indexes, Datadog, https://docs.datadoghq.com/logs/log_configuration/indexes/, consulté le 28/09/2026.
14. Best Practices for Log Management, Datadog, https://docs.datadoghq.com/logs/guide/best-practices-for-log-management/, consulté le 28/09/2026.
15. Generate Metrics from Ingested Logs, Datadog, https://docs.datadoghq.com/logs/log_configuration/logs_to_metrics/, consulté le 28/09/2026.
16. Ingestion Controls, Datadog, https://docs.datadoghq.com/tracing/trace_pipeline/ingestion_controls/, consulté le 28/09/2026.
17. Ingestion Mechanisms, Datadog, https://docs.datadoghq.com/tracing/trace_pipeline/ingestion_mechanisms/, consulté le 28/09/2026.
18. Trace Retention, Datadog, https://docs.datadoghq.com/tracing/trace_pipeline/trace_retention/, consulté le 28/09/2026.
19. Agent Commands, Datadog, https://docs.datadoghq.com/agent/configuration/agent-commands/, consulté le 28/09/2026.
20. Hostname Detection in Containers, Datadog, https://docs.datadoghq.com/agent/troubleshooting/hostname_containers/, consulté le 28/09/2026.
21. Duplicate hosts with Kubernetes on AWS (EC2 or EKS), Datadog, https://docs.datadoghq.com/containers/troubleshooting/duplicate_hosts/, consulté le 28/09/2026.
22. Pricing list (page de tarifs publique, unités uniquement), Datadog, https://www.datadoghq.com/pricing/list/, consulté le 28/09/2026.
23. Node (API Kubernetes), Kubernetes, https://kubernetes.io/docs/reference/kubernetes-api/core/node-v1/, consulté le 28/09/2026.
24. Event (API Kubernetes), Kubernetes, https://kubernetes.io/docs/reference/kubernetes-api/core/event-v1/, consulté le 28/09/2026.
25. Automatic Cleanup for Finished Jobs, Kubernetes, https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/, consulté le 28/09/2026.
26. Pods, Kubernetes, https://kubernetes.io/docs/concepts/workloads/pods/, consulté le 28/09/2026.