Version imprimable
D'après ce que j'ai compris sur JAMon corrigez moi si je me trompe
Il a tout autant besoin d'être intégré au logiciel a monitorer ex :
import com.jamonapi.*;
...
double myValue=...
MonitorFactory.add("myBytesSentLabel", "MB", myValue); // units can be any string, and myValue can be any numeric
malgrès ça il a l'air sympa et pratique ( il se rapproche un peu du source que j'ai linké tout a l'heure )
Phil_S > Désolé de ne pas avoir précisé plus tôt, qu'est-ce que tu entends par config de logger ?
Le myvalue tu pourrais le récupérer via JMX... dans une application à part, sans intrusion dans le code source d'origine. Attention, je ne dis pas que ce n'est pas un boulot de ouf, mais en théorie c'est faisable.Citation:
Envoyé par chiappero
la plupart des applis utilisent déjà des loggers (log4j, logback, etc.). Dans les librairies de log, tu peux la plupart du temps déclarer des appenders personnalisés que tu peux ensuite configurer dans ton appli. donc créer un appender "MonitoringAppender" qui fera soit de la délégation vers jamon soit une implémentation customCitation:
Envoyé par chiappero
ça 1) ne change pas le code et 2) ça permet de faire ce qu'on veut...
Mais si tu as un gestionnaire d'aspects à disposition, c'est très très très (très) largement à préférer...
PS: +1 pour jamon, je connaissais pas mais ça semble bien correspondre au besoin. je garde dans un coin de ma tête, dans la case "boîte à outils" :)
Pour moi les loggers sont totalement inconnu encore, il s'agirait de modifier les librairies de log ( si le code du programme a etudier utilise des loggers ) et ajouter en gros un appel a mon API ?
Ou se trouvent ces librairies, est-ce que ça implique de modifier des fichiers chez chaque utilisateur ?
Qu'est-ce qu'un gestionnaire d'aspec ?
Attention, je ne dis pas que ce n'est pas un boulot de ouf, mais en théorie c'est faisable.
> je dispose d'environ 2 mois , c'est réalisable ou une perte de temps ?
+1 pour l'analyse de log : c'est justement ce que je suis en train de faire, mais :
- c'est un boulot de ouf (enfin faut voir ce qu'on chercher à obtenir comme statistiques : moi je cherche à obtenir des cycles de vie d'objets, avec les actions utilsateurs, croisées sur plusieurs logs client)
- les logs sont faits souvent pour être lus par des humains, moins par des programmes : donc, en ce qui me concerne, c'est un boulot de ouf à coup de parsing, de regexp, de traitements en tout genre (genre diff text, diff xml, etc...), multi-passes (pour reconstituer des évènements liés fonctionnellement, etc, pour retrouver non seulement les actions sur les objets (CRUD) mais également les liens entre les objets pour reconstiuer des sous-grappes du modèle. Ce qui me permet d'obtenir des trucs du genre, pour le résumé :
Counters - Count of Security check: 19 - Count of Accepted: 5 - Count of Denied: 14 - Count of Lock deleted: 387 - Count of Notification change: 877 - Count of WXML changes: 310 - Count of WXML Fields changes: 30 - Count of WXML Field added: 12 - Count of WXML Field removed: 17 - Count of WXML Field name change: 1 - Count of WXML Field move from box to another: 0 - Count of WXML Tags changes: 37 - Count of WXML Field tag added: 28 - Count of WXML Field tag removed: 7 - Count of WXML Field tag updated: 2 - Count of WXML Content changes: 243 - Count of WXML Field flat text changed: 167 - Count of WXML Field html text changed: 243
J'aurais aussi besoin des actions utilisateur, quels bouttons ils utilisent, quels menu ils cliquent, quels fonctionalités ils appellent etc...
Dans un premier temps j'aimerais que ce soit possible de pouvoir detecter un demarrage du logiciel ( par exemple en interceptant le nom du process je pense ) pour savoir si il est lancé et pouvoir envoyer ces infos au server
Par rapport a ce dernier point j'ai une autre question, est-ce qu'il est possible que le service qui tourne et detecte le lancement d'un programme soit mis en place de manière a ne pas avoir un process intrusif qui tourne dés le demarrage de windows ?
J'ai tourné dans le code source de Jamon https://github.com/stevensouza/jamon...a/com/jamonapi
C'est un vraie usigne a gas
J'arrive pas a en saisir le fonctionnement
J'aimerais beaucoup réutiliser ce code et l'adapater a mon cas précis d'utilisation
Attention : par les logs on obtient que ce qui est dans les logs : et si peut loguer certaines actions (ou plutôt commandes en réalité), personnellement je logue jamais des notions d'UI : une commande peut être lancée d'un bouton, d'un menu, par une autre commande, par un script, etc...[.QUOTE]Citation:
Envoyé par chiappero
Bah soit il est démarré en même temps que le logiciel (en modifiant, si c'est possible, ce qui est loin d'être sûr, la commande lancement du logiciel (j'espère qu'on parle bien toujours de logiciel Java au moins). Soit il est démarré en tâche de fond. Je ne vois pas comment il pourrait détecter ou faire quoique ce soit en général s'il n'est pas démarré.Citation:
Envoyé par chiappero
Ça dépend du volume de données à traiter et du volume de données à produire. Ça dépend également de ta maîtrise des technologies employées pour faire l'analyse mais aussi des technologies à analyser (et du fonctionnel). Par contre, quelque soit les réponses à ces questions, ça me semble totalement utopique de faire un programme générique non intrusif qui extrait des statistiques de n'importe quel logiciel Java, même sans dormir pendant 2 mois. Surtout si tu ignores complètement ce qu'il y a actuellement dans les logs : ça veut dire que tu ne connais pas le logiciel. A mon avis, c'est casse-gueule comme projet, en 2 mois qui plus est. Extraire des statistiques techniques de performances, ou de chemins d'appel, avec des programmes d'analyse existant, peut-être. Des statistiques fonctionnelles (CRUD), ou d'usage de l'UI, je ne me lancerais pas sans avoir vu l'application et sans connaitre son fonctionnel.Citation:
Envoyé par chiappero
Merci beaucoup de vos réponses je réalise que j'en demande beaucoup et que je ne suis pas très clair.
Pour les logs ça m'a l'air d'être une vraie galère, est-ce que dans ton cas ça tourne efficacement coté utilisateur ?
Je te confirme qu'on parle uniquement de java, autant pour l'API que j'aurais a réaliser que pour les logiciels a analyser
" ça me semble totalement utopique de faire un programme générique non intrusif qui extrait des statistiques de n'importe quel logiciel Java "
Petit bémol sur le non-intrusif : je n'ai pas de restricition a ce sujet ( si ce n'est la loi )
voici ce qui est ecrit dans mon cahier des charges : The Telemetry API is generic, and must be usable on future tools
Donc surement qu'ils ont vu un peu grand a ce sujet ! Surtout que si un logiciel de la sorte etait possible et efficace j'immagine qu'il aurait été commercialisé depuis longtemps.
Même si ça semble hors de portée je compte en faire le plus possible et du mieux que je peux !
Vu que c'est bien plus compliqué que prévu je pense que je vais d'abord m'attaquer a envoyer un relevé au lancement d'un des programmes ciblés, je comprend que le service ne pourra rien faire si il n'est pas démarré ;) mais c'est un peu contraignant de le faire tourner h24 en tache de fond et peut sembler un peu envahissant pour l'utilisateur ( je suis pas sur que ça plaira ) et vu que je suis restreint je ne pourrais pas modifier la commande lancement du logiciel pour que le service soit lancé a ce moment là, une astuce pour le lancer efficacement ?
Dans ce contexte, intrusif="avec modif des applications à monitorer"Citation:
Envoyé par chiappero
Ce n'est pas temps réel : je collecte les logs et je les analyse ailleurs. Pour le temps réel, j'ai des sondes, qu'on peut activer (par configuration serveur) au besoin dans le soft lui-même : mais c'est pareil, l'analyse des données obtenues est faite ailleurs, et en temps différés.Citation:
Envoyé par chiappero
Oui, comme le dit @Pill_s, par "non intrusif", je parlais bien de ne pas modifier le code de l'application à analyser.Citation:
Envoyé par chiappero
Enfin, en général, quand on analyse le fonctionnement de logiciel, on fait des sessions d'analyse : on analyse pas en continu tout le temps. Donc on démarre l'application d'analyse, puis on démarre l'application à analyser. Si tu as une application qui n'arrête pas de capter des informations dans une autre et qui fait sans arrêt des I/O pour les stocker (locales ou même réseau), tu vas forcément perturber le fonctionnement du système (occuper de la mémoire, consommer du cpu, bloquer des I/O). On voit ce que ça donne avec les antivirus sur les serveurs de fichiers...Citation:
Envoyé par chiappero
Le problème c'est qu'on ne va pas fonctionner en "session d'analyse" le but est de collecter les données de l'usage qui en est fait par les utilisateurs pour pouvoir indiquer aux developpeurs l'usage qui est fait de chacunes des fonctionalités qu'ils ont mise si un truc est souvent utilisé ou si quelque chose est ignorée par les utilisateurs, ça devrait leur prermettre de mieux adapter les fonctionalités qu'ils offrent aux utilisateurs pour correspondre a leurs attentes.
Déclencher des sessions d'analyse ça poserait surement un problème de contrôle a distance de chaque API de collecte de données sur chaque poste utilisateurs ( on parle de logiciels qui sont vendus et donc qui peuvent se trouver partout dans le monde ) en plus de poser divers problème de mise en place les données relevées seraients alors moins révélante de l'usage qu'ils ont du logiciel puisque ce serait sur des periodes determinées.
On avait déjà plus ou moins accepté que forcément l'API allait consomer de la memoire et du CPU .
Les ntivirus peuvent être un problème
Je ne comprends pas ce qui leur pose problème à introduire une couche logiciel pour ça dans leur applicatif alors. C'est que fait Eclipse : si on peut avoir des stats, c'est parce que le framework intègre cette fonctionnalité (à commencer par sa couche évènementielle, sa couche de services, ses API standards ( commandes, vues, éditeurs, contextes, etc)...). Quand quelqu'un fait une application RCP, il bénéficie de tout le support, ce qui impose d'utiliser le framework évidemment.
+1, je comprend pas non plus... on veut pouvoir faire des stats sur n'importe quoi mais sans changer le code?? faut appeler Harry Potter là, c'est plus de l'informatique ça...Citation:
Envoyé par joel.drigo
En plus basé sur des aspects, c'est rapide, sans risque, puissant, etc...
Pour l'analyse des données ça ne devra pas se faire en temps réel
Y'a quand même un truc qui me surprend quand même dans cette argumentation. S'il y a une application qui tourne sur le poste en tâche de fond, d'un utilisateur lambda, pour analyser une autre application :Citation:
Envoyé par chiappero
- de deux choses l'une soit elle est installée à l'insu de l'utilisateur
- soit elle installée au su de l'utilisateur
Dans le second cas, elle ne sera pas installée. Ou très peu. Parce l'utilisateur final se fout du bon plaisir des développeurs et de leur besoin, surtout si pour le faire ça consomme des ressources.
Dans le premier, au pire ça s'appelle un spyware, et au mieux, c'est comme tous ces résidents qui tournent pour chercher s'il existe une mise à jour pour leur soft : ces programmes sont gênants pour beaucoup, mais sont peu pénalisants parce qu'il font du polling avec une période élevée, donc gênants oui, mais pas souvent. Là, le résident va sans arrêt tourner pour chercher à voir si on ne démarre pas le logiciel X... (j'ai pleins d'applications que j'utilise une fois l'an, ça me gonflerait qu'elles tournent en continu le reste de l'année - la dernière qui m'a fait le coup, un client vpn à la c... n'est pas restée très longtemps sur mon poste... une fois j'ai eu le login qui s'est ouvert au milieu de mon écran au démarrage du poste, pas 2). Pourquoi ne pas le lancer avec le logiciel X ? Le contraire est absurde, à mon humble avis. C'est une fonctionnalité du logiciel X : il doit faire partie du logiciel X. Et dans le logiciel X, il y a à l'installation, une boite à cocher (obligatoire cnil) qui dit "Aider nous à collecter des informations pour nous aider à améliorer le service", que les utilisateurs cochent ou pas. Ou mieux à chaque envoi de lot de données.
Après, qu'il s'agisse d'une API indépendante, avec quelques ponts (hooks, aspects, annotations, fabriques légèrement modifiées, etc...) dans l'application de base pour ne pas avoir à réécrire 15 millions de lignes de code, je veux bien (en espérant que l'application repose sur un framework cohérent, même maison). Mais je ne vois pas en quoi ça gène le système de collecte dans l'application. Sauf les anciennes versions qui ne l'auront pas... et alors ?
A un moment donné ou un autre, tu va devoir te brancher sur les applis que tu veux monitorer. Après, il faut qu'on sache pour t'aider quelles sont tes possibilités et le but final:
Fournir un outil d'aide aux développeurs de l'applications? Dans ce cas on peux envisager des fichiers de configurations spécifiques à l'application à tester et l'ajout de librairies pendant le test
Fournir un outil à l'administrateur d'une machine / à un boss pour savoir comment ses employés se comportent
Que peux tu faire?
1) Interagir sur la ligne de commande java => On peux envisager d'injecter un Agent ou de brancher une application type "profiler" qui sonderait à intervalle régulier l'état de l'application
2) Interagir sur le processus de compilation => On peut envisager de manipuler le compilateur pour injecter des points de surveillance
3) interagir avec les sources => On peut envisager des annotations du style "surveille moi"
Autre....
Je réagit à retardement, pas vu la deuxième page de messages :)
Vu tes contraintes qui semblent être, si j'ai bien compris, "fournir un outil ne nécessitant pas de changer le code du developpeur, pouvant être intégré à la distribution, permettant de connaitre l'usage du logiciel", je travaillerai avec des aspects, avec aspectj par exemple. Ton agent serait responsable de demander l'autorisation à l'utilisateur, de collecter l'information et de la transmettre, le développeur serait responsable d'ajouter cet aspect dans la ligne de commande de lancement de l'app et de créer un fichier de configuration précisant les méthodes et / ou packages à surveiller (pour que ton aspet connaisse ses pointcut), la fréquence d'échantillonage pour l'envoi, etc.
A noter que tu ne pourra pas surveiller toutes les méthodes. La surveillance complète c'est ce que fait un outil de mensure de couverture de test unitaire, et ça à un cout, ça ralentit toutes ces mesures.
Il a dit qu'ils ne voulaient pas faire ça.Citation:
Envoyé par tchize_
En plus, ils voudraient qu'en plus l'agent soit générique : qu'il puisse fonctionner avec n'importe quelle application Java. On peut faire ça avec les aspects ? Il faut bien les accrocher quelque part non ? ou alors on les accroche sur toutes les méthodes, et on teste dans l'aspect si on est sur une méthode qui a été indiquée comme à surveiller dans le fichier de config. Mais là on plombe à mort l'exécution, non ?
Et je vois difficilement comment gérer la notion de sens des paramètres (je veux dire qu'avec certains types on peut peut-être déterminer le sens d'un paramètre (si c'est une action SWING, possible), mais sur la plupart, c'est impossible, sans avoir des fichiers de configuration très complets : du coup, au lieu de faire ça dans le code, on fait ça dans des fichiers de configuration... c'est sûr qu'on ne modifie pas le code, mais bon, où est le gain ? Si le but est que ça tourne en continu sur tous les postes je veux dire...
Avec presque toutes, on a des soucis avec les bootclassloader non standard si on n'a pas fait le weaving durant la compilation desdites classes. On aura des soucis avec les sandbox, avec les jvm ne supportant pas les aspets (des vieux vieux trucs) et éventuellement des conflits avec d'autres aspect sont possibles, à gérer au cas par cas.Citation:
Envoyé par joel.drigo
Les pointcut peuvent être dynamique dans les aspect. J'ai pas la notation sous la main, mais on a au boulot un aspet de loging, on le configure au runtime pour préciser les méthodes qu'on veut mesurer. Par contre, les pointcut doivent être connu au moment du chargement de la classe. Après c'est trop tard je pense. Donc, oui, l'aspect peut lire une fichier de config et créer ses pointcut en fonction.Citation:
Envoyé par joel.drigo
Ca ne plombera pas non plus les perfs cette partie dynamique, car au final la configuration n'interviens qu'au moment du loadClass(), par au moment de l'appel de la méthode. Bien sur si le dev met qu'il veux tout surveiller sur tous les packages y compris les librairies qu'il importe, il se tire une balle dans le pieds, mais un dev aussi con, selon moi, il peut directement se tirer la balle dans la tête, ça fera du bien à tout le monde :aie:
Là effectivement tu limite. En même temps t'as pas besoin de savoir que Machin$1.actionPerformed ça signifie que l'utilisateur veux afficher la boite "about". Par contre, il est intéressant de savoir que la méthode définie à la ligne 273 du fichier Machin.java n'a été utilisé que par moins de 0.01% des exécutions du programme. On est dans la phase d'exploitation des statistiques, c'est une problématique indépendante. On pourrait envisager d'afficher une colonne supplémentaire dans l'ide, via un plugin, qui affiche ces statistiques par exemple. Ou mettre une couleur de fond +- sombre en fonction de l'importance de la méthode.Citation:
Envoyé par joel.drigo
L'aspect, ou n'importe quel outil d'ailleurs, a comme boulot de réculoter de la donnée brute, l'exploitation doit être faite à part, ne serait-ce que pour pouvoir réexploiter plus tard d'ancienne données et pour ne pas tuer les perfs.