คําขอ API ที่ไม่ได้บันทึกใน Edge UI

คุณกำลังดูเอกสารประกอบของ Apigee Edge
ไปที่เอกสารประกอบของ Apigee X ข้อมูล

ลักษณะปัญหา

รูปภาพต่อไปนี้แสดงคำขอ API ที่ไม่ได้บันทึกไว้ใน Edge UI เมื่อเริ่มเซสชันการติดตาม

ข้อความแสดงข้อผิดพลาด

เมื่อเกิดปัญหานี้ขึ้น ข้อความแสดงข้อผิดพลาดใน Edge UI จะไม่ปรากฏขึ้น

สาเหตุที่เป็นไปได้

ตารางต่อไปนี้แสดงสาเหตุที่เป็นไปได้ที่ทำให้บันทึกคำขอ API ในการติดตาม UI ของ Edge ไม่สำเร็จ

สาเหตุ: คำขอไม่ได้รับการดำเนินการโดยผู้ประมวลผลข้อความ

การวิเคราะห์

หากต้องการบันทึกคำขอ API ในเซสชันการติดตาม ต้องประมวลผลคำขอ API โดยผู้ประมวลผลข้อความที่เป็นคอมโพเนนต์ของ Edge มีสาเหตุหลายประการที่ทำให้ระบบไม่สามารถบันทึกคำขอ API ในธุรกรรมการติดตามได้

เช่น หากคำขอ API เข้าถึง Apigee Edge ไม่สำเร็จในจุดแรกเข้าของ Edge (เช่น เราเตอร์) หรือล้มเหลวก่อนที่จะได้รับการประมวลผลโดยผู้ประมวลผลข้อความ จะทำให้ไม่สามารถบันทึกการติดตามได้ สถานการณ์แต่ละสถานการณ์เหล่านี้อธิบายไว้โดยละเอียดที่ด้านล่างนี้

สถานการณ์ที่ 1: คำขอเข้าถึง Apigee Edge ไม่สำเร็จ

• สาเหตุ

  ในสถานการณ์นี้ ข้อผิดพลาดอาจเกิดจากการแปลงชื่อ DNS หรือปัญหาการเชื่อมต่อเครือข่าย หากเป็นเช่นนั้น คุณอาจพบข้อผิดพลาดต่อไปนี้เมื่อเรียกใช้คำสั่งนี้

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

  curl: (6) Could not resolve host: hostName
  

• ความละเอียด

  คุณสามารถยืนยันการกำหนดค่า DNS ด้วยคำสั่งต่อไปนี้

  dig hostName

  คุณสามารถยืนยันการเชื่อมต่อเครือข่ายด้วยคำสั่งต่อไปนี้

  telnet hostName port

สถานการณ์ที่ 2: คำขอล้มเหลวที่เราเตอร์ Apigee Edge

• สาเหตุ

  ในสถานการณ์นี้ ข้อผิดพลาดอาจเกิดจากแฮนด์เชค TLS/SSL ล้มเหลว หากเป็นเช่นนั้น คุณอาจพบข้อผิดพลาดอย่างใดอย่างหนึ่งต่อไปนี้

  Received fatal alert: handshake_failure
  

  HTTP/1.1 400 Bad Request
  

  นอกจากนี้คุณอาจเห็นข้อผิดพลาดเกี่ยวกับใบรับรอง SSL

• ความละเอียด

  โปรดอ่าน Playbook ต่อไปนี้เพื่อแก้ปัญหา

  แฮนด์เชค TLS/SSL ล้มเหลว

  400 คำขอไม่ถูกต้อง - ข้อผิดพลาดใบรับรอง SSL

สถานการณ์ที่ 3: ผู้ประมวลผลข้อความไม่สามารถดำเนินการตามคำขอได้

• สาเหตุ

  ในสถานการณ์นี้ ผู้ประมวลผลข้อความ Apigee จะไม่พบพร็อกซี API สำหรับโฮสต์และเส้นทางเสมือนที่ระบุ ด้วยเหตุนี้ คุณจึงอาจเห็นข้อผิดพลาดอย่างใดอย่างหนึ่งต่อไปนี้

  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"
      }
    }
  }
  
  

• ความละเอียด

  ดู Playbook นี้เพื่อแก้ปัญหา: 404 ระบุพร็อกซีสําหรับโฮสต์ไม่ได้

สาเหตุ: ไม่พบพร็อกซี API ในรายงานการแยกประเภท

การวิเคราะห์

หากผู้ประมวลผลข้อความไม่พบพร็อกซี API ในแผนผังการแยกประเภท คำขอ API ที่ส่งไปยังพร็อกซีดังกล่าวจะไม่แสดงในเซสชันการติดตามใน Edge UI

โปรดทำตามขั้นตอนต่อไปนี้เพื่อดูว่าเป็นกรณีนี้หรือไม่

1. ลงชื่อเข้าใช้ Message Processor แต่ละเครื่อง แล้วตรวจสอบว่ามีการใช้งานการแก้ไขเฉพาะของ API ที่ร้องขอในสภาพแวดล้อมที่เกี่ยวข้องของ Message Processor โดยใช้คำสั่งต่อไปนี้หรือไม่

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

   ตัวอย่างเอาต์พุต:

   คำสั่งข้างต้นจะแสดงรายการการแก้ไขที่ทำให้ใช้งานได้แล้ว ตัวอย่างเช่น ถ้ามีการทำให้เวอร์ชัน 12 ใช้งานได้ คุณจะเห็นเอาต์พุตต่อไปนี้

   [ "12" ]
   

   ถ้าคุณพบข้อผิดพลาด HTTP 404 ที่เกิดขึ้นเป็นระยะๆ คุณอาจเห็นว่ามีการทำให้การแก้ไขที่ระบุใช้งานได้แล้ว

2. อ่านแผนผังการจัดประเภทและตรวจสอบว่ามีชื่อพร็อกซี API หรือไม่โดยใช้คำสั่งต่อไปนี้

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

3. ทำขั้นตอนที่ 1 และ 2 ซ้ำสำหรับผู้ประมวลผลข้อความแต่ละราย หากชื่อพร็อกซี API ที่ระบุหายไปจากโครงสร้างการจัดประเภทของตัวประมวลผลข้อความ ให้ทำตามวิธีแก้ด้านล่าง

ความละเอียด

โปรดทำตามขั้นตอนด้านล่างเพื่อแก้ไขปัญหานี้ โปรดใช้ความระมัดระวังที่จำเป็นเพื่อหลีกเลี่ยงการหยุดทำงานของเวอร์ชันที่ใช้งานจริงที่อาจเกิดขึ้นจากการรีสตาร์ทตัวประมวลผลข้อความในขณะที่มีการโหลดคำขอจำนวนมาก

1. เข้าสู่ระบบโฮสต์ตัวประมวลผลข้อความแต่ละโฮสต์ที่ไม่มีพร็อกซี API เฉพาะใน Classification Tree และใช้คำสั่งด้านล่างเพื่อรีสตาร์ทตัวประมวลผลข้อความ

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

2. เมื่อรีสตาร์ทแล้ว ให้ใช้คำสั่งด้านล่างเพื่อรอจนกว่าจะพร้อมใช้งาน

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

3. เมื่อตัวประมวลผลข้อความพร้อมใช้งาน ให้ยืนยันความพร้อมใช้งานของพร็อกซี API โดยใช้คำสั่งต่อไปนี้

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

   ตัวอย่างเอาต์พุต:

   คำสั่งข้างต้นจะแสดงรายการการแก้ไขที่ทำให้ใช้งานได้แล้ว ตัวอย่างเช่น ถ้ามีการทำให้เวอร์ชัน 12 ใช้งานได้ คุณจะเห็นเอาต์พุตต่อไปนี้

   [ "12" ]
   

   ถ้าคุณพบข้อผิดพลาด HTTP 404 ที่เกิดขึ้นเป็นระยะๆ คุณอาจเห็นว่ามีการทำให้การแก้ไขที่ระบุใช้งานได้แล้ว

4. อ่านแผนผังการจัดประเภทและตรวจสอบว่ามีชื่อพร็อกซี API อยู่โดยใช้คำสั่งต่อไปนี้

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

   หากยังคงพบปัญหาอยู่ ให้ไปที่ต้องรวบรวมข้อมูลการวินิจฉัย

ต้องรวบรวมข้อมูลการวินิจฉัย

หากปัญหายังคงอยู่หลังจากทำตามวิธีการข้างต้นแล้ว โปรดรวบรวมข้อมูลการวินิจฉัยต่อไปนี้แล้วแชร์กับทีมสนับสนุนของ 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