502 เกตเวย์ไม่ถูกต้อง

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

ลักษณะปัญหา

แอปพลิเคชันไคลเอ็นต์ได้รับรหัสสถานะ HTTP 502 พร้อมข้อความ "เกตเวย์ไม่ถูกต้อง" เป็นการตอบสนองสำหรับการเรียก API

รหัสสถานะ HTTP 502 หมายความว่าไคลเอ็นต์ไม่ได้รับการตอบสนองที่ถูกต้องจาก เซิร์ฟเวอร์แบ็กเอนด์ที่ ควรดำเนินการตามคำขอจริงๆ

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

แอปพลิเคชันไคลเอ็นต์ได้รับโค้ดตอบกลับต่อไปนี้

HTTP/1.1 502 Bad Gateway

นอกจากนี้ คุณอาจสังเกตเห็นข้อความแสดงข้อผิดพลาดต่อไปนี้

<html>
<head>
<title>Error</title>
<style>
body {
width: 35em;
margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif;
}
</style>
</head>
<body>
<h1>An error occurred.</h1>
<p>Sorry, the page you are looking for is currently unavailable.<br/>
Please try again later.</p>
</body>
</html>

หากข้อผิดพลาดมาจากเซิร์ฟเวอร์แบ็กเอนด์ คุณอาจเห็นข้อผิดพลาดในลักษณะนี้ ข้อความแสดงข้อผิดพลาดจากแบ็กเอนด์จะขึ้นอยู่กับการติดตั้งใช้งานทั้งหมด 

<html>
<head><title>502 Bad Gateway</title></head>
<body bgcolor="white">
<center><h1>502 Bad Gateway</h1></center>
</body>
</html>

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

สาเหตุที่เป็นไปได้บางประการที่อาจทำให้เกิดข้อผิดพลาด 502 Bad Gateway สำหรับ API ที่ดำเนินการผ่าน Apigee Edge มีดังนี้

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

สาเหตุ: ไม่มี MP ที่ใช้ได้ในกลุ่ม

ข้อผิดพลาดนี้จะเกิดขึ้นหากเราเตอร์พบว่าตัวประมวลผลข้อความทั้งหมดในภูมิภาค/ศูนย์ข้อมูลที่ระบุไม่พร้อมใช้งาน (ตัวอย่างเช่น หากเราเตอร์ล่มทั้งหมด)

Apigee Edge มีการกำหนดค่าให้การรับส่งข้อมูล API ขาเข้า (คำขอ) ในภูมิภาค/ศูนย์ข้อมูลที่กำหนดจะมีการกำหนดเส้นทางจากเราเตอร์ไปยัง Message Processor (MP) ในภูมิภาค/ศูนย์ข้อมูลเดียวกันเสมอ ในบางกรณี คอมโพเนนต์ Apigee Edge อาจมีการตั้งค่าในภูมิภาค/ศูนย์ข้อมูลเพียงแห่งเดียว และในบางกรณีอาจมีการตั้งค่ามากกว่า 1 ภูมิภาค/ศูนย์ข้อมูล ในแต่ละภูมิภาค/ศูนย์ข้อมูลจะมีการกำหนดค่าเราเตอร์และตัวประมวลผลข้อความตั้งแต่ 2 รายการขึ้นไป

การวินิจฉัย

  1. ระบุภูมิภาค/ศูนย์ข้อมูลที่คำขอ API ล้มเหลวโดยมีข้อผิดพลาด 502 เกตเวย์ไม่ถูกต้อง หากมีมากกว่า 1 ภูมิภาค/ศูนย์ข้อมูล ซึ่งสามารถค้นหาได้โดยการระบุภูมิภาคที่ผู้ใช้กำลังสังเกตข้อผิดพลาด 502 หรือโดยการตรวจสอบบันทึกการเข้าถึง NGINX ในไดเรกทอรี /opt/apigee/var/log/edge-router/nginx/ บนเราเตอร์แต่ละตัวที่อยู่ในภูมิภาคต่างๆ
  2. คุณจะเห็นข้อผิดพลาดต่อไปนี้ในบันทึกข้อผิดพลาดของ NGINX (/opt/apigee/var/log/edge-router/nginx/ORG-Env._error_log)
    2019/06/24 15:26:00 [error] 4796#4796: *56357443 no live upstreams while connecting to upstream, client: <Router_IP_address>, server: <HostAlias>, request: "PUT <BasePath> HTTP/1.1", upstream: "http://<ListOfMP-IP_R-MP-Port>/<BasePath>", host: "<HostAlias>"

สถานการณ์ที่ 1: ตัวประมวลผลข้อความหยุดทำงาน

  1. ตรวจสอบว่าระบบประมวลผลข้อความในภูมิภาค/ศูนย์ข้อมูลที่ระบุทำงานอยู่หรือไม่
  2. หากตัวประมวลผลข้อความไม่ทำงาน ให้เริ่มต้นระบบใหม่

ความละเอียด

รีสตาร์ทโปรเซสเซอร์ข้อความทั้งหมดโดยใช้คำสั่งต่อไปนี้

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

สถานการณ์ที่ 2: ผู้ประมวลผลข้อมูลข้อความทั้งหมดไม่ว่างที่จะประมวลผลคำขอที่ต่อเนื่อง

ข้อผิดพลาดนี้จะเกิดขึ้นหากเราเตอร์พบว่าเครื่องมือประมวลผลข้อความทั้งหมดทั้งหมดในภูมิภาค/ศูนย์ข้อมูลที่ระบุไม่พร้อมใช้งาน เนื่องจากเราเตอร์เหล่านั้นไม่ว่างเนื่องจากประมวลผลคำขอที่กำลังดำเนินอยู่

  1. ตรวจสอบว่าระบบประมวลผลข้อความในภูมิภาค/ศูนย์ข้อมูลที่ระบุทำงานอยู่หรือไม่
  2. หากตัวประมวลผลข้อความทำงานและใช้งานอยู่ จากนั้นตรวจสอบว่าโปรเซสเซอร์ข้อความมีการใช้ CPU สูงหรือไม่ จากนั้นสร้างเทรดดัมพ์ 3 ชุดทุกๆ 30 วินาทีโดยใช้คำสั่งต่อไปนี้
    วันที่
    <JAVA_HOME>/bin/jstack -l <pid> > <filename>
  3. หากตัวประมวลผลข้อความมีการใช้หน่วยความจำสูง ให้สร้างฮีปดัมป์โดยใช้คำสั่งต่อไปนี้
    วันที่
    sudo -u apigee /bin/jmap -dump:live,format=b,file=
  4. รีสตาร์ทโปรแกรมประมวลผลข้อความโดยใช้คำสั่งด้านล่าง ทำให้ CPU และหน่วยความจำลดลง:
    วันที่
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
  5. ตรวจสอบการเรียก API เพื่อยืนยันว่าปัญหายังคงอยู่หรือไม่
  6. ติดต่อทีมสนับสนุนของ Apigee และส่งเทรดดัมพ์ ฮีปดัมป์ และบันทึกตัวประมวลผลข้อความ (/opt/apigee/var/log/edge-message-processor/logs/system.log) เพื่อช่วยตรวจสอบสาเหตุที่ทำให้มีการใช้งาน CPU/หน่วยความจำสูง

สาเหตุ: การกำหนดค่า SSL ระหว่างเราเตอร์และ MP ไม่ถูกต้อง

การวินิจฉัย

  1. ตรวจสอบบันทึกการเข้าถึง NGINX (/opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log) คุณจะเห็นการตอบกลับ 502 ดังที่แสดงด้านล่าง
        2019-07-23T12:13:42+03:00	sc-10-254-226-23	10.X.X.X:53634	10.X.X.X:8998	0.000	-	-	502	502	189	344	GET <path> curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.27.1 zlib/1.2.3 libidn/1.18 libssh2/1.4.2	<host alias>	mp-10-254-226-23-23706-8552529-1	10.129.107.101	-	-	-1	-	-	dc-2	gateway-2	green	-	gateway-2	dc-2	op	pilot	http	-
  2. ตรวจสอบบันทึกข้อผิดพลาดของ NGINX (/opt/apigee/var/log/edge-router/nginx/ORG-Env._error_log) คุณจะเห็นข้อผิดพลาดดังนี้
    	2019/07/30 17:02:24 [error] 7691#7691: *11753633 peer closed connection in SSL handshake while SSL handshaking to upstream, client: X.X.X.X, server: <HostAlias>, request: "GET /no-target HTTP/1.1", upstream: "https://X.X.X.X:8998/no-target", host: "<HostAlias>"
  3. ซึ่งจะแสดงแฮนด์เชค SSL ที่ล้มเหลวระหว่างเราเตอร์และตัวประมวลผลข้อความ
  4. หากคุณเห็นข้อความแสดงข้อผิดพลาดในขั้นตอนที่ 1 และ #2 อย่างถี่ถ้วน พอร์ต # ที่ใช้ในการสื่อสารกับตัวประมวลผลข้อความคือ 8998 ซึ่งเป็นพอร์ตที่ไม่ปลอดภัยแต่โปรโตคอลเป็น SSL (https) โดยปกติ # พอร์ตที่ปลอดภัยที่ใช้คือ 8443 และเนื่องจากมีการใช้พอร์ตที่ไม่ปลอดภัยสำหรับการสื่อสารที่มีการรักษาความปลอดภัย ทำให้แฮนด์เชค SSL ล้มเหลว
  5. โดยทั่วไปแล้ว ปัญหานี้อาจเกิดขึ้นได้หากคุณพลาดขั้นตอนใดไป หรือกำหนดค่าไม่ถูกต้องขณะกำหนดค่า SSL ระหว่างเราเตอร์และโปรแกรมประมวลผลข้อความ โปรดดูขั้นตอนที่ระบุไว้ที่นี่
    ตัวอย่างเช่น ข้อผิดพลาดนี้อาจเกิดขึ้นหาก
    1. พอร์ต # ระบุเป็น 8998 แทนที่จะเป็น 8443 ใน /opt/apigee/customer/application/message-processor.properties as shown below
              conf/message-processor-communication.properties+local.http.port=8998
    2. ไฟล์การกำหนดค่าเราเตอร์ภายใต้ไดเรกทอรี /opt/nginx/conf.d/* จะไม่ถูกลบและยังไม่ได้รีสตาร์ทเราเตอร์ขณะกำหนดค่า SSL ในกรณีนี้ คุณจะเห็นว่าพอร์ต# ของตัวประมวลผลข้อความยังคงเป็น 8998 ในไฟล์การกำหนดค่า

ความละเอียด

  1. ตรวจสอบว่าได้ปฏิบัติตามขั้นตอนทั้งหมดในการกำหนดค่า TLS ระหว่างเราเตอร์และตัวประมวลผลข้อความอย่างถูกต้อง
  2. หากยังคงพบปัญหา ให้ไปที่รวบรวมข้อมูลการวินิจฉัย

สาเหตุ: เกิดข้อผิดพลาดจากเซิร์ฟเวอร์แบ็กเอนด์

การวินิจฉัย

  1. หากเกิดข้อผิดพลาดทุกครั้ง คุณจะบันทึกการติดตาม UI สำหรับคำขอที่ไม่สำเร็จได้ เลือกคำขอที่ล้มเหลวและไปยังระยะต่างๆ ในการติดตาม หากคุณสังเกตเห็นว่าคุณได้รับ "502 Bad Gateway" จากเซิร์ฟเวอร์แบ็กเอนด์เอง ปัญหาอาจเกิดจากการทำงานล้มเหลวบางอย่างในเซิร์ฟเวอร์แบ็กเอนด์
    การติดตามแสดง 502 Bad Gateway มาจากเซิร์ฟเวอร์แบ็กเอนด์
  2. หากปัญหาเกิดขึ้นเป็นครั้งคราวและคุณจับภาพการติดตามไม่ได้
    1. หากคุณเป็นผู้ใช้ระบบคลาวด์สาธารณะ คุณสามารถใช้การตรวจสอบ API และตรวจสอบรายละเอียดเกี่ยวกับข้อผิดพลาด 502 ได้
      1. หากคุณสังเกตเห็นว่า Fault Code คือ messaging.adaptors.http.flow.ErrorResponseCode และแหล่งที่มาของข้อผิดพลาดคือ target แสดงว่าข้อผิดพลาดเกิดจากเซิร์ฟเวอร์แบ็กเอนด์
    2. หากคุณเป็นผู้ใช้ Private Cloud คุณก็วิเคราะห์บันทึกการเข้าถึง NGINX
      ได้ วันที่ /opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log.
      คุณจะเห็นรายการสำหรับคำขอที่ไม่สำเร็จดังนี้
      2017-02-24T14:42:12+00:00	rt-01	192.8.155.2:18118	192.168.84.166:8998	10.225	-	-	502	502	440	0	GET /adv-eadlg-test/documents?type=doctype HTTP/1.1	rt-02efawae234-1234	Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36	myorg-dev.apigee.net	 rt-02efawae234-1234	6	-	false	target	messaging.adaptors.http.flow.ErrorResponseCode	null/null	-	/organizations/myorg/environments/dev/apiproxies/api123
      1. หากคุณสังเกตเห็นว่า Fault Code คือ messaging.adaptors.http.flow.ErrorResponseCode และแหล่งที่มาของข้อผิดพลาดคือ target แสดงว่าข้อผิดพลาดเกิดจากเซิร์ฟเวอร์แบ็กเอนด์

ความละเอียด

  1. ทำงานร่วมกับทีมเซิร์ฟเวอร์แบ็กเอนด์เพื่อแก้ไขปัญหานี้ในแบ็กเอนด์

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

  1. บันทึกการเข้าถึง NGINX
    (/opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log)
    และบันทึกข้อผิดพลาด
    (/opt/apigee/var/log/edge-router/nginx/ORG-Env._error_log)
  2. บันทึกสำหรับผู้ประมวลผลข้อมูลข้อความ
    (/opt/apigee/var/log/edge-message-processor/logs/system.log)