404 Impossibile identificare il proxy per l'host: <nome host virtuale> e url: <path>

Stai visualizzando la documentazione di Apigee Edge.
Consulta la documentazione di Apigee X. info

Sintomo

L'applicazione client riceve un codice di stato HTTP 404 con il messaggio Not Found e il messaggio di errore Unable to identify proxy for host: VIRTUAL_HOST and url: PATH come risposta alle chiamate API.

Questo errore significa che Edge non è riuscito a trovare il proxy API per l'host virtuale e il percorso specificati.

Messaggio di errore

Riceverai il seguente codice di stato HTTP:

HTTP/1.1 404 Not Found

Verrà visualizzato anche un messaggio di errore simile a quello mostrato di seguito:

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

Il messaggio di errore riportato sopra indica che Edge non è riuscito a trovare il proxy API per l'host virtuale default e il percorso /oauth2/token.

Possibili cause

Di seguito sono elencate alcune delle possibili cause di questo errore:

Passaggi di diagnostica comuni

I log di NGINX e del processore di messaggi saranno utili per risolvere l'errore 404. Per controllare i log:

1. Visualizza i log NGINX utilizzando il seguente comando:

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

2. Controlla la presenza dei seguenti campi nelle voci di log:

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

   Prendi nota dell'ID messaggio dai log.

3. Controlla i log del processore di messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log)) per verificare se disponi di messaging.adaptors.http.flow.ApplicationNotFound per l'API specifica o se hai l'ID messaggio univoco del passaggio 2 per la richiesta API.

   Esempio di messaggio di errore del log del processore di messaggi

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)

Il log riportato sopra mostra il codice di errore e il messaggio di errore come segue:

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

Causa: proxy API non associato all'host virtuale specifico

Se il proxy API non è configurato per accettare le richieste per l'host virtuale specifico, possiamo ricevere una risposta 404 Not Found con il messaggio di errore Unable to identify proxy for host: VIRTUAL_HOST and url: PATH.

Diagnosi

1. Controlla la configurazione dell'endpoint proxy per il proxy API e verifica se il proxy API è configurato per accettare le richieste per l'host virtuale specificato nell'errore. Ciò è indicato dall'elemento VirtualHost. Per capire meglio, esaminiamo una configurazione ProxyEndpoint di esempio.

   Configurazione dell'endpoint proxy di esempio che mostra che il proxy API accetta richieste su un host virtuale sicuro

   

2. Supponiamo che gli host virtuali siano definiti nell'ambiente specifico come segue:

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

3. Effettui una richiesta API a default VirtualHost utilizzando l'URL http://myorg-prod.apigee.net/weather
4. Poiché ProxyEndpoint non ha default VirtualHost come mostrato nell'esempio precedente, ricevi il codice di risposta 404 con il seguente messaggio di errore:

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

5. Per risolvere il problema, consulta la sezione Soluzione di seguito.
6. Se ProxyEndpoint è configurato per accettare le richieste su default VirtualHost, vai alla causa successiva: Il percorso non è associato ad alcun proxy API.

Risoluzione

1. Aggiungi il valore VirtualHost mancante alla configurazione ProxyEndpoint per risolvere il problema. Per l'esempio mostrato sopra, puoi aggiungere VirtualHost alla configurazione ProxyEndpoint nel seguente modo:

   <VirtualHost>default</VirtualHost>

   Configurazione di un endpoint proxy di esempio che mostra l'aggiunta di VirtualHost predefinito

   

2. In alternativa, nell'esempio riportato sopra, se intendevi utilizzare solo secure VirtualHost per questo proxy API specifico, invia le richieste API solo a secure VirtualHost utilizzando il protocollo HTTPS:

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

Causa: host virtuale rimosso in una revisione del proxy API di cui è stato eseguito il deployment di recente

Se viene eseguito il deployment di una nuova revisione di un proxy API dopo la rimozione di un host virtuale specifico (che faceva parte della revisione di cui è stato eseguito il deployment in precedenza) e che viene ancora utilizzato dai client per effettuare richieste API, può verificarsi questo problema.

Diagnosi

1. Controlla la configurazione dell'endpoint proxy per il proxy API per verificare se il proxy API è configurato per accettare le richieste per l'host virtuale specificato nell'errore. Ciò è indicato dall'elemento VirtualHost nella configurazione ProxyEndpoint.
2. Se l'host virtuale specificato nell'errore non esiste nella configurazione di ProxyEndpoint, esegui i seguenti passaggi. Altrimenti, vai alla causa successiva: Il percorso non è associato ad alcun proxy API.
3. Confronta la configurazione ProxyEndpoint della revisione di cui è stato eseguito il deployment in precedenza con quella della revisione di cui è stato eseguito il deployment attualmente.
   1. Ad esempio, supponiamo che la revisione di cui è stato eseguito il deployment in precedenza fosse 5 e che la revisione di cui è stato eseguito il deployment attualmente sia 6:
      • Host virtuali configurati nell'endpoint proxy nella revisione 5

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

      • Host virtuali configurati nell'endpoint proxy nella revisione 6

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

   2. Nell'esempio precedente, VirtualHost vh1 esisteva in revision 5, ma viene rimosso in revision 6 e sostituito con VirtualHost secure.
   3. Pertanto, se tu o i tuoi clienti effettuate le richieste a questo proxy API utilizzando VirtualHost vh1 (che faceva parte di revision 5), riceverai il codice di risposta 404 con il seguente messaggio di errore:

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

4. Verifica se la modifica dell'host virtuale è stata apportata intenzionalmente o involontariamente nella revisione attualmente implementata e adotta le misure appropriate come spiegato nella sezione Risoluzione.

Risoluzione

Se identifichi che gli host virtuali vengono rimossi in una nuova revisione, potrebbe essere intenzionale o per errore. Per ogni caso, esegui i passaggi di risoluzione/consigliati riportati di seguito per risolvere il problema.

Scenario 1: modifica intenzionale

Se la rimozione dell'host virtuale è intenzionale, puoi scegliere una delle seguenti opzioni. La prima è l'approccio consigliato:

1. Crea un nuovo proxy con un percorso di base diverso e utilizza un host virtuale diverso (che non esiste nella revisione di cui è stato eseguito il deployment in precedenza).

2. Se vuoi continuare a utilizzare il proxy API esistente, ma utilizzare un host virtuale diverso, è meglio conservare l'host virtuale esistente e aggiungere l'host virtuale aggiuntivo.

   In questo modo, gli utenti di questo proxy API non saranno interessati dalla modifica.

3. Se vuoi utilizzare il proxy API esistente e hai solo un host virtuale diverso, informa in anticipo i tuoi utenti ed esegui questa modifica durante un periodo di manutenzione.

   In questo modo, gli utenti di questo proxy API saranno a conoscenza della modifica e potranno utilizzare un host virtuale diverso per effettuare le chiamate a questo proxy API. Pertanto, non saranno interessati dalla modifica.

Scenario 2: modifica involontaria

Se la rimozione dell'host virtuale è stata eseguita per errore e non intenzionalmente,segui questi passaggi:

1. Aggiorna la configurazione ProxyEndpoint nella revisione attualmente implementata per utilizzare gli stessi host virtuali utilizzati nella revisione implementata in precedenza. Nell'esempio precedente, modifica la seguente sezione da:

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

   a

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

2. Esegui nuovamente il deployment della revisione.

Best practice

È sempre consigliabile eseguire il deployment di nuovi proxy o nuove revisioni durante un periodo di manutenzione o quando il traffico è previsto al minimo, in modo da evitare eventuali problemi durante il deployment o ridurre al minimo l'effetto sul traffico.

Causa: percorso non associato ad alcun proxy API

Se il proxy API non è configurato per accettare le richieste per il percorso specifico utilizzato nell'URL della richiesta API, possiamo ricevere una risposta 404 Not Found con il messaggio di errore Unable to identify proxy for host: VIRTUAL_HOST and url: PATH.

Diagnosi

1. Esamina la configurazione ProxyEndpoint per il proxy API specifico per cui intendevi effettuare le richieste API.
2. Controlla se il proxy API è configurato per accettare le richieste per il percorso specifico indicato nel messaggio di errore. Per farlo, segui i passaggi descritti nello Scenario 1 e nello Scenario 2.

Scenario 1: il percorso non corrisponde al basepath del proxy API

1. Se il path indicato nel messaggio di errore non corrisponde al basepath del proxy API specifico o non inizia con il basepath, allora potrebbe essere la causa dell'errore.
2. Vediamo un esempio per spiegare questo concetto:
1. Il basepath del proxy API previsto è /weather
2. L'URL della richiesta API è https://myorg-prod.apigee.net/climate. Ciò significa che il percorso utilizzato nell'URL della richiesta API è /climate.
3. In questo esempio, path non è uguale a basepath e non inizia con basepath. Pertanto, viene visualizzato il seguente errore:

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

Risoluzione

1. Assicurati che path utilizzato nell'URL della richiesta API sia uguale a basepath del proxy API specifico.
2. Nell'esempio precedente, l'URL della richiesta API dovrebbe essere il seguente:

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

Scenario n. 2: il percorso non corrisponde a nessuno dei flussi condizionali disponibili

1. Se path utilizzato nell'URL della richiesta API inizia con basepath, è possibile che path suffix (la parte che segue basepath) indicato nel messaggio di errore non corrisponda a nessuno dei flussi condizionali, il che potrebbe causare l'errore 404.
2. Facciamo un esempio per spiegare questo concetto:
   1. Il basepath del proxy API previsto è /weather
   2. L'URL della richiesta API è https://myorg-prod.apigee.net/weather/Delhi. Ciò significa che il percorso utilizzato nell'URL della richiesta API è /weather/Delhi.
3. In questo esempio, path inizia con basepath /weather. Inoltre, ha un path suffix di /Delhi.
4. Ora controlla se sono presenti flussi condizionali in ProxyEndpoint.
5. Se non sono presenti flussi condizionali o sono presenti alcuni flussi non condizionali, vai alla causa successiva: Proxy API non di cui non è stato eseguito il deployment in un ambiente.
6. Se il ProxyEndpoint contiene solo flussi condizionali, controlla quanto segue:
   1. Se le condizioni in tutti questi flussi condizionali controllano un proxy.pathsuffix specifico (il percorso dopo il percorso di base).
   2. Se il path suffix specificato nell'URL della richiesta API non corrisponde a nessuna delle condizioni, questo è il motivo dell'errore.
7. Supponiamo di avere due flussi in ProxyEndpoint ed entrambi siano flussi condizionali, come mostrato di seguito:

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

   1. Nell'esempio mostrato sopra, abbiamo due flussi condizionali, uno che corrisponde a proxy.pathsuffix (percorso dopo il percorso di base) a /Bangalore e l'altro che corrisponde a /Chennai. Ma nessuno corrisponde a /Delhi che è il path suffix passato nell'URL della richiesta API.
   2. Questo è il motivo dell'errore 404. Pertanto, riceverai il seguente errore:

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

Risoluzione

1. Assicurati che path suffix corrisponda ad almeno uno dei flussi condizionali nell'endpoint proxy.
2. Nell'esempio precedente, puoi utilizzare uno dei seguenti approcci per risolvere l'errore:
   1. Se vuoi eseguire un insieme specifico di policy per il percorso /Delhi, aggiungi un flusso separato con l'insieme di policy richiesto e assicurati che esista una condizione che corrisponda a /proxy.pathsuffix /Delhi come mostrato di seguito:

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

   2. Se vuoi eseguire un insieme comune di norme per il percorso /Delhi, nel flusso comune assicurati che esista una condizione che consenta un /proxy.pathsuffix generico. ovvero consentirebbe qualsiasi percorso dopo basepath /weather come mostrato di seguito:

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

Se ProxyEndpoint ha il basepath corretto e il path suffix specificato nell'URL dell'API corrisponde a uno dei flussi condizionali, passa alla causa successiva: Proxy API non implementato in un ambiente.

Causa: il proxy API non è stato sottoposto a deployment in un ambiente

Diagnosi

1. Determina l'ambiente in cui esiste l'alias host utilizzato nell'URL della richiesta API. Per farlo, controlla i dettagli di tutti gli host virtuali in ciascuno degli ambienti della tua organizzazione nell'interfaccia utente Edge.

   Ad esempio, supponiamo la seguente configurazione:

   • Se http://myorg-prod.apigee.net/weather è il tuo URL, allora myorg-prod.apigee.net è l'alias host.
   • L'alias host myorg-prod.apigee.net è configurato come parte di uno degli host virtuali nell'ambiente prod della tua organizzazione.
2. Verifica se il proxy API specifico è stato eseguito il deployment nell'ambiente specifico determinato nel passaggio 1 precedente.
3. Se il proxy API non viene eseguito il deployment nell'ambiente specifico, questo è il motivo dell'errore 404.
   1. Quindi, nell'esempio utilizzato nel passaggio 1 sopra, supponiamo che il proxy API non sia implementato nell'ambiente prod, quindi questo è il motivo dell'errore.
   2. Vai alla sezione Risoluzione di seguito.
4. Se il proxy API è stato deployment nell'ambiente specifico, vai alla causa successiva: Ambiente non caricato sui processori di messaggi.

Risoluzione

Esegui il deployment del proxy API nell'ambiente specifico in cui intendi effettuare richieste API.

Causa: ambiente non caricato sui processori di messaggi

Diagnosi

1. Accedi a ciascun processore di messaggi e controlla se l'ambiente specifico in cui stai effettuando la richiesta API è caricato sul processore di messaggi utilizzando il seguente comando:

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

2. Se l'ambiente specifico è elencato nel comando precedente, vai alla causa successiva: proxy API non sottoposto a deployment su uno o più processori di messaggi.
3. Se l'ambiente specifico non è elencato, controlla /opt/apigee/var/log/edge-message-processor/logs/system.log e /opt/apigee/var/log/edge-message-processor/logs/startupruntimeerrors.log in Message Processors per eventuali errori durante il caricamento degli ambienti.
4. Potrebbero verificarsi molti errori diversi che potrebbero causare il mancato caricamento di un ambiente nel processore di messaggi. La risoluzione dipende dall'errore che si è verificato.

Risoluzione

L'ambiente potrebbe non essere caricato sul processore di messaggi per diversi motivi. Questa sezione illustra un paio di possibili motivi che possono causare questo problema e spiega come risolverlo.

1. Se nel log del processore di messaggi viene visualizzato uno dei seguenti errori, il problema è causato da un problema riscontrato con i certificati/le chiavi aggiunti al keystore/truststore specificato nell'ambiente specificato.

   Errore n. 1: java.security.KeyStoreException: Cannot overwrite own certificate

   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

   Errore n. 2: java.security.KeyStoreException: Cannot overwrite secret key

   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. Recupera i dettagli del keystore/truststore specificato nel messaggio di errore mostrato nel passaggio precedente utilizzando la seguente chiamata API di gestione:

   curl -v "http://<management-IPaddress>:8080/v1/organizations/<org-name>/environments/<env-name>/keystores/myTruststore" -u <user> 

   
   

   Output di esempio:

   {
      "certs":[
         "mycert",
         "mycert-new"
      ],
      "keys":[
         "mycert"
      ],
      "name":"myTruststore"
   }

3. L'output di esempio mostra che nel truststore myTruststore sono presenti due certificati e una chiave. In genere, il truststore non contiene una chiave. In questo caso, è meglio avere un unico certificato e un'unica chiave.
4. Recupera i dettagli dei due certificati utilizzando la seguente API:

   curl -s http://<management-IPaddress>:8080/v1/runtime/organizations/<org-name>/environments/<env-name>/keystores/<keystore-name>/certs/<cert-name>
   

5. Controlla la data di scadenza di ciascun certificato e determina il certificato scaduto/precedente.
6. Elimina il certificato scaduto o indesiderato dall'archivio di attendibilità myTruststore.

Se il problema persiste o se visualizzi un errore diverso da quelli menzionati nel passaggio 1 sopra, vai a Informazioni diagnostiche da raccogliere.

Causa: proxy API non di cui è stato eseguito il deployment su uno o più processori di messaggi

Il proxy API potrebbe non essere sottoposto a deployment su uno o più processori di messaggi. Questo problema si verifica molto raramente e si verifica principalmente a causa di una notifica di un evento mancante dal server di gestione al processore di messaggi durante il deployment del proxy API specifico. Anche in questo caso, non potrai creare la sessione di tracciamento nella UI di Edge.

Diagnosi

1. Accedi a ciascun processore di messaggi e controlla se la revisione specifica del proxy API è stata o meno implementata utilizzando il seguente comando:

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

2. Se la revisione specifica del proxy API non viene visualizzata come output del comando menzionato nel passaggio 1 precedente, riavvia il processore di messaggi specifico come spiegato in Risoluzione.
3. Ripeti i passaggi 1 e 2 per tutti i Message Processor.
4. Se la revisione specifica del proxy API viene implementata su tutti i processori di messaggi, allora non è la causa di questo problema. Vai a Must gather diagnostic information.

Risoluzione

Riavvia i processori di messaggi specifici su cui non è stato eseguito il deployment della revisione specifica del proxy API.

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

Diagnostica i problemi utilizzando API Monitoring

Il monitoraggio delle API ti consente di isolare rapidamente le aree problematiche per diagnosticare errori, problemi di prestazioni e latenza e la loro origine, ad esempio app per sviluppatori, proxy API, target di backend o la piattaforma API.

Per questo problema, puoi andare alla pagina Monitoraggio API > Esamina e scegliere la data, il proxy e così via appropriati. Potresti visualizzare i seguenti dettagli:

• Codice guasto: messaging.adaptors.http.flow.ApplicationNotFound
• Codice di stato: 404
• Origine del guasto: Apigee o MP

Inoltre, puoi fare clic su Visualizza log come mostrato nello screenshot sopra e controllare ulteriormente.

Esegui la procedura dettagliata di uno scenario di esempio mostra come risolvere i problemi di 5xx con le tue API utilizzando API Monitoring. Ad esempio, potresti configurare un avviso per ricevere una notifica quando il numero di codici di stato 404 supera una determinata soglia.

Deve raccogliere informazioni diagnostiche

Se il problema persiste anche dopo aver seguito le istruzioni riportate sopra, raccogli le seguenti informazioni diagnostiche. Contatta e condividi queste informazioni con l'assistenza Apigee Edge.

1. Se sei un utente del cloud pubblico, fornisci le seguenti informazioni:
   • Nome organizzazione
   • Nome ambiente
   • Nome del proxy API
   • Comando curl completo per riprodurre l'errore
2. Se sei un utente di Private Cloud, fornisci le seguenti informazioni:
   • Messaggio di errore completo osservato
   • Nome ambiente
   • Bundle proxy API
   • Log del processore di messaggi /opt/apigee/var/log/edge-message-processor/logs/system.log
   • Output dei seguenti comandi su ciascuno dei processori di messaggi.

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

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

3. Dettagli sulle sezioni di questo playbook che hai provato e su eventuali altre informazioni che ci aiuteranno a risolvere rapidamente il problema.