Questions Fréquentes

Installation sonde

Est-il possible de monitorer une application sous Docker ?

Oui.

En Java, la sonde s’active par un paramétrage de la JVM, donc il suffit d’activer ce paramétrage sur le processus Java de votre application qui tourne dans le conteneur.

En PHP l’extension Nudge APM doit être ajoutée au runtime PHP qui figure dans l’image du conteneur. Concernant l’agent, celui-ci est un processus à part entière et il ne peut pas être installé sur une machine séparée de l’application PHP elle-même. L’agent PHP doit donc être démarré dans le même conteneur que l’application PHP elle-même.

La sonde communique-t-elle bien avec la plateforme Nudge ?

La première chose à vérifier est : “pouvez vous faire un ping sur le serveur nudge” ?

ping collector.nudge-apm.com

devrait répondre : (l’adresse peut varier)

PING collector.nudge-apm.com (46.105.58.214) 56(84) bytes of data.
64 bytes from ip214.ip-46-105-58.eu (46.105.58.214): icmp_seq=1 ttl=54 time=6.11 ms
64 bytes from ip214.ip-46-105-58.eu (46.105.58.214): icmp_seq=2 ttl=54 time=6.48 ms
64 bytes from ip214.ip-46-105-58.eu (46.105.58.214): icmp_seq=3 ttl=54 time=6.79 ms

Comment vérifier que la sonde est bien prise en compte par le serveur d’application ?

Dans les fichiers de log / console du serveur on doit retrouver la ligne JAVAAGENT START qui signifie que l’agent est bien pris en compte par le serveur d’application.

Une fois la JVM démarrée, l’agent doit créer un répertoire log (à côté du jar de la sonde par défaut) ainsi qu’un fichier nudge.log à l’intérieur.

Les données sont-elles bien envoyés sur le serveur ?

Avec le paramètre log_level=INFO (valeur par défaut) une ligne est écrite dans le fichier log/nudge.log à chaque envoi.

Comment savoir si le problème vient du réseau ?

Pour tester la connexion sans timetout on peut utliser la commande suivante

telnet collector.nudge-apm.com 443

Si ça affiche Connected to, c’est que la connexion parvient à s’établir mais il y a une latence importante.

J’ai le message suivant dans les logs de la sonde après avoir laissé la sonde quelques minutes

error while sending data : java.net.SocketTimeoutException connect timed out

Il semblerait que la communication vers collector.nudge-apm.com sur le port 443 ne soit pas possible.

Si votre environnement utilise un proxy réseau, alors il est posible de l’utiliser en définissant les paramètres proxy_host, proxy_port, proxy_user et proxy_password dans le fichier nudge.properties.

Il est aussi possible d’utiliser le port 80 (sans chiffrage) avec server_url=http://collector.nudge-apm.com dans le fichier nudge.properties.

J’ai le message suivant dans les logs de la sonde après avoir laissé la sonde quelques minutes

error while sending data : java.net.ssl.SSLHandshakeException

Il semblerait que vous utilisez un keystore qui n’est pas celui par défaut du JDK.

Le keystore du JDK contient par défaut les certificats qui permettent la validation de la chaine de certification pour accéder de manière sécurisée à la plate forme nudge.

Si vous avez besoin de rajouter des certificats spécifiques, par exemple pour se connecter à un serveur utilisant un certificat auto-signé, il est courant de partir d’une copie du keystore par défaut plutôt que d’un keystore vide, ce qui évite ce genre de désagréments.

Ainsi, via un export du keystore existant vers le keystore par défaut tout devrait rentrer dans l’ordre.

Pour plus de détails, je vous invite à consulter la documentation de l’outil de gestion du keystore du JDK qui s’appelle keytool.

Par ailleurs, il est aussi possible de désactiver l’utilisation du protocole SSL en replaçant l’url en https en http.

Bien que moins sécurisé, en pratique il est très peu probable que les échanges avec le serveur soient compromis, en particulier car les informations envoyées ne sont que techniques et donc relativement peu sensibles.

Est-il possible de mettre la sonde dans un autre répertoire de mon choix et pointer dessus ensuite ?

Actuellement, cela n’est pas possible, le fichier de propriété doit impérativement être au même niveau que la sonde.

Dans la prochaine version, les propriétés pourront être passé en ligne de commande directement.

Quel est le port par défaut utilisé par la sonde pour envoyer les données au serveur ?

Le port 443 qui est aussi le numéro de port par défaut pour les transfert SSL.

Il est possible aussi d’utiliser le port 80 avec server_url=http://collector.nudge-apm.com dans le fichier nudge.properties.

Puis-je monitorer distinctement plusieurs applications qui tournent sur un même serveur d’application ?

La problématique : Les sondes se placent sur une JVM ou sur un serveur PHP qui sont tous les deux susceptibles de faire tourner plusieurs applications. Par ailleurs, si on crée dans l’interface Nudge de multiples applications, chacune est dotée d’un token particulier. Comment peut-on alors obtenir le monitoring de ces applications séparément les unes des autres.

Cas du PHP :

La documentation en ligne invite à spécifier le paramètre nudge.apps dans le fichier nudge.ini sous la forme [document root path]:[token]. En fait ce paramètre permet de spécifier tout un mapping de root path avec des tokens variés d’applications simplement à l’aide du séparateur ",".

Ainsi il est assez facile en PHP de répondre à ce besoin simplement en utilisant le paramètre de cette manière : [app1 document root path]:[app1 token],[app2 document root path]:[app2 token],…

Cas du Java :

Dans cette description, on part sur l’hypothèse que les transactions possèdent dans leur code une caractéristique qui permet de reconnaitre l’application à laquelle elle appartient.

C’est le cas notamment dans les applications web de type JEE avec le chemin de contexte qui figure dans les URL des transactions.

Il faut avoir à l’esprit que les données brutes (rawdata) produites par la sonde Java contiennent toutes les transactions qui ont tournées sur la JVM.

Le principe de cette solution est de faire en sorte que les informations de monitoring soient envoyées à la plateforme Nudge “en rateau” vers plusieurs applications qui feront le tri de leur côté pour ne prendre en compte que les transactions qui correspondent à telle ou telle application.

Étape 1 :

Côté sonde, l’envoi des données en rateau.

La sonde est dotée d’une option qui permet d’écrite les données sur disque : handlers=file dans nudge.properties.

Après écriture des données sur disque, on peut aisément les publier sur le portail Nudge par une simple commande curl de ce type : curl -X PUT --data-binary @{rawdata_file} https://collector.nudge-apm.com/collect/rawdata/{app_token}

Ainsi, lorsqu’un rawdata est produit, un simple script exécuté toutes les minutes peut se charger de consommer les fichiers disponibles et les publier sur le portail nudge à destination de l’ensemble des tokens d’applications concernées.

Étape 2 :

Côté portail, le filtrage des transactions pour chaque appli.

Suite à l’étape 1, par défaut l’ensemble des transactions vont être considérées par chaque application.

Il faut alors appliquer des filtres pour chacune d’entre elle pour ne retenir que celles qui concernent telle ou telle appli.

Les filtres peuvent être configurés dans l’écran de paramétrage de l’application, onglet “Filtres”.

Dans le cas d’une appli web JEE, les applications peuvent être reconnues par le début du code de la transaction il faut alors définir un filtre qui exclue toutes les autres.

Si par exemple on a une application dont le chemin de contexte est /application/, l’expression régulière du périmètre d’exclusion est le suivant : ^(?!/application/).*$

Serveur/APP/JVM

Un agent est déployé pour un serveur (1 jvm) , donc s’il y a plusieurs serveurs (plusieurs JVM), faut-il installer autant d’agent que de JVM ?

Oui, aujourd’hui un agent ne peut scruter qu’une instance de serveur.

Nous pouvons vous aider à automatiser l’installation des sondes sur vos instances de serveur si le cas se présente.

Dans le cas où le serveur d’application est installé sur une VM, a-t-on des informations sur la VM, par exemple : charge CPU, consommation mémoire… ?

La sonde Java ne remonte pas d’information système.

Mais une autre sonde dédiée au monitoring système est à votre disposition sur Nudge APM.

L’agent installé est-il capable de capter tout les événements qui arrivent y compris les appels javascripts ?

Non, l’agent ne capte que ce qui passe par le serveur, les traitements qui ont lieu au niveau du client ne sont pas attrapés.

En revanche, il est possible d’avoir les temps de réponses coté client (navigateur) en activant l’option prévue à cet effet (désactivée par défaut).

Comment se comporte la sonde dans le cas d’un serveur d’applications hébergeant plusieurs applications ?

Une sonde remonte les infos sur une JVM/instance de serveur.

Toutes les applications déployées sur le serveur apparaitront donc sous la même application défini dans le dashboard Nudge APM.

Y-a-t-il un paramétrage spécifique de la JVM pour l’utilisation de la sonde ?

Le paramétrage de la JVM nessecite uniquement l’ajoute du “-javaagent” (voir Guide de démarrage)

Dashboard Nudge

Quelle est la fréquence de rafraichissement des informations sur le dashboard ?

La sonde envoie des infos toutes les minutes, toutes les informations sont analysées et donc mises à disposition en temps réel.

Quel est la période d’historique des données enregistrées par la sonde ?

Les données sont sauvegardées durant 3 mois. Si cette période n’est pas suffisante, prenez contact avec le service commercial.

Quels sont les seuils par défaut de l’APDEX?

Seuil satisfaisant à 5 secondes et tolérable à 10 secondes.

Concernant les flux de données, qu’est ce qui est envoyé au dashboard ?

Les noms de méthodes, heure début, heure fin. Aucune données fonctionnelles ou métiers n’est transmise au serveur.

Elles sont systématiquement anonymisées par défaut.

(Il est possible dans le fichier properties de désactiver cette option dans certains cas de figure nécessitant un diagnostic fin).

Pourquoi la colonne nommée “ligne” (dans le profiling des transactions) affiche la valeur -1 ?

Il existe trois causes possibles :

• La compilation de votre application a été effectuée sans mode debug (par défaut, la compilation est en mode debug). Hors mode debug, l’information de la ligne de code n’est pas disponible.

• La librairie concernée par cette portion de code n’a pas été compilée en mode debug.

• La portion de code concernée a été élaborée dynamiquement (par exemple par instrumentation java) et n’est donc pas liée au code source de l’application.

Pourquoi la colonne nommée “ligne” (dans le profiling des transactions) affiche la valeur -2 ?

Cela correspond à un appel à du code natif, non Java.

Sur mon dashboard, je n’ai aucune donnée dans l’onglet “Navigateur” ?

Il faut vérifier le paramètre activate_rum=trueAPI REST dans le fichier properties qui par défaut est à false et qui signifie que l’on ne remonte pas les informations lié au client web (navigateur).

L’activation du paramètre “activate_rum=true” a-t-il un impact sur les performances de mon application ?

Les temps de réponse sont calculés par le navigateur avec ou sans ce paramètre.

L’activation de celui-ci positionne un cookie qui est envoyé à la sonde qui le relaye au dashboard Nudge.

Il fait appel à des mécanismes standard liés au navigateur et la seule contrainte sur le navigateur est que le navigateur doit supporter HTML5.

L’option est inoffensive pour l’affichage de la page.

J’ai une transaction avec le nom: “/” à quoi cela correspond ?

A la homepage de l’application supervisée par Nudge APM.

Pourquoi est-ce que je ne parviens pas à suivre la trace d’un WS entre deux applications ?

Lorsque deux applications interagissent par HTTP, un focus sur un appel à un WS sous jacent permet de visualiser le traitement dans l’application cible (l’interface bascule alors automatiquement de l’application appelante vers l’application appelée).

Pour assurer cette traçabilité, la sonde Nudge utilise le protocole HTTP : elle surcharge les requêtes en ajoutant un header.

Dans certains cas de figure, notamment en cas d’usage d’ESB ou de reverse proxy, il arrive que le message HTTP d’origine soit altéré en cours de route. Le cas échéant, il faut configurer le composant intermédiaire pour qu’il propage correctement le headers en question : NUDGE_TOKEN.

API REST

Que restitue l’API REST par rapport aux informations qui sont sur le dashboard ?

Toutes les informations qui présentent sur le dashboard sont accessibles via l’API REST à l’exception des liens entre les méthodes dans les transactions.

Technique

A-t-on besoin de faire des modifications dans le code source de l’application avant d’installer la sonde ?

Non, aucune modification n’est requise pour instrumenter le code.

Lors d’appel JNI, les infos sont-elles remontées ?

Non, on perd la trace des appels c’est une limitation inhérente à la technologie Java.

D’une manière générale, le code Java est exécuté par la JVM donc visible par la sonde.

Le code JNI est exécuté par le CPU directement donc non visible par la JVM.

Existe-t-il une liste exhaustive des types d’applications que l’on peut monitorer ?

La sonde Nudge APM fonctionne sur n’importe quelle type d’application Java.

Mais elle est dotée de mécanismes de détection automatiques de certaines technologies liées notamment JEE.

Dans d’autres cas de figure, certains paramétrages sont parfois nécessaires pour apprendre à la sonde à détecter les transactions à observer.

Possibilité d’industrialisation de la diffusion de la sonde sur les serveurs d’application ?

Nous accompagnons les clients dans la mise en oeuvre de notre solution ainsi que sur l’industrialisation des procédures de déploiement et installation.

En revanche, nous ne fournissons pas d’outils de déploiement car ces outils sont liés à l’environnement client et chaque client est maitre de ces outils.

Peut-on avoir le top10 des transactions qui consomment le plus de CPU ?

C’est la JVM qui consomme le CPU, pas les transactions, il est possible ensuite de faire des corrélations entre charge CPU consommé par la JVM et transactions qui sont passé au moment du pic de charge CPU.

Mais CPU et transactions sont deux choses indépendantes.

Est-ce que l’on peut avoir des SLA par rapport à la taille des pools de connexion en base de données, et au poids de leur utilisati

(permettant d’identifier des pools mal dimensionnés) ?**

Oui, il est possible de configurer les JMX afin de suivre les pools de connexion.

Concernant le taux de remplissage, certains pools n’exposent pas cette information, le cas échéant, il est possible de créer son propre MBean qui évalue le taux de remplissage à partir des autres informations mises à disposition par le pool.

Quelle est la fréquence de capture des photos de threads ?

Les threads sont échantillonnés toutes les secondes.

Quelle est la fréquence de capture des métriques par JMX ?

Les valeurs des attributs de Managed Bean sont observées toutes les 10 secondes.

Supports technologique

Quelles sont les bases de données supportées par la sonde ?

Toutes les bases de données sont détéctées par la sonde Nudge APM.

Sécurité

Peut-on auditer les flux ?

Oui ! Il suffit d’une simple configuration et un peu d’espace disque disponible.

L’audit nécessite deux étapes :

1. configuration de la sonde pour écrire les données sur disque

   Dans le fichier nudge.properties configurer handlers=file (ou handler=file,http pour conserver l’envoi sur Nudge), puis redémarrer l’application.

2. ouvrir les fichiers binaires “rawdata” en utilisant la sonde

   Les “fichiers bruts (raw data) sont écrits dans le répertoire log de la sonde et utilisent le format Protocol Buffers, par conséquent, il est nécessaire d’utiliser un outil pour les lire.

   Afin de les lire, nous fournissons deux outils avec la sonde :

   • une interface graphique (permet d’ouvrir plusieurs fichiers à la fois)

     java -jar nudge-x.y.z.jar -va <rawdata-files>

   • un outil en ligne de commande pour générer un format texte (un fichier à la fois)

     java -jar nudge-x.y.z.jar -pa <rawdata-file>

Remarque Importante

Par défaut, il n’y a pas de limitation sur l’occupation disque pour l’audit.

Par conséquent, vous devrez certainelement utiliser le paramètre disk_dump_max_size pour limiter le volume qui peut être utilisé pour l’audit si laissez cette option activée sur une longue période.

Que peut-on faire lorsque la connexion directe entre l’application et le portail Nudge est impossible ?

Plusieurs alternatives sont envisageables. Tout d’abord la sonde est capable de traverser un proxy. Celui est configurable à l’aide de paramètres de l’agent Java.

Ensuite, il est possible de procéder à l’envoi de données de manière asynchrone en activant l’option d’écriture des données par la sonde sur fichier puis en les déplaçant pour les envoyer à partir d’un autre emplacement capable de communiquer avec le portail Nudge.

Vous pouvez procéder à l’envoi de manière asynchrone à partir des fichiers produits par la sonde à l’aide d’une commande similaire à ceci:

curl -X PUT --data-binary @{un_fichier_protobuf} https://collector.nudge-apm.com/collect/rawdata/{un_app_id}

NB : Par la suite, pour consulter vos données sur le portail Nudge, sélectionnez la période durant correspondant aux données que vous avez envoyées.

Comment les résultats peuvent-ils être agrégés de votre coté pour une vision d’un seul applicatif ?( est ce que l’on peut démarrer l’agent plusieurs fois avec le même identifiant ?)

Oui vous pouvez utiliser le même identifiant d’1 sonde sur plusieurs JVM d’un seul applicatif pour remonter l’ensemble des données. Vous retrouverez d’ailleurs dans l’onglet “instance” le “load balancing” et des infos sur chaque JVM.

De même dans certain cas dans l’environnement de production plusieurs applications sont hébergées sur le même serveur, l’agent étant lié au démarrage de la jvm, pourrons nous avoir une vision par applicatif ?( filtre ? …)

Pour plusieurs applications sur 1 serveur, nos clients mettent en place des filtres pour identifier chaque application.

Vous trouverez dans le site de documentation plus d’explications pour les mettre en place.

Le plus simple est de filtrer les transactions par application.

Dans le cas d’une appli web, il s’agit de distinguer les transactions des applications par un préfixe d’url, par exemple.

Controles d’accès

Toutes ces questions sont relatives à un compte.
Et les ressources évoquées ne sont disponibles que pour les administrateurs de compte.

Est-il possible d’avoir une synthèse de tous les droits ?

Il existe une ressource d’API qui fournit la liste complète des droits d’accès sur l’ensemble des applications d’un compte. L’api REST est disponible en cliquant sur le button API une fois connecté à l’interface PH-Nudge APM

• URI : GET /api/accounts/{account-id}/appsAcl

Est-il possible de dupliquer les droits d’une utilisateur pour un autre utilisateur?

Lorsqu’un nouvel utilisateur rejoint votre société, vous aurez peut-être besoin de lui attribuer les mêmes droits que l’un de ses collègues.
Le cas échéant, uen ressource d’API vous permet de copier intégralement les droits d’une utilisateur vers un autre utilisateur. L’api REST est disponible en cliquant sur le button API une fois connecté à l’interface PH-Nudge APM

• URI : POST /api/accounts/{account-id}/accessCopy

Pour utiliser cette ressource, vous devez fournir un message JSON qui contient à la fois le login de l’utilisateur source et également de l’utilisateur de destination tel que celui-ci :

{
    "source_user_login":"user1@cie.tld",
    "target_user_login":"user2@cie.tld"
}

Est-il possible de révoquer tous les droits d’un utilisateur d’un seul coup ?

Lorsque quelqu’un quitte votre société ou bien change de poste, vous devez révoquer tous les accès qui lui ont été préalablement attribués.
L’api REST est disponible en cliquant sur le button API une fois connecté à l’interface PH-Nudge APM Vous pouvez effectuer cette opérations à l’aide d’une seule ressource de l’API :

• URI : POST /api/accounts/{account-id}/accessRevoke

Un message JSON doit être fourni à la ressources contenant le login de l’utilisateur à révoquer tel que celui-ci :

{
    "user_login":"user@cie.tld"
}