Permintaan API yang tidak diambil di UI Edge

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

Gejala

Gambar berikut menunjukkan bahwa permintaan API tidak dicatat di UI Edge saat sesi rekaman aktivitas dimulai:

Pesan Error

Tidak ada pesan error yang akan ditampilkan di UI Edge saat masalah ini terjadi.

Kemungkinan Penyebab

Tabel berikut menunjukkan kemungkinan penyebab kegagalan merekam permintaan API di Rekaman Aktivitas UI Edge:

Penyebab: Permintaan tidak diproses oleh Message Processor

Diagnosis

Untuk merekam permintaan API dalam sesi Trace, permintaan API harus diproses oleh komponen Message Processor Edge. Ada beberapa alasan mengapa permintaan API mungkin tidak dicatat dalam transaksi Trace.

Misalnya, jika permintaan API gagal mencapai Apigee Edge, gagal di titik entri ke Edge (yaitu, Router) atau gagal sebelum diproses oleh Message Processor, maka rekaman aktivitas tidak dapat diambil. Setiap skenario ini diuraikan secara lebih mendetail di bawah.

Skenario 1: Permintaan gagal mencapai Apigee Edge

• Penyebab

  Dalam skenario ini, error mungkin disebabkan oleh masalah resolusi DNS atau konektivitas jaringan. Jika ya, Anda mungkin melihat error berikut saat menjalankan perintah ini:

  curl https://hostName:port/apiProxyBasePath/requestPath
  

  curl: (6) Could not resolve host: hostName
  

• Resolusi

  Anda dapat memverifikasi konfigurasi DNS dengan perintah berikut:

  dig hostName

  Anda dapat memverifikasi konektivitas jaringan dengan perintah berikut:

  telnet hostName port

Skenario 2: Permintaan gagal di Router Apigee Edge

• Penyebab

  Dalam skenario ini, error dapat disebabkan oleh kegagalan handshake TLS/SSL. Jika ya, Anda mungkin melihat salah satu error berikut:

  Received fatal alert: handshake_failure
  

  HTTP/1.1 400 Bad Request
  

  Anda mungkin juga melihat error sertifikat SSL.

• Resolusi

  Lihat playbook berikut untuk memecahkan masalah dan menyelesaikannya:

  Kegagalan Handshake TLS/SSL

  400 Bad Request - SSL Certificate Error

Skenario 3: Permintaan tidak dapat diproses oleh Message Processor

• Penyebab

  Dalam skenario ini, Pemroses Pesan Apigee tidak dapat menemukan Proxy API untuk jalur dan host virtual yang ditentukan. Akibatnya, Anda mungkin melihat salah satu error berikut:

  HTTP/1.1 404 Not Found
  

  {
    "fault":{
      "faultstring":"Unable to identify proxy for host: default and url: \/apiProxyBasePath/requestPath",
      "detail":{
        "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
      }
    }
  }

• Resolusi

  Lihat playbook ini untuk memecahkan masalah dan menyelesaikannya: 404 Tidak dapat mengidentifikasi proxy untuk host.

Penyebab: Proxy API Tidak Ditemukan di Hierarki Klasifikasi

Diagnosis

Jika Pemroses Pesan tidak dapat menemukan proxy API di Pohon Klasifikasinya, semua permintaan API ke proxy tertentu tersebut tidak akan ditampilkan dalam sesi Trace di UI Edge.

Ikuti langkah-langkah di bawah untuk menentukan apakah hal ini terjadi:

1. Login ke setiap Pemroses Pesan dan periksa apakah revisi tertentu dari API yang diminta di-deploy di lingkungan Pemroses Pesan yang relevan menggunakan perintah berikut:

   curl -v http://localhost:8082/v1/runtime/organizations/orgName/environments/envName/apis/apiName/revisions
   

   Contoh Output:

   Perintah di atas akan menampilkan daftar revisi yang di-deploy. Misalnya, jika revisi 12 di-deploy, Anda akan melihat output berikut:

   [ "12" ]
   

   Kecuali jika Anda mengalami error HTTP 404 yang tidak konsisten, Anda kemungkinan akan melihat bahwa revisi tertentu telah di-deploy.

2. Baca Pohon Klasifikasi dan periksa keberadaan nama proxy API menggunakan perintah berikut:

   curl -i http://localhost:8082/v1/classification/tree | grep apiName
   

3. Ulangi Langkah 1 dan 2 untuk setiap Pemroses Pesan. Jika nama proxy API yang diberikan tidak ada di Pohon Klasifikasi salah satu Pemroses Pesan, ikuti penyelesaian yang diberikan di bawah.

Resolusi

Ikuti langkah-langkah di bawah untuk menyelesaikan masalah ini. Pastikan untuk mengambil tindakan pencegahan yang diperlukan untuk menghindari gangguan produksi yang dapat terjadi akibat memulai ulang Pemroses Pesan saat mengalami beban permintaan yang tinggi.

1. Login ke setiap host Message Processor yang tidak memiliki proxy API tertentu di Pohon Klasifikasi dan gunakan perintah di bawah untuk memulai ulang Message Processor:

   /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
   

2. Setelah dimulai ulang, gunakan perintah di bawah untuk menunggu hingga aktif:

   /opt/apigee/apigee-service/bin/apigee-service edge-message-processor wait_for_ready
   

3. Setelah Message Processor siap, verifikasi ketersediaan proxy API menggunakan perintah berikut:

   curl -v http://localhost:8082/v1/runtime/organizations/orgName/environments/envName/apis/apiName/revisions
   

   Contoh Output:

   Perintah di atas akan menampilkan daftar revisi yang di-deploy. Misalnya, jika revisi 12 di-deploy, Anda akan melihat output berikut:

   [ "12" ]
   

   Kecuali jika Anda mengalami error HTTP 404 yang tidak konsisten, Anda kemungkinan akan melihat bahwa revisi tertentu telah di-deploy.

4. Baca Pohon Klasifikasi dan verifikasi keberadaan nama proxy API menggunakan perintah berikut:

   curl -i http://localhost:8082/v1/classification/tree | grep apiName
   

   Jika masalah masih berlanjut, buka Must Gather Diagnostic Information.

Informasi Diagnostik yang Harus Dikumpulkan

Jika masalah berlanjut setelah mengikuti petunjuk di atas, kumpulkan informasi diagnostik berikut dan bagikan kepada Dukungan Apigee Edge:

curl -v management-server-host:8080/v1/runtime/organizations/orgName/environments/envName/apis/apiProxyName/revisions/revisionNumber/debugsessions -u user

/opt/apigee/var/log/edge-management-server/logs/system.log

/opt/apigee/var/log/edge-message-processor/logs/system.log

telnet MessageProcessor_IP 8082

nc -vz MessageProcessor_IP 8082

netstat -an > netstat.txt

curl -v http://localhost:8082/v1/runtime/organizations/orgName/environments/envName/apis/apiName/revisions

curl -i http://localhost:8082/v1/classification/tree