499 Koneksi klien ditutup

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

Gejala

Aplikasi klien menerima error waktu tunggu untuk permintaan API atau permintaan dihentikan secara tiba-tiba saat permintaan API masih dieksekusi di Apigee.

Anda akan melihat kode status 499 untuk permintaan API tersebut di Pemantauan API, dan log Akses NGINX. Terkadang, Anda akan melihat kode status yang berbeda di Analisis API karena kode tersebut menampilkan kode status yang ditampilkan oleh Pemroses Pesan.

Pesan error

Aplikasi klien mungkin melihat error seperti: 

curl: (28) Operation timed out after 6001 milliseconds with 0 out of -1 bytes received

Apa penyebab waktu tunggu klien habis?

Jalur umum untuk permintaan API di platform Edge adalah Klien > Router > Message Processor > Server Backend seperti yang ditunjukkan pada gambar berikut:

Router dan Pemroses Pesan dalam platform Apigee Edge disiapkan dengan nilai waktu tunggu default yang sesuai untuk memastikan permintaan API tidak terlalu lama diselesaikan.

Waktu Tunggu Habis di Klien

Aplikasi klien dapat dikonfigurasi dengan nilai waktu tunggu yang sesuai berdasarkan kebutuhan Anda.

Klien seperti browser web dan aplikasi seluler memiliki waktu tunggu yang ditentukan oleh sistem operasi.

Waktu Tunggu Router Habis

Waktu tunggu default yang dikonfigurasi di Router adalah 57 detik. Ini adalah jumlah waktu maksimum yang dapat dijalankan oleh proxy API sejak permintaan API diterima di Edge hingga respons dikirim kembali, termasuk respons backend dan semua kebijakan yang dijalankan. Waktu tunggu default dapat diganti di Router dan host virtual seperti yang dijelaskan dalam Mengonfigurasi waktu tunggu I/O di Router.

Waktu tunggu habis di Message Processor

Waktu tunggu default yang dikonfigurasi di Pemroses Pesan adalah 55 detik. Ini adalah jumlah waktu maksimum yang dapat digunakan server backend untuk memproses permintaan dan merespons kembali ke Message Processor. Waktu tunggu default dapat diganti di Pemroses Pesan atau dalam Proxy API seperti yang dijelaskan dalam Mengonfigurasi waktu tunggu I/O di Pemroses Pesan.

Jika klien menutup koneksi dengan Router sebelum proxy API kehabisan waktu, Anda akan melihat error waktu tunggu untuk permintaan API tertentu. Kode status 499 Client Closed Connection dicatat dalam Log Router untuk permintaan tersebut, yang dapat diamati di API Monitoring dan log Akses NGINX.

Kemungkinan Penyebab

Di Edge, penyebab umum error 499 Client Closed Connection adalah:

Penyebab Deskripsi Petunjuk pemecahan masalah yang berlaku untuk
Klien menutup koneksi secara tiba-tiba Hal ini terjadi saat klien menutup koneksi karena pengguna akhir membatalkan permintaan sebelum selesai. Pengguna Cloud Publik dan Pribadi
Waktu tunggu aplikasi klien Hal ini terjadi saat aplikasi klien mengalami waktu tunggu sebelum Proxy API memiliki waktu untuk memproses dan mengirim respons. Biasanya hal ini terjadi saat waktu tunggu klien lebih kecil daripada waktu tunggu router. Pengguna Cloud Publik dan Pribadi

Langkah-langkah diagnosis umum

Gunakan salah satu alat/teknik berikut untuk mendiagnosis error ini:

  • Pemantauan API
  • Log akses NGINX

Pemantauan API

Untuk mendiagnosis error menggunakan Pemantauan API:

  1. Buka halaman Analyze > API Monitoring > Investigate.
  2. Filter error 4xx, lalu pilih jangka waktu.
  3. Petakan Kode Status terhadap Waktu.
  4. Pilih sel yang memiliki error 499 seperti yang ditunjukkan di bawah:

  5. Anda akan melihat informasi tentang error 499 di panel sebelah kanan seperti yang ditunjukkan di bawah:

  6. Di panel sebelah kanan, klik Lihat log.

    Dari jendela Traffic Logs, catat detail berikut untuk beberapa error 499:

    • Permintaan:Ini menyediakan metode permintaan dan URI yang digunakan untuk melakukan panggilan
    • Waktu Respons:Ini memberikan total waktu yang berlalu untuk permintaan.

    Anda juga bisa mendapatkan semua log menggunakan API Monitoring GET logs API. Misalnya, dengan membuat kueri log untuk org, env, timeRange, dan status, Anda dapat mendownload semua log untuk transaksi yang waktu tunggu kliennya habis.

    Karena API Monitoring menetapkan proxy ke - untuk error 499 HTTP, Anda dapat menggunakan API (Logs API) untuk mendapatkan proxy terkait untuk host virtual dan jalur.

    For example : 

    curl "https://apimonitoring.enterprise.apigee.com/logs/apiproxies?org=ORG&env=ENV&select=https://VIRTUAL_HOST/BASEBATH" -H "Authorization: Bearer $TOKEN"
  7. Tinjau Waktu Respons untuk error 499 tambahan dan periksa apakah Waktu Respons konsisten (misalnya 30 detik) di semua error 499.

Log akses NGINX

Untuk mendiagnosis error menggunakan log akses NGINX:

  1. Jika Anda adalah pengguna Private Cloud, Anda dapat menggunakan log akses NGINX untuk menentukan informasi utama tentang error HTTP 499.
  2. Periksa log akses NGINX:
    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
  3. Cari untuk melihat apakah ada 499 Error selama durasi tertentu (jika masalah terjadi di masa lalu) atau apakah ada permintaan yang masih gagal dengan 499.
  4. Perhatikan informasi berikut untuk beberapa error 499:
    • Total Waktu Respons
    • URI Permintaan
    • Agen Pengguna

    Contoh error 499 dari log akses NGINX:

    2019-08-23T06:50:07+00:00       rrt-03f69eb1091c4a886-c-sy      50.112.119.65:47756
10.10.53.154:8443       10.001  -       -       499     -       422     0
   GET /v1/products HTTP/1.1        -       okhttp/3.9.1    api.acme.org
rrt-03f69eb1091c4a886-c-sy-13001-6496714-1
    50.112.119.65   -       -       -       -       -       -       -       -1      -       -       dc-1  router-pod-1
rt-214-190301-0020137-latest-7d
36       TLSv1.2 gateway-1     dc-1  acme    prod  https   -

    Untuk contoh ini, kita melihat informasi berikut:

    • Total waktu respons: 10.001 detik. Hal ini menunjukkan bahwa waktu tunggu klien habis setelah 10,001 detik
    • Permintaan: GET /v1/products
    • Host:api.acme.org
    • Agen Pengguna:okhttp/3.9.1
  5. Periksa apakah Total Waktu Respons dan Agen Pengguna konsisten di semua error 499.

Penyebab: Klien menutup koneksi secara tiba-tiba

Diagnosis

  1. Saat API dipanggil dari aplikasi halaman tunggal yang berjalan di browser atau aplikasi seluler, browser akan membatalkan permintaan jika pengguna akhir tiba-tiba menutup browser, membuka halaman web lain di tab yang sama, atau menghentikan pemuatan halaman dengan mengklik atau mengetuk berhenti memuat.
  2. Jika hal ini terjadi, transaksi dengan status HTTP 499 biasanya akan bervariasi dalam waktu pemrosesan permintaan (Waktu Respons) untuk setiap permintaan.
  3. Anda dapat menentukan apakah ini penyebabnya dengan membandingkan Waktu Respons dan memverifikasi apakah berbeda untuk setiap error 499 menggunakan Pemantauan API atau log Akses NGINX seperti yang dijelaskan dalam Langkah-langkah diagnosis umum.

Resolusi

  1. Hal ini normal dan biasanya tidak perlu dikhawatirkan jika error HTTP 499 terjadi dalam jumlah kecil.

  2. Jika sering terjadi untuk jalur URL yang sama, hal ini dapat terjadi karena proxy tertentu yang terkait dengan jalur tersebut sangat lambat dan pengguna tidak mau menunggu.

    Setelah mengetahui proxy mana yang mungkin terpengaruh, gunakan dasbor analisis Latensi untuk menyelidiki lebih lanjut penyebab latensi proxy.

    1. Dalam hal ini, tentukan proxy yang terpengaruh menggunakan langkah-langkah di Langkah-langkah diagnosis umum.
    2. Gunakan Dasbor analisis latensi untuk menyelidiki lebih lanjut penyebab latensi proxy dan memperbaiki masalah tersebut.
    3. Jika Anda mendapati bahwa latensi yang terjadi memang sudah diperkirakan untuk Proxy tertentu, Anda mungkin harus memberi tahu pengguna bahwa Proxy ini akan memerlukan waktu beberapa saat untuk merespons.

Penyebab: Waktu tunggu aplikasi klien habis

Hal ini dapat terjadi dalam beberapa skenario.

  1. Permintaan diperkirakan akan memerlukan waktu tertentu (misalnya 10 detik) untuk selesai dalam kondisi operasi normal. Namun, aplikasi klien ditetapkan dengan nilai waktu tunggu yang salah (misalnya 5 detik) yang menyebabkan aplikasi klien mengalami waktu tunggu sebelum permintaan API selesai, sehingga menyebabkan 499. Dalam hal ini, kita perlu menyetel waktu tunggu klien ke nilai yang sesuai.
  2. Server atau panggilan target memerlukan waktu lebih lama dari yang diperkirakan. Dalam hal ini, Anda perlu memperbaiki komponen yang sesuai dan menyesuaikan nilai waktu tunggu dengan tepat.
  3. Klien tidak lagi memerlukan respons sehingga dibatalkan. Hal ini dapat terjadi pada API frekuensi tinggi seperti pelengkapan otomatis atau polling singkat.

Diagnosis

Log akses NGINX atau Pemantauan API

Mendiagnosis error menggunakan Pemantauan API atau log akses NGINX:

  1. Periksa log Pemantauan API atau log akses NGINX untuk transaksi HTTP 499 seperti yang dijelaskan dalam Langkah-langkah diagnosis umum.
  2. Tentukan apakah Waktu Respons konsisten untuk semua error 499.
  3. Jika ya, berarti aplikasi klien tertentu telah mengonfigurasi waktu tunggu tetap di sisi aplikasi. Jika proxy API atau server target merespons secara lambat, klien akan mengalami waktu tunggu sebelum proxy mengalami waktu tunggu, sehingga menghasilkan banyak 499s HTTP untuk jalur URI yang sama. Dalam hal ini, tentukan Agen Pengguna dari log akses NGINX yang dapat membantu Anda menentukan aplikasi klien tertentu.
  4. Mungkin juga ada load balancer di depan Apigee seperti Akamai, F5, AWS ELB, dan sebagainya. Jika Apigee berjalan di balik load balancer kustom, waktu tunggu permintaan load balancer harus dikonfigurasi agar lebih lama daripada waktu tunggu API Apigee. Secara default, Apigee Router akan mengalami waktu tunggu habis setelah 57 detik, sehingga cocok untuk mengonfigurasi waktu tunggu permintaan 60 detik di load balancer.

Trace

Mendiagnosis error menggunakan Trace

Jika masalah masih aktif (error 499 masih terjadi), lakukan langkah-langkah berikut:

  1. Aktifkan sesi rekaman aktivitas untuk API yang terpengaruh di UI Edge.
  2. Tunggu hingga error terjadi, atau jika Anda memiliki panggilan API, lakukan beberapa panggilan API dan reproduksi error.
  3. Periksa waktu yang telah berlalu di setiap fase dan catat fase yang paling banyak menghabiskan waktu.
  4. Jika Anda melihat error dengan waktu berlalu terlama segera setelah salah satu fase berikut, hal ini menunjukkan bahwa server backend lambat atau membutuhkan waktu lama untuk memproses permintaan:
    • Permintaan dikirim ke server target
    • Kebijakan ServiceCallout

    Berikut contoh rekaman aktivitas UI yang menampilkan Gateway Timeout setelah Request dikirim ke server target:

Resolusi

  1. Lihat Praktik terbaik untuk mengonfigurasi waktu tunggu I/O untuk memahami nilai waktu tunggu yang harus ditetapkan pada berbagai komponen yang terlibat dalam alur permintaan API melalui Apigee Edge.
  2. Pastikan Anda menyetel nilai waktu tunggu yang sesuai pada aplikasi klien sesuai dengan praktik terbaik.

Jika masalah masih berlanjut, buka Harus mengumpulkan informasi diagnostik .

Harus mengumpulkan informasi diagnostik

Jika masalah berlanjut, kumpulkan informasi diagnostik berikut, lalu hubungi Dukungan Apigee Edge.

Jika Anda adalah pengguna Public Cloud, berikan informasi berikut:

  • Nama organisasi
  • Nama lingkungan
  • Nama Proxy API
  • Perintah curl lengkap yang digunakan untuk memunculkan kembali error waktu tunggu
  • File rekaman aktivitas untuk permintaan API yang menyebabkan error waktu tunggu klien

Jika Anda adalah pengguna Private Cloud, berikan informasi berikut:

  • Pesan error lengkap yang diamati untuk permintaan yang gagal
  • Nama lingkungan
  • Paket Proxy API
  • File rekaman aktivitas untuk permintaan API yang menyebabkan error waktu tunggu klien
  • Log akses NGINX (/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log)
  • Log sistem Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log)