Não foi possível criar a sessão de trace

Esta é a documentação do Apigee Edge.
Acesse Documentação da Apigee X. informações

Sintoma

O usuário não consegue criar a sessão de rastreamento na interface do Edge.

Mensagem de erro

Você vai receber uma mensagem de erro na interface do Edge, conforme mostrado abaixo:

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

Esta é a captura de tela de um exemplo de mensagem de erro observada na interface do Edge:

Causas possíveis

Algumas das possíveis causas para esse erro estão listadas abaixo:

Causa Descrição Instruções para solução de problemas aplicáveis
Problema de conectividade de rede Falha na comunicação entre o servidor de gerenciamento e o processador de mensagens devido a problemas de conectividade de rede ou regras de firewall. Usuários da nuvem privada de borda
Ambiente não carregado no processador de mensagens O ambiente específico (em que você está tentando ativar o rastreamento) não foi carregado nos processadores de mensagens devido a um erro.
Entradas do processador de mensagens obsoletas O servidor de gerenciamento está fazendo referência a processadores de mensagens inexistentes (desatualizados).
Processador de mensagens inacessível O processador de mensagens foi interrompido ou ficou inacessível.
Problema de alto uso de recursos Os processadores de mensagens estão com alta utilização de recursos (CPU, memória ou carga).
O proxy de API não foi implantado em um ou mais processadores de mensagens O proxy de API não pode ser implantado em um ou mais processadores de mensagens devido à ausência de notificação de evento durante a implantação.
Problema com a interface do Edge A interface do Edge não consegue criar uma sessão de rastreamento devido a um erro.

Etapas comuns do diagnóstico

  1. Execute esta API de gerenciamento:

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

  2. Se você encontrar erros, anote-os. Acesse Problema de conectividade de rede.

  3. Se você receber uma resposta bem-sucedida, isso indica que a sessão de rastreamento pode ser criada com a API Management. No entanto, pode haver um possível problema com a interface do Edge, em que a sessão de rastreamento não pode ser criada na interface. Vá para Problema com a interface do Edge.

Causa: problema de conectividade de rede

Diagnóstico

  1. Verifique o registro do servidor de gerenciamento /opt/apigee/var/log/edge-management-server/logs/system.log e confira se há erros durante a criação da sessão de rastreamento/depuração.

    Exemplo de erro do registro do servidor de gerenciamento

    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. O exemplo de erro acima mostra que recebemos erros "Conexão recusada" quando o servidor de gerenciamento tenta se conectar ao processador de mensagens na porta 8082. Portanto, o servidor de gerenciamento não pode criar a sessão de rastreamento.

  3. Se não houver erros relacionados à conectividade de rede ou um erro semelhante ao mostrado no exemplo acima, acesse Ambiente não carregado no processador de mensagens.

  4. Se você observar erros relacionados à conectividade de rede ou um erro semelhante ao mostrado no exemplo acima, siga as etapas abaixo.

  5. Teste a conectividade do servidor de gerenciamento com o processador de mensagens na porta 8082 seguindo estas etapas:

    1. Se o telnet estiver disponível, use o telnet:

      telnet <MessageProcessor_IP> 8082

    2. Se o telnet não estiver disponível, use o netcat para verificar a conectividade da seguinte maneira:

      nc -vz <MessageProcessor_IP> 8082

    3. Se você receber a resposta "Connection Refused" ou "O tempo limite de conexão expirou" e vá para a próxima etapa.

  6. Faça login em cada um dos processadores de mensagens com o endereço IP correspondente que apresentou o erro e siga estas etapas:

    1. Verifique se o processador de mensagens está ouvindo na porta 8082:

      netstat -an | grep LISTEN | grep 8082

    2. Se o processador de mensagens estiver ouvindo na porta 8082, vá para a etapa 7.

    3. Se o processador de mensagens não estiver ouvindo na porta 8082, reinicie-o usando o seguinte comando:

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

    4. Aguarde até que o processador de mensagens inicie completamente usando este comando:

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

    5. Assim que o processador de mensagens estiver ativo, verifique novamente se ele está escutando na porta 8082.

    6. Se o processador de mensagens estiver escutando na porta 8082, vá para a etapa 7.

  7. Verifique se agora você consegue iniciar a sessão de rastreamento na interface. Se o problema não for mais observado, pule as etapas abaixo.

  8. Se o processador de mensagens estiver em execução e ouvir na porta 8082, mas você ainda não conseguir se conectar a partir de outros servidores, como o servidor de gerenciamento, provavelmente há um firewall que deve estar bloqueando as conexões externas.

  9. Use o comando apropriado para verificar as regras de firewall. Por exemplo, você pode executar o comando iptables para listar todas as regras de firewall definidas no sistema:

    iptables -L -n

  10. Se não houver regras de firewall definidas para a porta 8082, vá para Problema de alto uso de recursos.

  11. Se houver alguma regra de firewall configurada na porta 8082, siga para a seção "Resolução" abaixo.

Resolução

  1. Trabalhe com o administrador da rede para permitir o tráfego de entrada/saída na porta 8082 vindo de servidores externos.

Se o problema persistir, consulte Precisa de informações de diagnóstico.

Causa: ambiente não carregado no processador de mensagens

Diagnóstico

  1. Verifique os registros do servidor de gerenciamento /opt/apigee/var/log/edge-management-server/logs/system.log e confira se há erros durante a criação da sessão de rastreamento/depuração.

  2. Você pode receber uma mensagem de erro como "nenhuma resposta válida do MP(s)" durante a criação da sessão de rastreamento/depuração, conforme mostrado abaixo:

    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}

    Este erro indica que os processadores de mensagens não estão respondendo ao servidor de gerenciamento por algum motivo.

  3. Se não encontrar um erro semelhante ao mostrado no exemplo acima, vá para Entradas do processador de mensagens obsoletos.

  4. Se você encontrar um erro semelhante ao mostrado no exemplo acima, siga estas etapas.

  5. Uma das causas mais comuns desse erro é que o ambiente em que você está tentando criar a sessão de rastreamento não está carregado nos processadores de mensagens.

  6. Faça login em cada um dos processadores de mensagens e verifique se o ambiente específico no qual você está tentando criar a sessão de rastreamento é carregado no processador de mensagens usando o comando abaixo:

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

    Exemplo de resposta:

    Você verá a lista de ambientes pertencentes à organização específica que foram carregados no processador de mensagens na saída do comando acima. Por exemplo, se os ambientes preprod e test forem carregados no processador de mensagens, você verá a saída da seguinte forma:

    [ "pré-produção", "teste" ]

  7. Se o ambiente específico, por exemplo, "dev", em que você está tentando criar uma sessão de rastreamento, estiver listado como parte do comando acima, vá para Entradas do processador de mensagens obsoletos.

  8. Se o ambiente específico, por exemplo, "dev", não estiver listado como parte do comando acima, verifique o /opt/apigee/var/log/edge-message-processor/logs/system.log e o /opt/apigee/var/log/edge-message-processor/logs/startupruntimeerrors.log nos processadores de mensagens se há erros durante o carregamento de ambientes.

  9. Pode haver muitos erros diferentes que podem levar à falha de carregamento de um ambiente no Processador de mensagens. A resolução depende do erro ocorrido.

Resolução

O ambiente pode não ser carregado no processador de mensagens por vários motivos. Esta seção ilustra alguns dos possíveis motivos que podem levar a esse problema e explica como resolvê-lo.

  1. Se você vir um dos seguintes erros no registro do processador de mensagens, isso foi causado por um problema encontrado nos certificados/chaves que foram adicionados ao keystore/truststore especificado no ambiente em questão.

    Erro 1: java.security.KeyStoreException: não é possível substituir o próprio certificado

    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

    Erro 2: java.security.KeyStoreException: não é possível substituir a chave secreta

    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. Use a seguinte chamada da API de gerenciamento para acessar os detalhes do keystore/truststore especificado na mensagem de erro mostrada na etapa anterior:

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

    Exemplo de saída:

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

  3. O exemplo de saída mostra que há dois certificados e uma chave no truststore myTruststore. O truststore geralmente não contém uma chave. Se funcionar, é melhor ter um único certificado e uma única chave.

  4. Acesse os detalhes sobre os dois certificados usando a seguinte API:

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

  5. Verifique a data de validade de cada certificado e determine o certificado expirado/mais antigo.

  6. Exclua o certificado expirado ou indesejado do truststore "myTruststore".

Se o problema persistir ou aparecer um erro diferente dos mencionados na Etapa 1 acima, consulte É necessário coletar informações de diagnóstico.

Causa: entradas do processador de mensagens desatualizadas OU processadores de mensagens inacessíveis

Diagnóstico

  1. Se a interface do Edge demorar muito e não criar a sessão de rastreamento, estas são algumas das possíveis causas:
    1. O servidor de gerenciamento pode estar se referindo a processadores de mensagens inexistentes (desatualizados)
    2. Os processadores de mensagens foram interrompidos ou estão inacessíveis
    3. Os processadores de mensagens estão com um alto uso de memória/CPU
  2. Verifique os registros do servidor de gerenciamento /opt/apigee/var/log/edge-management-server/logs/system.log e confira se há erros durante a criação da sessão de rastreamento/depuração.

  3. Você pode receber uma mensagem de erro como "server <UUID> não está ativo ou acessível" durante a criação da sessão de rastreamento/depuração, conforme mostrado abaixo:

    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

    Isto pode ocorrer depois de mais um erro "O tempo limite de conexão expirou" depois de um tempo, conforme mostrado abaixo:

    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. Esses dois erros podem ser causados por processador(es) de mensagens específicos:

    1. Ficar desatualizado (não existente mais)
    2. Estar fora do ar/não acessível por algum motivo

  5. Siga a resolução adequada dependendo do cenário encontrado.

Resolução

Cenário 1 : os processadores de mensagens estão desatualizados (inexistentes)

  1. Confira a lista de processadores de mensagens usando a API de gerenciamento abaixo:

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

  2. Anote o endereço IP ou o nome do host que corresponde aos UUIDs dos processadores de mensagens mencionados na mensagem de erro nos registros do servidor de gerenciamento (etapa 3 no diagnóstico acima). Verifique se eles são processadores de mensagens válidos usando uma das seguintes maneiras:

    1. Diagrama mais recente da configuração da topologia de nuvem privada
    2. Endereço IP mais recente do servidor de borda: tabela de mapeamento de nome do host

    Se você achar que eles são processadores de mensagens válidos, acesse Cenário 2 : processador (es) de mensagens inacessíveis.

  3. Exclua os processadores de mensagens desatualizados (inexistentes) usando as APIs de gerenciamento abaixo:

    1. Cancelar o registro do processador de mensagens nos ambientes da organização: 

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

    2. Cancelar o registro do tipo de servidor: 

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

    3. Exclua o servidor: 

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

  4. Repita a Etapa 3 se o problema ocorrer em outros ambientes da organização.

Cenário 2: não é possível acessar os processadores de mensagens

  1. Faça login em cada um dos processadores de mensagens determinando os endereços IP/nomes de host com base nos UUIDs observados na mensagem de erro nos registros do Management Server.

  2. Reinicie o processador de mensagens:

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

Verifique novamente se você consegue criar a sessão de rastreamento. Se o problema persistir, consulte Precisa de informações de diagnóstico.

Causa: problema de alto uso de recursos

Diagnóstico

  1. Faça login em cada um dos processadores de mensagens e verifique se há alta utilização de algum dos recursos: CPU, memória ou carga. É possível usar o comando top em sistemas operacionais baseados em Unix para receber informações de utilização de recursos do processo do processador de mensagens:

    top

  2. Se os processadores de mensagens não estiverem apresentando alta utilização de recursos, consulte Necessidade de coletar informações de diagnóstico.

  3. Se os processadores de mensagens estiverem com alto uso de CPU ou memória, é possível que isso esteja fazendo com que o processador de mensagens não responda ao servidor de gerenciamento a tempo. Isso impede que você crie uma sessão de rastreamento.

    1. Se algum processador de mensagens estiver apresentando alto uso da CPU, gere três despejos de linhas de execução a cada 30 segundos usando o seguinte comando:

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

    2. Se algum processador de mensagens estiver usando muito a memória, gere um heap dump com o seguinte comando:

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

    3. Mover para "Resolução".

Resolução

  1. Reinicie o processador de mensagens usando o comando abaixo. Isso deve reduzir o uso de CPU e memória:

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

  2. Monitore as chamadas de API e confirme se o problema ainda ocorre.

  3. Entre em contato com o suporte do Apigee Edge e envie os registros de despejo de linhas de execução, de heap dump e os registros de processador de mensagens (/opt/apigee/var/log/edge-message-processor/logs/system.log)) para ajudar a investigar a causa do alto uso de CPU/memória.

Causa: o proxy de API não foi implantado em um ou mais processadores de mensagens

Raramente, um proxy de API não pode ser implantado em um ou mais processadores de mensagens. Isso acontece principalmente devido à ausência de notificações de eventos do servidor de gerenciamento para o processador de mensagens durante a implantação do proxy de API específico. Nesse caso também, não será possível criar a sessão de rastreamento na interface do Edge.

Diagnóstico

  1. Faça login em cada um dos processadores de mensagens e verifique se a revisão específica do proxy de API foi implantada usando o seguinte comando:

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

    Exemplo de resposta:

    A lista de revisões vai aparecer como a saída do comando acima. Por exemplo, se a revisão 12 for implantada, você verá a resposta a seguir:

    [ "12" ]

  2. Se a revisão específica do proxy de API não aparecer como a saída do comando mencionado na Etapa 1 acima, reinicie o processador de mensagens específico, conforme explicado em Resolução abaixo.

  3. Repita as etapas 1 e 2 para todos os processadores de mensagens.

  4. Se a revisão específica do proxy de API estiver implantada em todos os processadores de mensagens, essa não será a causa do problema. Siga para Precisa coletar informações de diagnóstico.

Resolução

  1. Reinicie os processadores de mensagens específicos em que a revisão específica do proxy de API não está implantada:

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

Causa: problema com a interface do Edge

Diagnóstico

  1. Verifique os registros /opt/apigee/var/log/edge-ui/application.log e /opt/apigee/var/log/edge-ui/edge-ui.log da interface do Edge para ver se há algum erro.
  2. Entre em contato com o suporte do Apigee Edge e compartilhe esses arquivos para uma investigação mais detalhada.

É necessário coletar informações de diagnóstico

Se o problema persistir mesmo depois de seguir as instruções acima, colete as seguintes informações de diagnóstico. Entre em contato e compartilhe com o suporte do Apigee Edge:

  1. Saída do comando:

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

  2. Registro do servidor de gerenciamento 

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

  3. Registros do processador de mensagens

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

  4. Saída de comandos telnet/nc do servidor de gerenciamento para o processador de mensagens:

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

  5. Saída do comando netstat abaixo nos processadores de mensagens:

    netstat -an > netstat.txt

  6. Se for um problema com a interface do Edge, forneça os registros /opt/apigee/var/log/edge-ui/application.log e /opt/apigee/var/log/edge-ui/edge-ui.log. da interface do Edge.

  7. Detalhes sobre quais seções deste Manual foram testadas e quaisquer outros insights que nos ajudarão a agilizar a resolução do problema.