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

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

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

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

אבחון

  1. לזהות את האזור/מרכזי הנתונים שבהם בקשות ה-API נכשלות ומוצגת שגיאה 502 בשם 'שער שגוי', אם יש יותר מאזור אחד או מרכז נתונים אחד. כדי למצוא זאת, אפשר לזהות את האזור שבו המשתמשים מעיינים בשגיאות 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), ולאחר מכן ליצור שלושה dumps של שרשורים כל 30 שניות באמצעות הפקודה הבאה:
    <JAVA_HOME>/bin/jstack -l <pid> > <filename>
  3. אם מעבדי ההודעות משתמשים בזיכרון בתדירות גבוהה, יש ליצור Dump של ערימה באמצעות הפקודה הבאה:
    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 ולספק את הנתונים של קובצי dump של שרשור, Dump של ערימה ויומנים של מעבד ההודעות (/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. בתרחיש הזה, ניתן לראות שמס' היציאה של מעבדי ההודעות יישאר 8,998 בקובצי התצורה.

רזולוציה

  1. מוודאים שכל השלבים בהגדרת TLS בין נתב לבין מעבד הודעות מתקיימים באופן תקין.
  2. אם הבעיה נמשכת, עוברים אל איסוף פרטי אבחון.

הסיבה: שגיאה משרת הקצה העורפי

אבחון

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