Conseils de résolution des incidents liés au plug-in de serveur Web

Les rubriques suivantes vous permettent de diagnostiquer des incidents liés aux plug-in du serveur Web.

En cas d'incident lors de l'utilisation d'un plug-in du serveur Web, procédez comme suit :

Recherchez des indices dans le fichier plugins_root/logs/nom_serveur_Web/http_plugin.log . Aidez-vous de la table de référence des messages pour décrypter les messages d'erreur ou d'avertissement éventuellement trouvés.
Consultez les journaux d'accès et d'erreurs du serveur Web afin de déterminer si une erreur est survenue dans ce dernier :
- IBM® HTTP Server et Apache: access.log et error.log.
- Serveur Web Domino : httpd-log et httpd-error.
- Sun Java™ System: access et error.
- Microsoft IIS: timedatestamp.log.

Si ces fichiers ne révèlent aucun incident, effectuez les opérations complémentaires ci-après.

Procédure d'identification des incidents du plug-in

Le plug-in dispose d'un traçage très lisible qui peut vous aider à cerner l'incident. Avec l'attribut LogLevel du fichier config/plugin-cfg.xml défini à Trace, vous pouvez suivre le traitement des requêtes pour vérifier où se situe l'incident.

Remarque: Si vous utilisez un système de fichiers Veritas avec la prise en charge des fichiers volumineux activée, des tailles de fichier pouvant atteindre deux téraoctets sont autorisées. Dans ce cas, si vous paramétrez l'attribut LogLevel dans le fichier plugin-cfg.xml sur LogLevel=Trace, le fichier risque de croître rapidement et d'utiliser tout l'espace disponible de votre système de fichiers. Vous devez par conséquent définir l'attribut LogLevel sur ERROR ou DEBUG pour éviter la saturation de l'unité centrale.

De manière générale, les choses se passent ainsi :

Le plug-in reçoit une demande.
Il vérifie les routes définies dans le fichier plugin-cfg.xml.
Il trouve le groupe du serveur.
Il trouve le serveur.
Il extrait le protocole de transport, HTTP ou HTTPS.
Il envoie la demande.
Il lit la réponse.
Il la renvoie au client.

Ce processus vous apparaît très clairement à la lecture des traces d'une demande :

La première étape consiste à déterminer si le plug-in est correctement chargé dans le serveur Web.
- Vérifiez que le fichier http_plugin.log a été créé.
- S'il l'a été, vérifiez s'il contient des messages d'erreur signalant une défaillance quelconque lors de l'initialisation du plug-in. Si aucune erreur n'est signalée, recherchez la section suivante qui confirme que le plug-in a démarré normalement. Vérifiez que les horodatages des messages correspondent à l'heure de démarrage du serveur Web :
```
[Thu Jul 11 10:59:15 2002] 0000009e 000000b1 - PLUGIN: ------------System Information---------- 
[Thu Jul 11 10:59:15 2002] 0000009e 000000b1 - PLUGIN: Bld date: Jul  3 2002, 15:35:09 
[Thu Jul 11 10:59:15 2002] 0000009e 000000b1 - PLUGIN: Web server: IIS 
[Thu Jul 11 10:59:15 2002] 0000009e 000000b1 - PLUGIN: Hostname = SWEETTJ05 
[Thu Jul 11 10:59:15 2002] 0000009e 000000b1 - PLUGIN: OS version 4.0, build 1381, 'Service Pack 6' 
[Thu Jul 11 10:59:15 2002] 0000009e 000000b1 - PLUGIN: -------------------------------------------- 
```
- Les erreurs courantes sont les suivantes :
  lib_security : loadSecurityLibrary : Echec de chargement de la bibliothèque gsk
  IBM Global Security Kit (GSKit) n'a pas été installé ou une version incorrecte de GSKit a été installée. Pour savoir quelle situation s'est produite, procédez comme suit :
  - Sur une plateforme Windows, recherchez le fichier gsk8ssl.dll
  - Sur une plateforme UNIX, recherchez les fichiers libgsk8*.so dans le répertoire /usr/lib .
  Si vous ne trouvez pas le fichier approprié, essayez de réinstaller le plug-in avec la version correcte d' IBM Global Security Kit (GSKit) pour voir si cela permet de résoudre le problème.
  ws_transport : transportInitializeSecurity : Fichier de clés non défini
  
  Le transport HTTPS défini dans le fichier de configuration a été prématurément fermé et ne contient pas les définitions de propriété du fichier de clé et du fichier stash. Vérifiez la syntaxe XML de la ligne dont le numéro est indiqué dans les messages d'erreur qui suit celui-ci pour vous assurer que l'élément Transport contient des définitions pour le fichier de clé et le fichier stash avant d'être fermé.
- Si le fichier http_plugin.log n'est pas créé, vérifiez si le journal des erreurs du serveur Web contient des messages d'erreur relatifs au plug-in indiquant le motif de l'échec du chargement du plug-in. Les causes classiques de cet échec sont notamment une configuration du plug-in inappropriée à l'environnement du serveur Web. Consultez la documentation relative à la configuration du serveur Web que vous utilisez avec le plug-in de serveur Web.
Déterminez la présence éventuelle d'incidents de connexion réseau avec le plug-in et les divers serveurs d'applications définis dans la configuration. Auquel cas le message suivant s'affiche généralement :
```
Echec de la connexion à hostname: port number (code d'erreur):message d'erreur(numéro de port local)
```
Les causes de cette erreur peuvent être multiples.
- Testez la connectivité des machines (avec ping) pour vous assurez qu'elles sont correctement connectées au réseau. Si une commande ping ne peut pas être envoyée aux machines, le plug-in n'a alors aucun moyen de les contacter. Les causes possibles de cette erreur sont les suivantes :
  - Stratégies de pare-feu qui limitent le trafic du plug-in vers le serveur d'applications.
  - Machines ne se trouvant pas sur le même réseau.
- Si vous arrivez à tester les machines avec ping, il est possible que le port ne soit pas actif. Cela peut être dû au fait que le serveur d'applications ou le cluster n'est pas démarré ou que le serveur d'applications s'est arrêté pour un motif quelconque. Pour vérifier qu'il s'agit de la cause de l'incident, vous pouvez essayer de vous connecter manuellement via Telnet au port sur lequel la connexion échoue. Si vous n'y parvenez pas, cela signifie que le serveur d'applications n'est pas actif et que vous devez résoudre l'incident pour que le plug-in puisse se connecter.
Déterminez si une autre activité sur les machines où sont installés les serveurs porte atteinte à la capacité du serveur à servir une demande. Vérifiez l'utilisation du processeur selon les critères du gestionnaire de tâches, de l'ID de processeur ou de tout autre outil externe pour savoir si cette utilisation :
- n'est pas conforme aux attentes,
- est irrégulière au lieu d'être constante,
- montre qu'un nouveau membre ajouté du groupe n'est pas utilisé,
- montre qu'un membre défaillant réparé n'est pas utilisé.
Recherchez l'état du serveur dans la console d'administration.
Vérifiez dans la console d'administration que le serveur d'applications est démarré. Consultez les messages d'erreur dans la console d'administration ou consultez les journaux JVM.
Dans la console d'administration, sélectionnez le serveur d'applications en erreur et vérifiez si ses applications installées sont démarrées.

Si cela ne suffit pas pour résoudre votre incident :

Pour les problèmes spécifiques qui peuvent entraîner l'affichage des pages Web et de leur contenu, voirLa ressource Web (fichier JSP, servlet, fichier html, image, etc.) ne s'affiche pas dans la documentation.
Vérifiez si l'incident a été identifié et documenté à l'aide des liens de la rubrique Diagnostics et résolution des incidents: Ressources d'apprentissage.
Si vous ne trouvez pas de problème similaire au vôtre, ou si les informations fournies ne permettent pas de résoudre votre problème, contactez le support IBM pour obtenir de l'aide.

Modification du comportement lorsque le serveur Web utilise un transfert non sécurisé

Si des transferts sécurisés et non sécurisés sont définis et qu'un transfert sécurisé ne peut pas être obtenu en raison d'une panne du système, le plug-in du serveur Web utilise un transfert non sécurisé. Il s'agit du comportement par défaut.

Ce comportement a été modifié dans WebSphere Application Server version 8.5.5. Si une panne du système se produit lors de la tentative d'une connexion sécurisée et que le transfert n'est pas sécurisé, le plug-in du serveur Web n'utilise pas ce transfert. L'administrateur est averti de ce problème et peut le corriger à l'aide de connexions sécurisées.

3 options permettent à l'administrateur de résoudre ce problème :

Corriger le problème SSL de sorte que le transport HTTPS soit disponible (option recommandée).
Retirer le transport HTTPS si SSL n'est pas utilisé et régénérer le plug-in.
Définir UseInsecure=true dans le fichier plugin-cfg.xml pour rétablir le comportement par défaut précédent.

Si vous préférez revenir au comportement par défaut précédent, vous pouvez l'activer en définissant une propriété personnalisée sur la console d'administration. Sélectionnez Webserver > <nom_serveur_Web> > Propriétés du plug-in > Propriétés personnalisées, puis définissez UseInsecure sur true.

Pour obtenir des informations à jour disponibles auprès du support IBM sur les problèmes connus et leur résolution, voir les rubriques suivantes sur la page de support IBM . Avant d'ouvrir une PMR, consultez ces pages car elles contiennent des documents qui peuvent vous faire gagner du temps dans la collecte des informations nécessaires pour résoudre un incident.

Les rubriques suivantes de la page de support IBM peuvent également vous être utiles: