Impossible de créer une session de traçage

<ph type="x-smartling-placeholder"></ph> Vous consultez la documentation Apigee Edge.
Accédez à la page Documentation sur Apigee X. En savoir plus

Symptôme

L'utilisateur ne peut pas créer de session de trace dans l'interface utilisateur Edge.

Message d'erreur

Vous recevrez un message d'erreur dans l'interface utilisateur Edge comme indiqué ci-dessous:

Error creating trace session for API proxy <api proxy name>, revision <revision number>, environment <environment name>.
Failed to create DebugSession <session number> 

Voici la capture d'écran d'un exemple de message d'erreur observé dans l'interface utilisateur Edge:

Causes possibles :

Voici quelques-unes des causes possibles de cette erreur:

Étapes de diagnostic courantes

1. Exécutez cette API de gestion:

   curl -v <management-server-host>:8080/v1/runtime/organizations/<org-name>/environments/<env-name>/apis/<apiproxy-name>/revisions/<revision-number>/debugsessions -u <user>
   

2. Si des erreurs s'affichent, notez-les. Passez à la section Problème de connectivité réseau.

3. Si vous obtenez une réponse positive, cela signifie que la session de trace peut être créée via l'API Management. Cependant, il peut y avoir un problème possible avec l'interface utilisateur Edge, empêchant ainsi la création de la session de trace dans l'interface utilisateur. Passez à la section Problème avec l'interface utilisateur Edge.

Cause: problème de connectivité réseau

Diagnostic

1. Consultez le journal /opt/apigee/var/log/edge-management-server/logs/system.log du serveur de gestion et vérifiez si des erreurs se sont produites lors de la création de la session de trace/débogage.

   Exemple d'erreur dans le journal du serveur de gestion

   2018-02-08 09:08:21,310 org:myorg env:uat  qtp1073741635-1074 ERROR DISTRIBUTION - DebugSessionAPI.createDebugSession() : createDebugSession : Unable to connect to the server with UUID cedeabd2-e4d1-40bb-8f18-d6afc8835e5b
   org.apache.http.conn.HttpHostConnectException: Connect to 10.84.75.92:8082 [/10.84.75.92] failed: Connection refused
       at org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:140) ~[httpclient-4.3.5.jar:4.3.5]
       at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:318) ~[httpclient-4.3.5.jar:4.3.5]
       at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:363) ~[httpclient-4.3.5.jar:4.3.5]
   ...<snipped>
   Caused by: java.net.ConnectException: Connection refused
       at java.net.PlainSocketImpl.socketConnect(Native Method) ~[na:1.8.0_65]
       at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) ~[na:1.8.0_65]
   ...<snipped>
   

2. L'exemple d'erreur ci-dessus montre que nous obtenons des erreurs "Connection refused" (Connexion refusée) lorsque le serveur de gestion tente de se connecter au processeur de messages sur le port 8082. Par conséquent, le serveur de gestion ne peut pas créer la session de trace.

3. Si vous ne voyez pas d'erreur liée à la connectivité réseau ou une erreur semblable à celle présentée dans l'exemple ci-dessus, passez à Environnement non chargé sur le processeur de messages.

4. Si vous constatez une ou plusieurs erreurs liées à la connectivité réseau ou semblables à celle illustrée dans l'exemple ci-dessus, suivez les étapes ci-dessous.

5. Testez la connectivité entre le serveur de gestion et le processeur de messages sur le port 8082 en procédant comme suit:

   1. Si telnet est disponible, utilisez Telnet:

      telnet <MessageProcessor_IP> 8082
      

   2. Si telnet n'est pas disponible, utilisez netcat pour vérifier la connectivité comme suit:

      nc -vz <MessageProcessor_IP> 8082
      

   3. Si vous obtenez la réponse "Connexion refusée" ou "Expiration du délai de connexion", puis passez à l'étape suivante.

6. Connectez-vous à chacun des processeurs de messages avec l'adresse IP qui a généré l'erreur, puis procédez comme suit:

   1. Vérifiez si le processeur de messages écoute sur le port 8082:

      netstat -an | grep LISTEN | grep 8082
      

   2. Si le processeur de messages écoute sur le port 8082, passez à l'étape 7.

   3. Si le processeur de messages n'écoute pas sur le port 8082, redémarrez-le à l'aide de la commande suivante:

      /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
      

   4. Attendez que le processeur de messages ait complètement démarré à l'aide de cette commande:

      /opt/apigee/apigee-service/bin/apigee-service edge-message-processor wait_for_ready
      

   5. Une fois que le processeur de messages est opérationnel, vérifiez à nouveau qu'il écoute sur le port 8082.

   6. Si le processeur de messages écoute sur le port 8082, passez à l'étape 7.

7. Vérifiez si vous pouvez maintenant démarrer la session de trace dans l'interface utilisateur. Si le problème n'apparaît plus, ignorez les étapes ci-dessous.

8. Si le processeur de messages est en cours d'exécution et écoute sur le port 8082, mais que vous ne parvenez toujours pas à vous connecter à partir d'autres serveurs tels que le serveur de gestion, il y a probablement un pare-feu qui doit bloquer les connexions externes.

9. Utilisez la commande appropriée pour vérifier les règles de pare-feu. Par exemple, vous pouvez exécuter la commande iptables pour obtenir la liste de toutes les règles de pare-feu définies sur votre système:

   iptables -L -n
   

10. Si aucune règle de pare-feu n'est définie pour le port 8082, passez à la section High Resource Utilization Issue (Problème d'utilisation élevée des ressources).

11. Si des règles de pare-feu sont configurées sur le port 8082, passez à la section "Résolution" ci-dessous.

Solution

1. Demandez à votre administrateur réseau d'autoriser le trafic entrant/sortant sur le port 8082 depuis des serveurs externes.

Si le problème persiste, consultez Collecter des informations de diagnostic.

Cause: L'environnement n'est pas chargé sur le processeur de messages

Diagnostic

1. Consultez les journaux du serveur de gestion /opt/apigee/var/log/edge-management-server/logs/system.log et vérifiez si des erreurs se sont produites lors de la création de la session de trace/débogage.

2. Vous verrez peut-être s'afficher un message d'erreur du type "aucune réponse valide de la part du/des député(s)". lors de la création de la session de trace/débogage, comme indiqué ci-dessous:

   2018-01-30 08:28:09,721 org:mynonprod env:uat  qtp2007599722-712162 ERROR DISTRIBUTION - DebugSessionAPI.createDebugSession() : no valid responses from MP(s), throwing error
   2018-01-30 08:28:09,723 org:mynonprod env:uat  qtp2007599722-712162 ERROR REST - CustomJAXRSInvoker.performInvocation() : CustomJAXRSInvoker.performInvocation : Method com.apigee.distribution.DebugSessionAPI.createDebugSession threw an exception.
   2018-01-30 08:28:09,724 org:mynonprod env:uat  qtp2007599722-712162 ERROR REST - ExceptionMapper.toResponse() : Error occurred : Failed to create DebugSession 1517297564678
   2018-01-30 08:28:09,724 org:mynonprod env:uat  qtp2007599722-712162 ERROR REST - ExceptionMapper.toResponse() : Returning error response : ErrorResponse{errorCode = distribution.CreateDebugSessionFailed, errorMessage = Failed to create DebugSession 1517297564678}
   

   Cette erreur indique que le ou les processeurs de messages ne répondent pas au serveur de gestion pour une raison quelconque.

3. Si vous ne voyez pas d'erreur semblable à celle présentée dans l'exemple ci-dessus, passez à la section Entrées du processeur de messages non actualisées.

4. Si vous constatez une erreur semblable à celle présentée dans l'exemple ci-dessus, procédez comme suit.

5. L'une des causes les plus probables de cette erreur est que l'environnement dans lequel vous essayez de créer la session de trace n'est pas chargé sur le ou les processeurs de messages.

6. Connectez-vous à chacun des processeurs de messages et vérifiez si l'environnement spécifique dans lequel vous essayez de créer la session de trace est chargé sur le processeur de messages à l'aide de la commande ci-dessous:

   curl -s http://localhost:8082/v1/runtime/organizations/<org-name>/environments
   

   Exemple de résultat :

   Vous verrez la liste des environnements appartenant à l'organisation spécifique qui sont chargés sur le processeur de messages dans la sortie de la commande ci-dessus. Par exemple, si les environnements preprod et test sont chargés sur le processeur de messages, le résultat est le suivant:

   [ "préproduction", "test" ]

7. Si l'environnement spécifique, par exemple dev, dans lequel vous essayez de créer une session de trace, est répertorié dans la commande ci-dessus, puis passez à la section Entrées du processeur de messages obsolètes.

8. Si l'environnement spécifique, par exemple dev, ne figure pas dans la liste de la commande ci-dessus, vérifiez que /opt/apigee/var/log/edge-message-processor/logs/system.log et /opt/apigee/var/log/edge-message-processor/logs/startupruntimeerrors.log sur les processeurs de messages ne comportent aucune erreur lors du chargement des environnements.

9. De nombreuses erreurs différentes peuvent entraîner l'échec du chargement d'un environnement sur le processeur de messages. La résolution dépend de l'erreur qui s'est produite.

Solution

Il est possible que l'environnement ne soit pas chargé sur le processeur de messages pour de nombreuses raisons. Cette section présente deux raisons pouvant expliquer ce problème et explique comment le résoudre.

1. Si l'une des erreurs suivantes s'affiche dans le journal du processeur de messages, elle est due à un problème détecté avec les certificats/clés qui ont été ajoutés au keystore/truststore spécifié dans l'environnement spécifié.

   Erreur n° 1: java.security.KeyStoreException: Impossible de remplacer votre propre certificat

   2018-01-30 12:04:38,248 pool-47-thread-4 ERROR MESSAGING.RUNTIME - AbstractConfigurator.propagateEvent() : Error while handling the update for the Configurator 
   com.apigee.kernel.exceptions.spi.UncheckedException: Failed to add certificate : mycert in key store : mytruststore in environment : test
   at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:156) ~[config-entities-1.0.0.jar:na] 
   at com.apigee.entities.configurators.KeyStore.handleUpdate(KeyStore.java:101) ~[config-entities-1.0.0.jar:na] 
   at com.apigee.entities.AbstractConfigurator.propagateEvent(AbstractConfigurator.java:85) ~[config-entities-1.0.0.jar:na] 
   at com.apigee.messaging.runtime.Environment.handleUpdate(Environment.java:238) [message-processor-1.0.0.jar:na] 
   … 
   Caused by: java.security.KeyStoreException: Cannot overwrite own certificate 
   at com.sun.crypto.provider.JceKeyStore.engineSetCertificateEntry(JceKeyStore.java:355) ~[sunjce_provider.jar:1.8.0_151] 
   at java.security.KeyStore.setCertificateEntry(KeyStore.java:1201) ~[na:1.8.0_151] 
   at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:153) ~[config-entities-1.0.0.jar:na]
   ... 20 common frames omitted
   2018-01-30 12:04:38,250 pool-47-thread-4 ERROR MESSAGING.RUNTIME - AbstractConfigurator.rollbackTransaction() : Error in processing the changes : Unknown resource type cert
   

   Erreur n° 2: java.security.KeyStoreException: Impossible d'écraser la clé secrète

   2017-11-01 03:28:47,560 pool-21-thread-7 ERROR MESSAGING.RUNTIME - AbstractConfigurator.propagateEvent() : Error while handling the update for the Configurator 
   com.apigee.kernel.exceptions.spi.UncheckedException: Failed to add certificate : mstore in key store : myTruststore in environment : dev 
   at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:156) ~[config-entities-1.0.0.jar:na] 
   at com.apigee.entities.configurators.KeyStore.handleUpdate(KeyStore.java:101) ~[config-entities-1.0.0.jar:na] 
   ... 
   Caused by: java.security.KeyStoreException: Cannot overwrite secret key 
   at com.sun.crypto.provider.JceKeyStore.engineSetCertificateEntry(JceKeyStore.java:354) ~[sunjce_provider.jar:1.8.0_144] 
   at java.security.KeyStore.setCertificateEntry(KeyStore.java:1201) ~[na:1.8.0_144] 
   at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:153) ~[config-entities-1.0.0.jar:na] 
   ... 20 common frames omitted 
   
   2017-11-01 03:28:47,562 pool-21-thread-7 ERROR MESSAGING.RUNTIME - AbstractConfigurator.rollbackTransaction() : Error in processing the changes : Unknown resource type cert 
   

2. Obtenez les détails du keystore/truststore spécifié dans le message d'erreur affiché à l'étape précédente à l'aide de l'appel d'API de gestion suivant:

   curl -v "http://<management-IPaddress>:8080/v1/organizations/<org-name>/environments/<env-name>/keystores/myTruststore" -u <user>
   

   Exemple de résultat :

   { 
   "certs": [ 
   "mycert", 
   "mycert-new" 
   ], 
   "keys": [ 
   "mycert" 
   ], 
   "name": "myTruststore" 
   }
   

3. L'exemple de résultat montre que le truststore myTruststore contient deux certificats et une clé. Le truststore ne contient généralement pas de clé. Si c'est le cas, il est préférable d'avoir un seul certificat et une seule clé.

4. Obtenez des informations sur les deux certificats à l'aide de l'API suivante:

   curl -s http://<management-IPaddress>:8080/v1/runtime/organizations/<org-name>/environments/<env-name>/keystores/<keystore-name>/certs/<cert-name>
   

5. Vérifiez la date d'expiration de chacun des certificats et déterminez s'il est arrivé à expiration ou plus ancien.

6. Supprimez le certificat expiré ou indésirable du truststore "myTruststore".

Si le problème persiste ou si vous constatez une erreur autre que celles mentionnées à l'étape 1 ci-dessus, consultez la section Informations de diagnostic obligatoires.

Cause: entrées de processeur de messages obsolètes OU processeurs de messages inaccessibles

Diagnostic

1. Si l'interface utilisateur Edge prend beaucoup de temps et ne parvient pas à créer la session de trace, voici quelques-unes des causes possibles: <ph type="x-smartling-placeholder">
   </ph>
   1. Le serveur de gestion fait peut-être référence à des processeurs de messages inexistants (obsolètes)
   2. Le ou les processeurs de messages ont été arrêtés ou sont devenus inaccessibles
   3. Les processeurs de messages subissent une utilisation élevée de la mémoire ou du processeur
2. Consultez les journaux du serveur de gestion /opt/apigee/var/log/edge-management-server/logs/system.log et vérifiez si des erreurs se sont produites lors de la création de la session de trace/débogage.

3. Un message d'erreur tel que "server <UUID>" peut s'afficher. is is not up or accessible" lors de la création de la session de trace/débogage, comme indiqué ci-dessous:

   2017-12-27 07:42:38,975 org:cocacola env:prod qtp2007599722-222063 INFO DISTRIBUTION - DebugSessionAPI.createDebugSession() : server 458b5910-2646-441c-a6e2-428b6d84e021 is either not up or reachable, skipping the server
   

   Il se peut que vous suiviez une autre erreur "Connection timed out" (Expiration du délai de connexion). au bout d'un certain temps, comme illustré ci-dessous:

   2017-12-27 07:44:46.000 UTC org:cocacola env:prod qtp2007599722-222063 ERROR DISTRIBUTION - DebugSessionAPI.createDebugSession() : createDebugSession : Unable to connect to the server with UUID {}, skipping it458b5910-2646-441c-a6e2-428b6d84e021 org.apache.http.conn.HttpHostConnectException: Connect to 192.168.101.7:8080 [/192.168.101.7] failed: Connection timed out (Connection timed out) at org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:140) ~[httpclient-4.3.5.jar:4.3.5] at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:318) ~[httpclient-4.3.5.jar:4.3.5] at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:363) ~[httpclient-4.3.5.jar:4.3.5] at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:219) ~[httpclient-4.3.5.jar:4.3.5] 
   …<snipped>
   Caused by: java.net.ConnectException: Connection timed out (Connection timed out) at java.net.PlainSocketImpl.socketConnect(Native Method) ~[na:1.8.0_144] at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) ~[na:1.8.0_144]
   …<snipped>
   

4. Ces deux erreurs peuvent être dues à un ou plusieurs processeurs de messages spécifiques :

   1. Obsolète (obsolète)
   2. Être en panne/injoignable pour une raison quelconque

5. Veuillez suivre la solution appropriée en fonction du scénario rencontré.

Solution

Scénario 1 : un ou plusieurs processeurs de messages sont obsolètes (inexistants)

1. Obtenez la liste des processeurs de messages à l'aide de l'API de gestion ci-dessous:

   curl -u <sysadmin> "http://<management-server-host>:8080/v1/servers?pod=<podName>&regions=<regionName>"
   

2. Notez l'adresse IP ou le nom d'hôte correspondant au ou aux UUID des processeurs de messages mentionnés dans le message d'erreur des journaux du serveur de gestion (étape 3 du diagnostic ci-dessus). Vérifiez s'il s'agit de processeurs de messages valides en utilisant l'une des méthodes suivantes:

   1. Schéma de configuration de la dernière topologie de cloud privé
   2. Dernière adresse IP du serveur Edge : table de mappage des noms d'hôte

   S'il s'agit de processeurs de messages valides, passez au Scénario 2 : Les processeurs de messages sont inaccessibles.

3. Supprimez les processeurs de messages obsolètes (inexistants) à l'aide des API de gestion ci-dessous:

   1. Annulez l'enregistrement du processeur de messages dans les environnements de l'organisation:

      curl -X POST http://<management-server-host>:8080/v1/o/<orgName>/e/<envName>/servers -d "uuid={uuid}&region=<regionName>&pod=<podName}&action=remove" 
      

   2. Annulez l'enregistrement du type de serveur:

      curl http://<management-server-host>:8080/v1/servers -X POST -d "type={message-processor}&region=<regionName>&pod=<podName>&uuid=<uuid>&action=remove"
      

   3. Supprimez le serveur:

      curl http://<management-ip>:8080/v1/servers/<uuid> -X DELETE
      

4. Répétez l'étape 3 si vous rencontrez le même problème dans d'autres environnements de votre organisation.

Scénario 2: un ou plusieurs processeurs de messages sont inaccessibles

1. Connectez-vous à chacun des processeurs de messages en déterminant les adresses IP/noms d'hôte en fonction des UUID observés dans le message d'erreur dans les journaux du serveur de gestion.

2. Redémarrez le processeur de messages:

   /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
   
   

Vérifiez à nouveau si vous pouvez créer la session de trace. Si le problème persiste, consultez Obtenir des informations de diagnostic.

Cause: problème d'utilisation élevée des ressources

Diagnostic

1. Connectez-vous à chacun des processeurs de messages et vérifiez si les ressources(processeur, mémoire ou charge) sont fortement utilisées. Vous pouvez utiliser la commande top sur les systèmes d'exploitation Unix pour obtenir les informations d'utilisation des ressources du processus de traitement des messages:

   top
   

2. Si les processeurs de messages ne font pas l'objet d'une utilisation élevée des ressources, passez à la section Doit collecter des informations de diagnostic.

3. Si le ou les processeurs de messages connaissent une utilisation élevée du processeur ou de la mémoire, il se peut qu'il ne réponde pas au serveur de gestion à temps. Cela vous empêche finalement de créer une session de trace.

   1. Si un processeur de messages sollicite beaucoup le processeur, générez trois fichiers de dump toutes les 30 secondes à l'aide de la commande suivante:

      sudo <JAVA_HOME>/bin/jstack -l <pid> > <filename>
      

   2. Si un processeur de messages utilise beaucoup de mémoire, générez une empreinte de la mémoire à l'aide de la commande suivante:

      sudo -u apigee <JAVA_HOME>/bin/jmap -dump:live,format=b,file=<filename> <pid>
      
      

   3. Passer à la résolution.

Solution

1. Redémarrez le processeur de messages à l'aide de la commande ci-dessous. Cela devrait réduire l'utilisation du processeur et de la mémoire:

   /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
   

2. Surveillez les appels d'API et vérifiez si le problème persiste.

3. Contactez l'assistance Apigee Edge et fournissez-lui les journaux des copies de thread, de l'empreinte de la mémoire et du processeur de messages (/opt/apigee/var/log/edge-message-processor/logs/system.log)) pour l'aider à rechercher la cause de cette utilisation élevée du processeur ou de la mémoire.

Cause: le proxy d'API n'est pas déployé sur un ou plusieurs processeurs de messages

Il est rare qu'un proxy d'API ne soit pas déployé sur un ou plusieurs processeurs de messages. Cela est principalement dû à l'absence de notification d'événement du serveur de gestion vers le processeur de messages lors du déploiement du proxy d'API spécifique. Dans ce cas également, vous ne pourrez pas créer la session de trace dans l'interface utilisateur Edge.

Diagnostic

1. Connectez-vous à chacun des processeurs de messages et vérifiez si la révision spécifique du proxy d'API est déployée à l'aide de la commande suivante:

   curl -v localhost:8082/v1/runtime/organizations/<orgname>/environments/<envname>/apis/<apiname>/revisions
   

   Exemple de résultat :

   La liste des révisions qui s'affiche est la sortie de la commande ci-dessus. Par exemple, si la révision 12 est déployée, le résultat est le suivant:

   [ "12" ]

2. Si la révision spécifique du proxy d'API n'apparaît pas dans la sortie de la commande mentionnée à l'étape 1 ci-dessus, redémarrez le processeur de messages spécifique comme expliqué dans la section Résolution ci-dessous.

3. Répétez les étapes 1 et 2 pour tous les processeurs de messages.

4. Si la révision spécifique du proxy d'API est déployée sur tous les processeurs de messages, ce n'est pas la cause de ce problème. Passez à la section Doit collecter des informations de diagnostic.

Solution

1. Redémarrez le ou les processeurs de messages spécifiques sur lesquels la révision spécifique du proxy d'API n'est pas déployée:

   /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
   
   

Cause: problème avec l'interface utilisateur Edge

Diagnostic

1. Vérifiez les journaux d'interface utilisateur Edge /opt/apigee/var/log/edge-ui/application.log et /opt/apigee/var/log/edge-ui/edge-ui.log pour voir s'il existe des erreurs.
2. Contactez l'assistance Apigee Edge et partagez ces fichiers pour un examen plus approfondi.

Obligation de recueillir des informations de diagnostic

Si le problème persiste alors que vous avez suivi les instructions ci-dessus, veuillez rassembler les informations de diagnostic suivantes. Contactez-les et partagez-les avec l'assistance Apigee Edge:

1. Résultat de la commande:

   curl -v <management-server-host>:8080/v1/runtime/organizations/<org-name>/environments/<env-name>/apis/<apiproxy-name>/revisions/<revision-number>/debugsessions -u <user>
   

2. Journal du serveur de gestion

   /opt/apigee/var/log/edge-management-server/logs/system.log.
   

3. Journaux de processeur de messages

   /opt/apigee/var/log/edge-message-processor/logs/system.log.
   

4. Sortie des commandes telnet/nc du serveur de gestion vers le processeur de messages:

   telnet <MessageProcessor_IP> 8082
   nc -vz <MessageProcessor_IP> 8082
   

5. Le résultat de la commande netstat ci-dessous sur le ou les processeurs de messages :

   netstat -an > netstat.txt
   

6. S'il s'agit d'un problème avec Edge UI, fournissez les journaux d'interface utilisateur Edge /opt/apigee/var/log/edge-ui/application.log et /opt/apigee/var/log/edge-ui/edge-ui.log..

7. Des informations sur les sections de ce playbook qui ont fait l'objet de tests et toute autre information susceptible de nous aider à résoudre rapidement le problème