500 Interner Serverfehler

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

Videos

In den folgenden Videos erfahren Sie mehr über die Behebung von 500 Internal Server Errors.

Symptom

Die Clientanwendung erhält als Antwort auf API-Aufrufe den HTTP-Statuscode 500 mit der Meldung "Internal Server Error". Der 500 Internal Server Error kann durch einen Fehler bei der Ausführung einer Richtlinie in Edge oder durch einen Fehler auf dem Ziel-/Back-End-Server verursacht werden.

Der HTTP-Statuscode 500 ist eine allgemeine Fehlerantwort. Das bedeutet, dass der Server auf eine unerwartete Bedingung gestoßen ist, die ihn daran gehindert hat, die Anfrage zu erfüllen. Dieser Fehler wird in der Regel vom Server zurückgegeben, wenn kein anderer Fehlercode geeignet ist.

Fehlermeldungen

Möglicherweise wird die folgende Fehlermeldung angezeigt:

HTTP/1.1 500 Internal Server Error

In einigen Fällen wird möglicherweise eine andere Fehlermeldung mit weiteren Details angezeigt. Hier ist eine Beispiel Fehlermeldung:

{
   "fault":{
      "detail":{
         "errorcode":"steps.servicecallout.ExecutionFailed"
      },
      "faultstring":"Execution of ServiceCallout callWCSAuthServiceCallout failed. Reason: ResponseCode 400 is treated as error"
   }
}

Mögliche Ursachen

Der 500 Internal Server Error kann verschiedene Ursachen haben. In Edge, können die Ursachen je nach Ort des Fehlers in zwei Hauptkategorien eingeteilt werden:

Ausführungsfehler in einer Edge-Richtlinie

Eine Richtlinie im API-Proxy kann aus irgendeinem Grund fehlschlagen. In diesem Abschnitt wird erläutert, wie Sie das Problem beheben, wenn der 500 Internal Server Error während der Ausführung einer Richtlinie auftritt.

Diagnose

Diagnoseschritte für Private und Public Cloud-Nutzer

Wenn Sie die Trace-UI-Sitzung für den Fehler haben, gehen Sie so vor:

1. Prüfen Sie, ob der Fehler durch die Ausführung einer Richtlinie verursacht wurde. Weitere Informationen finden Sie unter Ursache des Problems ermitteln.
2. Wenn der Fehler während der Richtlinienausführung aufgetreten ist, fahren Sie fort. Wenn der Fehler durch den Back-End-Server verursacht wurde, gehen Sie zu Fehler auf dem Back-End-Server.
3. Wählen Sie im Trace die API-Anfrage aus, bei der der 500 Internal Server Error auftritt.
4. Prüfen Sie die Anfrage und wählen Sie die spezifische Richtlinie aus, die fehlgeschlagen ist, oder den Ablauf mit dem Namen "Error", der unmittelbar auf die fehlgeschlagene Richtlinie im Trace folgt.
5. Weitere Details zum Fehler finden Sie entweder im Feld „error“ im Abschnitt „Properties“ oder im Fehlerinhalt.
6. Versuchen Sie anhand der von Ihnen erfassten Details zum Fehler, die Ursache zu ermitteln.

Diagnoseschritte nur für Private Cloud-Nutzer

Wenn Sie keine Trace-UI-Sitzung haben, gehen Sie so vor:

1. Prüfen Sie, ob der Fehler während der Ausführung einer Richtlinie aufgetreten ist. Weitere Informationen finden Sie unter Ursache des Problems ermitteln.
2. Wenn der Fehler durch die Richtlinienausführung verursacht wurde, fahren Sie fort. Wenn der Fehler während der Richtlinien Ausführung aufgetreten ist, fahren Sie fort. Wenn der Fehler durch den Back-End-Server verursacht wurde, gehen Sie zu Fehler auf dem Back-End-Server.
3. Ermitteln Sie anhand der NGINX-Zugriffslogs, wie unter Ursache des Problems ermitteln beschrieben, die fehlgeschlagene Richtlinie im API-Proxy und die eindeutige ID der Anfragenachricht.
4. Prüfen Sie die Message Processor-Logs (/opt/apigee/var/log/edge-message-processor/logs/system.log) und suchen Sie darin nach der eindeutigen ID der Anfragenachricht.
5. Wenn Sie die eindeutige ID der Anfragenachricht finden, prüfen Sie, ob Sie weitere Informationen zur Ursache des Fehlers erhalten können.

Auflösung

Wenn Sie die Ursache des Problems mit der Richtlinie ermittelt haben, versuchen Sie, das Problem zu beheben, indem Sie die Richtlinie korrigieren und den Proxy noch einmal bereitstellen.

Die folgenden Beispiele veranschaulichen, wie Sie die Ursache und die Lösung für verschiedene Arten von Problemen ermitteln.

Wenn Sie weitere Unterstützung bei der Fehlerbehebung für den 500 Internal Server Error benötigen oder vermuten , dass es sich um ein Problem in Edge handelt, wenden Sie sich an den Apigee -Support.

Beispiel 1: Fehler in der Service-Callout-Richtlinie aufgrund eines Fehlers auf dem Back-End Server

Wenn der Aufruf des Back-End-Servers in der Service-Callout-Richtlinie mit einem Fehler wie 4XX oder 5XX fehlschlägt, wird er als 500 Internal Server Error behandelt.

1. Hier ist ein Beispiel, bei dem der Backend-Dienst mit einem 404-Fehler in der Service Callout-Richtlinie fehlschlägt. Die folgende Fehlermeldung wird an den Endnutzer gesendet:

   {
   "fault":
        { "detail":
              { "errorcode":"steps.servicecallout.ExecutionFailed"
              },"faultstring":"Execution of ServiceCallout service_callout_v3_store_by_lat_lon
    failed. Reason: ResponseCode 404 is treated as error"
             }
        }
   }

2. Die folgende Trace-UI-Sitzung zeigt den Statuscode 500, der durch einen Fehler in der Service Callout-Richtlinie verursacht wurde:

   

3. In diesem Beispiel wird in der Eigenschaft "error" der Grund für den Fehler in der Service-Callout-Richtlinie als "ResponseCode 404 is treated as error". aufgeführt. Dieser Fehler kann auftreten, wenn die Ressource, auf die über die Back-End-Server-URL in der Service-Callout-Richtlinie zugegriffen wird, nicht verfügbar ist.
4. Prüfen Sie die Verfügbarkeit der Ressource auf dem Back-End-Server. Sie ist möglicherweise vorübergehend oder dauerhaft nicht verfügbar oder wurde an einen anderen Ort verschoben.

Auflösung für Beispiel 1

1. Prüfen Sie die Verfügbarkeit der Ressource auf dem Back-End-Server. Sie ist möglicherweise vorübergehend oder dauerhaft nicht verfügbar oder wurde an einen anderen Ort verschoben.
2. Korrigieren Sie die Back-End-Server-URL in der Service-Callout-Richtlinie, sodass sie auf eine gültige und vorhandene Ressource verweist.
3. Wenn die Ressource nur vorübergehend nicht verfügbar ist, versuchen Sie, die API-Anfrage zu senden, sobald die Ressource wieder verfügbar ist.

Beispiel 2: Fehler in der Richtlinie zum Extrahieren von Variablen

Sehen wir uns nun ein weiteres Beispiel an, bei dem der 500 Internal Server Error durch einen Fehler in der Richtlinie zum Extrahieren von Variablen verursacht wird. Wir zeigen Ihnen, wie Sie das Problem beheben.

1. Der folgende Trace in der UI-Sitzung zeigt den Statuscode 500 aufgrund eines Fehlers in der Richtlinie zum Extrahieren Variablen:

   

2. Wählen Sie die fehlgeschlagene Richtlinie zum Extrahieren von Variablen aus, scrollen Sie nach unten und suchen Sie im Abschnitt "Error Content" nach weiteren Details:
   
   
3. Der Fehlerinhalt gibt an, dass die"serviceCallout.oamCookieValidationResponse" Variable in der Richtlinie zum Extrahieren von Variablen nicht verfügbar ist. Wie der Name der Variablen angibt, sollte sie die Antwort der vorherigen Service-Callout-Richtlinie enthalten.
4. Wählen Sie im Trace die Service-Callout-Richtlinie aus. Möglicherweise stellen Sie fest, dass die "serviceCallout.oamCookieValidationResponse" Variable nicht festgelegt wurde. Das bedeutet, dass der Aufruf des Backend-Dienstes fehlgeschlagen ist, was zu einer leeren Antwortvariablen geführt hat.
5. Obwohl die Service-Callout-Richtlinie fehlgeschlagen ist, wird die Ausführung der Richtlinien nach der Service Callout-Richtlinie fortgesetzt, da das Flag „continueOnError“ in der Service-Callout-Richtlinie auf „true“ gesetzt ist, wie unten gezeigt:
   
   

   <ServiceCallout async="false" continueOnError="true" enabled="true" name="Callout.OamCookieValidation">
     <DisplayName>Callout.OamCookieValidation</DisplayName>
     <Properties />
     <Request clearPayload="true" variable="serviceCallout.oamCookieValidationRequest">
       <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
     </Request>
     <Response>serviceCallout.oamCookieValidationResponse</Response>
     <HTTPTargetConnection>
       <Properties />
       <URL>http://{Url}</URL>
     </HTTPTargetConnection>
   </ServiceCallout>

6. Notieren Sie die eindeutige Nachrichten-ID "X-Apigee.Message-ID" für diese spezifische API Anfrage aus dem Trace, wie folgt:
   1. Wählen Sie in der Anfrage die Phase „Analytics Data Recorded“ aus.
   2. Scrollen Sie nach unten und notieren Sie den Wert von X-Apigee.Message-ID.

   

7. Sehen Sie sich das Message Processor-Log (/opt/apigee/var/log/edge-message-processor/system.log) an und suchen Sie nach der eindeutigen Nachrichten-ID, die Sie in Schritt 6 notiert haben. Für die spezifische API Anfrage wurde die folgende Fehlermeldung beobachtet:

   2017-05-05 07:48:18,653 org:myorg env:prod api:myapi rev:834 messageid:rrt-04984fed9e5ad3551-c-wo-32168-77563  NIOThread@5 ERROR HTTP.CLIENT - HTTPClient$Context.onTimeout() : ClientChannel[C:]@149081 useCount=1 bytesRead=0 bytesWritten=0 age=3002ms lastIO=3002ms .onConnectTimeout connectAddress=mybackend.domain.com/XX.XX.XX.XX:443 resolvedAddress=mybackend.domain.com/XX.XX.XX.XX

   Der obige Fehler gibt an, dass die Service-Callout-Richtlinie aufgrund eines Verbindungs zeitfehlers beim Herstellen einer Verbindung zum Back-End-Server fehlgeschlagen ist.

8. Um die Ursache für den Verbindungszeitfehler zu ermitteln, führen Sie den telnet Befehl vom Message Processor zu den Back-End-Servern aus. Der Befehl „telnet“ hat den Fehler „Connection timed out“ zurückgegeben, wie unten gezeigt:

   telnet mybackend.domain.com 443
   Trying XX.XX.XX.XX...
   telnet: connect to address XX.XX.XX.XX: Connection timed out

   Dieser Fehler tritt in der Regel unter den folgenden Umständen auf:

   • Wenn der Back-End-Server nicht so konfiguriert ist, dass Traffic von den Edge Message Processors zugelassen wird.
   • Wenn der Back-End-Server den spezifischen Port nicht überwacht.

   Im obigen Beispiel ist zwar die Richtlinie zum Extrahieren von Variablen fehlgeschlagen, die eigentliche Ursache war jedoch, dass Edge keine Verbindung zum Back-End-Server in der Service-Callout Richtlinie herstellen konnte. Die Ursache für diesen Fehler war, dass der Back-End-Server nicht so konfiguriert war, dass Traffic von den Edge Message Processors zugelassen wird.

   Ihre eigene Richtlinie zum Extrahieren von Variablen verhält sich anders und kann aus einem anderen Grund fehlschlagen. Sie können das Problem entsprechend beheben, je nach Ursache für den Fehler in Ihrer Richtlinie zum Extrahieren von Variablen. Prüfen Sie dazu die Nachricht in der error Eigenschaft.

Auflösung für Beispiel 2

1. Beheben Sie die Ursache für den Fehler in der Richtlinie zum Extrahieren von Variablen entsprechend.
2. Im obigen Beispiel bestand die Lösung darin, die Netzwerkkonfiguration so zu korrigieren, dass Traffic von Edge Message Processors zu Ihrem Back-End-Server zugelassen wird. Dazu wurden die IP-Adressen der Message Processors auf dem spezifischen Back-End-Server auf die Zulassungsliste gesetzt. Unter Linux können Sie beispielsweise iptables verwenden, um Traffic von den IP-Adressen des Message Processors auf dem Back-End-Server zuzulassen.

Beispiel 3: Fehler in der JavaCallout-Richtlinie

Sehen wir uns nun ein weiteres Beispiel an, bei dem der 500 Internal Server Error durch einen Fehler in der JavaCallout-Richtlinie verursacht wird. Wir zeigen Ihnen, wie Sie das Problem beheben.

1. Der folgende UI-Trace zeigt den Statuscode 500 aufgrund eines Fehlers in der JavaCallout-Richtlinie:

   

2. Wählen Sie den Ablauf mit dem Namen "Error" und dann die fehlgeschlagene JavaCallout-Richtlinie aus, um die Fehlerdetails zu erhalten, wie in der folgenden Abbildung gezeigt:

   

3. In diesem Beispiel zeigt die Eigenschaft "error" im Abschnitt „Properties“, dass der Fehler auf ein abgelaufenes Passwort zurückzuführen ist, das beim Herstellen einer Verbindung zur Oracle-Datenbank aus der JavaCallout-Richtlinie verwendet wurde. Ihr eigener Java-Callout verhält sich anders und wird eine andere Nachricht in der Eigenschaft error ausfüllen.
4. Prüfen Sie den JavaCallout-Richtliniencode und bestätigen Sie die richtige Konfiguration, die verwendet werden muss.

Auflösung für Beispiel 3

Korrigieren Sie den Java-Callout-Code oder die Konfiguration entsprechend, um die Laufzeitausnahme zu vermeiden. In dem obigen Beispiel für einen Java-Callout-Fehler muss das richtige Passwort für die Verbindung zur Oracle-Datenbank verwendet werden, um das Problem zu beheben.

Fehler auf dem Back-End-Server

Ein 500 Internal Server Error kann auch vom Back-End-Server stammen. In diesem Abschnitt wird erläutert, wie Sie das Problem beheben, wenn der Fehler vom Back-End-Server stammt.

Diagnose

Diagnoseschritte für alle Nutzer

Die Ursache anderer Back-End-Fehler kann sehr unterschiedlich sein. Sie müssen jede Situation unabhängig diagnostizieren.

1. Prüfen Sie, ob der Fehler durch den Back-End-Server verursacht wurde. Weitere Informationen finden Sie unter Ursache des Problems ermitteln.
2. Wenn der Fehler durch den Back-End-Server verursacht wurde, fahren Sie fort. Wenn der Fehler während der Richtlinienausführung aufgetreten ist, gehen Sie zu Ausführungsfehler in einer Edge Richtlinie.
3. Führen Sie je nachdem, ob Sie Zugriff auf eine Trace-Sitzung für die fehlgeschlagene API haben oder ob das Back-End ein Node.js-Server ist, die folgenden Schritte aus:

Wenn Sie keine Trace-Sitzung für den fehlgeschlagenen API-Aufruf haben:

1. Wenn der UI-Trace für die fehlgeschlagene Anfrage nicht verfügbar ist, prüfen Sie die Back-End-Server Logs, um Details zum Fehler zu erhalten.
2. Aktivieren Sie nach Möglichkeit den Debug-Modus auf dem Back-End-Server, um weitere Details zum Fehler und zur Ursache zu erhalten.

Wenn Sie eine Trace-Sitzung für den fehlgeschlagenen API-Aufruf haben:

Wenn Sie eine Trace-Sitzung haben, können Sie das Problem mit den folgenden Schritten diagnostizieren.

1. Wählen Sie im Trace-Tool die API-Anfrage aus, bei der der 500 Internal Server Error aufgetreten ist.
2. Wählen Sie in der fehlgeschlagenen API-Anfrage die Phase „Response received from target server“ aus, wie in der folgenden Abbildung gezeigt:

   

3. Details zum Fehler finden Sie im Abschnitt "Response Content".

   

4. In diesem Beispiel enthält der Antwortinhalt, ein SOAP-Envelope, die Fehlermeldung "Not Authorized". Die wahrscheinlichste Ursache für dieses Problem ist, dass der Nutzer nicht die richtigen Anmeldedaten (Nutzername/Passwort, Zugriffstoken usw.) an den Back-End-Server übergeben hat. Dieses Problem kann behoben werden, indem die richtigen Anmeldedaten an den Back-End-Server übergeben werden.

Wenn das Back-End ein Node.js-Server ist :

1. Wenn das Back-End ein Node.js-Back-End-Server ist, prüfen Sie die Node.js-Logs für den spezifischen API-Proxy in der Edge-UI (sowohl Public als auch Private Cloud-Nutzer können die Node.js-Logs prüfen). Wenn Sie ein Edge Private Cloud-Nutzer sind, können Sie auch in den Message Processor-Logs (/opt/apigee/var/log/edge-message-processor/logs/system.log) nach weiteren Details zum Fehler suchen.
   
   

   Option „NodeJS Logs“ in der Edge-UI – Tab „Overview“ des API-Proxys

   

Auflösung

1. Nachdem Sie die Ursache des Fehlers ermittelt haben, beheben Sie das Problem auf Ihrem Back-End-Server.
2. Wenn es sich um einen Node.js-Back-End-Server handelt:
   1. Prüfen Sie, ob der Fehler in Ihrem benutzerdefinierten Code auftritt, und beheben Sie das Problem, wenn möglich.
   2. Wenn der Fehler nicht in Ihrem benutzerdefinierten Code auftritt oder Sie Unterstützung benötigen, wenden Sie sich an den Apigee-Support.

Wenn Sie weitere Unterstützung bei der Fehlerbehebung für den 500 Internal Server Error benötigen oder vermuten , dass es sich um ein Problem in Edge handelt, wenden Sie sich an den Apigee -Support.

Ursache des Problems ermitteln

Mit einer der folgenden Methoden können Sie ermitteln, ob der 500 Internal Server Error während der Ausführung einer Richtlinie im API-Proxy oder vom Back-End-Server ausgelöst wurde.

Trace in der UI verwenden

Hinweis: Die Schritte in diesem Abschnitt können sowohl von Public als auch von Private Cloud-Nutzern ausgeführt werden.

1. Wenn das Problem weiterhin besteht, aktivieren Sie den Trace in der UI für die betroffene API.
2. Nachdem Sie den Trace erfasst haben, wählen Sie die API-Anfrage aus, bei der der Antwortcode als 500 angezeigt wird.
3. Gehen Sie alle Phasen der fehlgeschlagenen API-Anfrage durch und prüfen Sie, in welcher Phase der 500 Internal Server Error zurückgegeben wird:
   1. Wenn der Fehler während der Ausführung einer Richtlinie auftritt, fahren Sie mit Ausführungsfehler in einer Edge-Richtlinie fort.
   2. Wenn der Back-End-Server mit 500 Internal Server geantwortet hat, fahren Sie mit Fehler auf dem Back-End-Server fort.

API-Monitoring verwenden

Hinweis:Die Schritte in diesem Abschnitt können nur von Public Cloud-Nutzern ausgeführt werden.

Mit API-Monitoring können Sie Problembereiche schnell 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. Sie können beispielsweise eine Benachrichtigung einrichten, die Sie benachrichtigt, wenn die Anzahl der Statuscodes 500 oder der Fehler steps.servicecallout.ExecutionFailed einen bestimmten Grenzwert überschreitet.

NGINX-Zugriffslogs verwenden

Hinweis: Die Schritte in diesem Abschnitt sind nur für Edge Private Cloud-Nutzer vorgesehen.

Sie können auch in den NGINX-Zugriffslogs nachsehen, ob der Statuscode 500 während der Ausführung einer Richtlinie im API-Proxy oder vom Back-End-Server ausgelöst wurde. Dies ist besonders nützlich, wenn das Problem in der Vergangenheit aufgetreten ist oder wenn es nur zeitweise auftritt und Sie den Trace in der UI nicht erfassen können. Führen Sie die folgenden Schritte aus, um diese Informationen aus den NGINX-Zugriffslogs zu ermitteln:

1. Prüfen Sie die NGINX-Zugriffslogs (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log).
2. Suchen Sie nach 500-Fehlern für den spezifischen API-Proxy im angegebenen Zeitraum.
3. Wenn 500-Fehler vorhanden sind, prüfen Sie, ob es sich um einen Richtlinien- oder einen Zielserverfehler handelt, wie unten gezeigt:

   Beispieleintrag mit einem Richtlinienfehler

   

   Beispieleintrag mit einem Zielserverfehler

   

4. Nachdem Sie ermittelt haben, ob es sich um einen Richtlinien- oder einen Zielserverfehler handelt:
   1. Fahren Sie mit Ausführungsfehler in einer Edge-Richtlinie fort, wenn es sich um einen Richtlinienfehler handelt.
   2. Fahren Sie mit Fehler auf dem Back-End-Server fort, wenn es sich um einen Ziel serverfehler handelt.