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 bahwa Edge tidak dapat menemukan proxy API untuk host dan jalur 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 ditunjukkan di bawah ini:

{
   "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 host virtual default dan jalur /oauth2/token.

Kemungkinan Penyebab

Beberapa kemungkinan penyebab error ini tercantum di bawah:

Penyebab	Deskripsi	Petunjuk pemecahan masalah yang berlaku untuk
Proxy API tidak terkait dengan host virtual tertentu	Proxy API tertentu tidak dikonfigurasi untuk menerima permintaan pada host virtual yang ditentukan dalam pesan error.	Pengguna Edge Publik dan Private Cloud
Host virtual dihapus dalam revisi proxy API yang baru di-deploy	Menghapus host virtual dari revisi yang baru di-deploy saat klien masih menggunakan host virtual tertentu dapat menyebabkan masalah ini.	Pengguna Edge Publik dan Private Cloud
Jalur yang tidak terkait dengan proxy API apa pun	Proxy API tertentu tidak dikonfigurasi untuk menerima permintaan di jalur yang ditentukan dalam pesan error.	Pengguna Edge Publik dan Private Cloud
Proxy API tidak di-deploy di lingkungan	Proxy API tertentu tidak di-deploy di lingkungan tertentu tempat Anda mencoba membuat permintaan API.	Pengguna Edge Publik dan Private Cloud
Lingkungan tidak dimuat di Pemroses Pesan	Lingkungan tertentu (tempat Anda mencoba membuat permintaan API) belum dimuat di Pemroses Pesan karena terjadi error.	Pengguna Edge Private Cloud
Proxy API tidak di-deploy pada satu atau beberapa Pemroses Pesan	Proxy API mungkin tidak di-deploy pada satu atau beberapa Pemroses Pesan karena tidak ada notifikasi peristiwa selama deployment.	Pengguna Edge Private Cloud

Langkah-langkah diagnosis umum

Log NGINX dan Pemroses Pesan akan membantu 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 Pemroses Pesan (/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 adalah 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 host virtual tertentu, kita bisa mendapatkan respons 404 Not Found dengan pesan error Unable to identify proxy for host: VIRTUAL_HOST and url: PATH.

Diagnosis

1. Periksa konfigurasi Endpoint Proxy 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 memahami hal ini.

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

   

2. Katakanlah host virtual ditentukan dalam lingkungan spesifik 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 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 pada default VirtualHost, buka penyebab berikutnya - Jalur tidak dikaitkan dengan proxy API apa pun.

Resolusi

1. Tambahkan VirtualHost yang hilang 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 menampilkan penambahan default> VirtualHost>

   

2. Atau, dalam contoh yang dirujuk di atas, jika Anda hanya bermaksud menggunakan secure VirtualHost untuk proxy API spesifik 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

Masalah ini dapat terjadi 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.

Diagnosis

1. Periksa konfigurasi Endpoint Proxy 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 yang tidak terkait dengan proxy API apa pun.
3. Bandingkan konfigurasi ProxyEndpoint dari 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. Dalam contoh di atas, VirtualHost vh1 ada di revision 5, tetapi dihapus dalam 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 untuk mengetahui apakah perubahan host virtual dilakukan secara sengaja atau tidak sengaja dalam revisi yang saat ini di-deploy dan lakukan tindakan yang sesuai seperti yang dijelaskan di bagian Penyelesaian.

Resolusi

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

Skenario #1: Perubahan yang Disengaja

Jika penghapusan host virtual disengaja, Anda dapat memilih salah satu opsi berikut dengan opsi pertama adalah pendekatan yang direkomendasikan:

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

2. Jika Anda ingin terus menggunakan proxy API yang ada, tetapi menggunakan host virtual lain, 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 sudah ada dan hanya memiliki host virtual berbeda, 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 lain 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 tidak sengaja 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. Pada 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 deploy proxy baru atau revisi baru selama periode pemeliharaan atau saat traffic diperkirakan paling tidak diinginkan, sehingga masalah apa pun yang timbul selama deployment dapat dihindari atau efek pada traffic dapat diminimalkan.

Penyebab: Jalur tidak terkait dengan proxy API apa pun

Jika proxy API tidak dikonfigurasi untuk menerima permintaan bagi jalur tertentu yang digunakan dalam 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 buatkan 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 menjelaskan hal ini:
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 dalam URL permintaan API sama dengan basepath proxy API tertentu.
2. Pada contoh di atas, URL Permintaan API akan terlihat 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, ada kemungkinan bahwa path suffix (bagian yang muncul setelah basepath) yang ditunjukkan dalam pesan error tidak cocok dengan alur bersyarat mana pun, maka hal itu dapat menyebabkan error 404.
2. Mari kita lihat contoh untuk menjelaskan hal ini:
   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, kode ini memiliki path suffix dari /Delhi.
4. Sekarang periksa untuk melihat apakah ada flow kondisional dalam ProxyEndpoint.
5. Jika tidak ada flow kondisional atau ada beberapa flow non-kondisional, lanjutkan ke penyebab berikutnya - proxy API tidak di-deploy di lingkungan.
6. Jika ProxyEndpoint hanya memiliki flow kondisional, periksa hal berikut:
   1. Jika kondisi di semua alur bersyarat ini memeriksa proxy.pathsuffix tertentu (jalur setelah jalur dasar).
   2. Dan jika path suffix yang ditentukan dalam URL Permintaan API tidak cocok dengan salah satu kondisi, berarti itulah penyebab error.
7. Misalnya, kita memiliki dua flow di ProxyEndpoint dan keduanya adalah flow kondisional 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 flow kondisional, satu yang cocok dengan proxy.pathsuffix (jalur setelah jalur dasar) ke /Bangalore dan yang lainnya cocok dengan /Chennai. Namun, tidak ada yang cocok dengan /Delhi, yang merupakan path suffix yang diteruskan di URL Permintaan API.
   2. Hal ini menyebabkan 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 flow bersyarat di endpoint proxy Anda.
2. Pada contoh di atas, Anda dapat menggunakan pendekatan berikut untuk mengatasi error:
   1. Jika Anda ingin menjalankan kumpulan kebijakan tertentu untuk jalur /Delhi, tambahkan alur terpisah dengan kumpulan 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 dalam alur umum, pastikan ada kondisi yang mengizinkan /proxy.pathsuffix umum. Artinya, metode ini akan mengizinkan jalur apa pun setelah basepath /weather 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 dalam URL API cocok dengan salah satu flow kondisional, 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 ada. Hal ini dapat dilakukan dengan memeriksa detail semua host virtual di setiap lingkungan organisasi Anda pada UI Edge.

   Misalnya, asumsikan konfigurasi berikut:

   • Jika http://myorg-prod.apigee.net/weather adalah URL Anda, berarti 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 pada langkah 1 di atas.
3. Jika proxy API tidak di-deploy di lingkungan tertentu, berarti 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 error.
   2. Buka bagian Resolusi 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 spesifik tempat Anda membuat permintaan API dimuat di Pemroses Pesan menggunakan perintah berikut:

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

2. Jika lingkungan spesifik 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 spesifik tidak tercantum, periksa /opt/apigee/var/log/edge-message-processor/logs/system.log dan /opt/apigee/var/log/edge-message-processor/logs/startupruntimeerrors.log pada Pemroses Pesan untuk menemukan error selama pemuatan lingkungan.
4. Kemungkinan 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 menjelaskan beberapa kemungkinan alasan yang dapat menyebabkan masalah ini dan menjelaskan cara mengatasinya.

1. Jika Anda melihat salah satu error berikut di log Message Processor, hal ini 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: Tidak dapat menimpa sertifikat sendiri

   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: Tidak dapat menimpa kunci rahasia

   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 Management API 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 satu kunci di myTruststore truststore. Truststore umumnya tidak berisi kunci. Jika ya, sebaiknya Anda memiliki 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 masa berlaku sertifikat yang lebih lama.
6. Hapus sertifikat yang habis masa berlakunya atau tidak diinginkan dari truststore myTruststore.

Jika masalah masih berlanjut atau jika Anda melihat error selain yang disebutkan pada langkah 1 di atas, buka Harus mengumpulkan informasi diagnostik.

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

Proxy API mungkin tidak dapat di-deploy pada satu atau beberapa Prosesor Pesan. Masalah ini sangat jarang terjadi dan sebagian besar terjadi karena notifikasi peristiwa yang hilang dari Server Pengelolaan ke Pemroses Pesan selama deployment proxy API tertentu. Jika demikian, Anda juga tidak akan dapat membuat sesi perekaman aktivitas di UI Edge.

Diagnosis

1. Login ke setiap Pemroses Pesan dan periksa apakah revisi tertentu 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 khusus proxy API tidak muncul sebagai output perintah yang disebutkan pada langkah 1 di atas, mulai ulang Message Processor tertentu seperti yang dijelaskan di bagian Resolution.
3. Ulangi langkah 1-2 untuk semua Pemroses Pesan.
4. Jika revisi khusus proxy API di-deploy di semua Pemroses Pesan, berarti hal tersebut bukan penyebab masalah ini. Buka Harus mengumpulkan informasi diagnostik.

Resolusi

Mulai ulang Prosesor Pesan tertentu yang tidak menerapkan revisi tertentu pada proxy API.

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

Mendiagnosis masalah menggunakan API Monitoring

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

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

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

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

Ikuti contoh skenario menunjukkan cara memecahkan masalah 5xx pada API Anda menggunakan Pemantauan API. Misalnya, Anda mungkin ingin menyiapkan pemberitahuan yang akan dikirimkan saat jumlah kode status 404 melebihi nilai minimum tertentu.

Harus mengumpulkan informasi diagnostik

Jika masalah terus 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 Cloud Publik, berikan informasi berikut:
   • Nama organisasi
   • Nama lingkungan
   • Nama proxy API
   • Menyelesaikan perintah curl untuk mereproduksi error
2. Jika Anda adalah pengguna Private Cloud, berikan informasi berikut:
   • Pesan error lengkap yang diamati
   • Nama lingkungan
   • Paket proxy API
   • Log Pemroses Pesan /opt/apigee/var/log/edge-message-processor/logs/system.log
   • Output dari 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 playbook ini yang telah Anda coba, dan insight lain yang akan membantu kami mempercepat penyelesaian masalah ini.