Paramètres Sonde Java

Avant d’utiliser la configuration avancée, vous devriez vous assurer d’avoir installé la sonde en utilisant la procédure d’installation java.

Le fichier nudge.properties peut devenir optionnel en fournissant les paramètres via les proprtiétés système de la JVM.

CONFIGURATION OBLIGATOIRE

Certains paramètres peuvent bénéficier du rechargement à chaud (depuis la version 4.0.0), c’est à dire qu’ils peuvent être modifiés dans le fichier de configuration et pris en compte en cours de fonctionnement sans redémarrer le serveur. Le rechargement à chaud des paramètres peut être désactivé en utilisant le paramètre allow_hot_reloading.

Liste des paramètres rechargeables à chaud

ignored_params
capture_params
allowed_params
capture_headers
ignored_headers
allowed_headers
httpclient_ip
compressed
profiling_thread_depth
profiling_sample_max_time
max_mbean_attributes_monitored
mbeans_monitored
prepend_tx_type
allow_instance_config
disk_fallback_max_send
disk_fallback_ignore_threshold
disk_fallback_max_size
disk_dump_max_size
system_sample_max_time
disk_fallback_directory
disk_dump_directory
service_qualifier

app_id

Il définit le lien avec l’application concernée sur le portail Nudge APM.

app_id est le paramètre le plus important du fichier nudge.properties. Il s’agit de la clé d’identification de votre application qui permet d’associer les informations envoyées par la JVM à l’application déclarée sur le portail Nudge.

Lorsque vous téléchargez le fichier zip depuis les paramètres de l’application, le fichier nudge.properties qui s’y trouve est automatiquement renseigné avec cet identifiant. Si vous réutilisez la sonde sur une autre application il faut le modifier afin d’alimenter une application distincte.

Quand l’application est hébergée sur plusieurs JVM, par exemple dans pour un cluster de serveurs, une valeur seule peut être partagée entre les serveurs. En conséquence, toutes les transactions seront regroupées dans la même application sur le portail Nudge APM.

D’un point de vue sécurité, ce paramètre définit l’identifiant de l’application pour l’envoi de données, il faut donc s’assurer que sa valeur ne soit pas exposée publiquement.

server_url

Pour les évaluations utiliser la valeur : server_url=https://ph-apm.eval.atakama-technologies.com/
Pour les clients, utiliser la valeur qui vous a été fournie par le support ou contacter le support
Pour les nouveaux clients contacter: support@atakama-technologies.com pour avoir la valeur de : server_url=https://ph-apm.<nomduclient>.collector.atakama-technologies.com/

Définit quel portail de Nudge APM est à utiliser et indique si l’installation est en local lorsqu’elle est déployé en On-Premises, ou par défaut en Saas.

Rechargement à chaud

allow_hot_reloading

Ce paramètre permet de désactiver le rechargement à chaud des propriétés (valeur : false). Sa valeur par défaut est “true”. Dans certains rares cas, le serveur ou la machine java ne parvient pas à stopper ce processus parallèle en cas d’arrêt ou de redémarrage ; ce paramètre permet d’éviter ce problème.

Compatibilité Java 17

excluded_classpath

La sonde est pleinement compatible Java 17 à partir de la version 3.6.1 Cette compatibilité implique cependant l’exclusion de certain(s) package(s) de l’instrumentation. Il convient donc d’ajouter le paramètre suivant au fichier nudge.properties :

excluded_classpath=jdk.proxy2

Les tests menés sur nos environnements ont montré que dans certains cas, l’exclusion du seul package jdk.proxy2 est insuffisante. Si vous rencontrez des soucis au lancement de l’agent, modifiez la configuration de la façon suivante :

excluded_classpath=jdk.proxy2,jdk.proxy3

Si malgré ces modifications, l’agent ne fonctionne pas correctement avec votre application Java 17, merci de nous contacter via le support Atakama.

Général

enable

Valeur par défaut : true

Permet de désactiver la sonde sans changer la ligne de commande de la JVM.

handlers

Valeur par défaut : http

Liste des destinations des données à envoyer, séparé par des virgules. Les valeurs valides sont : http et file

http la sonde envoie des données au portail Nudge APM.
file les données de la sonde sont stockées dans le dossier ‘log’ sans être envoyées sur le portain Nudge APM.
file,http combine les deux options : celles-ci sont envoyés au portail et stockés dans le disque.

Vous devrez aussi configurer disk_dump_directory et disk_dump_max_size pour contrôler l’emplacement et le volume de données conservées.

configuration_location

Valeur par défaut : system-file

Mode de paramétrage de la sonde et priorité de configuration

system-file
1. paramètres système de la JVM
2. fichier nudge.properties s’il existe
3. valeur par défaut
system : ignore le fichier nudge.properties
1. paramètres système de la JVM
2. valeur par défaut
/chemin/vers/ma/configuration.properties : utilisation d’un fichier de configuration spécifique
1. paramètres système de la JVM
2. fichier /chemin/vers/ma/configuration.properties s’il existe
3. valeur par défaut

service_hostname

Valeur par défaut : null

Disponible depuis la version 3.1.x

Permet de surcharger le nom d’hôte, doit être utilisé dans les cas suivants :

déploiement sur une plateforme PaaS où le nom d’hôte est un containeur et doit être surchargé avec un “nom logique” pour être pertinent.
lorsque la machine ne peut pas résoudre son propre nom.
lorsque le nom d’hôte doit être masqué

service_qualifier

Valeur par défaut : null

Disponible depuis la version 3.1.x

Permet de rajouter un suffixe du nom d’hôte pour faciliter le nommage.

Doit être utilisé lorsque plusieurs JVMs s’exécutent sur un système hôte partagé et doivent être distinguées sur le monitoring, par défaut elles seront toutes nommées avec le nom de la machine.

Ce paramètre est modifiable à chaud sans redémarrer le serveur (depuis la version 4.0.0).

collector_enable

Valeur par défaut: true

Disponible depuis la version version 3.2

Contrôle la collecte de données : false pour désactiver. Peut aussi être modifié dynamiquement via JMX.

Composants

Les composants sont disponibles depuis la version 3.2.

component_scan

Valeur par défaut : true

Lorsque activé, la sonde va automatiquement identifier les fichiers .jar de l’application. Les composants du conteneur sont aussi couverts.

Cela permet d’effectuer un suivi de l’utilisation des composants :

est-ce que le classpath d’exécution correspond à celui attendu ?
intégrité/sécurité : est-ce que les fichiers .jar de l’application ont été modifiés ?
architecture : sur quels composants l’application est-elle construite ?

Le suivi des composants est fait lors de leur usage::

il n’y a pas de lecture du classpath, les composants n’incluent que ce qui est utilisé
une utilisation réaliste de l’application est nécessaire pour détecter l’ensemble des composants.

Système

Les métriques système sont disponibles depuis les versions 3.1.x.

system_sample_enable

Valeur par défaut : true à partir de la version 3.1.1, false avant

Active/Désactive l’échantillonage des métriques système.

system_sample_interval

Valeur par défaut : 60000 (1 minute)

Contrôle la période d’échantillonage des métriques système

system_sample_max_time

Valeur par défaut : 100 (100 ms)

Contrôle la durée maximale d’échantillonage des métriques système, la fréquence est réduite au delà de cette limite.

Ce paramètre est modifiable à chaud sans redémarrer le serveur (depuis la version 4.0.0).

Corba

log_corba

Valeur par défaut : true

Controle l’instrumentation de CORBA

EJB

log_ejb3

Valeur par défaut : true

Controle l’instrumentation de l’EJB3.

Si vous avez des EJB2, vous pouvez utiliser trace_classpath_regex, l’annotation @Trace de l’API sonde nudge, ou contacter le support pour d’autres options.

RUM

activate_rum

Valeur par défaut : false

Contrôle l’injection de Javascript RUM dans les pages HTML produites par le Serveur d’application (JSP, Servlets…) Requis pour fournir la métrique du niveau de navigateur sur le portail.

Runnable & Threads

log_runnable

désactivé par défaut depuis la version 3.0.x

Contactez le support si vous avez besoin de suivre les Runnables et les Threads de votre application.

Profiling

profiling_enable

Valeur par défaut : true

Version disponible >= 3.0.10

Contrôle si l’échantillonage du profiling est actif.

profiling_thread_depth

Version disponible>= 3.0.10, pour les versions antérieures utiliser thread_depth.

Valeur par défaut : 1000

Profondeur maximum pour capturer des threadss, une valeur basse minimise le poids de données de profilage. Mais le profilage sera moins précis. Sauf indication explicite de l’équipe support, vous ne devriez pas changer cette valeur.

Ce paramètre est modifiable à chaud sans redémarrer le serveur (depuis la version 4.0.0).

profiling_sample_interval

Version disponible >= 3.0.10

Valeur par défaut : 1000

Profiling échantillonnant par intervalle, en millisecondes.

Par défaut, la sonde capture en instantané les transactions en cours chaque seconde.

Si vos transactions sont très rapides ou que vous avez seulement peu de transactions par jour, vous avez besoin d’une plus grande précision, ce qui ce traduit par “plus d’échantillonage”, vous devriez alors baisser cette valeur.

Avec un grand pouvoir vient de grande responsabilités

Nous conseillons d’utiliser ce paramètre avec soin et de contrôler l’activité de la sonde pour trouver un juste milieu entre “nombre d’échantillons” versus “la fréquence de profilage”.

profiling_sample_max_time

Version disponible >= 3.0.10

Valeur par défaut : 10

Temps alloué maximal pour l’échantillonnage de profiling en millisecondes. La fréquence est réduite en atteignant cette valeur afin de limiter une surchage.

Ce paramètre est modifiable à chaud sans redémarrer le serveur (depuis la version 4.0.0).

RMI

log_rmi

Valeur par défaut : true

Contrôle de l’instrumentation du RMI.

AOP

L’AOP (Aspect Oriented Programming) permet de définir quelles sont les méthodes à instrumenter dans votre code. Cela permet de procéder au suivi des transactions personnalisées & couches qui ne correspondant pas à un standard JEE supporté nativement par la sonde.

trace_classpath_regex

Le rôle de ce paramètre est de désigner les emplacements du code d’une application qui doivent faire l’objet d’un monitoring comme pour les transactions.

Quand l’utiliser ?

Il est généralement utilisé pour des traitements que la sonde ne sait pas détecter automatiquement, comme par exemple :

utilisation d’APIs non-gérées automatiquement par la sonde (pour le moment),
traitements batch (une méthode est appelé périodiquement),
traitements asynchrones (le traitement d’une transaction déclenche un appel dans un autre thread),
traitements concurrents (le traitement d’une transaction est distribuée sur différents threads)

Il permet de détecter des traitements asynchrones ou concurrents. En effet, les appels liés à une transaction sont liés à un thread durant l’exécution. Si le traitement est distribué dans différents threads, alors une partie du traitement devient invisible pour la sonde dans le cadre de la transaction précitée.

Pour les versions 3.x ou plus

Il correspond à des méthodes à instrumenter en tant que transactions ou en tant que layer. Il est exprimé en utilisant une syntaxe AOP avec valeurs séparées par des virgules.

Chaque élément est défini par 5 attributs :

Visibility : peut être soit public, protected, package, private ou * (ce qui inclus toute les valeurs possibles)
package : le nom du package java. Peut inclure le symbole * pour inclure plusieurs packages.
method : le nom de la méthode java. Peut inclure le symbole * pour inclure plusieurs méthodes.
name : le nom de la transaction ou du layer correspondant. Ce nom apparaît dans les données récoltés par Nudge et depuis les écrans du portail.
type : Valeur optionnelle qui peut être layer (par défaut) ou tx. Indique si l’entrée doit correspondre respectivement à un layer ou à une transaction.

Voici quelques examples :

* com.xyz.service.* * Service tx : Toutes les méthodes du package com.xyz.service sont instrumentées en tant que transactions de type Service.
public org.slf4j.impl.Log4jLoggerAdapter * Log4j layer : Crée une couche “Log4j” depuis slf4j pour suivre les logs en tant que couche.

Pour les versions antérieures à 3.x

Il correspond à des méthodes à instrumenter en tant que transactions. Il est exprimé en utilisant une syntaxe AOP avec valeurs séparées par des virgules.

Chaque élément est défini par 3 attributs :

Visibility : peut être soit public, protected, package, private ou * (ce qui inclus toute les valeurs possibles)
package : le nom du package java. Peut inclure le symbole * pour inclure plusieurs packages.
method : le nom de la méthode java. Peut inclure le symbole * pour inclure plusieurs méthodes.

Voici quelques examples :

public * * : Toutes les méthodes publiques sont instrumentées
* * set: Toutes les méthodes dont le nom commence par set sont instrumentées
com.xyz.service.* : Toutes les méthodes du package com.xyz.service sont instrumentées
com.xyz.Dao *: Toutes les méthodes dans des classes dont le nom commence par Dao dans le package (ou sous-package) com.xyz sont instrumentées.

Alternative avec annotation

Ce paramètre permet de détecter une nouvelle transaction sans besoin de modifier le code de l’application. Une alternative est l’utilisation de l’annotation @Trace reconnue par le sonde. Cette annotation indique à la sonde d’ajouter la méthode annotée en tant que transaction ou layer. Cette solution nécessite néanmoins une modification du code. Vous trouverez des informations détaillées sur cette annotation dans le projet publique dédié.

JMX

activate_jmx

Déprécié depuis la version 3.3.
Valeur par défaut : false

Permet d’activer ou de désactiver l’échantillonnage JMX.
À partir de la version 3.3, l’activation de ce monitoring se fait dès lors qu’une liste de mbean à monitorer est spécifiée.

mbeans_monitored

Liste des MBeans à transmettre. Seuls les MBeans objectNames mentionnés dans cette liste seront présents dans Nudge. Chaque MBean de la liste doit être séparé d’un point virgule (;).

Voici un exemple avec un MBean exposé par Tomcat:

mbeans_monitored=Catalina:type=RequestProcessor,worker="http-bio-8080",name=HttpRequest1

Ce même MBean peut aussi être récupéré avec un caractère de remplacement (*), comme les exemples ci-dessous le montrent :

mbeans_monitored=Catalina:type=RequestProcessor,worker="http-bio-8080",name=*
mbeans_monitored=Catalina:type=RequestProcessor,*

Avec des caractères de remplacement, tous les MBeans correspondants seront considérés. Soyez prudent concernant les différents cas d’utilisations de caractères de remplacement entre les versions J2SE 5.0 et Java SE 6. Ces différences sont expliquées sur le site Web d’Oracle.

Vous pouvez inclure plusieurs MBeans et groupes de MBeans grace au caractère point-virgule (;). Voici un exemple d’utilisation :

mbeans_monitored=com.mycompany.mymbean:type=mytype;Catalina:type=RequestProcessor,*

Ce dernier exemple inclus les MBeans correspondants à Catalina:type=RequestProcessor,* mais aussi le MBean com.mycompany.mymbean:type=mytype. Pour une meilleure lisibilité, il est aussi possible de l’écrire ainsi :

mbeans_monitored=\
com.mycompany.mymbean:type=mytype;\
Catalina:type=RequestProcessor,*

Par défaut tous les attributs numérique d’un MBean spécifié ici sont récupérés par l’agent.
À partir de la version 3.3, il est possible de ne capturer que certains attributs. Il suffit d’ajouter à la suite d’un MBean un espace et la liste des attributs à récupérer séparés par des virgules :

mbeans_monitored=\
com.mycompany.mymbean:type=mytype attr1,attr2,attr3;\
Catalina:type=RequestProcessor,*

Ce paramètre est modifiable à chaud sans redémarrer le serveur (depuis la version 4.0.0).

max_mbean_attributes_monitored

Valeur par défaut : 2000

La sonde enregistre tout les attributs Mbean, jusqu’à cette limite. Soit le nombre maximal d’attributs enregistrés pour chaque MBEAN.

Ce paramètre est modifiable à chaud sans redémarrer le serveur (depuis la version 4.0.0).

jmx_sample_interval

Version disponible >= 3.0.10

Valeur par défaut : 10000 (10s)

Echantillonnage JMX par intervalle, en millisecondes. Valeur minimale : 10s, qui se traduisent à 6 échantillons par minute sur le portail.

jmx_sample_max_time

Version disponible >= 3.0.10

Valeur par défaut : 100 (100ms)

Temps maximal pour l’échantillonage JMX en millisecondes. La fréquence est réduite en atteignant cette valeur afin de limiter une surcharge.

HTTP

Les paramètres et entêtes HTTP pouvant avoir un caractère confidentiel, la sonde Nudge n’en capture par défaut aucun.
Cependant, il peut s’avérer utile de récupérer certaines informations non confidentielles notamment dans deux cas de figure :

afin de permettre de regrouper les appels de transactions de manière pertinente
en cas de problème car ces informations peuvent aider au diagnostic

Pour répondre à ce besoin, la sonde dispose de paramètres qui permettent de définir le périmètre des données que la sonde est autorisée à capturer et à publier sur le contrôleur Nudge et qui pourront ensuite être exploité dans le monitoring.

Ce mécanisme fonctionne pour les requêtes GET (avec les données en query) aussi bien que pour les paramètres de requêtes POST (dans le body).

capture_params

Valeur par défaut : false

Active la capture des paramètres HTTP.

Si ce paramètre est activé, il est alors nécessaire de définir la liste des paramètres autorisés (allowed_params) et/ou la liste des paramètres interdits (ignored_params) à la capture.
Ces deux listes peuvent être combinées en suivant ces règles :

en activant les deux listes “allowed” et “ignored”, les paramètres présent dans “allowed” seront pris en compte et ceux dans “ignored” seront ignorés
si un paramètre fait partie des deux listes, il sera ignoré puisque présent dans la liste “ignored”
on peut déclarer seulement le paramètre “allowed”
on ne peut pas déclarer seulement la liste “ignored” sans quoi tous les paramètres seront ignorés (aucun ne sera présent dans la liste “allowed”)

Ce paramètre est modifiable à chaud sans redémarrer le serveur (depuis la version 4.0.0).

ignored_params

Valeur par défaut : (vide)
Exemple : ignored_params=password,card_number

ignored_params est une liste de valeurs séparées par des virgules. Elle permet de spécifier les paramètres que l’agent doit ignorer dans les appels HTTP.
À titre d’exemple, si on considère la configuration suivante : ignored_params=password,card_number et qu’une requête HTTP contient les paramètres login, password et action alors l’agent ne conservera et ne publiera au contrôleur Nudge que les paramètres login et action pour cette transaction.

Ce paramètre est modifiable à chaud sans redémarrer le serveur (depuis la version 4.0.0).

allowed_params

Valeur par défaut : (vide)
Exemple : allowed_params=login,action

allowed_params est une liste de valeurs séparées par des virgules. Elle permet de spécifier les paramètres que la sonde est autorisée à capturer dans les appels HTTP.
À titre d’exemple, si on considère la configuration suivante : allowed_params=login,action et qu’une requête HTTP contient les paramètres login, password et action alors la sonde ne conservera et ne publiera au contrôleur Nudge que les paramètres login et action pour cette transaction.

Ce paramètre est modifiable à chaud sans redémarrer le serveur (depuis la version 4.0.0).

capture_headers

Default value : false

Active la capture des entêtes HTTP.

Si ce paramètre est activé, il est alors nécessaire de définir la liste des entêtes authorisés (allowed_headers) et/ou la liste des entêtes interdits (ignored_headers) à la capture.
Ces deux listes peuvent être combinées en suivant ces règles :

en activant les deux listes “allowed” et “ignored”, les paramètres présent dans “allowed” seront pris en compte et ceux dans “ignored” seront ignorés
si un paramètre fait partie des deux listes, il sera ignoré puisque présent dans la liste “ignored”
on peut déclarer seulement le paramètre “allowed”
on ne peut pas déclarer seulement la liste “ignored” sans quoi tous les paramètres seront ignorés (aucun ne sera présent dans la liste “allowed”)

Ce paramètre est modifiable à chaud sans redémarrer le serveur (depuis la version 4.0.0).

ignored_headers

Valeur par défaut : (vide)
Exemple : ignored_headers=Authorization,Proxy-Authenticate

ignored_headers est une liste de valeurs séparées par des virgules. Elle permet de spécifier les entêtes que la sonde doit ignorer dans les appels HTTP.
À titre d’exemple, si on considère la configuration suivante : ignored_headers=Authorization,Proxy-Authenticate et qu’une requête HTTP contient les entêtess Authorization et Cookie alors la sonde ne conservera et ne publiera au contrôleur Nudge que l’entête Cookie pour cette transaction.

Cette configuration n’est pas sensible à la casse : ignored_headers=Authorization et ignored_headers=AUTHORIZATION auront le même effet.

Ce paramètre est modifiable à chaud sans redémarrer le serveur (depuis la version 4.0.0).

allowed_headers

Valeur par défaut : (vide)
Exemple : ignored_headers=Cookie,Accept

allowed_headers est une liste de valeurs séparées par des virgules. Elle permet de spécifier les entêtes que la sonde est autorisée à capturer dans les appels HTTP.
À titre d’exemple, si on considère la configuration suivante : allowed_headers=Cookie,Accept et qu’une requête HTTP contient les entêtes Authorization et Cookie alors la sonde ne conservera et ne publiera au contrôleur Nudge que l’entête Cookie pour cette transaction.

Cette configuration n’est pas sensible à la casse : allowed_headers=Cookie et allowed_headers=COOKIE auront le même effet.

Ce paramètre est modifiable à chaud sans redémarrer le serveur (depuis la version 4.0.0).

http_client_ip

Valeur par défaut : false

Ce paramètre permet de demander à la sonde de capturer les adresses IP des clients qui invoquent les transactions sur l’application.
Selon la légisalation en vigueur, en cas d’activation de cette capture, vous pouvez être tenu d’en informer vos utilisateurs.

Paramètre disponible à partir de la version 3.2.5, avant cette version l’adresse était toujours capturée.

Ce paramètre est modifiable à chaud sans redémarrer le serveur (depuis la version 4.0.0).

log_servlet_contextlistener

Valeur par défaut : false

Crée une transaction pour le démarrage et arrêt d’une application web, permet de diagnostiquer les ralentissements lors de ces phases du déploiement.

Inclusion/Exclusion

Lors de l’instrumentation, la sonde procède en deux étapes : évaluer l’éligibilité de chaque classe à une instrumentation puis l’instrumentation elle-même. Ces paramétres permettent d’accélérer la phase d’éligibité en évitant de charger systématiquement toutes les informations nécessaires pour vérifier l’ensemble des possibilité.

excluded_classpath

Liste de packages ou des classes à exclure (black list) de l’instrumentation.

Séparateur : , (virgule)
Exemple (une exclusion d’un package et une exclusion d’une classe) :
```
excluded_classpath=oracle.oc4j.sql.proxy,com.acme.impl.SomeClass
```

included_classpath

Liste de packages à inclure (white list) de l’instrumentation.

excluded_classloaders

Liste de classloader dont toutes les classes qu’ils chargent sont à exclure de l’instrumentation.

SQL

query_anonymization

Valeur par défaut : true

Si vous remontez un volume élevé de requêtes, il est recommandé de ne pas activer ce paramètre afin d’éviter les ralentissements dans les temps d’affichage.

long_query_threshold

Valeur par défaut : 0 (désactivé)

Lorsqu’une requête SQL est généralement rapide mais de temps en temps très lente, cela rend la compréhension de l’erreur difficile car sa reproduction n’est pas évidente. Ce genre de problème est souvent lié à un jeu de valeurs particulier des paramètres de la requête.
En utilisant une valeur supérieure à zéro pour long_query_threshold, les requêtes SQL dont la durée dépasse ce seuil en millisecondes seront envoyés sans anonymisation, cela facilite la reproduction du problème et ainsi sa résolution.

query_count_limit

Valeur par défaut: 10000

Nombre maxium de requêtes SQL collectées par l’agent dans chacun de ses messages envoyés (env. 1 par minute) au collecteur de Nudge APM.

log_connection

Valeur par défaut : false

Logging

log_level

Valeur par défaut : INFO

Les valeurs possibles sont SEVERE, WARNING, INFO, CONFIG, FINE, FINER ou FINEST.

log_level est le paramètre qui contrôle le niveau de log que la sonde utilise, par défaut le niveau de log est en INFO, ce qui convient pour les environnements de production. Lorsque vous installez l’agent pour la première fois ou que vous souhaitez valider son fonctionnement sur une application, il est recommandé de le configurer à la valeur FINE.

log_directory

Répertoire utilisé pour le log, il sera crée s’il n’existe pas.

Par défaut, il s’agit du répertoire log à côté du jar de la sonde.

Avec plusieurs JVM sur le même hôte, vous devriez vous assurer que chaque instance de la JVM a son propre dossier consacré.

log_rotation_count

Valeur par défaut : 5

Le nombre de fichiers de log à garder. La rotation des logs est faite à chaque démarrage de la JVM.

upload_log

Valeur par défaut : true

Le transfert des logs de la sonde vers le portail Nudge APM permet à l’équipe Nudge d’effectuer un meilleur suivi.

fine_log_on_startup

Valeur par défaut : true

Élève temporairement le niveau de log par défaut en FINE pendant les premières minutes après le démarrage.

Facilite le support et le diagnostic en cas d’un problème au démarrage de l’application.

allow_instance_config

Valeur par défaut : true

Active l’envoi de la configuration de la sonde vers le portail Nudge APM. Lorsque désactivé, uniquement certains paramètres de la JVM sont remontés vers le protail Nudge APM.

Ce paramètre est modifiable à chaud sans redémarrer le serveur (depuis la version 4.0.0).

upload_config

Valeur par défaut : true pour les versions 3.0.x false pour les versions 3.1.x

Transférer les configurations de la sonde vers le portail Nudge APM afin d’avoir un meilleur suivi.

Collecte

La sonde collecte les métriques en mémoire et ensuite envoie (flush) les données dans le portail Nudge APM de manière asynchrone. Ces paramètres controlent les événements qui déclenchent un flush.

Les valeurs par défaut s’adaptent à la plupart des applications, cependant si vous avez un volume important de transactions (> 1000 tx/min ou plus), vous devriez adapter ces valeurs afin de réduire l’impact de la sonde sur la mémoire.

flush_tx_count

Valeur par défaut : 2000

Nombre de transactions pour déclencher un flush.

flush_thread_samples_count

Valeur par défaut : 5000

Nombre d’échantillons de threads pour déclencher un flush.

flush_jmx_samples_count

Valeur par défaut : 1000

Nombre d’échantillons JMX pour déclencher un flush.

flush_system_samples_count

Valeur par défaut : 1000

Nombre d’échantillons de métriques système pour déclencher un flush.

flush_components_count

Valeur par défaut : 1000

Nombre de composants détectés pour déclencher un flush.

flush_rum_count

Valeur par défaut : 1000

Nombre d’échantillons RUM pour déclencher un flush.

flush_interval

Valeur par défaut : 60 (1 minute)

Intervalle de temps entre deux flush en seconde(s)

flush_overflow_limit_factor

Valeur par défaut : 5

Contrôle le nombre maximum d’éléments conservés en mémoire par la sonde en attente d’un flush. Ce facteur est appliqué aux paramètres flush_*_count ci-dessus pour définir la limite.

Par défaut, une valeur de 5 permet à la sonde de conserver au plus 5 x 2000 = 10000 transactions en mémoire. Au delà, les nouvelles transactions sont ignorées, et le monitoring devien partiel.

Réseau

proxy_type

Valeur par défaut : http

proxy_host

Nom d’hôte ou IP du serveur Proxy.

proxy_port

Port du serveur Proxy

proxy_user

L’utilisateur du Proxy, laissez vide pour désactiver l’authentification

proxy_password

Mot de passe du Proxy

compressed

Valeur par défaut : true

Active/Désactive la compression des donnés lors de l’envoi au contrôleur.

Avec la compression activée, les données envoyées sont réduites de 90%, l’agent consomme un peu plus de CPU.

Ce paramètre est modifiable à chaud sans redémarrer le serveur (depuis la version 4.0.0).

network_connect_timeout

Default value : 2000 (2s)

Délai de connexion au portail Nudge en millisecondes.

network_read_timeout

Default value : 5000 (5s)

Délai d’envoi au portail en millisecondes.

packet_size

Usage Disque

disk_dump_directory

Valeur par défaut: log_directory

Contrôle où les données sont stockées lorsque l’option handlers = file

Ce paramètre est modifiable à chaud sans redémarrer le serveur (depuis la version 4.0.0).

disk_dump_max_size

Valeur par défaut: -1 (illimité)

Contrôle le volume maximum de données (en octets) qui doit être conservé lorsque l’option handlers = file

Ce paramètre est modifiable à chaud sans redémarrer le serveur (depuis la version 4.0.0).

disk_fallback_directory

Valeur par défaut: log_directory

Contrôle l’emplacement de stockage temporaire lorsque le Portail Nudge est injoignable.

Ce paramètre est modifiable à chaud sans redémarrer le serveur (depuis la version 4.0.0).

disk_fallback_max_size

Valeur par défaut: 209715200 (200Mb)

Contrôle le volume de stockage temporaire (en octets) lorsque le Portail Nudge est injoignable.

Ce paramètre est modifiable à chaud sans redémarrer le serveur (depuis la version 4.0.0).

disk_fallback_ignore_threshold

Valeur par défaut: 86400 (24h)

Contrôle la durée (en secondes) pendant laquelle les données doivent être conservées lorsque le Portail Nudge est injoignable.

Les données seront détruites lorsque le Portail Nudge reste indisponible pour une période plus longue que ce paramètre.

Ce paramètre est modifiable à chaud sans redémarrer le serveur (depuis la version 4.0.0).

disk_fallback_max_send

Valeur par défaut: 10

Contrôle le nombre de fichiers temporaires stockés lors de l’indisponibilité du portail doivent être envoyés lorsque la connexion est à nouveau disponible.

Ce paramètre est modifiable à chaud sans redémarrer le serveur (depuis la version 4.0.0).

Autres

Ces fonctions sont mises à disposition principalement pour diagnostic, mais leur usage n’est pas garanti. Nous pouvons les modifier ou les retirer dans des versions futures.

dryrun

Valeur par défaut : false

Permet de désactiver l’instrumentation de l’application en conservant la capture des métriques JMX et l’envoi des données. Ne doit être utilisé que pour du diagnostic, lorsque activé aucune transaction ne sera capturée.

thread_dump_frequency

Fréquence d’exécution des captures des thread dump, en seconde.
Ce paramètre est à utiliser avec thread_dump_duration

Valeur par défaut : 0 (signifie que ce paramètre est désactivé)

thread_dump_duration

Permet de définir la durée de capture en seconde des thread dumps à partir du démarrage de la JVM.
Ce paramètre est actif seulement lorsque thread_dump_frequency est > 0.

Valeur par défaut : 0 (signifie que ce paramètre est désactivé)
Exemple pour une capture de thread toutes les secondes pendant dix secondes après le démarrage de la JVM :
```
thread_dump_frequency=1
thread_dump_duration=10
```

prepend_tx_type

Valeur par défaut : false

Prefixe le nom des transactions avec leur type.

Ce paramètre est modifiable à chaud sans redémarrer le serveur (depuis la version 4.0.0).

dump_classes

Valeur par défaut : false

Copie les classes instrumentées avant et après transformation dans le répertoire log_directory.

dump_all_classes

Valeur par défaut : false

Copie l’ensemble des classes de l’application dans log_directory.

instrumented_code_stacktraces

Valeur par défaut : false

Ecrit en log la stack trace d’une méthode instrumentée, c’est un paramètre particulièrement verbeux.