Diese Seite wurde von der Cloud Translation API übersetzt.

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

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

Symptom

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

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 wie diese angezeigt:

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

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

Mögliche Ursachen

Mögliche Ursachen für diesen Fehler:

Ursache	Beschreibung	Anleitungen zur Fehlerbehebung gelten für
API-Proxy nicht mit dem bestimmten virtuellen Host verknüpft	Der spezifische API-Proxy ist nicht dafür konfiguriert, Anfragen auf dem in der Fehlermeldung angegebenen virtuellen Host zu akzeptieren.	Nutzer von Edge Public und Private Cloud
Virtueller Host in einer neu bereitgestellten Version des API-Proxys entfernt	Dieses Problem kann auftreten, wenn der virtuelle Host aus der neu bereitgestellten Überarbeitung entfernt wird, während der Client den spezifischen virtuellen Host noch verwendet.	Nutzer von Edge Public und Private Cloud
Pfad ist keinem API-Proxy zugeordnet	Der spezifische API-Proxy ist nicht dafür konfiguriert, Anfragen unter dem in der Fehlermeldung angegebenen Pfad zu akzeptieren.	Nutzer von Edge Public und Private Cloud
API-Proxy nicht in einer Umgebung bereitgestellt	Der spezifische API-Proxy wird nicht in der spezifischen Umgebung bereitgestellt, in der Sie die API-Anfragen stellen möchten.	Nutzer von Edge Public und Private Cloud
Umgebung nicht auf Message Processor geladen	Die spezifische Umgebung (in der Sie versuchen, die API-Anfragen zu senden) wurde aufgrund eines Fehlers nicht auf die Message Processor geladen.	Edge Private Cloud-Nutzer
API-Proxy nicht auf einem oder mehreren Message Processorn bereitgestellt	Der API-Proxy kann aufgrund fehlender Ereignisbenachrichtigungen während der Bereitstellung nicht auf einem oder mehreren Message Processorn bereitgestellt werden.	Edge Private Cloud-Nutzer

Allgemeine Diagnoseschritte

NGINX- und Message Processor-Logs sind bei der Behebung des Fehlers 404 hilfreich. So prüfen Sie die Protokolle:

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

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

Prüfen Sie die folgenden Felder in den Logeinträgen:

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

Notieren Sie sich die Nachrichten-ID aus den Protokollen.

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 einer Fehlermeldung aus dem Message Processor-Protokoll

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)

Das Protokoll oben zeigt den Fehlercode und die Fehlermeldung wie folgt an:

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

Hinweis:url und host können je nach API-Proxy, bei dem das Problem auftritt, variieren.

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

Wenn der API-Proxy nicht so konfiguriert ist, dass er die Anfragen für den jeweiligen virtuellen Host akzeptiert, erhalten wir eine 404 Not Found-Antwort mit der Fehlermeldung Unable to identify proxy for host: VIRTUAL_HOST and url: PATH..

Diagnose

Prüfen Sie die Konfiguration des Proxy-Endpunkts für den API-Proxy und 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 angegeben. Sehen wir uns eine ProxyEndpoint-Beispielkonfiguration an, um dies zu verstehen.
Beispiel für eine Proxy-Endpunktkonfiguration, die zeigt, dass der API-Proxy Anfragen auf einem sicheren virtuellen Host akzeptiert

Angenommen, die virtuellen Hosts sind in der spezifischen Umgebung so definiert:

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

Sie stellen eine API-Anfrage an default VirtualHost mit der URL http://myorg-prod.apigee.net/weather.

Da ProxyEndpoint nicht default VirtualHost enthält, 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"}}}

Im Abschnitt Lösung unten erfahren Sie, wie Sie das Problem beheben können.
Wenn ProxyEndpoint so konfiguriert ist, dass die Anfragen an den default-VirtualHost akzeptiert werden, fahren Sie mit der nächsten Ursache fort: Pfad ist mit keinem API-Proxy verknüpft.

Auflösung

Fügen Sie der ProxyEndpoint-Konfiguration das fehlende VirtualHost hinzu, um das Problem zu beheben. Im obigen Beispiel können Sie der ProxyEndpoint-Konfiguration den Standard-VirtualHost so hinzufügen:
```
<VirtualHost>default</VirtualHost>
```
Beispiel für eine Proxy-Endpunktkonfiguration, in der Standard> VirtualHost> hinzugefügt wird
Wenn Sie im obigen Beispiel nur secure VirtualHost für diesen bestimmten API-Proxy verwenden möchten, stellen Sie die API-Anfragen auch nur an secure VirtualHost mit dem HTTPS-Protokoll:
```
https://myorg-prod.apigee.net/weather
```

Ursache: Virtueller Host in einer neu bereitgestellten Version des API-Proxys entfernt

Wenn nach dem Entfernen eines bestimmten virtuellen Hosts (der Teil der zuvor bereitgestellten Überarbeitung war) eine neue Version eines API-Proxys bereitgestellt wird, der von den Clients noch für API-Anfragen verwendet wird, kann dies zu diesem Problem führen.

Diagnose

Prüfen Sie die Konfiguration des Proxy-Endpunkts für den API-Proxy, 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 Konfiguration ProxyEndpoint angegeben.
Wenn der im Fehler angegebene virtuelle Host nicht in der Konfiguration ProxyEndpoint vorhanden ist, führen Sie die folgenden Schritte aus. Fahren Sie andernfalls mit der nächsten Ursache fort: Pfad ist mit keinem API-Proxy verknüpft.
Vergleichen Sie die ProxyEndpoint-Konfiguration der zuvor bereitgestellten Überarbeitung mit der aktuell bereitgestellten Überarbeitung.
1. Angenommen, die zuvor bereitgestellte Überarbeitung war 5 und Ihre aktuell bereitgestellte Überarbeitung ist 6:
  - Virtuelle Hosts, die in Überarbeitung 5 im Proxy-Endpunkt konfiguriert wurden
  - Virtuelle Hosts, die in Überarbeitung 6 im Proxy-Endpunkt konfiguriert wurden
2. Im obigen Beispiel war VirtualHost vh1 in revision 5, vorhanden, wurde aber aus revision 6 entfernt und durch VirtualHost secure ersetzt.
3. Wenn Sie oder Ihre Clients Anfragen an diesen API-Proxy mit VirtualHost vh1 senden (dies war Teil von revision 5), 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"}}}
```
Prüfen Sie, ob die Änderung des virtuellen Hosts in der aktuell bereitgestellten Überarbeitung absicht oder unbeabsichtigt erfolgt ist, und ergreifen Sie die entsprechenden Maßnahmen, wie im Abschnitt Lösung beschrieben.

Auflösung

Wenn Sie feststellen, dass der virtuelle Host bzw. die virtuellen Hosts bei einer neuen Überarbeitung entfernt werden, kann dies beabsichtigt sein oder versehentlich. Führen Sie für jeden Fall die folgenden Lösungsvorschläge bzw. die empfohlenen Schritte durch, um das Problem zu beheben.

Szenario 1: Beabsichtigte Änderung

Falls die Entfernung des virtuellen Hosts beabsichtigt ist, können Sie eine der folgenden Optionen auswählen. Die erste wird empfohlen:

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).
Wenn Sie den vorhandenen API-Proxy weiterhin verwenden, aber einen anderen virtuellen Host verwenden möchten, ist es besser, den vorhandenen virtuellen Host beizubehalten und den zusätzlichen virtuellen Host hinzuzufügen.

Dadurch wird sichergestellt, dass die Nutzer dieses API-Proxys von der Änderung nicht betroffen sind.
Wenn Sie den vorhandenen API-Proxy verwenden möchten und nur einen anderen virtuellen Host haben, informieren Sie Ihre Nutzer im Voraus und führen Sie diese Änderung während eines Wartungszeitraums durch.

Dadurch wird sichergestellt, dass die Nutzer dieses API-Proxys über die Änderung informiert sind und einen anderen virtuellen Host verwenden können, um die Aufrufe an diesen API-Proxy auszuführen. Sie sind daher von dieser Änderung nicht betroffen.

Szenario 2: Unbeabsichtigte Änderung

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

Aktualisieren Sie die ProxyEndpoint-Konfiguration in der aktuell bereitgestellten Überarbeitung, um dieselben virtuellen Hosts zu verwenden, die auch in der zuvor bereitgestellten Überarbeitung verwendet wurden. Ändern Sie im obigen Beispiel den folgenden Abschnitt von

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

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

Stellen Sie die Überarbeitung noch einmal bereit.

Best Practices

Es ist immer ratsam, während eines Wartungszeitraums neue Proxys oder neue Überarbeitungen bereitzustellen oder wenn der Traffic am wenigsten zu erwarten ist. So können Probleme, die während der Bereitstellung auftreten, vermieden werden und die Auswirkungen auf den Traffic minimiert werden.

Ursache: Pfad ist keinem API-Proxy zugeordnet

Wenn der API-Proxy nicht so konfiguriert ist, dass er die Anfragen für den spezifischen Pfad akzeptiert, der in der API-Anfrage-URL verwendet wird, erhalten wir eine 404 Not Found-Antwort mit der Fehlermeldung Unable to identify proxy for host: VIRTUAL_HOST and url: PATH..

Diagnose

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

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

Wenn der in der Fehlermeldung angegebene path nicht mit dem basepath des spezifischen API-Proxys übereinstimmt oder nicht mit basepath beginnt, könnte dies die Ursache des Fehlers sein.
Im Folgenden wird dies anhand eines Beispiels erklärt:

Der basepath des gewünschten API-Proxys ist /weather
Die API-Anfrage-URL lautet https://myorg-prod.apigee.net/climate. Der in der API-Anfrage-URL verwendete Pfad lautet also /climate.

In diesem Beispiel ist path nicht mit basepath identisch und beginnt nicht mit basepath. Daher wird der folgende Fehler angezeigt:

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

Auflösung

Achten Sie darauf, dass die in Ihrer API-Anfrage-URL verwendete path mit der basepath des jeweiligen API-Proxys übereinstimmt.
Im Beispiel oben sollte die API-Anfrage-URL so aussehen:
```
{
https://myorg-prod.apigee.net/weather
```

Szenario 2: Pfad stimmt mit keinem der verfügbaren bedingten Abläufe überein

Wenn das in der API-Anfrage-URL verwendete path mit basepath beginnt, stimmt der in der Fehlermeldung angegebene path suffix (der Teil nach basepath) möglicherweise mit keinem der bedingten Flüsse überein. In diesem Fall kann der Fehler 404 auftreten.
Sehen wir uns ein Beispiel an, um dies zu erklären:
1. Der basepath des gewünschten API-Proxys ist /weather
2. Die API-Anfrage-URL lautet https://myorg-prod.apigee.net/weather/Delhi. Der in der API-Anfrage-URL verwendete Pfad lautet also /weather/Delhi.
In diesem Beispiel beginnt path mit dem basepath-/weather. Außerdem hat er für path suffix den Wert /Delhi.
Prüfen Sie nun, ob bedingte Flows in ProxyEndpoint vorhanden sind.
Wenn es keine bedingten Flüsse oder einige nicht bedingte Datenflüsse gibt, fahren Sie mit der nächsten Ursache fort – API-Proxy nicht in einer Umgebung bereitgestellt.
Wenn ProxyEndpoint nur bedingte Abläufe enthält, prüfen Sie Folgendes:
1. Wenn die Bedingungen in all diesen bedingten Flüssen nach einem bestimmten proxy.pathsuffix suchen (dem Pfad nach dem Basispfad).
2. Wenn das in der API-Anfrage-URL angegebene path suffix mit keiner der Bedingungen übereinstimmt, ist das die Ursache des Fehlers.
Angenommen, wir haben zwei Abläufe in ProxyEndpoint und beide sind bedingte Abläufe, wie unten gezeigt:
```
<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 Flüsse: einen, der mit proxy.pathsuffix (Pfad nach dem Basispfad) zu /Bangalore übereinstimmt, und der andere mit /Chennai. Es gibt jedoch keine Übereinstimmung, die mit /Delhi übereinstimmt, also dem path suffix, der in der API-Anfrage-URL übergeben wird.
2. Dies ist die Ursache des Fehlers 404. Daher würde der folgende Fehler angezeigt werden:
```
{
   "fault":{
      "faultstring":"Unable to identify proxy for host: secure and url: \/weather\/Delhi",
      "detail":{
         "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
      }
   }
}
```

Auflösung

Achten Sie darauf, dass path suffix mit mindestens einem der bedingten Datenflüsse in Ihrem Proxy-Endpunkt übereinstimmt.
Im obigen Beispiel können Sie den Fehler mit den folgenden Ansätzen beheben:
1. Wenn Sie einen bestimmten Satz von Richtlinien für den Pfad /Delhi ausführen möchten, fügen Sie einen separaten Ablauf mit den erforderlichen Richtlinien hinzu und achten Sie darauf, dass eine Bedingung vorhanden ist, die dem /proxy.pathsuffix-/Delhi entspricht (siehe unten):
```
<Condition>(proxy.pathsuffix MatchesPath "/Delhi") and (request.verb = "GET")</Condition>
```
2. Wenn Sie einen gemeinsamen Satz von Richtlinien für den Pfad /Delhi ausführen möchten, achten Sie im gemeinsamen Ablauf darauf, dass eine Bedingung vorhanden ist, die einen generischen /proxy.pathsuffix-Wert zulässt. Es ist also ein beliebiger Pfad nach dem basepath-/weather zulässig, wie unten gezeigt:
```
<Condition>(proxy.pathsuffix MatchesPath "/**") and (request.verb = "GET")</Condition>
```

Wenn die ProxyEndpoint den richtigen basepath hat und die in der API-URL angegebene path suffix 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

Ermitteln Sie die Umgebung, in der der Hostalias vorhanden ist, der in Ihrer API-Anfrage-URL verwendet wird. Dazu können Sie die Details aller virtuellen Hosts in jeder Umgebung Ihrer Organisation in der Edge-Benutzeroberfläche prüfen.
Angenommen, die folgende Konfiguration sieht so aus:
- Wenn http://myorg-prod.apigee.net/weather Ihre URL ist, dann ist myorg-prod.apigee.net der Hostalias.
- Der Hostalias myorg-prod.apigee.net ist als Teil eines der virtuellen Hosts in der Umgebung prod Ihrer Organisation konfiguriert.
Prüfen Sie, ob der spezifische API-Proxy in der in Schritt 1 oben festgelegten Umgebung bereitgestellt wurde.
Wenn der API-Proxy nicht in der spezifischen Umgebung bereitgestellt ist, ist das die Ursache für den Fehler 404.
1. Wenn also im obigen Beispiel in Schritt 1 der API-Proxy nicht in der prod-Umgebung bereitgestellt wurde, ist das die Fehlerursache.
2. Gehen Sie zum Abschnitt Lösung unten.
Wenn der API-Proxy in der spezifischen Umgebung bereitgestellt wird, fahren Sie mit dem nächsten Grund fort: Umgebung nicht auf Message Processors geladen.

Auflösung

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

Ursache: Umgebung nicht auf Message Processors geladen

Diagnose

Melden Sie sich bei jedem der Message Processor an und prüfen Sie mit dem folgenden Befehl, ob die Umgebung, in der Sie die API-Anfrage stellen, auf den Message Processor geladen wurde:
```
curl -v 0:8082/v1/runtime/organizations/<orgname>/environments
```
Wenn die spezifische Umgebung als Teil des obigen Befehls aufgeführt ist, fahren Sie mit dem nächsten Grund fort: API-Proxy nicht auf einem oder mehreren Message Processorn bereitgestellt.
Wenn die spezifische 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 auf den Message Processorn auf Fehler beim Laden der Umgebungen.
Es können viele verschiedene Fehler auftreten, die zu einem Fehler beim Laden einer Umgebung in den Message Processor führen können. Die Lösung hängt vom aufgetretenen Fehler ab.

Auflösung

Die Umgebung kann aus vielen Gründen nicht auf den Message Processor geladen werden. In diesem Abschnitt werden einige mögliche Gründe für dieses Problem aufgezeigt und erläutert, wie Sie das Problem beheben können.

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

Fehler 1: java.security.KeyStoreException: Eigenes Zertifikat kann nicht überschrieben werden

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: Geheimer Schlüssel kann nicht überschrieben werden

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

Rufen Sie mit dem folgenden Verwaltungs-API-Aufruf die Details zum Schlüsselspeicher/Truststore ab, der in der Fehlermeldung angegeben wurde, die im vorherigen Schritt angezeigt wurde:

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"
}

Die Beispielausgabe zeigt, dass im Truststore myTruststore zwei Zertifikate und ein Schlüssel vorhanden sind. Der Truststore enthält in der Regel keinen Schlüssel. Ist dies der Fall, ist es besser, ein einzelnes Zertifikat und einen einzelnen Schlüssel zu haben.

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>

Überprüfen Sie das Ablaufdatum jedes Zertifikats und ermitteln Sie, welches abgelaufene/ältere Zertifikat ist.
Löschen Sie das abgelaufene oder unerwünschte Zertifikat aus dem Truststore myTruststore.

Wenn das Problem weiterhin besteht oder ein anderer Fehler als der in Schritt 1 oben genannte Fehler auftritt, lesen Sie den Abschnitt Diagnoseinformationen müssen erfasst werden.

Ursache: Der API-Proxy wurde auf einem oder mehreren Message Processorn nicht bereitgestellt

Der API-Proxy darf nicht auf einem oder mehreren Message Processorn bereitgestellt werden. Dieses Problem tritt sehr selten auf und tritt meistens aufgrund einer fehlenden Ereignisbenachrichtigung vom Management Server an den Message Processor während der Bereitstellung des spezifischen API-Proxys auf. In diesem Fall können Sie die Trace-Sitzung auch nicht in der Edge-Benutzeroberfläche erstellen.

Diagnose

Melden Sie sich bei jedem Message Processor an und prüfen Sie mit dem folgenden Befehl, ob die spezifische Version des API-Proxys bereitgestellt wurde:
```
curl -v 0:8082/v1/runtime/organizations/<orgname>/environments/<envname>/apis/<apiname>/revisions
```
Wenn die spezifische Version des API-Proxys nicht als Ausgabe des in Schritt 1 genannten Befehls angezeigt wird, starten Sie den jeweiligen Message Processor neu, wie unter Lösung erläutert.
Wiederholen Sie die Schritte 1 bis 2 für alle Message Processor.
Wenn die spezifische Version des API-Proxys auf allen Message Processorn bereitgestellt ist, ist dies nicht die Ursache für dieses Problem. Weitere Informationen finden Sie unter Diagnoseinformationen müssen erfasst werden.

Auflösung

Starten Sie die spezifischen Message Processors neu, auf denen die spezifische Version des API-Proxys nicht bereitgestellt wurde.

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

Probleme mithilfe von API-Monitoring diagnostizieren

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

Bei diesem Problem können Sie zur Seite API Monitoring > Investigate gehen und das entsprechende Datum, den Proxy usw. auswählen. Dort werden möglicherweise die folgenden Details angezeigt:

Fehler- und Statuscode in der Benutzeroberfläche

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

Sie können auch auf Logs ansehen klicken, wie im Screenshot oben gezeigt, und das Problem weiter untersuchen.

Logs aufrufen

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

Erfassen von Diagnoseinformationen erforderlich

Wenn das Problem trotz Befolgen der obigen Anleitung weiterhin besteht, stellen Sie die folgenden Diagnoseinformationen zusammen. Teilen Sie diese Informationen mit dem Apigee Edge-Support.

Wenn Sie ein Nutzer von Public Cloud sind, geben Sie die folgenden Informationen an:
- Name der Organisation
- Name der Umgebung
- Name des API-Proxys
- Führen Sie den curl-Befehl aus, um den Fehler zu reproduzieren
Wenn Sie die private Cloud nutzen, geben Sie die folgenden Informationen an:
- Vollständige Fehlermeldung festgestellt
- Name der Umgebung
- API-Proxy-Bundle
- Message Processor-Protokolle /opt/apigee/var/log/edge-message-processor/logs/system.log
- Ausgabe der folgenden Befehle auf jedem der Message Processor
Details zu den Abschnitten in diesem Playbook, die du ausprobiert hast, und zu anderen Erkenntnissen, die uns helfen könnten, dieses Problem schneller zu lösen.