Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

500 Interner Serverfehler – Streaming aktiviert

Sie lesen gerade die Dokumentation zu Apigee Edge.
Zur Dokumentation zuApigee X wechseln. info

Symptom

Die Clientanwendung erhält für API-Aufrufe einen HTTP-Antwortstatuscode 500 mit der Meldung Internal Server Error.

Fehlermeldungen

Die Clientanwendungen erhalten möglicherweise eine Fehlerantwort wie unten gezeigt:

HTTP/1.1 500 Internal Server Error

Darauf kann eine Fehlermeldung wie diese folgen:

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

OR

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

Mögliche Ursachen

Der Fehler „500 Internal Server Error“ kann verschiedene Ursachen haben. In diesem Playbook geht es um den Fehler „500 Internal Server Error“, der durch den Zugriff auf die Anfrage-/Antwortnutzlast verursacht wird, wenn das Streaming aktiviert ist.

Ursache	Beschreibung	Wer kann die Schritte zur Fehlerbehebung ausführen?
Zugriff auf die Nutzlast bei aktiviertem Streaming	Ein Fehler ist aufgetreten, weil auf die Anfrage-/Antwortnutzlast zugegriffen wird, wenn das Streaming aktiviert ist.	Nutzer von Edge Private und Public Cloud

Ursache: Zugriff auf die Nutzlast bei aktiviertem Streaming

Diagnose

Verfahren 1: Trace verwenden

Aktivieren Sie die Trace Sitzung und führen Sie den API-Aufruf aus, um das Problem zu reproduzieren: „500 Internal Server Error“.
Wählen Sie eine der fehlgeschlagenen Anfragen aus und prüfen Sie den Trace.
Gehen Sie die verschiedenen Phasen des Trace durch und suchen Sie nach der Stelle, an der der Fehler aufgetreten ist.
Dieser Fehler ist möglicherweise aufgetreten, während eine Richtlinie die Anfrage-/Antwortnutzlast geparst hat.
Hier ist ein Beispiel für einen Trace-Screenshot, auf dem die JSONThreatProtection Richtlinie mit dem Fehler "Expecting } at line 1" fehlschlägt:

Notieren Sie sich die folgenden Informationen aus der Trace-Ausgabe, wie im obigen Screenshot:

Fehlgeschlagene Richtlinie: JSONThreatProtection

Ablauf:Proxy-Anfrage

Prüfen Sie die Definition der fehlgeschlagenen Richtlinie und die Nutzlast, die geparst wird.

Prüfen Sie im Beispielszenario die fehlgeschlagene JSONThreatProtection-Richtlinie mit dem Namen JSON-Threat-Protection und das <Source> Element.

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

Beachten Sie, dass das Element <Source> auf request. verweist. Das bedeutet, dass der Fehler beim Parsen der Anfragenutzlast aufgetreten ist.

Ermitteln Sie den Typ der Nutzlast, die geparst wird, indem Sie die API-Anfrage prüfen.

Sie können den Inhalt der Anfragenutzlast und den Header Content-Type in der API-Anfrage prüfen. Im folgenden Beispiel für einen cURL-Befehl wird eine JSON-Nutzlast verwendet.

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

Sie können auch die Richtlinie prüfen, die fehlschlägt, und den Typ der Nutzlast ermitteln, die geparst wird. Im obigen Beispielszenario schlägt die Richtlinie „JSON-Threat-Protection“ fehl. Das bedeutet, dass die Nutzlast im JSON-Format vorliegen muss.

Prüfen Sie, ob die Nutzlast das richtige Format hat. Wenn die Nutzlast ungültig ist, kann dieser Fehler auftreten.

Hinweis: Wenn die Nutzlast groß ist, können Sie einen Online-Formatter verwenden, um das Format der Nutzlast zu prüfen.
Wenn die Nutzlast gültig ist, aber weiterhin Fehler auftreten, wie im Abschnitt Fehlermeldungen aufgeführt, liegt die Ursache für diese Fehler darin, dass auf die Nutzlast zugegriffen wird, wenn das Streaming aktiviert ist.

Prüfen Sie je nach Nutzlast, die von der Richtlinie geparst wird (wie in Schritt 6 ermittelt), den Nutzlastinhalt im Trace-Tool in der entsprechenden Phase.

Im Beispielszenario wird die Anfragenutzlast geparst. Prüfen Sie daher die "Request Received from Client" Phase im Trace und den Request Content.

Wenn der Anfrageninhalt leer ist, wie im obigen Screenshot gezeigt, obwohl Sie eine gültige Nutzlast gesendet haben, ist die wahrscheinliche Ursache dieses Problems, dass das Anfragestreaming aktiviert ist.

Wenn das Streaming aktiviert ist, wird die Anfragenutzlast nicht im Trace angezeigt.

Wenn die Antwortnutzlast geparst wird, wenn der Fehler auftritt, prüfen Sie den Antwortinhalt in der "Response received from target server" Phase.
Prüfen Sie als Nächstes die Proxy- und Ziel-Endpoint-Definitionen, je nachdem, wo die fehlgeschlagene Richtlinie im API-Proxy-Ablauf verwendet wird. Prüfen Sie, ob das Streaming aktiviert wurde.

Im Beispielszenario wurde die fehlgeschlagene Richtlinie im Proxy-Anfrageablauf ausgeführt (wie oben in Schritt 5 ermittelt). Prüfen Sie daher den Proxy-Endpoint:
```
<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>
```
Wie im obigen Beispiel zu sehen ist, wurde das Anfragestreaming aktiviert, wie durch das Attribut "request.streaming.enabled" mit dem Wert „true“ angegeben.

Die Ursache des Fehlers ist also die Verwendung der JSONThreatProtection-Richtlinie im API-Proxy die auf die Anfragenutzlast zugreift, wenn das Streaming aktiviert ist. Dies führt zu Fehlern, da es das Pufferung im API-Proxy auslöst und den Zweck des Streamings in Apigee Edge zunichtemacht.

Dieser Fehler tritt möglicherweise nicht bei kleineren Nutzlasten auf, aber bei größeren Nutzlasten können Sie diese Fehler sehen.
Sie können prüfen, ob der Fehler „500“ durch die Richtlinie verursacht wird, indem Sie den Wert von "X-Apigee-fault-source" in der Phase "AX" (Analytics Data Recorded) im Trace mit den folgenden Schritten prüfen:
1. Klicken Sie auf die Phase "AX" (Analytics Data Recorded) wie im folgenden Screenshot gezeigt:
2. Scrollen Sie in den Phasen-Details nach unten zum "Error Headers" Abschnitt und ermitteln Sie die Werte von "X-Apigee-fault-code", "X-Apigee-fault-source" und "X-Apigee-fault-policy" wie unten gezeigt:
3. Wenn der Wert von "X-Apigee-fault-source" "policy" ist, wie in der Abbildung oben gezeigt, wird der Fehler dadurch verursacht, dass die Richtlinie auf die Nutzlast zugreift, wenn das Streaming aktiviert ist.

Auflösung

Der Zugriff auf die Nutzlast bei aktiviertem Streaming ist ein Anti-Pattern, wie unter Anti-Pattern: Auf Anfrage-/Antwortnutzlast zugreifen, wenn Streaming aktiviert ist erläutert.

Wenn Sie die Nutzlast verarbeiten möchten, müssen Sie das Streaming im Proxy-/Ziel Endpoint deaktivieren, indem Sie die Attribute "request.streaming.enabled" and "response.streaming.enabled" entfernen, wie im folgenden Beispiel für einen ProxyEndpoint gezeigt:
```
<ProxyEndpoint name="default">
...
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <VirtualHost>secure</VirtualHost>
  </HTTPProxyConnection>
</ProxyEndpoint>
```
ODER
Wenn Sie das Streaming für Ihre API-Proxys verwenden möchten, verwenden Sie keine Richtlinien im API-Proxy, die auf die Anfrage-/Antwortnutzlast zugreifen.

Hinweis:

In diesem Playbook wurde die JSONThreatProtection-Richtlinie verwendet, um die Anfragenutzlast bei aktiviertem Streaming im Beispielszenario zu verarbeiten. Dies führte zu dem Fehler „500 Internal Server Error“ mit verschiedenen Fehlern.
Diese Fehler können auch bei Richtlinien wie JSONToXML und XMLToJSON auftreten, die Anfragen- oder Antwortnutzlasten verarbeiten, wenn das Streaming aktiviert ist.
Wir empfehlen dringend, solche Richtlinien nicht in Proxys zu verwenden, die Zugriff auf Nutzlasten benötigen, wenn das Streaming aktiviert ist.
Dies ist ein Anti-Pattern, wie unter Anti-Pattern: Auf Anfrage-/Antwortnutzlast zugreifen, wenn Streaming aktiviert ist dokumentiert.

Probleme mit API Monitoring diagnostizieren

Wenn Sie ein Private Cloud-Nutzer sind, überspringen Sie dieses Verfahren.

API Monitoring ermöglicht Ihnen, Problembereiche schnell zu isolieren, um Fehler, Leistungs- und Latenzprobleme sowie deren Quellen wie Entwickler-Apps, API-Proxys, Back-End-Ziele oder die API-Plattform zu diagnostizieren.

Sehen Sie sich ein Beispielszenario an, in dem gezeigt wird, wie Sie 5xx-Probleme mit Ihren APIs mithilfe von API Monitoring beheben können. Sie können beispielsweise eine Benachrichtigung einrichten, um benachrichtigt zu werden, wenn die Anzahl der 500-Fehler einen bestimmten Schwellenwert überschreitet.

Wenn Sie benachrichtigt werden möchten, wenn eine 500-Fehlerantwort von der Richtlinie ausgelöst wird, müssen Sie die Benachrichtigung für den Statuscode 500 mit der Fehlerquelle als Proxy einrichten.

Erfassen von Diagnoseinformationen erforderlich

Wenn das Problem auch nach Befolgen der obigen Anweisungen weiterhin besteht, sammeln Sie die folgenden Diagnoseinformationen. Wenden Sie sich an den Apigee-Support und teilen Sie ihm diese Informationen mit.

Wenn Sie ein Public Cloud-Nutzer sind, geben Sie die folgenden Informationen an:

Name der Organisation
Umgebungsname
Name des API-Proxys
Vollständiger cURL-Befehl mit Anfragenutzlast (falls vorhanden), um den Fehler „500“ zu reproduzieren
Trace-Datei mit den Anfragen mit dem Fehler „500 Internal Server Error“
Wenn die Fehler „500“ derzeit nicht auftreten, geben Sie den Zeitraum mit den Zeitzoneninformationen an, in dem die Fehler „500“ in der Vergangenheit aufgetreten sind.

Wenn Sie ein Private Cloud-Nutzer sind, geben Sie die folgenden Informationen an:

Vollständige Fehlermeldung für die fehlgeschlagenen Anfragen
Name der Organisation, Umgebungsname und Name des API-Proxys, für die Sie Fehler „500“ beobachten
API-Proxy-Bundle
In der Anfrage verwendete Nutzlast (falls vorhanden)
Trace-Datei mit den Anfragen mit dem Fehler „500 Internal Server Error“
NGINX-Zugriffslogs (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log)
Message Processor-Logs (/opt/apigee/var/log/edge-message-processor/logs/system.log)
Der Zeitraum mit den Zeitzoneninformationen, in dem die Fehler „500“ aufgetreten sind.