Discussion :

[chiappero]

Bonjour,

Je suis actuellement en stage dans une equipe de developpement et ma tâche est de venir plugger une API sur leurs softwares, mon API doit être indépendante et dans l'absolu devrait pouvoir fonctionner sur tout les outils en java.
Mes connaissances sont limitées et j'aimerais savoir comment monitorer, ou mettre en place des observers sur un logiciel externe.
Le but serait de récuperer les données d'utilisation pour voir comment leurs logiciels sont utilisés et quelles fonctionalités doivent être mises en avant.

[joel.drigo]

Salut,

Peut-être pourrais-tu commencer par regarder :

• Monitoring and management for the Java Platform
• ...using the JMX API

[Pill_S]

Sinon, il y a sûrement quelques autres pistes qui pourraient être utiles, en fonction du besoin réel...

JProfiler: permet de s'attacher à une vm en cours d'exécution (à chaud) et peut permettre de voir 1) le temps passé dans chaque bout de code 2) le nombre d'invocations 3) l'état de la mémoire (à la base, c'est un outil de profiling/débuggage, mais ça peut s'utiliser aussi comme analyseur d'utilisation, mais attention au surcout lié à la collecte d'une telle masse d'informations)
EclEmma: à la base, un outil de couverture de code, qui possède un agent java à installer sur les serveurs d'applis: http://www.eclemma.org/jacoco/trunk/doc/agent.html (pourra indiquer du code mort, ie, du code non-exécuté, mais pas le nombre d'itérations)
DynaTrace: le top du top mais très cher, une fois configuré, permet de suivre l'exécution d'une action utilisateur dans toutes les couches, jusqu'à la base de données... mais encore une fois, c'est un outil de diagnostiques, et pas de statistiques
Takipi: https://www.takipi.com/ semble proche de dynatrace en terme de fonctionnalités, mais bcp moins cher voir gratuit

Tout ça c'était pour aider au diagnostique et mettre en évidence les fonctionnalités non utilisées. Si tu veux plutôt des statistiques (en mode web), tu as:
Webtrends: pour collecter des statistiques d'utilisation d'un site web en analysant le contenu du fichier access.log d'Apache
Google Analytics: un peu comme webtrends, mais gratuit... les données sont également moins protégées, car stockées chez Google (bin voui, c'est pas gratuit pour rien...)

[chiappero]

Merci de vos réponses, j'ai encore beaucoup de questions ! Comment est-ce que vous vous y prendrez pour mettre en place une API qui récupère les stats d'utilisation de logiciels ?

[Pill_S]

Il faut commencer par faire un choix... en fonction des besoins (et ça c'est à toi de voir)

Commence peut-être par expliquer le genre d'indicateurs dont tu as besoin...

[chiappero]

Il me faudrait récupérer un maximum d'info :
Le nom du logiciel ( l'api doit fonctionner sur plusieurs logiciels )
La version du logiciel
le timestamp( pas un problème )
L'ip !!
Le nom d'utilisateur
CPU Size
OS
System type ( 32 ou 64 )
Language
Region
Time Zone
Country

ça c'est "le minimum"
Je dois aussi definir le "type" d'evenement ( comme un click boutton un click "save" un click sur une entity etc... mais aussi la fonction invoquée) et a chaque fois envoyer ces infos en bdd

[Pill_S]

Ok, pas dit que tu puisses faire ce que tu veux avec les technos précitées... même si un simple webtrends peut déjà donner beaucoup d'infos (et souvent, cela suffit largement), cela ne permettra pas de descendre au niveau des différentes briques de code.

Tu utilises spring et/ou aspectj? Si oui, alors il suffit peut-être d'attacher un aspect sur les beans à monitorer, aspect qui s'occupera de sauver en base tout ce qui est nécessaire. ça à l'avantage d'être non-intrusif (un peu de config et aucune modif du code) et désactivable sans recompilation (via des configs xml). En plus, tu as la main sur tous les détails d'implémentation...

Mais pour cracher des stats bien formattées et tout, faudra implémenter ça à la main...

PS: dans le fameux aspect que tu devras développer, tu peux peut-être t'appuyer sur un custom appender d'un framework à choix: ex. tu dis à log4j ou logback, de sauver les messages de logs dans une db http://logback.qos.ch/manual/appenders.html ça aura également comme avantage de fournir toute la puissance du framework en question, ie, dans logback, tu peux afficher des infos sur la requête http à la source, et donc, des infos sur l'utilisateur et son contexte...

[joel.drigo]

CPU Size
OS
System type ( 32 ou 64 )

C'est des données système ça : pas besoin d'espionner un logiciel. ça se lit dans les System.getProperties()...

Language
Region
Time Zone
Country

Lequel ? Quand ? Parce que j'ai 4 langages actuellement sur ma configuration, et je peux en changer quand je veux. Par contre s'il y a une gestion interne à l'application de la locale, tu as un peu près autant de manière qu'on peut imaginer de le gérer... il faudrait presque analyser le source des classes pour voir où on utilise une instance de Locale (et encore, si c'est la classe standard qui est utilisée), mais ça ne veut pas forcément dire qu'on y gère une locale utilisateur...( il y'a même des applications qui gèrent plusieurs locales à la fois... avec des formulaires multilangues par exemple). A mon avis c'est utopique de vouloir gérer ça automatiquement (sans un minimum de description qui va dire "ton espion doit aller regarder là pour savoir la locale).

Il me faudrait récupérer un maximum d'info :
Le nom du logiciel ( l'api doit fonctionner sur plusieurs logiciels )
La version du logiciel

Là, c'est pareil : il y a autant de façon de gérer ça que de façon de l'imaginer : ce n'est pas standard... ça risque pas d'être automatique

L'ip !!

L'ip de quoi ? Du poste local ? Pas besoin d'espionner un logiciel pour ça : c'est une information système. L'ip distante sur laquelle l'application se connecte à distance : globalement, c'est pareil que pour le nom du logiciel, quoiqu'on pourrait se dire qu'on peut reconnaître si URLConnection, ou httpclient par exemple, est utilisé, alors on pourrait chercher à savoir ou la donnée pourrait être passé, en sniffant peut-être, mais en pratique ça me semble complètement utopique de le gérer en automatique...

Le nom d'utilisateur

system properties user.name éventuellement. Mais sinon, si un utilisateur gérée en interne par l'application, c'est pas standard non plus...

ça c'est "le minimum"
Je dois aussi definir le "type" d'evenement ( comme un click boutton un click "save" un click sur une entity etc... mais aussi la fonction invoquée) et a chaque fois envoyer ces infos en bdd

ça c'est plus envisageable.

Par monitoring, j'entendais plutôt :

• savoir le nombre d'instances créées par classe
• les temps d'exécution
• le nombre de thread lancés
• la mémoire occupée par telle ou telle classe
• etc...

Maintenant déterminer génériquement à partir des classes d'une application quelconque ce que font fonctionnellement ces classes sans passer par un descriptif établi (qui dit telle classe fait ça, tel bouton fait ça... etc...), ou préparer l'application pour ça (ce que je fais personnellement), ça me semble infaisable.
A mon avis, tu devrais plutôt envisager de décrire dans l'application, par annotation par exemple, cette méthode doit être espionnée, et je veux compter le nombre d'appel, en stockant tel paramètre... etc...)

[chiappero]

Tu utilises spring et/ou aspectj?

> Je n'ai pas encore attaqué la prog, je suis a l'étape d'étude du projet, c'est pourquoi il ya surement es incohérences et des questions vagues.
Pour les logiciels sur lequell l'api doit s'appliquer je n'ai que très peu d'infos

joel.drigo >
L'application devra tourner coté client, pour savoir quel utilisation les tilisateurs font des logiciels qu'on leur fourni

A mon avis, tu devrais plutôt envisager de décrire dans l'application, par annotation par exemple, cette méthode doit être espionnée, et je veux compter le nombre d'appel, en stockant tel paramètre... etc...)

ça pourrait être envisable mais ça consisterais a limiter l'api a un seul logiciel dont on connait par coeur le fonctionnement ? Si c'est le cas je vais être limité par ma connaissance du logiciel et ça sort du cahier des charges puisque je suis censé faire une API pour trois logiciels différents, mais si il s'agit de la seule solution je devrais être capable de leur faire comprendre

[joel.drigo]

ça pourrait être envisable mais ça consisterais a limiter l'api a un seul logiciel dont on connait par coeur le fonctionnement ? Si c'est le cas je vais être limité par ma connaissance du logiciel et ça sort du cahier des charges puisque je suis censé faire une API pour trois logiciels différents, mais si il s'agit de la seule solution je devrais être capable de leur faire comprendre

Non, au contraire, mais ça oblige celui qui fait l'application à espionner à mettre des marqueurs dedans. Tu ne pourras pas espionner n'importe quelle application comme ça. Après, les annotations (ou la programmation orienté aspect également) c'est un moyen simple de le faire pour celui qui programme : mais on peut faire un système qui marche avec les annoations d'un côté, et qui permet de décrire dans un fichier xml par exemple, la même chose qu'on fait avec les annotations, pour pouvoir traiter un programme qui n'a pas été écrit à la base pour ça. Maintenant, il y a des choses beaucoup moins facile à faire (comme récupérer des paramètres), et puis il faut quand même comprendre ce que fait un peut chaque classe, chaque méthode, chaque paramètre, donc connaitre l'application. De tout manière ça me parait complètement utopique autrement : genre j'ai une application de gestion de stock, et je veux comme stat "le nombre de fois que chaque vendeur à consulter une fichier produit", ou "La moyenne du nombre d'impressions par heure, par produit", juste comme ça à partir d'une hiérarchie de classes, en automatique... je voudrais bien voir ça tourner...

[Pill_S]

> Je n'ai pas encore attaqué la prog, je suis a l'étape d'étude du projet, c'est pourquoi il ya surement es incohérences et des questions vagues.

oui je m'en doute mais les applis à espionner, elle sont spring-aware?

avant de pouvoir choisir le meilleur outil, il faut justement une définition précise du scope et des besoins. Si tu es springifié, c'est très facile d'intégrer un nouvel aspect à l'appli, c'est non intrusif, très rapide à implémenter, ça peut permettre de faire exactement ce que tu veux, avec la souplesse voulue (voir même plus...) bref, techniquement, c'est vraiment une option à envisager... et ça ne te limite pas du tout à une seule appli, c'est même plutôt le contraire: tu peux greffer ton aspect de façon déclarative sur tout bean spring via un bout de config...

si par contre tu n'as que du code impératif standard, pas de container d'inversion de contrôle ni d'injection de dépendances, va falloir greffer ton espion manuellement partout où tu en as besoin... donc niveau souplesse, on est à raz des pâquerettes...

ou alors, s'appuyer sur d'autres mécanismes (eg. webtrends, encore une fois, c'est vraiment une option à envisager, ça peut permettre de sortir plein de chiffres sans même avoir à modifier quoi que ce soit des applis existantes)

[chiappero]

J'ai dis "espionner" mais c'est peut être un grand mot, je pense juste à recuperer les statistiques d'utilisations, quels fonctionalités sont utiles etc ça pourrait permettre de mieux comprendre les besoins de l'utilisateur
"mais ça oblige celui qui fait l'application à espionner à mettre des marqueurs dedans"
>je ne pourrais pas faire ça hélasJe ne pourrais pas toucher aux logiciels a etudier

Si tu es springifié, c'est très facile d'intégrer un nouvel aspect à l'appli
> je ne pourrais pas "integrer" aux logiciels qu'on souhaite étudier, l'API doit être indépendante.

[chiappero]

Webtrends a l'air pas mal, t'en ait tu éjà servi ?

[chiappero]

Mon but final serait d'obtenir quelque chose qui se raproche de ça https://www.eclipse.org/org/usagedata/index.php qui existe déjà pour Eclipse, mais dont le source n'est pas dispo.
J'ai cet example que j'ai trouvé qui a l'air de s'en rapprocher https://code.google.com/p/usagestatistic/source/browse/ mais je ne peux pas savoir si il rempli bien sa fonction.

[Pill_S]

>je ne pourrais pas faire ça hélasJe ne pourrais pas toucher aux logiciels a etudier

> je ne pourrais pas "integrer" aux logiciels qu'on souhaite étudier, l'API doit être indépendante.

LOL bin là ça va grandement limiter les options, si tu ne peux absolument rien toucher aux applis... Reste quoi, à part webtrends ou autres analyseurs de logs...?

Sinon webtrends, même si je n'ai jamais eu à m'en servir, c'est ce qu'on a utilisé dans mon service pendant des années... J'ai déjà vu des rapports et je connais les socles techniques, mais jamais fait de mise en oeuvre...

PS: ton outil googlecode là, tu ne pourras pas l'intégrer sans modifier les applis existantes (cf. https://code.google.com/p/usagestati...ainWindow.java, c'est à toi d'invoquer manuellement le logger - us.log), donc c'est laaaaargement moins configurable et plus intrusif que l'option via aspects...

[chiappero]

LOL bin là ça va grandement limiter les options, si tu ne peux absolument rien toucher aux applis

Hé c'est que je suis stagiaire et que eux font leurs boulot, je suis pas censé aller gratter dedans.


Webtrends qu'est-ce que c'est et comment l'utiliser ?

[Pill_S]

Certes, personne ne te demande de le faire toi-même...

Par contre, si c'était autorisé, tu pourrais établir une procédure qui explique comment EUX devront le faire, avec une petite démo d'une appli bidon que tu codes à l'arrache... C'est pour ça qu'il faudrait des précisions sur ce qui est réellement autorisé. Rajouter un noeud xml dans un fichier de config spring + une dépendance dans un pom, ça devrait pas faire peur à beaucoup de monde et c'est facile à maitriser... Mais si on te l'interdit, alors...

Webtrends va lire le fichier access.log d'un Apache, et sortir plein de stats à partir de ça... Pour le reste, faut lire la doc...

Mais 2 contraintes: 1) ça marche que pour les applis web 2) ça marche que quand on a un proxy apache devant le serveur d'application (sinon, personne ne produira de fichier access.log et tu seras marron...)

[chiappero]

1) ça marche que pour les applis web 2) ça marche que quand on a un proxy apache devant le serveur d'application (sinon, personne ne produira de fichier access.log et tu seras marron...)

> Il s'agit de clents lourds donc pas d'applis web donc je pense pas que je pourrais le mettre en place

De plus si j'ai bien compris il va lire access.log donc ça impliquerais que chaque utilisateur soit sur apache
Je pense que je suis pas sorti de l'auberge

[Pill_S]

Ah bon bin il aurait peut-être fallu commencer par ça... Non Webtrends tu peux faire une croix dessus, aucune chance d'aboutir dans cette direction...

Etant donné que je suis plus orienté web que clients lourds, pour la suite, je vais trop pouvoir t'aider...

Si pas de spring ni aspectj, tu peux aussi laisser tomber les aspects...

Une config de logger peut-être?

[joel.drigo]

Ou quelque chose comme jamon ?