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

สาเหตุ: ไม่มี MP ในพูล

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

Apigee Edge คือมีการกำหนดค่าในลักษณะที่การรับส่งข้อมูล API ขาเข้า (คำขอ) ในภูมิภาค/ศูนย์ข้อมูลที่ระบุจะมีการกำหนดเส้นทางจากเราเตอร์ไปยังตัวประมวลผลข้อความ (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 ที่ไม่ดีซึ่งมาจากเซิร์ฟเวอร์แบ็กเอนด์
  2. หากปัญหาเกิดขึ้นในบางช่วงเวลาและคุณไม่สามารถจับภาพการติดตามได้
    1. หากคุณเป็นผู้ใช้ระบบคลาวด์สาธารณะ คุณอาจใช้การตรวจสอบ API และตรวจสอบรายละเอียดเกี่ยวกับข้อผิดพลาด 502 ได้
      1. หากคุณสังเกตเห็นว่ารหัสข้อผิดพลาดคือ 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. หากคุณสังเกตเห็นว่ารหัสข้อผิดพลาดคือ 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)