Anda sedang melihat dokumentasi Apigee Edge.
Buka dokumentasi
Apigee X. info
Bagian berikut menjelaskan masalah umum pada Apigee. Umumnya, masalah yang tercantum akan diperbaiki dalam rilis mendatang.
Masalah umum Edge lainnya
Bagian berikut menjelaskan berbagai masalah umum pada Edge.
| Area | Masalah umum |
|---|---|
Masa berlaku cache berakhir sehingga menghasilkan nilai cachehit yang salah |
Saat variabel alur Solusi: Ulangi prosesnya (lakukan panggilan kedua) lagi tepat setelah panggilan pertama. |
Menetapkan Kebijakan InvalidateCache
PurgeChildEntries ke benar (true) tidak berfungsi dengan benar |
Menetapkan Solusi: Gunakan kebijakan KeyValueMapOperations untuk melakukan iterasi pembuatan versi cache dan mengabaikan kebutuhan untuk membatalkan validasi cache. |
| Permintaan deployment serentak untuk proxy SharedFlow atau API dapat mengakibatkan status yang tidak konsisten di Server Pengelolaan tempat beberapa revisi ditampilkan sebagai di-deploy. |
Hal ini dapat terjadi, misalnya, saat pipeline deployment CI/CD dijalankan secara serentak menggunakan revisi yang berbeda. Untuk menghindari masalah ini, jangan deploy proxy API atau SharedFlow sebelum deployment saat ini selesai. Solusi: Hindari deployment proxy API atau SharedFlow serentak. |
Masalah umum pada UI Edge
Bagian berikut menjelaskan masalah umum pada UI Edge.
| Area | Masalah umum |
|---|---|
| Tidak dapat mengakses halaman Administrasi Zona SSO Edge dari menu navigasi setelah organisasi dipetakan ke zona identitas | Saat menghubungkan organisasi ke zona identitas, Anda tidak dapat lagi mengakses halaman Administrasi Zona SSO Edge dari menu navigasi sebelah kiri dengan memilih Admin > SSO. Sebagai solusi, buka halaman secara langsung menggunakan URL berikut: https://apigee.com/sso |
Masalah umum pada portal terintegrasi
Bagian berikut menjelaskan masalah umum pada portal terintegrasi.
| Area | Masalah umum |
|---|---|
| SmartDocs |
|
| Penyedia identitas SAML | Single logout (SLO) dengan penyedia identitas SAML tidak didukung untuk domain kustom. Untuk mengaktifkan domain kustom dengan penyedia identitas SAML, biarkan kolom URL Logout kosong saat Anda mengonfigurasi setelan SAML. |
| Admin portal |
|
| Fitur portal |
|
Masalah umum pada Edge for Private Cloud
Bagian berikut menjelaskan masalah umum pada Edge for Private Cloud.
| Area | Masalah umum |
|---|
| Edge for Private Cloud 4.52.02 & 4.53.00 |
Saat Anda menggunakan kebijakan SetOauthV2Info, jika AccessToken tidak dapat di-resolve ke variabel atau null, kebijakan tersebut akan menyebabkan error datastore: {
"fault": {
"faultstring": "Error while accessing datastore;Please retry later",
"detail": {
"errorcode": "datastore.ErrorWhileAccessingDataStore"
}
}
}
Perilaku ini berbeda dengan versi Apigee sebelumnya, saat skenario tersebut memicu error {
"fault": {
"faultstring": "Invalid Access Token",
"detail": {
"errorcode": "keymanagement.service.invalid_access_token"
}
}
}
Untuk memitigasi hal ini, tambahkan kebijakan RaiseFault ke proxy Anda untuk menyimulasikan pesan error yang lebih lama. Kebijakan RaiseFault ini dapat dijalankan jika variabel token akses bernilai null. Lihat contoh di bawah: <!-- Sample Raise Fault Policy ---> <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <RaiseFault async="false" continueOnError="false" enabled="true" name="RaiseFault-MissingAccessToken"> <DisplayName>RaiseFault-MissingAccessToken</DisplayName> <Properties/> <FaultResponse> <Set> <Headers/> <Payload contentType="application/json">{"fault":{"faultstring":"Invalid Access Token","detail":{"errorcode":"keymanagement.service.invalid_access_token"}}}</Payload> <StatusCode>500</StatusCode> <ReasonPhrase>Internal Server Error</ReasonPhrase> </Set> </FaultResponse> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> </RaiseFault> Kebijakan RaiseFault dapat ditambahkan secara bersyarat sebelum kebijakan SetOauthV2Info dalam alur proxy Anda seperti yang ditunjukkan pada contoh di bawah:
<Step> <!-- Execute RaiseFault policy if access_token flow variable is null --> <Condition>access_token = null</Condition> <Name>RaiseFault-MissingAccessToken</Name> </Step> <Step> <!-- Execute SetOAuthV2Info policy if access_token flow variable is null --> <Condition>access_token != null</Condition> <Name>SetOAuthV2Info</Name> </Step> Apigee akan merilis patch untuk memulihkan perilaku yang disebutkan di atas untuk Edge For Private Cloud versi 4.52.02 dan 4.53.00. |
| Update Edge for Private Cloud 4.52.02 |
Saat Anda mengupdate Edge for Private Cloud dari versi 4.51.00, 4.52.00, atau 4.52.01 ke 4.52.02, perkirakan dampak tambahan pada runtime dan API pengelolaan. Dampak ini terjadi setelah node Cassandra diupdate dan berlangsung hingga semua node server manajemen dan pemroses pesan diupdate. Jika hal ini terjadi, perkirakan dampak di salah satu area berikut:
Apigee akan memublikasikan dokumentasi update yang telah direvisi untuk Edge for Private Cloud 4.52.02 yang mengatasi masalah ini. |
| Update Mint Edge for Private Cloud 4.52.01 |
Masalah ini hanya memengaruhi pengguna yang menggunakan MINT atau mengaktifkan MINT di penginstalan Edge for Private Cloud. Komponen yang terpengaruh: edge-message-processor Masalah: Jika Anda mengaktifkan monetisasi dan menginstal 4.52.01 sebagai penginstalan baru atau mengupgrade dari versi Cloud Pribadi sebelumnya, Anda akan mengalami masalah dengan pemroses pesan. Jumlah thread terbuka akan meningkat secara bertahap sehingga menyebabkan kehabisan resource. Pengecualian berikut terlihat di system.log edge-message-processor: Error injecting constructor, java.lang.OutOfMemoryError: unable to create new native thread |
| Kerentanan HTTP/2 Apigee | Kerentanan Denial-of-Service (DoS) baru-baru ini ditemukan di beberapa penerapan protokol HTTP/2 (CVE-2023-44487), termasuk di Apigee Edge untuk Cloud Pribadi. Kerentanan ini dapat menyebabkan DoS pada fungsi pengelolaan Apigee API. Untuk mengetahui detail selengkapnya, lihat Buletin Keamanan Apigee GCP-2023-032. Komponen router dan server pengelolaan Edge for Private Cloud terekspos ke internet dan berpotensi rentan. Meskipun HTTP/2 diaktifkan di port manajemen komponen khusus Edge lainnya di Edge untuk Private Cloud, tidak ada komponen tersebut yang terekspos ke internet. Pada komponen non-Edge, seperti Cassandra, Zookeeper, dan lainnya, HTTP/2 tidak diaktifkan. Sebaiknya lakukan langkah-langkah berikut untuk mengatasi kerentanan Edge untuk Private Cloud:
Ikuti langkah-langkah berikut jika Anda menggunakan Edge Private Cloud versi 4.51.00.11 atau yang lebih baru:
Ikuti langkah-langkah berikut jika Anda menggunakan Edge for Private Cloud versi yang lebih lama dari 4.51.00.11:
|
| Upgrade Postgresql saat mengupdate ke versi 4.52 | Apigee-postgresql mengalami masalah saat mengupgrade dari Edge untuk Private Cloud versi 4.50 atau 4.51 ke versi 4.52. Masalah ini terutama terjadi jika jumlah tabel lebih besar dari 500. Anda dapat memeriksa jumlah total tabel di Postgres dengan menjalankan kueri SQL di bawah: select count(*) from information_schema.tables Solusi: Saat Memperbarui Apigee Edge 4.50.00 atau 4.51.00 ke 4.52.00, pastikan untuk melakukan langkah awal sebelum mengupgrade Apigee-postgresql. |
| Kebijakan LDAP | 149245401: Setelan kumpulan koneksi LDAP untuk JNDI yang dikonfigurasi melalui resource LDAP tidak ditampilkan, dan setelan default JNDI menyebabkan koneksi sekali pakai setiap kali. Akibatnya, koneksi dibuka dan ditutup setiap kali untuk penggunaan tunggal, sehingga menghasilkan sejumlah besar koneksi per jam ke server LDAP. Solusi: Untuk mengubah properti kumpulan koneksi LDAP, lakukan langkah-langkah berikut untuk menetapkan perubahan global di semua kebijakan LDAP.
Untuk memverifikasi bahwa properti JNDI kumpulan koneksi Anda telah diterapkan, Anda dapat melakukan tcpdump untuk mengamati perilaku kumpulan koneksi LDAP dari waktu ke waktu. |
| Latensi Pemrosesan Permintaan Tinggi | 139051927: Latensi pemrosesan proxy yang tinggi yang ditemukan di Message Processor memengaruhi semua Proxy API. Gejalanya meliputi keterlambatan waktu pemrosesan 200-300 md dibandingkan waktu respons API normal dan dapat terjadi secara acak meskipun dengan TPS rendah. Hal ini dapat terjadi jika ada lebih dari 50 server target tempat pemroses pesan membuat koneksi. Penyebab utama: Pemroses pesan menyimpan cache yang memetakan URL server target ke objek HTTPClient untuk koneksi keluar ke server target. Secara default, setelan ini ditetapkan ke 50 yang mungkin terlalu rendah untuk sebagian besar deployment. Jika deployment memiliki beberapa kombinasi org/env dalam penyiapan, dan memiliki banyak server target yang melebihi 50 secara keseluruhan, URL server target akan terus dihapus dari cache, sehingga menyebabkan latensi. Validasi: Untuk menentukan apakah penghapusan URL server target menyebabkan masalah latensi, telusuri log sistem Message Processor untuk menemukan kata kunci "onEvict" atau "Eviction". Kehadirannya dalam log menunjukkan bahwa URL server target dihapus dari cache HTTPClient karena ukuran cache terlalu kecil. Solusi:
Untuk Edge for Private Cloud versi 19.01 dan 19.06, Anda dapat mengedit dan mengonfigurasi cache HTTPClient, conf/http.properties+HTTPClient.dynamic.cache.elements.size=500 Kemudian, mulai ulang pemroses pesan. Lakukan perubahan yang sama untuk semua pemroses pesan. Nilai 500 adalah contoh. Nilai optimal untuk penyiapan Anda harus lebih besar dari jumlah server target yang akan dihubungkan oleh pemroses pesan. Tidak ada efek samping dari menetapkan properti ini lebih tinggi, dan satu-satunya pengaruhnya adalah waktu pemrosesan permintaan proxy pemroses pesan yang lebih baik.
Catatan: Edge for Private Cloud versi 50.00 memiliki setelan default 500. |
| Beberapa entri untuk peta nilai kunci | 157933959: Penyisipan dan pembaruan serentak ke peta nilai kunci (KVM) yang sama yang dicakup ke tingkat organisasi atau lingkungan menyebabkan data yang tidak konsisten dan pembaruan yang hilang. Catatan: Batasan ini hanya berlaku untuk Edge for Private Cloud. Edge untuk Cloud Publik dan Hybrid tidak memiliki batasan ini. Untuk solusi di Edge for Private Cloud, buat KVM di cakupan |