© Copyright International Business Machines Corporation 2000, 2006. All rights reserved. US Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
1.0 Analyseur de journaux et de traces
1.1 Vues
1.1.1 Problèmes avec les fonctions de filtrage et de mise en évidence dans la
vue Journal
1.2 Importation de journaux
1.2.1 Problèmes d'importation de fichiers journaux distants
1.2.2 Importation de fichiers journaux sous Linux et AIX
1.2.3 Importation du fichier trace.log de WebSphere
Application Server
1.2.4 Certains fichiers journaux ne peuvent pas
être importés avec IBM Agent Controller V5
1.2.5 Exception "mémoire insuffisante" lors de l'importation de fichiers journaux et
de catalogues de symptômes volumineux
1.2.6 Les événements CBE affichés pour un journal DB2 Express Diagnostic ne respectent pas la
spécification Common Base Event
1.2.7 Aucune validation n'est effectuée par l'analyseur de journaux et de traces sur le type de fichier journal importé
1.2.8 Limitation affectant l'importation de fichiers journaux générés dans un environnement local différent
1.2.9 Echec de l'importation d'un journal d'activité WebSphere Application Server avec l'analyseur de règles à partir d'un système AIX
1.2.10 Impossible de créer une corrélation temporelle avec Apache Derby version 10.1.2.1
1.2.11 Performances en baisse lors de la création et de l'affichage de corrélations pour de grands journaux
1.3 Prise en charge de la base de données
1.3.1 L'accès simultané de plusieurs clients à la base de données avec le même compte n'est pas accepté
1.3.2 Conflits entre les chemins des ressources
1.3.3 Les préférences de support des ressources volumineuses demeurent inaccessibles malgré une sélection valide
1.3.4 Améliorer les performances du support des grands journaux
1.3.5 Redémarrer DB2 après la création d'une base de données et de ses tables
1.3.6 Exception SQL intermittente
1.3.7 Le test de connexion renvoie une erreur si vous n'avez pas appliqué les préférences
1.3.8 Expression XPath CommonBaseEvent non acceptée lors de l'analyse de grands journaux
1.3.9 Un seul contextDataElement est affiché pour les grands journaux
1.4 Autre
1.4.1 L'assistant Nouvelle corrélation de journaux
n'est pas affiché correctement sur le pilote GTK de Linux
1.4.2 Les modifications apportées au niveau de
journalisation d'un plug-in après le premier démarrage du plan de
travail ne sont pas respectées
1.4.3 Echec du plan de travail lors de la création d'un exemple sous Red Hat Linux v8.0 avec la JVM IBM
1.4.4 Seules des bases de données de symptômes au
format TPTP peuvent être créées à partir du menu contextuel et de la
barre d'outils du navigateur de journaux
1.4.5 IBM Log Analyzer ne traite que les premiers 1024 octets des messages
1.4.6 L'éditeur de symptôme génère des règles XPATH qui ne sont pas valides en cas d'utilisation d'éléments complexes
1.4.7 L'éditeur de symptôme génère des règles XPATH qui ne concordent avec aucun événement CBE d'entrée
2.0 Outil de profilage
2.1 Les vues Interactions d'agents et
Interactions de processus ne sont pas prises en charge à partir de
la vue Diagramme de séquence
2.2 La commande de régénération des vues du
navigateur de profilage ne fonctionne pas pour les interactions
de trace
2.3 Le profilage sous Windows à l'aide de Sun JDK 1.4.x peut générer un rapport d'erreurs Microsoft
Vous trouverez d'autres informations de dernière minute sur
TPTP Log and Trace Analyzer dans le document
TPTP V4.2 release notes.
Dans la vue Journal, les fonctions de filtrage et de mise en évidence ne fonctionnent pas sur les éléments complexes des événements CBE (par exemple, sourceComponentId). Un correctif sera fourni dans le prochain fix pack (groupe de correctifs).
Lors de l'importation d'un fichier distant (Fichier > Importer... > Fichier journal), aucune entrée de journal n'est affichée dans la vue Journal après la régénération des vues du moniteur de profilage (Profil > Régénérer les vues) ou une boîte de dialogue Message de journalisation indique que le client local n'a pas commencé la surveillance de l'analyseur syntaxique des journaux distants au bout de 30 secondes.
Ce problème est dû au délai d'attente du réseau et peut être résolu en augmentant la durée pendant laquelle Agent Controller attend que le client local commence la surveillance de l'analyseur syntaxique de journaux distants. Pour remédier à cette situation, essayez la procédure suivante :
<Application configuration="default" executable="RemoteLogParserLoader" extends="default" location="%SYS_TEMP_DIR%" path="%JAVA_PATH%"> ... <Parameter position="prepend" value="-Dorg.eclipse.hyades.logging.parsers.maxWaitTimeInMillis=xxxxx"/> ... </Application>xxxxx représentant le délai d'attente maximal en millisecondes (supérieur à 30000).
Certaines importations de fichier journal ne fonctionnent pas du tout sur les plateformes Linux et AIX.
Cela se produit lorsque l'utilisateur ne possède pas les droits requis pour accéder aux fichiers journaux. Pour remédier à cette situation, copiez les fichiers journaux dans le répertoire de base (home) de l'utilisateur et importez-les à partir de là.
1.2.3 Importation du fichier trace.log de WebSphere Application ServerUne corrélation interne est créée lorsqu'un fichier trace.log de WebSphere Application Server est importé.
L'utilisateur ne doit pas supprimer ces corrélations car elles contiennent les informations relatives à la structure interne de l'agent correspondant.
1.2.4 Certains fichiers journaux ne peuvent pas être importés avec IBM Agent Controller V5Les fichiers journaux distants autres que activity.log ne peuvent pas être importés lorsqu'ils proviennent d'IBM Agent Controller V5. L'instance d'IBM Agent Controller installée sur la machine distante doit être à un niveau de version supérieur ou égal à celui d'IBM Log and Trace Analyzer for Eclipse.
Pour contourner cette limitation, installez sur la machine distante la version d'IBM Agent Controller fournie avec IBM Log and Trace Analyzer for Eclipse.
1.2.5 Exception "mémoire insuffisante" lors de l'importation de fichiers journaux et de catalogues de symptômes volumineuxLes fichiers journaux et les catalogues de symptômes dont la taille ne dépasse pas 25 Mo peuvent être importés dans l'espace de travail et ouverts dans l'analyseur de journaux et de traces.
Le temps nécessaire à l'ouverture d'un fichier journal dépend du nombre d'enregistrements qu'il contient et il est possible que vous receviez une exception OutOfMemoryException (mémoire insuffisante). Pour éviter ce problème, utilisez la fonction de support des grands journaux.
Si vous recevez une exception "mémoire insuffisante" lors de l'importation de grands catalogues de symptômes, augmentez la taille du tas (heap) en ajoutant l'argument suivant :
-vmargs -Xmx1000m
Si l'utilisation de la fonction de support des grands journaux ne permet pas d'éviter l'exception "mémoire insuffisante" lors de l'importation de grands journaux, augmenter la taille du tas devrait également remédier à ce problème.
Si vous importez un journal IBM DB2(R) Express Diagnostic, les événements CBE affichés dans l'analyseur de journaux et de traces ne respectent pas entièrement la spécification Common Base Event. La raison est un bogue dans l'utilitaire db2diag.exe servant à convertir les journaux de diagnostic DB2 en événements CBE. Exception faite de ce défaut, l'opération d'importation n'est pas entravée. Il n'existe pas de solution connue tant que db2diag.exe n'est pas corrigé.
Aucune validation n'est effectuée par l'analyseur de journaux et de traces sur le type de fichier journal importé. Lors de l'importation d'un fichier journal, assurez-vous que la version et le type corrects de journal sont choisis pour le fichier importé. Si un incident se produit lors de l'importation, la vue Journal n'affiche aucun enregistrement ou comporte des enregistrements incorrects et une message d'erreur apparaît. Pour en savoir plus sur l'erreur, consultez les détails dans la boîte de dialogue d'erreur.
Lors de l'importation de fichiers journaux contenant des horodatages dans un environnement local différent de celui dans lequel est exécuté l'analyseur de journaux et de traces, l'analyseur syntaxique de journaux à base de règles n'interprète parfois pas correctement l'horodatage et d'autres données des enregistrements. Par exemple, si vous importez, dans l'analyseur de journaux et de traces exécuté sur une machine japonaise, le fichier journal des accès d'un serveur IBM HTTP Server fonctionnant dans un environnement local anglais, les valeurs creationTime des événements CBE (Common Base Events) résultants sont égales à zéro et le champ msg de ces événements est vide.
Pour éviter ce problème, lorsque vous importez un fichier journal contenant des horodatages dans un environnement local différent de celui de la machine de destination, spécifiez l'environnement local du fichier journal sous l'onglet Détails de l'assistant d'importation de journal, si un champ est prévu à cet effet.
L'importation d'un fichier binaire d'activité WAS avec l'analyseur de règles à partir d'un système AIX échoue et signale l'erreur suivante dans la fenêtre d'erreur :
IWAT0030E Une erreur s'est produite lors de l'exécution de l'analyseur de journal distant "com.ibm.etools.logging.adapter.config.StaticParserExtension" : IWAT0412E Des erreurs se sont produites lors de l'analyse syntaxique du fichier journal /home/tfoun/logs/activity.log. java.lang.Exception : IWAT0239E La commande du convertisseur a échoué : java.lang.Exception: IWAT0238E Le processus du convertisseur s'est arrêté avec la valeur de sortie 1
La commande servant à convertir le fichier journal binaire en texte afin de permettre son analyse échoue sous AIX. Pour contourner ce problème, utilisez l'analyseur statique pour importer le fichier journal d'activité binaire ou convertissez ce dernier à l'aide de l'utilitaire showlog de WAS et importez le fichier texte résultant dans l'analyseur de journaux et de traces. L'utilitaire showlog se trouve dans le sous-répertoire bin du répertoire d'installation de WAS. Par exemple, utilisez la commande suivante pour convertir le fichier journal binaire en un fichier texte appelé activity.txt :
/opt/WebSphere/AppServer/bin/showlog activity.log activity.txt
Importez ensuite activity.txt dans l'analyseur de journaux et de traces.
Bien que cela ne soit pas officiellement supporté par la plateforme TPTP, un utilisateur a tenté d'utiliser Derby 10.1.2.1 conjointement avec le support des grands journaux et a constaté le problème suivant : en tentant de créer une corrélation temporelle avec un grand journal, il a reçu une exception ArrayIndexOutOfBoundsException (index de tableau hors limites) et la corrélation s'est alors exécutée indéfiniment sans jamais aboutir. Il s'agit d'un bogue connu, propre à Derby, qui est corrigé dans la version 10.2.0.0. Pour plus d'informations, consultez la description du bogue Derby à l'adresse http://www.archivum.info/derby-dev@db.apache.org/2006-03/msg01624.html.
Notez que cette exception se produit côté serveur et n'est pas rapportée dans le plan de travail de l'utilisateur. Elle est visible dans la fenêtre de commande à partir de laquelle a été lancée la commande de démarrage du serveur Derby.
Lors de la création ou de l'affichage d'une corrélation portant sur un grand journal, une baisse de performances peut être observée avec Apache Derby et DB2.
Pour améliorer les performances, importez les journaux avec un filtre d'importation configuré de manière à exclure de la base de données les événements inutiles ou sans rapport avec ce que vous souhaitez mettre en corrélation. L'utilisation d'un filtre "Afficher uniquement les enregistrements de journaux corrélés" peut améliorer les performances à l'ouverture de la corrélation dans la vue Interactions de journaux.
L'accès simultané de plusieurs clients à la base de données peut verrouiller certaines tables. Pour les déverrouiller, redémarrez le plan de travail ainsi que le serveur de base de données.
Si vous utilisez la même base de données et le même compte d'accès pour plusieurs espaces de travail, il peut en résulter des conflits entre les chemins des ressources et, dans ce cas, ces dernières ne sont pas stockées dans la base de données.
Pour éviter ce problème, utilisez des noms de projet et de moniteur différents dans chaque espace de travail. Les ressources auront ainsi des chemins différents.
Sous Linux/GTK, sur la page de préférences Support de ressources volumineuses, les champs de paramétrage de la base de données demeurent inaccessibles même si un type valide de base de données est sélectionné.
Pour contourner ce problème, sélectionnez DB2 comme type de base de données et cliquez sur Appliquer. Fermez ensuite la boîte de dialogue Préférences et rouvrez-la. Les champs doivent alors être accessibles.
Pour améliorer les performances du support des grands journaux, exécutez la commande suivante après avoir importé de grands journaux :
db2 -tvf plugins/com.ibm.etools.ac.resources.database_x_x_x /scripts/runStatsForAllHyadesTablesDB2-8.1.sqloù x_x_x est le numéro de version figurant dans le nom du répertoire du plug-in.
Après avoir exécuté le script de création de la base de données et des tables, CreateDatabaseAndTablesDB2-8.1.sql, vous devez redémarrer DB2. Pour cela, entrez successivement les commandes db2stop et db2start dans une fenêtre de commande DB2 afin d'appliquer les modifications apportées par le script aux paramètres de configuration.
L'exception SQL suivante peut se produire occasionnellement :
com.ibm.db2.jcc.b.SQLException: NULLID.SYSSH203 0X5359534C564C3031
Face à cette situation, redémarrez le plan de travail et la base de données si vous utilisez DB2 ou Cloudscape en mode réseau. Les journaux importés lorsque cette exception se produit ne sont pas valides et devront être réimportés.
Dans la fenêtre Préférences, à la page Support de journaux volumineux de la section Profilage et consignation, si vous cliquez sur le bouton Tester la connexion avant d'avoir appliqué les modifications apportées aux paramètres, il est possible qu'une erreur de connexion soit renvoyée. Pour éviter cette erreur, cliquez sur Appliquer après toute modification des paramètres et, ensuite seulement, cliquez sur Tester la connexion.
L'expression XPath suivante n'est pas acceptée par IBM Log Analyzer lors de l'analyse de grands journaux.
<expression:xpathExpression>/CommonBaseEvent</expression:xpathExpression>
Si DB2 est utilisé pour le support des grands journaux, un seul contextDataElement par événement est affiché dans la vue Journal, même s'il existe plusieurs de ces éléments pour cet événement.
Dans l'assistant Nouvelle corrélation de journaux, seule la liste Journaux disponibles est affichée et cette liste est vide. Cela vient du fait que seule la partie de gauche de la page de l'assistant est affichée.
Pour remédier à ce problème, essayez de redimensionner la page de l'assistant pour afficher la liste Journaux sélectionnés et les boutons d'action. Vous pouvez également sélectionner les fichiers journaux à corréler dans la vue Navigateur de journaux avant de cliquer sur le bouton Nouvelle corrélation de journaux.
Si vous modifiez le niveau de journalisation d'un plug-in dans son fichier plugin.xml (via les points d'extension com.ibm.etools.common.logging.commonLoggingOptions ou com.ibm.etools.logging.util.loggingOptions) après le premier démarrage d'un plan de travail, la modification n'est pas respectée dans les lancements ultérieurs du plan de travail. Le niveau de journalisation spécifié dans le fichier plugin.xml du plug-in est stocké en cache par l'environnement d'exécution Eclipse au premier démarrage du plan de travail. Les démarrages ultérieurs du plan de travail utilisent la valeur stockée en cache comme niveau de journalisation du plug-in, en dépit de la modification du fichier plugin.xml.
Pour remédier à ce problème, redémarrez le plan de travail avec l'argument de ligne de commande -clean. Cette option vide les caches utilisés pour stocker les données de résolution des dépendances de bundles et de registre des extensions d'Eclipse, forçant ainsi Eclipse à réinitialiser ces caches. Ajoutez l'option après eclipse.exe dans le fichier <répertoire d'installation du plan de travail>\eclipse\ac.bat (Windows) ou <répertoire d'installation du plan de travail>/eclipse/ac.sh (Linux). Vous pouvez également modifier le niveau de journalisation du plug-in dans la page Préférences de journalisation (Fenêtre > Préférences > Journalisation) et redémarrer le plan de travail.
Lors de la création d'un exemple dans l'analyseur de journaux et de traces à l'aide de l'assistant de création d'exemple (Nouveau > Exemple), le plan de travail se bloque. Cela se produit lorsque l'assistant de création d'exemple essaye d'ouvrir le fichier readme.html dans le cadre de la procédure de création. Cet incident survient sous Red Hat Linux version 8.0 avec la JVM d'IBM. Il s'agit d'un bogue de SWT (https://bugs.eclipse.org/bugs/show_bug.cgi?id=76515).
Pour remédier à cet incident, essayez d'ajouter -Xj9 comme argument de JVM dans le fichier ac.sh afin de lancer le produit dans la JVM J9 d'IBM. (Par exemple, ./eclipse -vmargs -Xj9 -Xmx500m). Pour plus d'informations sur l'exécution de SWT sous Red Hat Linux v8.0, consultez le site SWT FAQ (http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-swt-home/faq.html).
Remarque : Comme indiqué dans le tableau des plateformes de référence Eclipse (http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_0.html#TargetOperatingEnvironments), seuls les systèmes Linux suivants sont pris en charge : la version 2.2.1 des outils d'objet fenêtre GTK+ et des bibliothèques associées (GLib, Pango) ; le visualiseur de fichiers HTML de SWT requiert Mozilla 1.4GTK2. Pour Motif sur les autres systèmes Linux : Open Motif 2.1 (inclus) ; le visualiseur de fichiers HTML de SWT requiert Mozilla 1.4GTK2.
En raison d'une limitation de la plateforme TPTP, les utilisateurs ne peuvent pas créer les deux types de base de données de symptômes à partir du menu contextuel et de la barre d'outils du navigateur de journaux. Une solution consiste à sélectionner Fichier > Nouveau > Autre > Profilage et journalisation sur la barre de menus du plan de travail, puis à choisir le type de base de données de symptômes à créer.
Dans les règles XPATH et les règles de corrélation IBM, la chaîne figurant dans la propriété msg d'un événement CBE (Common Base Event) ne doit pas dépasser 1024 octets. Au-delà de cette limite, l'excédent d'octets n'est pas traité par IBM Log Analyzer.
En cas d'utilisation des éléments complexes de Common Base Event (par exemple, sourceComponentID), l'éditeur de symptôme génère des règles XPATH qui ne sont pas valides. Un correctif sera fourni dans le prochain fix pack (groupe de correctifs).
Si l'un quelconque des ExtendedDataElements est sélectionné lors de la création d'une nouvelle
expression XPATH, le catalogue de symptômes résultant
contient extendedDataElement
au lieu de extendedDataElements
.
L'éditeur de symptôme génère donc des règles XPATH qui ne concordent avec aucun événement CBE d'entrée.
Les vues Interactions d'agents et Interactions de processus ne sont pas prises en charge à partir de la vue Diagramme de séquences des fichiers journaux.
Il n'existe actuellement aucune solution à ce problème.
2.2 La commande de régénération des vues du navigateur de profilage ne fonctionne pas pour les interactions de traceLa commande de régénération des vues du navigateur de profilage ne fonctionne pas pour les interactions de trace. Toutefois, ces interactions se régénèrent automatiquement à intervalle régulier.
Une solution consiste à sélectionner un autre noeud dans l'arborescence Profilage et de resélectionner le noeud précédent.
2.3 Le profilage sous Windows à l'aide de Sun JDK 1.4.x peut générer un rapport d'erreurs MicrosoftDéfaut Bugzilla : 103058
Le profilage d'une application se termine et entraîne l'affichage du message "java.exe a rencontré un problème et doit fermer. Nous vous prions de nous excuser pour le désagrément encouru." La fenêtre du message contient d'autres informations ainsi que des options vous permettant de soumettre un rapport d'erreur à Microsoft. Voir bugzilla 103058 pour consulter une capture d'écran du message.
Cet incident a été constaté dans différents modes : Analyse du délai (avec ou sans l'option d'affichage des instances), Analyse de la mémoire et lors de la combinaison des deux. Vous pouvez résoudre l'incident en exécutant à nouveau le profilage ou l'application en désactivant le compilateur JIT ; pour ce faire, entrez "-Djava.compiler=NONE" comme argument de la machine JVM. L'incident a été constaté avec SUN JDK 1.4.2_08-b03 pour Windows.