Halaman ini diterjemahkan oleh Cloud Translation API.

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 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 kesalahan 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 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 Public 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 dalam proses menggunakan {i>host<i} virtual tertentu dapat menyebabkan masalah ini.	Pengguna Edge Public dan Private Cloud
Jalur tidak terkait dengan proxy API apa pun	Proxy API tertentu tidak dikonfigurasi untuk menerima permintaan pada jalur yang ditetapkan dalam pesan error.	Pengguna Edge Public 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 Public dan Private Cloud
Lingkungan tidak dimuat di Pemroses Pesan	Lingkungan spesifik (tempat Anda mencoba membuat permintaan API) belum dimuat di Pemroses Pesan karena terjadi error.	Pengguna Edge Private Cloud
Proxy API tidak di-deploy di satu atau beberapa Pemroses Pesan	Proxy API tidak dapat 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 berguna dalam memecahkan masalah error 404. Gunakan langkah-langkah berikut untuk memeriksa log:

Lihat log NGINX menggunakan perintah berikut:

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

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.

Memeriksa 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 jika Anda memiliki ID unik ID pesan dari langkah 2 untuk permintaan API.
Contoh pesan error dari log Pemroses Pesan

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 menampilkan 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

Catatan: url dan host di atas dapat bervariasi bergantung pada proxy API yang mengalami masalah.

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

Periksa konfigurasi Proxy Endpoint untuk proxy API dan lihat apakah proxy API dikonfigurasi untuk menerima permintaan pada {i>host<i} virtual yang ditentukan dalam kesalahan. Ini adalah yang ditunjukkan oleh elemen VirtualHost. Mari kita lihat contoh ProxyEndpoint konfigurasi untuk memahami hal ini.
Contoh konfigurasi Endpoint Proxy yang menunjukkan bahwa proxy API menerima permintaan pada host virtual yang aman

Misalnya host virtual ditentukan dalam lingkungan tertentu sebagai berikut:

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

Anda membuat permintaan API ke default VirtualHost menggunakan URL http://myorg-prod.apigee.net/weather

Karena ProxyEndpoint tidak memiliki default VirtualHost seperti yang ditunjukkan di 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"}}}

Buka bagian Penyelesaian di bawah untuk mengatasi masalah ini.
Jika ProxyEndpoint dikonfigurasi untuk menerima permintaan di default VirtualHost, lihat penyebab berikutnya - Jalur tidak terkait dengan proxy API apa pun.

Resolusi

Tambahkan VirtualHost yang hilang ke konfigurasi ProxyEndpoint untuk menyelesaikan masalah. Untuk contoh yang ditampilkan di atas, Anda dapat menambahkan VirtualHost default ke konfigurasi ProxyEndpoint sebagai berikut:
```
<VirtualHost>default</VirtualHost>
```
Contoh konfigurasi Endpoint Proxy yang menampilkan nilai default> VirtualHost> ditambahkan
Atau, dalam contoh yang disebutkan di atas, jika Anda hanya bermaksud menggunakan secure VirtualHost untuk proxy API khusus ini, lalu 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 diterapkan sebelumnya), yang masih digunakan oleh klien untuk membuat permintaan API, maka hal itu dapat menyebabkan masalah ini.

Diagnosis

Periksa konfigurasi Proxy Endpoint untuk proxy API untuk melihat apakah proxy API dikonfigurasi untuk menerima permintaan pada {i>host<i} virtual yang ditentukan dalam kesalahan. Ini adalah ditunjukkan oleh elemen VirtualHost dalam konfigurasi ProxyEndpoint.
Jika host virtual yang ditentukan dalam error tidak ada di ProxyEndpoint konfigurasi, lalu lakukan langkah-langkah berikut. Jika tidak, buka penyebab berikutnya - Jalur tidak terkait dengan proxy API apa pun.
Bandingkan konfigurasi ProxyEndpoint dari revisi yang di-deploy sebelumnya dengan yang saat ini revisi yang di-deploy.
1. Misalnya, revisi yang Anda deploy sebelumnya adalah 5 dan revisi yang saat ini di-deploy adalah 6:
  - Host Virtual yang dikonfigurasi di Endpoint Proxy dalam revisi 5
  - Host Virtual yang dikonfigurasi di Endpoint Proxy dalam revisi 6
2. Pada 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"}}}
```
Periksa apakah perubahan host virtual dilakukan sengaja atau tidak sengaja dalam revisi yang saat ini di-deploy dan tindakan yang sesuai seperti yang dijelaskan di bagian Penyelesaian.

Resolusi

Jika Anda mengidentifikasi bahwa {i>host<i} virtual atau {i>host<i} dihapus dalam revisi baru, hal itu mungkin disengaja atau mungkin karena kecelakaan. Untuk setiap kasus, lakukan penyelesaian/langkah yang direkomendasikan berikut untuk menyelesaikan masalah.

Skenario #1: Perubahan yang Disengaja

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

Buat proxy baru dengan jalur dasar yang berbeda dan gunakan host virtual yang berbeda (yang tidak ada dalam revisi yang di-deploy sebelumnya).
Jika Anda ingin terus menggunakan {i>proxy<i} API yang ada tetapi menggunakan {i>host<i} virtual yang berbeda, maka lebih baik mempertahankan {i> host<i} virtual yang ada dan menambahkan {i>host<i} virtual tambahan.

Tindakan ini akan memastikan bahwa pengguna proxy API ini tidak terpengaruh oleh perubahan tersebut.
Jika Anda ingin menggunakan proxy API yang ada dan hanya memiliki {i>host<i} virtual yang berbeda, maka memberi tahu pengguna terlebih dahulu dan melakukan perubahan ini selama masa pemeliharaan.

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

Skenario #2: Perubahan yang Tidak Disengaja

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

Perbarui konfigurasi ProxyEndpoint di revisi yang saat ini di-deploy untuk digunakan {i>host<i} virtual yang sama yang digunakan dalam revisi yang di-deploy sebelumnya. Di kolom 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>

Deploy ulang revisi.

Praktik terbaik

Sebaiknya selalu gunakan proxy baru atau revisi baru selama periode pemeliharaan atau saat traffic paling sedikit diperkirakan sehingga masalah apa pun yang timbul selama deployment dapat dapat dihindari atau efek pada lalu lintas dapat diminimalkan.

Penyebab: Jalur tidak terkait dengan proxy API apa pun

Jika proxy API tidak dikonfigurasi untuk menerima permintaan 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

Lihat konfigurasi ProxyEndpoint untuk proxy API tertentu yang ingin Anda untuk membuat permintaan API.
Memeriksa 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 jalur dasar proxy API

Jika path yang ditunjukkan dalam pesan error tidak sama dengan basepath dari proxy API tertentu atau tidak dimulai dengan basepath, maka dapat menjadi penyebab error.
Mari kita ambil contoh untuk menjelaskan hal ini:

basepath proxy API yang dimaksud adalah /weather
URL Permintaan API adalah https://myorg-prod.apigee.net/climate. Hal ini berarti bahwa jalur yang digunakan dalam URL permintaan API adalah /climate.

Dalam contoh ini, path tidak sama dengan basepath dan memang tidak dimulai dengan basepath. Oleh karena itu, Anda mendapatkan error berikut:

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

Resolusi

Pastikan path yang digunakan di URL permintaan API Anda sama dengan basepath dari proxy API tertentu.
Dalam contoh di atas, URL Permintaan API harus seperti berikut:
```
{
https://myorg-prod.apigee.net/weather
```

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

Jika path yang digunakan di URL Permintaan API dimulai dengan basepath, maka mungkin saja path suffix (bagian yang muncul setelah basepath) yang ditunjukkan dalam pesan error tidak cocok dengan kondisional berjalan, maka hal tersebut dapat menyebabkan error 404.
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/weather/Delhi. Artinya jalur yang digunakan dalam URL permintaan API adalah /weather/Delhi.
Dalam contoh ini, path dimulai dengan basepath /weather. Selain itu, terdapat path suffix dari /Delhi.
Sekarang periksa untuk melihat apakah ada alur kondisional di ProxyEndpoint.
Jika tidak ada alur kondisional atau ada beberapa alur non-kondisional, buka penyebab berikutnya - Proxy API tidak di-deploy di lingkungan.
Jika ProxyEndpoint hanya memiliki alur bersyarat, periksa hal berikut:
1. Jika kondisi di semua alur bersyarat ini memeriksa proxy.pathsuffix spesifik (jalur setelah jalur dasar).
2. Dan jika path suffix yang ditentukan dalam URL Permintaan API tidak cocok dengan tertentu, maka itulah penyebab {i>error<i}.
Misalkan kita memiliki dua flow di ProxyEndpoint dan keduanya alur bersyarat seperti yang ditunjukkan di bawah ini:
```
<Condition>(proxy.pathsuffix MatchesPath "/Bangalore") and (request.verb = "GET")</Condition>

<Condition>(proxy.pathsuffix MatchesPath "/Chennai") and (request.verb = "GET")</Condition>
```
1. Pada contoh yang ditunjukkan di atas, kita memiliki dua flow kondisional, satu yang cocok proxy.pathsuffix (jalur setelah jalur basis) ke /Bangalore dan satu lagi cocok dengan /Chennai. Tapi tidak ada yang cocok dengan /Delhi yaitu path suffix yang diteruskan di 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

Pastikan path suffix cocok dengan setidaknya salah satu alur bersyarat di endpoint proxy Anda.
Dalam contoh di atas, Anda dapat menggunakan pendekatan berikut untuk menyelesaikan error:
1. Jika Anda ingin menjalankan serangkaian 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 ini:
```
<Condition>(proxy.pathsuffix MatchesPath "/Delhi") and (request.verb = "GET")</Condition>
```
2. Jika Anda ingin menjalankan kumpulan kebijakan umum untuk jalur /Delhi, alur umum, pastikan bahwa ada kondisi yang memungkinkan /proxy.pathsuffix. Artinya, ini akan mengizinkan jalur apa pun setelah basepath /weather seperti yang ditunjukkan di bawah ini:
```
<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, lalu pindah ke sebab berikutnya - Proxy API tidak di-deploy di lingkungan.

Penyebab: Proxy API tidak di-deploy di lingkungan

Diagnosis

Tentukan lingkungan tempat alias host digunakan di URL permintaan API Anda. Hal ini dapat dilakukan dengan memeriksa detail semua {i>host<i} 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 dikonfigurasikan sebagai bagian dari salah satu host virtual di lingkungan prod organisasi Anda.
Periksa untuk melihat apakah proxy API tertentu di-deploy di lingkungan tertentu yang ditentukan dalam langkah 1 di atas.
Jika proxy API tidak di-deploy di lingkungan tertentu, maka itulah penyebab error 404.
1. Jadi dalam contoh yang digunakan di langkah 1 di atas, anggaplah proxy API tidak di-deploy di prod, maka itulah penyebab error.
2. Buka bagian Penyelesaian di bawah.
Jika proxy API di-deploy di lingkungan tertentu, lihat 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 pada Pemroses Pesan

Diagnosis

Masuk ke setiap Pemroses Pesan dan periksa apakah lingkungan tertentu tempat Anda membuat permintaan API dimuat pada Pemroses Pesan menggunakan perintah berikut:
```
curl -v 0:8082/v1/runtime/organizations/<orgname>/environments
```
Jika lingkungan tertentu tercantum sebagai bagian dari perintah di atas, buka penyebab berikutnya - Proxy API tidak di-deploy di satu atau beberapa Pemroses Pesan.
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 pada Pemroses Pesan untuk error apa pun selama pemuatan lingkungan.
Ada banyak error yang dapat menyebabkan kegagalan pemuatan lingkungan di {i>Message Processor<i}. 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 mengatasinya menyelesaikan masalah.

Jika Anda melihat salah satu dari kesalahan berikut di log Pemroses Pesan, itu disebabkan oleh ditemukan pada sertifikat/kunci yang telah ditambahkan ke keystore/truststore yang ditentukan dalam lingkungan tertentu.

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

Dapatkan detail keystore/truststore yang ditentukan dalam pesan error yang ditampilkan di langkah sebelumnya dengan 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"
}

Contoh output menunjukkan bahwa ada dua sertifikat dan sebuah kunci di truststore myTruststore. Truststore umumnya tidak berisi kunci. Jika ya, hal itu lebih baik memiliki satu sertifikat dan satu kunci.

Dapatkan detail tentang kedua sertifikat tersebut menggunakan API berikut:

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

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

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

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

Proxy API tidak boleh di-deploy pada satu atau beberapa Pemroses Pesan. Masalah ini sangat sering terjadi jarang terjadi dan kebanyakan terjadi karena tidak adanya pemberitahuan peristiwa dari Server Manajemen untuk Pemroses Pesan selama deployment proxy API tertentu. Dalam hal ini, Anda juga akan tidak dapat membuat sesi pelacakan di UI Edge.

Diagnosis

Masuk ke setiap Pemroses Pesan dan periksa untuk melihat apakah revisi Proxy API di-deploy atau tidak menggunakan perintah berikut:
```
curl -v 0:8082/v1/runtime/organizations/<orgname>/environments/<envname>/apis/<apiname>/revisions
```
Jika revisi spesifik dari proxy API tidak muncul sebagai output perintah yang disebutkan pada langkah 1 di atas, lalu memulai ulang Pemroses Pesan tertentu seperti yang dijelaskan dalam Resolusi.
Ulangi langkah 1-2 untuk semua Pemroses Pesan.
Jika revisi tertentu dari proxy API di-deploy di semua Pemroses Pesan, ini bukanlah penyebab masalah ini. Buka Harus mengumpulkan informasi diagnostik.

Resolusi

Memulai ulang Pemroses Pesan tertentu tempat revisi proxy API tertentu berada 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 masalah error, performa, dan latensi beserta sumbernya, seperti aplikasi developer, Proxy API, target backend, atau platform API.

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

Kode error dan kode status di UI

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 dalam screenshot di atas, dan memeriksanya lebih lanjut.

lihat log

Menggunakan contoh skenario menunjukkan cara memecahkan masalah 5xx terkait API Anda menggunakan Pemantauan API. Sebagai contoh, Anda mungkin ingin menyiapkan notifikasi yang akan diberi tahu saat jumlah kode status 404 melebihi ambang 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.

Jika Anda adalah pengguna Cloud Publik, berikan informasi berikut:
- Nama organisasi
- Nama lingkungan
- Nama proxy API
- Menyelesaikan perintah curl untuk mereproduksi error
Jika Anda adalah pengguna Private Cloud, berikan informasi berikut:
- Pesan error lengkap diamati
- Nama lingkungan
- Paket proxy API
- Log Pemroses Pesan /opt/apigee/var/log/edge-message-processor/logs/system.log
- Output dari perintah berikut pada setiap Pemroses Pesan.
Detail tentang bagian mana saja dalam playbook ini yang telah Anda coba dan wawasan lain yang akan membantu kami mempercepat penyelesaian masalah ini.