O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

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

Você está lendo a documentação do Apigee Edge.
Acesse a documentação da Apigee X. info

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 possíveis causas para uma falha na captura de solicitações de API no rastreamento da interface do Edge:

Causa	Descrição	Instruções de solução de problemas aplicáveis para
Solicitações não processadas pelo processador de mensagens	As solicitações de API precisam ser processadas pelo componente processador de mensagens do Edge para capturar o trace. Se uma solicitação de API não chegar ao Apigee Edge ou falhar no ponto de entrada do Edge (por exemplo, Router) ou falhar antes de ser processado pelo processador de mensagens, o rastreamento não poderá ser capturado.	Usuários da nuvem pública e privada do Edge
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 despachar 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 rastreamento poderão não ser preenchidas.	Usuários da nuvem privada do Edge

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

Diagnóstico

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

Por exemplo, se uma solicitação de API não chegar ao Apigee Edge ou falhar no ponto de entrada do 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 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 de conectividade de rede. Se for o caso, o seguinte erro pode aparecer ao executar esse comando:
```
curl https://hostName:port/apiProxyBasePath/requestPath
```
```
curl: (6) Could not resolve host: hostName
```
Resolução

Verifique a configuração de DNS com o seguinte comando:
```
dig hostName
```
Para verificar a conectividade de rede, use 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 no handshake TLS/SSL. Se for esse o caso, você poderá encontrar um dos seguintes erros:
```
Received fatal alert: handshake_failure
```
```
HTTP/1.1 400 Bad Request
```
Um erro de certificado SSL também pode aparecer.
Resolução

Consulte os seguintes playbooks para resolver 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 do 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 solucionar e resolver o problema: 404 Não foi possível identificar o proxy para o 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 mostradas nas sessões de rastreamento 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 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 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ê esteja enfrentando 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 mensagens. Se o nome do proxy de API especificado estiver faltando na árvore de classificação de algum 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 na produção que possam ocorrer ao reiniciar os 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 reiniciar, 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 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ê esteja enfrentando 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 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, colete as seguintes informações de diagnóstico e compartilhe com o suporte do Apigee Edge:

Tipo de informação de diagnóstico	Comando
Saída do comando de 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 dos 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
Saída listando as revisões 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