Esta página foi traduzida pela API Cloud Translation.

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

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

Sintoma

A imagem a seguir mostra que as solicitações da 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 na captura de solicitações de API no Edge UI Trace:

Causa	Descrição	Instruções de solução de problemas aplicáveis a
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 rastros. Se uma solicitação de API não chegar ao Apigee Edge, ocorrerá uma falha no ponto de entrada para o Edge (ou seja, Router) ou falhar antes de ser processado pelo Processador de mensagens, o rastreamento 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 de árvore de classificação para enviar solicitações com base no nome do host, no caminho base, na revisão e no ambiente da solicitação recebida. Se o proxy de API relevante for removido por algum motivo da Árvore de classificação, as transações de Trace poderão não ser 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, a solicitação de API 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, ocorrerá uma falha no ponto de entrada para o Edge (ou seja, Router) ou falhar antes de ser processado pelo Processador de mensagens, o rastreamento não poderá ser capturado. Cada um desses cenários é descrito com 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 de conectividade de rede. Nesse caso, você pode ver o seguinte erro ao executar este 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
```
Verifique a conectividade de rede com o seguinte comando:
```
telnet hostName port
```

Cenário 2: as solicitações falham no roteador do Apigee Edge

Causa

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

Consulte os seguintes playbooks para resolver esses problemas:

Falhas do 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

Neste cenário, o processador de mensagens da Apigee não consegue encontrar o proxy de API para o host virtual e o caminho especificados. Como resultado, você pode encontrar 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 manual 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 encontrar um proxy de API na árvore de classificação, as solicitações de API para esse proxy específico não serão exibidas nas sessões de rastreamento na interface do usuário de borda.

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

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 a revisão específica seja 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 mensagem. Se o nome do proxy de API fornecido estiver ausente da árvore de classificação de qualquer um dos processadores de mensagens, siga a resolução fornecida 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 possam 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
```
Após a reinicialização, use o comando abaixo para aguardar até que ele fique ativo:
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor wait_for_ready
```
Quando o processador de mensagens estiver pronto, verifique a disponibilidade do proxy de API com o seguinte comando:
```
curl -v http://localhost:8082/v1/runtime/organizations/orgName/environments/envName/apis/apiName/revisions
```
Exemplo de saída:

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 a revisão específica seja 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, acesse Precisa coletar informações de diagnóstico.

Coletar informações de diagnóstico

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

Tipo de informações de diagnóstico	Comando
Saída do comando trace session	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 operador 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