Cette section décrit les problèmes connus de la Monitoring Console et du cadre de contrôle. Le cadre de contrôle, composant partagé installé automatiquement avec les autres composants, réalise les tâches de contrôle.
Les patchs suivants sont nécessaires à la prévention de certains problèmes connus du cadre de contrôle. Ces patchs sont en général fournis en standard avec les autres patchs requis pour Java ES ou avec les versions mises à jour du système d'exploitation Solaris. Toutefois, vous devez vérifier que ces patchs ou des patchs de remplacement sont présents sur tous les hôtes qui serviront à contrôler un composant de produit Java ES :
Tableau 1 Patchs de contrôle pour le système d'exploitation Solaris
Version de Solaris |
Numéro de correctif |
---|---|
Solaris 9 sur plate-forme Sparc (jusqu'à la version s9u7_06 incluse) |
114344-17 |
Solaris 9 sur plate-forme i386 (jusqu'à la version s9u7_06 incluse) |
114345-08 (remplacée par : 117172-17), 118559-28 (ou version ultérieure) |
Solaris 10 sur plate-forme Sparc (jusqu'à la version s10_58 incluse) |
114344-17 |
Solaris 10 sur plate-forme i386 (jusqu'à la version s10_58 incluse) |
114345-08 (remplacée par : 117172-17), 118855-15 (ou version ultérieure) |
Pour le système d'exploitation HP-UX, les patchs requis pour le contrôle sont fournis avec ceux décrits à la section Conditions requises pour HP-UX et problèmes connexes.
Lorsque vous ajoutez un nouvel hôte à contrôler, la Monitoring Console utilise le protocole SSL pour sécuriser la connexion mais n'affiche pas le certificat présenté par l'hôte sélectionné. Etant donné que la Monitoring Console transmet le mot de passe root de l'hôte à l'agent du noeud, le système devient vulnérable aux attaques lorsque l'adresse IP de l'hôte concerné est créée et le mot de passe reçu. Le risque est toutefois très faible car la plupart des agents de noeud sont exécutés sur des hôtes installés sur un réseau sécurisé.
Solution Si le réseau des hôtes d'agent du noeud n'est pas sécurisé, vous devez les authentifier avant de les ajouter à la Monitoring Console en tant que nouveaux hôtes. Pour authentifier un hôte, connectez-vous à celui-ci et vérifiez que vous reconnaissez sa configuration et son système de fichiers. Dans le cas d'un hôte UNIX, vous pouvez vous connecter à l'aide de la commande ssh afin d'afficher les informations relatives au certificat.
Les objets contenus dans un produit sont référencés dans la Monitoring Console en tant que serveurs d'applications.Il ne faut pas confondre ce terme et Sun Java System Serveur d'application.
Solution Dans le cadre de la Monitoring Console, un serveur d'application signigie l'instance en cours d'exécution d'un composant Java ES installé.
Dans certains cas, l'affichage et le changement de pages dans la Monitoring Console peut prendre jusqu'à 30 secondes.
Solution Exécutez Monitoring Console sur un hôte puissant sans aucune autre application.
La Monitoring Console ne peut pas activer ou désactiver le contrôle d'un composant spécifique.
Solution Vous devez utiliser le système d'activation et de désactivation propre au composant concerné. Pour obtenir des instructions, reportez-vous aux sections correspondantes du Chapitre 2, Enabling and Configuring the Monitoring Framework du Sun Java Enterprise System 5 Update 1 Monitoring Guide.
Lorsqu'un composant contrôlé s'arrête brutalement ou normalement, il se peut que les objets contrôlés ne soient pas supprimés de l'agent du noeud et demeurent dans l'arborescence de gauche de la console de contrôle. De même, si vous arrêtez un agent du noeud entier, il se peut que le noeud d'hôte ne soit pas supprimé de l'arborescence de gauche. Ce problème survient par intervalle.
Solution Lorsque vous arrêtez ou redémarrez une instance de serveur, redémarrez l'agent du noeud, l'agent maître et la console de contrôle. Si vous arrêtez un hôte et son agent du noeud, vous devrez peut-être redémarrer l'agent maître et la console de contrôle. La procédure To Restart a Node Agent du Sun Java Enterprise System 5 Update 1 Monitoring Guide décrit les deux procédures de démarrage.
Lorsqu'un hôte est supprimé de la Monitoring Console, les règles et alarmes de contrôle associées aux composants contrôlés ne sont pas automatiquement effacées. Ceci permet de conserver les états de règles et alarmes au cas où vous ajouteriez de nouveau le même hôte.
Solution Si vous n'avez pas l'intention d'ajouter de nouveau l'hôte en question, utilisez la boîte de dialogue des règles pour rechercher puis supprimer toutes les règles associées à cet hôte. Les alarmes existant au moment de la suppression de l'hôte sont peut-être reconnues, mais ne sont pas supprimées de la console de contrôle car l'attribut contrôlé ayant déclenché l'alarme n'est plus accessible. Pour éviter que les alarmes ne restent dans un état reconnu, résolvez toutes les alarmes de composant contrôlé et reconnaissez ces alarmes sur la console de contrôle avant de supprimer l'hôte.
Si l'intervalle de planification est configuré pour une règle, vous ne pouvez pas désactiver la règle.
Solution Au lieu de la désactiver, supprimez la règle.
La liste suivante répertorie les autres problèmes connus de la Monitoring Console.
Par défaut, les tableaux ne sont pas triés
L'hôte lié à partir de l'option Objects Using This Installed Product (Objets utilisant ce produit installé) ne doit pas être un objet inconnu
Lors de l'utilisation du plugin AppServer, les objets contenus dans ce serveur ne doivent pas inclure les enfants de leurs enfants
L'activation et la désactivation ne fonctionnent pas correctement dans le tableau des hôtes
Les champs de légende et de description s'affichent pour les objets de statistiques et de paramètres, mais non pour les objets de base
L'utilisateur ne devrait pas avoir à recliquer sur un objet lorsqu'il sélectionne celui-ci et clique sur Monitoring Rule->New (Règle de contrôle->Créer)
Le nom des objets JVM répertoriés pour un hôte donné ne sont pas cohérents
Les objets CMM_Cluster créés par Application Server ne s'affichent nulle part
La liste des objets visibles dans la boîte de dialogue de création d'une règle n'est pas claire
Les objets Portal Server, Web Server et Application Server affichent un état d'objet et opérationnel inconnu
Les noms des composants Enterprise Java Beans déployés sur Serveur d'application devraient être plus descriptifs
Les noms des attributs des objets de contrôle Serveur d'application sont impossibles à utiliser
Les modifications de configuration Serveur d'application internes ne sont pas reflétées sur la console de contrôle
Monitoring Console devrait pouvoir exposer une vue de domaine.
Dans l'environnement linguistique allemand, l'index de l'Aide en ligne ne correspond pas à la version anglaise.
La fonction Show Objects With Status (Afficher l'état des objets) est inaccessible lorsque l'option Show Selected Object (Afficher l'objet sélectionné) est activée.
Échec du retrait des intervalles de planification d'une règle accompagné d'une erreur de script.
Certaines chaînes ne sont pas localisées dans la table JVM-General.
Dans l'interface utilisateur espagnole, la chaîne de copyright n'est pas localisée.
De nombreuses chaînes ne sont pas localisées dans l'interface utilisateur de Monitoring Console.
La modification de l'intervalle de planification d'une règle en vue de passer de 0:00 à 0:00 a pour effet de supprimer la règle.
Les composants dont l'interfaçage avec le cadre de contrôle repose sur des bibliothèques C risquent de s'afficher plus lentement dans la Monitoring Console lorsqu'ils sont exécutés sur un système d'exploitation Linux.
Solution Aucune.
La communication interprocessus entre les composants reposant sur des bibliothèques C et l'agent du noeud sur le même hôte n'est pas sécurisée. Par défaut, la communication utilise l'interface de loopback, ce qui réduit les risques liés à la sécurité.
Solution Aucune.
Les composants dont l'interfaçage avec le cadre de contrôle repose sur des bibliothèques Java risquent de rencontrer des problèmes de performances lors d'un accès via SNMP.
Solution Aucune.
En raison d'un bogue sur Solaris 9, les paquets envoyés à une adresse IPv4 ne sont pas délivrés au listener sur un socket IPv6. Ceci interrompt le mécanisme de détection entre les agents de noeud et les composants à contrôler sur l'hôte.
Solution Forcez le JVM de l'agent du noeud à écouter les sockets IPv4 à l'aide des commandes suivantes :
cacaoadm stop oldvalue=`cacaoadm get-param java-flags --value` cacaoadm set-param java-flags="${oldvalue} -Djava.net.preferIPv4Stack=true" |
Redémarrez ensuite l'agent du nœud, l'agent principal et la console de contrôle en suivant la procédure To Restart a Node Agent du Sun Java Enterprise System 5 Update 1 Monitoring Guide.
Si les horloges des hôtes de l'agent du noeud et de l'agent maître sont asynchrones, l'ajout de ce noeud sur la Monitoring Console échoue. Le journal des erreurs de cadre de contrôle de l'agent maître signale une erreur grave pendant la tentative de connexion JRMP.”
Solution Réglez les horloges des deux hôtes de sorte qu'elles soient synchrones.
Lorsqu'il existe un nombre trop important de règles de contrôle concurrentes sur un agent du noeud exécuté sur un système d'exploitation HP-UX, le nombre d'unités d'exécution de JVM (Java Virtual Machine) risque de dépasser la limite de paramètre de noyau et de générer une exception de type OutOfMemory.
Solution Téléchargez, puis exécutez l'outil HPjconfig, tel que décrit dans la procédure To Optimize Kernel Parameters for Monitoring Framework on HP-UX du Sun Java Enterprise System 5 Update 1 Monitoring Guide.
Lorsque vous exécutez la commande mfwkadm sous Windows, l'erreur suivante est générée :
'C:\Program' is not recognized as an internal or external command, operable program or batch file. |
Solution Placez en commentaire la quatrième ligne du fichier C:\Program Files\Sun\JavaES5\share\mfwk\bin\masetup.bat en ajoutant REM au début de la ligne.
Avant : |
|
|
Après : |
|
La liste suivante dresse la liste des autres problèmes connus concernant Monitoring Framework.
Sous Linux, la détection n'a pas lieu lorsque IPv6 est activé.