- Si vous ne l’avez pas déjà fait, installez le chart Helm.
La configuration par défaut crée un répertoire sur le host et le monte dans l’Agent. L’Agent crée ensuite un fichier de socket /var/run/datadog/apm.socket
et effectue une écoute sur ce fichier. Les pods d’application peuvent alors être montés de la même façon sur ce volume et rédiger des données sur ce socket. Vous pouvez modifier le chemin et le socket avec les paramètres datadog.apm.hostSocketPath
et datadog.apm.socketPath
.
Cette fonctionnalité peut être désactivée à l’aide de l’option datadog.apm.socketEnabled
.
Il est possible de configurer l’Agent Datadog afin qu’il reçoive les traces via TCP. Pour activer cette fonctionnalité, procédez comme suit :
- Mettez à jour votre fichier
values.yaml
avec la configuration APM suivante :datadog:
## Enable apm agent and provide custom configs
apm:
# datadog.apm.portEnabled -- Enable APM over TCP communication (port 8126 by default)
## ref: https://docs.datadoghq.com/agent/kubernetes/apm/
portEnabled: true
Ensuite, mettez à jour votre chart Helm Datadog à l’aide de la commande suivante : helm upgrade -f values.yaml <NOM_VERSION> datadog/datadog
. Si vous n’avez pas défini votre système d’exploitation dans values.yaml
, ajoutez --set targetSystem=linux
ou --set targetSystem=windows
à cette commande.
Attention : le paramètre datadog.apm.portEnabled
ouvre un port sur votre host. Assurez-vous que votre pare-feu accorde uniquement un accès à vos applications ou à d’autres sources de confiance. Si votre plug-in réseau ne prend pas en charge hostPorts
, ajoutez hostNetwork: true
aux spécifications de pod de votre Agent afin de partager l’espace de nommage réseau de votre host avec l’Agent Datadog. Cela signifie également que tous les ports ouverts sur le conteneur sont également ouverts sur le host. Si un port est utilisé sur le host et dans votre conteneur, ces derniers peuvent entrer en conflit (puisqu’ils partagent le même espace de nommage réseau), empêchant ainsi le pod de démarrer. Cela n’est pas possible avec certaines installations Kubernetes.
Pour activer la collecte de traces APM, ouvrez le fichier de configuration DaemonSet et modifiez les éléments suivants :
Autorisez la réception de données sur le port 8126
(transmission du trafic du host à l’Agent) dans le conteneur trace-agent
:
# (...)
containers:
- name: trace-agent
# (...)
ports:
- containerPort: 8126
hostPort: 8126
name: traceport
protocol: TCP
# (...)
Si vous utilisez une ancienne version de l’Agent (7.17 ou antérieure), en plus des étapes ci-dessus, vous devez définir les variables DD_APM_NON_LOCAL_TRAFFIC
et DD_APM_ENABLED
sur true
dans la section env
du manifeste de l’Agent de trace datadog.yaml
:
# (...)
containers:
- name: trace-agent
# (...)
env:
- name: DD_APM_ENABLED
value: 'true'
- name: DD_APM_NON_LOCAL_TRAFFIC
value: "true"
# (...)
Attention : le paramètre hostPort
ouvre un port sur votre host. Assurez-vous que votre pare-feu accorde uniquement un accès à vos applications ou à d’autres sources de confiance. Si votre plug-in réseau ne prend pas en charge hostPorts
, ajoutez hostNetwork: true
aux spécifications de pod de votre Agent afin de partager l’espace de nommage réseau de votre host avec l’Agent Datadog. Cela signifie également que tous les ports ouverts sur le conteneur sont également ouverts sur le host. Si un port est utilisé sur le host et dans votre conteneur, ces derniers peuvent entrer en conflit (puisqu’ils partagent le même espace de nommage réseau), empêchant ainsi le pod de démarrer. Cela n’est pas possible avec certaines installations Kubernetes.
Pour activer la collecte de traces APM, ouvrez le fichier de configuration DaemonSet et modifiez les éléments suivants :
# (...)
containers:
- name: trace-agent
# (...)
env:
- name: DD_APM_ENABLED
value: "true"
- name: DD_APM_RECEIVER_SOCKET
value: "/var/run/datadog/apm.socket"
# (...)
volumeMounts:
- name: apmsocket
mountPath: /var/run/datadog/
volumes:
- hostPath:
path: /var/run/datadog/
type: DirectoryOrCreate
# (...)
Cette configuration crée un répertoire sur le host et le monte dans l’Agent. L’Agent crée ensuite un fichier de socket dans ce répertoire avec la valeur DD_APM_RECEIVER_SOCKET
de /var/run/datadog/apm.socket
et effectue une écoute sur ce fichier. Les pods d’application peuvent alors être montés de la même façon sur ce volume et rédiger des données sur ce socket.
Lorsque la solution APM est activée, la configuration par défaut crée un répertoire sur le host et le monte dans l’Agent. L’Agent crée ensuite un fichier de socket /var/run/datadog/apm/apm.socket
et effectue une écoute sur ce fichier. Les pods d’application peuvent alors être montés de la même façon sur ce volume et rédiger des données sur ce socket. Vous pouvez modifier le chemin et le socket avec le paramètre features.apm.unixDomainSocketConfig.path
.
Il est possible de configurer l’Agent Datadog afin qu’il reçoive les traces via TCP. Pour activer cette fonctionnalité, procédez comme suit :
Modifiez votre manifeste DatadogAgent
en indiquant ce qui suit :
apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
name: datadog
spec:
global:
credentials:
apiKey: <CLÉ_API_DATADOG>
site: <SITE_DATADOG>
features:
apm:
enabled: true
hostPortConfig:
enabled: true
Remplacez <SITE_DATADOG>
par
(valeur par défaut : datadoghq.com
).
Consultez l’exemple de manifeste avec activation de l’APM et de la collecte des métriques pour un exemple complet.
Ensuite, appliquez la nouvelle configuration :
kubectl apply -n $DD_NAMESPACE -f datadog-agent.yaml
Attention : le paramètre hostPort
ouvre un port sur votre host. Assurez-vous que votre pare-feu accorde uniquement un accès à vos applications ou à d’autres sources de confiance. Si votre plug-in réseau ne prend pas en charge hostPorts
, ajoutez hostNetwork: true
aux spécifications de pod de votre Agent afin de partager l’espace de nommage réseau de votre host avec l’Agent Datadog. Cela signifie également que tous les ports ouverts sur le conteneur sont également ouverts sur le host. Si un port est utilisé sur le host et dans votre conteneur, ces derniers peuvent entrer en conflit (puisqu’ils partagent le même espace de nommage réseau), empêchant ainsi le pod de démarrer. Cela n’est pas possible avec certaines installations Kubernetes.