Questa pagina è stata tradotta dall'API Cloud Translation.

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

Stai visualizzando la documentazione di Apigee Edge.
Vai alla documentazione di Apigee X. informazioni

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 in risposta alle chiamate API.

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

Messaggio di errore

Verrà visualizzato il seguente codice di stato HTTP:

HTTP/1.1 404 Not Found

Riceverai 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

Alcune delle possibili cause di questo errore sono elencate di seguito:

Causa	Descrizione	Istruzioni per la risoluzione dei problemi applicabili a
Proxy API non associato all'host virtuale specifico	Il proxy API specifico non è configurato per accettare richieste sull'host virtuale specificato nel messaggio di errore.	Utenti di cloud pubblico e privato perimetrale
Host virtuale rimosso in una revisione di cui è stato eseguito il deployment del proxy API	Il problema può essere causato dalla rimozione dell'host virtuale dalla revisione di cui è stato appena eseguito il deployment mentre il client utilizza ancora l'host virtuale specifico.	Utenti di cloud pubblico e privato perimetrale
Percorso non associato ad alcun proxy API	Il proxy API specifico non è configurato per accettare richieste nel percorso specificato nel messaggio di errore.	Utenti di cloud pubblico e privato perimetrale
Proxy API di cui non è stato eseguito il deployment in un ambiente	Il proxy API specifico non è stato eseguito nell'ambiente specifico in cui stai tentando di effettuare le richieste API.	Utenti di cloud pubblico e privato perimetrale
Ambiente non caricato sul processore di messaggi	L'ambiente specifico (in cui stai tentando di effettuare le richieste API) non è stato caricato sui processori di messaggi a causa di un errore.	Utenti del cloud privato perimetrale
Impossibile eseguire il deployment del proxy API su uno o più processori di messaggi	Potrebbe non essere eseguito il deployment del proxy API su uno o più processori di messaggi a causa della mancata notifica degli eventi durante il deployment.	Utenti del cloud privato perimetrale

Passaggi di diagnosi più comuni

I log di NGINX e del processore di messaggi saranno utili per la risoluzione dell'errore 404. Per controllare i log:

Visualizza i log NGINX utilizzando il seguente comando:

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

Controlla i 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 dei log.

Controlla i log del processore di messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log) per verificare se hai messaging.adaptors.http.flow.ApplicationNotFound per l'API specifica o se disponi dell'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 e il messaggio di errore come segue:

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

Nota: i valori url e host precedenti possono variare a seconda del proxy API per cui hai riscontrato il problema.

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 ottenere una risposta 404 Not Found con il messaggio di errore Unable to identify proxy for host: VIRTUAL_HOST and url: PATH.

Diagnostica

Controlla la configurazione Endpoint proxy del proxy API e verifica se quest'ultimo è configurato in modo da accettare le richieste per l'host virtuale specificato nell'errore. Ciò è indicato dall'elemento VirtualHost. Diamo un'occhiata a una configurazione ProxyEndpoint di esempio per capire meglio questo concetto.
Esempio di configurazione di endpoint proxy che mostra che il proxy API accetta richieste su un host virtuale sicuro

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`

Effettua una richiesta API a default VirtualHost utilizzando l'URL http://myorg-prod.apigee.net/weather

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"}}}

Vai alla sezione Risoluzione di seguito per risolvere il problema.
Se ProxyEndpoint è configurato per accettare le richieste su default VirtualHost, vai alla causa successiva: Percorso non associato ad alcun proxy API.

Risoluzione

Aggiungi il valore VirtualHost mancante alla configurazione di ProxyEndpoint per risolvere il problema. Per l'esempio mostrato sopra, puoi aggiungere il valore predefinito VirtualHost alla configurazione di ProxyEndpoint nel seguente modo:
```
<VirtualHost>default</VirtualHost>
```
Esempio di configurazione di endpoint proxy che mostra l'aggiunta predefinita> VirtualHost> in fase di aggiunta
In alternativa, nell'esempio citato in precedenza, se volevi 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 nuova revisione del proxy API di cui è stato eseguito il deployment

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), che è ancora utilizzato dai client per le richieste API, può verificarsi questo problema.

Diagnostica

Controlla la configurazione Endpoint proxy del proxy API per verificare se quest'ultimo è configurato in modo da accettare le richieste per l'host virtuale specificato nell'errore. Ciò è indicato dall'elemento VirtualHost nella configurazione ProxyEndpoint.
Se l'host virtuale specificato nell'errore non esiste nella configurazione ProxyEndpoint, svolgi i passaggi che seguono. Altrimenti, vai alla causa successiva: Percorso non associato ad alcun proxy API.
Confronta la configurazione ProxyEndpoint della revisione di cui è stato eseguito il deployment in precedenza con la revisione attualmente di cui è stato eseguito il deployment.
1. Ad esempio, supponiamo che la revisione di cui hai eseguito il deployment in precedenza sia stata 5 e che la revisione attualmente sottoposta a deployment sia 6:
  - Host virtuali configurati nell'endpoint proxy nella revisione 5
  - Host virtuali configurati nell'endpoint proxy nella revisione 6
2. Nell'esempio precedente, VirtualHost vh1 esisteva in revision 5, ma è stato rimosso in revision 6 e sostituito con VirtualHost secure.
3. Pertanto, se tu o i tuoi client state inviando 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"}}}
```
Verifica se la modifica dell'host virtuale è stata apportata intenzionalmente o involontariamente nella revisione attualmente sottoposta a deployment e adotta le misure appropriate come spiegato nella sezione Risoluzione.

Risoluzione

Se noti che l'host virtuale o gli host vengono rimossi in una nuova revisione, potrebbe essere stato intenzionale o potrebbe essere stato accidentale. Per ogni caso, segui la risoluzione o i passaggi consigliati che seguono per risolvere il problema.

Scenario 1: cambiamento intenzionale

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

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).
Se vuoi continuare a utilizzare il proxy API esistente, ma usi un host virtuale diverso, è meglio mantenere l'host virtuale esistente e aggiungere l'host virtuale aggiuntivo.

In questo modo, gli utenti di questo proxy API non saranno interessati dalla modifica.
Se vuoi utilizzare il proxy API esistente e hai solo un host virtuale diverso, informa gli utenti in anticipo ed esegui la modifica durante il 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. Di conseguenza, non saranno interessate dalla modifica.

Scenario 2: cambiamento involontario

Se la rimozione dell'host virtuale è stata effettuata per errore e non intenzionale,procedi nel seguente modo:

Aggiorna la configurazione ProxyEndpoint nella revisione attualmente di cui è stato eseguito il deployment in modo da utilizzare gli stessi host virtuali utilizzati nella revisione di cui è stato eseguito il deployment in precedenza. Nell'esempio precedente, modifica la seguente sezione da:
```
<HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>
```
a una
```
<HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>vh1</VirtualHost>
</HTTPProxyConnection>
```
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 è previsto il traffico minimo, in modo da evitare eventuali problemi che si verifichino durante il deployment o da 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 ottenere una risposta 404 Not Found con il messaggio di errore Unable to identify proxy for host: VIRTUAL_HOST and url: PATH.

Diagnostica

Controlla la configurazione ProxyEndpoint per il proxy API specifico per il quale intendi effettuare le richieste API.
Verifica se il proxy API è configurato per accettare le richieste per il percorso specifico indicato nel messaggio di errore. A tale scopo, segui i passaggi nello Scenario n. 1 e nello Scenario n. 2.

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

Se l'elemento path indicato nel messaggio di errore non corrisponde a quello del proxy API specifico (basepath) o non inizia con basepath, questa potrebbe essere la causa dell'errore.
Facciamo un esempio per spiegare questo concetto:

Il valore basepath del proxy API previsto è /weather
L'URL della richiesta API è https://myorg-prod.apigee.net/climate. Ciò significa che il percorso utilizzato nell'URL della richiesta API è /climate.

In questo esempio, path non è uguale a basepath e non inizia con basepath. Viene quindi visualizzato il seguente errore:

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

Risoluzione

Assicurati che il valore path utilizzato nell'URL della richiesta API corrisponda al valore basepath dello specifico proxy API.
Nell'esempio precedente, l'URL della richiesta API deve essere il seguente:
```
{
https://myorg-prod.apigee.net/weather
```

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

Se il valore path utilizzato nell'URL di richiesta API inizia con basepath, è possibile che path suffix (la parte che segue il basepath) indicata nel messaggio di errore non corrisponda a nessuno dei flussi condizionali, quindi è possibile che si verifichi l'errore 404.
Facciamo un esempio per spiegare questo concetto:
1. Il valore 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.
In questo esempio, path inizia con basepath /weather. Inoltre, ha un path suffix pari a /Delhi.
Ora controlla se sono presenti flussi condizionali in ProxyEndpoint.
Se non sono presenti flussi condizionali o se sono presenti alcuni flussi non condizionali, vai alla causa successiva: il deployment del proxy API non è stato eseguito in un ambiente.
Se ProxyEndpoint ha solo flussi condizionali, verifica quanto segue:
1. Se le condizioni di tutti questi flussi condizionali vengono controllate per un valore proxy.pathsuffix specifico (il percorso dopo il percorso base).
2. Se l'elemento path suffix specificato nell'URL della richiesta API non corrisponde a nessuna delle condizioni, allora questa è la causa dell'errore.
Supponiamo di avere due flussi in ProxyEndpoint e che 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 base) a /Bangalore e l'altro che corrisponde a /Chennai. Tuttavia, nessuna corrisponde a /Delhi, ovvero il valore path suffix trasmesso nell'URL della richiesta API.
2. Questa è la causa dell'errore 404. Riceverai quindi il seguente errore:
```
{
   "fault":{
      "faultstring":"Unable to identify proxy for host: secure and url: \/weather\/Delhi",
      "detail":{
         "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
      }
   }
}
```

Risoluzione

Assicurati che path suffix corrisponda ad almeno uno dei flussi condizionali nel tuo endpoint proxy.
Per risolvere l'errore, nell'esempio riportato sopra puoi utilizzare i seguenti approcci:
1. Se vuoi eseguire un insieme specifico di criteri per il percorso /Delhi, aggiungi un flusso separato con l'insieme di criteri richiesto e assicurati che esista una condizione che corrisponda al /Delhi di /proxy.pathsuffix, come mostrato di seguito:
```
<Condition>(proxy.pathsuffix MatchesPath "/Delhi") and (request.verb = "GET")</Condition>
```
2. Se vuoi eseguire un insieme comune di criteri per il percorso /Delhi, nel flusso comune assicurati che esista una condizione che consenta un /proxy.pathsuffix generico. Ciò significa che sarebbe consentito qualsiasi percorso dopo basepath /weather, come mostrato di seguito:
```
<Condition>(proxy.pathsuffix MatchesPath "/**") and (request.verb = "GET")</Condition>
```

Se ProxyEndpoint ha il valore 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 deployment del proxy API non è stato eseguito in un ambiente

Diagnostica

Determina l'ambiente in cui si trova l'alias host utilizzato nell'URL della richiesta API. A questo scopo, controlla i dettagli di tutti gli host virtuali in ciascuno degli ambienti della tua organizzazione nella UI perimetrale.
Ad esempio, supponiamo che la configurazione sia la seguente:
- Se http://myorg-prod.apigee.net/weather è il tuo URL, 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.
Verifica se è stato eseguito il deployment del proxy API specifico nell'ambiente specifico determinato nel passaggio 1 riportato sopra.
Se il deployment del proxy API non è stato eseguito nell'ambiente specifico, è questa la causa dell'errore 404.
1. Nell'esempio utilizzato nel passaggio 1 precedente, supponiamo che il deployment del proxy API non sia stato eseguito nell'ambiente prod e che sia questa la causa dell'errore.
2. Vai alla sezione Risoluzione di seguito.
Se è stato eseguito il deployment del proxy API 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 nei processori di messaggi

Diagnostica

Accedi a ciascuno dei processori 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
```
Se l'ambiente specifico è elencato come parte del comando precedente, vai alla causa successiva: il deployment del proxy API non è stato eseguito su uno o più processori di messaggi.
Se l'ambiente specifico non è in elenco, verifica la presenza di /opt/apigee/var/log/edge-message-processor/logs/system.log e /opt/apigee/var/log/edge-message-processor/logs/startupruntimeerrors.log nei processori di messaggi per verificare la presenza di eventuali errori durante il caricamento degli ambienti.
Potrebbero esserci molti errori diversi che potrebbero portare al mancato caricamento di un ambiente sul 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.

Se vedi uno dei seguenti errori nel log del processore di messaggi, significa che è stato rilevato un problema con i certificati/le chiavi che sono stati aggiunti all'archivio chiavi/archivio attendibilità specificato nell'ambiente specificato.

Errore 1: java.security.KeyStoreException: impossibile sovrascrivere il proprio certificato

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 2: java.security.KeyStoreException: impossibile sovrascrivere la chiave segreta

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

Recupera i dettagli dell'archivio chiavi/dell'archivio attendibilità 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"
}

L'output di esempio mostra che ci sono due certificati e una chiave nell'archivio attendibilità myTruststore. In genere l'archivio attendibilità non contiene una chiave. Se sì, è meglio avere un singolo certificato e un'unica chiave.

Ottieni i dettagli sui 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>

Controlla la data di scadenza di ciascuno dei certificati e determina se il certificato è scaduto o meno.
Elimina il certificato scaduto o indesiderato dall'archivio attendibilità myTruststore.

Se il problema persiste o se ricevi errori diversi da quelli menzionati nel passaggio 1, vai a Devi raccogliere informazioni diagnostiche.

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

Potrebbe non essere stato eseguito il deployment del proxy API su uno o più processori di messaggi. Questo problema si verifica molto raramente e si verifica principalmente a causa di una notifica di eventi mancante dal server di gestione al processore di messaggi durante il deployment del proxy API specifico. Inoltre, in questo caso non potrai creare la sessione di traccia nella UI di Edge.

Diagnostica

Accedi a ciascuno dei processori di messaggi e controlla se è stato eseguito il deployment della revisione specifica del proxy API o se non è stato eseguito il deployment utilizzando il seguente comando:
```
curl -v 0:8082/v1/runtime/organizations/<orgname>/environments/<envname>/apis/<apiname>/revisions
```
Se la revisione specifica del proxy API non viene visualizzata come output del comando citato nel passaggio 1, riavvia lo specifico processore di messaggi come spiegato nella sezione Risoluzione.
Ripeti i passaggi 1-2 per tutti i processori di messaggi.
Se su tutti i processori di messaggi viene eseguito il deployment della revisione specifica del proxy API, non è questa la causa del problema. Vai a Devi raccogliere dati diagnostici.

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 consente di isolare rapidamente le aree problematiche per diagnosticare i problemi di errore, prestazioni e latenza e la relativa origine, ad esempio app per sviluppatori, proxy API, target di backend o la piattaforma API.

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

Codice di errore e codice di stato nell'interfaccia utente

Codice di errore: messaging.adaptors.http.flow.ApplicationNotFound
Codice di stato: 404
Origine errore: Apigee o MP

Inoltre, puoi fare clic su Visualizza log come mostrato nello screenshot qui sopra e proseguire con la procedura.

Visualizza i log

Una procedura dettagliata di esempio illustra come risolvere i problemi relativi a 5xx con le tue API utilizzando API Monitoring. Ad esempio, potresti voler configurare un avviso per ricevere una notifica quando il numero di codici di stato 404 supera una soglia specifica.

Devi raccogliere dati diagnostici

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.

Se sei un utente del cloud pubblico, fornisci le seguenti informazioni:
- Nome dell'organizzazione.
- Nome ambiente
- Nome proxy API
- Completa il comando curl per riprodurre l'errore
Se sei un utente del cloud privato, fornisci le seguenti informazioni:
- Rilevato messaggio di errore completo
- Nome ambiente
- Bundle di 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.
Dettagli sulle sezioni di questa guida pratica che hai provato e su eventuali altri insight che ci aiuteranno a velocizzare la risoluzione del problema.