Impossible de créer une session de traçage

Vous consultez la documentation Apigee Edge.
Accédez à la documentation Apigee X.

Problème constaté

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

Message d'erreur

Un message d'erreur s'affiche 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 vous rencontrez des erreurs, notez-les. Accédez à 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. Toutefois, il est possible qu'un problème se produise avec l'UI Edge et qu'il soit impossible de créer une session de trace dans l'UI. Accédez à Problème avec l'UI Edge.

Cause : problème de connectivité réseau

Diagnostic

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

   Exemple d'erreur provenant du 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. Le serveur de gestion ne peut donc pas créer la session de trace.

3. Si vous ne voyez aucune erreur liée à la connectivité réseau ni aucune erreur semblable à celle de l'exemple ci-dessus, passez à la section Environnement non chargé sur le processeur de messages.

4. Si vous constatez des erreurs liées à la connectivité réseau ou une erreur semblable à celle de l'exemple ci-dessus, suivez les étapes ci-dessous.

5. Pour tester la connectivité entre le serveur de gestion et le processeur de messages sur le port 8082, procédez comme suit :

   1. Si telnet est disponible, utilisez-le :

      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 "Délai de connexion dépassé", passez à l'étape suivante.

6. Connectez-vous à chacun des processeurs de messages avec l'adresse IP correspondante qui a affiché 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 le processeur de messages opérationnel, vérifiez à nouveau s'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'UI. Si le problème n'est plus observé, 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 est probable qu'un pare-feu bloque 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 lister 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 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. Collaborez avec votre administrateur réseau pour autoriser le trafic entrant/sortant sur le port 8082 à partir de serveurs externes.

Si le problème persiste, consultez la page Vous devez 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 s'il y a des erreurs lors de la création de la session de trace/débogage.

2. Il est possible que le message d'erreur no valid responses from MP(s) (aucune réponse valide des MP) s'affiche lors de la création d'une 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 aucune erreur semblable à celle de l'exemple ci-dessus ne s'affiche, passez à la section Entrées du processeur de messages obsolètes.

4. Si vous rencontrez une erreur semblable à celle de l'exemple ci-dessus, suivez ces étapes.

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 :

   La liste des environnements appartenant à l'organisation spécifique chargés sur le processeur de message s'affiche dans le résultat de la commande ci-dessus. Par exemple, si les environnements preprod et test sont chargés sur le Processeur de messages, le résultat se présente comme suit :

   [ "preprod", "test" ]

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

8. Si l'environnement spécifique, par exemple "dev", ne figure pas dans la commande ci-dessus, vérifiez les /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 message pour détecter les erreurs 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

L'environnement peut ne pas être chargé sur le processeur de messages pour de nombreuses raisons. Cette section présente quelques raisons possibles qui peuvent entraîner 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, cela est dû à un problème détecté avec les certificats/clés ajoutés au keystore/truststore spécifié dans l'environnement spécifié.

   Erreur 1 : java.security.KeyStoreException : Impossible d'écraser son 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 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 en utilisant 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 qu'il existe deux certificats et une clé dans le truststore myTruststore. 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 identifiez celui qui est expiré ou plus ancien.

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

Si le problème persiste ou si vous rencontrez une erreur autre que celles mentionnées à l'étape 1 ci-dessus, consultez la page Vous devez collecter des informations de diagnostic.

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

Diagnostic

1. Si l'interface utilisateur Edge met beaucoup de temps à créer la session de trace et échoue, voici quelques-unes des causes possibles :
   1. Le serveur de gestion peut faire 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 utilisent beaucoup de mémoire/de ressources processeur
2. Consultez les journaux du serveur de gestion /opt/apigee/var/log/edge-management-server/logs/system.log et vérifiez s'il y a des erreurs lors de la création de la session de trace/débogage.

3. Un message d'erreur tel que "le serveur <UUID> n'est pas opérationnel ou n'est pas accessible" peut s'afficher lors de la création d'une 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
   

   L'erreur "Délai de connexion expiré" peut s'afficher peu de temps après, 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 à des processeurs de messages spécifiques :

   1. Être obsolète (ne plus exister)
   2. Être hors service/inaccessible pour une raison quelconque

5. Veuillez suivre la procédure de résolution appropriée en fonction du scénario rencontré.

Solution

Scénario 1 : Les 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 de la section "Diagnostic" ci-dessus). Vérifiez si ces processeurs de messages sont valides de l'une des manières suivantes :

   1. Dernier schéma de configuration de la topologie du cloud privé
   2. Dernière table de mappage entre les adresses IP des serveurs Edge et les noms d'hôte

   Si vous les jugez 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. Désenregistrez le processeur de messages des 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 : Les 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 des 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 la page Vous devez collecter des informations de diagnostic.

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

Diagnostic

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

   top
   

2. Si les processeurs de messages ne présentent pas une utilisation élevée des ressources, passez à la section Vous devez collecter des informations de diagnostic.

3. Si le ou les processeurs de messages utilisent beaucoup de ressources processeur ou de mémoire, cela peut les empêcher de répondre au serveur de gestion à temps. Cela vous empêche à terme de créer une session de trace.

   1. Si un processeur de messages connaît une utilisation élevée du processeur, générez trois dumps de thread 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 un dump de tas à l'aide de la commande suivante :

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

   3. Passez à l'état "Résolu".

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 vidages de thread, l'empreinte de la mémoire et les journaux du processeur de messages (/opt/apigee/var/log/edge-message-processor/logs/system.log)) pour l'aider à identifier la cause de l'utilisation élevée du processeur/de la mémoire.

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

Il arrive rarement qu'un proxy d'API ne soit pas déployé sur un ou plusieurs processeurs de messages. Cela se produit principalement en raison de l'absence de notification d'événement du serveur de gestion au processeur de message 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'UI 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 s'affiche en tant que résultat de la commande ci-dessus. Par exemple, si la révision 12 est déployée, le résultat suivant s'affiche :

   [ "12" ]

2. Si la révision spécifique du proxy d'API ne s'affiche pas dans le résultat 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 message, ce n'est pas la cause de ce problème. Accédez à Vous devez 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 lié à l'interface utilisateur Edge

Diagnostic

1. Consultez les journaux de l'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 y a des erreurs.
2. Contactez l'assistance Apigee Edge et partagez ces fichiers pour une analyse plus approfondie.

Vous devez collecter des informations de diagnostic

Si le problème persiste, même après avoir suivi les instructions ci-dessus, veuillez rassembler les informations de diagnostic suivantes. Contactez l'assistance Apigee Edge et partagez-les :

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 du processeur de messages

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

4. Résultat des commandes telnet/nc du serveur de gestion au processeur de messages :

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

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

   netstat -an > netstat.txt
   

6. Si le problème concerne l'UI Edge, fournissez les journaux de l'UI 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 été testées et tout autre insight qui nous aidera à résoudre rapidement ce problème.