Esta página foi traduzida pela API Cloud Translation.

Solicitações de API não capturadas na IU do Edge

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

Sintoma

A imagem a seguir mostra que as solicitações de API não são capturadas na interface do Edge quando uma sessão de rastreamento é iniciada:

Mensagem de erro

Nenhuma mensagem de erro será exibida na interface do Edge quando esse problema ocorrer.

Causas possíveis

A tabela a seguir mostra as possíveis causas de uma falha ao capturar solicitações de API no Edge UI Trace:

Causa	Descrição	Instruções para solução de problemas aplicáveis
Solicitações não processadas pelo processador de mensagens	As solicitações de API precisam ser processadas pelo processador de mensagens do componente do Edge para capturar o rastro. Se uma solicitação de API não alcançar o Apigee Edge, ocorrerá uma falha no ponto de entrada para o Edge (por exemplo, Router) ou falhar antes de ser processado pelo processador de mensagens, o rastro não poderá ser capturado.	Usuários de nuvem pública e privada de borda
Proxy de API não encontrado na árvore de classificação	Os processadores de mensagens da Apigee usam uma definição de regra de roteamento chamada "árvore de classificação" para enviar solicitações com base no nome do host, caminho base, revisão e ambiente da solicitação recebida. Se o proxy de API relevante for removido da árvore de classificação por algum motivo, talvez as transações de Trace não sejam preenchidas.	Usuários da nuvem privada de borda

Causa: solicitações não processadas pelo processador de mensagens

Diagnóstico

Para capturar uma solicitação de API em uma sessão do Trace, ela precisa ser processada pelo processador de mensagens do componente do Edge. Há vários motivos para uma solicitação de API não ser capturada em uma transação do Trace.

Por exemplo, se uma solicitação de API não chegar ao Apigee Edge, ela falhará no ponto de entrada para o Edge (por exemplo, Router) ou falhar antes de ser processado pelo processador de mensagens, o rastro não poderá ser capturado. Cada um desses cenários é descrito em mais detalhes abaixo.

Cenário 1: as solicitações não chegam ao Apigee Edge

Causa

Nesse cenário, o erro pode ser causado por um problema de resolução de DNS ou conectividade de rede. Nesse caso, talvez você veja o seguinte erro ao executar esse comando:
```
curl https://hostName:port/apiProxyBasePath/requestPath
```
```
curl: (6) Could not resolve host: hostName
```
Resolução

Você pode verificar a configuração do DNS com o seguinte comando:
```
dig hostName
```
É possível verificar a conectividade de rede com o seguinte comando:
```
telnet hostName port
```

Cenário 2: falha nas solicitações no Apigee Edge Router

Causa

Nesse cenário, o erro pode ser causado por uma falha de handshake de TLS/SSL. Nesse caso, um dos seguintes erros pode aparecer:
```
Received fatal alert: handshake_failure
```
```
HTTP/1.1 400 Bad Request
```
Você também pode ver um erro de certificado SSL.
Resolução

Consulte os manuais a seguir para solucionar esses problemas:

Falhas de handshake de TLS/SSL

400 Solicitação inválida - erro de certificado SSL

Cenário 3: as solicitações não podem ser processadas pelo processador de mensagens

Causa

Nesse cenário, o processador de mensagens da Apigee não consegue encontrar o proxy de API para host virtual e caminho especificados. Como resultado, você pode ver um dos seguintes erros:

HTTP/1.1 404 Not Found

{
  "fault":{
    "faultstring":"Unable to identify proxy for host: default and url: \/apiProxyBasePath/requestPath",
    "detail":{
      "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
    }
  }
}

Resolução

Consulte este playbook para resolver o problema: 404 Não foi possível identificar o proxy do host.

Causa: proxy de API não encontrado na árvore de classificação

Diagnóstico

Se um processador de mensagens não conseguir encontrar um proxy de API na árvore de classificação, as solicitações de API para esse proxy específico não serão mostradas nas sessões do Trace na interface do Edge.

Siga as etapas abaixo para determinar se esse é o caso:

Faça login em cada um dos processadores de mensagens e verifique se a revisão específica da API solicitada foi implantada no ambiente relevante do processador de mensagens usando o seguinte comando:
```
curl -v http://localhost:8082/v1/runtime/organizations/orgName/environments/envName/apis/apiName/revisions
```
Exemplo de resposta:

O comando acima vai gerar uma lista de revisões implantadas. Por exemplo, se a revisão 12 for implantada, você verá a seguinte saída:
```
[ "12" ]
```
A menos que você encontre erros HTTP 404 intermitentes, é provável que veja que a revisão específica foi implantada.
Leia a árvore de classificação e verifique a existência do nome do proxy de API usando o seguinte comando:
```
curl -i http://localhost:8082/v1/classification/tree | grep apiName
```
Repita as etapas 1 e 2 para cada processador de mensagens. Se o nome de proxy de API fornecido estiver ausente na árvore de classificação de qualquer um dos processadores de mensagens, siga a resolução abaixo.

Resolução

Siga as etapas abaixo para resolver esse problema. Tome todas as precauções necessárias para evitar interrupções de produção que podem ocorrer devido à reinicialização dos processadores de mensagens durante cargas de solicitações altas.

Faça login em cada um dos hosts do processador de mensagens que não têm o proxy de API específico na Árvore de classificação e use o comando abaixo para reiniciar o processador de mensagens:
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```

Depois de reiniciado, use o comando abaixo para aguardar até que fique ativo:

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

Assim que o processador de mensagens estiver pronto, verifique a disponibilidade do proxy de API usando o seguinte comando:
```
curl -v http://localhost:8082/v1/runtime/organizations/orgName/environments/envName/apis/apiName/revisions
```
Exemplo de resposta:

O comando acima vai gerar uma lista de revisões implantadas. Por exemplo, se a revisão 12 for implantada, você verá a seguinte saída:
```
[ "12" ]
```
A menos que você encontre erros HTTP 404 intermitentes, é provável que veja que a revisão específica foi implantada.
Leia a árvore de classificação e verifique a existência do nome do proxy de API usando o seguinte comando:
```
curl -i http://localhost:8082/v1/classification/tree | grep apiName
```
Se o problema persistir, consulte Precisa de informações de diagnóstico.

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

Se o problema persistir depois de seguir as instruções acima, reúna as seguintes informações de diagnóstico e compartilhe-as com o suporte do Apigee Edge:

Informações de diagnóstico Tipo	Comando
Saída do comando da sessão de rastreamento	curl -v `management-server-host`:8080/v1/runtime/organizations/`orgName`/environments/`envName`/apis/`apiProxyName`/revisions/`revisionNumber`/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`/`netcat` do servidor de gerenciamento para o processador de mensagens	telnet `MessageProcessor_IP` 8082 nc -vz `MessageProcessor_IP` 8082
Saída do comando netstat nos processadores de mensagens	netstat -an > netstat.txt
Revisões da lista de saída implantadas para o proxy de API específico em todos os processadores de mensagens	curl -v http://localhost:8082/v1/runtime/organizations/`orgName`/environments/`envName`/apis/`apiName`/revisions
Saída da árvore de classificação em todos os processadores de mensagens	curl -i http://localhost:8082/v1/classification/tree