Questa pagina è stata tradotta dall'API Cloud Translation.

Errore interno del server 500 - Streaming abilitato

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

Sintomo

L'applicazione client riceve un codice di stato di risposta HTTP 500 con il messaggio Errore interno del server per le chiamate API.

Messaggi di errore

Le applicazioni client potrebbero ricevere una risposta di errore, come mostrato di seguito:

HTTP/1.1 500 Internal Server Error

Potrebbe essere seguito da un messaggio di errore simile al seguente:

{
   "fault":{
      "faultstring":"Expecting } at line 1"
      "detail":{
         "errorcode":"Internal Server Error"
      }
   }
}

OR

{
   "fault":{
      "faultstring":"Expecting ] at line 1"
      "detail":{
         "errorcode":"Internal Server Error"
      }
   }
}

Possibili cause

L'errore 500 interno del server può verificarsi a causa di una serie di cause diverse. Questo playbook è incentrato sull'errore interno 500 del server causato dall'accesso al payload di richiesta/risposta quando è abilitato il flusso di dati.

Causa	Descrizione	Chi può eseguire la procedura di risoluzione dei problemi
Accesso al payload con i flussi di dati abilitati	Si è verificato un errore perché si accede al payload di richiesta/risposta quando è abilitato il flusso di dati.	Utenti del cloud privato e pubblico Edge

Causa: accesso al payload con lo streaming abilitato

Diagnostica

Procedura 1: utilizzo di Trace

Abilita la sessione di traccia ed effettua la chiamata API per riprodurre il problema: errore interno 500 del server.
Seleziona una delle richieste non riuscite ed esamina la traccia.
Naviga tra le varie fasi della traccia e individua il punto in cui si è verificato l'errore.
Questo errore potrebbe essersi verificato durante l'analisi del payload della richiesta/risposta da parte di un criterio.
Ecco uno screenshot della traccia di esempio che mostra il criterio JSONThreatProtection che non presenta l'errore "Expecting } alla riga 1":

Prendi nota delle seguenti informazioni dell'output della traccia, come mostrato nello screenshot riportato sopra:

Norme non superate: JSONThreatProtection

Flusso: richiesta di proxy

Esamina la definizione del criterio con errori e controlla il payload che viene analizzato.

Nello scenario di esempio, esamina il criterio JSONThreatProtection denominato JSON-Threat-Protection che non è riuscito e controlla l'elemento <Source>.

<JSONThreatProtection async="false" continueOnError="false" enabled="true" name="JSON-Threat-Protection">
   <DisplayName>JSON Threat Protection</DisplayName>
   <ArrayElementCount>20</ArrayElementCount>
   <ContainerDepth>10</ContainerDepth>
   <ObjectEntryCount>15</ObjectEntryCount>
   <ObjectEntryNameLength>50</ObjectEntryNameLength>
   <Source>request</Source>
   <StringValueLength>1000</StringValueLength>
</JSONThreatProtection>

Tieni presente che l'elemento <Source> rimanda a request.. Ciò significa che l'errore si è verificato durante l'analisi del payload della richiesta.

Determina il tipo di payload da analizzare controllando la richiesta API.

Puoi controllare il contenuto del payload della richiesta e dell'intestazione Content-Type nella richiesta API. Nel comando curl di esempio riportato di seguito, viene utilizzato un payload JSON.

curl -i https://VIRTUAL_HOST_ALIAS/BASEPATH -H "Content-Type: application/json" \
-X POST -d @request-payload.json

Puoi anche controllare il criterio che presenta errori e determinare il tipo di payload da analizzare. Nello scenario di esempio riportato sopra, il criterio JSON-Threat-Protection non riesce. Ciò indica che il payload deve essere in formato JSON.

Verifica che il formato del payload sia corretto. Se il payload non è valido, puoi ricevere questo errore.

Nota: se il payload è di grandi dimensioni, puoi utilizzare qualsiasi formattatore online per convalidare il formato del payload.
Se il payload è valido, ma continui a ricevere errori come elencato nella sezione Messaggi di errore, la causa di questi errori è l'accesso al payload quando è abilitato il flusso di dati.

A seconda del payload che viene analizzato dal criterio (come determinato nel passaggio 6), esamina il contenuto del payload nello strumento Trace nella fase appropriata.

Nello scenario di esempio, il payload della richiesta viene analizzato, quindi esamina la fase "Richiesta ricevuta dal client" nella traccia e controlla la sezione Richiesta di contenuti.

Se i contenuti della richiesta risultano vuoti come mostrato nello screenshot precedente, anche se hai inviato un payload valido, significa che la probabile causa di questo problema è che il flusso di richieste è abilitato.

Questo perché, quando il flusso di dati è abilitato, il payload della richiesta non verrà visualizzato nella traccia.

Allo stesso modo, se il payload della risposta viene analizzato quando si verifica l'errore, controlla i contenuti della risposta nella fase "Risposta ricevuta dal server di destinazione".
Quindi, esamina le definizioni del proxy e dell'endpoint di destinazione a seconda di dove viene utilizzato il criterio con errori nel flusso del proxy API. Verifica che il flusso di dati sia stato abilitato.

Nello scenario di esempio, il criterio con errori è stato eseguito nel flusso di richiesta proxy (come determinato nel passaggio 5 sopra riportato); pertanto, esamina l'endpoint proxy:
```
<ProxyEndpoint name="default">
...
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <VirtualHost>secure</VirtualHost>
    <Properties>
      <Property name="response.streaming.enabled">true</Property>
      <Property name="request.streaming.enabled">true</Property>
    </Properties>
  </HTTPProxyConnection>
</ProxyEndpoint>
```
Come mostrato nell'esempio precedente, il flusso di richieste è stato attivato, come indicato dalla proprietà "request.streaming.enabled" impostata su true.

Pertanto, la causa dell'errore è l'utilizzo del criterio JSONThreatProtection nel proxy API che accede al payload della richiesta quando il flusso di dati è abilitato. Questo causa errori perché attiva il buffering nel proxy API e annulla lo scopo di utilizzare i flussi di dati in Apigee Edge.

Questo errore potrebbe non essere rilevato con payload più piccoli, ma quando utilizzi payload di dimensioni maggiori, puoi visualizzare questi errori.
Puoi verificare che l'errore 500 sia causato dal criterio controllando il valore di "X-Apigee-fault-source" nella fase "AX" (Analytics Data Recorded) della traccia seguendo i passaggi riportati di seguito:
1. Fai clic sulla fase "AX" (Dati di Analytics registrati) come mostrato nello screenshot di seguito:
2. Scorri verso il basso i dettagli della fase fino alla sezione "Intestazioni degli errori" e determina i valori di "X-Apigee-fault-code", "X-Apigee-fault-source" e "X-Apigee-fault-policy" come mostrato di seguito:
3. Se il valore di "X-Apigee-fault-source" è "policy" come mostrato nell'immagine precedente, indica che l'errore è causato dall'accesso dei criteri al payload quando il flusso di dati è abilitato.

Risoluzione

L'accesso al payload con i flussi di dati abilitati è un anti-pattern, come spiegato in Antipattern: accesso al payload di richiesta/risposta quando il flusso di dati è abilitato.

Se vuoi elaborare il payload, devi disabilitare il flusso di dati nel proxy/endpoint di destinazione rimuovendo le proprietà "request.streaming.enabled" and "response.streaming.enabled"come mostrato nell'esempio di ProxyEndpoint di seguito:
```
<ProxyEndpoint name="default">
...
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <VirtualHost>secure</VirtualHost>
  </HTTPProxyConnection>
</ProxyEndpoint>
```
OPPURE
Se vuoi utilizzare il flusso di dati per i proxy API, non utilizzare alcun criterio nel proxy API che accede al payload di richiesta/risposta.

Nota

In questo playbook, è stato utilizzato il criterio JSONThreatProtection per elaborare il payload delle richieste con lo streaming abilitato nello scenario di esempio. Questo ha causato la generazione di un errore 500 (Internal Server Error) con diversi errori.
Questi errori possono essere visualizzati anche con criteri come JSONToXML e XMLToJSON, che elaborano i payload di richiesta o risposta quando il flusso di dati è abilitato.
Ti consigliamo vivamente di non utilizzare questi criteri nei proxy che richiedono l'accesso ai payload quando è abilitato il flusso di dati.
Questa operazione è un anti-pattern, come documentato in Antipattern: accesso al payload di richiesta/risposta quando il flusso di dati è abilitato.

Diagnostica i problemi utilizzando API Monitoring

Se sei un utente del cloud privato, ignora questa procedura.

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.

Illustra uno scenario di esempio che illustra come risolvere i problemi 5xx relativi alle tue API utilizzando il monitoraggio delle API. Ad esempio, potresti voler configurare un avviso per ricevere una notifica quando il numero di 500 errori supera una determinata soglia.

Se vuoi ricevere una notifica quando viene generata una risposta di errore 500 dal criterio, devi configurare l'avviso per il codice di stato 500 con l'origine dell'errore come proxy.

Raccogliere informazioni diagnostiche

Se il problema persiste anche dopo aver seguito le istruzioni riportate sopra, raccogli le seguenti informazioni diagnostiche. Contattali e inviali all'assistenza Apigee.

Se sei un utente del cloud pubblico, fornisci le seguenti informazioni:

Nome organizzazione
Nome ambiente
Nome proxy API
Completa il comando curl insieme al payload (se presente) della richiesta per riprodurre l'errore 500
File di traccia contenente le richieste con errore interno del server (500)
Se al momento gli errori 500 non si verificano, indica il periodo di tempo con le informazioni sul fuso orario in cui si sono verificati 500 errori in passato.

Se sei un utente del cloud privato, fornisci le seguenti informazioni:

Messaggio di errore completo osservato per le richieste non riuscite
Organizzazione, Nome ambiente e Nome proxy API per i quali stai osservando errori 500
Bundle proxy API
Payload utilizzato nella richiesta (se presente)
File di traccia contenente le richieste con errore interno del server (500)
Log degli accessi NGINX (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log)
Log del processore di messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log)
Il periodo di tempo con le informazioni sul fuso orario in cui si sono verificati gli errori 500.