404 Ana makine için proxy tanımlanamadı: <virtual host name> and url: <path>

Apigee Edge belgelerini görüntülüyorsunuz.
. Git: Apigee X belgeleri. bilgi

Belirti

İstemci uygulaması şu mesajla birlikte 404 HTTP durum kodunu alır: Not Found ve hata mesajı Unable to identify proxy for host: VIRTUAL_HOST and url: PATH yanıt olarak yeniden geliştiriyoruz.

Bu hata, Edge'in belirtilen sanal ana makine ve yol için API proxy'sini bulamadığı anlamına gelir.

Hata Mesajı

Aşağıdaki HTTP durum kodunu alırsınız: 

HTTP/1.1 404 Not Found

Ayrıca, aşağıda gösterilene benzer bir hata mesajı da görürsünüz: 

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

Yukarıdaki hata mesajı, Edge'in default sanal ana makine ve /oauth2/token yolu.

Olası Nedenler

Bu hatanın olası nedenlerinden bazıları aşağıda listelenmiştir:

Neden Açıklama Şunun için geçerli sorun giderme talimatları:
API proxy'si belirli bir sanal ana makineyle ilişkilendirilmemiş İlgili API proxy'si, sanal ana makinede istekleri kabul edecek şekilde yapılandırılmamış hata iletisinde belirtilmiş olmalıdır. Edge Herkese Açık ve Private Cloud kullanıcıları
API proxy'sinin yeni dağıtılan bir düzeltmesinde sanal ana makine kaldırıldı İstemci hâlâ etkinken yeni dağıtılan düzeltmeden sanal ana makineyi kaldırma kullanılması bu soruna neden olabilir. Edge Herkese Açık ve Private Cloud kullanıcıları
Yol herhangi bir API proxy'siyle ilişkili değil İlgili API proxy'si belirtilen yoldaki istekleri kabul edecek şekilde yapılandırılmamış yazın. Edge Herkese Açık ve Private Cloud kullanıcıları
API proxy'si bir ortamda dağıtılmıyor İlgili API proxy'si, bulunduğunuz ortamda dağıtılmıyor yapmaya çalışıyor diyelim. Edge Herkese Açık ve Private Cloud kullanıcıları
Ortam, Mesaj İşleyici'ye yüklenmedi Belirli bir ortamda (API isteklerinde bulunmaya çalıştığınız ortam) bir hata nedeniyle Mesaj İşleyicilerine yüklenmiştir. Edge Private Cloud kullanıcıları
API proxy'si bir veya daha fazla Mesaj İşleyicide dağıtılmadı API proxy'si, eksik olduğu için bir veya daha fazla İleti İşleyicide dağıtılamıyor olabilir etkinlik bildirimi almalısınız. Edge Private Cloud kullanıcıları

Sık kullanılan teşhis adımları

NGINX ve İleti İşleyici günlükleri, 404 hatasının giderilmesinde yardımcı olacaktır. Günlükleri kontrol etmek için aşağıdaki adımları uygulayın:

  1. Aşağıdaki komutu kullanarak NGINX günlüklerini görüntüleyin: 
    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
    .
  2. Günlük girişlerinde aşağıdaki alanları kontrol edin:
    Alan Değer
    Upstream_status, status 404
    X-Apigee-fault-code messaging.adaptors.http.flow.ApplicationNotFound

    Günlüklerdeki ileti kimliğini not edin.

  3. İleti İşleyici günlüklerini kontrol etme (/opt/apigee/var/log/edge-message-processor/logs/system.log) belirli API için messaging.adaptors.http.flow.ApplicationNotFound kullanıyorsanız veya API isteği için 2. adımdaki mesaj kimliği.

    İleti İşleyici günlüğündeki örnek hata iletisi

    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)

    Yukarıdaki günlükte hata kodu gösterilmektedir. Hata mesajı şöyledir:

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

Neden: API proxy'si ilgili sanal ana makineyle ilişkilendirilmemiş

API proxy'si ilgili sanal ana makineden gelen istekleri kabul edecek şekilde yapılandırılmamışsa şu hata mesajını içeren bir 404 Not Found yanıtı alabiliriz: Unable to identify proxy for host: VIRTUAL_HOST and url: PATH.

Teşhis

  1. API proxy'si için Proxy Uç Noktası yapılandırmasını kontrol edin ve API proxy'sinin hatada belirtilen sanal ana makine için istekleri kabul edecek şekilde yapılandırıldı. Bu VirtualHost öğesiyle gösterilir. ProxyEndpoint örneğini inceleyelim en iyi uygulamaları görelim.

    API proxy'sinin güvenli sanal ana makine

  2. Sanal ana makinelerin belirli bir ortamda aşağıdaki gibi tanımlandığını varsayalım:
    Ad Bağlantı noktası Ana Makine Takma Adı
    default 80 myorg-prod.apigee.net
    secure 443 myorg-prod.apigee.net
  3. default VirtualHost için URL'yi kullanarak API isteğinde bulunursunuz http://myorg-prod.apigee.net/weather
  4. ProxyEndpoint, aşağıda gösterildiği gibi default VirtualHost içermediğinden örnekte, 404 yanıt kodunu şu hata mesajıyla alıyorsunuz: 
    {"fault":{"faultstring":"Unable to identify proxy for host: default and url: \/weather","detail":{"errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"}}}
  5. Bu sorunu gidermek için aşağıdaki Çözüm bölümüne gidin.
  6. ProxyEndpoint, default üzerindeki istekleri kabul edecek şekilde yapılandırılmışsa VirtualHost, bir sonraki hedefe git - Yol herhangi bir API proxy'siyle ilişkili değil.

Çözünürlük

  1. Eksik VirtualHost değerini ProxyEndpoint yapılandırmasına ekleyin ve ele alacağız. Yukarıda gösterilen örnek için varsayılan VirtualHost değerini ekleyebilirsiniz. şu şekilde ProxyEndpoint yapılandırmasına uygulayın: 
    <VirtualHost>default</VirtualHost>

    Varsayılanı gösteren örnek Proxy Uç noktası yapılandırması> VirtualHost&gt; ekleniyor

  2. Alternatif olarak, yukarıda bahsedilen örnekte yalnızca Bu API proxy'si için secure VirtualHost, ardından API isteklerini yapın HTTPS protokolü kullanılarak yalnızca secure VirtualHost: 
    https://myorg-prod.apigee.net/weather

Neden: API proxy'sinin yeni dağıtılan bir düzeltmesinde sanal ana makine kaldırıldı

Belirli bir sanal ana makine kaldırıldıktan sonra API proxy'sinin yeni bir revizyonu dağıtılırsa (bu, daha önce dağıtılan düzeltmenin bir parçasıydı) istemciler tarafından kullanılmaya devam ediyor. kullanırsanız bu soruna neden olabilir.

Teşhis

  1. API proxy'sinin şu anda etkin olup olmadığını görmek için API proxy'sinin Proxy Uç Noktası yapılandırmasını kontrol edin hatada belirtilen sanal ana makine için istekleri kabul edecek şekilde yapılandırıldı. Bu ProxyEndpoint yapılandırmasındaki VirtualHost öğesi ile gösterilir.
  2. Hatada belirtilen sanal ana makine ProxyEndpoint içinde yoksa yapılandırmanın ardından aşağıdaki adımları uygulayın. Aksi takdirde, bir sonraki nedene gidin: Yol herhangi bir API proxy'siyle ilişkili değil.
  3. Daha önce dağıtılan düzeltmenin ProxyEndpoint yapılandırmasını şu anki ile karşılaştır dağıtılan düzeltme.
    1. Örneğin, daha önce dağıtılan düzeltmenizin 5 olduğunu ve şu anda dağıtılmış olan düzeltme 6:
      • 5. düzeltmedeki Proxy Uç Noktasında yapılandırılmış Sanal Ana Makineler
        • <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>vh1</VirtualHost>
</HTTPProxyConnection>
      • 6. düzeltmedeki Proxy Uç Noktasında yapılandırılmış Sanal Ana Makineler
        • <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>
    2. Yukarıdaki örnekte VirtualHost vh1, revision 5, içinde vardı ancak revision 6 ürününden kaldırılıp VirtualHost secure ile değiştirildi.
    3. Bu nedenle siz veya müşterileriniz VirtualHost vh1 (revision 5 öğesinin bir parçasıydı) şunu alırsınız: Şu hata mesajını içeren 404 yanıt kodu: 
      {"fault":{"faultstring":"Unable to identify proxy for host: vh1 and url: \/weather","detail":{"errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"}}}
  4. Sanal ana makine değişikliğinin kasıtlı olarak yapılıp yapılmadığını kontrol edin. halihazırda dağıtılmış olan düzeltmede kasıtsız olarak Çözüm bölümünde açıklandığı şekilde gerekli önlemleri alın.

Çözünürlük

Sanal ana makinenin veya ana makinelerin yeni bir düzeltmede kaldırıldığını tespit ederseniz bu durum bilinçli olarak veya kaza. Her durumda, sorunu çözmek için aşağıdaki çözümü/önerilen adımları uygulayın.

1. Senaryo: Kasıtlı Değişim

Sanal ana makine kaldırma işlemini kasıtlı olarak yaptıysanız aşağıdakilerden birini seçebilirsiniz seçenekleri vardır.

  1. Farklı bir temel yola sahip yeni bir proxy oluşturma ve farklı bir sanal ana makine kullanma (bu, daha önce dağıtılan düzeltmede mevcut değildir).

  2. Mevcut API proxy'sini kullanmaya devam etmek ancak farklı bir sanal ana makine kullanmak istiyorsanız mevcut sanal ana makineyi tutmak ve ilave sanal ana makine eklemek daha iyidir.

    Bu sayede, ilgili API proxy'si kullanıcıları değişiklikten etkilenmez.

  3. Mevcut API proxy'sini kullanmak ve yalnızca farklı bir sanal ana makineye sahip olmak istiyorsanız kullanıcılarınızı önceden bilgilendirin ve bakım döneminde bu değişikliği yapın.

    Böylece, söz konusu API proxy'sini kullananlar bu değişiklikten haberdar olur ve bu API proxy'sine çağrı yapmak için farklı bir sanal ana makine kullanabilir. Dolayısıyla, değişiklikten etkilenmeyeceğini belirtir.

2. Senaryo: İstemsiz Değişim

Sanal ana makine kaldırma işleminin yanlışlıkla ve bilinçli olarak yapılmaması durumunda aşağıdakileri yapın:

  1. Şu anda dağıtılmış olan düzeltmedeki ProxyEndpoint yapılandırmasını daha önce dağıtılan düzeltmede kullanılanlarla aynı sanal ana makineler arasındadır. aşağıdaki bölümü değiştirin: 
    <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>
    .

    -

    <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>vh1</VirtualHost>
</HTTPProxyConnection>
  2. Düzeltmeyi yeniden dağıtın.

En iyi uygulamalar

Bakım süresince her zaman yeni proxy'lerin veya yeni revizyonların dağıtılması önerilir dağıtım sırasında ortaya çıkan herhangi bir sorunun gerçekleşebileceği şekilde, trafiğin en az veya trafik üzerindeki etkisi en aza indirilebilir.

Neden: Yol herhangi bir API proxy'si ile ilişkilendirilmemiş

API proxy'si, bağlantıda kullanılan belirli yola ilişkin istekleri kabul edecek şekilde yapılandırılmamışsa API İstek URL'si ise hata mesajıyla birlikte bir 404 Not Found yanıtı alabiliriz. Unable to identify proxy for host: VIRTUAL_HOST and url: PATH.

Teşhis

  1. Amaçladığınız API proxy'si için ProxyEndpoint yapılandırmasına bakın API isteklerinde bulunun.
  2. API proxy'sinin belirtilen yol için istekleri kabul edecek şekilde yapılandırılıp yapılandırılmadığını kontrol edin yazın. Bunu yapmak için 1. Senaryo ve 2. senaryo.

1. Senaryo: Yol, API proxy'sinin temel yoluyla eşleşmiyor

  1. Hata mesajında belirtilen path, basepath ile aynı değilse API proxy'si veya basepath ile başlamazsa bu hatanın nedeni olabilir.
  2. Bunu açıklamak için bir örnek verelim:
    1. Amaçlanan API proxy'sinin basepath değeri /weather
    2. API İsteği URL'si: https://myorg-prod.apigee.net/climate. Bunun anlamı, API isteği URL'sinde kullanılan yol: /climate.
  3. Bu örnekte, path, basepath ile aynı değildir ve basepath ile başlamaz. Bu nedenle şu hatayı alırsınız: 
    {
   "fault":{
      "faultstring":"Unable to identify proxy for host: secure and url: \/climate",
      "detail":{
         "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
      }
   }
}
    .

Çözünürlük

  1. API istek URL'nizde kullanılan path değerinin basepath ile aynı olduğundan emin olun tercih edebilirsiniz.
  2. Yukarıdaki örnekte, API İstek URL'si aşağıdaki gibi olmalıdır: 
    {
https://myorg-prod.apigee.net/weather
    .

2. Senaryo: Yol, kullanılabilir koşullu akışlardan hiçbiriyle eşleşmiyor

  1. API İstek URL'sinde kullanılan path, basepath ile başlıyorsa path suffix ( basepath), akışı söz konusu olursa bu, 404 hatasına neden olabilir.
  2. Bunu açıklamak için bir örnek verelim:
    1. Amaçlanan API proxy'sinin basepath değeri /weather
    2. API İsteği URL'si: https://myorg-prod.apigee.net/weather/Delhi. Bunun anlamı şudur: API isteği URL'sinde kullanılan yol /weather/Delhi.
  3. Bu örnekte path, basepath /weather ile başlıyor. Ayrıca path suffix /Delhi değerine sahip.
  4. Şimdi ProxyEndpoint içinde koşullu akış olup olmadığını kontrol edin.
  5. Koşullu akış yoksa veya koşullu olmayan birkaç akış varsa sonraki neden - API proxy'si bir ortamda dağıtılmıyor.
  6. ProxyEndpoint yalnızca koşullu akışlara sahipse aşağıdakileri kontrol edin:
    1. Tüm bu koşullu akışların koşulları, belirli bir proxy.pathsuffix (temel yoldan sonraki yol).
    2. API İstek URL'sinde belirtilen path suffix, bu durum hatanın nedenidir.
  7. ProxyEndpoint içinde iki akışımız olduğunu varsayalım ve her ikisinin de koşullu akışlar vardır: 
    <Condition>(proxy.pathsuffix MatchesPath "/Bangalore") and (request.verb = "GET")</Condition>

<Condition>(proxy.pathsuffix MatchesPath "/Chennai") and (request.verb = "GET")</Condition>
    1. Yukarıdaki örnekte, biri eşleşen proxy.pathsuffix (temel yoldan sonraki yol) ile /Bangalore ve diğeri /Chennai ile eşleşiyor. Ancak /Delhi ile eşleşen yok Bu, API İstek URL'sinde geçirilen path suffix değeridir.
    2. 404 hatasının nedeni budur. Bu nedenle şu hatayı alırsınız: 
      {
   "fault":{
      "faultstring":"Unable to identify proxy for host: secure and url: \/weather\/Delhi",
      "detail":{
         "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
      }
   }
}
      .

Çözünürlük

  1. path suffix öğesinin, proxy uç noktanızdaki koşullu akışlardan en az biriyle eşleştiğinden emin olun.
  2. Yukarıdaki örnekte, hatayı gidermek için aşağıdaki yaklaşımlardan yararlanabilirsiniz:
    1. /Delhi yolunda belirli bir politika grubunu yürütmek isterseniz Ardından gerekli politika grubuyla ayrı bir akış ekleyin ve aşağıdaki gibi /proxy.pathsuffix /Delhi ile eşleşen: 
      <Condition>(proxy.pathsuffix MatchesPath "/Delhi") and (request.verb = "GET")</Condition>
    2. /Delhi yolu için ortak politika grubunu uygulamak istiyorsanız genel akışa izin veren bir koşul olduğundan emin olun. /proxy.pathsuffix. Yani, basepath etiketinden sonraki her yola izin verir Aşağıda gösterildiği gibi /weather: 
      <Condition>(proxy.pathsuffix MatchesPath "/**") and (request.verb = "GET")</Condition>

ProxyEndpoint, API URL'sinde doğru basepath ve path suffix değerini belirtiyorsa koşullu akışlardan biriyle eşleştiğini ve ardından bir sonraki nedene geçer. API proxy'si bir ortamda dağıtılmıyor.

Neden: API proxy'si bir ortamda dağıtılmadı

Teşhis

  1. API istek URL'nizde kullanılan ana makine takma adının bulunduğu ortamı belirleyin. Bu işlem, ortamların her birindeki tüm sanal ana makinelerin ayrıntılarını kontrol edilerek yapılabilir. kuruluşunuzun fark etmelerinden haberdar olmanız gerekir.

    Örneğin, aşağıdaki yapılandırmayı varsayalım:

    • Eğer http://myorg-prod.apigee.net/weather. URL'niz ise myorg-prod.apigee.net, ana makine takma adıdır.
    • myorg-prod.apigee.net ana makine takma adı, kuruluşunuzun prod ortamındaki sanal ana makineler.
  2. İlgili API proxy'sinin şurada belirlenen belirli bir ortamda dağıtılıp dağıtılmadığını kontrol edin: Yukarıdaki 1. adıma bakın.
  3. API proxy'si belirli bir ortamda dağıtılmazsa 404 hatası.
    1. Yukarıdaki 1. adımda kullanılan örnekte API proxy'sinin prod ortamı söz konusuysa hatanın nedeni budur.
    2. Aşağıdaki Çözünürlük bölümüne gidin.
  4. API proxy'si belirli bir ortamda dağıtılmışsa sonraki nedene gidin: Ortam, mesaj işlemcilerinde yüklenmedi.

Çözünürlük

API proxy'sini, API isteklerinde bulunmak istediğiniz belirli bir ortama dağıtın.

Neden: Ortam, İleti İşleyenlerine yüklenmedi

Teşhis

  1. İleti İşleyicilerin her birine giriş yapın ve iletileriniz üzerinde çalıştığınız belirli bir ortamın aşağıdaki komutu kullanarak API isteğinin Mesaj İşleyici'ye yüklenmesini sağlayabilir: 
    curl -v 0:8082/v1/runtime/organizations/<orgname>/environments
    .
  2. Söz konusu ortam yukarıdaki komutun parçası olarak listeleniyorsa sonraki nedene gidin: API proxy'si bir veya daha fazla Mesaj İşleyicide dağıtılmadı.
  3. Söz konusu ortam listede yoksa /opt/apigee/var/log/edge-message-processor/logs/system.log ve /opt/apigee/var/log/edge-message-processor/logs/startupruntimeerrors.log Ortamların yüklenmesi sırasında oluşan hatalar için Mesaj İşlemcileri.
  4. Mesaj İşleyen. Çözüm oluşan hataya bağlıdır.

Çözünürlük

Ortam, birçok nedenden dolayı Mesaj İşleyici'ye yüklenmeyebilir. Bu bölüm bu soruna yol açabilecek birkaç olası nedeni gösteriyor ve düşünmesi gerekir.

  1. İleti İşleyen günlüğünde aşağıdaki hatalardan birini görürseniz bunun nedeni bir belirtilen anahtar deposuna/güvenilir depoya eklenen sertifikalarla/anahtarlarla ilgili sorun bulundu belirtilen ortamda gönderin.

    Hata 1: java.security.KeyStoreException: Kendi sertifikanın üzerine yazılamaz

    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

    Hata 2: java.security.KeyStoreException: Gizli anahtarın üzerine yazılamıyor

    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. önceki adımına geçmek için aşağıdaki management API çağrısını kullanın: 
    curl -v "http://<management-IPaddress>:8080/v1/organizations/<org-name>/environments/<env-name>/keystores/myTruststore" -u <user>

    Örnek çıkış:

    {
   "certs":[
      "mycert",
      "mycert-new"
   ],
   "keys":[
      "mycert"
   ],
   "name":"myTruststore"
}
  3. Örnek çıktı, güven deposunda iki sertifika ve bir anahtar olduğunu gösteriyor myTruststore Truststore genellikle bir anahtar içermez. Böyle bir durumda, tek bir sertifika ve tek bir anahtara sahip olmak daha iyidir.
  4. Aşağıdaki API'yi kullanarak iki sertifikayla ilgili ayrıntıları öğrenin: 
    curl -s http://<management-IPaddress>:8080/v1/runtime/organizations/<org-name>/environments/<env-name>/keystores/<keystore-name>/certs/<cert-name>
    .
  5. Her sertifikanın geçerlilik bitiş tarihini kontrol edin ve süresi dolmuş/eski sertifikayı belirleyin.
  6. Süresi dolmuş veya istenmeyen sertifikayı myTruststore güven deposundan silin.

Sorun devam ederse veya 1. adımda belirtilenler dışında bir hata görürseniz Yukarıdaki Teşhis bilgileri toplanmalıdır'a gidin.

Neden: API proxy'si değil bir veya daha fazla Mesaj İşlemcisine dağıtılarak

API proxy'si, bir veya daha fazla Mesaj İşleyiciye dağıtılamaz. Bu sorun, nadiren ve çoğunlukla Yönetim Sunucusu’ndan gelen ve Belirli API proxy'sinin dağıtımı sırasında İleti İşleyici. Bu durumda ayrıca, Edge kullanıcı arayüzünde izleme oturumu oluşturulamıyor.

Teşhis

  1. İleti İşlemcilerinin her birine giriş yapın ve API proxy'si şu komut kullanılarak dağıtıldı veya kullanılmıyor: 
    curl -v 0:8082/v1/runtime/organizations/<orgname>/environments/<envname>/apis/<apiname>/revisions
    .
  2. API proxy'sinin ilgili düzeltmesi, komutun çıkışı olarak görünmüyorsa seçin, ardından ilgili Mesaj İşleyici'yi aşağıda açıklandığı şekilde yeniden başlatın: Çözüm.
  3. Tüm Mesaj İşleyicileri için 1-2. adımları tekrarlayın.
  4. API proxy'sinin ilgili düzeltmesi tüm Mesaj İşleyicilerine dağıtıldıysa Bu sorunun nedeni bu değildir. sayfasına gidin. Teşhis bilgileri toplanmalıdır.

Çözünürlük

API proxy'sinin ilgili revizyonunun uygulanacağı Mesaj İşleyicileri yeniden başlatın. dağıtılmadı.

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

API Monitoring'i kullanarak sorunları teşhis etme

API İzleme, sorunlu alanları hızlı bir şekilde izole etmenizi sağlar hata, performans ve gecikme sorunlarını ve bunların kaynağını (ör. geliştirici uygulamaları) teşhis etmek için API proxy'leri, arka uç hedefleri veya API platformu.

Bu sorun için API Monitoring > İnceleme sayfası ve uygun tarihi, proxy'yi ve benzeri öğeleri seçtiğinizde aşağıdaki ayrıntıları görebilirsiniz:

Kullanıcı arayüzünde hata kodu ve durum kodu

  • Hata Kodu: messaging.adaptors.http.flow.ApplicationNotFound
  • Durum Kodu: 404
  • Hata Kaynağı: Apigee veya MP

Ayrıca, yukarıdaki ekran görüntüsünde gösterildiği gibi Günlükleri görüntüle'yi tıklayıp daha ayrıntılı bilgi edinebilirsiniz.

günlükleri görüntüle

Örnek senaryoda ilerle API Monitoring'i kullanarak API'lerinizle ilgili 5xx sorunlarını giderin. Örneğin, eğitime 404 durum kodlarının sayısı karar verebilirsiniz.

Teşhis bilgileri toplanmalıdır

Yukarıdaki talimatları uygulamanıza rağmen sorun devam ederse teşhis bilgilerini ele alalım. Apigee Edge Destek Ekibi ile iletişime geçip bu bilgileri paylaşın.

  1. Herkese Açık Bulut kullanıcısıysanız aşağıdaki bilgileri sağlayın:
    • Kuruluş adı
    • Ortam adı
    • API proxy'si adı
    • Hatayı yeniden oluşturmak için curl komutunu tamamlayın
  2. Private Cloud kullanıcısıysanız aşağıdaki bilgileri sağlayın:
    • Tam hata mesajı görüntülendi
    • Ortam adı
    • API proxy paketi
    • Mesaj İşleyici günlükleri /opt/apigee/var/log/edge-message-processor/logs/system.log
    • Mesaj İşleyicilerin her birinde aşağıdaki komutların çıkışı. 
      • curl -v 0:8082/v1/runtime/organizations/<orgname>/environments
      curl -v 0:8082/v1/runtime/organizations/<orgname>/environments/<envname>/apis/<apiname>/revisions
  3. Bu başucu kitabının hangi bölümlerini denediğiniz ve sizin de başarılı olduğunuz bu sorunu hızlıca çözmemize yardımcı olacaktır.