Trafic réseau

Le trafic est toujours généré par l'Agent et envoyé à Datadog. Aucune session n'est jamais initiée par Datadog et transmise à l'Agent.

Présentation

L’intégralité du trafic de l’Agent est envoyé via SSL. La destination dépend du service et du site Datadog. Pour consulter les destinations disponibles en fonction de votre site, utilisez le sélecteur SITE sur la droite.

Destinations

APM
trace.agent.
Live Containers & Live Process
process.
Network Device Monitoring
ndm-intake.
snmp-traps-intake.
Orchestrator
orchestrator.
Profiling
intake.profile.
Real User Monitoring (RUM)
rum.
session-replay.
Emplacement privé Synthetic
Worker v>=1.5.0 : intake.synthetics. est le seul endpoint à configurer.
Résultats des tests API pour worker v>0.1.6 : intake.synthetics.
Résultats des tests Browser pour worker v>0.2.0 : intake-v2.synthetics.
Résultats des tests API pour worker v<0.1.5 : api.

Database Monitoring
dbm-metrics-intake.
dbquery-intake.

Logs et logs HIPAA
TCP : agent-intake.logs.datadoghq.com
HTTP : agent-http-intake.logs.datadoghq.com
Autre : voir les endpoints pour les logs
Logs HIPAA (obsolète)
tcp-encrypted-intake.logs.datadoghq.com
lambda-tcp-encrypted-intake.logs.datadoghq.com
gcp-encrypted-intake.logs.datadoghq.com
http-encrypted-intake.logs.datadoghq.com

Logs et logs HIPAA
TCP : agent-intake.logs.datadoghq.eu
HTTP : agent-http-intake.logs.datadoghq.eu
Autre : voir les endpoints pour les logs
Logs HIPAA (obsolète)
tcp-encrypted-intake.logs.datadoghq.eu
lambda-tcp-encrypted-intake.logs.datadoghq.eu
gcp-encrypted-intake.logs.datadoghq.eu
http-encrypted-intake.logs.datadoghq.eu

Logs et logs HIPAA
HTTP : agent-http-intake.logs.us3.datadoghq.com
Autre : voir les endpoints pour les logs
Logs HIPAA (obsolète)
lambda-tcp-encrypted-intake.logs.us3.datadoghq.com
gcp-encrypted-intake.logs.us3.datadoghq.com
http-encrypted-intake.logs.us3.datadoghq.com

Logs et logs HIPAA
HTTP : agent-http-intake.logs.us5.datadoghq.com
Autre : voir les endpoints pour les logs
Logs HIPAA (obsolète)
lambda-tcp-encrypted-intake.logs.us5.datadoghq.com
gcp-encrypted-intake.logs.us5.datadoghq.com
http-encrypted-intake.logs.us5.datadoghq.com

Logs et logs HIPAA
HTTP : agent-http-intake.logs.ddog-gov.com
Autre : voir les endpoints pour les logs
Logs HIPAA (obsolète)
lambda-tcp-encrypted-intake.logs.ddog-gov.com
gcp-encrypted-intake.logs.ddog-gov.com
http-encrypted-intake.logs.ddog-gov.com

Toutes les autres données de l’Agent
<VERSION>-app.agent.
Par exemple, l’Agent v7.31.0 envoie ses données à 7-31-0-app.agent.. Vous devez donc ajouter *.agent. dans les listes d’inclusion de vos pare-feu.
À partir de la v6.1.0, l’Agent interroge également l’API Datadog pour certaines fonctionnalités non essentielles (par exemple, pour indiquer la validité d’une clé d’API configurée) :
Agent >= 7.18.0/6.18.0 api.
Agent < 7.18.0/6.18.0 app.

Tous ces domaines sont des entrées CNAME qui pointent vers un ensemble d’adresses IP statiques. Vous pouvez trouver ces adresses sur la page https://ip-ranges..

Les informations sont structurées au format JSON selon le schéma suivant :

{
    "version": 1,                          // <-- valeur incrémentée chaque fois que cette information est modifiée
    "modified": "YYYY-MM-DD-HH-MM-SS",     // <-- timestamp de la dernière modification
    "agents": {                            // <-- adresses IP utilisées par l'Agent pour envoyer des métriques à Datadog
        "prefixes_ipv4": [                 // <-- liste des blocs CIDR IPv4
            "a.b.c.d/x",
            ...
        ],
        "prefixes_ipv6": [                 // <-- liste des blocs CIDR IPv6
            ...
        ]
    },
    "api": {...},                          // <-- même chose, mais pour une fonctionnalité non essentielle de l'Agent (demande d'informations à partir de l'API)
    "apm": {...},                          // <-- même structure que « agents », mais il s'agit des adresses IP utilisées pour les données de l'Agent APM
    "logs": {...},                         // <-- même chose, mais pour les données de l'Agent de log
    "process": {...},                      // <-- même chose, mais pour les données de l'Agent de processus
    "orchestrator": {...},                 // <-- même chose, mais pour les données de l'Orchestrator
    "synthetics": {...},                   // <-- non utilisé pour le trafic de l'Agent (adresses IP sources de Datadog pour les bots utilisés pour les tests Synthetic)
    "synthetics-private-locations": {...}, // <--  non utilisé pour le trafic de l'Agent (adresses IP d'admission des emplacements privés Synthetics)
    "webhooks": {...}                      // <-- non utilisé pour le trafic de l'Agent (adresses IP Datadog transmettant les webhooks)
}

Chaque section possède un endpoint dédié, par exemple :

  • https://ip-ranges./logs.json pour les adresses IP utilisées pour recevoir les données des logs via TCP ;
  • https://ip-ranges./apm.json pour les adresses IP utilisées pour recevoir les données d’APM.

Inclusion

Toutes les ip-ranges doivent être ajoutées à votre liste d’inclusion. Bien qu’elles ne soient pas toutes actives en même temps, les adresses utilisées sont amenées à changer en raison des opérations de gestion et de maintenance réseau effectuées régulièrement.

Ports ouverts

L'intégralité du trafic sortant est protégé par SSL et envoyé via TCP/UDP.

Ouvrez les ports suivants pour profiter de toutes les fonctionnalités de l’Agent :

Trafic sortant

443/tcp
Port utilisé pour la plupart des données de l’Agent (métriques, APM, live processes/containers)
123/udp
Port utilisé pour le NTP (en savoir plus sur l’importance du NTP)
Voir les cibles NTP par défaut
6062/tcp
Port utilisé pour les endpoints de debugging de l’Agent de processus
6162/tcp
Port utilisé pour la configuration des paramètres de runtime de l’Agent de processus
10516/tcp
Port utilisé pour la collecte de logs via TCP
Consultez les endpoints pour les logs pour découvrir d’autres types de connexions.
10255/tcp
Port utilisé pour le kubelet HTTP Kubernetes
10250/tcp
Port utilisé pour le kubelet HTTPS Kubernetes

443/tcp
Port utilisé pour la plupart des données de l’Agent (métriques, APM, live processes/containers)
123/udp
Port utilisé pour le NTP (en savoir plus sur l’importance du NTP)
Voir les cibles NTP par défaut
443/tcp
Port utilisé pour la collecte de logs via TCP
Consultez les endpoints pour les logs pour découvrir d’autres types de connexions.
10255/tcp
Port utilisé pour le kubelet HTTP Kubernetes
10250/tcp
Port utilisé pour le kubelet HTTPS Kubernetes

443/tcp
Port utilisé pour la plupart des données de l’Agent (métriques, APM, live processes/containers)
123/udp
Port utilisé pour le NTP (en savoir plus sur l’importance du NTP)
Voir les cibles NTP par défaut
10255/tcp
Port utilisé pour le kubelet HTTP Kubernetes
10250/tcp
Port utilisé pour le kubelet HTTPS Kubernetes

Trafic entrant

Ports utilisés pour les services de l’Agent qui communiquent entre eux en local au sein du host uniquement

5000/tcp
Port utilisé pour le serveur go_expvar
5001/tcp
Port sur lequel l’API IPC écoute le trafic
5002/tcp
Port utilisé pour accéder à l’interface graphique de l’Agent depuis le navigateur
8125/udp
Port utilisé pour DogStatsD, sauf si dogstatsd_non_local_traffic est défini sur true. Ce port est disponible sur localhost : 127.0.0.1, ::1, fe80::1.
8126/tcp
Port utilisé pour le récepteur APM

Trafic sortant

443/tcp
Port utilisé pour la plupart des données de l’Agent (métriques, APM, live processes/containers)
123/udp
Port utilisé pour le NTP (en savoir plus sur l’importance du NTP).
Voir les cibles NTP par défaut.

Trafic entrant

8125/udp
Port utilisé pour DogStatsD, sauf si dogstatsd_non_local_traffic est défini sur true. Ce port est disponible sur localhost : 127.0.0.1, ::1, fe80::1.
8126/tcp
Port utilisé pour le récepteur de l’APM
17123/tcp
Forwarder de l’Agent, utilisé pour la mise en mémoire tampon du trafic en cas de perte de communication entre l’Agent et Datadog
17124/tcp
Redirecteur pour la prise en charge de Graphite (facultatif)

Utilisation d’un proxy

Pour obtenir des instructions détaillées sur la configuration d’un proxy, consultez la section Configuration de l’Agent pour un proxy.

Mise en mémoire tampon des données

Si votre réseau n’est plus disponible, l’Agent stocke les métriques en mémoire. L’utilisation maximale de la mémoire pour le stockage des métriques est définie par le paramètre forwarder_retry_queue_payloads_max_size. Lorsque cette limite est atteinte, les métriques sont ignorées.

À partir de la v7.27.0, l’Agent stocke les métriques sur disque une fois la limite de mémoire atteinte. Pour activer cette fonctionnalité, définissez le paramètre forwarder_storage_max_size_in_bytes sur une valeur positive correspondant au volume d’espace de stockage maximal, en octets, que l’Agent peut utiliser pour stocker les métriques sur disque.

Les métriques sont stockées dans le dossier défini par le paramètre forwarder_storage_path, qui prend par défaut la valeur /opt/datadog-agent/run/transactions_to_retry pour les systèmes Unix et C:\ProgramData\Datadog\run\transactions_to_retry sous Windows.

Pour veiller à ne pas utiliser tout l’espace de stockage, l’Agent stocke les métriques sur disque uniquement si le total d’espace de stockage utilisé est inférieur à 95 %. La valeur de cette limite est définie par le paramètre forwarder_storage_max_disk_ratio.

Pour aller plus loin