502 שער שגוי

אתם צופים במסמכי התיעוד של Apigee Edge.
כדאי לעיין במסמכי התיעוד של Apigee X. מידע

תיאור הבעיה

אפליקציית הלקוח מקבלת קוד סטטוס של HTTP‏ 502 עם ההודעה "Bad Gateway" כתגובה לקריאות ל-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:

הסיבה: אין חברי פרלמנט זמינים במאגר

השגיאה הזו תתרחש אם נתב יגלה שכל מעבדי ההודעות באזור או במרכז נתונים מסוים לא זמינים (לדוגמה, אם כולם מושבתים).

מערכת Apigee Edge מוגדרת כך שתנועת ה-API הנכנסת (בקשות) באזור או במרכז נתונים מסוים תמיד מנותבת מהנתבים למעבדי ההודעות (MPs) באותו אזור או מרכז נתונים. במקרים מסוימים, יכול להיות שרכיבי Apigee Edge יוגדרו רק באזור אחד או במרכז נתונים אחד, ובמקרים אחרים הם יוגדרו ביותר מאזור אחד או ביותר ממרכז נתונים אחד. בכל אזור או מרכז נתונים יוגדרו שני נתבים או יותר ומעבדי הודעות.

אבחון

1. אם יש יותר מאזור או מרכז נתונים אחד, צריך לקבוע את האזור או מרכז הנתונים שבהם בקשות ה-API נכשלות עם השגיאה 502 Bad Gateway. אפשר לזהות את האזור שבו המשתמשים רואים שגיאות 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: כל מעבדי ההודעות עסוקים בעיבוד בקשות שוטפות

השגיאה הזו מתרחשת אם נתבי ה-Router מזהים שכל מעבדי ההודעות באזור או במרכז נתונים מסוים לא זמינים, כי כולם עסוקים בעיבוד בקשות שמתבצעות כרגע.

1. בודקים אם מעבדי ההודעות באזור הספציפי או במרכז הנתונים הספציפי פועלים.
2. אם כל מעבדי ההודעות פועלים ופעילים, בודקים אם יש שימוש גבוה ב-CPU של מעבדי ההודעות, ואז יוצרים שלוש תמונות מצב של השרשור כל 30 שניות באמצעות הפקודה הבאה:
   

   <JAVA_HOME>/bin/jstack -l <pid> > <filename>

3. אם מעבד ההודעות צורך הרבה שימוש בזיכרון, צריך ליצור תמונת מצב של הזיכרון באמצעות הפקודה הבאה:
   

   sudo -u apigee /bin/jmap -dump:live,format=b,file= 

4. מפעילים מחדש את מעבד ההודעות באמצעות הפקודה שלמטה. השימוש במעבד ובזיכרון צריך לרדת:
   

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

5. כדאי לעקוב אחרי הקריאות ל-API כדי לוודא שהבעיה עדיין קיימת.
6. כדי לחקור את הסיבה לשימוש הגבוה ב-CPU או בזיכרון, אפשר לפנות אל התמיכה של Apigee ולספק את קובצי ה-thread dumps, את קובץ ה-heap dump ואת היומנים של Message Processor ‏ (/opt/apigee/var/log/edge-message-processor/logs/system.log).

הסיבה: הגדרת SSL שגויה בין נתבים לבין מעבדי הודעות

אבחון

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. אם השגיאה מתרחשת בכל פעם, אפשר לצלם את המעקב בממשק המשתמש עבור הבקשות שנכשלו. בוחרים בקשה שנכשלה ועוברים בין השלבים השונים ב-trace. אם אתם מקבלים את השגיאה '502 Bad Gateway' מהשרת העורפי עצמו, יכול להיות שהבעיה היא שקרה כשל כלשהו בשרת העורפי.
   Trace showing 502 Bad Gateway coming from the backend server
   
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).