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

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

Symptom

Die Clientanwendung ruft den HTTP-Statuscode 404 zusammen mit der Nachricht ab Not Found und die 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 den angegebenen Pfad nicht finden konnte.

Fehlermeldung

Sie erhalten den folgenden HTTP-Statuscode: 

HTTP/1.1 404 Not Found

Außerdem wird eine Fehlermeldung angezeigt, die in etwa so aussieht: 

{
   "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 die Virtueller Host default und /oauth2/token-Pfad.

Mögliche Ursachen

Im Folgenden finden Sie einige mögliche Ursachen für diesen Fehler:

Ursache Beschreibung Anleitungen zur Fehlerbehebung gelten für
<ph type="x-smartling-placeholder"></ph> API-Proxy nicht mit dem spezifischen virtuellen Host verknüpft Der spezifische API-Proxy ist nicht so konfiguriert, dass Anfragen auf dem virtuellen Host akzeptiert werden in der Fehlermeldung angegeben ist. Edge-Nutzer von öffentlichen und privaten Clouds
Virtueller Host in einer neu bereitgestellten Version des API-Proxys entfernt Virtuellen Host aus der neu bereitgestellten Version entfernen, während der Client noch vorhanden ist die Verwendung des jeweiligen virtuellen Hosts, kann dieses Problem verursachen. Edge-Nutzer von öffentlichen und privaten Clouds
<ph type="x-smartling-placeholder"></ph> Pfad ist mit keinem API-Proxy verknüpft Der spezifische API-Proxy ist nicht so konfiguriert, dass er Anfragen unter dem angegebenen Pfad akzeptiert. in der Fehlermeldung. Edge-Nutzer von öffentlichen und privaten Clouds
<ph type="x-smartling-placeholder"></ph> API-Proxy nicht in einer Umgebung bereitgestellt Der spezifische API-Proxy wurde nicht in der spezifischen Umgebung bereitgestellt, in der Sie sich befinden. die API-Anfragen senden. Edge-Nutzer von öffentlichen und privaten Clouds
<ph type="x-smartling-placeholder"></ph> Umgebung nicht in Message Processor geladen In der spezifischen Umgebung, in der Sie versuchen, die API-Anfragen zu senden, wurden wurde aufgrund eines Fehlers in die Message Processors geladen. Edge Private Cloud-Nutzer
<ph type="x-smartling-placeholder"></ph> API-Proxy nicht auf einem oder mehreren Message Processorn bereitgestellt Der API-Proxy wurde möglicherweise nicht auf einem oder mehreren Message Processorn bereitgestellt, da während der Bereitstellung Ereignisbenachrichtigungen sendet. Edge Private Cloud-Nutzer

Allgemeine Diagnoseschritte

NGINX- und Message Processor-Logs sind bei der Behebung des Fehlers 404 hilfreich. Führen Sie die folgenden Schritte aus, um die Logs zu prüfen:

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

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

    Beispiel für eine Fehlermeldung aus dem Message Processor-Protokoll

    4. 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 Protokoll oben sehen Sie den Fehlercode und die folgende Fehlermeldung:

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

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

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

Diagnose

  1. Überprüfen Sie die Konfiguration des Proxy-Endpunkts für den API-Proxy und stellen Sie fest, ob der API-Proxy ist so konfiguriert, dass sie die Anfragen für den in der Fehlermeldung angegebenen virtuellen Host akzeptieren. Dies ist VirtualHost-Element angezeigt. Sehen wir uns ein Beispiel für ProxyEndpoint an. Konfiguration, um dies zu verstehen.

    Beispielkonfiguration für einen Proxy-Endpunkt, die zeigt, dass der API-Proxy Anfragen auf einer sicherer virtueller Host

  2. 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
  3. Sie stellen mit der URL eine API-Anfrage an die default VirtualHost http://myorg-prod.apigee.net/weather
  4. Da ProxyEndpoint nicht über default VirtualHost verfügt, wie in der im obigen Beispiel erhalten Sie den 404-Antwortcode mit der folgenden Fehlermeldung: 
    {"fault":{"faultstring":"Unable to identify proxy for host: default and url: \/weather","detail":{"errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"}}}
  5. Lesen Sie unten den Abschnitt Lösung, um dieses Problem zu beheben.
  6. Wenn die ProxyEndpoint so konfiguriert ist, dass sie die Anfragen im default akzeptiert VirtualHost, wechseln Sie zum nächsten Grund – <ph type="x-smartling-placeholder"></ph> Pfad ist mit keinem API-Proxy verknüpft.

Auflösung

  1. Fügen Sie der ProxyEndpoint-Konfiguration die fehlende VirtualHost hinzu. um das Problem zu lösen. Für das obige Beispiel können Sie den Standardwert VirtualHost hinzufügen. auf die ProxyEndpoint-Konfiguration: 
    <VirtualHost>default</VirtualHost>

    Beispiel für eine Proxy-Endpunktkonfiguration mit dem Standardwert VirtualHost&gt; wird hinzugefügt

  2. Wenn Sie im oben genannten Beispiel nur das secure VirtualHost für diesen spezifischen API-Proxy und stellen Sie dann die API-Anfragen. nur an secure VirtualHost unter Verwendung des HTTPS-Protokolls: 
    https://myorg-prod.apigee.net/weather

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

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

Diagnose

  1. Überprüfen Sie die Konfiguration des Proxy-Endpunkts für den API-Proxy, um festzustellen, ob der API-Proxy ist so konfiguriert, dass sie die Anfragen für den in der Fehlermeldung angegebenen virtuellen Host akzeptieren. Dies ist in der ProxyEndpoint-Konfiguration durch das Element VirtualHost angegeben.
  2. Wenn der im Fehler angegebene virtuelle Host in der ProxyEndpoint nicht vorhanden ist und führen Sie dann die folgenden Schritte aus. Anderenfalls fahren Sie mit dem nächsten Grund fort: Pfad ist mit keinem API-Proxy verknüpft.
  3. Vergleichen Sie die ProxyEndpoint-Konfiguration der zuvor bereitgestellten Version mit der aktuellen Konfiguration bereitgestellte Version.
    1. Angenommen, Ihre zuvor bereitgestellte Überarbeitung war 5 und Ihr Die aktuell bereitgestellte Version ist 6: <ph type="x-smartling-placeholder">
        </ph>
      • Im Proxy-Endpunkt in Version 5 konfigurierte virtuelle Hosts
        • <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>vh1</VirtualHost>
</HTTPProxyConnection>
      • In Proxy-Endpunkt konfigurierte virtuelle Hosts in Version 6
        • <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>
    2. Im obigen Beispiel war VirtualHost vh1 in revision 5, vorhanden wird aber in revision 6 entfernt und durch VirtualHost secure ersetzt.
    3. Wenn Sie oder Ihre Clients also Anfragen an diesen API-Proxy mithilfe von VirtualHost vh1 (das gehörte zu revision 5), dann erhalten Sie die 404-Antwortcode 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 absichtlich vorgenommen wurde. unbeabsichtigt in der aktuell bereitgestellten Version die angemessenen Maßnahmen, wie im Abschnitt Lösung erläutert.

Auflösung

Wenn Sie feststellen, dass der virtuelle Host oder die virtuellen Hosts in einer neuen Version entfernt werden, kann dies beabsichtigt oder durch Unfalls. Führen Sie für jeden Fall die folgenden Lösungs- bzw. empfohlenen Schritte aus, um das Problem zu beheben.

Szenario 1: Vorsätzliche Änderung

Wenn der virtuelle Host absichtlich entfernt wurde, können Sie eine der folgenden Optionen auswählen: Optionen, wobei die erste Option die empfohlene Vorgehensweise ist:

  1. Neuen Proxy mit einem anderen Basispfad erstellen und einen anderen virtuellen Host verwenden (ist in der zuvor bereitgestellten Version nicht vorhanden)

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

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

    Dadurch wird sichergestellt, dass die Nutzer dieses API-Proxys über die Änderung informiert sind und kann einen anderen virtuellen Host verwenden, um die Aufrufe an diesen API-Proxy zu senden. Daher werden sie sind von der Änderung nicht betroffen.

Szenario 2: Unbeabsichtigte Veränderung

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

  1. ProxyEndpoint-Konfiguration in der aktuell bereitgestellten Version aktualisieren dieselben virtuellen Hosts wie in der zuvor bereitgestellten Version. Im ändern Sie 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 Überarbeitung noch einmal bereit.

Best Practices

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

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 eingeben, erhalten wir eine 404 Not Found-Antwort mit der Fehlermeldung Unable to identify proxy for host: VIRTUAL_HOST and url: PATH.

Diagnose

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

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

  1. Wenn die in der Fehlermeldung angegebene path nicht mit der basepath übereinstimmt des spezifischen API-Proxys erstellt oder nicht mit basepath beginnt, die Ursache für den Fehler sein.
  2. Sehen wir uns dazu ein Beispiel an:
    1. Die basepath des vorgesehenen 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 lautet /climate..
  3. In diesem Beispiel ist path nicht dasselbe wie basepath. beginnen 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

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

Szenario 2: Der Pfad stimmt mit keinem der verfügbaren bedingten Datenflüsse überein

  1. Beginnt die path in der API-Anfrage-URL mit basepath, ist es möglich, dass path suffix (der Teil nach dem basepath), die in der Fehlermeldung angegeben wird, stimmt mit keiner der Bedingungen überein kann dies zum Fehler 404 führen.
  2. Sehen wir uns dazu ein Beispiel an: <ph type="x-smartling-placeholder">
      </ph>
    1. Die basepath des vorgesehenen 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 path mit basepath /weather. Außerdem hat er für path suffix den Wert /Delhi.
  4. Prüfen Sie jetzt, ob im ProxyEndpoint bedingte Datenflüsse vorhanden sind.
  5. Wenn es keine bedingten Flüsse oder einige nicht bedingte Datenflüsse gibt, gehen Sie zum Nächster Grund – API-Proxy nicht in einer Umgebung bereitgestellt
  6. Wenn ProxyEndpoint nur bedingte Datenflüsse hat, prüfen Sie Folgendes: <ph type="x-smartling-placeholder">
      </ph>
    1. Wenn die Bedingungen in all diesen bedingten Datenflüssen eine bestimmte proxy.pathsuffix (Pfad nach dem Basispfad).
    2. Und wenn die in der API-Anfrage-URL angegebene path suffix mit keinem der ist das die Ursache für den Fehler.
  7. Angenommen, es gibt zwei Abläufe in ProxyEndpoint, die beide bedingten Datenflüssen wie unten gezeigt: 
    <Condition>(proxy.pathsuffix MatchesPath "/Bangalore") and (request.verb = "GET")</Condition>

<Condition>(proxy.pathsuffix MatchesPath "/Chennai") and (request.verb = "GET")</Condition>
    <ph type="x-smartling-placeholder">
      </ph>
    1. Im obigen Beispiel haben wir zwei bedingte Datenflüsse, einer, die mit proxy.pathsuffix (Pfad nach dem Basispfad) zu /Bangalore und den die andere stimmt mit /Chennai überein. Es gibt aber keine Übereinstimmungen mit /Delhi Dabei handelt es sich um die path suffix, die in der API-Anfrage-URL übergeben wurde.
    2. Dies ist die Ursache für den Fehler 404. Daher wird Ihnen der folgende Fehler 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 Datenflüsse in Ihrem Proxy-Endpunkt entspricht.
  2. Im obigen Beispiel können Sie den Fehler folgendermaßen beheben: <ph type="x-smartling-placeholder">
      </ph>
    1. Wenn Sie einen bestimmten Satz von Richtlinien für den Pfad /Delhi ausführen möchten, Fügen Sie dann einen separaten Ablauf mit den erforderlichen Richtlinien hinzu und stellen Sie sicher, dass eine Bedingung das dem /proxy.pathsuffix-/Delhi entspricht, wie unten gezeigt: 
      <Condition>(proxy.pathsuffix MatchesPath "/Delhi") and (request.verb = "GET")</Condition>
    2. Wenn Sie allgemeine Richtlinien für den Pfad /Delhi ausführen möchten, muss eine Bedingung vorhanden sein, die eine allgemeine /proxy.pathsuffix. Das heißt, alle Pfade nach basepath sind zulässig. /weather, wie unten gezeigt: 
      <Condition>(proxy.pathsuffix MatchesPath "/**") and (request.verb = "GET")</Condition>

Wenn ProxyEndpoint die richtige basepath und die path suffix hat, die in der API-URL angegeben sind mit einem der bedingten Datenflüsse übereinstimmt, und fahren dann mit der nächsten Ursache fort: Der API-Proxy wurde nicht in einer Umgebung bereitgestellt.

Ursache: API-Proxy nicht in einer Umgebung bereitgestellt

Diagnose

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

    Nehmen wir zum Beispiel die folgende Konfiguration an:

    • Wenn http://myorg-prod.apigee.net/weather Ihre URL ist, dann ist myorg-prod.apigee.net der Host-Alias.
    • Der Host-Alias myorg-prod.apigee.net ist als Teil eines der virtuelle Hosts in der prod-Umgebung Ihrer Organisation.
  2. Überprüfen Sie, ob der API-Proxy in der spezifischen Umgebung bereitgestellt ist, die in den Schritt 1 oben.
  3. Wenn der API-Proxy nicht in der spezifischen Umgebung bereitgestellt ist, ist das der Grund Fehler 404.
    1. Nehmen wir also in dem Beispiel in Schritt 1 oben an, dass der API-Proxy nicht im prod-Umgebung hat, ist das die Ursache für den Fehler.
    2. Gehen Sie zum Abschnitt Lösung unten.
  4. Wenn der API-Proxy in der spezifischen Umgebung bereitgestellt wurde, fahren Sie mit der nächsten Ursache fort: <ph type="x-smartling-placeholder"></ph> Umgebung nicht in Message Processor geladen

Auflösung

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

Ursache: Umgebung wurde nicht in Message Processor geladen

Diagnose

  1. Melden Sie sich bei jedem der Message Processors an und prüfen Sie, ob die spezifische Umgebung, in der Sie die die API-Anfrage stellen, wird mit dem folgenden Befehl in den Message Processor geladen: 
    curl -v 0:8082/v1/runtime/organizations/<orgname>/environments
  2. Wenn die spezifische Umgebung als Teil des obigen Befehls aufgeführt ist, fahren Sie mit der nächsten Ursache fort: <ph type="x-smartling-placeholder"></ph> Der API-Proxy wurde nicht auf einem oder mehreren Message Processorn bereitgestellt.
  3. Wenn die spezifische Umgebung nicht aufgeführt ist, /opt/apigee/var/log/edge-message-processor/logs/system.log und /opt/apigee/var/log/edge-message-processor/logs/startupruntimeerrors.log am Message Processor für Fehler beim Laden von Umgebungen.
  4. Es kann viele verschiedene Fehler geben, die dazu führen können, dass eine Umgebung Message Processor. Die Lösung hängt vom aufgetretenen Fehler ab.

Auflösung

Die Umgebung wird möglicherweise aus vielen Gründen nicht in den Message Processor geladen. Dieser Abschnitt zeigt einige mögliche Gründe für dieses Problem auf und erklärt, wie sich diese lösen lassen das Problem zu lösen.

  1. Wenn Sie einen der folgenden Fehler im Message Processor-Protokoll sehen, wird er durch eine Es wurde ein Problem mit den Zertifikaten/Schlüsseln festgestellt, die dem angegebenen Schlüsselspeicher/Truststore hinzugefügt wurden. in der angegebenen Umgebung.

    Fehler Nr. 1: java.security.KeyStoreException: cannot override 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: 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
  2. Rufen Sie die Details zum Schlüsselspeicher/Truststore ab, der in der Fehlermeldung angegeben ist, die in der vorherigen Schritt mithilfe des folgenden Verwaltungs-API-Aufrufs ausführen: 
    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 im Truststore zwei Zertifikate und ein Schlüssel vorhanden sind myTruststore Der Truststore enthält im Allgemeinen keinen Schlüssel. Ist dies der Fall, besser ein einzelnes Zertifikat und einen Schlüssel.
  4. Rufen Sie die Details zu den beiden Zertifikaten mithilfe 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 finden Sie heraus, welches abgelaufene/ältere Zertifikat abgelaufen ist.
  6. Löschen Sie das abgelaufene oder unerwünschte Zertifikat aus dem Truststore myTruststore.

Wenn das Problem weiterhin besteht oder ein anderer als der in Schritt 1 genannte Fehler auftritt Weitere Informationen finden Sie unter Diagnoseinformationen müssen erfasst werden.

Ursache: API-Proxy nicht die auf einem oder mehreren Message Processorn bereitgestellt werden

Der API-Proxy darf nicht auf einem oder mehreren Message Processorn bereitgestellt werden. Dieses Problem tritt sehr selten und geschieht meist aufgrund einer fehlenden Ereignisbenachrichtigung vom Management Server Message Processor während der Bereitstellung des jeweiligen API-Proxys. In diesem Fall werden Sie auch die Ablaufverfolgungssitzung in der Edge-Benutzeroberfläche nicht erstellen.

Diagnose

  1. Melden Sie sich bei jedem der Message Processors an und prüfen Sie, ob die spezifische Version des Der API-Proxy wird mit dem folgenden Befehl bereitgestellt oder nicht: 
    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 Befehls angezeigt wird und starten Sie dann den Message Processor neu, wie in den Lösung.
  3. Wiederholen Sie die Schritte 1 bis 2 für alle Message Processor.
  4. Wenn die spezifische Version des API-Proxys auf allen Message Processors bereitgestellt wird, gilt Folgendes: ist das nicht die Ursache des Problems. Gehe zu <ph type="x-smartling-placeholder"></ph> Diagnosedaten müssen erfasst werden.

Auflösung

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

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

Probleme mithilfe von API-Monitoring diagnostizieren

Mit dem API-Monitoring können Sie Problembereiche schnell erkennen. zur Diagnose von Fehlern, Leistungs- und Latenzproblemen und ihrer Ursache, z. B. Entwickler-Apps, API-Proxys, Back-End-Ziele oder die API-Plattform.

Rufen Sie für dieses Problem den Bereich API-Monitoring > Seite „Untersuchen“ und das entsprechende Datum, Proxy usw. auswählen. Möglicherweise werden die folgenden Details angezeigt:

Fehlercode und Statuscode in der Benutzeroberfläche

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

Darüber hinaus können Sie wie im Screenshot oben gezeigt auf Logs ansehen klicken und dann weiter nachsehen.

Logs aufrufen

Schritt durch ein Beispielszenario, in der gezeigt wird, wie Sie Beheben Sie 5xx-Probleme mit Ihren APIs mithilfe von API-Monitoring. Zum Beispiel können Sie möchten Sie eine Warnung einrichten, damit Sie informiert werden, wenn die Anzahl der 404-Statuscodes einen bestimmten Schwellenwerts.

Erfassen von Diagnoseinformationen erforderlich

Wenn das Problem trotz Befolgung der Anleitung oben weiterhin besteht, folgenden Diagnoseinformationen folgen. Teilen Sie diese Informationen dem Apigee Edge-Support mit.

  1. Wenn Sie ein Nutzer der öffentlichen Cloud sind, geben Sie die folgenden Informationen an: <ph type="x-smartling-placeholder">
      </ph>
    • Name der Organisation
    • Name der Umgebung
    • Name des API-Proxys
    • Führen Sie den curl-Befehl aus, um den Fehler zu reproduzieren.
  2. Wenn Sie ein Nutzer der Private Cloud sind, geben Sie die folgenden Informationen an: <ph type="x-smartling-placeholder">
      </ph>
    • Vollständige Fehlermeldung erkannt
    • Name der Umgebung
    • API-Proxy-Bundle
    • Message Processor-Logs /opt/apigee/var/log/edge-message-processor/logs/system.log
    • Ausgabe der folgenden Befehle für jeden Message Processor. 
      • 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 in diesem Playbook Sie ausprobiert haben und welche anderen Erkenntnisse hilft uns dabei, dieses Problem schnell zu lösen.