404 Proxy für Host kann nicht identifiziert werden: <virtueller Hostname> und URL: <Pfad>

Sie lesen gerade die Dokumentation zu Apigee Edge.
Apigee X-Dokumentation aufrufen info

Symptom

Die Clientanwendung erhält als Antwort auf die API-Aufrufe den HTTP-Statuscode 404 mit der Meldung Not Found und der Fehlermeldung Unable to identify proxy for host: VIRTUAL_HOST and url: PATH.

Dieser Fehler bedeutet, dass Edge den API-Proxy für den angegebenen virtuellen Host und Pfad nicht finden konnte.

Fehlermeldung

Sie erhalten den folgenden HTTP-Statuscode:

HTTP/1.1 404 Not Found

Außerdem wird eine Fehlermeldung ähnlich der folgenden angezeigt:

{
   "fault":{
      "faultstring":"Unable to identify proxy for host: default and url: \/oauth2\/token",
      "detail":{
         "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
      }
   }
}

Die obige Fehlermeldung gibt an, dass Edge den API-Proxy für den virtuellen Host default und den Pfad /oauth2/token nicht finden konnte.

Mögliche Ursachen

Einige mögliche Ursachen für diesen Fehler:

Allgemeine Diagnoseschritte

NGINX- und Message Processor-Logs können bei der Fehlerbehebung des 404-Fehlers hilfreich sein. So prüfen Sie die Logs:

1. Rufen Sie die NGINX-Logs mit dem folgenden Befehl auf:

   /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

2. Prüfen Sie die Logeinträge auf die folgenden Felder:

   Feld	Wert
   Upstream_status, status	404
   X-Apigee-fault-code	messaging.adaptors.http.flow.ApplicationNotFound

   Notieren Sie sich die Nachrichten-ID aus den Logs.

3. Prüfen Sie die Message Processor-Logs (/opt/apigee/var/log/edge-message-processor/logs/system.log)), um festzustellen, ob Sie messaging.adaptors.http.flow.ApplicationNotFound für die jeweilige API haben oder ob Sie die eindeutige Nachrichten-ID aus Schritt 2 für die API-Anfrage haben.

   Beispiel für Fehlermeldung aus dem Message Processor-Log

NIOThread@1 ERROR ADAPTORS.HTTP.FLOW - AbstractRequestListener.onException() : Request:POST, uri:/weather, message Id:null, exception:com.apigee.rest.framework.ResourceNotFoundException{ code = messaging.adaptors.http.flow.ApplicationNotFound, message = Unable to identify proxy for host: vh1 and url: /weather, associated contexts = []}, context:Context@342ea86b input=ClientInputChannel(SSLClientChannel[Accepted: Remote:10.123.123.123:8443 Local:10.135.33.68:62092]@1206954 useCount=1 bytesRead=0 bytesWritten=0 age=1ms  lastIO=0ms  isOpen=true)

Im obigen Log sind der Fehlercode und die Fehlermeldung wie folgt angegeben:

code = messaging.adaptors.http.flow.ApplicationNotFound,
message = Unable to identify proxy for host: vh1 and url: /weather

Ursache: API-Proxy ist nicht mit dem angegebenen virtuellen Host verknüpft

Wenn der API-Proxy nicht für die Annahme der Anfragen für den jeweiligen virtuellen Host konfiguriert ist, kann eine 404 Not Found-Antwort mit der Fehlermeldung Unable to identify proxy for host: VIRTUAL_HOST and url: PATH. zurückgegeben werden.

Diagnose

1. Prüfen Sie die Proxy-Endpunkt-Konfiguration für den API-Proxy und sehen Sie nach, ob der API-Proxy so konfiguriert ist, dass er die Anfragen für den im Fehler angegebenen virtuellen Host akzeptiert. Dies wird durch das VirtualHost-Element angegeben. Sehen wir uns dazu eine Beispielkonfiguration für ProxyEndpoint an.

   Beispielkonfiguration für ProxyEndpoint, die zeigt, dass der API-Proxy Anfragen auf einem sicheren virtuellen Host akzeptiert

   

2. Angenommen, die virtuellen Hosts sind in der jeweiligen Umgebung so definiert:

   Name	Port	Host-Alias
   default	80	myorg-prod.apigee.net
   secure	443	myorg-prod.apigee.net

3. Sie senden eine API-Anfrage an die default VirtualHost über die URL http://myorg-prod.apigee.net/weather.
4. Da ProxyEndpoint nicht default VirtualHost hat, wie im Beispiel oben gezeigt, erhalten Sie den Antwortcode 404 mit der folgenden Fehlermeldung:

   {"fault":{"faultstring":"Unable to identify proxy for host: default and url: \/weather","detail":{"errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"}}}

5. Im Abschnitt Lösung unten finden Sie Informationen dazu, wie Sie das Problem beheben können.
6. Wenn ProxyEndpoint so konfiguriert ist, dass Anfragen an default VirtualHost akzeptiert werden, fahren Sie mit der nächsten Ursache fort: Pfad ist keinem API-Proxy zugeordnet.

Auflösung

1. Fügen Sie der ProxyEndpoint-Konfiguration das fehlende VirtualHost hinzu, um das Problem zu beheben. Für das oben gezeigte Beispiel können Sie die Standard-VirtualHost der ProxyEndpoint-Konfiguration so hinzufügen:

   <VirtualHost>default</VirtualHost>

   Beispiel für die ProxyEndpoint-Konfiguration mit dem hinzugefügten Standard-VirtualHost

   

2. Wenn Sie im oben genannten Beispiel nur secure VirtualHost für diesen bestimmten API-Proxy verwenden möchten, senden Sie die API-Anfragen nur an secure VirtualHost über das HTTPS-Protokoll:

   https://myorg-prod.apigee.net/weather

Ursache: Der virtuelle Host wurde in einer neu bereitgestellten Überarbeitung des API-Proxys entfernt.

Wenn eine neue Version eines API-Proxys bereitgestellt wird, nachdem ein bestimmter virtueller Host (der Teil der zuvor bereitgestellten Version war) entfernt wurde, der von den Clients weiterhin für API-Anfragen verwendet wird, kann dies zu diesem Problem führen.

Diagnose

1. Prüfen Sie die Proxy Endpoint-Konfiguration des API-Proxys, um festzustellen, ob der API-Proxy so konfiguriert ist, dass er die Anfragen für den im Fehler angegebenen virtuellen Host akzeptiert. Dies wird durch das Element VirtualHost in der ProxyEndpoint-Konfiguration angegeben.
2. Wenn der im Fehler angegebene virtuelle Host nicht in der ProxyEndpoint-Konfiguration vorhanden ist, führen Sie die folgenden Schritte aus. Andernfalls fahren Sie mit der nächsten Ursache fort: Pfad ist keinem API-Proxy zugeordnet.
3. Vergleichen Sie die ProxyEndpoint-Konfiguration der zuvor bereitgestellten Version mit der aktuell bereitgestellten Version.
   1. Angenommen, Ihre zuvor bereitgestellte Überarbeitung war 5 und Ihre aktuell bereitgestellte Überarbeitung ist 6:
      • In Proxy-Endpunkt in Revision 5 konfigurierte virtuelle Hosts

      <HTTPProxyConnection>
          <BasePath>/weather</BasePath>
          <Properties/>
          <VirtualHost>vh1</VirtualHost>
      </HTTPProxyConnection>

      • In ProxyEndpoint in Revision 6 konfigurierte virtuelle Hosts

      <HTTPProxyConnection>
          <BasePath>/weather</BasePath>
          <Properties/>
          <VirtualHost>secure</VirtualHost>
      </HTTPProxyConnection>

   2. Im obigen Beispiel war VirtualHost vh1 in revision 5, vorhanden, wurde aber in revision 6 entfernt und durch VirtualHost secure ersetzt.
   3. Wenn Sie oder Ihre Kunden die Anfragen an diesen API-Proxy also mit VirtualHost vh1 (das Teil von revision 5 war) stellen, erhalten Sie den Antwortcode 404 mit der folgenden Fehlermeldung:

      {"fault":{"faultstring":"Unable to identify proxy for host: vh1 and url: \/weather","detail":{"errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"}}}

4. Prüfen Sie, ob die Änderung des virtuellen Hosts in der aktuell bereitgestellten Revision absichtlich oder unbeabsichtigt vorgenommen wurde, und ergreifen Sie die entsprechenden Maßnahmen, wie im Abschnitt Lösung beschrieben.

Auflösung

Wenn Sie feststellen, dass der oder die virtuellen Hosts in einer neuen Revision entfernt wurden, kann dies beabsichtigt oder versehentlich geschehen sein. Führen Sie für jeden Fall die folgenden Schritte zur Fehlerbehebung aus.

Szenario 1: Bewusste Änderung

Wenn die Entfernung des virtuellen Hosts beabsichtigt ist, können Sie eine der folgenden Optionen auswählen. Die erste Option ist die empfohlene Vorgehensweise:

1. Erstellen Sie einen neuen Proxy mit einem anderen Basispfad und verwenden Sie einen anderen virtuellen Host, der in der zuvor bereitgestellten Überarbeitung nicht vorhanden ist.

2. Wenn Sie den vorhandenen API-Proxy weiterhin verwenden, aber einen anderen virtuellen Host nutzen möchten, ist es besser, den vorhandenen virtuellen Host beizubehalten und den zusätzlichen virtuellen Host hinzuzufügen.

   So wird sichergestellt, dass die Nutzer dieses API-Proxys von der Änderung nicht betroffen sind.

3. Wenn Sie den vorhandenen API-Proxy verwenden und nur einen anderen virtuellen Host haben möchten, informieren Sie Ihre Nutzer im Voraus und nehmen Sie die Änderung während eines Wartungszeitraums vor.

   So wird sichergestellt, dass die Nutzer dieses API-Proxys über die Änderung informiert werden und einen anderen virtuellen Host für die Aufrufe an diesen API-Proxy verwenden können. Daher sind sie von der Änderung nicht betroffen.

Szenario 2: Unbeabsichtigte Änderung

Wenn der virtuelle Host versehentlich und nicht absichtlich entfernt wurde,gehen Sie so vor:

1. Aktualisieren Sie die ProxyEndpoint-Konfiguration in der aktuell bereitgestellten Revision, damit dieselben virtuellen Hosts verwendet werden, die in der zuvor bereitgestellten Revision verwendet wurden. Ändern Sie im obigen Beispiel den folgenden Abschnitt von:

   <HTTPProxyConnection>
       <BasePath>/weather</BasePath>
       <Properties/>
       <VirtualHost>secure</VirtualHost>
   </HTTPProxyConnection>

   zu

   <HTTPProxyConnection>
       <BasePath>/weather</BasePath>
       <Properties/>
       <VirtualHost>vh1</VirtualHost>
   </HTTPProxyConnection>

2. Stellen Sie die Version noch einmal bereit.

Best Practices

Es ist immer ratsam, neue Proxys oder neue Überarbeitungen während eines Wartungszeitraums oder bei geringem Traffic bereitzustellen, damit Probleme, die während der Bereitstellung auftreten, vermieden oder die Auswirkungen auf den Traffic minimiert werden können.

Ursache: Pfad ist keinem API-Proxy zugeordnet

Wenn der API-Proxy nicht für die Annahme der Anfragen für den in der API-Anfrage-URL verwendeten Pfad konfiguriert ist, kann eine 404 Not Found-Antwort mit der Fehlermeldung Unable to identify proxy for host: VIRTUAL_HOST and url: PATH. zurückgegeben werden.

Diagnose

1. Sehen Sie sich die ProxyEndpoint-Konfiguration für den API-Proxy an, für den Sie die API-Anfragen stellen wollten.
2. Prüfen Sie, ob der API-Proxy so konfiguriert ist, dass er die Anfragen für den in der Fehlermeldung angegebenen Pfad akzeptiert. Führen Sie dazu die Schritte in Szenario 1 und Szenario 2 aus.

Szenario 1: Der Pfad stimmt nicht mit dem Basispfad des API-Proxys überein

1. Wenn der in der Fehlermeldung angegebene path nicht mit dem basepath des jeweiligen API-Proxys übereinstimmt oder nicht damit basepath beginnt, kann dies die Ursache für den Fehler sein.
2. Hier ein Beispiel:
1. Die basepath des gewünschten API-Proxys ist /weather.
2. Die API-Anfrage-URL lautet https://myorg-prod.apigee.net/climate. Das bedeutet, dass der in der API-Anfrage-URL verwendete Pfad /climate. ist.
3. In diesem Beispiel ist die path nicht mit der basepath identisch und beginnt auch nicht mit der basepath. Daher erhalten Sie folgende Fehlermeldung:

   {
      "fault":{
         "faultstring":"Unable to identify proxy for host: secure and url: \/climate",
         "detail":{
            "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
         }
      }
   }

Auflösung

1. Prüfen Sie, ob der path in der URL Ihrer API-Anfrage mit dem basepath des jeweiligen API-Proxys übereinstimmt.
2. Im obigen Beispiel sollte die API-Anfrage-URL so aussehen:

   {
   https://myorg-prod.apigee.net/weather

Szenario 2: Der Pfad entspricht keinem der verfügbaren bedingten Abläufe.

1. Wenn die path, die in der API-Anfrage-URL verwendet wird, mit basepath beginnt, ist es möglich, dass die path suffix (der Teil nach basepath), die in der Fehlermeldung angegeben ist, mit keinem der bedingten Abläufe übereinstimmt. Dies könnte den 404-Fehler verursachen.
2. Hier ein Beispiel:
   1. Die basepath des gewünschten API-Proxys ist /weather.
   2. Die API-Anfrage-URL lautet https://myorg-prod.apigee.net/weather/Delhi. Das bedeutet, dass der in der API-Anfrage-URL verwendete Pfad /weather/Delhi. ist.
3. In diesem Beispiel beginnt der path mit dem basepath /weather. Außerdem hat er eine path suffix von /Delhi.
4. Prüfen Sie nun, ob es im ProxyEndpoint bedingte Abläufe gibt.
5. Wenn es keine bedingten Abläufe oder nur wenige nicht bedingte Abläufe gibt, fahren Sie mit der nächsten Ursache fort: API-Proxy nicht in einer Umgebung bereitgestellt.
6. Wenn der ProxyEndpoint nur bedingte Abläufe enthält, prüfen Sie Folgendes:
   1. Wenn in den Bedingungen in allen diesen bedingten Abläufen ein bestimmter proxy.pathsuffix (der Pfad nach dem Basispfad) geprüft wird.
   2. Wenn der in der API-Anfrage-URL angegebene path suffix mit keiner der Bedingungen übereinstimmt, ist dies die Ursache des Fehlers.
7. Angenommen, wir haben zwei Abläufe in ProxyEndpoint und beide sind bedingte Abläufe, wie unten dargestellt:

   <Condition>(proxy.pathsuffix MatchesPath "/Bangalore") and (request.verb = "GET")</Condition>
   
   <Condition>(proxy.pathsuffix MatchesPath "/Chennai") and (request.verb = "GET")</Condition>

   1. Im obigen Beispiel haben wir zwei bedingte Abläufe. Der erste entspricht proxy.pathsuffix (Pfad nach dem Basispfad) bis /Bangalore und der zweite entspricht /Chennai. Es gibt jedoch keine, die mit /Delhi übereinstimmt. ist der path suffix, der in der API-Anfrage-URL übergeben wird.
   2. Das ist die Ursache für den Fehler 404. Daher wird die folgende Fehlermeldung angezeigt:

      {
         "fault":{
            "faultstring":"Unable to identify proxy for host: secure and url: \/weather\/Delhi",
            "detail":{
               "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
            }
         }
      }

Auflösung

1. Achten Sie darauf, dass path suffix mindestens einem der bedingten Abläufe in Ihrem Proxy-Endpunkt entspricht.
2. Im obigen Beispiel können Sie den Fehler mit einer der folgenden Methoden beheben:
   1. Wenn Sie eine bestimmte Gruppe von Richtlinien für den Pfad /Delhi ausführen möchten, fügen Sie einen separaten Ablauf mit der erforderlichen Gruppe von Richtlinien hinzu und sorgen Sie dafür, dass eine Bedingung vorhanden ist, die dem /proxy.pathsuffix /Delhi entspricht, wie unten dargestellt:

      <Condition>(proxy.pathsuffix MatchesPath "/Delhi") and (request.verb = "GET")</Condition>

   2. Wenn Sie eine gemeinsame Gruppe von Richtlinien für den Pfad /Delhi ausführen möchten, muss im gemeinsamen Ablauf eine Bedingung vorhanden sein, die eine generische /proxy.pathsuffix zulässt. Das bedeutet, dass jeder Pfad nach basepath /weather zulässig wäre, wie unten dargestellt:

      <Condition>(proxy.pathsuffix MatchesPath "/**") and (request.verb = "GET")</Condition>

Wenn ProxyEndpoint das richtige basepath hat und path suffix in der API-URL mit einem der bedingten Abläufe übereinstimmt, fahren Sie mit der nächsten Ursache fort: API-Proxy nicht in einer Umgebung bereitgestellt.

Ursache: API-Proxy nicht in einer Umgebung bereitgestellt

Diagnose

1. Ermitteln Sie die Umgebung, in der der in der URL Ihrer API-Anfrage verwendete Hostalias vorhanden ist. Dazu können Sie die Details aller virtuellen Hosts in den einzelnen Umgebungen Ihrer Organisation in der Edge-Benutzeroberfläche prüfen.

   Angenommen, Sie haben folgende Konfiguration:

   • Wenn Ihre URL beispielsweise http://myorg-prod.apigee.net/weather lautet, ist myorg-prod.apigee.net der Hostalias.
   • Der Hostalias myorg-prod.apigee.net ist als Teil eines der virtuellen Hosts in der prod-Umgebung Ihrer Organisation konfiguriert.
2. Prüfen Sie, ob der spezifische API-Proxy in der in Schritt 1 oben ermittelten Umgebung bereitgestellt wird.
3. Wenn der API-Proxy nicht in der angegebenen Umgebung bereitgestellt wird, ist dies die Ursache für den Fehler 404.
   1. Wenn der API-Proxy im Beispiel aus Schritt 1 oben nicht in der Umgebung prod bereitgestellt wird, ist dies die Ursache für den Fehler.
   2. Weitere Informationen finden Sie unten im Abschnitt Lösung.
4. Wenn der API-Proxy in der angegebenen Umgebung bereitgestellt wird, fahren Sie mit der nächsten Ursache fort: Umgebung nicht in Message Processors geladen.

Auflösung

Stellen Sie den API-Proxy in der Umgebung bereit, in der Sie API-Anfragen senden möchten.

Ursache: Umgebung wurde nicht in die Message Processors geladen

Diagnose

1. Melden Sie sich bei jedem Message Processor an und prüfen Sie mit dem folgenden Befehl, ob die Umgebung, in der Sie die API-Anfrage stellen, auf dem Message Processor geladen ist:

   curl -v 0:8082/v1/runtime/organizations/<orgname>/environments

2. Wenn die betreffende Umgebung in der Ausgabe des oben genannten Befehls aufgeführt ist, fahren Sie mit dem nächsten möglichen Grund fort: API-Proxy nicht auf einem oder mehreren Message Processors bereitgestellt.
3. Wenn die jeweilige Umgebung nicht aufgeführt ist, prüfen Sie /opt/apigee/var/log/edge-message-processor/logs/system.log und /opt/apigee/var/log/edge-message-processor/logs/startupruntimeerrors.log in den Message Processors auf Fehler beim Laden von Umgebungen.
4. Es gibt viele verschiedene Fehler, die dazu führen können, dass eine Umgebung nicht in den Message Processor geladen wird. Die Lösung hängt vom aufgetretenen Fehler ab.

Auflösung

Es kann viele Gründe geben, warum die Umgebung nicht in den Message Processor geladen wird. In diesem Abschnitt werden einige mögliche Gründe für dieses Problem beschrieben und es wird erläutert, wie Sie es beheben können.

1. Wenn einer der folgenden Fehler im Message Processor-Log angezeigt wird, liegt das an einem Problem mit den Zertifikaten/Schlüsseln, die dem angegebenen Keystore/Truststore in der angegebenen Umgebung hinzugefügt wurden.

   Fehler 1: java.security.KeyStoreException: Cannot overwrite own certificate

   2018-01-30 12:04:38,248 pool-47-thread-4 ERROR MESSAGING.RUNTIME - AbstractConfigurator.propagateEvent() : Error while handling the update for the Configurator
   com.apigee.kernel.exceptions.spi.UncheckedException: Failed to add certificate : mycert in key store : mytruststore in environment : test
   at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:156) ~[config-entities-1.0.0.jar:na]
   at com.apigee.entities.configurators.KeyStore.handleUpdate(KeyStore.java:101) ~[config-entities-1.0.0.jar:na]
   at com.apigee.entities.AbstractConfigurator.propagateEvent(AbstractConfigurator.java:85) ~[config-entities-1.0.0.jar:na]
   at com.apigee.messaging.runtime.Environment.handleUpdate(Environment.java:238) [message-processor-1.0.0.jar:na]
   …
   Caused by: java.security.KeyStoreException: Cannot overwrite own certificate
   at com.sun.crypto.provider.JceKeyStore.engineSetCertificateEntry(JceKeyStore.java:355) ~[sunjce_provider.jar:1.8.0_151]
   at java.security.KeyStore.setCertificateEntry(KeyStore.java:1201) ~[na:1.8.0_151]
   at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:153) ~[config-entities-1.0.0.jar:na]

   ... 20 common frames omitted

   2018-01-30 12:04:38,250 pool-47-thread-4 ERROR MESSAGING.RUNTIME - AbstractConfigurator.rollbackTransaction() : Error in processing the changes : Unknown resource type cert

   Fehler 2: java.security.KeyStoreException: Cannot overwrite secret key

   2017-11-01 03:28:47,560 pool-21-thread-7 ERROR MESSAGING.RUNTIME - AbstractConfigurator.propagateEvent() : Error while handling the update for the Configurator
   com.apigee.kernel.exceptions.spi.UncheckedException: Failed to add certificate : mstore in key store : myTruststore in environment : dev
   at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:156) ~[config-entities-1.0.0.jar:na]
   at com.apigee.entities.configurators.KeyStore.handleUpdate(KeyStore.java:101) ~[config-entities-1.0.0.jar:na]
   ...
   Caused by: java.security.KeyStoreException: Cannot overwrite secret key
   at com.sun.crypto.provider.JceKeyStore.engineSetCertificateEntry(JceKeyStore.java:354) ~[sunjce_provider.jar:1.8.0_144]
   at java.security.KeyStore.setCertificateEntry(KeyStore.java:1201) ~[na:1.8.0_144]
   at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:153) ~[config-entities-1.0.0.jar:na]
   ... 20 common frames omitted
   
   2017-11-01 03:28:47,562 pool-21-thread-7 ERROR MESSAGING.RUNTIME - AbstractConfigurator.rollbackTransaction() : Error in processing the changes : Unknown resource type cert

2. Rufen Sie die Details des im vorherigen Schritt in der Fehlermeldung angegebenen Keystore/Truststore mit dem folgenden Management API-Aufruf ab:

   curl -v "http://<management-IPaddress>:8080/v1/organizations/<org-name>/environments/<env-name>/keystores/myTruststore" -u <user> 

   
   

   Beispielausgabe:

   {
      "certs":[
         "mycert",
         "mycert-new"
      ],
      "keys":[
         "mycert"
      ],
      "name":"myTruststore"
   }

3. Die Beispielausgabe zeigt, dass sich im Truststore myTruststore zwei Zertifikate und ein Schlüssel befinden. Der Truststore enthält in der Regel keinen Schlüssel. Wenn dies der Fall ist, ist es besser, ein einzelnes Zertifikat und einen einzelnen Schlüssel zu verwenden.
4. Rufen Sie die Details zu den beiden Zertifikaten mit der folgenden API ab:

   curl -s http://<management-IPaddress>:8080/v1/runtime/organizations/<org-name>/environments/<env-name>/keystores/<keystore-name>/certs/<cert-name>
   

5. Prüfen Sie das Ablaufdatum der einzelnen Zertifikate und ermitteln Sie das abgelaufene/ältere Zertifikat.
6. Löschen Sie das abgelaufene oder unerwünschte Zertifikat aus dem Truststore myTruststore.

Wenn das Problem weiterhin besteht oder ein anderer Fehler als die in Schritt 1 genannten auftritt, gehen Sie zu Erfassen von Diagnoseinformationen erforderlich.

Ursache: API-Proxy ist nicht auf einem oder mehreren Message Processors bereitgestellt

Der API-Proxy ist möglicherweise nicht auf einem oder mehreren Message Processors bereitgestellt. Dieses Problem tritt sehr selten auf und ist meistens auf eine fehlende Ereignisbenachrichtigung vom Management Server an den Message Processor während der Bereitstellung des jeweiligen API-Proxys zurückzuführen. Auch in diesem Fall können Sie die Trace-Sitzung nicht in der Edge-Benutzeroberfläche erstellen.

Diagnose

1. Melden Sie sich bei jedem Message Processor an und prüfen Sie mit dem folgenden Befehl, ob die jeweilige Revision des API-Proxys bereitgestellt ist:

   curl -v 0:8082/v1/runtime/organizations/<orgname>/environments/<envname>/apis/<apiname>/revisions
   

2. Wenn die spezifische Version des API-Proxys nicht als Ausgabe des in Schritt 1 genannten Befehls angezeigt wird, starten Sie den spezifischen Message Processor neu, wie unter Lösung beschrieben.
3. Wiederholen Sie die Schritte 1 und 2 für alle Message Processors.
4. Wenn die jeweilige Revision des API-Proxys auf allen Message Processors bereitgestellt wird, ist dies nicht die Ursache für dieses Problem. Gehen Sie zu Erfassen von Diagnoseinformationen erforderlich.

Auflösung

Starten Sie die Message Processors neu, auf denen die betreffende Revision des API-Proxys nicht bereitgestellt ist.

/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

Fehlerdiagnose mit API Monitoring

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

Rufen Sie für dieses Problem die Seite API-Monitoring > Untersuchen auf, wählen Sie das entsprechende Datum, den entsprechenden Proxy usw. aus. Möglicherweise werden die folgenden Details angezeigt:

• Fehlercode:messaging.adaptors.http.flow.ApplicationNotFound
• Statuscode:404
• Fehlerquelle:Apigee oder MP

Außerdem können Sie wie im Screenshot oben auf Logs ansehen klicken, um weitere Informationen zu erhalten.

Im Beispielszenario wird gezeigt, wie Sie 5xx-Probleme mit Ihren APIs mithilfe von API Monitoring beheben können. Sie können beispielsweise eine Benachrichtigung einrichten, um benachrichtigt zu werden, wenn die Anzahl der 404-Statuscodes einen bestimmten Grenzwert überschreitet.

Erfassen von Diagnoseinformationen erforderlich

Wenn das Problem auch nach Befolgen der obigen Anweisungen weiterhin besteht, sammeln Sie die folgenden Diagnoseinformationen. Wenden Sie sich mit diesen Informationen an den Apigee Edge-Support.

1. Wenn Sie ein Public Cloud-Nutzer sind, geben Sie die folgenden Informationen an:
   • Name der Organisation
   • Name der Umgebung
   • Name des API-Proxys
   • Vollständiger curl-Befehl zum Reproduzieren des Fehlers
2. Wenn Sie ein Private Cloud-Nutzer sind, geben Sie die folgenden Informationen an:
   • Vollständige angezeigte Fehlermeldung
   • Name der Umgebung
   • API-Proxy-Bundle
   • Message Processor-Logs /opt/apigee/var/log/edge-message-processor/logs/system.log
   • Ausgabe der folgenden Befehle auf jedem der Message Processors.

   curl -v 0:8082/v1/runtime/organizations/<orgname>/environments

   curl -v 0:8082/v1/runtime/organizations/<orgname>/environments/<envname>/apis/<apiname>/revisions
         

3. Details dazu, welche Abschnitte dieses Playbooks Sie ausprobiert haben, und alle anderen Informationen, die uns helfen, das Problem schnell zu beheben.