Données de performances Request metrics

Utilisez cette page pour apprendre à interpréter les données de performance de Request Metrics au format des enregistrements de trace.

[AIX Solaris HP-UX Linux Windows][z/OS]Les enregistrements de trace des données request metrics sont écrits dans deux fichiers journaux : le fichier journal des plug-ins du serveur Web et le fichier journal du serveur d'applications. Les noms par défaut des fichiers journaux sont SystemOut.log et http_plugin.log. Cependant, voue avez la possibilité de leur donner un nom différent et de les placer dans un répertoire personnalisé. Les répertoires par défaut de ces fichiers journaux sont les suivants :
  • [AIX Solaris HP-UX Linux Windows][z/OS]plugin_install_root/logs/web_server_name/http_plugin.log et install_root/profiles/profile_name/logs/server_name
  • [IBM i]plugin_install_root/logs/web_server_name/http_plugin.log et profile_root/logs/server_name
et
Dans le fichier journal de WebSphere Application Server, le format des enregistrements de trace est le suivant :
PMRM0003I: parent:ver=n,ip=n.n.n.n,time=nnnnnnnnnn,pid=nnnn,reqid=nnnnnn,event=nnnn 
- current:ver=n,ip=n.n.n.n,time=nnnnnnnnnn,pid=nnnn,reqid=nnnnnn,event=nnnn 
           type=TTT detail=some_detail_information elapsed=nnnn
Dans le fichier journal du plug-in de serveur Web, le format des enregistrements de trace est le suivant :
PLUGIN:
parent:ver=n,ip=n.n.n.n,time=nnnnnnnnnn,pid=nnnn,reqid=nnnnnn,event=nnnn 
- current:ver=n,ip=n.n.n.n,time=nnnnnnnnnn,pid=nnnn,reqid=nnnnnn,event=nnnn 
           type=TTT detail=some_detail_information elapsed=nnnn bytesIn=nnnn 
           bytesOut=nnnn

Le format d'enregistrement de trace est constitué des deux corrélateurs suivants : corrélateur parent et corrélateur en cours. Le corrélateur parent représente la demande en amont et le corrélateur en cours l'opération en cours. Si les corrélateurs parent et en cours sont identiques, l'enregistrement représente une opération qui se produit lorsqu'elle est entrée dans WebSphere Application Server.

Pour corréler des enregistrements de trace pour une demande particulière, collectez les enregistrements dont l'ID message est PMRM0003I à partir des fichiers journaux de serveur d'applications appropriés ainsi que les enregistrements de trace PLUGIN à partir du fichier journal de plug-in de serveur Web. Les enregistrements sont corrélés via la correspondance des corrélateurs en cours aux corrélateurs parent. L'arborescence logique peut être créée en connectant les corrélateurs en cours des enregistrements de trace parent avec les corrélateurs parent des enregistrements enfant. Cette arborescence montre la progression de la demande dans le cluster de serveurs. Consultez la rubrique Utilité de Request Metrics qui propose un exemple de flux de transactions.

Le corrélateur parent est indiqué à l'aide des zones séparées par des virgules, qui suivent le mot clé parent:. De même, le corrélateur en cours est indiqué à l'aide des zones séparées par des virgules, qui suivent le mot clé current:.

Les zones des deux corrélateurs (parent et en cours) sont les suivantes :
  • ver : Version du corrélateur. Par souci de commodité, elle est dupliquée dans les deux corrélateurs (parent et en cours).
  • ip : Adresse IP du noeud du serveur d'applications qui a généré le corrélateur. Si le système possède plusieurs adresses IP, request metrics utilise l'une d'elles pour identifier le système.
  • pid : ID processus du serveur d'applications qui a généré le corrélateur.
  • time : Heure de début du processus du serveur d'applications qui a généré le corrélateur.
  • reqid: ID attribué à la requête par request metrics, spécifique au processus du serveur d'applications.
  • event : ID événement attribué pour différencier les événements de trace réels.
Les informations qui suivent les corrélateurs parent et en cours sont les données de l'opération chronométrée :
  • type : Code représentant le type d'opération en cours de chronométrage. Les types prise en charge incluent HTTP, URI, EJB, JDBC, JMS, COMMONJ_WORK_POOLED, COMMONJ_TIMER, demandeur de services Web et fournisseur de services Web.
  • detail : Identifie le nom de l'opération en cours de chronométrage (voir la description d'URI (Universal Resource Identifier), HTTP, EJB, JDBCJ, JMS, les beans asynchrones et les services Web).
  • elapsed : la durée de mesure a expiré dans <units> pour cette opération, ce qui inclut toutes les sous-opérations appelées par cette opération. L'unité de temps est la milliseconde.
  • bytesIn : Nombre d'octets de la demande reçue par le plug-in de serveur Web.
  • bytesOut : Nombre d'octets de la réponse envoyée par le plug-in de serveur Web au client.
Voici la description des zones de type et de détails :
  • HTTP : Le plug-in de serveur Web génère l'enregistrement de trace. Le détail est le nom de l'URI utilisé pour appeler la requête.
  • URI : L'enregistrement de trace est généré par un composant Web. L'URI est le nom de l'URI utilisé pour appeler la requête.
  • EJB : Nom complet de package et de méthode du bean enterprise.
  • JDBC : Nom de l'interface et nom de la méthode pour cet appel JDBC.
  • JMS : JMS inclut certains paramètres JMS.
  • Beans asynchrones : Le détail indique le nom des beans asynchrones. Les beans asynchrones sont de deux types : COMMONJ_WORK_POOLED et COMMONJ_TIMER.
  • Services Web : Les services Web incluent les options de certains paramètres de service Web. Les services Web sont de l'un ou l'autre type : demandeur de services Web ou fournisseur de services Web.
  • SIB : Utilisé pour l'instrumentation dans le bus d'intégration de services, p. ex : envoi/réception de messages et médiation.
  • JCA : Architecture J2EE Connector. Le détail spécifie le nom de classe dans lequel l'appel JCA est effectué.
  • JNDI : Utilisé pour la recherche de nom JNDI. Le détail indique le nom JNDI.
  • Envoi/Réception JMS : Génère l'enregistrement de trace grâce à l'envoi/réception JMS de messages.
  • Envoi/Réception SIB : Génère l'enregistrement de trace grâce à l'envoi/réception SIB de messages.

[z/OS]Lorsqu'il existe plusieurs régions servantes pour un serveur d'applications, il existe plusieurs fichiers SystemOut.log, un pour chaque région servante. Par conséquent, request metrics peuvent consigner les enregistrements de trace dans plusieurs fichiers SystemOut.log. La région servante qui gère une demande consigne les enregistrements correspondants dans ses fichiers SystemOut.log. L'ID processus (PID) des mesures de demande actuelles correspond au PID de la région servante associée. Si le système possède plusieurs adresses IP, l'IP du corrélateur peut être l'une d'elles, mais elle doit utiliser la même adresse IP pour la même région servante.

Remarque : Cette rubrique fait référence à un ou plusieurs des fichiers journaux de serveur d'applications. Il est recommandé de configurer le serveur de telle sorte qu'il utilise l'infrastructure de journalisation et de trace HPEL (High Performance Extensible Logging) à la place des fichiers SystemOut.log, SystemErr.log, trace.log et activity.log sur les systèmes distribués et IBM® i. Vous pouvez également utiliser HPEL conjointement avec vos fonctions de journalisation z/OS natives. Si vous utilisez l'infrastructure HPEL, vous pouvez accéder à toutes les informations de journalisation et de trace en utilisant l'outil de ligne de commande LogViewer à partir de votre répertoire bin de profil de serveur. Pour plus d'informations sur l'utilisation de HPEL, voir les informations sur l'utilisation de HPEL en vue du traitement des incidents liés aux applications.

Icône indiquant le type de rubrique Rubrique de référence



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rprf_tracerecord
Nom du fichier : rprf_tracerecord.html