Impossible de créer une session de traçage

Vous consultez la documentation d'Apigee Edge.
Consultez la documentation Apigee X. en savoir plus

Problème constaté

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

Message d'erreur

Vous obtiendrez 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:

Cause Description Instructions de dépannage applicables à
Problème de connectivité réseau Échec de la communication entre le serveur de gestion et le processeur de messages en raison de problèmes de connectivité réseau ou de règles de pare-feu. Utilisateurs de cloud privé périphérique
Environnement non chargé dans le processeur de messages L'environnement spécifique (dans lequel vous essayez d'activer la trace) n'a pas été chargé sur le ou les processeurs de messages en raison d'une erreur.
Entrées de processeur de messages obsolètes Le serveur de gestion fait référence à des processeurs de messages inexistants (obsolètes).
Processeur de messages inaccessible Le processeur de messages a été arrêté ou est devenu inaccessible.
Problème d'utilisation élevée des ressources Les processeurs de messages utilisent de nombreuses ressources (processeur, mémoire ou charge).
Proxy d'API non déployé sur un ou plusieurs processeurs de messages Il est possible que le proxy d'API ne soit pas déployé sur un ou plusieurs processeurs de messages en raison de l'absence de notification d'événement lors du déploiement.
Problème avec l'interface utilisateur Edge L'interface utilisateur Edge ne peut pas créer de session de trace en raison d'une 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 surviennent, notez-les. Consultez la section Problème de connectivité réseau.

  3. Si vous obtenez une réponse positive, cela signifie que la session de suivi peut être créée via l'API Management. Toutefois, il se peut qu'il y ait un problème avec l'interface utilisateur Edge qui empêche la création de session de traçage 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 qu'il n'y a pas d'erreurs 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 refusée" lorsque le serveur de gestion tente de se connecter au processeur de messages sur le port n° 8082. Par conséquent, le serveur de gestion ne peut pas créer la session de traçage.

  3. Si vous ne constatez aucune erreur liée à la connectivité réseau ou à une erreur semblable à celle présentée dans 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 illustrée dans l'exemple ci-dessus, suivez les étapes ci-dessous.

  5. Testez la connectivité du serveur de gestion au 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 "Connection Refused" (Connexion refusée) ou "Connection timed out" (Expiration du délai de connexion), passez à l'étape suivante.

  6. Connectez-vous à chacun des processeurs de messages avec l'adresse IP correspondante ayant généré l'erreur et 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 en marche, 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 Trace dans l'interface utilisateur. 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 des autres serveurs tels que Management Server, 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. Demandez à votre administrateur réseau d'autoriser le trafic entrant et sortant sur le port 8082 en provenance de serveurs externes.

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

Cause: l'environnement n'est pas chargé dans le processeur de messages

Diagnostic

  1. Consultez les journaux /opt/apigee/var/log/edge-management-server/logs/system.log du serveur de gestion et vérifiez qu'il n'y a pas d'erreurs lors de la création de la session de trace/débogage.

  2. Un message d'erreur du type "no valid answers from MP(s)" (Aucune réponse valide du ou des MP(s)) peut s'afficher 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 à Management Server pour une raison quelconque.

  3. Si vous ne voyez pas d'erreur semblable à celle présentée dans l'exemple ci-dessus, passez à Entrées de processeur de messages obsolètes.

  4. Si vous constatez une erreur semblable à celle illustré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 traçage 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 suivi 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 messages 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, vous obtenez le résultat suivant:

    [ "preprod", "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, passez à Entrées de processeur de messages obsolètes.

  8. Si l'environnement spécifique, dites "dev",, ne figure pas dans la liste 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 contiennent pas d'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 rencontrée.

Résolution

L'environnement peut ne pas être chargé sur le processeur de messages pour de nombreuses raisons. Cette section présente quelques-unes des raisons pouvant être à l'origine de 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 ou au magasin de clés de confiance spécifié dans l'environnement spécifié.

    Erreur n° 1: java.security.KeyStoreException: Cannot replace own certificate

    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: Cannot override secret key

    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 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 les détails des 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 le certificat arrivé à expiration/l'ancien.

  6. Supprimez le certificat arrivé à expiration 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 Obtention des informations de diagnostic nécessaires.

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 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 la mémoire/le processeur.
  2. Consultez les journaux du serveur de gestion /opt/apigee/var/log/edge-management-server/logs/system.log et vérifiez qu'il n'y a pas d'erreur lors de la création de la session de trace/débogage.

  3. Il est possible qu'un message d'erreur de type "server <UUID> is not up or reachable" peut s'afficher 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

    Une autre erreur "Connection timed out" (Expiration du délai de connexion) peut s'afficher au bout d'un certain temps, comme indiqué 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. Obsolète (ce n'est plus le cas)
    2. En panne/Injoignable pour une raison inconnue

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

Ré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 dans les journaux du serveur de gestion (étape 3 de l'analyse ci-dessus). Vérifiez s'il s'agit de processeurs de messages valides en utilisant l'une des méthodes suivantes:

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

    S'ils correspondent à des 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. Annuler 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 traçage. Si le problème persiste, consultez Obtention d'informations de diagnostic obligatoire..

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

Diagnostic

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

    top

  2. Si le ou les processeurs de messages ne sont pas soumis à une utilisation élevée des ressources, passez à la section Recueillir des informations de diagnostic.

  3. Si un ou plusieurs processeurs de messages utilisent beaucoup le processeur ou la mémoire, cela peut expliquer qu'ils ne répondent pas au serveur de gestion à temps. À terme, cela vous empêche de créer une session de traçage.

    1. Si l'un des processeurs de messages utilise particulièrement le processeur, générez trois copies de thread toutes les 30 secondes à l'aide de la commande suivante:

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

    2. Si l'un des processeurs 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.

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

Cause: proxy d'API non déployé sur un ou plusieurs processeurs de messages

Dans de rares cas, un proxy d'API ne peut pas être 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 messages lors du déploiement du proxy d'API spécifique. Dans ce cas également, vous ne pourrez pas créer la session de traçage 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 s'affiche dans le 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 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 problème n'est pas la cause du problème. Passez à la section Obtention des informations de diagnostic.

Ré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 et voyez s'il y a des erreurs.
  2. Contactez l'assistance Apigee Edge et partagez ces fichiers pour un examen plus approfondi.

Obtention d'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-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 du 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. Résultat de la commande netstat ci-dessous sur le ou les processeurs de messages :

    netstat -an > netstat.txt

  6. S'il s'avère qu'il s'agit d'un problème avec l'interface utilisateur Edge, indiquez 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 été testées et sur d'autres informations qui nous aideront à accélérer la résolution de ce problème.