500 ข้อผิดพลาดภายในเซิร์ฟเวอร์ - เปิดใช้งานสตรีมมิง

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

ลักษณะปัญหา

แอปพลิเคชันไคลเอ็นต์ได้รับรหัสสถานะการตอบกลับ HTTP 500 ด้วย ข้อความข้อผิดพลาดภายในเซิร์ฟเวอร์สำหรับการเรียก API

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

แอปพลิเคชันไคลเอ็นต์อาจได้รับการตอบสนองข้อผิดพลาดดังที่แสดงด้านล่าง

HTTP/1.1 500 Internal Server Error

ซึ่งอาจตามด้วยข้อความแสดงข้อผิดพลาดต่อไปนี้

{
   "fault":{
      "faultstring":"Expecting } at line 1"
      "detail":{
         "errorcode":"Internal Server Error"
      }
   }
}

OR

{
   "fault":{
      "faultstring":"Expecting ] at line 1"
      "detail":{
         "errorcode":"Internal Server Error"
      }
   }
}

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

ข้อผิดพลาดภายใน 500 ของเซิร์ฟเวอร์อาจเกิดขึ้นจากสาเหตุหลายประการ Playbook นี้ โฟกัสที่ 500 ข้อผิดพลาดภายในเซิร์ฟเวอร์ที่เกิดจากการเข้าถึงคำขอ/การตอบกลับ เพย์โหลดเมื่อสตรีม แล้ว

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

สาเหตุ: การเข้าถึงเพย์โหลดที่เปิดใช้สตรีมมิง

การวินิจฉัย

ขั้นตอนที่ 1: การใช้การติดตาม

  1. เปิดใช้งาน การติดตาม และทำการเรียก API เพื่อจำลองปัญหา - 500 ข้อผิดพลาดภายในเซิร์ฟเวอร์
  2. เลือกคำขอที่ไม่สำเร็จรายการหนึ่งและตรวจสอบการติดตาม
  3. ดำเนินการตามขั้นตอนต่างๆ ของการติดตามและค้นหาตำแหน่งที่เกิดข้อผิดพลาด
  4. ข้อผิดพลาดนี้อาจเกิดขึ้นขณะที่นโยบายกำลังแยกวิเคราะห์เพย์โหลดคำขอ/การตอบกลับ
  5. นี่คือตัวอย่างภาพหน้าจอการติดตามที่แสดง JSONThreatProtection นโยบาย ล้มเหลวโดยมีข้อผิดพลาด "Expecting } ที่บรรทัด 1"

    alt_text

    จดข้อมูลต่อไปนี้จากเอาต์พุตการติดตามดังที่แสดงไว้ด้านบน ภาพหน้าจอ:

    นโยบายความล้มเหลว: JSONThreatProtection

    ขั้นตอน: คำขอพร็อกซี

  6. ตรวจสอบคำจำกัดความของนโยบายที่ไม่สำเร็จและตรวจสอบเพย์โหลดที่กำลังแยกวิเคราะห์

    ในสถานการณ์ตัวอย่าง ให้ตรวจสอบนโยบาย JSONThreatProtection ที่ชื่อ JSON-Threat-Protection ที่ล้มเหลวและตรวจสอบองค์ประกอบ <Source>

    <JSONThreatProtection async="false" continueOnError="false" enabled="true" name="JSON-Threat-Protection">
       <DisplayName>JSON Threat Protection</DisplayName>
       <ArrayElementCount>20</ArrayElementCount>
       <ContainerDepth>10</ContainerDepth>
       <ObjectEntryCount>15</ObjectEntryCount>
       <ObjectEntryNameLength>50</ObjectEntryNameLength>
       <Source>request</Source>
       <StringValueLength>1000</StringValueLength>
    </JSONThreatProtection>
    

    โปรดสังเกตว่าองค์ประกอบ <Source> ชี้ไปที่ request. ซึ่งหมายความว่า เกิดข้อผิดพลาดขณะแยกวิเคราะห์เพย์โหลดคำขอ

  7. ระบุประเภทเพย์โหลดที่จะแยกวิเคราะห์โดยการตรวจสอบคำขอ API
  8. คุณสามารถตรวจสอบเนื้อหาของเพย์โหลดคำขอและส่วนหัว Content-Type ได้ใน คำขอ API ในคำสั่ง curl ตัวอย่างต่อไปนี้ ระบบจะใช้เพย์โหลด JSON

    curl -i https://VIRTUAL_HOST_ALIAS/BASEPATH -H "Content-Type: application/json" \
    -X POST -d @request-payload.json

    คุณอาจตรวจสอบนโยบายที่ล้มเหลวและระบุประเภทเพย์โหลด แยกวิเคราะห์แล้ว ในตัวอย่างข้างต้น นโยบาย JSON-Threat-Protection ล้มเหลว ซึ่งเป็นการระบุว่าเพย์โหลดต้องอยู่ในรูปแบบ JSON

  9. ตรวจสอบว่าเพย์โหลดอยู่ในรูปแบบที่ถูกต้องหรือไม่ หากเพย์โหลดไม่ถูกต้อง คุณอาจเห็นข้อผิดพลาดนี้

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

    ขึ้นอยู่กับเพย์โหลดที่นโยบายแยกวิเคราะห์ (ตามที่กำหนดไว้ในขั้นตอนที่ 6) ตรวจสอบเนื้อหาเพย์โหลดในเครื่องมือติดตามในระยะที่เหมาะสม

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

    alt_text

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

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

    ในทำนองเดียวกัน หากระบบแยกวิเคราะห์เพย์โหลดการตอบกลับเมื่อเกิดข้อผิดพลาด ให้ตรวจสอบ เนื้อหาการตอบกลับในระยะ "การตอบกลับจากเซิร์ฟเวอร์เป้าหมาย"

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

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

    <ProxyEndpoint name="default">
    ...
      <HTTPProxyConnection>
        <BasePath>/v1/weather</BasePath>
        <VirtualHost>secure</VirtualHost>
        <Properties>
          <Property name="response.streaming.enabled">true</Property>
          <Property name="request.streaming.enabled">true</Property>
        </Properties>
      </HTTPProxyConnection>
    </ProxyEndpoint>
    

    ดังที่เห็นในตัวอย่างข้างต้น ได้มีการเปิดใช้สตรีมมิงคำขอตามที่ระบุโดย ตั้งค่าคุณสมบัติ "request.streaming.enabled" เป็น "จริง"

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

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

  12. คุณตรวจสอบได้ว่าข้อผิดพลาด 500 เกิดจากนโยบายดังกล่าวหรือไม่ โดยตรวจสอบค่า ของ &quot;X-Apigee-fault-source&quot; ใน "AX" (บันทึกข้อมูล Analytics) ช่วงการติดตามโดยใช้ขั้นตอนที่ระบุไว้ด้านล่าง
    1. คลิกระยะ "AX" (ข้อมูลที่ Analytics บันทึกไว้) ดังที่แสดงในภาพหน้าจอด้านล่าง

      alt_text

    2. เลื่อนลงไปที่ "ส่วนหัวข้อผิดพลาด" และ ระบุค่าของ "X-Apigee-fault-code" &quot;X-Apigee-fault-source&quot; และ "X-Apigee-fault-policy" ดังที่แสดงด้านล่าง

      alt_text

    3. หากค่าของ &quot;X-Apigee-fault-source&quot; เป็น "policy" ตามที่แสดง ในภาพด้านบน คุณจะเห็นว่าข้อผิดพลาดเกิดจากการที่นโยบายเข้าถึง เพย์โหลดเมื่อเปิดใช้สตรีมมิง

ความละเอียด

การเข้าถึงเพย์โหลดที่เปิดใช้สตรีมมิงเป็นลายพยากรณ์ที่อธิบายใน Antipattern: เข้าถึงเพย์โหลดคำขอ/คำตอบเมื่อเปิดใช้สตรีมมิง

  1. หากต้องการประมวลผลเพย์โหลด คุณต้องปิดใช้สตรีมมิงใน Proxy/Target ปลายทางโดยนำพร็อพเพอร์ตี้ "request.streaming.enabled" and "response.streaming.enabled" ออกดังที่แสดงในตัวอย่าง ProxyEndpoint ด้านล่าง วันที่
    <ProxyEndpoint name="default">
    ...
      <HTTPProxyConnection>
        <BasePath>/v1/weather</BasePath>
        <VirtualHost>secure</VirtualHost>
      </HTTPProxyConnection>
    </ProxyEndpoint>
    

    หรือ

  2. หากคุณต้องการใช้สตรีมมิงสำหรับพร็อกซี API โปรดอย่าใช้นโยบายใดๆ ใน พร็อกซี API ที่เข้าถึงเพย์โหลดคำขอ/การตอบกลับ

หมายเหตุ:

  • ใน Playbook นี้มีการใช้นโยบาย JSONThreatProtection เพื่อประมวลผลเพย์โหลดคำขอด้วย เปิดใช้สตรีมมิงในสถานการณ์ตัวอย่าง ซึ่งทำให้เกิดข้อผิดพลาดภายในเซิร์ฟเวอร์ 500 รายการแต่มีข้อผิดพลาดต่างกัน
  • ข้อผิดพลาดเหล่านี้ยังเห็นด้วยนโยบายต่างๆ เช่น JSONToXML และ XMLToJSON ซึ่งประมวลผล เพย์โหลดคำขอหรือการตอบกลับเมื่อเปิดใช้สตรีมมิง
  • เราขอแนะนำไม่ให้ใช้นโยบายดังกล่าวใดๆ ในพร็อกซีที่ต้องมีการเข้าถึง เพย์โหลดเมื่อเปิดใช้สตรีมมิง
  • การทำเช่นนี้เป็น สิ่งปฏิกูลตามที่ระบุไว้ในเอกสาร Antipattern: เข้าถึงเพย์โหลดคำขอ/คำตอบเมื่อเปิดใช้สตรีมมิง

วิเคราะห์ปัญหาโดยใช้การตรวจสอบ API

หากคุณเป็นผู้ใช้ Private Cloud ให้ข้ามขั้นตอนนี้

การตรวจสอบ API ช่วยให้คุณแยกส่วนที่เป็นปัญหาได้อย่างรวดเร็วเพื่อวินิจฉัยปัญหาด้านข้อผิดพลาด ประสิทธิภาพ และเวลาในการตอบสนอง รวมถึงแหล่งที่มาของปัญหานั้นๆ เช่น แอปของนักพัฒนาซอฟต์แวร์, พร็อกซี API, เป้าหมายแบ็กเอนด์ หรือแพลตฟอร์ม API

ดูตัวอย่างสถานการณ์ที่แสดงวิธีแก้ปัญหา 5xx เกี่ยวกับ API โดยใช้การตรวจสอบ API เช่น คุณอาจต้องการตั้งค่าการแจ้งเตือนเมื่อจำนวนข้อผิดพลาด 500 รายการเกินเกณฑ์ที่ต้องการ

หากต้องการรับการแจ้งเตือนเมื่อมีการส่งการตอบกลับข้อผิดพลาด 500 จากนโยบาย คุณต้องตั้งค่าการแจ้งเตือนสำหรับรหัสสถานะ 500 ที่มีแหล่งที่มาของข้อผิดพลาดเป็นพร็อกซี

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

หากปัญหายังคงอยู่แม้ว่าจะทำตามคำแนะนำด้านบนแล้ว โปรดรวบรวมข้อมูลการวินิจฉัยต่อไปนี้ ติดต่อและแชร์กับทีมสนับสนุนของ Apigee

หากคุณเป็นผู้ใช้ระบบคลาวด์สาธารณะ ให้ระบุข้อมูลต่อไปนี้

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

หากคุณเป็นผู้ใช้ Private Cloud ให้ระบุข้อมูลต่อไปนี้

  • พบข้อความแสดงข้อผิดพลาดทั้งหมดสำหรับคำขอที่ล้มเหลว
  • องค์กร ชื่อสภาพแวดล้อม และชื่อพร็อกซี API ที่คุณสังเกตเห็นข้อผิดพลาด 500
  • แพ็กเกจพร็อกซี API
  • เพย์โหลดที่ใช้ในคำขอ (หากมี)
  • ไฟล์การติดตามที่มีคำขอที่มีข้อผิดพลาดภายในเซิร์ฟเวอร์ 500
  • บันทึกการเข้าถึง NGINX (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log)
  • บันทึกสำหรับผู้ประมวลผลข้อมูลข้อความ (/opt/apigee/var/log/edge-message-processor/logs/system.log)
  • ช่วงเวลาที่มีข้อมูลเขตเวลาเมื่อเกิดข้อผิดพลาด 500