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“ weist auf ein Zeitlimit für die Verbindung zwischen der Apigee-Instanz und dem Internetziel oder einem Ziel hin, das über VPC-Peering erreichbar ist.

Der Fehler sollte nicht mit anderen Zeitüberschreitungsfehlern wie „504 Gateway Timeout“ verwechselt werden.

Fehlermeldung

Dies ist der typische Fehler in der Debugging-Sitzung oder der Antwortnutzlast. 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 beziehen sich nur auf Internetziele oder Ziele, die über VPC-Peering erreichbar sind. Siehe Apigee-Netzwerkoptionen. Wenn das Ziel PSC (Endpoint Attachment) 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 annehmen.
IP-Zulassungsliste am Ziel mit einigen oder allen Apigee-NAT-IPs, die nicht hinzugefügt wurden Nicht alle Apigee-NAT-IPs stehen auf der Zulassungsliste am Ziel.
Erschöpfung des NAT-IP-Ports Es sind nicht genügend NAT-Ports für den Traffic vorhanden.
connect.timeout.millis-Wert zu niedrig Das Zeitlimit für Verbindungen ist auf Apigee-Seite zu niedrig.

Allgemeine Diagnoseschritte

Debug ist ein wichtiges Tool, mit dem Sie die folgenden Details zum Problem erfassen und auswerten können:

  • Die Gesamtdauer der Anfrage. Normalerweise dauert es drei Sekunden (Standardwert für connect.timeout.millis), bis eine Zeitüberschreitung der Verbindung auftritt. Wenn Sie eine kürzere Dauer feststellen, prüfen Sie die Konfiguration des Zielendpunkts.
  • Ziel-Hostname und IP-Adresse. Wenn die falsche IP-Adresse angezeigt wird, kann das auf ein DNS-Problem hinweisen. Möglicherweise stellen Sie auch eine Korrelation zwischen verschiedenen Ziel-IP-Adressen und dem Problem fest.
  • Häufigkeit. Je nachdem, ob das Problem unregelmäßig 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 der Methoden ist die Verwendung einer Debug-Sitzung. Rufen Sie unter Debug auf AnalyticsPublisher (oder AX im klassischen Debugging) auf:

    Fehlerbehebungsfenster

    Suchen Sie auf der rechten Seite des Bildschirms nach dem Wert target.ip.

    In diesem Beispiel lautet die IP-Adresse 10.2.0.1. Da dieser Bereich privat ist, sind bestimmte Routingmaßnahmen erforderlich, 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-Konsoleninstanzen
  3. Rufen Sie im Projekt, das mit Apigee verbunden 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 anstelle des Apigee-Projekts 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 Route 10.2.0.0/24 als exportiert angezeigt. Sie enthält die Beispiel-Ziel-IP 10.2.0.1. 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 sorgen Sie dafür, dass Routen in das VPC-Peering mit Apigee exportiert werden. Höchstwahrscheinlich ist die fehlende Route entweder statisch oder dynamisch. Das Fehlen der erforderlichen dynamischen Routen deutet auf ein Problem mit dem entsprechenden Feature hin, z. B. 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 die VPC erreichbar oder kann keine Verbindung akzeptieren. Es gibt zwei Optionen zur Diagnose des Problems.

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

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

    Rufen Sie unter "Debugging" AnalyticsPublisher (oder AX im klassischen Debugging) auf. Suchen Sie auf der rechten Seite des Bildschirms nach dem Wert target.ip.

    In diesem Beispiel lautet die IP-Adresse 10.2.0.1. Dies ist eine private IP-Adresse, daher können wir 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. Rufen Sie Konnektivitätstests auf und klicken Sie auf Konnektivitätstest erstellen. Geben Sie die folgenden Informationen an:
    1. Quell-IP-Adresse:Verwenden Sie die Apigee-Instanz-IP, die Sie oben in Schritt 2 abgerufen haben. Hinweis: Dies ist nicht die genaue Quell-IP, 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 deaktiviert, sofern die Adresse nicht in einem Ihrer Google Cloud-Projekte enthalten ist. Wenn Sie diesen Wert prüfen, geben Sie 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 zum ersten Mal ausgeführt wurde.
  5. Klicken Sie in der Liste der Konnektivitätstests auf Ansehen, um die Ergebnisse der Ausführung aufzurufen.
  6. Wenn das Ergebnis „Nicht erreichbar“ lautet, liegt ein Problem mit der Konfiguration vor. Das Tool sollte Sie zur Dokumentation zu den Status von Konnektivitätstests weiterleiten, damit Sie fortfahren können. Wenn der Status „Erreichbar“ lautet, sind viele Konfigurationsprobleme ausgeschlossen. Dies ist jedoch keine Garantie dafür, dass das Ziel erreichbar ist. Es wurde nicht versucht, eine TCP-Verbindung zum Ziel herzustellen. Nur die nächste Diagnose unten kann dabei helfen.

    Ergebnisse des Konnektivitätstests


VM-Konnektivitätstest (alle Ziele)

  1. Erstellen Sie eine VM-Instanz in derselben VPC, die per Peering mit Apigee verbunden ist, auf Linux.
  2. Führen Sie Konnektivitätstests von der VM aus durch, 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 einem Zeitlimit 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 gesamte Ausgabe und suchen Sie nach diesem Fehler: 
    * Closing connection 0
 curl: (28) Connection timed out after 3005 milliseconds

    Das Vorhandensein dieses Fehlers bestätigt, dass das Problem außerhalb von Apigee reproduzierbar ist.

    Wenn andere Fehler auftreten, z. B. TLS-Fehler oder ungültige 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 identifiziert 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. Wenn das Zeitlimit für die Verbindung außerhalb von Apigee reproduzierbar ist, untersuchen Sie das Problem in der VPC. Testen Sie die Verbindung möglichst nah am Ziel.

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.

Wenn das Problem zu Stoßzeiten auftritt, ist das Ziel möglicherweise ü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 reproduzierbar ist.

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 Zulassungsliste für IP-Adressen aktiviert ist. Achten Sie darauf, dass alle Apigee-NAT-IPs auf der betroffenen Zielseite hinzugefügt werden. Wenn am Ziel keine Zulassungsliste vorhanden ist, können Sie diesen Abschnitt überspringen.

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

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

NAT-IP-Adressen für eine Instanz auflisten:

curl -H "Authorization: Bearer $TOKEN" \
"https://apigee.googleapis.com/v1/organizations/$ORG_ID/instances/$INSTANCE_NAME/natAddresses"
 Beispielantwort:
{
  "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 ist AKTIV, dann erlauben keine der verwendeten Adressen den Zugriff auf das Internet. Das ist ebenfalls ein Problem.

Wenn Sie mindestens eine AKTIVE Adresse haben, kann sie auf dem Ziel 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 des Ziels.

Wenn das Problem nur zeitweise auftritt, kann das darauf hindeuten, dass nur eine Teilmenge der NAT-IP-Adressen auf die Zulassungsliste des Ziels gesetzt wurde. So finden Sie heraus, ob das der Fall ist:

  1. Erstellen Sie einen neuen Reverse-Proxy, in dem das betroffene Ziel im TargetEndpoint 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 Aufrufers in der Antwort zurückgibt. Speichern Sie die Antwort in der Variablen „response“, damit der Inhalt im Debugger sichtbar ist. Hier ist ein Beispiel für die Konfiguration einer 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. Dazu müssen Sie jedoch mit der AssignMessage-Richtlinie den „.content“-Teil dieser Variablen lesen, damit sie im Debugging-Tool angezeigt wird.

    Achten Sie darauf, dass das Ziel genau wie im betroffenen Proxy konfiguriert ist.

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

    Mit ServiceCallout debuggen
  4. Rechts unten sollte der Bereich Response content (Antwortinhalt) angezeigt werden, der die NAT-IP (im Body) der Apigee-Instanz enthält, die die Anfrage stellt. Wenn Sie die ServiceCallout-Antwort an einem anderen Ort speichern, sollten Sie sie dort finden.

    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 IPs fehlschlagen, ist das ein Zeichen dafür, dass einige, aber nicht alle IPs am Ziel auf der Zulassungsliste stehen.
  6. Wenn Sie keine Korrelation zwischen NAT-IP-Adressen und den Fehlern sehen, 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 liegt ein NAT-Fehler vor. Weitere Informationen finden Sie unter Ursache: Erschöpfung des NAT-IP-Ports.

Lösung

Prüfen Sie, ob NAT-IPs bereitgestellt und aktiviert wurden und ob alle auf der Zielseite hinzugefügt wurden.

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 des Problems. Beispiel: täglich zwischen 17:58 Uhr und 18:08 Uhr.
  2. Prüfen Sie, ob in demselben Zeitraum auch andere Ziele von dem Problem betroffen sind. Dieses andere Ziel muss über das Internet zugänglich sein und darf nicht am selben Ort wie das ursprüngliche betroffene Ziel gehostet werden.
  3. Stellen Sie fest, ob Fehler nur bei einem bestimmten Trafficvolumen in TPS auftreten. Notieren Sie sich dazu den Zeitraum des Problems und rufen Sie das Dashboard Proxy-Leistung auf.
  4. Versuchen Sie, den Zeitraum des Fehlers mit dem Anstieg der durchschnittlichen Transaktionen pro Sekunde in Beziehung zu setzen.
API-Messwerte

In diesem Beispiel steigt die Anzahl der TPS um 17:58 Uhr auf 1.000. 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 für NAT-IP-Adressen neu. Folgen Sie dazu der Anleitung unter Anforderungen für statische NAT-IP-Adressen berechnen.

Sie können auch weitere NAT-IPs hinzufügen und prüfen, ob das Problem dadurch behoben wird. Wenn Sie weitere IPs hinzufügen, müssen Sie sie möglicherweise zuerst auf allen Zielen auf die Zulassungsliste setzen.

Ursache: connect.timeout.millis-Wert zu niedrig

Diagnose

Möglicherweise haben Sie den Zeitlimitwert im Proxy falsch konfiguriert.

Rufen Sie dazu den betroffenen Proxy auf und prüfen Sie den entsprechenden TargetEndpoint. Notieren Sie sich das Attribut „connect.timeout.millis“ und seinen Wert. Im Beispiel ist der Wert 50, was 50 Millisekunden entspricht. Das ist in der Regel zu niedrig, um eine TCP-Verbindung herzustellen. Wenn Sie einen Wert unter 1.000 sehen, ist das wahrscheinlich die Ursache des Problems. Wenn die Property „connect.timeout.millis“ nicht angezeigt wird, ist der Standardwert festgelegt und die Ursache ist nicht bestätigt.

Proxy mit Zeitlimit

Lösung

Korrigieren Sie den Wert für „connect.timeout.millis“ und beachten Sie, dass die Zeiteinheiten in Millisekunden angegeben werden. Der Standardwert ist 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 auch nach Befolgen der obigen Anweisungen weiterhin besteht, sammeln Sie 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: Die Ausgabe des Befehls curl in einer VM