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

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

ลักษณะปัญหา

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

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

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

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

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

สาเหตุ: คำขอที่เครื่องมือประมวลผลข้อความไม่ได้ประมวลผล

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

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

ตัวอย่างเช่น หากคำขอ 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

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

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

  ความล้มเหลวในแฮนด์เชค 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. อ่าน Classification Tree และตรวจสอบการมีอยู่ของชื่อพร็อกซี API โดยใช้คำสั่งต่อไปนี้

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

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

ความละเอียด

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

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

   /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. อ่าน Classification Tree และตรวจสอบการมีอยู่ของชื่อพร็อกซี 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