404 Tidak dapat mengidentifikasi proxy untuk host: <nama host virtual> dan url: <path>

Anda sedang melihat dokumentasi Apigee Edge.
Buka dokumentasi Apigee X. info

Gejala

Aplikasi klien mendapatkan kode status HTTP 404 dengan pesan Not Found dan pesan error Unable to identify proxy for host: VIRTUAL_HOST and url: PATH sebagai respons terhadap panggilan API.

Error ini berarti Edge tidak dapat menemukan proxy API untuk jalur dan host virtual yang ditentukan.

Pesan Error

Anda akan mendapatkan kode status HTTP berikut:

HTTP/1.1 404 Not Found

Anda juga akan melihat pesan error yang mirip dengan yang ditampilkan di bawah:

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

Pesan error di atas menunjukkan bahwa Edge tidak dapat menemukan proxy API untuk jalur /oauth2/token dan host virtual default.

Kemungkinan Penyebab

Beberapa kemungkinan penyebab error ini tercantum di bawah:

Langkah-langkah diagnosis umum

Log NGINX dan Message Processor akan berguna dalam memecahkan masalah error 404. Gunakan langkah-langkah berikut untuk memeriksa log:

1. Lihat log NGINX menggunakan perintah berikut:

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

2. Periksa kolom berikut dalam entri log:

   Kolom	Nilai
   Upstream_status, status	404
   X-Apigee-fault-code	messaging.adaptors.http.flow.ApplicationNotFound

   Catat ID pesan dari log.

3. Periksa log Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log) untuk melihat apakah Anda memiliki messaging.adaptors.http.flow.ApplicationNotFound untuk API tertentu atau apakah Anda memiliki ID pesan unik dari langkah 2 untuk permintaan API.

   Contoh pesan error dari log Message Processor

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)

Log di atas menunjukkan kode error dan pesan error sebagai berikut:

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

Penyebab: Proxy API tidak terkait dengan host virtual tertentu

Jika proxy API tidak dikonfigurasi untuk menerima permintaan untuk host virtual tertentu, kita dapat memperoleh respons 404 Not Found dengan pesan error Unable to identify proxy for host: VIRTUAL_HOST and url: PATH.

Diagnosis

1. Periksa konfigurasi Proxy Endpoint untuk proxy API dan lihat apakah proxy API dikonfigurasi untuk menerima permintaan untuk host virtual yang ditentukan dalam error. Hal ini ditunjukkan oleh elemen VirtualHost. Mari kita lihat contoh konfigurasi ProxyEndpoint untuk memahaminya.

   Contoh konfigurasi Endpoint Proxy yang menunjukkan bahwa proxy API menerima permintaan di host virtual yang aman

   

2. Misalkan host virtual ditentukan dalam lingkungan tertentu sebagai berikut:

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

3. Anda membuat permintaan API ke default VirtualHost menggunakan URL http://myorg-prod.apigee.net/weather
4. Karena ProxyEndpoint tidak memiliki default VirtualHost seperti yang ditunjukkan dalam contoh di atas, Anda akan mendapatkan kode respons 404 dengan pesan error berikut:

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

5. Buka bagian Penyelesaian di bawah untuk mengatasi masalah ini.
6. Jika ProxyEndpoint dikonfigurasi untuk menerima permintaan di default VirtualHost, lanjutkan ke penyebab berikutnya - Jalur tidak dikaitkan dengan proxy API mana pun.

Resolusi

1. Tambahkan VirtualHost yang tidak ada ke konfigurasi ProxyEndpoint untuk mengatasi masalah ini. Untuk contoh yang ditunjukkan di atas, Anda dapat menambahkan VirtualHost default ke konfigurasi ProxyEndpoint sebagai berikut:

   <VirtualHost>default</VirtualHost>

   Contoh konfigurasi Endpoint Proxy yang menunjukkan default> VirtualHost> yang ditambahkan

   

2. Atau, dalam contoh yang disebutkan di atas, jika Anda ingin menggunakan hanya secure VirtualHost untuk proxy API tertentu ini, buat permintaan API hanya ke secure VirtualHost menggunakan protokol HTTPS:

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

Penyebab: Host virtual dihapus dalam revisi proxy API yang baru di-deploy

Jika revisi baru proxy API di-deploy setelah menghapus host virtual tertentu (yang merupakan bagian dari revisi yang di-deploy sebelumnya), yang masih digunakan oleh klien untuk membuat permintaan API, maka hal ini dapat menyebabkan masalah ini.

Diagnosis

1. Periksa konfigurasi Proxy Endpoint untuk proxy API guna melihat apakah proxy API dikonfigurasi untuk menerima permintaan untuk host virtual yang ditentukan dalam error. Hal ini ditunjukkan oleh elemen VirtualHost dalam konfigurasi ProxyEndpoint.
2. Jika host virtual yang ditentukan dalam error tidak ada dalam konfigurasi ProxyEndpoint, lakukan langkah-langkah berikut. Jika tidak, lanjutkan ke penyebab berikutnya - Jalur tidak terkait dengan proxy API mana pun.
3. Bandingkan konfigurasi ProxyEndpoint revisi yang di-deploy sebelumnya dengan revisi yang saat ini di-deploy.
   1. Misalnya, revisi yang sebelumnya di-deploy adalah 5 dan revisi yang saat ini di-deploy adalah 6:
      • Host Virtual yang dikonfigurasi di Endpoint Proxy dalam revisi 5

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

      • Host Virtual yang dikonfigurasi di Endpoint Proxy dalam revisi 6

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

   2. Pada contoh di atas, VirtualHost vh1 ada di revision 5, tetapi dihapus di revision 6 dan diganti dengan VirtualHost secure.
   3. Jadi, jika Anda atau klien Anda membuat permintaan ke proxy API ini menggunakan VirtualHost vh1 (yang merupakan bagian dari revision 5), Anda akan mendapatkan kode respons 404 dengan pesan error berikut:

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

4. Periksa apakah perubahan host virtual dilakukan dengan sengaja atau tidak sengaja dalam revisi yang saat ini di-deploy dan ambil tindakan yang sesuai seperti yang dijelaskan di bagian Penyelesaian.

Resolusi

Jika Anda mengidentifikasi bahwa host virtual dihapus dalam revisi baru, hal ini mungkin disengaja atau tidak disengaja. Untuk setiap kasus, lakukan langkah-langkah penyelesaian/yang direkomendasikan berikut untuk mengatasi masalah.

Skenario #1: Perubahan yang Disengaja

Jika penghapusan host virtual dilakukan dengan sengaja, Anda dapat memilih salah satu opsi berikut dengan opsi pertama sebagai pendekatan yang direkomendasikan:

1. Buat proxy baru dengan jalur dasar yang berbeda dan gunakan host virtual yang berbeda (yang tidak ada dalam revisi yang di-deploy sebelumnya).

2. Jika Anda ingin terus menggunakan proxy API yang ada, tetapi menggunakan host virtual yang berbeda, sebaiknya pertahankan host virtual yang ada dan tambahkan host virtual tambahan.

   Hal ini akan memastikan bahwa pengguna proxy API ini tidak terpengaruh oleh perubahan tersebut.

3. Jika Anda ingin menggunakan proxy API yang ada dan hanya memiliki host virtual yang berbeda, maka beri tahu pengguna Anda terlebih dahulu dan lakukan perubahan ini selama periode pemeliharaan.

   Hal ini akan memastikan bahwa pengguna proxy API ini mengetahui perubahan tersebut dan mereka dapat menggunakan host virtual yang berbeda untuk melakukan panggilan ke proxy API ini. Oleh karena itu, mereka tidak akan terpengaruh oleh perubahan tersebut.

Skenario #2: Perubahan yang Tidak Disengaja

Jika penghapusan host virtual dilakukan secara keliru dan tidak disengaja,lakukan hal berikut:

1. Perbarui konfigurasi ProxyEndpoint dalam revisi yang saat ini di-deploy untuk menggunakan host virtual yang sama dengan yang digunakan dalam revisi yang di-deploy sebelumnya. Dalam contoh di atas, ubah bagian berikut dari:

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

   hingga

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

2. Deploy ulang revisi.

Praktik terbaik

Sebaiknya selalu men-deploy proxy baru atau revisi baru selama periode pemeliharaan atau saat traffic diperkirakan paling sedikit sehingga masalah apa pun yang muncul selama deployment dapat dihindari atau efek pada traffic dapat diminimalkan.

Penyebab: Jalur tidak dikaitkan dengan proxy API mana pun

Jika proxy API tidak dikonfigurasi untuk menerima permintaan untuk jalur tertentu yang digunakan di URL Permintaan API, kita bisa mendapatkan respons 404 Not Found dengan pesan error Unable to identify proxy for host: VIRTUAL_HOST and url: PATH.

Diagnosis

1. Lihat konfigurasi ProxyEndpoint untuk proxy API tertentu yang ingin Anda gunakan untuk membuat permintaan API.
2. Periksa apakah proxy API dikonfigurasi untuk menerima permintaan untuk jalur tertentu yang ditunjukkan dalam pesan error. Anda dapat melakukannya dengan melakukan langkah-langkah di Skenario #1 dan Skenario #2.

Skenario #1: Jalur tidak cocok dengan basepath proxy API

1. Jika path yang ditunjukkan dalam pesan error tidak sama dengan basepath proxy API tertentu atau tidak dimulai dengan basepath, maka hal tersebut dapat menjadi penyebab error.
2. Mari kita ambil contoh untuk menjelaskannya:
1. basepath proxy API yang dimaksud adalah /weather
2. URL Permintaan API adalah https://myorg-prod.apigee.net/climate. Artinya, jalur yang digunakan dalam URL permintaan API adalah /climate.
3. Dalam contoh ini, path tidak sama dengan basepath dan tidak dimulai dengan basepath. Oleh karena itu, Anda akan mendapatkan error berikut:

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

Resolusi

1. Pastikan path yang digunakan di URL permintaan API Anda sama dengan basepath proxy API tertentu.
2. Dalam contoh di atas, URL Permintaan API harus sebagai berikut:

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

Skenario #2: Jalur tidak cocok dengan alur bersyarat yang tersedia

1. Jika path yang digunakan dalam URL Permintaan API dimulai dengan basepath, maka path suffix (bagian yang muncul setelah basepath) yang ditunjukkan dalam pesan error mungkin tidak cocok dengan alur bersyarat mana pun, sehingga dapat menyebabkan error 404.
2. Mari kita ambil contoh untuk menjelaskannya:
   1. basepath proxy API yang dimaksud adalah /weather
   2. URL Permintaan API adalah https://myorg-prod.apigee.net/weather/Delhi. Artinya, jalur yang digunakan dalam URL permintaan API adalah /weather/Delhi.
3. Dalam contoh ini, path dimulai dengan basepath /weather. Selain itu, aplikasi ini memiliki path suffix /Delhi.
4. Sekarang periksa apakah ada alur bersyarat di ProxyEndpoint.
5. Jika tidak ada alur bersyarat atau ada beberapa alur tidak bersyarat, lanjutkan ke penyebab berikutnya - Proxy API tidak di-deploy di lingkungan.
6. Jika ProxyEndpoint hanya memiliki alur bersyarat, periksa hal berikut:
   1. Jika kondisi di semua alur bersyarat ini memeriksa proxy.pathsuffix tertentu (jalur setelah basepath).
   2. Jika path suffix yang ditentukan di URL Permintaan API tidak cocok dengan salah satu kondisi, maka itulah penyebab error.
7. Misalkan kita memiliki dua alur di ProxyEndpoint dan keduanya adalah alur bersyarat seperti yang ditunjukkan di bawah:

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

   1. Dalam contoh yang ditunjukkan di atas, kita memiliki dua alur bersyarat, satu yang cocok dengan proxy.pathsuffix (jalur setelah basepath) ke /Bangalore dan yang lainnya cocok dengan /Chennai. Namun, tidak ada yang cocok dengan /Delhi yang merupakan path suffix yang diteruskan dalam URL Permintaan API.
   2. Ini adalah penyebab error 404. Oleh karena itu, Anda akan mendapatkan error berikut:

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

Resolusi

1. Pastikan path suffix cocok dengan setidaknya salah satu alur bersyarat di endpoint proxy Anda.
2. Dalam contoh di atas, Anda dapat menggunakan pendekatan berikut untuk mengatasi error:
   1. Jika Anda ingin menjalankan serangkaian kebijakan tertentu untuk jalur /Delhi, tambahkan alur terpisah dengan serangkaian kebijakan yang diperlukan dan pastikan ada kondisi yang cocok dengan /proxy.pathsuffix /Delhi seperti yang ditunjukkan di bawah:

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

   2. Jika Anda ingin menjalankan kumpulan kebijakan umum untuk jalur /Delhi, maka di alur umum, pastikan ada kondisi yang memungkinkan /proxy.pathsuffix generik. Artinya, jalur apa pun setelah basepath /weather akan diizinkan seperti yang ditunjukkan di bawah:

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

Jika ProxyEndpoint memiliki basepath yang benar dan path suffix yang ditentukan di URL API cocok dengan salah satu alur bersyarat, lanjutkan ke penyebab berikutnya - Proxy API tidak di-deploy di lingkungan.

Penyebab: Proxy API tidak di-deploy di lingkungan

Diagnosis

1. Tentukan lingkungan tempat alias host yang digunakan di URL permintaan API Anda berada. Hal ini dapat dilakukan dengan memeriksa detail semua host virtual di setiap lingkungan organisasi Anda di UI Edge.

   Misalnya, asumsikan konfigurasi berikut:

   • Jika http://myorg-prod.apigee.net/weather adalah URL Anda, maka myorg-prod.apigee.net adalah alias host.
   • Alias host myorg-prod.apigee.net dikonfigurasi sebagai bagian dari salah satu host virtual di lingkungan prod organisasi Anda.
2. Periksa apakah proxy API tertentu di-deploy di lingkungan tertentu yang ditentukan di langkah 1 di atas.
3. Jika proxy API tidak di-deploy di lingkungan tertentu, maka itulah penyebab error 404.
   1. Jadi, dalam contoh yang digunakan pada langkah 1 di atas, misalkan proxy API tidak di-deploy di lingkungan prod, maka itulah penyebab errornya.
   2. Buka bagian Penyelesaian di bawah.
4. Jika Proxy API di-deploy di lingkungan tertentu, lanjutkan ke penyebab berikutnya - Lingkungan tidak dimuat di Pemroses Pesan.

Resolusi

Deploy proxy API di lingkungan tertentu tempat Anda ingin membuat permintaan API.

Penyebab: Lingkungan tidak dimuat di Pemroses Pesan

Diagnosis

1. Login ke setiap Pemroses Pesan dan periksa apakah lingkungan tertentu tempat Anda membuat permintaan API dimuat di Pemroses Pesan menggunakan perintah berikut:

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

2. Jika lingkungan tertentu tercantum sebagai bagian dari perintah di atas, lanjutkan ke penyebab berikutnya - Proxy API tidak di-deploy di satu atau beberapa Pemroses Pesan.
3. Jika lingkungan tertentu tidak tercantum, periksa /opt/apigee/var/log/edge-message-processor/logs/system.log dan /opt/apigee/var/log/edge-message-processor/logs/startupruntimeerrors.log di Pemroses Pesan untuk mengetahui apakah ada error selama pemuatan lingkungan.
4. Mungkin ada banyak error berbeda yang dapat menyebabkan kegagalan pemuatan lingkungan di Pemroses Pesan. Penyelesaian bergantung pada error yang terjadi.

Resolusi

Lingkungan mungkin tidak dimuat di Pemroses Pesan karena berbagai alasan. Bagian ini mengilustrasikan beberapa kemungkinan alasan yang dapat menyebabkan masalah ini dan menjelaskan cara menyelesaikan masalah tersebut.

1. Jika Anda melihat salah satu error berikut di log Message Processor, error tersebut disebabkan oleh masalah yang ditemukan pada sertifikat/kunci yang telah ditambahkan ke keystore/truststore yang ditentukan di lingkungan yang ditentukan.

   Error #1: 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

   Error #2: 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. Dapatkan detail keystore/truststore yang ditentukan dalam pesan error yang ditampilkan di langkah sebelumnya menggunakan panggilan API pengelolaan berikut:

   curl -v "http://<management-IPaddress>:8080/v1/organizations/<org-name>/environments/<env-name>/keystores/myTruststore" -u <user> 

   
   

   Contoh output:

   {
      "certs":[
         "mycert",
         "mycert-new"
      ],
      "keys":[
         "mycert"
      ],
      "name":"myTruststore"
   }

3. Contoh output menunjukkan bahwa ada dua sertifikat dan kunci di truststore myTruststore. Truststore umumnya tidak berisi kunci. Jika ya, sebaiknya gunakan satu sertifikat dan satu kunci.
4. Dapatkan detail tentang kedua sertifikat menggunakan API berikut:

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

5. Periksa tanggal habis masa berlaku setiap sertifikat dan tentukan sertifikat yang sudah habis masa berlakunya/lebih lama.
6. Hapus sertifikat yang sudah tidak berlaku atau tidak diinginkan dari truststore myTruststore.

Jika masalah masih berlanjut atau Anda melihat error selain yang disebutkan di langkah 1 di atas, buka Informasi diagnostik yang harus dikumpulkan.

Penyebab: Proxy API tidak di-deploy di satu atau beberapa Pemroses Pesan

Proxy API mungkin tidak di-deploy di satu atau beberapa Pemroses Pesan. Masalah ini sangat jarang terjadi dan sebagian besar disebabkan oleh notifikasi peristiwa yang tidak ada dari Server Pengelolaan ke Message Processor selama deployment proxy API tertentu. Dalam kasus ini juga, Anda tidak akan dapat membuat sesi rekaman aktivitas di UI Edge.

Diagnosis

1. Login ke setiap Pemroses Pesan dan periksa apakah revisi tertentu dari proxy API di-deploy atau tidak menggunakan perintah berikut:

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

2. Jika revisi spesifik proxy API tidak muncul sebagai output perintah yang disebutkan di langkah 1 di atas, mulai ulang Message Processor tertentu seperti yang dijelaskan dalam Penyelesaian.
3. Ulangi langkah 1-2 untuk semua Pemroses Pesan.
4. Jika revisi spesifik proxy API di-deploy di semua Pemroses Pesan, maka hal ini bukan penyebab masalah ini. Buka Harus mengumpulkan informasi diagnostik.

Resolusi

Mulai ulang Pemroses Pesan tertentu tempat revisi tertentu proxy API tidak di-deploy.

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

Mendiagnosis masalah menggunakan Pemantauan API

Pemantauan API memungkinkan Anda mengisolasi area masalah dengan cepat untuk mendiagnosis error, performa, dan masalah latensi serta sumbernya, seperti aplikasi developer, proxy API, target backend, atau platform API.

Untuk masalah ini, Anda dapat membuka halaman API Monitoring > Investigate dan memilih tanggal, proxy, dan sebagainya yang sesuai, dan Anda dapat melihat detail berikut:

• Kode Kesalahan: messaging.adaptors.http.flow.ApplicationNotFound
• Kode Status: 404
• Sumber Kesalahan: Apigee atau MP

Selain itu, Anda dapat mengklik Lihat log seperti yang ditunjukkan pada screenshot di atas, dan memeriksa lebih lanjut.

Menjalankan skenario contoh menunjukkan cara memecahkan masalah 5xx dengan API Anda menggunakan Pemantauan API. Misalnya, Anda mungkin ingin menyiapkan pemberitahuan untuk diberi tahu saat jumlah kode status 404 melebihi batas tertentu.

Harus mengumpulkan informasi diagnostik

Jika masalah berlanjut bahkan setelah mengikuti petunjuk di atas, kumpulkan informasi diagnostik berikut. Hubungi dan bagikan informasi ini kepada Dukungan Apigee Edge.

1. Jika Anda adalah pengguna Public Cloud, berikan informasi berikut:
   • Nama organisasi
   • Nama lingkungan
   • Nama proxy API
   • Perintah curl lengkap untuk mereproduksi error
2. Jika Anda adalah pengguna Private Cloud, berikan informasi berikut:
   • Pesan error lengkap yang diamati
   • Nama lingkungan
   • Paket proxy API
   • Log Message Processor /opt/apigee/var/log/edge-message-processor/logs/system.log
   • Output perintah berikut di setiap Pemroses Pesan.

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

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

3. Detail tentang bagian mana dalam panduan ini yang telah Anda coba dan insight lainnya yang akan membantu kami mempercepat penyelesaian masalah ini.