Re: EJB/MBean et consultation via un Nagios

Nicolas Delsaux <[email protected]> Fri, 21 Jan 2011 09:59:35 +0100
Newsgroups gmane.comp.java.french.general
Message-ID <[email protected]>
Si ça vous dérange pas, je vais utiliser la réponse de Jérôme pour
compléter mes questions.

2011/1/21 jerome moliere <[email protected]>
>
> Salut ma Tania -)

Toi aimer cravache sur fesses toi ? :-)

>>
>> 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 ...
>
>
> 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 ....

> 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.

>>
>> - 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 ?
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, ...

>
> 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 ?

> 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 :-)

> 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) ?
>
> 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 ;-)



--
Nicolas Delsaux