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:

הסיבה תיאור הוראות לפתרון בעיות שרלוונטיות
אין במאגר חברי קבוצה זמינים השגיאה הזו מתקבלת אם כל ערכי ה-MP במאגר לא זמינים. כלומר, הם לא פעילים או לא פעילים, ולכן לא מגיבים. משתמשי ענן פרטי ב-Edge
תצורה שגויה של SSL בין נתבים ל-MP השגיאה הזו מתקבלת אם אישור הבסיס החתום של ה-CA של הלקוח חסר ב-Truststore של הנתב של Edge. משתמשי ענן פרטי ב-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: כל מעבדי ההודעות עסוקים בעיבוד בקשות מתמשכות

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

  1. בודקים אם מעבדי ההודעות באזור או במרכז הנתונים הספציפיים פועלים.
  2. אם כל מעבדי ההודעות פועלים ופעילים, צריך לבדוק אם מעבדי ההודעות סובלים משימוש גבוה במעבד (CPU), ואז יוצרים שלושה קובצי מצב של תהליכונים (threads) כל 30 שניות, באמצעות הפקודה הבאה:
    <JAVA_HOME>/bin/jstack -l <pid> > <filename>
  3. אם יש שימוש גבוה בזיכרון במעבדי ההודעות, יש ליצור תמונת מצב של הזיכרון באמצעות הפקודה הבאה:
    sudo -u apigee /bin/jmap -dump:live,format=b,file=
  4. מפעילים מחדש את מעבד ההודעות באמצעות הפקודה הבאה. השימוש במעבד (CPU) ובזיכרון אמור להפחית את כמות המעבד (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) כדי לבדוק מה הסיבה לשימוש הגבוה במעבד או בזיכרון.

הסיבה: הגדרה שגויה של 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. אם השגיאה מתרחשת בכל פעם, אפשר לתעד את המעקב אחר ממשק המשתמש לגבי הבקשות שנכשלו. בוחרים בקשה שנכשלה ומנווטים בין השלבים השונים במעקב. אם מופיעה ההודעה ' 502 Bad Gateway' משרת הקצה העורפי עצמו, יכול להיות שהסיבה לכך היא שמשהו השתבש בשרת בקצה העורפי.
    מעקב שמראה 502 Bad Gateway מגיע משרת הקצה העורפי
  2. אם הבעיה מתרחשת לסירוגין ולא ניתן לתעד את המעקב,
    1. אם אתם משתמשים בענן ציבורי, אתם יכולים להשתמש ב-API Monitoring ולבדוק את הפרטים לגבי השגיאות מסוג 502.
      1. אם מופיע קוד השגיאה messaging.adaptors.http.flow.ErrorResponseCode ומקור התקלה הוא target, השגיאה נגרמת על ידי שרת הקצה העורפי.
    2. משתמשים בענן פרטי יכולים לנתח את יומני הגישה של 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).