503 Dienst nicht verfügbar

Sie sehen die Dokumentation zu Apigee Edge.
Zur Apigee X-Dokumentation weitere Informationen

Videos

Weitere Informationen zu 503-Fehlern finden Sie in den folgenden Videos:

Video	Beschreibung
Fehlerbehebung: Fehler 503 „Dienst nicht verfügbar“ aufgrund eines DNS-Problems	Hier finden Sie Informationen zu folgenden Themen: Fehler 503 „Dienst nicht verfügbar“ aufgrund von DNS-Auflösung und netzwerkbezogenen Problemen in Apigee Edge Fehlerbehebung und Behebung eines Echtzeitfehlers 503 „Dienst nicht verfügbar“, der durch ein Problem mit der DNS-Auflösung verursacht wird
Fehlerbehebung und Behebung des Fehlers 503 „Dienst nicht verfügbar“ aufgrund eines Netzwerkproblems	Fehlerbehebung und Behebung eines Echtzeitfehlers 503 Service Nicht verfügbar, der durch ein Netzwerkproblem in Apigee Edge verursacht wird

Symptom

Nach einem API-Proxy-Aufruf erhält die Clientanwendung den HTTP-Antwortstatus 503 mit der Meldung Service Nicht verfügbar.

Fehlermeldungen

Folgende Fehlermeldung wird angezeigt:

HTTP/1.1 503 Service Unavailable
      

In der HTTP-Antwort wird auch die folgende Fehlermeldung angezeigt:

Dienst nicht verfügbar

{
   "fault": {
      "faultstring": "The Service is temporarily unavailable",
      "detail": {
           "errorcode": "messaging.adaptors.http.flow.ServiceUnavailable"
       }
    }
}
      

Mögliche Ursachen

Die HTTP-Antwort 503 Service Nicht verfügbar mit dem Fehlercode messaging.adaptors.http.flow.ServiceUnavailable tritt auf, wenn beim Nachrichtenprozessor von Apigee Edge während der Kommunikation mit dem Back-End-Server Fehler aufgrund von Zeitüberschreitungen, falschem Hostnamen oder SSL-Handshakefehlern auftreten.

Mögliche Ursachen für die Antwort 503 Service Unavailable sind:

Ursache	Beschreibung	Wer kann die Schritte zur Fehlerbehebung ausführen?
Verbindungsfehler aufgrund falscher DNS-Auflösung	Die DNS-Auflösung des Zielservers führte zu fehlerhaften IP-Adressen, die zu Verbindungsfehlern führten.	Edge Private Cloud-Nutzer
Verbindungsfehler	Netzwerk- oder Verbindungsprobleme verhindern, dass der Client eine Verbindung zum Server herstellt.	Edge Private Cloud-Nutzer
Falscher Name des Zielserver-Hostnamens	Der angegebene Zielserver-Host ist falsch oder enthält unerwünschte Zeichen (z. B. Leerzeichen).	Nutzer von Edge Public und Private Cloud
Fehler beim SSL-Handshake	Der TLS/SSL-Handshake zwischen Client und Server ist fehlgeschlagen. (Die Fehlerbehebung für diese Problemklasse wird in einem anderen Thema behandelt.)	Nutzer von Edge Public und Private Cloud

Allgemeine Diagnoseschritte

Nachrichten-ID der fehlgeschlagenen Anfrage ermitteln

Verbindungsfehler aufgrund falscher DNS-Auflösung

Diagnose

1. Bestimmen Sie die Nachrichten-ID der fehlgeschlagenen Anfrage.
2. Suchen Sie im Message Processor-Protokoll nach der spezifischen Anfragenachrichten-ID (/opt/apigee/var/log/edge-message-processor/logs/system.log). Es können folgende Fehler auftreten:
   
   Ein onConnectTimeout-Fehler gibt an, dass der Message Processor innerhalb des voreingestellten Zeitlimits für die Verbindung (Standardwert: 3 Sekunden) keine Verbindung zum Back-End-Server herstellen konnte.

   2019-08-14 09:11:49,314 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onTimeout() : ClientChannel[Connected:]@164162 useCount=1 bytesRead=0 bytesWritten=0 age=3001ms lastIO=3001ms .onConnectTimeout connectAddress=www.abc.com/11.11.11.11  resolvedAddress=www.abc.com/22.22.22.22
   
   2019-08-14 09:11:49,333 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - RequestWriteListener.onTimeout() : RequestWriteListener.onTimeout(HTTPRequest@6b393600)
         

3. Notieren Sie sich die aufgelöste IP-Adresse im Fehler onConnectTimeout und prüfen Sie, ob die IP-Adresse für Ihren Back-End-Server gültig ist. Wenn die IP-Adresse gültig ist, gehen Sie zu Verbindungsfehler.
4. Wenn die IP-Adresse ungültig ist, kann dies höchstwahrscheinlich auf Probleme mit der DNS-Auflösung zurückzuführen sein.
5. Wiederholen Sie Schritt 3 und Schritt 4 für weitere fehlerhafte API-Anfragen und prüfen Sie, ob Sie dieselbe oder eine andere ungültige IP-Adresse sehen.
6. Suchen Sie im Message Processor-Protokoll (/opt/apigee/var/log/edge-message-processor/logs/system.log) nach Nachrichten mit dem Suchbegriff DNS Refresh. Überprüfen Sie, ob hin und wieder fehlerhafte oder ungültige IP-Adressen zum DNS-Cache des Message Processor hinzugefügt werden.

   2019-08-14 09:11:49,314 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@0 INFO c.a.p.h.d.DNSCachedAddress - DNSCachedAddress.reportDifferences() : DNS Refresh for host: apitarget-uat.schemeweb.co.uk:4436. Added 2 IPs [www.abc.com/22.22.22.22, www.abc.com/33.33.33.33] Removed 1 IPs [www.abc.com/11.11.11.11]
         

7. Dieses Problem kann auftreten, wenn Probleme mit den autoritativen DNS-Servern oder den in /etc/resolv.conf konfigurierten Nameservern auftreten.
   
   Normalerweise sind mindestens ein autoritativer DNS-Server für die DNS-Auflösung konfiguriert. Wenn keine autoritativen DNS-Server vorhanden sind, wird auf die Konfigurationseinrichtung in /etc/resolv.conf zurückgesetzt und die DNS-Auflösung entsprechend durchgeführt. Beispiel: Wenn /etc/resolv.conf für die Verwendung bestimmter Nameserver konfiguriert ist, werden diese Nameserver zur DNS-Auflösung genutzt.
8. Wenn Probleme mit autoritativen DNS-Servern oder in /etc/resolv.conf angegebenen Nameservern auftreten, werden die Hostnamen des Back-End-Servers in ungültige oder ungültige IP-Adressen aufgelöst. Die fehlerhaften/ungültigen IP-Adressen werden dann im DNS-Cache des Message Processor gespeichert.
   1. Wenn das Problem mit autoritativen DNS-Servern oder Nameservern in /etc/resolv.conf dauerhaft besteht, verbleiben die ungültigen/ungültigen IP-Adressen weiterhin im DNS-Cache des Message Processor. Solange die fehlerhaften IP-Adressen im DNS-Cache des Message Processor gespeichert sind, schlagen die Anfragen für alle diese APIs, die den spezifischen Back-End-Server verwenden, mit dem Fehler 503 fehl.
   2. Wenn das Problem mit autoritativen DNS-Servern oder Nameservern in /etc/resolv.conf zeitweise auftritt, werden gültige und fehlerhafte IP-Adressen mit Unterbrechungen im DNS-Cache gespeichert. In diesem Fall werden ab und zu 503-Fehler für alle APIs angezeigt, die den jeweiligen Back-End-Server verwenden.
9. Wenn das Problem mit den DNS-Servern dauerhaft besteht, treten fortlaufende Fehler auf. Wenn das Problem mit den DNS-Servern nur zeitweise auftritt, treten zeitweise Fehler auf. Das heißt, wenn der Hostname des Back-End-Servers in falsche IP-Adressen aufgelöst wird, treten 503-Fehler auf. Wenn die Hostnamen des Back-End-Servers in gute IP-Adressen aufgelöst werden, werden Sie erfolgreiche Antworten beobachten.

Auflösung

Wenden Sie sich an Ihren Betriebssystemadministrator und beheben Sie die Probleme mit den DNS-Servern.

1. Wenn ein Problem mit den autoritativen DNS-Servern oder Nameservern in /etc/resolv.conf auftritt, beheben Sie es gemeinsam mit dem entsprechenden Server.
2. Wenn es ein Problem mit der Konfiguration in /etc/resolv.conf auf Systemen mit Message Processorn gibt, beheben Sie das Konfigurationsproblem.

Verbindungsfehler

Ein Verbindungsfehler tritt auf, wenn ein Apigee Edge-Nachrichtenprozessor versucht, eine Verbindung zu einem Back-End-Server herzustellen, und eines der folgenden Probleme auftritt:

• Message Processor kann keine Verbindung innerhalb des voreingestellten Zeitlimits für Verbindungen herstellen. (Standardeinstellung: 3 Sekunden)
• Der Back-End-Server lehnt die Verbindung ab.

Diagnose

1. Bestimmen Sie die Nachrichten-ID der fehlgeschlagenen Anfrage.
2. Suchen Sie im Message Processor-Protokoll (/opt/apigee/var/log/edge-message-processor/logs/system.log) nach der spezifischen Anfragenachrichten-ID. Es können folgende Fehler auftreten:
   1. Ein onConnectTimeout-Fehler weist darauf hin, dass der Message Processor innerhalb des voreingestellten Zeitlimits für die Verbindung keine Verbindung zum Back-End-Server herstellen konnte.

      2016-06-23 09:11:49,314 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@2 ERROR HTTP.CLIENT - HTTPClient$Context.onTimeout() : ClientChannel[C:]@10 useCount=1 bytesRead=0 bytesWritten=0 age=3001ms lastIO=3001ms .onConnectTimeout connectAddress=www.abc.com/11.11.11.11:80 resolvedAddress=www.abc.com/11.11.11.11
      2016-06-23 09:11:49,333 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@2 ERROR ADAPTORS.HTTP.FLOW - RequestWriteListener.onTimeout() : RequestWriteListener.onTimeout(HTTPRequest@6b393600)
      

   2. Der Fehler java.net.ConnectException: Connection abgelehnte gibt an, dass die Verbindung vom Back-End-Server abgelehnt wurde.

      14:40:16.531 +0530
      2016-06-17 09:10:16,531 org:myorg env:prod api:www.abc.com rev:1 rrt07eadn-22739-40983870-15 NIOThread@2 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() : connect to www.abc.com:11.11.11.11:443 failed with exception {}
      java.net.ConnectException: Connection refused
      at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) ~[na:1.7.0_75]
      at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:739) ~[na:1.7.0_75]
      at com.apigee.nio.ClientChannel.finishConnect(ClientChannel.java:121) ~[nio-1.0.0.jar:na]
      at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:108) ~[nio-1.0.0.jar:na]
      

3. Prüfen Sie mit dem Befehl telnet, ob Sie von jedem der Message Processor aus eine direkte Verbindung zum jeweiligen Back-End-Server herstellen können:
   1. Wenn der Back-End-Server in eine einzelne IP-Adresse aufgelöst wird, verwenden Sie den folgenden Befehl:

      telnet BackendServer-IPaddress 443
                

   2. Wenn der Back-End-Server in mehrere IP-Adressen aufgelöst wird, verwenden Sie den Hostnamen des Back-End-Servers im telnet-Befehl wie unten gezeigt:

      telnet BackendServer-HostName 443
                

4. Wenn Sie eine Verbindung zum Back-End-Server herstellen können, wird möglicherweise eine Meldung wie Connected to backend-server angezeigt. Wenn Sie keine Verbindung zum Back-End-Server herstellen können, liegt dies möglicherweise daran, dass die IP-Adressen der Message Processor für den jeweiligen Back-End-Server nicht auf der Zulassungsliste stehen.

Auflösung

Gewähren Sie Zugriff auf die IP-Adressen des Message Processor auf dem spezifischen Back-End-Server, um Traffic von den Edge Message Processorn den Zugriff auf Ihren Back-End-Server zu ermöglichen. Unter Linux könnten Sie beispielsweise iptables verwenden, um den Traffic von den IP-Adressen des Message Processor auf dem Back-End-Server zuzulassen.

Wenn das Problem weiterhin besteht, wenden Sie sich an Ihren Netzwerkadministrator, um es zu ermitteln und zu beheben. Wenn Sie weitere Unterstützung von Apigee benötigen, wenden Sie sich bitte an den Apigee-Support.

Falscher Hostname des Zielservers

Diagnose

Wenn der auf dem Zielserver angegebene Hostname falsch ist, erhalten Sie die Antwort 503 Service Nicht verfügbar mit dem Fehlercode messaging.adaptors.http.flow.ServiceUnavailable..

Auflösung

1. Achten Sie darauf, dass der in der Konfiguration des Zielendpunkts oder in der Definition des Zielservers angegebene Hostname des Zielservers korrekt ist und keine unerwünschten Leerzeichen oder Sonderzeichen enthält.
2. Wenn Sie eine AssignMessage/JavaScript-Richtlinie verwenden, um den Hostnamen des Zielservers dynamisch zu generieren, prüfen Sie die Richtliniendefinition und den Code und sorgen Sie dafür, dass der Hostname des Zielservers korrekt generiert wird.

SSL-Handshake-Fehler

Ein komplettes Playbook zur Fehlerbehebung beschäftigt sich mit TLS/SSL-Handshakefehlern. Siehe SSL-Handshakefehler.

Ursache des Problems ermitteln

Bestimmte Arten von Fehlern können entweder bei der eingehenden Verbindung (nach Norden) oder bei der ausgehenden Verbindung (nach Süden) auftreten. Ein eingehender (nordgebundener) Fehler tritt zwischen der Clientanwendung und Edge auf. Ein ausgehender Fehler (Southbound) tritt zwischen Edge und dem Back-End-Zielserver auf. Um diese Art von Problemen zu diagnostizieren, muss Ihr erster Job herausfinden, ob der Fehler bei der Verbindung nach Norden oder Süden auftritt.

Verbindungen in nördlicher und südlicher Richtung

In Edge können Sie den Fehler 503 Service Nicht verfügbar entweder bei der eingehenden oder ausgehenden Verbindung sehen:

• Eingehende Verbindung (oder Nordverbindung): Die Verbindung zwischen der Clientanwendung und dem Edge Router. Der Router ist die Komponente von Apigee Edge, die eingehende Anfragen an das System verarbeitet.
• Ausgehende Verbindung (oder Südverbindung) – Die Verbindung zwischen dem Edge Message Processor und dem Back-End-Server. Der Message Processor ist eine Komponente von Apigee Edge, die API-Anfragen an Back-End-Zielserver weiterleitet.

Wenn Sie Edge Public Cloud-Nutzer sind, kennen Sie interne Komponenten wie den Router oder den Message Processor wahrscheinlich nicht. Diese internen Komponenten sind für Nutzer von Public Clouds weder sichtbar noch zugänglich. Wenn möglich, bieten wir alternative Möglichkeiten zur Untersuchung des Problems an, die keinen direkten Zugriff auf diese Komponenten erfordern.

Die folgende Abbildung zeigt für Apigee Edge Verbindungen nach Norden und Süden.

Herausfinden, wo der Fehler „503 Service Nicht verfügbar“ aufgetreten ist

Prüfen Sie mit einem der folgenden Verfahren, ob der Fehler „503 Service Nicht verfügbar“ an der Verbindung nach Norden oder Süden aufgetreten ist.