Esta página foi traduzida pela API Cloud Translation.

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

Você está vendo a documentação do Apigee Edge.
Acesse a documentação da Apigee X. informações

Sintoma

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

Mensagem de erro

Você 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 é uma 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 de solução de problemas aplicáveis a
Problema de conectividade de rede	Falha de 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 no (s) processador de mensagens devido a um erro.
Entradas do processador de mensagens desatualizadas	O Servidor de gerenciamento está fazendo referência a processadores de mensagens inexistentes (obsoletos).
Processador de mensagens inacessível	O processador de mensagens foi interrompido ou ficou inacessível.
Problema com o alto uso de recursos	Os processadores de mensagens estão apresentando um alto uso 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 eventos durante a implantação.
Problema com a interface do Edge	A interface do Edge não conseguiu criar uma sessão de rastreamento devido a um erro.

Etapas comuns de diagnóstico

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>

Se você encontrar erros, anote-os. Siga para Problema de conectividade de rede.
Se a resposta for bem-sucedida, isso indica que a sessão de rastreamento pode ser criada na 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. Prossiga para Problema com a interface do Edge.

Causa: problema de conectividade de rede

Diagnóstico

Verifique o registro /opt/apigee/var/log/edge-management-server/logs/system.log do servidor de gerenciamento e verifique 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>

O exemplo de erro acima mostra que estamos recebendo erros "Conexão recusada" quando o servidor de gerenciamento tenta se conectar ao processador de mensagens na porta no 8082. Portanto, o servidor de gerenciamento não consegue criar a sessão de rastreamento.
Se você não encontrar nenhum erro relacionado à conectividade de rede ou um erro semelhante ao mostrado no exemplo acima, vá para Ambiente não carregado no processador de mensagens.
Se você observar erros relacionados à conectividade de rede ou algo semelhante ao mostrado no exemplo acima, siga as etapas abaixo.
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 "Conexão recusada" ou "Tempo limite de conexão esgotado", siga para a próxima etapa.
Faça login em cada um dos processadores de mensagens com o endereço IP correspondente que mostraram o erro e siga estas etapas:
1. Verifique se o processador de mensagens está detectando na porta 8082:
```
netstat -an | grep LISTEN | grep 8082
```
2. Se o processador de mensagens estiver ouvindo na porta 8082, passe para a etapa 7.
3. Se o processador de mensagens não estiver detectando na porta 8082, reinicie o processador de mensagens usando este comando:
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```
4. Aguarde até que o processador de mensagens comece a usar este comando:
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor wait_for_ready
```
5. Quando o processador de mensagens estiver em funcionamento, verifique novamente se ele está ouvindo na porta 8082.
6. Se o processador de mensagens estiver detectando na porta 8082, passe para a etapa 7.
Verifique se você consegue iniciar a sessão de rastreamento na interface. Se o problema não for mais observado, pule as etapas abaixo.
Se o processador de mensagens estiver em execução e detectar na porta 8082, mas você ainda não conseguir se conectar a partir de outros servidores, como o servidor de gerenciamento, é provável que um firewall esteja bloqueando as conexões externas.
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
```
Se não houver regras de firewall definidas para a porta 8082, prossiga para Problema de utilização de recursos alta.
Se houver regras de firewall configuradas na porta 8082, vá para a seção "Resolução" abaixo.

Resolução

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

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

Causa: ambiente não carregado no processador de mensagens

Diagnóstico

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

É possível que você veja uma mensagem de erro como "no valid messages from MP(s)" (nenhuma resposta válida dos 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}

Esse erro indica que o(s) processador(es) de mensagens não estão respondendo ao servidor de gerenciamento por algum motivo.

Se você não vê um erro semelhante ao mostrado no exemplo acima, vá para Entradas do processador de mensagens desatualizadas.
Se você observar um erro semelhante ao mostrado no exemplo acima, siga estas etapas.
Uma das causas mais comuns desse erro é que o ambiente no qual você está tentando criar a sessão de rastreamento não está carregado nos processadores de mensagens.
Faça login em cada um dos processadores de mensagens e verifique se o ambiente específico em que 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 saída:

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

[ "pré-prod", "teste" ]
Se o ambiente específico, como "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 desatualizadas.
Se o ambiente específico, diga "dev", não estiver listado como parte do comando acima, verifique /opt/apigee/var/log/edge-message-processor/logs/system.log e /opt/apigee/var/log/edge-message-processor/logs/startupruntimeerrors.log nos processadores de mensagens para ver se há erros durante o carregamento de ambientes.
Podem existir muitos erros diferentes que talvez levem à 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.

Se você encontrar um dos seguintes erros no registro do processador de mensagens, isso significa que ele foi causado por um problema encontrado nos certificados/chaves adicionados ao keystore/truststore especificado no ambiente especificado.

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

Consulte os detalhes do keystore/truststore especificado na mensagem de erro mostrada na etapa anterior usando a seguinte chamada de API de gerenciamento:

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" 
}

O exemplo de saída mostra que há dois certificados e uma chave no myTruststore truststore. Em geral, o truststore não contém uma chave. Se isso acontecer, é melhor ter apenas um certificado e uma chave.

Veja os detalhes dos 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>

Verifique a data de validade de cada um dos certificados e determine qual deles expirou/antigo.
Exclua o certificado expirado ou indesejado do truststore "myTruststore".

Se o problema persistir ou você encontrar um erro diferente dos mencionados na etapa 1 acima, acesse Precisa coletar informações de diagnóstico.

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

Diagnóstico

Se a IU do Edge demorar muito e falhar ao 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 alto uso de memória/CPU
Verifique os registros /opt/apigee/var/log/edge-management-server/logs/system.log do servidor de gerenciamento e verifique se há algum erro durante a criação da sessão de rastreamento/depuração.

Talvez você veja uma mensagem de erro como "server <UUID> is either not up or reachable" 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

Isso pode ocorrer depois de mais um erro "O tempo limite de conexão foi atingido" após algum 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>

Estes dois erros podem ser causados devido a Processadores de mensagens específicos:
1. Estar desatualizado (não existe mais)
2. Ficar parado/inacessível por algum motivo
Siga a resolução apropriada dependendo do cenário encontrado.

Resolução

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

Veja 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>"

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 do diagnóstico acima). Verifique se esses são processadores de mensagens válidos usando uma das seguintes formas:
1. Diagrama de configuração mais recente da topologia de nuvem privada
2. Endereço IP mais recente do servidor de borda: tabela de mapeamento do nome do host
Se você achar que eles são processadores de mensagens válidos, siga para Cenário 2 : os processadores de mensagens estão inacessíveis.

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

Cancele 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"

Cancele 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"

Exclua o servidor:

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

Repita a etapa 3 se você tiver o mesmo problema em outros ambientes na sua organização.

Cenário 2: os processadores de mensagens estão inacessíveis

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 servidor de gerenciamento.

Reinicie o processador de mensagens:

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

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

Causa: problema de alto uso de recursos

Diagnóstico

Faça login em cada processador de mensagens e verifique se há alta utilização de algum recurso - CPU, memória ou carga. Você pode usar o comando top em sistemas operacionais baseados em Unix para obter as informações de utilização de recursos do processo do Message Processor:
```
top
```
Se os processadores de mensagens não estiverem apresentando uma alta utilização de recursos, vá para Precisa coletar informações de diagnóstico.
Se o processador de mensagens estiver apresentando um alto uso de CPU ou memória, isso pode estar fazendo com que ele 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 de 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 apresentando alto uso de memória, gere um heap dump usando o seguinte comando:
```
sudo -u apigee <JAVA_HOME>/bin/jmap -dump:live,format=b,file=<filename> <pid>
```
3. Mover para Resolução.

Resolução

Reinicie o processador de mensagens usando o comando abaixo. Isso diminui o uso de CPU e memória:
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```
Monitore as chamadas de API e confirme se o problema ainda persiste.
Entre em contato com o suporte do Apigee Edge e informe os registros de despejos de linha de execução, heap dump e do 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 pode não ser implantado em um ou mais processadores de mensagens. Isso acontece principalmente devido a notificações de eventos ausentes 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 vai ser possível criar a sessão de rastreamento na interface do Edge.

Diagnóstico

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 saída:

A lista de revisões será exibida como saída do comando acima. Por exemplo, se a revisão 12 for implantada, você verá a saída desta forma:

[ "12" ]
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.
Repita as etapas de 1 a 2 para todos os processadores de mensagens.
Se a revisão específica do proxy de API estiver implantada em todos os processadores de mensagens, esse não será o motivo do problema. Passe para Precisa coletar informações de diagnóstico.

Resolução

Reinicie os processadores de mensagens específicos em que a revisão específica do proxy de API não foi implantada:
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```

Causa: problema com a interface do Edge

Diagnóstico

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 e veja se há algum erro.
Entre em contato com o suporte do Apigee Edge e compartilhe esses arquivos para uma investigação mais detalhada.

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:

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>

Registro do servidor de gerenciamento

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

Registros do processador de mensagens

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

Saída de comandos telnet/nc do servidor de gerenciamento para o processador de mensagens:
```
telnet <MessageProcessor_IP> 8082
nc -vz <MessageProcessor_IP> 8082
```
Saída do comando netstat abaixo no(s) processador(es) de mensagens:
```
netstat -an > netstat.txt
```
Se for encontrado um problema com a interface do Edge, envie os registros /opt/apigee/var/log/edge-ui/application.log e /opt/apigee/var/log/edge-ui/edge-ui.log. dessa interface
Detalhes sobre quais seções deste Manual foram testadas e quaisquer outros insights que nos ajudarão a agilizar a resolução deste problema.