499 Koneksi klien ditutup

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

Gejala

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

Anda akan mengamati kode status 499 untuk permintaan API tersebut di Pemantauan API, dan log Akses NGINX. Terkadang, Anda akan melihat kode status yang berbeda di API Analytics karena kode tersebut menunjukkan 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 yang menyebabkan waktu tunggu klien habis?

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

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

Waktu tunggu pada 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 di Router

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

Waktu tunggu pada Prosesor Pesan

Waktu tunggu default yang dikonfigurasi pada Pemroses Pesan adalah 55 detik. Ini adalah jumlah waktu maksimum yang dapat dibutuhkan server backend untuk memproses permintaan dan merespons kembali ke Pemroses Pesan. Waktu tunggu default dapat diganti pada 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 habis waktunya, Anda akan mengamati error waktu tunggu untuk permintaan API tertentu. Kode status 499 Client Closed Connection dicatat di Router untuk permintaan tersebut, yang dapat diamati di log Pemantauan API dan 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 waktu aplikasi klien habis sebelum Proxy API memiliki waktu untuk memproses dan mengirim respons. Biasanya ini terjadi jika waktu tunggu klien kurang dari 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 API Monitoring:

  1. Buka halaman Analyze > API Monitoring > Menyelidiki.
  2. Filter untuk 4xx error dan pilih jangka waktu.
  3. Tandai Kode Status terhadap Waktu.
  4. Pilih sel yang memiliki 499 error seperti yang ditunjukkan di bawah:

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

  6. Di panel sebelah kanan, klik View logs.

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

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

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

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

    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, lalu 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 penting tentang error 499 HTTP.
  2. Periksa log akses NGINX:
    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
  3. Telusuri untuk melihat apakah ada Error 499 selama durasi tertentu (jika masalah terjadi sebelumnya) 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
    • Penyelenggara: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 tiba-tiba menutup koneksi

Diagnosis

  1. Saat API dipanggil dari aplikasi satu halaman 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 499 HTTP biasanya akan bervariasi dalam waktu pemrosesan permintaan (Waktu Respons) untuk setiap permintaan.
  3. Anda dapat menentukan apakah hal ini merupakan penyebabnya dengan membandingkan Waktu Respons dan memverifikasi apakah berbeda untuk setiap error 499 menggunakan API Monitoring atau log Akses NGINX seperti yang dijelaskan dalam Langkah-langkah diagnosis umum.

Resolusi

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

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

    Setelah mengetahui proxy 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 dalam Langkah-langkah diagnosis umum.
    2. Gunakan Dasbor analisis latensi untuk menyelidiki lebih lanjut penyebab latensi proxy dan memperbaiki masalah tersebut.
    3. Jika ternyata latensi memang diharapkan untuk Proxy tertentu, Anda mungkin harus memberi tahu pengguna bahwa Proxy ini memerlukan waktu untuk merespons.

Penyebab: Waktu tunggu aplikasi klien habis

Hal ini dapat terjadi dalam beberapa skenario.

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

Diagnosis

Pemantauan API atau log akses NGINX

Diagnosis error menggunakan API Monitoring atau log akses NGINX:

  1. Periksa log Pemantauan API atau log akses NGINX untuk transaksi 499 HTTP seperti yang dijelaskan dalam Langkah-langkah diagnosis umum.
  2. Tentukan apakah Waktu Respons konsisten untuk semua error 499.
  3. Jika ya, maka aplikasi klien tertentu mungkin telah mengonfigurasi waktu tunggu tetap pada sistemnya. Jika proxy API atau server target merespons dengan lambat, waktu tunggu klien akan habis sebelum waktu proxy habis, sehingga HTTP 499s ditampilkan dalam jumlah besar 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 besar dari waktu tunggu API Apigee. Secara default, Waktu Router Apigee akan habis setelah 57 detik, sehingga cocok untuk mengonfigurasi waktu tunggu permintaan 60 detik pada load balancer.

Rekaman aktivitas

Mendiagnosis error menggunakan Trace

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

  1. Aktifkan sesi perekaman aktivitas untuk API yang terpengaruh di UI Edge.
  2. Tunggu hingga error terjadi, atau jika Anda memiliki panggilan API, buat beberapa panggilan API dan rekonstruksi error tersebut.
  3. Periksa waktu berlalu di setiap fase dan buat catatan fase tempat sebagian besar waktu dihabiskan.
  4. Jika Anda mengamati error dengan waktu berlalu yang paling lama tepat setelah salah satu fase berikut, ini menunjukkan bahwa server backend lambat atau memerlukan waktu lama untuk memproses permintaan:
    • Permintaan dikirim ke server target
    • Kebijakan ServiceCallout

    Berikut ini contoh pelacakan UI yang menunjukkan Waktu Tunggu Gateway 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 menetapkan nilai waktu tunggu yang tepat 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 Cloud Publik, berikan informasi berikut:

  • Nama organisasi
  • Nama lingkungan
  • Nama Proxy API
  • Menyelesaikan perintah curl yang digunakan untuk mereproduksi error waktu tunggu
  • File pelacakan untuk permintaan API yang Anda lihat error waktu tunggu kliennya

Jika Anda adalah pengguna Private Cloud, berikan informasi berikut:

  • Pesan error lengkap yang diamati untuk permintaan yang gagal
  • Nama lingkungan
  • Paket Proxy API
  • File pelacakan untuk permintaan API yang Anda lihat error waktu tunggu kliennya
  • Log akses NGINX (/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log)
  • Log sistem Pemroses Pesan (/opt/apigee/var/log/edge-message-processor/logs/system.log)