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 404 HTTP durum kodunu Not Found mesajı ve Unable to identify proxy for host: VIRTUAL_HOST and url: PATH hata mesajıyla birlikte 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ğıda gösterilene benzer bir hata mesajı 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 makinesi ve /oauth2/token yolu için API proxy'sini bulamadığını gösterir.

Olası nedenler

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

Sık karşılaşılan teşhis adımları

NGINX ve Mesaj İşleyici günlükleri, 404 hatasını gidermede yardımcı olur. 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 API için messaging.adaptors.http.flow.ApplicationNotFound olup olmadığını veya API isteği için 2. adımda benzersiz ileti kimliğinin olup olmadığını görmek için Mesaj İşleyici günlüklerini (/opt/apigee/var/log/edge-message-processor/logs/system.log)) kontrol edin.

   Mesaj iş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 ve hata mesajı aşağıdaki gibi gösterilmektedir:

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

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

API proxy'si belirli sanal ana makineye yönelik istekleri kabul edecek şekilde yapılandırılmamışsa 404 Not Found yanıtı ve Unable to identify proxy for host: VIRTUAL_HOST and url: PATH. hata mesajı alınabilir.

Teşhis

1. API proxy'sinin Proxy Endpoint yapılandırmasını kontrol edin ve API proxy'sinin, hatada belirtilen sanal ana makineye yönelik istekleri kabul edecek şekilde yapılandırılıp yapılandırılmadığını görün. Bu, VirtualHost öğesiyle belirtilir. Bunu anlamak için örnek bir ProxyEndpoint yapılandırmasına bakalım.

   API proxy'sinin güvenli bir sanal ana makinede istekleri kabul ettiğini gösteren örnek proxy uç noktası yapılandırması

   

2. Sanal ana makinelerin belirli bir ortamda aşağıdaki şekilde 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. URL'yi kullanarak default VirtualHost adresine bir API isteği gönderirsiniz. http://myorg-prod.apigee.net/weather
4. ProxyEndpoint, yukarıdaki örnekte gösterildiği gibi default VirtualHost içermediğinden aşağıdaki hata mesajıyla birlikte 404 yanıt kodunu 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, istekleri default VirtualHost üzerinde kabul edecek şekilde yapılandırılmışsa bir sonraki nedene ( Yol herhangi bir API proxy'siyle ilişkilendirilmemiş) gidin.

Çözünürlük

1. Sorunu gidermek için eksik olan VirtualHost özelliğini ProxyEndpoint yapılandırmasına ekleyin. Yukarıda gösterilen örnek için VirtualHost varsayılanını ProxyEndpoint yapılandırmasına aşağıdaki gibi ekleyebilirsiniz:

   <VirtualHost>default</VirtualHost>

   Varsayılan> VirtualHost> öğesinin eklendiğini gösteren örnek proxy uç nokta yapılandırması

   

2. Alternatif olarak, yukarıda bahsedilen örnekte, bu API proxy'si için yalnızca secure VirtualHost kullanmayı amaçlıyorsanız API isteklerini yalnızca HTTPS protokolünü kullanarak secure VirtualHost adresine gönderin:

   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 bir API proxy'sinin yeni bir revizyonu dağıtılırsa (daha önce dağıtılan revizyonun bir parçasıydı) ve bu revizyon, API istekleri göndermek için istemciler tarafından kullanılmaya devam ederse bu sorun oluşabilir.

Teşhis

1. API proxy'sinin, hatada belirtilen sanal ana makineye yönelik istekleri kabul edecek şekilde yapılandırılıp yapılandırılmadığını görmek için API proxy'sinin Proxy Endpoint yapılandırmasını kontrol edin. Bu durum, 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, bir sonraki nedene geçin: Yol herhangi bir API proxy'siyle ilişkilendirilmemiş.
3. Daha önce 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 ve şu anda dağıtılan düzeltmenizin 6 olduğunu varsayalım:
      • 5. düzeltmede Proxy Uç Noktası'nda yapılandırılan sanal ana makineler

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

      • 6. düzeltmede Proxy Endpoint'te 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. Bu nedenle, siz veya müşterileriniz bu API proxy'sine VirtualHost vh1 (revision 5'nin bir parçasıydı) kullanarak istekte bulunuyorsanız aşağıdaki hata mesajıyla birlikte 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, şu anda dağıtılan düzeltmede kasıtlı mı yoksa kasıtsız mı yapıldığını kontrol edin ve Çözüm bölümünde açıklandığı gibi 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 işlem kasıtlı olarak yapılmış veya yanlışlıkla gerçekleşmiş olabilir. Her durumda, sorunu çözmek için aşağıdaki çözüm/önerilen adımları uygulayın.

1. Senaryo: Amaçlanan Değişiklik

Sanal ana makine kaldırma işleminin kasıtlı olarak yapıldığı durumlarda aşağıdaki seçeneklerden birini belirleyebilirsiniz. İlk seçeneğin kullanılması önerilir:

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

2. Mevcut API proxy'sini kullanmaya devam etmek ancak farklı bir sanal ana makine kullanmak istiyorsanız mevcut sanal ana makineyi koruyup ek sanal ana makineyi eklemeniz daha iyi olur.

   Bu işlem, API proxy'sinin kullanıcılarının değişiklikten etkilenmemesini sağlar.

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 bu değişikliği bir bakım döneminde yapın.

   Bu sayede, bu API proxy'sinin kullanıcıları değişiklikten haberdar olur ve bu API proxy'sine yapılan çağrılar için farklı bir sanal ana makine kullanabilir. Bu nedenle, değişiklikten etkilenmezler.

2. Senaryo: İstem dışı değişiklik

Sanal ana makine kaldırma işlemi yanlışlıkla yapıldıysa aşağıdakileri yapın:

1. Şu anda dağıtılan düzeltmedeki ProxyEndpoint yapılandırmasını, daha önce dağıtılan düzeltmede kullanılan sanal ana makineleri kullanacak şekilde güncelleyin. Yukarıdaki örnekte, aşağıdaki bölümü şu şekilde değiştirin:

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

   to

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

2. Düzeltmeyi yeniden dağıtın.

En iyi uygulamalar

Yeni proxy'leri veya yeni düzeltmeleri her zaman bakım döneminde ya da trafiğin en az olması beklenen zamanlarda dağıtmanız önerilir. Böylece dağıtım sırasında ortaya çıkabilecek sorunlar önlenebilir veya trafik üzerindeki etki en aza indirilebilir.

Neden: Yol, herhangi bir API proxy'siyle ilişkilendirilmemiş

API proxy'si, API isteği URL'sinde kullanılan belirli yola yönelik istekleri kabul edecek şekilde yapılandırılmamışsa 404 Not Found yanıtı ve Unable to identify proxy for host: VIRTUAL_HOST and url: PATH. hata mesajı alınabilir.

Teşhis

1. API isteklerini göndermek istediğiniz belirli API proxy'sinin ProxyEndpoint yapılandırmasına bakın.
2. API proxy'sinin, hata mesajında belirtilen belirli yola yönelik istekleri kabul edecek şekilde yapılandırılıp yapılandırılmadığını kontrol edin. Bu işlemi, 1. Senaryo ve 2. Senaryo'daki adımları uygulayarak yapabilirsiniz.

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

1. Hata mesajında belirtilen path, belirli 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 verelim:
1. Amaçlanan API proxy'sinin basepath değeri /weather
2. API isteği 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 ile basepath aynı değildir ve basepath ile başlamaz. Bu nedenle 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 istek URL'nizde kullanılan path değerinin, belirli API proxy'sinin basepath değeriyle aynı olduğundan emin olun.
2. Yukarıdaki örnekte, API isteği 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çbirine uymuyor

1. API isteği URL'sinde kullanılan path, basepath ile başlıyorsa hata mesajında belirtilen path suffix (basepath'den sonra gelen kısım) koşullu akışlardan herhangi biriyle eşleşmiyor olabilir. Bu durum, 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 isteği 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şlıyor. Ayrıca, path suffix /Delhi'dir.
4. Şimdi ProxyEndpoint içinde koşullu akış olup olmadığını kontrol edin.
5. Koşullu akış yoksa veya birkaç koşulsuz akış varsa bir sonraki nedene ( API proxy'si bir ortama dağıtılmamış) geçin.
6. ProxyEndpoint yalnızca koşullu akışlar içeriyorsa aşağıdakileri kontrol edin:
   1. Tüm bu koşullu akışlardaki koşullar belirli bir proxy.pathsuffix (temel yoldan sonraki yol) için kontrol ediliyorsa.
   2. Ayrıca, API isteği URL'sinde belirtilen path suffix koşullardan herhangi biriyle eşleşmiyorsa hatanın nedeni budur.
7. ProxyEndpoint içinde iki akış olduğunu ve her ikisinin de aşağıdaki şekilde gösterildiği gibi koşullu akışlar 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ıda gösterilen örnekte, biri proxy.pathsuffix (basepath'ten sonraki yol) ile /Bangalore eşleşen, diğeri ise /Chennai ile eşleşen iki koşullu akış vardır. Ancak, API istek URL'sinde iletilen path suffix olan /Delhi ile eşleşen yok.
   2. Bu durum, 404 hatasına neden olur. Bu nedenle aşağıdaki 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 birini kullanabilirsiniz:
   1. /Delhi yolu için belirli bir politika grubunu yürütmek istiyorsanız gerekli politika grubunu içeren ayrı bir akış ekleyin ve aşağıda gösterildiği gibi /proxy.pathsuffix /Delhi ile eşleşen bir koşul olduğundan emin olun:

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

   2. /Delhi yolu için ortak bir politika grubu yürütmek istiyorsanız ortak akışta genel bir /proxy.pathsuffix'ye izin veren bir koşul olduğundan emin olun. Yani, aşağıdaki örnekte gösterildiği gibi basepath /weather sonrasındaki herhangi bir yola izin verilir:

      <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 bir sonraki nedene (API proxy'si bir ortama dağıtılmamış) geçin.

Neden: API proxy'si bir ortama dağıtılmamış

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ını kontrol ederek 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, barındırıcı takma adıdır.
   • myorg-prod.apigee.net ana makine takma adı, kuruluşunuzun prod ortamındaki sanal ana makinelerden biri olarak yapılandırılmıştır.
2. İlgili API proxy'sinin yukarıdaki 1. adımda belirlenen ortamda dağıtılıp dağıtılmadığını kontrol edin.
3. API proxy'si belirli bir ortamda dağıtılmamışsa 404 hatasının nedeni budur.
   1. Bu nedenle, yukarıdaki 1. adımda kullanılan örnekte API proxy'sinin prod ortamına dağıtılmadığını varsayarsak 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 bir sonraki nedene geçin: Ortam, mesaj işlemcilerine yüklenmedi.

Çözünürlük

API proxy'sini, API istekleri göndermeyi planladığınız belirli bir ortamda dağıtın.

Nedeni: Ortam, ileti işlemcilere yüklenmemiş

Teşhis

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

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

2. Belirli bir ortam yukarıdaki komutun bir parçası olarak listeleniyorsa bir sonraki nedene geçin: API proxy'si bir veya daha fazla mesaj işleyiciye dağıtılmamış.
3. Belirli bir ortam listelenmiyorsa ortamların yüklenmesi sırasında hata olup olmadığını kontrol etmek için Mesaj İşleyiciler'de /opt/apigee/var/log/edge-message-processor/logs/system.log ve /opt/apigee/var/log/edge-message-processor/logs/startupruntimeerrors.log'ı inceleyin.
4. Bir ortamın Mesaj İşleyici'ye yüklenememesine neden olabilecek birçok farklı hata olabilir. Çözüm, oluşan hataya bağlıdır.

Çözünürlük

Ortam, birçok nedenden dolayı Mesaj İşleyici'ye yüklenemeyebilir. Bu bölümde, bu soruna yol açabilecek birkaç olası neden açıklanmakta ve sorunun nasıl çözüleceği anlatılmaktadır.

1. İleti İşleyici günlüğünde aşağıdaki hatalardan birini görüyorsanız bu durum, belirtilen ortamda belirtilen anahtar deposuna/güven deposuna eklenen sertifikalar/anahtarlarla ilgili bir sorundan kaynaklanıyordur.

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

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

   ... 20 common frames omitted

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

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

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

2. Önceki adımda gösterilen hata mesajında belirtilen anahtar deposu/güven deposu ayrıntılarını almak 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ıda, güvenli depoda myTruststore iki sertifika ve bir anahtar olduğu gösterilmektedir. Güvenli anahtar deposu genellikle anahtar içermez. Bu durumda tek bir sertifika ve tek bir anahtar kullanmak daha iyidir.
4. Aşağıdaki API'yi kullanarak iki sertifika hakkında ayrıntılı bilgi edinin:

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

5. Sertifikaların son kullanma tarihini kontrol edin ve süresi dolmuş/eski sertifikayı belirleyin.
6. Süresi dolmuş veya istenmeyen sertifikayı güvenli depodan silin myTruststore.

Sorun devam ederse veya yukarıdaki 1. adımda belirtilenler dışında bir hatayla karşılaşırsanız Toplanması gereken teşhis bilgileri başlıklı makaleye gidin.

Nedeni: API proxy'si bir veya daha fazla mesaj işleyicide dağıtılmamış

API proxy'si bir veya daha fazla mesaj işleyicide dağıtılmamış olabilir. Bu sorun çok nadiren görülür ve çoğunlukla belirli bir API proxy'sinin dağıtımı sırasında Yönetim Sunucusu'ndan Mesaj İşleyici'ye etkinlik bildirimi gönderilmemesinden kaynaklanır. 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 belirtilen komutun çıktısı olarak görünmüyorsa Çözüm bölümünde açıklandığı şekilde belirli mesaj işlemcisini yeniden başlatın.
3. Tüm mesaj işlemciler için 1-2 arasındaki adımları tekrarlayın.
4. API proxy'sinin belirli bir düzeltmesi tüm Mesaj İşleyicilerde dağıtılıyorsa bu durum sorunun nedeni değildir. Teşhis bilgilerini toplama başlıklı makaleye gidin.

Çözünürlük

API proxy'sinin belirli revizyonunun dağıtılmadığı belirli mesaj işleyicileri yeniden başlatın.

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

API izlemeyi kullanarak sorunları teşhis etme

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

Bu sorun için API İzleme > İncele sayfasına gidip uygun tarihi, proxy'yi vb. seçebilirsiniz. Ardından 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örüntüle'yi tıklayarak daha ayrıntılı inceleme yapabilirsiniz.

Örnek senaryoyu adım adım inceleme, API İzleme'yi kullanarak API'lerinizle ilgili 5xx sorunlarını nasıl gidereceğinizi gösterir. Örneğin, 404 durum kodlarının sayısı belirli bir eşiği aştığında bildirim almak için uyarı oluşturmak isteyebilirsiniz.

Teşhis bilgilerini toplamalıdır

Yukarıdaki talimatları uyguladıktan sonra sorun devam ederse aşağıdaki teşhis bilgilerini toplayın. Bu bilgilerle ilgili olarak Apigee Edge Destek Ekibi ile iletişime geçin ve bu bilgileri onlarla 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'sinin adı
   • Hatayı yeniden oluşturmak için kullanılan curl komutunun tamamı
2. Private Cloud kullanıcısıysanız aşağıdaki bilgileri sağlayın:
   • Gözlemlenen hata mesajının tamamı
   • Ortam adı
   • API proxy paketi
   • Mesaj işleyici günlükleri /opt/apigee/var/log/edge-message-processor/logs/system.log
   • Her bir mesaj işlemcisinde 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 oyun kitabında hangi bölümleri denediğiniz ve sorunun çözümünü hızlandırmamıza yardımcı olacak diğer bilgiler.