Fehler „503-Dienst nicht verfügbar“ mit TARGET_CONNECT_TIMEOUT (Internet- und VPC-Peering-Ziele)

Sie lesen gerade die Dokumentation zu Apigee und Apigee Hybrid.
Für dieses Thema gibt es keine entsprechende Apigee Edge-Dokumentation.

Symptom

Dieses Problem wird in API-Monitoring, Debugging oder anderen Tools als Fehler vom Typ „503 – Dienst nicht verfügbar“ angezeigt. Der Grund „TARGET_CONNECT_TIMEOUT“ gibt ein Verbindungstimeout zwischen der Apigee-Instanz und dem Internetziel oder einem Ziel an, das über VPC-Peering erreichbar ist.

Dieser Fehler sollte nicht mit anderen Zeitüberschreitungsfehlern wie 504 Gateway Timeout verwechselt werden.

Fehlermeldung

Dies ist der typische Fehler in der Debug-Sitzung oder in der Antwortnutzlast. Bitte beachten Sie den Grund: TARGET_CONNECT_TIMEOUT.

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

Mögliche Ursachen

Diese Ursachen sind spezifisch für Internetziele oder Ziele, die über VPC-Peering erreichbar sind. Weitere Informationen finden Sie unter Apigee-Netzwerkoptionen. Wenn das Ziel PSC (Endpunktanhang) ist, lesen Sie stattdessen das PSC-Playbook.

Ursache Beschreibung
Fehlerhafte Konfiguration von Routen Zielrouten werden nicht in das Peering mit der Apigee-Instanz exportiert.
Verbindungsproblem am Ziel Das Ziel kann nicht immer eine TCP-Verbindung akzeptieren.
IP-Zulassungsliste am Ziel mit einigen oder allen Apigee-NAT-IPs, die nicht hinzugefügt wurden Nicht alle Apigee-NAT-IPs stehen am Ziel auf der Zulassungsliste.
Erschöpfung des NAT-IP-Ports Nicht genügend NAT-Ports für den Traffic vorhanden.
connect.timeout.millis-Wert zu niedrig Die Einstellung für das Zeitlimit für die Verbindung ist auf Apigee-Seite zu niedrig.

Allgemeine Diagnoseschritte

Debug ist ein wichtiges Tool, um die folgenden Details zum Problem zu erfassen und auszuwerten:

  • Die Gesamtdauer der Anfrage. Normalerweise dauert es drei Sekunden (Standardwert connect.timeout.millis), bis eine Zeitüberschreitung der Verbindung auftritt. Wenn die Dauer kürzer ist, prüfen Sie die Konfiguration des Zielendpunkts.
  • Ziel-Hostname und IP-Adresse Die falsche IP-Adresse kann auf ein DNS-Problem hinweisen. Möglicherweise gibt es auch einen Zusammenhang zwischen verschiedenen Ziel-IP-Adressen und dem Problem.
  • Häufigkeit. Je nachdem, ob das Problem sporadisch oder dauerhaft auftritt, sind unterschiedliche Ansätze erforderlich.

Ursache: Fehlkonfiguration der Route

Diagnose

Wenn das Problem dauerhaft besteht, kann es durch eine fehlerhafte Konfiguration der Route verursacht werden, auch wenn es kürzlich begonnen hat.

Dies kann sowohl interne (weitergeleitet innerhalb Peering-VPC) als auch externe (Internet-)Ziele betreffen.

  1. Ermitteln Sie zuerst die IP-Adresse des Ziels, die von der Apigee-Instanz aufgelöst wurde. Eine Möglichkeit ist die Verwendung einer Debug-Sitzung. Rufen Sie unter Debug auf AnalyticsPublisher (oder AX im klassischen Debugging) auf:

    Fehlerbehebungsfenster

    Suchen Sie rechts auf dem Bildschirm nach dem Wert target.ip.

    In diesem Beispiel lautet die IP-Adresse 10.2.0.1. Da dieser Bereich privat ist, müssen bestimmte Routingmaßnahmen ergriffen werden, damit Apigee das Ziel erreichen kann.

    Wenn sich das Ziel im Internet befindet, müssen Sie diesen Schritt ausführen, wenn VPC Service Controls für Apigee aktiviert sind, da dies die Internetverbindung verhindert.

  2. Notieren Sie sich die Region, in der die betroffene Apigee-Instanz bereitgestellt wird. Klicken Sie in der Apigee-UI in der Cloud Console auf Instanzen. Im Feld Standort sehen Sie die genaue Region der Instanz.

    Apigee Console-Instanzen
  3. Rufen Sie im Projekt, das mit Apigee gepeert ist, in der Benutzeroberfläche den Bereich VPC-Netzwerk -> VPC-Netzwerk-Peering auf. Wenn Sie eine freigegebene VPC verwenden, müssen diese Schritte im Hostprojekt und nicht im Apigee-Projekt ausgeführt werden.

    VPC-Netzwerk-Peering
  4. Klicken Sie auf servicenetworking-googleapis-com, wählen Sie den Tab EXPORTIERTE ROUTEN aus und filtern Sie nach der Region aus Schritt 2.

    In diesem Beispiel wird die exportierte Route 10.2.0.0/24 mit der Beispielziel-IP 10.2.0.1 angezeigt. Wenn Sie keine Route sehen, die Ihrem Ziel entspricht, liegt hier das Problem.

    Details zur Peering-Verbindung

Lösung

Prüfen Sie Ihre Netzwerkarchitektur und achten Sie darauf, dass Routen in das VPC-Peering mit Apigee exportiert werden. Höchstwahrscheinlich ist die fehlende Route entweder statisch oder dynamisch. Fehlende erforderliche dynamische Routen weisen auf ein Problem mit der entsprechenden Funktion hin, z. B. mit Cloud Interconnect.

Transitives Peering wird nicht unterstützt. Wenn also das VPC-Netzwerk N1 mit N2 und N3 verbunden ist, aber N2 und N3 nicht direkt miteinander verbunden sind, kann das VPC-Netzwerk N2 nicht per VPC-Netzwerk-Peering mit dem VPC-Netzwerk N3 kommunizieren.

Weitere Informationen finden Sie unter Southbound-Netzwerkmuster.

Ursache: Konnektivitätsproblem am Ziel

Diagnose

Das Ziel ist möglicherweise nicht über das VPC erreichbar oder kann keine Verbindung akzeptieren. Es gibt zwei Möglichkeiten, das Problem zu diagnostizieren.

Konnektivitätstest (private Ziel-IP-Adressen)

Wenn sich das Ziel in einem privaten Netzwerk befindet, können Sie mit der Funktion Konnektivitätstest häufige Ursachen diagnostizieren.

  1. Ermitteln Sie die IP-Adresse des Ziels, die von der Apigee-Instanz aufgelöst wurde. Eine Möglichkeit ist die Verwendung einer Debug-Sitzung.

    Rufen Sie unter "Debugging" AnalyticsPublisher (oder AX im klassischen Debugging) auf. Suchen Sie rechts auf dem Bildschirm nach dem Wert target.ip.

    In diesem Beispiel lautet die IP-Adresse 10.2.0.1. Dies ist eine private IP-Adresse. Wir können also den Konnektivitätstest verwenden.

    AnalyticsPublisher
  2. Notieren Sie sich die IP-Adresse der Apigee-Instanz, die keine Verbindung zum Ziel herstellen kann. Suchen Sie in der Apigee Console unter Instanzen im Feld IP-Adresse nach der IP-Adresse der Apigee-Instanz.

    Instanzen mit IP-Adresse
  3. Gehen Sie zu Konnektivitätstests und klicken Sie auf Konnektivitätstest erstellen. Geben Sie die folgenden Informationen an:
    1. Quell-IP-Adresse:Verwenden Sie die IP-Adresse der Apigee-Instanz, die Sie in Schritt 2 oben erhalten haben. Hinweis: Dies ist nicht die genaue Quell-IP-Adresse, die von Apigee zum Senden einer Anfrage an das Ziel verwendet wird. Sie reicht jedoch für den Test aus, da sie sich im selben Subnetz befindet.
    2. Dies ist eine IP-Adresse, die in Google Cloud verwendet wird:Lassen Sie das Kästchen leer, es sei denn, die Adresse befindet sich in einem Ihrer Google Cloud-Projekte. Wenn du diesen Wert auswählst, gib auch das Projekt und das Netzwerk an.
    3. Geben Sie die Zieladresse (Schritt 1) und den Port als Ziel-IP-Adresse bzw. Zielport ein.
    Konnektivitätstest erstellen
  4. Klicken Sie auf Erstellen und warten Sie, bis der Test abgeschlossen ist.
  5. Klicken Sie in der Liste der Konnektivitätstests auf Anzeigen, um die Ergebnisse der Ausführung aufzurufen.
  6. Wenn das Ergebnis „Unerreichbar“ lautet, liegt ein Problem mit der Konfiguration vor. Das Tool sollte Sie zur Dokumentation zu den Zuständen von Konnektivitätstests weiterleiten. Wenn der Status „Erreichbar“ lautet, sind viele Konfigurationsprobleme ausgeschlossen. Dies ist jedoch keine Garantie dafür, dass das Ziel erreichbar ist. Es wurde kein Versuch unternommen, eine TCP-Verbindung zum Ziel herzustellen. Das lässt sich nur mit der nächsten Diagnose unten testen.

    Ergebnisse des Konnektivitätstests


VM-Konnektivitätstest (alle Ziele)

  1. Erstellen Sie in derselben VPC, die mit Apigee per Peering verbunden ist, eine VM-Instanz unter Linux.
  2. Führen Sie Konnektivitätstests von der VM aus aus, vorzugsweise zu dem Zeitpunkt, zu dem das Problem von Apigee aus reproduzierbar ist. Sie können Telnet, Curl und andere Dienstprogramme verwenden, um eine Verbindung herzustellen. Dieses Curl-Beispiel wird in einer Schleife mit einer Zeitüberschreitung von drei Sekunden ausgeführt. Wenn curl innerhalb von drei Sekunden keine TCP-Verbindung herstellen kann, schlägt der Vorgang fehl. 
    for i in {1..100}; do curl -m 3 -v -i https://[TARGET_HOSTNAME] ; sleep 0.5 ; done
  3. Prüfen Sie die vollständige Ausgabe und suchen Sie nach diesem Fehler: 
    * Closing connection 0
 curl: (28) Connection timed out after 3005 milliseconds

    Wenn dieser Fehler auftritt, lässt sich das Problem auch außerhalb von Apigee reproduzieren.

    Wenn andere Fehler auftreten, z. B. TLS-bezogene Fehler oder fehlerhafte Statuscodes, dass sie die Zeitüberschreitung der Verbindung nicht bestätigen und in keinem Zusammenhang mit diesem Problem stehen.

  4. Wenn für das Ziel eine IP-Zulassungsliste erforderlich ist, können Sie es möglicherweise nicht von einer VM aus testen, es sei denn, Sie lassen auch die IP-Adresse der VM-Instanz zu.

Lösung

Wenn Sie anhand der Konnektivitätstests ein Problem festgestellt haben, fahren Sie mit den dokumentierten Schritten zur Fehlerbehebung fort.

Wenn die Zeitüberschreitung von einer VM reproduziert wird, gibt es keine klare Anleitung zur Behebung des Problems auf der Zielseite. Sobald die Zeitüberschreitung bei der Verbindung außerhalb von Apigee reproduzierbar ist, untersuchen Sie das Problem weiter in der VPC. Versuchen Sie, die Verbindung so nah wie möglich am Ziel zu testen.

Wenn sich das Ziel hinter einer VPN-Verbindung befindet, können Sie es möglicherweise auch über das lokale Netzwerk testen.

Wenn sich das Ziel im Internet befindet, können Sie versuchen, das Problem außerhalb der Google Cloud Console zu reproduzieren.

Tritt das Problem zu Stoßzeiten auf, ist das Ziel möglicherweise von zu vielen Verbindungen überlastet.

Wenn Sie in dieser Phase einen Google Cloud-Supportfall erstellen müssen, müssen Sie die Apigee-Komponente nicht mehr auswählen, da das Problem jetzt direkt über die VPC reproduziert werden kann.

Ursache: IP-Zulassungsliste am Ziel mit einigen oder allen Apigee-NAT-IPs, die nicht hinzugefügt wurden

Diagnose

Dies betrifft externe Ziele (das Internet), für die die IP-Zulassungsliste aktiviert ist. Prüfen Sie, ob alle Apigee-NAT-IPs auf der betroffenen Zielseite hinzugefügt wurden. Wenn am Ziel keine Zulassungsliste vorhanden ist, können Sie diesen Abschnitt überspringen.

Das Problem ist leichter zu erkennen, wenn die Fehler sporadisch auftreten, da Sie in diesem Fall möglicherweise einen Zusammenhang zwischen bestimmten NAT-IPs und den Fehlern finden.

Wenn das Problem weiterhin besteht (alle Aufrufe schlagen fehl), prüfen Sie, ob NAT-IP-Adressen in Apigee aktiviert sind, und rufen Sie sie mit den folgenden Schritten ab:

Listen Sie die NAT-IP-Adressen für eine Instanz auf:

curl -H "Authorization: Bearer $TOKEN" \
"https://apigee.googleapis.com/v1/organizations/$ORG_ID/instances/$INSTANCE_NAME/natAddresses"
 Beispiel für eine Antwort:
{
  "natAddresses": [
    {
      "name": "nat-1",
      "ipAddress": "35.203.160.18",
      "state": "ACTIVE"
    },
    {
      "name": "nat-2",
      "ipAddress": "35.230.14.174",
      "state": "RESERVED"
    }
  ]
}
 Wenn Sie in der Ausgabe keine Adressen erhalten, dann werden NAT-IP-Adressen auf Apigee-Seite nicht hinzugefügt. Wenn Sie Adressen erhalten, aber keine davon AKTIV ist, können Sie über keine der verwendeten Adressen auf das Internet zugreifen. Das ist ebenfalls ein Problem.

Wenn Sie mindestens eine AKTIVE Adresse haben, kann sie auf der Zielseite auf die Zulassungsliste gesetzt werden. Es liegt also keine Fehlkonfiguration auf Apigee-Seite vor. In diesem Fall fehlt die Adresse möglicherweise auf der Zulassungsliste am Ziel.

Wenn das Problem sporadisch auftritt, kann das darauf hindeuten, dass nur ein Teil der NAT-IP-Adressen auf der Zulassungsliste des Ziels steht. So können Sie das herausfinden:

  1. Erstellen Sie einen neuen Reverse-Proxy, in dem das betroffene Ziel im Zielendpunkt angegeben ist. Sie können auch den vorhandenen Proxy wiederverwenden und mit dem nächsten Schritt fortfahren:

    Reverse-Proxy erstellen
  2. Fügen Sie dem Anfrage-PreFlow eine ServiceCallout-Richtlinie hinzu. Der ServiceCallout sollte „https://icanhazip.com“, „https://mocktarget.apigee.net/ip“ oder einen anderen öffentlichen Endpunkt aufrufen, der die IP-Adresse des Anrufers in der Antwort zurückgibt. Speichern Sie die Antwort in der Variablen „response“, damit der Inhalt im Debug-Tool sichtbar ist. Dies ist eine Beispielkonfiguration für eine ServiceCallout-Richtlinie:
    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ServiceCallout continueOnError="false" enabled="true" name="Service-Callout-1">
    <DisplayName>Service Callout-1</DisplayName>
    <Properties/>
    <Request clearPayload="true" variable="myRequest">
        <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    </Request>
    <Response>response</Response>
    <HTTPTargetConnection>
        <Properties/>
        <URL>https://icanhazip.com</URL>
    </HTTPTargetConnection>
</ServiceCallout>

    Sie können die Antwort auch in einer benutzerdefinierten Variablen speichern. Sie müssen dann aber den Inhalt „.content“ dieser Variablen mit der AssignMessage-Richtlinie lesen, um sie im Debugging-Tool zu sehen.

    Das Ziel muss genau so konfiguriert sein wie im betroffenen Proxy.

  3. Führen Sie eine Debug-Sitzung aus und klicken Sie auf den Schritt „ServiceCallout“:

    Mit ServiceCallout debuggen
  4. Rechts unten sollte der Bereich Response content (Antwortinhalt) mit der NAT-IP-Adresse (im Body) der Apigee-Instanz angezeigt werden, die die Anfrage stellt. Wenn Sie die Antwort für den ServiceCallout an einem anderen Ort speichern, sollte sie dort angezeigt werden.

    Beachten Sie, dass der Proxy später im Ablauf das Ziel aufruft und der Antwortinhalt mit dem Fehler oder einer Antwort vom Ziel überschrieben wird.
  5. Versuchen Sie, die NAT-IPs mit dem Problem in Verbindung zu bringen. Wenn nur bestimmte IP-Adressen fehlschlagen, ist das ein Zeichen dafür, dass einige, aber nicht alle IP-Adressen auf der Zulassungsliste des Ziels stehen.
  6. Wenn Sie keine Korrelation zwischen NAT-IP-Adressen und den Fehlern feststellen, z. B. wenn dieselbe IP-Adresse bei einer Anfrage fehlschlägt, bei der anderen jedoch nicht, handelt es sich höchstwahrscheinlich nicht um ein Problem mit der Zulassungsliste. Möglicherweise ist die NAT erschöpft. Weitere Informationen finden Sie unter Ursache: Erschöpfung des NAT-IP-Ports.

Lösung

NAT-IP-Adressen müssen bereitgestellt und aktiviert sein und alle müssen auf der Zielseite hinzugefügt werden.

Ursache: Erschöpfung des NAT-IP-Ports

Diagnose

Wenn das Problem nur von Apigee aus reproduzierbar ist und NAT-IP-Adressen für Ihr Unternehmen bereitgestellt werden und Sie sehen, dass es bei verschiedenen Zielen gleichzeitig auftritt, gehen Ihnen möglicherweise die NAT-Quellports aus:

  1. Notieren Sie sich den Zeitraum, in dem das Problem auftritt. Beispiel: täglich zwischen 17:58 und 18:08 Uhr.
  2. Prüfen Sie, ob im selben Zeitraum andere Ziele von dem Problem betroffen sind. Auf dieses andere Ziel muss über das Internet zugegriffen werden können und es darf nicht am selben Ort gehostet werden wie das ursprünglich betroffene Ziel.
  3. Prüfen Sie, ob Fehler nur bei einem bestimmten Traffic-Volumen in TPS auftreten. Notieren Sie sich dazu den Zeitraum des Problems und rufen Sie das Dashboard Proxy-Leistung auf.
  4. Versuchen Sie, das Fehlerzeitfenster mit dem Anstieg der durchschnittlichen Transaktionen pro Sekunde (tps) in Verbindung zu bringen.
API-Messwerte

In diesem Beispiel steigt die Anzahl der Transaktionen pro Sekunde um 17:58 Uhr auf 1.000 an. Angenommen, in diesem Beispiel tritt das Problem genau um 17:58 Uhr auf und betrifft zwei oder mehr nicht miteinander in Verbindung stehende Ziele, dann ist dies ein Hinweis auf ein Problem mit der NAT-Erschöpfung.

Lösung

Berechnen Sie die Anforderungen an NAT-IP-Adressen noch einmal. Folgen Sie dazu der Anleitung unter Anforderungen für statische NAT-IP-Adressen berechnen.

Sie können auch weitere NAT-IP-Adressen hinzufügen, um zu sehen, ob das Problem dadurch behoben wird. Hinweis: Wenn Sie weitere IP-Adressen hinzufügen, müssen Sie sie möglicherweise zuerst bei allen Zielen auf die Zulassungsliste setzen.

Ursache: connect.timeout.millis-Wert zu niedrig

Diagnose

Möglicherweise ist der Zeitlimitwert im Proxy falsch konfiguriert.

Rufen Sie dazu den betroffenen Proxy auf und prüfen Sie den entsprechenden TargetEndpoint. Notieren Sie sich die Property „connect.timeout.millis“ und ihren Wert. In diesem Beispiel beträgt der Wert 50, also 50 Millisekunden, was in der Regel zu niedrig ist, um eine TCP-Verbindung herzustellen. Wenn der Wert unter 1.000 liegt, ist das wahrscheinlich die Ursache des Problems. Wenn die Property „connect.timeout.millis“ nicht angezeigt wird, ist der Standardwert festgelegt und die Ursache kann nicht bestätigt werden.

Proxy mit Zeitüberschreitung

Lösung

Korrigieren Sie den Wert „connect.timeout.millis“. Die Zeiteinheiten müssen in Millisekunden angegeben werden. Der Standardwert ist 3000, also 3.000 Millisekunden. Weitere Informationen finden Sie in der Referenz zu Endpunktattributen.

Wenden Sie sich an den Support, um weitere Unterstützung zu erhalten.

Wenn das Problem nach Befolgen der obigen Anweisungen weiterhin besteht, erfassen Sie bitte die folgenden Diagnoseinformationen für den Google Cloud-Support:

  1. Projekt-ID und Name der Apigee-Organisation
  2. Proxyname(n) und die Umgebung.
  3. Zeitraum des Problems.
  4. Häufigkeit des Problems
  5. Ziel-Hostname
  6. Fehlerbehebungssitzung mit dem Problem.
  7. Ergebnis der Prüfungen, die für die oben genannten möglichen Ursachen durchgeführt wurden. Beispiel: Ausgabe des Befehls curl in einer VM