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 tersebut dihentikan secara mendadak 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 Analytics API karena 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 Klien > {i>Router<i} > Pemroses Pesan > Server Backend seperti yang ditunjukkan pada gambar berikut:

Router dan Prosesor Pesan dalam platform Apigee Edge disiapkan dengan nilai waktu tunggu default untuk memastikan permintaan API tidak memerlukan waktu 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 waktu maksimum Proxy API dapat dieksekusi sejak permintaan API diterima di Edge hingga respons diterima dikirim kembali, termasuk respons backend dan semua kebijakan yang dijalankan. Default waktu tunggu dapat diganti di Router dan host virtual seperti yang dijelaskan dalam Mengonfigurasi waktu tunggu I/O di Router.

Waktu Tunggu pada Pemroses Pesan

Waktu tunggu default yang dikonfigurasi pada Pemroses Pesan adalah 55 detik. Ini adalah jumlah maksimum waktu yang dapat dibutuhkan server backend untuk memproses permintaan dan merespons kembali Pesan Pemroses. Waktu tunggu default dapat diganti pada Pemroses Pesan atau dalam API {i>Proxy<i} seperti yang dijelaskan dalam Mengonfigurasi waktu tunggu I/O di Pemroses Pesan.

Jika klien menutup koneksi dengan Router sebelum waktu proxy API habis, maka 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 API Log Monitoring dan NGINX Access.

Kemungkinan Penyebab

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

Penyebab Deskripsi Petunjuk pemecahan masalah berlaku untuk
Klien menutup koneksi secara tiba-tiba Ini terjadi ketika klien menutup koneksi karena pengguna akhir membatalkan permintaan sebelum prosesnya selesai. Pengguna Cloud Publik dan Pribadi
Waktu tunggu aplikasi klien Hal ini terjadi ketika waktu tunggu aplikasi klien habis sebelum Proxy API memiliki waktu untuk memproses dan mengirim respons. Biasanya hal ini terjadi saat waktu tunggu klien lebih singkat daripada waktu tunggu {i>router<i}. 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 Analyze > Pemantauan API > Investigasi.
  2. Filter error 4xx dan pilih jangka waktu.
  3. Tempatkan 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 sebagai yang ditampilkan di bawah ini:

  6. Di panel sebelah kanan, klik View logs.

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

    • Request:Fungsi ini menyediakan metode permintaan dan URI yang digunakan untuk melakukan panggilan
    • Waktu Respons:Kolom ini menunjukkan total waktu yang berlalu untuk permintaan.

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

    Karena Pemantauan API menetapkan proxy ke - untuk 499 HTTP Anda dapat menggunakan API (Logs API) untuk mendapatkan yang terkait untuk {i> host<i} 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 mengetahui error 499 tambahan dan periksa apakah Waktu Respons konsisten (misalnya 30 detik) di semua 499 error.

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 apakah ada Error 499 selama durasi tertentu atau tidak (jika masalah terjadi di masa lalu) atau jika 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 klien habis setelah 10.001 detik
    • Permintaan: GET /v1/products
    • Host:api.acme.org
    • Agen Pengguna:okhttp/3.9.1
  5. Periksa untuk melihat apakah Total Waktu Respons dan Agen Pengguna konsisten pada 499 error.

Penyebab: Klien tiba-tiba menutup koneksi

Diagnosis

  1. Saat API dipanggil dari aplikasi web satu halaman yang berjalan di browser atau aplikasi seluler, {i>browser<i} akan membatalkan permintaan jika pengguna akhir tiba-tiba menutup {i>browser<i}, menavigasi membuka halaman web lain di tab yang sama, atau menghentikan halaman dimuat 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 mengetahui penyebabnya dengan membandingkan Waktu Respons dan memverifikasi apakah Hal ini berbeda untuk setiap error 499 yang menggunakan Monitoring API atau NGINX Access log seperti yang dijelaskan dalam Langkah-langkah diagnosis umum.

Resolusi

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

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

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

    1. Dalam hal ini, tentukan {i>proxy<i} 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 yang diharapkan untuk Proxy tertentu, Anda mungkin memiliki untuk memberi tahu pengguna bahwa {i>Proxy<i} ini memerlukan waktu untuk merespons.

Penyebab: Waktu tunggu aplikasi klien habis

Hal ini dapat terjadi dalam beberapa skenario.

  1. Diharapkan bahwa permintaan akan memerlukan waktu tertentu (misalnya 10 detik) untuk selesai dalam kondisi operasi normal. Namun, aplikasi klien ditetapkan dengan nilai batas waktu (katakanlah 5 detik) yang menyebabkan aplikasi klien kehabisan waktu sebelum permintaan API diselesaikan, yang mengarah ke 499. Dalam hal ini, kita perlu mengatur 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, dan karenanya dibatalkan. Hal ini dapat terjadi pada API frekuensi seperti pelengkapan otomatis atau polling singkat.

Diagnosis

Log akses Pemantauan API atau NGINX

Diagnosis error menggunakan Pemantauan API 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 bisa jadi aplikasi klien tertentu telah mengonfigurasi waktu tunggu tetap pada akhirnya. Jika proxy API atau server target merespons dengan lambat, waktu tunggu klien akan habis sebelum waktu tunggu proxy habis, yang menghasilkan 499s HTTP 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 belakang load balancer kustom, permintaan waktu tunggu load balancer harus dikonfigurasi agar lebih besar dari waktu tunggu Apigee API. Menurut default, Waktu Router Apigee akan habis waktu setelah 57 detik, sehingga cocok untuk mengonfigurasi permintaan waktu tunggu 60 detik di load balancer.

Trace

Mendiagnosis error menggunakan Trace

Jika masalah masih aktif (499 error 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 memunculkan kembali error.
  3. Periksa waktu yang berlalu pada setiap fase dan catat fase yang paling sering dibelanjakan.
  4. Jika Anda mengamati error dengan waktu berlalu terlama, tepat setelah salah satu berikut ini, menunjukkan bahwa server backend lambat atau membutuhkan waktu lama untuk memproses permintaan:
    • Permintaan dikirim ke server target
    • Kebijakan ServiceInfo

    Berikut adalah contoh rekaman aktivitas UI yang menunjukkan Gateway Timeout setelah Request diproses dikirim ke server target:

Resolusi

  1. Rujuk Praktik terbaik untuk mengonfigurasi waktu tunggu I/O guna 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 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 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)