404 Não foi possível identificar o proxy do host: <nome do host virtual> e URL: <caminho>

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

Sintoma

O aplicativo cliente recebe um código de status HTTP de 404 com a mensagem Not Found e a mensagem de erro Unable to identify proxy for host: VIRTUAL_HOST and url: PATH como uma resposta às chamadas de API.

Esse erro significa que o Edge não conseguiu encontrar o proxy de API do host virtual e do caminho especificados.

Mensagem de erro

Você verá o seguinte código de status HTTP:

HTTP/1.1 404 Not Found

Você também vai encontrar uma mensagem de erro parecida com esta:

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

A mensagem de erro acima indica que o Edge não conseguiu encontrar o proxy de API da Host virtual default e caminho /oauth2/token.

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 para
Proxy de API não associado ao host virtual específico	O proxy de API específico não está configurado para aceitar solicitações no host virtual especificado na mensagem de erro.	Usuários de nuvem pública e privada de borda
Host virtual removido em uma revisão recém-implantada do proxy de API	Remover o host virtual da revisão recém-implantada enquanto o cliente ainda está usando o host virtual específico pode causar esse problema.	Usuários de nuvem pública e privada de borda
Caminho não associado a nenhum proxy de API	O proxy de API específico não está configurado para aceitar solicitações no caminho especificado na mensagem de erro.	Usuários de nuvem pública e privada de borda
Proxy de API não implantado em um ambiente	O proxy de API específico não é implantado no ambiente específico em que você está tentando fazer as solicitações de API.	Usuários de nuvem pública e privada de borda
Ambiente não carregado no processador de mensagens	O ambiente específico (em que você está tentando fazer as solicitações de API) não carregado nos processadores de mensagens devido a um erro.	Usuários da nuvem privada de borda
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 notificações de eventos durante a implantação.	Usuários da nuvem privada de borda

Etapas comuns do diagnóstico

Os registros do NGINX e do Message Processor serão úteis para resolver o erro 404. Siga estas etapas para verificar os registros:

1. Visualize os registros do NGINX usando o seguinte comando:

   /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

2. Verifique os seguintes campos nas entradas de registro:

   Campo	Valor
   Upstream_status, status	404
   X-Apigee-fault-code	messaging.adaptors.http.flow.ApplicationNotFound

   Anote o ID da mensagem que aparece nos registros.

3. Verificar os registros do processador de mensagens (/opt/apigee/var/log/edge-message-processor/logs/system.log) para ver se você messaging.adaptors.http.flow.ApplicationNotFound para a API específica ou se você tem o parâmetro ID da mensagem da etapa 2 para a solicitação de API.

   Exemplo de mensagem de erro do registro do processador de mensagens

NIOThread@1 ERROR ADAPTORS.HTTP.FLOW - AbstractRequestListener.onException() : Request:POST, uri:/weather, message Id:null, exception:com.apigee.rest.framework.ResourceNotFoundException{ code = messaging.adaptors.http.flow.ApplicationNotFound, message = Unable to identify proxy for host: vh1 and url: /weather, associated contexts = []}, context:Context@342ea86b input=ClientInputChannel(SSLClientChannel[Accepted: Remote:10.123.123.123:8443 Local:10.135.33.68:62092]@1206954 useCount=1 bytesRead=0 bytesWritten=0 age=1ms  lastIO=0ms  isOpen=true)

O registro acima mostra o código e a mensagem de erro:

code = messaging.adaptors.http.flow.ApplicationNotFound,
message = Unable to identify proxy for host: vh1 and url: /weather

Causa: proxy de API não associado ao host virtual específico

Se o proxy de API não estiver configurado para aceitar as solicitações do host virtual específico, podemos receber uma resposta 404 Not Found com a mensagem de erro Unable to identify proxy for host: VIRTUAL_HOST and url: PATH.

Diagnóstico

1. Verifique a configuração do Endpoint do proxy do proxy de API e veja se ele está configurado para aceitar as solicitações do host virtual especificado no erro. Isso é indicado pelo elemento VirtualHost. Vamos analisar um exemplo de ProxyEndpoint configuração para entender isso.

   Exemplo de configuração de endpoint de proxy mostrando que o proxy de API aceita solicitações em uma host virtual seguro

   

2. Digamos que os hosts virtuais estejam definidos no ambiente específico da seguinte maneira:

   Nome	Porta	Alias de host
   default	80	myorg-prod.apigee.net
   secure	443	myorg-prod.apigee.net

3. Você faz uma solicitação de API ao default VirtualHost usando o URL http://myorg-prod.apigee.net/weather
4. Como o ProxyEndpoint não tem default VirtualHost, como mostrado no exemplo acima, você recebe o código de resposta 404 com a seguinte mensagem de erro:

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

5. Acesse a seção Resolução abaixo para resolver esse problema.
6. Se o ProxyEndpoint estiver configurado para aceitar as solicitações no default VirtualHost, vá para a próxima causa: O caminho não está associado a nenhum proxy de API.

Resolução

1. Adicione o VirtualHost ausente à configuração do ProxyEndpoint para resolver o problema. No exemplo mostrado acima, é possível adicionar o VirtualHost padrão para a configuração ProxyEndpoint desta maneira:

   <VirtualHost>default</VirtualHost>

   Exemplo de configuração do endpoint de proxy mostrando o padrão> VirtualHost&gt; sendo adicionados

   

2. Como alternativa, no exemplo mencionado acima, se você pretendia usar apenas o secure VirtualHost para esse proxy de API específico. Em seguida, faça as solicitações de API. somente para o VirtualHost secure usando o protocolo HTTPS:

   https://myorg-prod.apigee.net/weather

Causa: host virtual removido em uma revisão recém-implantada do proxy de API

Se uma nova revisão de um proxy de API for implantada após a remoção de um host virtual específico que fazia parte da revisão implantada anteriormente e que ainda está sendo usada pelos clientes para fazer solicitações de API, isso poderá causar o problema.

Diagnóstico

1. Verifique a configuração do Endpoint do proxy do proxy de API para ver se ele está configurado para aceitar as solicitações do host virtual especificado no erro. Isso é indicado pelo elemento VirtualHost na configuração ProxyEndpoint.
2. Se o host virtual especificado no erro não existir no ProxyEndpoint e execute as etapas a seguir. Caso contrário, vá para a próxima causa: Caminho não associado a nenhum proxy de API.
3. Compare a configuração do ProxyEndpoint da revisão implantada anteriormente com a atual na revisão implantada.
   1. Por exemplo, digamos que a revisão implantada anteriormente foi 5 e seu revisão implantada atualmente é 6:
      • Hosts virtuais configurados no endpoint de proxy na revisão 5

      <HTTPProxyConnection>
          <BasePath>/weather</BasePath>
          <Properties/>
          <VirtualHost>vh1</VirtualHost>
      </HTTPProxyConnection>
      

      • Hosts virtuais configurados no endpoint de proxy na revisão 6

      <HTTPProxyConnection>
          <BasePath>/weather</BasePath>
          <Properties/>
          <VirtualHost>secure</VirtualHost>
      </HTTPProxyConnection>
      

   2. No exemplo acima, VirtualHost vh1 existia em revision 5,. mas é removido em revision 6 e substituído por VirtualHost secure.
   3. Se você ou seus clientes fizerem as solicitações para o proxy de API usando VirtualHost vh1 (que fazia parte de revision 5), então você vai receber o Código de resposta 404 com a seguinte mensagem de erro:

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

4. Verifique se a alteração do host virtual foi feita intencionalmente ou acidentalmente na revisão implantada atualmente e as medidas apropriadas, conforme explicado na seção Resolução.

Resolução

Se você identificar que os hosts virtuais foram removidos em uma nova revisão, isso pode ter sido intencional ou acidente. Em cada caso, siga as etapas de resolução/recomendada a seguir para resolver o problema.

Cenário 1: mudança intencional

Caso a remoção do host virtual seja intencional, você pode escolher uma das seguintes opções com a primeira opção sendo a abordagem recomendada:

1. Criar um proxy com um caminho base diferente e usar um host virtual diferente (que não existe na revisão implantada anteriormente).

2. Se quiser continuar usando o proxy de API atual, mas com um host virtual diferente, é melhor reter o host virtual existente e adicionar o host virtual adicional.

   Isso vai garantir que os usuários desse proxy de API não sejam afetados pela mudança.

3. Se quiser usar o proxy de API existente e tiver apenas um host virtual diferente, informe os usuários com antecedência e faça essa alteração durante um período de manutenção.

   Isso garante que os usuários desse proxy de API estejam cientes da mudança e pode usar um host virtual diferente para fazer as chamadas para esse proxy de API. Portanto, eles vão não é afetado pela mudança.

Cenário 2: alteração não intencional

Caso a remoção do host virtual seja feita por engano e não de maneira intencional,faça o seguinte:

1. Atualize a configuração ProxyEndpoint na revisão implantada atualmente para usá-la os mesmos hosts virtuais usados na revisão implantada anteriormente. Na exemplo acima, altere a seguinte seção de:

   <HTTPProxyConnection>
       <BasePath>/weather</BasePath>
       <Properties/>
       <VirtualHost>secure</VirtualHost>
   </HTTPProxyConnection>
   

   a

   <HTTPProxyConnection>
       <BasePath>/weather</BasePath>
       <Properties/>
       <VirtualHost>vh1</VirtualHost>
   </HTTPProxyConnection>
   

2. Implante a revisão novamente.

Práticas recomendadas

É sempre aconselhável implantar novos proxies ou novas revisões durante um período de manutenção ou quando o tráfego é menos esperado, para que qualquer problema surgido durante a implantação possa ser evitadas ou o efeito no trânsito pode ser minimizado.

Causa: o caminho não está associado a nenhum proxy de API

Se o proxy de API não estiver configurado para aceitar as solicitações do caminho específico usado no URL de solicitação de API, poderemos receber uma resposta 404 Not Found com a mensagem de erro Unable to identify proxy for host: VIRTUAL_HOST and url: PATH.

Diagnóstico

1. Confira a configuração ProxyEndpoint do proxy de API específico que você quer. para fazer as solicitações de API.
2. Verificar se o proxy de API está configurado para aceitar as solicitações do caminho específico indicado na mensagem de erro. Para isso, siga as etapas em Cenário 1 e Cenário 2.

Cenário 1: o caminho não corresponde ao caminho de base do proxy de API

1. Se o path indicado na mensagem de erro não for igual ao basepath do proxy de API específico ou não começar com basepath, esse pode ser a causa do erro.
2. Vamos usar um exemplo para explicar isso:
1. O basepath do proxy de API pretendido é /weather
2. O URL da solicitação de API é https://myorg-prod.apigee.net/climate. Isso significa que o caminho usado no URL da solicitação de API é /climate.
3. Neste exemplo, o path não é o mesmo que o basepath e faz não comece com basepath. Portanto, você recebe o seguinte erro:

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

Resolução

1. Verifique se o path usado no URL da solicitação de API é o mesmo que o basepath do proxy de API específico.
2. No exemplo acima, o URL de solicitação de API deve ser o seguinte:

   {
   https://myorg-prod.apigee.net/weather
   

Cenário 2: o caminho não corresponde a nenhum dos fluxos condicionais disponíveis

1. Se o path usado no URL da solicitação de API começar com basepath, é possível que path suffix (a parte que vem depois do basepath) indicados na mensagem de erro não correspondem a nenhuma das condições que podem causar o erro 404.
2. Vamos usar um exemplo para explicar isso:
   1. O basepath do proxy de API pretendido é /weather
   2. O URL da solicitação de API é https://myorg-prod.apigee.net/weather/Delhi. Isso significa que o caminho usado no URL da solicitação de API é /weather/Delhi.
3. Neste exemplo, a path começa com o basepath /weather. Além disso, ele tem um path suffix de /Delhi.
4. Agora, verifique se há fluxos condicionais no ProxyEndpoint.
5. Se não houver fluxos condicionais ou se houver alguns fluxos não condicionais, vá para o próxima causa - Proxy de API não implantado em um ambiente.
6. Se o ProxyEndpoint tiver apenas fluxos condicionais, verifique o seguinte:
   1. Se as condições em todos esses fluxos condicionais procurarem um proxy.pathsuffix específico (o caminho após o caminho de base).
   2. Se o path suffix especificado no URL da solicitação de API não corresponder a nenhum dos as condições, essa será a causa do erro.
7. Digamos que temos dois fluxos na ProxyEndpoint e ambos são fluxos condicionais, como mostrado abaixo:

   <Condition>(proxy.pathsuffix MatchesPath "/Bangalore") and (request.verb = "GET")</Condition>
   
   <Condition>(proxy.pathsuffix MatchesPath "/Chennai") and (request.verb = "GET")</Condition>
   

   1. No exemplo mostrado acima, temos dois fluxos condicionais, um que corresponde proxy.pathsuffix (caminho após o caminho de base) para /Bangalore e o outro corresponde a /Chennai. Mas não há nenhum que corresponda a /Delhi que é o path suffix transmitido no URL de solicitação da API.
   2. Essa é a causa do erro 404. Portanto, você receberia o seguinte erro:

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

Resolução

1. Verifique se o path suffix corresponde a pelo menos um dos fluxos condicionais no endpoint do proxy.
2. No exemplo acima, é possível usar as seguintes abordagens para resolver o erro:
   1. Se você quiser executar qualquer conjunto específico de políticas para o caminho /Delhi, adicione um fluxo separado com o conjunto de políticas necessário e verifique se há uma condição que corresponde a /proxy.pathsuffix /Delhi, conforme mostrado abaixo:

      <Condition>(proxy.pathsuffix MatchesPath "/Delhi") and (request.verb = "GET")</Condition>

   2. Se você quiser executar um conjunto comum de políticas para o caminho /Delhi, então, em fluxo comum, é necessário que haja uma condição que permita /proxy.pathsuffix. Ou seja, qualquer caminho depois do basepath seria permitido. /weather, como mostrado abaixo:

      <Condition>(proxy.pathsuffix MatchesPath "/**") and (request.verb = "GET")</Condition>

Se o ProxyEndpoint tiver o basepath correto e o path suffix especificado no URL da API corresponder a um dos fluxos condicionais e passar para a próxima causa - Proxy de API não implantado em um ambiente.

Causa: o proxy de API não foi implantado em um ambiente

Diagnóstico

1. Determine o ambiente em que existe o alias de host usado no URL de solicitação de API. Isso pode ser feito verificando os detalhes de todos os hosts virtuais em cada um dos ambientes da organização na interface do Edge.

   Por exemplo, considere a seguinte configuração:

   • Se http://myorg-prod.apigee.net/weather é seu URL, myorg-prod.apigee.net é o alias de host.
   • O alias de host myorg-prod.apigee.net está configurado como parte de um dos hosts virtuais no ambiente prod da organização.
2. Verifique se o proxy de API específico está implantado no ambiente determinado no etapa 1 acima.
3. Se o proxy de API não estiver implantado no ambiente específico, essa será a causa do o erro 404.
   1. No exemplo usado na etapa 1 acima, o proxy de API não está implantado na prod, essa será a causa do erro.
   2. Acesse a seção Resolução abaixo.
4. Se o proxy de API estiver implantado no ambiente específico, vá para a próxima causa: Ambiente não carregado nos processadores de mensagens.

Resolução

Implante o proxy de API no ambiente específico em que você pretende fazer solicitações de API.

Causa: ambiente não carregado nos processadores de mensagens

Diagnóstico

1. Faça login em cada um dos processadores de mensagens e verifique se o ambiente específico em que que estão fazendo a solicitação de API ser carregada no processador de mensagens usando o seguinte comando:

   curl -v 0:8082/v1/runtime/organizations/<orgname>/environments

2. Se o ambiente específico estiver listado como parte do comando acima, vá para a próxima causa: O proxy de API não foi implantado em um ou mais processadores de mensagens.
3. Se o ambiente específico não estiver listado, verifique /opt/apigee/var/log/edge-message-processor/logs/system.log e /opt/apigee/var/log/edge-message-processor/logs/startupruntimeerrors.log no(a) Processadores de mensagens em busca de erros durante o carregamento de ambientes.
4. Pode haver muitos erros diferentes que podem levar à falha de carregamento de um ambiente o processador de mensagens. 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 resolver o problema.

1. Se um dos erros a seguir aparecer no registro do processador de mensagens, ele foi causado por um erro. problema encontrado com os certificados/chaves que foram 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

2. Obtenha os detalhes do keystore/truststore especificado na mensagem de erro mostrada no 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> 

   e
   

   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 sim, é é melhor ter um único certificado e uma só 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 se ocorrer algum erro diferente dos mencionados na etapa 1 acima, acesse É preciso coletar informações de diagnóstico.

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

O proxy de API não pode ser implantado em um ou mais processadores de mensagens. Esse problema ocorre muito raramente e acontece principalmente devido à ausência de uma notificação de evento do servidor de gerenciamento para Processador de mensagens durante a implantação do proxy de API específico. Nesse caso também, você 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 O proxy de API está implantado ou não usando o seguinte comando:

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

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.
3. Repita as etapas 1 e 2 para todos os processadores de mensagens.
4. Se a revisão específica do proxy de API for implantada em todos os processadores de mensagens, essa não é a causa do problema. Ir para É necessário coletar informações de diagnóstico.

Resolução

Reiniciar os processadores de mensagens específicos em que a revisão específica do proxy de API está não implantado.

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

Diagnosticar problemas usando a API Monitoring

O API Monitoring permite isolar áreas problemáticas rapidamente para diagnosticar problemas de erro, desempenho e latência e a origem deles, como apps de desenvolvedores, Proxies de API, destinos de back-end ou a plataforma de API.

Para esse problema, acesse Monitoramento de APIs > Investigar e escolha a data apropriada, proxy etc. e você poderá ver os seguintes detalhes:

• Código da falha:messaging.adaptors.http.flow.ApplicationNotFound
• Código de status: 404
• Origem da falha:Apigee ou MP

Além disso, você pode clicar em Ver registros, como mostrado na captura de tela acima, e verificar mais.

Confira um exemplo de cenário que demonstra como solucionar problemas de 5xx com suas APIs usando o monitoramento de APIs. Por exemplo, é possível quiser definir um alerta para ser notificado quando o número de códigos de status 404 exceder um um limite específico.

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

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

1. Se você é usuário da nuvem pública, forneça as seguintes informações:
   • Nome da organização
   • Nome do ambiente
   • Nome do proxy da API
   • Complete o comando curl para reproduzir o erro
2. Se você é usuário da nuvem privada, forneça as seguintes informações:
   • Mensagem de erro completa observada
   • Nome do ambiente
   • Pacote de proxy de API
   • Registros do processador de mensagens /opt/apigee/var/log/edge-message-processor/logs/system.log
   • Saída dos comandos a seguir em cada um dos processadores de mensagens.

   curl -v 0:8082/v1/runtime/organizations/<orgname>/environments

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

3. Detalhes sobre quais seções deste playbook você testou e outros insights que nos ajudarão a acelerar a resolução do problema.