Masalah umum pada Apigee

Jika variabel alur cachehit digunakan setelah kebijakan LookupCache, karena cara titik debug dikirimkan untuk perilaku asinkron, LookupPolicy akan mengisi objek DebugInfo sebelum panggilan kembali dijalankan, sehingga menghasilkan error.

Solusi: Ulangi proses ini (lakukan panggilan kedua) lagi tepat setelah panggilan pertama.

Menyetel PurgeChildEntries dalam kebijakan InvalidateCache hanya akan menghapus permanen nilai elemen KeyFragment, tetapi seluruh cache akan dihapus.

Solusi: Gunakan kebijakan KeyValueMapOperations untuk mengiterasi pembuatan versi cache dan mengabaikan kebutuhan pembatalan validasi cache.

• Apigee Edge mendukung OpenAPI Specification 3.0 saat Anda membuat spesifikasi menggunakan editor spesifikasi dan memublikasikan API menggunakan SmartDocs di portal Anda, meskipun sebagian fitur belum didukung.

  Misalnya, fitur berikut dari OpenAPI Specification 3.0 belum didukung:

  • allOf properti untuk menggabungkan dan memperluas skema
  • Referensi jarak jauh

  Jika fitur yang tidak didukung dirujuk dalam Spesifikasi OpenAPI Anda, dalam beberapa kasus, alat akan mengabaikan fitur tersebut tetapi tetap merender dokumentasi referensi API. Dalam kasus lain, fitur yang tidak didukung akan menyebabkan error yang mencegah rendering dokumentasi referensi API berhasil. Dalam kedua kasus tersebut, Anda harus mengubah Spesifikasi OpenAPI untuk menghindari penggunaan fitur yang tidak didukung hingga didukung dalam rilis mendatang.

  Catatan: Karena editor spesifikasi tidak terlalu ketat dibandingkan SmartDocs saat merender dokumentasi referensi API, Anda mungkin mendapatkan hasil yang berbeda antar-alat.

• Saat menggunakan Coba API ini di portal, header Accept disetel ke application/json, terlepas dari nilai yang disetel untuk consumes di Spesifikasi OpenAPI.

• Update portal simultan (seperti pengeditan halaman, tema, CSS, atau skrip) oleh beberapa pengguna tidak didukung untuk saat ini.
• Jika Anda menghapus halaman dokumentasi referensi API dari portal, tidak ada cara untuk membuatnya kembali. Anda harus menghapus dan menambahkan kembali produk API, serta membuat ulang dokumentasi referensi API.
• Saat mengonfigurasi kebijakan keamanan konten, mungkin perlu waktu hingga 15 menit agar perubahan diterapkan sepenuhnya.
• Saat menyesuaikan tema portal, mungkin perlu waktu hingga 5 menit agar perubahan diterapkan sepenuhnya.

• Penelusuran akan diintegrasikan ke dalam portal terintegrasi dalam rilis mendatang.

Masalah ini hanya memengaruhi pengguna yang menggunakan MINT atau mengaktifkan MINT di penginstalan Edge untuk Private Cloud.

Komponen yang terpengaruh: edge-message-processor

Masalah: Jika Anda telah mengaktifkan monetisasi dan menginstal 4.52.01 sebagai penginstalan baru atau mengupgrade dari versi Private Cloud sebelumnya, Anda akan mengalami masalah dengan pemroses pesan. Akan ada peningkatan bertahap dalam jumlah thread terbuka yang menyebabkan kehabisan resource. Pengecualian berikut terlihat di edge-message-processor system.log:

Error injecting constructor, java.lang.OutOfMemoryError: unable to create new native thread

Kerentanan {i>Denial-of-Service<i} (DoS) baru-baru ini ditemukan di berbagai dan implementasi protokol HTTP/2 (CVE-2023-44487), termasuk di Apigee Edge untuk di Cloud Private Cloud. Kerentanan ini dapat menyebabkan DoS fungsi pengelolaan API Apigee. Untuk mengetahui detail selengkapnya, lihat Buletin Keamanan Apigee GCP-2023-032.

Komponen router dan server pengelolaan Edge untuk Private Cloud diekspos ke internet dan berpotensi rentan. Meskipun HTTP/2 diaktifkan di bagian pengelolaan porta komponen khusus Edge lainnya dari Edge untuk Private Cloud, tidak ada satu pun terekspos ke internet. Pada komponen non-Edge, seperti Cassandra, Zookeeper, dan lainnya, HTTP/2 tidak diaktifkan. Sebaiknya Anda melakukan langkah-langkah berikut untuk mengatasi kerentanan Edge untuk Private Cloud:

• Langkah-langkah untuk Edge untuk Private Cloud versi 4.51.00.11 atau yang lebih baru
• Langkah-langkah untuk Edge untuk versi Private Cloud yang lebih lama dari 4.51.00.11

Ikuti langkah-langkah ini jika Anda menggunakan Edge Private Cloud versi 4.51.00.11 atau yang lebih baru:

1. Update server pengelolaan:

   1. Di setiap node server pengelolaan, buka /opt/apigee/customer/application/management-server.properties
   2. Tambahkan baris berikut ke file properti:

      conf_webserver_http2.enabled=false

   3. Mulai ulang komponen server pengelolaan:

      apigee-service edge-management-server restart

2. Update pemroses pesan:

   1. Pada setiap node pemroses pesan, buka /opt/apigee/customer/application/message-processor.properties
   2. Tambahkan baris berikut ke file properti:

      conf_webserver_http2.enabled=false

   3. Mulai ulang komponen pemroses pesan:

      apigee-service edge-message-processor restart

3. Update router:

   1. Di setiap node router, buka /opt/apigee/customer/application/router.properties
   2. Tambahkan baris berikut ke file properti:

      conf_webserver_http2.enabled=false

   3. Mulai ulang komponen pemroses pesan:

      apigee-service edge-router restart

4. Perbarui QPID:

   1. Di setiap node QPID, buka /opt/apigee/customer/application/qpid-server.properties
   2. Tambahkan baris berikut ke file properti:

      conf_webserver_http2.enabled=false

   3. Mulai ulang komponen pemroses pesan:

      apigee-service edge-qpid-server restart

5. Update Postgres:

   1. Di setiap node Postgres, buka /opt/apigee/customer/application/postgres-server.properties
   2. Tambahkan baris berikut ke file properti:

      conf_webserver_http2.enabled=false

   3. Mulai ulang komponen pemroses pesan:

      apigee-service edge-postgres-server restart

Ikuti langkah-langkah ini jika Anda menggunakan Edge untuk Private Cloud versi yang lebih lama dari 4.51.00.11:

1. Update server pengelolaan:

   1. Di setiap node server pengelolaan, buka /opt/apigee/customer/application/management-server.properties
   2. Tambahkan dua baris berikut ke file properti:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Mulai ulang komponen server pengelolaan:

      apigee-service edge-management-server restart

2. Update pemroses pesan:

   1. Pada setiap node pemroses pesan, buka /opt/apigee/customer/application/message-processor.properties
   2. Tambahkan dua baris berikut ke file properti:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Mulai ulang komponen pemroses pesan:

      apigee-service edge-message-processor restart

3. Update router:

   1. Di setiap node router, buka /opt/apigee/customer/application/router.properties
   2. Tambahkan dua baris berikut ke file properti:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Mulai ulang komponen pemroses pesan:

      apigee-service edge-router restart

4. Perbarui QPID:

   1. Di setiap node QPID, buka /opt/apigee/customer/application/qpid-server.properties
   2. Tambahkan dua baris berikut ke file properti:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Mulai ulang komponen pemroses pesan:

      apigee-service edge-qpid-server restart

5. Update Postgres:

   1. Di setiap node Postgres, buka /opt/apigee/customer/application/postgres-server.properties
   2. Tambahkan dua baris berikut ke file properti:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Mulai ulang komponen pemroses pesan:

      apigee-service edge-postgres-server restart

Apigee-postgresql mengalami masalah saat mengupgrade dari Edge untuk Private Cloud versi 4.50 atau 4.51 ke versi 4.52. Masalah utamanya terjadi ketika jumlah tabel lebih besar dari 500.

Anda dapat memeriksa jumlah total tabel di Postgres dengan menjalankan kueri SQL di bawah ini:

select count(*) from information_schema.tables

Solusi: Saat Mengupdate Apigee Edge 4.50.00 atau 4.51.00 ke 4.52.00, pastikan untuk melakukan langkah awal sebelum mengupgrade Apigee-postgresql.

apigee-mirror tidak berfungsi di Red Hat Enterprise Linux (RHEL) 8.0.

Solusi: Sebagai solusi, instal apigee-mirror pada server yang menjalankan versi lebih rendah dari RHEL atau didukung sistem operasi untuk Apigee. Anda kemudian dapat menggunakan cermin untuk menambahkan paket bahkan jika Anda menginstal Apigee di server RHEL 8.0.

149245401: Pengaturan kumpulan koneksi LDAP untuk JNDI dikonfigurasi melalui Resource LDAP tidak diterapkan, dan JNDI secara {i>default <i} menyebabkan koneksi sekali pakai setiap saat. Akibatnya, koneksi dibuka dan ditutup setiap kali untuk penggunaan tunggal, menciptakan 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.

1. Buat file properti konfigurasi jika belum ada:

   /opt/apigee/customer/application/message-processor.properties

2. Tambahkan kode berikut ke file (ganti nilai Properti Java Naming dan Directory Interface (JNDI) berdasarkan persyaratan konfigurasi resource LDAP Anda).

   bin_setenv_ext_jvm_opts="-Dcom.sun.jndi.ldap.connect.pool.maxsize=20
   -Dcom.sun.jndi.ldap.connect.pool.prefsize=2
   -Dcom.sun.jndi.ldap.connect.pool.initsize=2
   -Dcom.sun.jndi.ldap.connect.pool.timeout=120000
   -Dcom.sun.jndi.ldap.connect.pool.protocol=ssl"

3. Pastikan file /opt/apigee/customer/application/message-processor.properties sama dengan yang dimiliki oleh apigee:apigee.
4. Mulai ulang setiap pemroses pesan.

Untuk memverifikasi bahwa JNDI kumpulan koneksi Anda properti aktif, Anda dapat lakukan {i>tcpdump<i} untuk mengamati perilaku kumpulan koneksi LDAP seiring waktu.

139051927: Latensi pemrosesan proxy tinggi ditemukan dalam Pemroses Pesan memengaruhi semua Proxy API. Gejala termasuk penundaan 200-300 md dalam waktu pemrosesan di atas normal Respons API kali dan dapat terjadi secara acak bahkan dengan TPS rendah. Hal ini dapat terjadi jika lebih dari 50 target server di mana pemroses pesan membuat koneksi.

Akar masalah: Pemroses pesan menyimpan cache yang memetakan URL server target ke objek HTTPClient untuk koneksi keluar ke server target. Secara default, pengaturan ini diatur ke 50 yang mungkin terlalu rendah untuk sebagian besar deployment. Saat deployment memiliki beberapa kombinasi org/env dalam konfigurasi, dan memiliki sejumlah besar server target yang melebihi 50 secara keseluruhan, URL server target terus dikeluarkan dari cache, sehingga menyebabkan latensi.

Validasi: Untuk menentukan apakah penghapusan URL server target menyebabkan masalah latensi, telusuri System.logs Prosesor Pesan untuk kata kunci "onEvict" atau "Penghapusan". Keberadaannya di log menunjukkan bahwa URL server target dikeluarkan 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 HTTPClient cache, /opt/apigee/customer/application/message-processor.properties:

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 contohnya. Nilai optimal untuk konfigurasi Anda harus lebih besar dari jumlah server target yang akan disambungkan oleh pemroses pesan. Tidak ada sisi efek dari menetapkan properti ini lebih tinggi, dan satu-satunya dampaknya adalah pemroses pesan yang ditingkatkan dan waktu pemrosesan permintaan proxy.

Catatan: Edge untuk Private Cloud versi 50.00 memiliki setelan default 500.

157933959: Penyisipan dan pembaruan serentak ke peta nilai kunci (KVM) yang sama yang dicakupkan ke tingkat organisasi atau lingkungan menyebabkan data yang tidak konsisten dan pembaruan akan hilang.

Catatan: Batasan ini hanya berlaku pada Edge untuk Private Cloud. Edge untuk Cloud Publik dan Hybrid tidak memiliki keterbatasan ini.

Untuk solusi di Edge untuk Private Cloud, buat KVM di Cakupan apiproxy.