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 sezione Documentazione di Apigee X. Informazioni

Sintomo

L'applicazione client riceve un codice di stato HTTP di 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 significa 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

Vedrai 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 Host virtuale default e percorso /oauth2/token.

Possibili cause

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

Causa	Descrizione	Le istruzioni di 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 perimetrali di cloud pubblici e privati
Host virtuale rimosso in una revisione del proxy API appena di cui è stato eseguito il deployment	Rimozione dell'host virtuale dalla revisione di cui è stato appena eseguito il deployment mentre il client è ancora il problema può essere causato dall'uso dell'host virtuale specifico.	Utenti perimetrali di cloud pubblici e privati
Percorso non associato ad alcun proxy API	Il proxy API specifico non è configurato per accettare richieste sul percorso specificato nel messaggio di errore.	Utenti perimetrali di cloud pubblici e privati
Proxy API di cui non è stato eseguito il deployment in un ambiente	Il deployment del proxy API specifico non è stato eseguito nell'ambiente specifico in cui che tenta di eseguire le richieste API.	Utenti perimetrali di cloud pubblici e privati
Ambiente non caricato sul processore di messaggi	L'ambiente specifico (in cui stai tentando di effettuare le richieste API) non ha sui processori di messaggi a causa di un errore.	Utenti Edge Private Cloud
Proxy API di cui non è stato eseguito il deployment su uno o più processori di messaggi	Impossibile eseguire il deployment del proxy API su uno o più processori di messaggi perché manca durante il deployment.	Utenti Edge Private Cloud

Passaggi diagnostici 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

Verifica 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 dei log.

Controllare i log del processore di messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log) per sapere se avere messaging.adaptors.http.flow.ApplicationNotFound per l'API specifica o se disponi dell'attributo l'ID messaggio del passaggio 2 per la richiesta API.
Esempio di messaggio di errore dal 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 seguenti:

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

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

Causa: il 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.

Diagnosi

Controlla la configurazione dell'endpoint proxy per il proxy API e verifica che sia stato eseguito configurato in modo da accettare le richieste per l'host virtuale specificato nell'errore. Questo è indicato dall'elemento VirtualHost. Diamo un'occhiata a un esempio di ProxyEndpoint configurazione per comprendere 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 all'elemento default VirtualHost utilizzando l'URL http://myorg-prod.apigee.net/weather
Poiché ProxyEndpoint non ha default VirtualHost come mostrato in esempio precedente, viene visualizzato 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 l'elemento VirtualHost mancante alla configurazione ProxyEndpoint per risolvere il problema. Per l'esempio mostrato sopra, puoi aggiungere il valore predefinito VirtualHost alla configurazione ProxyEndpoint come segue:
```
<VirtualHost>default</VirtualHost>
```
Esempio di configurazione di endpoint proxy che mostra il valore predefinito VirtualHost> in fase di aggiunta
In alternativa, nell'esempio citato in precedenza, se intendevi utilizzare solo secure VirtualHost per questo proxy API specifico, quindi effettua le richieste API solo al 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 appena 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 precedentemente eseguito il deployment), che viene ancora utilizzato dai clienti per effettuare richieste API, questo potrebbe causare questo problema.

Diagnosi

Controlla la configurazione dell'endpoint proxy per il proxy API per verificare che sia stato eseguito configurato in modo da accettare le richieste per l'host virtuale specificato nell'errore. Questo è indicato dall'elemento VirtualHost nella configurazione ProxyEndpoint.
Se l'host virtuale specificato nell'errore non esiste in ProxyEndpoint configurazione, segui questi passaggi. Altrimenti, passa alla causa successiva: Percorso non associato ad alcun proxy API.
Confronta la configurazione ProxyEndpoint della revisione di cui è stato precedentemente eseguito il deployment con quella attualmente di cui è stato eseguito il deployment.
1. Ad esempio, supponiamo che la revisione di cui hai eseguito il deployment in precedenza sia 5 e che il tuo la revisione attualmente di cui è stato eseguito il deployment è 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 clienti inviate 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 di cui è stato eseguito il deployment e prendere le misure appropriate, come spiegato nella sezione Risoluzione.

Risoluzione

Se rilevi che l'host o gli host virtuali sono stati rimossi in una nuova revisione, la rimozione potrebbe essere stata intenzionale o potrebbe essere incidente. In ogni caso, per risolvere il problema, svolgi i passaggi consigliati per la risoluzione dei problemi riportati di seguito.

Scenario 1: cambiamento intenzionale

Se la rimozione dell'host virtuale è intenzionale, puoi scegliere una delle seguenti opzioni la cui prima opzione è quella consigliata:

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 utilizzare un host virtuale diverso, è preferibile mantenere l'host virtuale esistente e aggiungere l'altro host virtuale.

In questo modo ti assicuri che gli utenti di questo proxy API non siano interessati dalla modifica.
Se vuoi utilizzare il proxy API esistente e hai solo un host virtuale diverso, informare gli utenti in anticipo e apportare questa modifica durante un periodo di manutenzione.

In questo modo, gli utenti di questo proxy API saranno a conoscenza della modifica e potranno puoi utilizzare un host virtuale diverso per effettuare le chiamate a questo proxy API. Pertanto, non sarà interessata 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 per utilizzare gli stessi host virtuali utilizzati nella revisione di cui è stato eseguito il deployment in precedenza. Nella precedente, modifica la sezione seguente da:
```
<HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>
```
a
```
<HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>vh1</VirtualHost>
</HTTPProxyConnection>
```
Esegui di nuovo 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 come meno, in modo che qualsiasi problema derivante durante il deployment possa essere da evitare per 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 nel URL della richiesta API, potremo ricevere una risposta 404 Not Found con il messaggio di errore Unable to identify proxy for host: VIRTUAL_HOST and url: PATH.

Diagnosi

Controlla la configurazione di ProxyEndpoint per il proxy API specifico per cui volevi per effettuare le richieste API.
Verifica che il proxy API sia configurato per accettare le richieste per il percorso specifico indicato nel messaggio di errore. Puoi farlo seguendo la procedura descritta in Scenario 1 e Scenario 2.

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

Se il valore path indicato nel messaggio di errore non corrisponde a basepath del proxy API specifico o non inizia con basepath, potrebbe essere la causa dell'errore.
Vediamo un esempio per spiegare questo:

Il 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 al basepath e corrisponde non iniziano con basepath. Di conseguenza, ricevi 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 sia lo stesso di basepath del proxy API specifico.
Nell'esempio precedente, l'URL di richiesta API dovrebbe 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 basepath) indicato nel messaggio di errore non corrisponde a nessuna delle condizioni flussi, questo potrebbe causare l'errore 404.
Vediamo un esempio per spiegare questo:
1. Il basepath del proxy API previsto è /weather
2. L'URL della richiesta API è https://myorg-prod.apigee.net/weather/Delhi. Ciò significa il percorso utilizzato nell'URL della richiesta API è /weather/Delhi.
In questo esempio, path inizia con basepath /weather. Inoltre, ha un valore di path suffix pari a /Delhi.
Ora controlla se esistono flussi condizionali in ProxyEndpoint.
Se non ci sono flussi condizionali o alcuni non condizionali, vai alla prossima causa - Proxy API di cui non è stato eseguito il deployment in un ambiente.
Se ProxyEndpoint ha solo flussi condizionali, verifica quanto segue:
1. Se le condizioni in tutti questi flussi condizionali verificano un valore proxy.pathsuffix specifico (il percorso dopo il basepath).
2. Se il valore path suffix specificato nell'URL della richiesta API non corrisponde a nessuno dei , questa è la causa dell'errore.
Supponiamo di avere due flussi in ProxyEndpoint e che 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 proxy.pathsuffix (percorso dopo il percorso base) fino a /Bangalore e l'altro corrisponde a /Chennai. Ma nessuna corrispondenza corrisponde a /Delhi ossia il valore path suffix passato nell'URL della richiesta API.
2. Questa è la causa dell'errore 404. Di conseguenza, visualizzerai 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.
Nell'esempio precedente, puoi utilizzare i seguenti approcci per risolvere l'errore:
1. Se vuoi eseguire un set specifico di criteri per il percorso /Delhi, aggiungi un flusso separato con l'insieme di criteri richiesto e assicurati che sia presente una condizione che corrisponde al /proxy.pathsuffix /Delhi come mostrato di seguito:
```
<Condition>(proxy.pathsuffix MatchesPath "/Delhi") and (request.verb = "GET")</Condition>
```
2. Se vuoi eseguire un set comune di criteri per il percorso /Delhi, comune, è necessario assicurarsi che sia presente una condizione che consenta una /proxy.pathsuffix. In altre parole, consente qualsiasi percorso dopo basepath /weather come mostrato di seguito:
```
<Condition>(proxy.pathsuffix MatchesPath "/**") and (request.verb = "GET")</Condition>
```

Se ProxyEndpoint presenta i valori basepath corretti e path suffix specificati nell'URL dell'API corrisponde a uno dei flussi condizionali, quindi passa alla causa successiva, proxy API di cui non è stato eseguito il deployment in un ambiente.

Causa: il deployment del proxy API non è stato eseguito in un ambiente

Diagnosi

Determina l'ambiente in cui esiste l'alias host utilizzato nell'URL della richiesta API. A questo scopo, controlla i dettagli di tutti gli host virtuali in ciascun ambiente della tua organizzazione nella UI Edge.
Ad esempio, supponi la seguente configurazione:
- Se http://myorg-prod.apigee.net/weather è l'URL, myorg-prod.apigee.net è l'alias host.
- L'alias host myorg-prod.apigee.net è configurato come parte di uno dei host virtuali nell'ambiente prod della tua organizzazione.
Verifica se è stato eseguito il deployment del proxy API specifico nell'ambiente specifico determinato in passaggio 1 precedente.
Se il proxy API non viene eseguito nell'ambiente specifico, è la causa l'errore 404.
1. Nell'esempio utilizzato nel passaggio 1 precedente, supponiamo che il proxy API non sia implementato nella prod, questa è la causa dell'errore.
2. Vai alla sezione Risoluzione di seguito.
Se viene 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 sui processori di messaggi

Diagnosi

Accedi a ciascuno dei processori di messaggi e verifica se l'ambiente specifico che la richiesta API venga caricata 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: Proxy API di cui non è stato eseguito il deployment su uno o più processori di messaggi.
Se l'ambiente specifico non è in elenco, controlla /opt/apigee/var/log/edge-message-processor/logs/system.log e /opt/apigee/var/log/edge-message-processor/logs/startupruntimeerrors.log il Processori di messaggi per rilevare eventuali errori durante il caricamento degli ambienti.
Potrebbero esserci tanti errori diversi che potrebbero portare al mancato caricamento di un ambiente il 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 portare a questo problema e spiega come risolverlo risolvere il problema.

Se nel log del processore di messaggi viene visualizzato uno dei seguenti errori, significa che la causa è un errore: è stato rilevato un problema con i certificati/le chiavi che sono stati aggiunti all'archivio chiavi/truststore specificati nell'ambiente specificato.

Errore 1: java.security.KeyStoreEccezioni: 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.KeyStoreEccezione: 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

Visualizza i dettagli dell'archivio chiavi/truststore specificato nel messaggio di errore visualizzato in 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 sono presenti due certificati e una chiave nell'archivio di attendibilità myTruststore. Generalmente, l'archivio attendibili non contiene una chiave. Se sì, è preferibile avere un unico certificato e una sola 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 ciascun certificato e individua quello scaduto o meno recente.
Elimina il certificato scaduto o indesiderato dall'archivio attendibilità myTruststore.

Se il problema persiste o se viene visualizzato un errore diverso da quelli menzionati nel passaggio 1 in alto, vai a Raccogliere i dati diagnostici.

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

Non è possibile eseguire 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 evento mancante dal server di gestione Processore di messaggi durante il deployment del proxy API specifico. Anche in questo caso dovrai non sarà in grado di creare la sessione di traccia nella UI Edge.

Diagnosi

Accedere a ciascuno dei processori di messaggi e verificare se la revisione specifica dei Il deployment del proxy API è stato eseguito o non è stato utilizzato 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 menzionato nel passaggio 1, quindi riavvia lo specifico processore di messaggi come spiegato nella Risoluzione.
Ripeti i passaggi 1-2 per tutti i processori di messaggi.
Se viene eseguito il deployment della revisione specifica del proxy API su tutti i processori di messaggi, non è la causa del problema. Vai a Raccogliere dati diagnostici.

Risoluzione

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

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

Diagnosticare 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 piattaforma API.

Per questo problema, puoi andare alla sezione Monitoraggio API > Esamina e scegliere la data, il proxy e così via; 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 sopra e verificare ulteriormente.

Visualizza i log

Esamina uno scenario di esempio dimostra come risolvi i problemi di 5xx con le tue API utilizzando API Monitoring. Ad esempio, potresti vuoi configurare un avviso per ricevere una notifica quando il numero di codici di stato 404 supera una una determinata soglia.

Raccogliere dati diagnostici

Se il problema persiste anche dopo aver seguito le istruzioni riportate sopra, raccogli i dati 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 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:
- 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.
Dettagli sulle sezioni di questo playbook che hai provato e qualsiasi altro insight che ci aiuterà a velocizzare la risoluzione del problema.