Dépannage pour les intégrations JMX
Pour vérifier que vous avez bien accès à JMX, effectuez un test à lʼaide de JConsole ou équivalent, si possible. Si vous nʼêtes pas en mesure de vous connecter à lʼaide de JConsole, cet article peut vous venir en aide. Aussi, si les métriques indiquées dans votre YAML ne correspondent pas exactement à celles indiquées dans JConsole, vous devrez corriger ce problème.
Pour toutes les versions de
Agent v5.32.8 ou ultérieur, le JAR
jmxterm
nʼest pas fourni avec lʼagent. Pour télécharger et utiliser
jmxterm
, consultez le
projet upstream. Modifiez
/opt/datadog-agent/agent/checks/libs/jmxterm-1.0-DATADOG-uber.jar
dans les exemples ci-dessous en le remplaçant par le chemin JAR
jmxterm
que vous avez téléchargé depuis le projet upstream.
Si vous êtes en mesure de vous connecter à lʼaide de JConsole, exécutez la commande suivante :
java -jar /opt/datadog-agent/agent/checks/libs/jmxterm-1.0-DATADOG-uber.jar -l localhost:<PORT> -u <UTILISATEUR> -p <MOT_DE_PASSE>
Si vous êtes en mesure de vous connecter à lʼaide de la commande ci-dessus, exécutez beans
et envoyez une copie des résultats à lʼéquipe dʼassistance de Datadog avec les informations suivantes :
- Flare de lʼAgent,qui comprend :
- Résultat de la commande status.
- Contenu de
/var/log/datadog/agent.log
- Contenu de
/var/log/datadog/jmxfetch.log
- Une copie de lʼintégration YAML.
- Résultat de :
ps aux | grep jmxfetch
- Résultat de :
sudo -u dd-agent datadog-agent jmx list everything -l debug
(lʼajout de --flare
permet dʼinclure le résultat dans le flare pour la version 6.26.x/7.26.x)
- Flare de lʼAgent,qui comprend :
- Résultat de la commande info.
- Contenu de
/var/log/datadog/jmxfetch.log
- Une copie de lʼintégration integration.
- Résultat de :
ps aux | grep jmxfetch
- Résultat de :
sudo /etc/init.d/datadog-agent jmx list_everything
Remarque : si vous êtes en mesure de consulter des métriques (comme jvm.heap_memory
ou jvm.non_heap_memory
, entre autres), cela signifie que JMXFetch fonctionne correctement. Si vous ciblez une autre application et si vous ne voyez pas les métriques associées, cela veut certainement dire que votre YAML est mal configuré.
Dépannage de lʼAgent
Ces commandes ont été introduites avec la version v6.2.0 :
Commande | Description |
---|
sudo -u dd-agent datadog-agent jmx list matching | Énumère les attributs qui correspondent au moins à l’une de vos configurations d’instance. |
sudo -u dd-agent datadog-agent jmx list limited | Énumère les attributs qui correspondent à l’une de vos configurations d’instance, mais qui ne sont pas recueillis afin de ne pas dépasser le nombre maximum de métriques pouvant être recueillies. |
sudo -u dd-agent datadog-agent jmx list collected | Indiquez des attributs qui sont vraiment recueillis par la configuration actuelle de vos instances. |
sudo -u dd-agent datadog-agent jmx list not-matching | Énumère les attributs qui ne correspondent à aucune de vos configurations d’instance. |
sudo -u dd-agent datadog-agent jmx list everything | Énumère l’ensemble des attributs disponibles dont le type est pris en charge par JMXFetch. |
sudo -u dd-agent datadog-agent jmx collect | Démarrer la collecte de métriques en fonction de votre configuration actuelle et les afficher dans la console. |
Remarques :
Par défaut, ces commandes sʼexécutent pour tous les checks JMX configurés. Pour restreindre lʼutilisation des commandes à certains checks, utilisez le flag --checks
, par exemple :
sudo -u dd-agent datadog-agent jmx list collected --checks tomcat
Pour lʼAgent v6.26.+/v7.26+, lʼajout de --flare
writes the output of the above commands under /var/log/datadog/jmxinfo/
, inclus dans le flare.
sudo -u dd-agent datadog-agent jmx list everything -l debug --flare
LʼAgent 6 transmet JMXFetch et prend en charge lʼensemble de ses fonctionnalités, à lʼexception de celles qui sont indiquées ci-dessous.
Lʼinterface de lʼAgent ne dispose pas des toutes les fonctionnalités nécessaires à JMXFetch. Vous devrez donc peut-être exécuter certaines commandes manuellement pour débuguer la liste des éléments recueillis, les JVM, etc. Un appel manuel standard prendra la forme suivante :
/usr/bin/java -Xmx200m -Xms50m -classpath /usr/lib/jvm/java-8-oracle/lib/tools.jar:/opt/datadog-agent/bin/agent/dist/jmx/jmxfetch-0.18.2-jar-with-dependencies.jar org.datadog.jmxfetch.App --check <CHECK_LIST> --conf_directory /etc/datadog-agent/conf.d --log_level INFO --log_location /var/log/datadog/jmxfetch.log --reporter console <COMMAND>
où <COMMAND>
est un des éléments suivants :
list_everything
list_collected_attributes
list_matching_attributes
list_not_matching_attributes
list_limited_attributes
list_jvms
et <CHECK_LIST>
correspond à une liste de configurations yaml
valides dans /etc/datadog-agent/conf.d/
. Par exemple :
cassandra.d/conf.yaml
kafka.d/conf.yaml
jmx.d/conf.yaml
Exemple :
/usr/bin/java -Xmx200m -Xms50m -classpath /usr/lib/jvm/java-8-oracle/lib/tools.jar:/opt/datadog-agent/bin/agent/dist/jmx/jmxfetch-0.18.2-jar-with-dependencies.jar org.datadog.jmxfetch.App --check cassandra.d/conf.yaml jmx.d/conf.yaml --conf_directory /etc/datadog-agent/conf.d --log_level INFO --log_location /var/log/datadog/jmxfetch.log --reporter console list_everything
Remarques :
- Lʼemplacement de lʼélément tools.jar de JRE (
/usr/lib/jvm/java-8-oracle/lib/tools.jar
dans lʼexemple) peut se trouver ailleurs dans votre système. La commande sudo find / -type f -name 'tools.jar'
devrait vous permettre de le retrouver. - Il est recommandé dʼindiquer des paramètres alternatifs pour le tas JVM
-Xmx
, -Xms
. Les valeurs utilisées dans lʼexemple correspondent aux valeurs par défaut de JMXFetch.
Commande | Description |
---|
sudo /etc/init.d/datadog-agent jmx list_matching_attributes | Énumérer les attributs qui correspondent à au moins l’une de vos configurations d’instance. |
sudo /etc/init.d/datadog-agent jmx list_limited_attributes | Énumère les attributs qui correspondent à l’une de vos configurations d’instance, mais qui ne sont pas recueillis afin de ne pas dépasser le nombre maximum de métriques pouvant être recueillies. |
sudo /etc/init.d/datadog-agent jmx list_collected_attributes | Énumère les attributs qui sont véritablement recueillis par vos configurations d’instance actuelles. |
sudo /etc/init.d/datadog-agent jmx list_not_matching_attributes | Énumère les attributs qui ne correspondent à aucune de vos configurations d’instance. |
sudo /etc/init.d/datadog-agent jmx list_everything | Énumère l’ensemble des attributs disponibles dont le type est pris en charge par JMXFetch. |
sudo /etc/init.d/datadog-agent jmx collect | Démarrer la collecte de métriques en fonction de votre configuration actuelle et les afficher dans la console. |
Pour vérifier qu’Autodiscovery charge les checks basés sur JMX :
$ docker exec -it <AGENT_CONTAINER_NAME> agent configcheck
Pour consulter lʼétat des checks basés sur JMX depuis lʼAgent :
$ docker exec -it <AGENT_CONTAINER_NAME> agent status
FAQ
Limite de 350 métriques
Datadog permet lʼutilisation dʼun maximum de 350 métriques.
Il est recommandé de se limiter pour ne pas atteindre ce seuil, en affinant les métriques recueillies à lʼaide de filtres. Toutefois, si vous avez besoin de plus de 350 métriques, vous pouvez augmenter cette limite en modifiant un paramètre dans votre fichier de configuration JMX.
Veuillez contacter lʼéquipe dʼassistance de Datadog si vous souhaitez augmenter cette limite.
Chemin Java
Aucune JVM nʼest fournie lors de lʼinstallation par défaut de lʼAgent. Celle qui est installée sur votre système est utilisée. Vous devez donc vous assurer que le chemin de lʼutilisateur qui exécute lʼAgent inclut le répertoire principal de Java.
Remarques :
- Lʼimage
gcr.io/datadoghq/agent:latest-jmx
du Docker comprend une JVM, dont lʼAgent a besoin pour exécuter jmxfetch. Vous pouvez aussi indiquer le chemin de la JVM dans le fichier de configuration de lʼintégration avec le paramètre java_bin_path
. - Un seul chemin Java valide doit être indiqué pour JMXFetch.
Métriques JVM
La bibliothèque Java APM de Datadog est en mesure de recueillir des métriques JVM sans lʼintégration JMX. Consultez la section Métriques runtime pour en savoir plus.
Surveillance des applications JBoss ou WildFly
Les instructions suivantes fonctionnent sur la version 5.6.0+ de l’Agent.
Les applications JBoss/WildFly exposent JMX avec un protocole spécifique (JMX à distance) qui n’est pas par défaut groupé avec JMXFetch. Pour que JMXFetch se connecte à ces applications, suivez les étapes suivantes :
- Naviguez jusqu’au fichier
jboss-cli-client.jar
sur votre serveur JBoss/WildFly (par défaut, son chemin est $JBOSS_HOME/bin/client/jboss-cli-client.jar
). - Si JMXFetch s’exécute sur un host autre que l’application JBoss/WildFly, copiez
jboss-cli-client.jar
à un emplacement du host sur lequel JMXFetch s’exécute. - Ajoutez le chemin du fichier jar dans la section
init_config
de votre configuration :
# Datadog Agent >= 5.6.0
init_config:
custom_jar_paths:
- /chemin/vers/client-cli-jboss.jar
- Indiquez une URL personnalisée à laquelle JMXFetch doit se connecter dans la section
instances
de votre configuration :
# Agent Datadog >= 5.6.0
# jmx_url peut être différent en fonction de la version de JBoss/WildFly que vous utilisez
# et de la façon dont vous avez configuré la JMX sur votre serveur
# Consultez la documentation correspondante de JBoss/WildFly pour en savoir plus
instances:
- jmx_url: "service:jmx:remote://localhost:4447"
name: jboss-application # Obligatoire, mais nʼimporte quelle valeur peut être utilisée,
# sert à appliquer un tag aux métriques extraites de cette instance
Remarque : si un message dʼerreur similaire à Unable to instantiate or initialize instance <instance_name> for an unknown reason.Parameter 'name' may not be null
sʼaffiche, il se peut que vous deviez définir un utilisateur wildfly avec $WILDFLY_HOME/bin/add-user.sh -a -u <user> -p <password>
et indiquer une valeur pour user
et password
dans la section instances
de votre configuration :
instances:
- jmx_url: <jmx_url>
name: <instance_name>
user: <username>
password: <password>
Surveillance de Tomcat via lʼactivation de lʼécouteur de cycle de vie distant JMX
Les instructions suivantes fonctionnent sur la version 5.6.0+ de l’Agent.
Si vous avez activé lʼécouteur de cycle de vie distant JMX lors de votre utilisation de Tomcat (consultez la documentation de Tomcat pour en savoir plus), JMXFetch a besoin dʼune configuration supplémentaire pour pouvoir se connecter à votre application Tomcat.
- Naviguez jusqu’au fichier
catalina-jmx-remote.jar
sur votre serveur Tomcat (par défaut, son chemin est $CATALINA_HOME/lib
). - Si JMXFetch s’exécute sur un host autre que l’application Tomcat, copiez
catalina-jmx-remote.jar
à un emplacement du host sur lequel JMXFetch s’exécute. - Ajoutez le chemin du fichier jar dans la section
init_config
de votre configuration :
# Agent Datadog >= 5.6.0
init_config:
custom_jar_paths:
- /chemin/vers/catalina-jmx-remote.jar
- Indiquez une URL personnalisée à laquelle JMXFetch doit se connecter dans la section
instances
de votre configuration :
# Agent Datadog >= 5.6.0
# Le jmx_url peut varier en fonction de votre configuration de JMX sur votre serveur Tomcat.
instances:
- jmx_url: "service:jmx:rmi://:10002/jndi/rmi://:10001/jmxrmi"
name: tomcat-application # Requis, mais peut être défini sur n'importe quelle valeur arbitraire,
# est utilisé pour taguer les métriques récupérées à partir de cette instance
Dépannage du SSL
Une fois que lʼAPI JMX est activée et que le check de votre Agent envoie correctement des métriques à Datadog, vous pouvez sécuriser la connexion à distance via un socket SSL.
Remarque : vous ne pouvez pas sécuriser JMX via SSL sans lʼaide des fichiers dʼauthentification distants de lʼutilisateur ou du mot de passe de JMX. Si vous exécutez votre application par le biais dʼautorisations au niveau du système, ajoutez ces fichiers et exécutez-les au démarrage.
Cet exemple illustre la configuration de Datadog pour lʼintégration de Tomcat.
- Établissez un certificat et une clé à appliquer au keystore de votre app Java.
- Mettez à jour votre fichier Tomcat Datadog
conf.yaml
, situé dans conf.d/tomcat.d
:
instances:
- host: localhost
port: 9000
user: tomcat
password: tomcat
name: tomcat_webapp
trust_store_path: <KEYSTORE_PATH>
trust_store_password: <KEY_PASSWORD>
Pour aller plus loin
Documentation, liens et articles supplémentaires utiles: