Errore interno del server 500 - Streaming abilitato

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

Sintomo

L'applicazione client riceve un codice di stato della risposta HTTP 500 con il messaggio Internal Server Error 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

Questo potrebbe essere seguito da un messaggio di errore simile a questo:

{
   "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 interno del server 500 può verificarsi per una serie di cause diverse. Questo playbook si concentra sull'errore interno del server 500 causato dall'accesso al payload della richiesta/risposta quando lo streaming è abilitato.

Causa: accesso al payload con lo streaming abilitato

Diagnosi

Procedura n. 1: utilizzo di Trace

1. Attiva la sessione di traccia ed effettua la chiamata API per riprodurre il problema: errore interno del server 500.
2. Seleziona una delle richieste non riuscite ed esamina la traccia.
3. Esamina le varie fasi della traccia e individua il punto in cui si è verificato l'errore.
4. Questo errore potrebbe essersi verificato durante l'analisi del payload della richiesta/risposta da parte di una policy.
5. Ecco uno screenshot di esempio della traccia che mostra la JSONThreatProtection policy che non riesce a eseguire l'operazione con l'errore "Expecting } at line 1":

   

   Prendi nota delle seguenti informazioni dall'uscita della traccia, come mostrato nello screenshot sopra:
   

   Policy non riuscita: JSONThreatProtection

   Flusso: richiesta del proxy

6. Esamina la definizione della policy non riuscita e controlla il payload analizzato.

   Nello scenario di esempio, esamina la policy JSONThreatProtection denominata JSON-Threat-Protection che non è riuscita a eseguire l'operazione 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> punta a request. Ciò significa che si è verificato un errore durante l'analisi del payload della richiesta.

7. Determina il tipo di payload analizzato controllando la richiesta API.

Puoi controllare i contenuti del payload della richiesta e l'intestazione Content-Type nella richiesta API. Nel seguente comando curl di esempio 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 la policy che non riesce a eseguire l'operazione e determinare il tipo di payload analizzato. Nello scenario di esempio sopra, la policy JSON-Threat-Protection non riesce a eseguire l'operazione. Ciò indica che il payload deve essere in formato JSON.

8. Verifica se il payload è nel formato corretto. Se il payload non è valido, puoi ricevere questo errore.

9. Se il payload è valido, ma continui a ricevere gli errori elencati nella sezione Messaggi di errore, la causa di questi errori è che si accede al payload quando lo streaming è abilitato.

   A seconda del payload analizzato dalla policy (come determinato nel passaggio 6), esamina i contenuti del payload nello strumento Trace nella fase appropriata.

   Nello scenario di esempio, viene analizzato il payload della richiesta, quindi esamina la "Request Received from Client" fase nella traccia e controlla i contenuti della richiesta.

   

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

   Questo perché, quando lo streaming è abilitato, il payload della richiesta non viene 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 "Response received from target server".

10. Esamina quindi le definizioni di proxy ed endpoint di destinazione a seconda di dove viene utilizzata la policy non riuscita nel flusso del proxy API. Verifica se lo streaming è stato abilitato.

    Nello scenario di esempio, la policy non riuscita è stata eseguita nel flusso della richiesta del proxy (come determinato nel passaggio 5 sopra), quindi esamina l'endpoint del 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 sopra, lo streaming delle richieste è stato abilitato come indicato dalla proprietà "request.streaming.enabled" impostata su true.

    Pertanto, la causa dell'errore è l'utilizzo della policy JSONThreatProtection nel proxy API che accede al payload della richiesta quando lo streaming è abilitato. Ciò causa errori perché attiva il buffering nel proxy API e vanifica lo scopo dell'utilizzo dello streaming in Apigee Edge.

    Questo errore potrebbe non essere visualizzato con payload più piccoli, ma quando utilizzi payload più grandi, puoi visualizzare questi errori.

11. Puoi verificare che l'errore 500 sia causato dalla policy controllando il valore di "X-Apigee-fault-source" nella fase "AX" (Analytics Data Recorded) della traccia utilizzando i passaggi riportati di seguito:
    1. Fai clic sulla fase "AX" (Analytics Data Recorded) come mostrato nello screenshot di seguito:

       

    2. Scorri verso il basso i dettagli della fase fino alla sezione "Error Headers" 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 sopra, significa che l'errore è causato dalla policy che accede al payload quando lo streaming è abilitato.

Risoluzione

L'accesso al payload con lo streaming abilitato è un antipattern, come spiegato in Antipattern: Access the request/response payload when streaming is enabled.

1. Se vuoi elaborare il payload, devi disabilitare lo streaming nell'endpoint proxy/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

2. Se vuoi utilizzare lo streaming per i tuoi proxy API, non utilizzare alcuna policy nel proxy API che acceda al payload della richiesta/risposta.

Nota

• In questo playbook, la policy JSONThreatProtection è stata utilizzata per elaborare il payload della richiesta con lo streaming abilitato nello scenario di esempio. Ciò ha comportato un errore interno del server 500 con errori diversi.
• Questi errori possono essere visualizzati anche con policy come JSONToXML e XMLToJSON, che elaborano i payload di richiesta o risposta quando lo streaming è abilitato.
• Ti consigliamo vivamente di non utilizzare queste policy nei proxy che richiedono l'accesso a payload quando lo streaming è abilitato.
• Questa operazione è un antipattern, come documentato in Antipattern: Access the request/response payload when streaming is enabled.

Diagnosticare i problemi utilizzando il monitoraggio delle API

Se sei un utente di Private Cloud, salta questa procedura.

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

Segui un esempio di scenario che mostra come risolvere i problemi 5xx con le API utilizzando il monitoraggio delle API. Ad esempio, potresti voler configurare un avviso per ricevere una notifica quando il numero di errori 500 supera una determinata soglia.

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

Informazioni di diagnostica da raccogliere

Se il problema persiste anche dopo aver seguito le istruzioni sopra riportate, raccogli le seguenti informazioni di diagnostica. Contatta l'assistenza Apigee e condividile.

Se sei un utente di Public Cloud, fornisci le seguenti informazioni:

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

Se sei un utente di Private Cloud, fornisci le seguenti informazioni:

• Messaggio di errore completo osservato per le richieste non riuscite
• Nome dell'organizzazione, dell'ambiente e del proxy API per cui stai osservando gli errori 500
• Bundle del proxy API
• Payload utilizzato nella richiesta (se presente)
• File di traccia contenente le richieste con errore interno del server 500
• Log di accesso 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.