Google ใช้เทคโนโลยี AI เพื่อแปลเนื้อหาเป็นภาษาที่คุณต้องการ การแปลโดย AI อาจมีข้อผิดพลาด

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

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

ลักษณะปัญหา

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

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

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

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

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

สาเหตุ	คำอธิบาย	วิธีการแก้ปัญหาที่ใช้ได้กับ
คำขอที่ Message Processor ไม่ได้ประมวลผล	คำขอ API ต้องได้รับการประมวลผลโดย Message Processor ของคอมโพเนนต์ Edge เพื่อบันทึกการติดตาม หากคำขอ API ไปยัง Apigee Edge ไม่สำเร็จ หรือไม่สำเร็จที่จุดแรกเข้าของ Edge (เช่น ) หรือล้มเหลวก่อนที่ Message Processor จะประมวลผล ระบบจะบันทึกการติดตามไม่ได้	ผู้ใช้ Edge Public และ Private Cloud
ไม่พบพร็อกซี API ในโครงสร้างการจัดประเภท	ตัวประมวลผลข้อความของ Apigee ใช้คำจำกัดความกฎการกำหนดเส้นทางที่เรียกว่า "แผนผังการจัดประเภท" เพื่อส่งคำขอตามชื่อโฮสต์ เส้นทางฐาน การแก้ไข และสภาพแวดล้อมของคำขอขาเข้า หากมีการนำพร็อกซี API ที่เกี่ยวข้องออกจากโครงสร้างการจัดประเภทด้วยเหตุผลบางประการ ธุรกรรมการติดตามอาจไม่แสดง	ผู้ใช้ Edge Private Cloud

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

การวินิจฉัย

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

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

สถานการณ์ที่ 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 Router

สาเหตุ

ในสถานการณ์นี้ ข้อผิดพลาดอาจเกิดจากแฮนด์เชค TLS/SSL ไม่สำเร็จ หากเป็นเช่นนั้น คุณอาจเห็นข้อผิดพลาดอย่างใดอย่างหนึ่งต่อไปนี้
```
Received fatal alert: handshake_failure
```
```
HTTP/1.1 400 Bad Request
```
นอกจากนี้ คุณอาจเห็นข้อผิดพลาดเกี่ยวกับใบรับรอง SSL ด้วย
ความละเอียด

ดู Playbook ต่อไปนี้เพื่อแก้ปัญหาและแก้ไขปัญหาเหล่านี้

แฮนด์เชค TLS/SSL ไม่สำเร็จ

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

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

สาเหตุ

ในสถานการณ์นี้ Message Processor ของ 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 ในโครงสร้างการจัดประเภท

การวินิจฉัย

หาก Message Processor ไม่พบพร็อกซี API ใน Classification Tree คำขอ API ใดๆ ที่ส่งไปยังพร็อกซีนั้นจะไม่แสดงในเซสชันการติดตามใน UI ของ Edge

โปรดทำตามขั้นตอนด้านล่างเพื่อตรวจสอบว่าเกิดกรณีนี้หรือไม่

เข้าสู่ระบบ Message Processor แต่ละรายการ แล้วตรวจสอบว่ามีการติดตั้งใช้งานรีวิชันที่เฉพาะเจาะจงของ API ที่ขอในสภาพแวดล้อมที่เกี่ยวข้องของ Message Processor หรือไม่ โดยใช้คำสั่งต่อไปนี้
```
curl -v http://localhost:8082/v1/runtime/organizations/orgName/environments/envName/apis/apiName/revisions
```
ตัวอย่างเอาต์พุต:

คำสั่งด้านบนจะแสดงรายการรีวิชันที่ใช้งาน เช่น หากมีการติดตั้งใช้งานรีวิชัน 12 คุณจะเห็นเอาต์พุตต่อไปนี้
```
[ "12" ]
```
คุณน่าจะเห็นว่ามีการติดตั้งใช้งานรีวิชันที่เฉพาะเจาะจง เว้นแต่จะพบข้อผิดพลาด HTTP 404 เป็นระยะๆ
อ่านแผนผังการจัดประเภทและตรวจสอบว่ามีชื่อพร็อกซี API หรือไม่โดยใช้คำสั่งต่อไปนี้
```
curl -i http://localhost:8082/v1/classification/tree | grep apiName
```
ทำขั้นตอนที่ 1 และ 2 ซ้ำสำหรับ Message Processor แต่ละรายการ หากไม่มีชื่อพร็อกซี API ที่ระบุในแผนผังการจัดประเภทของตัวประมวลผลข้อความใดก็ตาม ให้ทำตามวิธีแก้ปัญหาที่ระบุไว้ด้านล่าง

วิธีแก้ปัญหา

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

เข้าสู่ระบบโฮสต์ของ Message Processor แต่ละรายการที่ไม่มีพร็อกซี API ที่เฉพาะเจาะจงในแผนผังการจัดประเภท แล้วใช้คำสั่งด้านล่างเพื่อรีสตาร์ท Message Processor
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```
เมื่อรีสตาร์ทแล้ว ให้ใช้คำสั่งด้านล่างเพื่อรอจนกว่าจะเปิดใช้งานได้
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor wait_for_ready
```
เมื่อ Message Processor พร้อมแล้ว ให้ตรวจสอบความพร้อมใช้งานของพร็อกซี API โดยใช้คำสั่งต่อไปนี้
```
curl -v http://localhost:8082/v1/runtime/organizations/orgName/environments/envName/apis/apiName/revisions
```
ตัวอย่างเอาต์พุต:

คำสั่งด้านบนจะแสดงรายการรีวิชันที่ใช้งาน เช่น หากมีการติดตั้งใช้งานรีวิชัน 12 คุณจะเห็นเอาต์พุตต่อไปนี้
```
[ "12" ]
```
คุณน่าจะเห็นว่ามีการติดตั้งใช้งานรีวิชันที่เฉพาะเจาะจง เว้นแต่จะพบข้อผิดพลาด HTTP 404 เป็นระยะๆ
อ่านแผนผังการจัดประเภทและยืนยันการมีอยู่ของชื่อพร็อกซี 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
บันทึกของ Message Processor	/opt/apigee/var/log/edge-message-processor/logs/system.log
เอาต์พุตของคำสั่ง `telnet`/`netcat` จากเซิร์ฟเวอร์การจัดการไปยัง Message Processor	telnet `MessageProcessor_IP` 8082 nc -vz `MessageProcessor_IP` 8082
เอาต์พุตของคำสั่ง netstat ใน Message Processor	netstat -an > netstat.txt
การแก้ไขรายการเอาต์พุตที่ติดตั้งใช้งานสำหรับพร็อกซี API ที่เฉพาะเจาะจงใน Message Processor ทั้งหมด	curl -v http://localhost:8082/v1/runtime/organizations/`orgName`/environments/`envName`/apis/`apiName`/revisions
เอาต์พุตแผนผังการแยกประเภทใน Message Processor ทั้งหมด	curl -i http://localhost:8082/v1/classification/tree