503 Dienst nicht verfügbar

<ph type="x-smartling-placeholder"></ph> Sie sehen die Dokumentation zu Apigee Edge.
Gehen Sie zur Apigee X-Dokumentation. Weitere Informationen

Videos

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

Video Beschreibung
Fehler „503: Dienst nicht verfügbar“ aufgrund eines DNS-Problems beheben Hier finden Sie Informationen zu folgenden Themen: <ph type="x-smartling-placeholder">
    </ph>
  • 503-Fehler „Dienst nicht verfügbar“, der durch die DNS-Auflösung und netzwerkbezogene Probleme in Apigee Edge verursacht wird
  • Echtzeit-Fehler „503 Service Unavailable“ beheben, der durch ein Problem bei der DNS-Auflösung verursacht wurde
Fehler „503: Dienst nicht verfügbar“ aufgrund eines Netzwerkproblems beheben Fehlerbehebung und Behebung des Fehlers „503 Dienst nicht verfügbar“ in Echtzeit aufgrund eines Netzwerkproblems in Apigee Edge

Symptom

Die Clientanwendung empfängt den HTTP-Antwortstatus 503 mit der Nachricht Service Unavailable. nach einem API-Proxy-Aufruf.

Fehlermeldungen

Es wird die folgende Fehlermeldung angezeigt:

HTTP/1.1 503 Service Unavailable

Außerdem sehen Sie in der HTTP-Antwort die folgende Fehlermeldung:

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 Unavailable mit dem Fehlercode messaging.adaptors.http.flow.ServiceUnavailable tritt auf, wenn der Message Processor von Apigee Edge aufgrund einer Zeitüberschreitung der Verbindung Fehler aufweist Hostnamen oder SSL-Handshake-Fehler während der Kommunikation mit dem Back-End-Server.

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

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

Allgemeine Diagnoseschritte

Nachrichten-ID der fehlgeschlagenen Anfrage ermitteln

Trace-Tool

So ermitteln Sie die Nachrichten-ID der fehlgeschlagenen Anfrage mithilfe des Trace-Tools:

  1. Wenn das Problem weiterhin besteht, aktivieren Sie die Trace-Sitzung für die betroffene API.
  2. Führen Sie den API-Aufruf aus und reproduzieren Sie das Problem – „503 Service Nicht verfügbar mit Fehlercode messaging.adaptors.http.flow.ServiceUnavailable.“
  3. Wählen Sie eine der fehlgeschlagenen Anfragen aus.
  4. Navigieren Sie zur AX-Phase und ermitteln Sie die Nachrichten-ID (X-Apigee.Message-ID) der Anfrage, indem Sie im Abschnitt Phase Details nach unten scrollen, wie in der folgenden Abbildung dargestellt.

    Nachrichten-ID im Abschnitt „Phasendetails“

NGINX-Zugriffslogs

So ermitteln Sie die Nachrichten-ID der fehlgeschlagenen Anfrage mithilfe der NGINX-Zugriffslogs:

Sie können auch die NGINX-Zugriffsprotokolle heranziehen, um die Nachrichten-ID für die 503-Fehler zu ermitteln. Dies ist besonders nützlich, wenn das Problem in der Vergangenheit aufgetreten ist oder zeitweise auftritt. und Sie können den Trace nicht in der Benutzeroberfläche erfassen. 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 503-Fehlern für den spezifischen API-Proxy während eines bestimmten Zeitraums (wenn das Problem in der Vergangenheit aufgetreten ist) oder wenn immer noch Anfragen mit 503 fehlschlagen.
  3. Wenn 503-Fehler mit X-Apigee-Failed-code Messaging.adaptors.http.flow.ServiceUnavailable auftreten, Notieren Sie sich die Nachrichten-ID für eine oder mehrere Anfragen, wie im folgenden Beispiel gezeigt:

    Beispieleintrag mit dem Fehler 503

    Beispieleintrag mit Statuscode, Nachrichten-ID, Fehlerquelle und Fehlercode

Verbindungsfehler aufgrund falscher DNS-Auflösung

Diagnose

  1. Ermitteln Sie die Nachrichten-ID der fehlgeschlagenen Anfrage.
  2. Suchen Sie im Message Processor-Log nach der spezifischen Anfragenachrichten-ID (/opt/apigee/var/log/edge-message-processor/logs/system.log). Möglicherweise treten die folgenden Fehler auf:

    Ein onConnectTimeout-Fehler gibt an, dass der Message Processor innerhalb des voreingestellten Zeitlimits für Verbindungen (Standardeinstellung: 3 Sekunden) keine Verbindung zum Backend-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 sie für Ihren Back-End-Server gültig ist. Wenn die IP-Adresse gültig ist, fahren Sie mit Verbindungsfehler fort.
  4. Wenn die IP-Adresse ungültig ist, wird dies höchstwahrscheinlich durch Probleme mit der DNS-Auflösung verursacht.
  5. Wiederholen Sie Schritt 3 und Schritt 4 für weitere fehlgeschlagenen API-Anfragen und prüfen Sie, ob dieselbe oder eine andere ungültige IP-Adresse angezeigt wird.
  6. Suchen Sie im Message Processor-Protokoll (/opt/apigee/var/log/edge-message-processor/logs/system.log) nach Nachrichten mit dem Stichwort DNS Refresh. Prüfen Sie, ob ab und zu ungültige 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 bei Problemen mit den autoritativen DNS-Servern oder den in /etc/resolv.conf konfigurierten Nameservern auftreten.

    In der Regel kann ein oder mehrere autoritative DNS-Server für die DNS-Auflösung konfiguriert sein. Wenn keine autoritativen DNS-Server vorhanden sind, wird die Konfiguration in /etc/resolv.conf verwendet und die DNS-Auflösung entsprechend durchgeführt. Wenn die /etc/resolv.conf beispielsweise für die Verwendung bestimmter Nameserver konfiguriert ist, werden diese Nameserver für die DNS-Auflösung verwendet.
  8. Bei Problemen mit autoritativen DNS-Servern oder Nameservern, die in /etc/resolv.conf angegeben sind, werden die Hostnamen der Backend-Server in ungültige bzw. ungültige IP-Adressen aufgelöst. Die ungültigen/ungültigen IP-Adressen werden dann im DNS-Cache des Message Processor gespeichert.
    1. Wenn das Problem mit autoritativen DNS-Servern oder Nameservern, die in /etc/resolv.conf angegeben sind, dauerhaft ist, verbleiben die ungültigen/ungültigen IP-Adressen im DNS-Cache des Message Processor. Solange die ungültigen IP-Adressen im DNS-Cache des Message Processor gespeichert sind, schlagen die Anfragen für alle diese APIs, die den jeweiligen Backend-Server verwenden, mit dem Fehler 503 fehl.
    2. Wenn das Problem mit autoritativen DNS-Servern oder Nameservern, die in /etc/resolv.conf angegeben sind, zeitweise auftritt, werden gute und fehlerhafte IP-Adressen ab und zu im DNS-Cache gespeichert. In diesem Fall werden ab und zu für alle APIs, die den jeweiligen Back-End-Server verwenden, 503-Fehler angezeigt.
  9. Wenn das Problem mit den DNS-Servern dauerhaft ist, werden kontinuierliche Fehler angezeigt. Wenn das Problem mit den DNS-Servern zeitweise auftritt, werden Ihnen zeitweise Fehler angezeigt. Wenn also der Hostname des Back-End-Servers in ungültige IP-Adressen aufgelöst wird, tritt der Fehler 503 auf. Und 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 den Administrator Ihres Betriebssystems, um die Probleme mit den DNS-Servern zu beheben.

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

Verbindungsfehler

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

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

Diagnose

  1. Ermitteln Sie die Nachrichten-ID der fehlgeschlagenen Anfrage.
  2. Suchen Sie im Message Processor-Log nach der spezifischen Anfragenachrichten-ID (/opt/apigee/var/log/edge-message-processor/logs/system.log). Es können folgende Fehler auftreten: <ph type="x-smartling-placeholder">
      </ph>
    1. Ein onConnectTimeout-Fehler zeigt an, dass der Message Processor nicht Stellen Sie innerhalb des voreingestellten Zeitlimits für Verbindungen eine Verbindung zum Backend-Server her. 
      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 disapprovedd gibt an, dass die Verbindung wurde vom Backend-Server abgelehnt. 
      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, ob Sie von jedem der beiden Message Processor mit dem Befehl telnet: <ph type="x-smartling-placeholder">
      </ph>
    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 Backend-Server mehrere IP-Adressen auflöst, verwenden Sie den Hostnamen den Back-End-Server im Befehl telnet, wie unten gezeigt: 
      telnet BackendServer-HostName 443
  4. Wenn Sie eine Verbindung zum Backend-Server herstellen können, wird möglicherweise eine Meldung wie Connected to backend-server angezeigt. Wenn du keine Verbindung zum Backend-Server herstellen kannst, könnte dies an da die Message Processors IP-Adressen sind im jeweiligen Backend nicht auf der Zulassungsliste Server.

Auflösung

Gewähren Sie Zugriff auf die IP-Adressen des Message Processor auf dem jeweiligen Backend-Server, um dies zuzulassen. von den Edge Message Processors, um auf Ihren Back-End-Server zuzugreifen. Unter Linux könnten Sie beispielsweise iptables, um den Traffic von den IP-Adressen des Message Processor zuzulassen auf dem Back-End-Server.

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

Falscher Zielserver-Hostname

Diagnose

Wenn der im Zielserver angegebene Hostname falsch ist, können Sie die Antwort 503 Service Unavailable mit dem Fehlercode erhalten. messaging.adaptors.http.flow.ServiceUnavailable.

Trace-Tool

So führen Sie eine Diagnose mit dem Trace-Tool durch:

  1. Wenn das Problem weiterhin besteht, aktivieren Sie die Trace-Sitzung für die betroffene API.
  2. Führen Sie den API-Aufruf aus und reproduzieren Sie das Problem – 503 Dienst nicht verfügbar mit Fehlercode messaging.adaptors.http.flow.ServiceUnavailable.
  3. Wählen Sie eine der fehlgeschlagenen Anfragen aus.
  4. Durchlaufen Sie die verschiedenen Phasen des Trace und finden Sie heraus, wo der Fehler aufgetreten ist.
  5. Wählen Sie die FlowInfo mit dem Fehler aus. Im Feld error.cause finden Sie möglicherweise weitere Informationen zur Fehlerursache, wie im folgenden Beispiel gezeigt:

    Beispielanfrage mit „error.cause“ im Trace

    Beispielanfrage mit „error.cause“ im Trace
  6. Wenn Sie feststellen, dass für error.cause Host nicht erreichbar angezeigt wird, ist das wahrscheinlich eine der folgenden Ursachen: <ph type="x-smartling-placeholder">
      </ph>
    • Der in der Konfiguration des Zielservers/Zielendpunkts angegebene Hostname ist falsch oder enthält unerwünschte Leerzeichen oder Sonderzeichen.

      Beispiel: Der Hostname enthält ein unerwünschtes Leerzeichen:
      "demo-target.apigee.net "
    • Der Hostname, der im API-Proxy mit AssignMessage von der Variablen target.url oder Die JavaScript-Richtlinie ist falsch oder enthält ein Leerzeichen oder andere unerwünschte Sonderzeichen.
  7. Prüfen Sie die Konfiguration des Zielendpunkts und/oder die Zielserverdefinition, um zu sehen, ob der Hostname des Zielservers falsch ist oder unerwünschte Leerzeichen oder Sonderzeichen enthält.
  8. Wenn der Zielserverhost dynamisch erstellt wird, aktivieren Sie die entsprechende Richtlinie (z. B. die Richtlinie AssignMessage/JavaScript), mit der er erstellt wurde. Aktivieren Sie Prüfen Sie, ob der Hostname des Zielservers falsch ist oder unerwünschte Leerzeichen oder Sonderzeichen enthalten.
  9. Nachdem Sie den Hostnamen des Zielservers ermittelt haben, führen Sie den Befehl nslookup/dig für den Hostnamen aus, um zu sehen, ob er aufgelöst werden kann.

    Wenn Sie beispielsweise den Befehl nslookup für den Hostnamen mit einem unerwünschten Leerzeichen ausführen, wird die folgende Ausgabe zurückgegeben:

    nslookup "demo-target.apigee.net "
Server:	49.205.75.2
Address:	49.205.75.2#53

** server can't find demo-target.apigee.net\032: NXDOMAIN
  10. Wenn der Betriebssystembefehl nslookup auch den Hostnamen nicht auflösen kann, wird das Problem durch den falschen Hostnamen verursacht, der für den Zielserver verwendet wurde.

    Gehe zu Lösung.

Nachrichtenprozessorlogs

So führen Sie eine Diagnose mithilfe von Message Processor-Logs durch:

  1. Ermitteln Sie die Nachrichten-ID der fehlgeschlagenen Anfrage.
  2. Suchen Sie im Message Processor-Protokoll nach der Nachrichten-ID. (/opt/apigee/var/log/edge-message-processor/logs/system.log)
  3. Wenn die folgenden Warn-/Fehlermeldungen angezeigt werden, konnte der Message Processor den Hostnamen nicht auflösen. Die Nachricht wird zurückgestellt. Daher sehen Sie diese Option möglicherweise nicht. Warnmeldung für alle Nachrichten-IDs/Anfragen. 
    org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 WARN S.HTTPCLIENTSERVICE - DNSCache$2.failed() : Failed to resolve hostname www.somehost.com . Reason mocktarget.apigee.net : Name or service not known. This log message will snooze for 2 hours
  4. Es folgt eine Warnmeldung, dass der Message Processor die Adresse aus dem DNS-Cache entfernt, da der Zielserverhost nicht erreicht werden konnte. 
    org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid> NIOThread@0 WARN  c.a.p.h.d.DNSCachedAddress - DNSCachedAddress.addressNotReachable() : The last address has been removed from Address list null refreshing
  5. Möglicherweise sehen Sie dann eine Meldung, dass der Message Processor mit der Ausnahme „Host nicht erreichbar“ fehlschlägt. Manchmal wird der Hostname als Teil der Fehlermeldung angezeigt: 
    org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() :  connect to demo-target.apigee.net  failed with exception {}
java.lang.RuntimeException: Host not reachable
	at com.apigee.protocol.http.HTTPClient$Context.initConnect(HTTPClient.java:704)
	at com.apigee.protocol.http.HTTPClient$Context.send(HTTPClient.java:675)
	at com.apigee.messaging.adaptors.http.flow.data.TargetRequestSender.sendRequest(TargetRequestSender.java:234)
	…<snipped>
  6. Manchmal wird sie als null angezeigt, da der Hostname nicht aufgelöst oder nicht erreichbar ist (siehe unten): 
    org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() :  connect to null failed with exception {}
java.lang.RuntimeException: Host not reachable
	at com.apigee.protocol.http.HTTPClient$Context.initConnect(HTTPClient.java:704)
	at com.apigee.protocol.http.HTTPClient$Context.send(HTTPClient.java:675)
	at com.apigee.messaging.adaptors.http.flow.data.TargetRequestSender.sendRequest(TargetRequestSender.java:234)
	…<snipped>
  7. Der Host not reachable-Fehler tritt normalerweise in einem der folgenden Fälle auf: <ph type="x-smartling-placeholder">
      </ph>
    • Der in der Konfiguration des Zielservers/Zielendpunkts angegebene Hostname ist falsch oder enthält unerwünschte Leerzeichen oder Sonderzeichen.

      Es gibt beispielsweise ein unerwünschtes Leerzeichen im Hostnamen „demo-target.apigee.net “ in der folgenden Fehlermeldung: 
      NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() :  connect to demo-target.apigee.net  failed with exception
    • Der Hostname, der von der Variablen target.url im API-Proxy mit der Richtlinie AssignMessage oder JavaScript überschrieben wird, ist falsch oder enthält ein Leerzeichen oder andere unerwünschte Sonderzeichen.
  8. Bestimmen Sie den Hostnamen des Zielservers, mit dem der Message Processor zu kommunizieren versucht, indem Sie einen der folgenden Befehle verwenden:
    1. Sieh dir die Fehlermeldung mit Host not reachable sorgfältig an.
    2. Wenn der Hostname in der Fehlermeldung angezeigt wird, kopieren Sie den Hostnamen einschließlich Leerzeichen und Sonderzeichen.
    3. Wenn die Fehlermeldung null für den Hostnamen anzeigt, wie in der folgenden Fehlermeldung dargestellt, 
      org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() :  connect to null failed with exception {}
      1. Bestimmen Sie den Hostnamen, indem Sie die Zielserverdefinition überprüfen, die im fehlgeschlagenen API-Proxy verwendet wird.
      2. Wenn der Zielserverhost dynamisch erstellt wird, aktivieren Sie die entsprechende Richtlinie (z. B. AssignMessage/JavaScript-Richtlinie), die zum Erstellen des Zielservers verwendet wurde.
  9. Nachdem Sie den Hostnamen des Zielservers ermittelt haben, führen Sie den Befehl nslookup/dig für den Hostnamen aus und prüfen Sie, ob er aufgelöst werden kann.

    Führen Sie beispielsweise den Befehl nslookup auf den Hostnamen aus, der ein Leerzeichen enthält.

    nslookup "demo-target.apigee.net "
Server:	49.205.75.2
Address:	49.205.75.2#53

** server can't find demo-target.apigee.net\032: NXDOMAIN
  10. Wenn auch der Betriebssystembefehl nslookup den Hostnamen nicht auflösen kann, wird das Problem durch den falschen Hostnamen verursacht, der für den Zielserver verwendet wurde.

Auflösung

  1. Prüfen Sie, ob der Hostname des Zielservers in der Zielendpunktkonfiguration oder im Zielserver angegeben ist ist korrekt und enthält keine unerwünschten Leerzeichen oder Sonderzeichen.
  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 stellen Sie sicher, dass der Hostname des Zielservers korrekt generiert wird.

SSL-Handshake-Fehler

Ein ganzes Playbook zur Fehlerbehebung befasst sich mit TLS/SSL-Handshake-Fehlern. Siehe SSL-Handshake-Fehler.

Ursache des Problems ermitteln

Bestimmte Fehlertypen können entweder auf der eingehenden (Richtung in nördlicher Richtung) oder auf der ausgehenden (Richtung Süden) auftreten. Zwischen der Clientanwendung und Edge tritt ein eingehender Fehler (in Nordausrichtung) auf. Eine Postausgangsfehler (Richtung Süden) zwischen Edge und dem Back-End-Zielserver auftritt. Zur Diagnose dieser müssen Sie zuerst herausfinden, ob der Fehler an der Nord- oder Richtung Süden.

Verbindungen in nördliche und südliche Richtung verstehen

In Edge kann für die eingehende oder die ausgehende Verbindung der Fehler 503 Dienst nicht verfügbar sein:

  • Eingehende (oder nach Norden) verbundene Verbindung: die Verbindung zwischen dem Client und den Edge Router. Der Router ist die Komponente von Apigee Edge, eingehende Anfragen an das System.
  • Ausgehende Verbindung (oder in Richtung Süden): die Verbindung zwischen dem Edge Message Processor und der Backend-Server. Der Message Processor ist eine Komponente von Apigee Edge das API-Anfragen an Back-End-Zielserver weiterleitet.

Wenn Sie Edge Public Cloud-Nutzer sind, sind Sie wahrscheinlich nicht mit internen Komponenten wie dem Router oder dem Message Processor. Diese internen Komponenten sind für Public Cloud-Nutzer Wenn möglich bieten wir alternative Möglichkeiten zur Untersuchung des Problems an, benötigen keinen direkten Zugriff auf diese Komponenten.

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

Fluss der Clientanwendung (Verbindung nach Norden) über Edge zum Backend-Server (Verbindung nach Süden)

Ermitteln, wo der Fehler 503 Dienst nicht verfügbar ist

Verwenden Sie eines der folgenden Verfahren, um festzustellen, ob der Fehler 503 Dienst nicht verfügbar ist. Verbindung in nördlicher oder südlicher Richtung.

UI-Trace

So ermitteln Sie mithilfe von UI Trace, wo der Fehler aufgetreten ist:

  1. Wenn das Problem weiterhin besteht, aktivieren Sie das UI-Trace für die betroffene API.
  2. Wenn im UI-Trace für die fehlgeschlagene API-Anfrage der Fehler „503 Service Nicht verfügbar“ angezeigt wird während des Ziel-Anfrageflusses auftritt oder vom Back-End-Server gesendet wird, ist das Problem southbound (zwischen dem Message Processor und dem Back-End) Server).
  3. Wenn Sie den Trace für den spezifischen API-Aufruf nicht erhalten, ist das Problem northbound: zwischen der Clientanwendung und dem Router.

API-Monitoring

Mit der API-Überwachung können Sie Problembereiche schnell isolieren, um Fehler-, Leistungs- und Latenzprobleme sowie deren Ursache zu diagnostizieren. wie z. B. Entwickler-Apps, API-Proxys, Back-End-Ziele oder die API-Plattform.

Schritt durch ein Beispielszenario, das zeigt, wie Sie 5xx-Probleme mit Ihren APIs mithilfe von API-Monitoring beheben. Beispielsweise können Sie eine Warnung einrichten, die informiert wird, wenn die Anzahl der messaging.adaptors.http.flow.ServiceUnavailable-Fehler einen bestimmten Schwellenwert überschreitet.

NGINX-Zugriffslogs

So ermitteln Sie mithilfe von UI Trace, wo der Fehler aufgetreten ist:

Wenn das Problem in der Vergangenheit aufgetreten ist oder zeitweise auftritt und Sie Erfassen Sie den Trace und führen Sie dann die folgenden Schritte aus:

  1. Prüfen Sie die NGINX-Zugriffslogs (/opt/apigee/var/log/edge-router/nginx/ org-env.port_access_log).
  2. Suchen Sie nach 503-Fehlern für einen bestimmten API-Proxy.
  3. Wenn Sie zu einem bestimmten Zeitpunkt einen 503-Fehler für die spezifische API ermitteln können, Bei der Verbindung southbound (zwischen dem Message Processor und Back-End-Server).
  4. Ist dies nicht der Fall, trat das Problem an der Verbindung in Richtung Norden auf (zwischen dem Clientanwendung und Router).