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

Apigee Edge belgelerini görüntülüyorsunuz.
Apigee X belgelerine gidin. bilgi

Belirti

İstemci uygulaması, API çağrılarına yanıt olarak Not Found mesajını ve Unable to identify proxy for host: VIRTUAL_HOST and url: PATH hata mesajını içeren 404 HTTP durum kodunu alır.

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ğıdakine benzer bir hata mesajıyla karşılaşı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 makinesi ve /oauth2/token yolu için API proxy'sini bulamadığını belirtir.

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şkili değil	İlgili API proxy'si, hata mesajında belirtilen sanal ana makinede istekleri kabul edecek şekilde yapılandırılmamış.	Edge Herkese Açık ve Özel Bulut kullanıcıları
Yeni dağıtılan bir API proxy düzeltmesinde sanal ana makine kaldırıldı	İstemci hâlâ belirli sanal ana bilgisayarı kullanırken sanal ana makinenin yeni dağıtılan düzeltmeden kaldırılması bu soruna neden olabilir.	Edge Herkese Açık ve Özel Bulut kullanıcıları
Yol, herhangi bir API proxy'si ile ilişkili değil	İlgili API proxy'si, hata mesajında belirtilen yoldaki istekleri kabul edecek şekilde yapılandırılmamış.	Edge Herkese Açık ve Özel Bulut kullanıcıları
API proxy'si bir ortamda dağıtılmamış	İlgili API proxy'si, API istekleri göndermeye çalıştığınız belirli ortamda dağıtılmamış.	Edge Herkese Açık ve Özel Bulut kullanıcıları
Mesaj İşleyici'ye ortam yüklenmedi	API isteklerini göndermeye çalıştığınız belirli ortam, bir hata nedeniyle Mesaj İşleyicilere yüklenmemiştir.	Edge Private Cloud kullanıcıları
API proxy'si bir veya daha fazla Mesaj İşleyicide dağıtılmadı	API proxy'si, dağıtım sırasında etkinlik bildiriminin olmaması nedeniyle bir veya daha fazla Mesaj İşleyiciye dağıtılamayabilir.	Edge Private Cloud kullanıcıları

Yaygın teşhis adımları

NGINX ve Mesaj İş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. Belirli bir API için messaging.adaptors.http.flow.ApplicationNotFound bilginizin olup olmadığını veya API isteği için 2. adımdaki benzersiz mesaj kimliğine sahip olup olmadığınızı öğrenmek amacıyla Message Processor günlüklerini kontrol edin (/opt/apigee/var/log/edge-message-processor/logs/system.log)).

   İleti İşleyici günlüğünden örnek hata mesajı

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ı ise aşağıdaki gibidir:

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

Neden: API proxy'si belirli bir sanal ana makineyle ilişkili değil

API proxy'si, belirli bir sanal ana makine için 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'sinin 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ılıp yapılandırılmadığını kontrol edin. Bu, VirtualHost öğesiyle belirtilir. Bunu anlamak için örnek bir ProxyEndpoint yapılandırmasına göz atalım.

   API proxy'sinin güvenli bir sanal ana makinedeki istekleri kabul ettiğini gösteren örnek Proxy Uç Noktası yapılandırması

   

2. Sanal ana makinelerin belirli bir ortamda aşağıdaki gibi tanımlandığını varsayalım:

   Ad	Bağlantı noktası	Barındırıcı Takma Adı
   default	80	myorg-prod.apigee.net
   secure	443	myorg-prod.apigee.net

3. http://myorg-prod.apigee.net/weather URL'sini kullanarak default VirtualHost için API isteği yapıyorsunuz
4. ProxyEndpoint, yukarıdaki örnekte gösterildiği gibi default VirtualHost içermediğinden 404 yanıt kodunu aşağıdaki hata mesajıyla alırsınız:

   {"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 VirtualHost üzerinde istekleri kabul edecek şekilde yapılandırılmışsa sonraki nedene gidin: Herhangi bir API proxy'si ile ilişkili olmayan yol.

Çözünürlük

1. Sorunu gidermek için eksik VirtualHost öğesini ProxyEndpoint yapılandırmasına ekleyin. Yukarıda gösterilen örnekte, varsayılan VirtualHost değerini ProxyEndpoint yapılandırmasına aşağıdaki şekilde ekleyebilirsiniz:

   <VirtualHost>default</VirtualHost>

   Varsayılan> VirtualHost> eklenmeyi gösteren örnek Proxy Uç Noktası yapılandırması

   

2. Alternatif olarak, yukarıda bahsedilen örnekte bu belirli API proxy'si için yalnızca secure VirtualHost kullanmayı amaçladıysanız API isteklerini HTTPS protokolünü kullanarak yalnızca secure VirtualHost'a yapın:

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

Neden: Sanal ana makine, yeni dağıtılan bir API proxy düzeltmesinden kaldırıldı

Belirli bir sanal ana makine kaldırıldıktan sonra (önceden dağıtılan düzeltmenin parçası olan) yeni bir API proxy düzeltmesi dağıtılırsa bu düzeltme istemciler tarafından API istekleri yapmak için kullanılmaya devam ediyorsa bu soruna neden olabilir.

Teşhis

1. API proxy'sinin, hatada belirtilen sanal ana makine için istekleri kabul edecek şekilde yapılandırılıp yapılandırılmadığını görmek için API proxy'sine yönelik Proxy Uç Noktası yapılandırmasını kontrol edin. Bu, ProxyEndpoint yapılandırmasındaki VirtualHost öğesiyle belirtilir.
2. Hatada belirtilen sanal ana makine ProxyEndpoint yapılandırmasında yoksa aşağıdaki adımları uygulayın. Aksi takdirde, sonraki nedene geçin: Yol herhangi bir API proxy'si ile ilişkilendirilmemiş.
3. Önceden dağıtılan düzeltmenin ProxyEndpoint yapılandırmasını şu anda dağıtılan düzeltmeyle karşılaştırın.
   1. Örneğin, daha önce dağıtılan düzeltmenizin 5, şu anda dağıtılan düzeltmenizin de 6 olduğunu varsayalım:
      • Düzeltme 5'teki Proxy Uç Noktası'nda yapılandırılan Sanal Ana Makineler

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

      • Düzeltme 6'daki Proxy Uç Noktası'nda yapılandırılan 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 içinde kaldırıldı ve VirtualHost secure ile değiştirildi.
   3. Dolayısıyla, siz veya istemcileriniz bu API proxy'sine VirtualHost vh1 kullanarak (yani revision 5 kapsamında) istekte bulunuyorsanız aşağıdaki hata mesajını içeren 404 yanıt kodunu alırsınız:

      {"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, dağıtılmış olan düzeltmede kasıtlı olarak mı yoksa kasıtsız olarak mı yapıldığını kontrol edin ve Çözüm bölümünde açıklanan uygun ö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 kasıtlı veya kazara yapılmış olabilir. Her durumda, sorunu çözmek için aşağıdaki çözüm/önerilen adımları uygulayın.

1. Senaryo: İstemli Değişim

Sanal ana makineyi kasıtlı olarak kaldırıyorsanız aşağıdaki seçeneklerden birini tercih edebilirsiniz: İlk seçeneğin önerilen yaklaşım olmasıdır:

1. Farklı bir temel yola sahip yeni bir proxy oluşturun ve farklı bir sanal ana makine (önceden dağıtılan düzeltmede mevcut olmayan) kullanın.

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

   Bu sayede, bu API proxy'si kullanıcılarının değişiklikten etkilenmemesini sağlarsınız.

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

   Böylece bu API proxy'si kullanıcılarının değişiklikten haberdar olurlar ve bu API proxy'sine çağrı yapmak için farklı bir sanal ana makine kullanabilirler. Dolayısıyla bu mülkler değişiklikten etkilenmez.

2. Senaryo: İstemsiz Değişim

Sanal ana makinenin yanlışlıkla ve kasıtlı bir şekilde kaldırılmaması durumunda aşağıdakileri yapın:

1. Şu anda dağıtılmış olan düzeltmedeki ProxyEndpoint yapılandırmasını, önceden dağıtılan düzeltmede kullanılan sanal ana makineleri kullanacak şekilde güncelleyin. Yukarıdaki örnekte, aşağıdaki bölümü şu değerden 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

Dağıtım sırasında ortaya çıkabilecek sorunların önlenmesi veya trafik üzerindeki etkinin en aza indirilmesi için bakım döneminde veya trafiğin en az beklendiği zamanlarda yeni proxy'ler ya da yeni düzeltmeler dağıtmanız önerilir.

Neden: Yol herhangi bir API proxy'si ile ilişkili değil

API proxy'si, API İstek URL'sinde kullanılan belirli yol için 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 isteklerinde bulunmak istediğiniz API proxy'si için ProxyEndpoint yapılandırmasına bakın.
2. API proxy'sinin, hata mesajında belirtilen belirli yol için istekleri kabul edecek şekilde yapılandırılıp yapılandırılmadığını kontrol edin. Bunun için 1. Senaryo ve 2. Senaryo'daki adımları uygulayabilirsiniz.

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

1. Hata mesajında belirtilen path, ilgili API proxy'sinin basepath ile aynı değilse veya basepath ile başlamıyorsa hatanın nedeni bu olabilir.
2. Bunu açıklamak için bir örnek inceleyelim:
1. Amaçlanan API proxy'sinin basepath değeri /weather
2. API İstek URL'si: https://myorg-prod.apigee.net/climate. Bu, API isteği URL'sinde kullanılan yolun /climate. olduğu anlamına gelir.
3. Bu örnekte, path, basepath ile aynı değildir ve basepath ile başlamaz. Bu durumda aşağıdaki 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 isteği URL'nizde kullanılan path değerinin, ilgili API proxy'sinin basepath ile aynı olduğundan emin olun.
2. Yukarıdaki örnekte API istek URL'si aşağıdaki gibi olmalıdır:

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

2. Senaryo: Yol, mevcut koşullu akışların hiçbiriyle eşleşmiyor

1. API İsteği URL'sinde kullanılan path, basepath ile başlıyorsa hata mesajında belirtilen path suffix (basepath'dan sonra gelen bölüm) koşullu akışların hiçbiriyle eşleşmiyor olabilir. Bu durum 404 hatasına neden olabilir.
2. Bunu açıklamak için bir örnek inceleyelim:
   1. Amaçlanan API proxy'sinin basepath değeri /weather
   2. API İstek URL'si: https://myorg-prod.apigee.net/weather/Delhi. Bu, API isteği URL'sinde kullanılan yolun /weather/Delhi. olduğu anlamına gelir.
3. Bu örnekte path, basepath /weather ile başlar. Ayrıca, path suffix, /Delhi var.
4. Şimdi ProxyEndpoint içinde herhangi bir koşullu akış olup olmadığını kontrol edin.
5. Koşullu akış yoksa veya birkaç koşullu olmayan akış varsa bir sonraki neden olan API proxy'si bir ortamda dağıtılmadı'ya gidin.
6. ProxyEndpoint yalnızca koşullu akışlara sahipse aşağıdakileri kontrol edin:
   1. Tüm bu koşullu akışlardaki koşullar belirli bir proxy.pathsuffix öğesini (temel yoldan sonraki yol) kontrol ediyorsa.
   2. API İstek URL'sinde belirtilen path suffix koşulların hiçbiriyle eşleşmiyorsa hatanın nedeni budur.
7. ProxyEndpoint bölgesinde iki akışımız olduğunu ve bunların her ikisinin de aşağıda gösterildiği gibi koşullu akış olduğunu varsayalım:

   <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 proxy.pathsuffix (temel yoldan sonraki yol) ile /Bangalore ile eşleşen ve diğeri /Chennai ile eşleşen iki koşullu akışımız var. Ancak /Delhi ile eşleşen bir yanıt yok. Bu, API İstek URL'sinde iletilen path suffix değeridir.
   2. 404 hatasının nedeni budur. Bu durumda ş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ı çözmek için aşağıdaki yaklaşımları kullanabilirsiniz:
   1. /Delhi yolu için belirli bir politika grubunu yürütmek istiyorsanız gerekli politika grubunu içeren ayrı bir akış ekleyip aşağıda gösterildiği gibi /proxy.pathsuffix /Delhi ile eşleşen bir koşul bulunduğundan emin olun:

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

   2. /Delhi yolu için ortak politika grubu yürütmek istiyorsanız ortak akışta genel bir /proxy.pathsuffix öğesine izin veren bir koşul bulunduğundan emin olun. Yani aşağıda gösterildiği gibi basepath /weather sonrasındaki tüm yollara izin verir:

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

ProxyEndpoint doğru basepath değerine sahipse ve API URL'sinde belirtilen path suffix koşullu akışlardan biriyle eşleşiyorsa sonraki nedene geçin: API proxy'si bir ortamda dağıtılmadı.

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

Teşhis

1. API isteği URL'nizde kullanılan ana makine takma adının bulunduğu ortamı belirleyin. Bu işlem, Edge kullanıcı arayüzünde kuruluşunuzun her bir ortamındaki tüm sanal ana makinelerin ayrıntıları kontrol edilerek yapılabilir.

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

   • URL'niz http://myorg-prod.apigee.net/weather ise myorg-prod.apigee.net, ana makine takma adıdır.
   • Ana makine takma adı myorg-prod.apigee.net, kuruluşunuzun prod ortamındaki sanal ana makinelerden birinin bir parçası olarak yapılandırıldı.
2. Belirli bir API proxy'sinin, yukarıdaki 1. adımda belirlenen belirli ortamda dağıtılıp dağıtılmadığını kontrol edin.
3. API proxy'si belirli bir ortamda dağıtılmadıysa 404 hatasının nedeni budur.
   1. Yukarıdaki 1. adımda kullanılan örnekte API proxy'sinin prod ortamında dağıtılmadığını varsayalım. Hatanın nedeni budur.
   2. Aşağıdaki Çözüm bölümüne gidin.
4. API proxy'si belirli bir ortamda dağıtılmışsa sonraki nedene geçin: Mesaj İşleyicilerine ortam yüklenmedi.

Çözünürlük

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

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

Teşhis

1. Mesaj İşleyicilerin her birine giriş yapın ve aşağıdaki komutu kullanarak API isteğini yaptığınız belirli ortamın Mesaj İşleyici'ye yüklenip yüklenmediğini kontrol edin:

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

2. Yukarıdaki komutun parçası olarak belirli bir ortam listeleniyorsa sıradaki nedene geçin: API proxy'si bir veya daha fazla Mesaj İşleyicide dağıtılmadı.
3. Belirli bir ortam listede yoksa Mesaj İşleyicilerinde ortamların yüklenmesi sırasında hata olup olmadığını görmek için /opt/apigee/var/log/edge-message-processor/logs/system.log ve /opt/apigee/var/log/edge-message-processor/logs/startupruntimeerrors.log ayarlarını kontrol edin.
4. Mesaj İşleyici'de bir ortamın yüklenmesinin başarısız olmasına yol açabilecek birçok farklı hata olabilir. Çözüm, oluşan hataya bağlıdır.

Çözünürlük

Ortam birçok nedenden dolayı İleti İşleyici'ye yüklenmeyebilir. Bu bölümde, bu sorunun olası birkaç nedeni açıklanmakta ve sorunun nasıl çözüleceği açıklanmaktadır.

1. Mesaj İşleyici günlüğünde aşağıdaki hatalardan birini görüyorsanız bunun nedeni, belirtilen ortamda belirtilen anahtar deposuna/güvenilir depoya eklenmiş sertifikalar/anahtarlarda bulunan bir sorundur.

   Hata 1: java.security.KeyStoreException: Kendi sertifikasını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ılamaz

   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. Aşağıdaki Management API çağrısını kullanarak önceki adımda gösterilen hata mesajında belirtilen anahtar deposu/güven deposu ayrıntılarını alı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 çıkış, güven deposunda (myTruststore) iki sertifika ve bir anahtar olduğunu göstermektedir. Truststore genellikle anahtar içermez. Bu durumda tek bir sertifikaya ve tek bir anahtara sahip olmak daha iyidir.
4. Aşağıdaki API'yi kullanarak iki sertifikanın ayrıntılarını öğrenin:

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

5. Her bir sertifikanın son kullanma 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 yukarıdaki 1. adımda belirtilenlerin dışında bir hata görürseniz Teşhis bilgileri toplanmalıdır bölümüne gidin.

Neden: API proxy'si bir veya daha fazla Mesaj İşleyiciye dağıtılmadı

API proxy'si, bir veya daha fazla Mesaj İşleyiciye dağıtılamaz. Bu sorun çok nadiren meydana gelir ve genellikle belirli bir API proxy'sinin dağıtımı sırasında Yönetim Sunucusu'ndan İleti İşleyiciye gönderilen bir etkinlik bildiriminin eksik olması nedeniyle meydana gelir. Bu durumda da, Edge kullanıcı arayüzünde izleme oturumu oluşturamazsınız.

Teşhis

1. Mesaj İşleyicilerin her birine giriş yapın ve aşağıdaki komutu kullanarak API proxy'sinin belirli bir düzeltmesinin dağıtılıp dağıtılmadığını kontrol edin:

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

2. API proxy'sinin belirli bir düzeltmesi yukarıdaki 1. adımda bahsedilen komutun sonucu olarak görünmüyorsa Çözüm bölümünde açıklandığı şekilde ilgili Mesaj İşleyiciyi yeniden başlatın.
3. Tüm mesaj işleyenler için 1 ve 2. adımları tekrarlayın.
4. API proxy'sinin ilgili düzeltmesi tüm Mesaj İşleyicilerine dağıtılmışsa sorunun nedeni bu değildir. Teşhis bilgileri toplanmalıdır bölümüne gidin.

Çözünürlük

API proxy'sinin belirli düzeltmesinin dağıtılmadığı belirli Mesaj İşleyicileri yeniden başlatın.

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

API Monitoring'i kullanarak sorunları teşhis edin

API Monitoring; hata, performans ve gecikme sorunlarını ve bunların kaynaklarını (ör. geliştirici uygulamaları, API proxy'leri, arka uç hedefleri veya API platformu) teşhis etmek için sorunlu alanları hızla izole etmenize olanak tanır.

Bu sorun için API İzleme > Araştır sayfasına gidip uygun tarihi, proxy'yi ve diğer öğeleri seçtiğinizde aşağıdaki ayrıntıları görebilirsiniz:

• 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öster'i tıklayabilir ve daha fazla kontrol edebilirsiniz.

Örnek senaryoyu adım adım inceleyin, API Monitoring'i kullanarak API'lerinizle ilgili 5xx sorunlarını nasıl gidereceğinizi gösterir. Örneğin, 404 durum kodu sayısı belirli bir eşiği aştığında bilgilendirilecek bir uyarı ayarlamak isteyebilirsiniz.

Teşhis bilgileri toplanmalıdır

Yukarıdaki talimatları uygulamanıza rağmen sorun devam ederse aşağıdaki teşhis bilgilerini toplayın. Apigee Edge Destek Ekibi ile iletişime geçin ve 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özlemlendi
   • Ortam adı
   • API proxy paketi
   • Mesaj İşleyici günlükleri /opt/apigee/var/log/edge-message-processor/logs/system.log
   • Mesaj işleyenlerin her birinde aşağıdaki komutların çıkışını alın.

   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ında hangi bölümleri denediğinizle ilgili ayrıntılar ve bu sorunun çözümünü hızlı bir şekilde takip etmemize yardımcı olacak diğer tüm bilgiler.