Re: EJB/MBean et consultation via un Nagios

Le 21 janvier 2011 09:59, Nicolas Delsaux <[email protected]> a
écrit :

> Si ça vous dérange pas, je vais utiliser la réponse de Jérôme pour
> compléter mes questions.
>
>
utilises mon gars, utilises..;

> 2011/1/21 jerome moliere <[email protected]>
> >
> > Salut ma Tania -)
>
> Toi aimer cravache sur fesses toi ? :-)
>
>
humm tentante proposition -)

> >>
> >> je vais bientôt entamer le développement d'une web-app susceptible
> >> d'être déployée sur un cluster Glassfish (ou JBoss) éventuellement
> >> hébergé chez Amazon.
> >
> > courage à toi
> > may the force be with you...il faudrait choisir vite entre les 2 car le
> support du clustering n'a pas du tout les mêmes implications ...
> > et il te faudra avoir des instances amazon quine partent pas en cachuète
> ..
>
> A priori, notre choix s'oriente assez clairement vers Glassfish, pour
> des raisons assez basiques d'implémentation de référence JEE 6 ...
> >
>

choix rasionnable à cet égard...

>  >
> > oula le jeune padawan est en plein délire ...
> > alors les MIBs standard s: il n'y en a pas
> > Jboss dispose d'une MIB proprio payante ...
> > GF n'en dispose pas à mes dernières infos...
>
> Donc on n'a pas moyen de récupérer des informations "simples" sur
> Glassfish ? Genre la quantité de RAM utilisée, l'uptime, la liste des
> jars chargés ....
>
>
si tu peux mais tu as 2 solutions :
- soit implémenter ta propre MIb , ASN1 quand tu nous tiens ..
- soit tu balances des traps SNMP directes (plus simples)  mais pas
réellement idéal d'un point de vue perf et va nécessiter d'agglomérer plein
de datas..

> > pour s'intégrer avec quel tool SNMP ? Patrol / Nagios/ Tivoli/ openView
>  ...
>
> On n'a pas encore pris de décision là-dessus. Cependant, si tu poses
> la question, c'est sans doute qu'il y a des subtilités, non ? A
> priori, on serait parti vers Nagios, mais on est encore assez ouverts.
>
> beinh Nagios dispose d'un moteur de polling pourri, donc si c'est Nagios
qui vient chercher les infos par le SNMP Adaptor sur ton GF3 ca va coûter
cher et tu devras surement avoir une fréquence de polling assez basse (et
donc pas faire du super management)


> >>
> >> - associer des MBeans à des EJBs (par exemple)
> >
> > un Mbean c'est une interface + 1 implémentation  t'encapsules ce que tu
> veux dedans , donc tu fais généralement de la délégation dans ton impl et
> redirige vers le Bean à manager ...
>
> OK, donc si mon EJB implémente, en plus de ses interfaces locales et
> remote, une interface de MBean, je peux y accéder depuis ma console
> JMX, c'est ça ?
>

oui en effet , moi je préfère dissocier impl du bean et du mbean pour des
raisons de filtrage (une sorte de décorateur) mais bon c'est kif kif

> Puisque d'autres m'ont posé la question, je ne sais pas encore
> précisément quel type d'information devra être retourné. Sachez
> simplement que, par exemple, on souhaite pouvoir piloter via ces EJBs
> des instances d'InDesign serveur pour produire des très beaux PDFs. Et
> que du coup il faut pouvoir dire si l'EJB (et donc son InDesign
> serveur associé) est occupé à produire un document, combien de pages
> il produit à l'heure, ...
>
>
je vois en effet t'es dans le bon use case -)

>  >
> > si t'es dans GF aucun souci rien à faire de spécial avec un JDK 1.6 (mis
> à part les 2 switches classiques à passer à Java)
>
> Arf. C'est pas positionné par défaut dans les scripts de lancement de
> Glassfish ?
>
>
hummm j'ai pas vérifié..

> > si t'es dans Jboss c'est le bordel avec les versions 4, 5.0 et 5.1 c'est
> 3 configurations différentes et foireuses..
>
> Toi, t'as toujours su donner envie d'utiliser les produits :-)
>
>
si tu regardes le sujet dans le wiki Jboss tu verras que je n'ai même pas
arrangé la vision des choses ..c'est réellement du n'importe quoi ce sujet
dans Jboss

> > le souci est qu'en gros Jboss embarque un serveur de Mbean (instance de
> MBeanServer) et qu'il le peuple avec ses entrées
> > Or la console JMX exploite le serveur de Mbeeans présent par défaut dans
> la plate-forme Java et bingo tu as trouvé c'est pas le même...
> >
>
> Cela dit, le monitoring local n'est qu'un début.
>
> >
> > alors là courage Jedi ...
>
> Ah ?
> j'imaginais que, dans la mesure où passer du JMX au SNMP semble
> possible, il "tait de la même manière possible d'envoyer ces
> informations à distance. Manifestement, t'es pas d'accord. Alors du
> coup, je me pose une question.
>
> Supposons que je sois une grosse entreprise, avec des paquets de
> serveurs JEE. Comment je fais pour les monitorer correctement (genre
> savoir si ils ont reçu la nouvelle version de mon application par
> hot-deploy, tout ça) ?
>

hot deploy ? interdit en prod partout...
avec GF3 et son implémentation OSGi tu peux mettre en place de l'OBR ou du
File Install Felix et cela se passera bien..avec Jboss et sa merde
d'UnifiedClassLoader je ne le ferai pas

> >
> > rien d'existant tout à construire à la main..supervision métier en
> agglomérant des indicateurs techniques pour faire basculer du vert au rouge
> tes indicateurs métier.....
>
> Dans le monde Java, il y a encore des trucs qui ne sont pas faits ? Je
> suis surpris ;-)
>
>
> bah c'est pas vraiment dans le monde Java le problème...

Jerome

>
> --
> Nicolas Delsaux
>



-- 
J.MOLIERE - Mentor/J
auteur Eyrolles