503 שירות לא זמין

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

סרטונים

מידע נוסף על שגיאות 503 זמין בסרטונים הבאים:

וידאו תיאור
פתרון בעיות שקשורות ל-DNS וגורמות לשגיאה '503 השירות לא זמין' מידע על הנושאים הבאים:
  • שגיאה 503 Service Unavailable (השירות לא זמין) שנגרמת בגלל פענוח DNS ובעיות שקשורות לרשת ב-Apigee Edge
  • פתרון בעיות וטיפול בשגיאה בזמן אמת 503 Service Unavailable שנגרמת בגלל בעיה בפענוח DNS
פתרון בעיות של שגיאה 503 'השירות לא זמין' בגלל בעיה ברשת פתרון בעיות של שגיאת 503 Service Unavailable בזמן אמת שנגרמת בגלל בעיה ברשת ב-Apigee Edge

תיאור הבעיה

אחרי קריאה ל-proxy ל-API, אפליקציית הלקוח מקבלת סטטוס תגובת HTTP‏ 503 עם ההודעה Service Unavailable (השירות לא זמין).

הודעות שגיאה

יכול להיות שתופיע הודעת השגיאה הבאה:

HTTP/1.1 503 Service Unavailable

אפשר גם לראות את הודעת השגיאה הבאה בתגובת ה-HTTP:

השירות לא זמין

{
   "fault": {
      "faultstring": "The Service is temporarily unavailable",
      "detail": {
           "errorcode": "messaging.adaptors.http.flow.ServiceUnavailable"
       }
    }
}

גורמים אפשריים

תגובת ה-HTTP‏ 503 Service Unavailable עם קוד השגיאה messaging.adaptors.http.flow.ServiceUnavailable מתרחשת אם מעבד ההודעות של Apigee Edge נתקל בשגיאות בגלל פסק זמן של החיבור, שם מארח שגוי או כשלים בתהליך ה-SSL במהלך התקשורת עם שרת הקצה העורפי.

סיבות אפשריות לתגובה 503 Service Unavailable:

סיבה תיאור מי יכול לבצע את השלבים לפתרון בעיות
שגיאות חיבור בגלל פענוח DNS שגוי רזולוציית ה-DNS של שרת היעד הניבה כתובות IP שגויות שמובילות לשגיאות בחיבור. משתמשים ב-Edge Private Cloud
שגיאות חיבור בעיות ברשת או בקישוריות מונעות מהלקוח להתחבר לשרת. משתמשים ב-Edge Private Cloud
שם המארח של שרת היעד שגוי המארח של שרת היעד שצוין שגוי או מכיל תווים לא רצויים (כמו רווח). משתמשים ב-Edge Public Cloud וב-Edge Private Cloud
כשלים בלחיצת היד של SSL לחיצת היד של TLS/SSL בין הלקוח לשרת נכשלה. (פתרון בעיות שקשורות לסוג הזה של הבעיה מוסבר בנושא נפרד). משתמשים ב-Edge Public Cloud וב-Edge Private Cloud

שלבים נפוצים לאבחון

קביעת מזהה ההודעה של הבקשה שנכשלה

כלי המעקב

כדי לקבוע את מזהה ההודעה של הבקשה שנכשלה באמצעות הכלי Trace:

  1. אם הבעיה עדיין פעילה, מפעילים את trace session עבור ה-API המושפע.
  2. מבצעים את הקריאה ל-API ומשחזרים את הבעיה – 503 Service Unavailable עם קוד השגיאה messaging.adaptors.http.flow.ServiceUnavailable.
  3. בוחרים אחת מהבקשות שנכשלו.
  4. עוברים אל שלב AX וקובעים את מזהה ההודעה (X-Apigee.Message-ID) של הבקשה על ידי גלילה למטה בקטע פרטי השלב, כמו שמוצג באיור הבא.

    מזהה ההודעה בקטע 'פרטי השלב'

יומני גישה של NGINX

כדי לקבוע את מזהה ההודעה של הבקשה שנכשלה באמצעות יומני הגישה של NGINX:

אפשר גם לעיין ביומני הגישה של NGINX כדי לזהות את מזהה ההודעה של שגיאות 503. האפשרות הזו שימושית במיוחד אם הבעיה התרחשה בעבר או אם הבעיה מתרחשת לסירוגין ואין אפשרות לצלם את הנתונים בממשק המשתמש. כדי לקבוע את המידע הזה מיומני הגישה של NGINX:

  1. בודקים את יומני הגישה של NGINX:‏ (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log)
  2. מחפשים אם יש שגיאות 503 עבור ה-proxy ל-API הספציפי במהלך משך זמן מסוים (אם הבעיה התרחשה בעבר) או אם יש בקשות שעדיין נכשלות עם שגיאה 503.
  3. אם יש שגיאות 503 עם X-Apigee-fault-code messaging.adaptors.http.flow.ServiceUnavailable, שימו לב למזהה ההודעה של בקשה אחת או יותר כאלה, כמו שמוצג בדוגמה הבאה:

    דוגמה לערך שבו מוצגת השגיאה 503

    דוגמה לרשומה שבה מוצגים קוד סטטוס, מזהה הודעה, מקור השגיאה וקוד השגיאה

שגיאות בחיבור עקב פענוח DNS שגוי

אבחון

  1. קובעים את מזהה ההודעה של הבקשה שנכשלה.
  2. מחפשים את מזהה הודעת הבקשה הספציפית ביומן של מעבד ההודעות (/opt/apigee/var/log/edge-message-processor/logs/system.log). יכול להיות שתופיע אחת מהשגיאות הבאות:

    שגיאת onConnectTimeout מציינת שמעבד ההודעות לא הצליח להתחבר לשרת העורפי במסגרת הזמן הקצוב לתפוגה של החיבור (ברירת מחדל: 3 שניות). 
    2019-08-14 09:11:49,314 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onTimeout() : ClientChannel[Connected:]@164162 useCount=1 bytesRead=0 bytesWritten=0 age=3001ms lastIO=3001ms .onConnectTimeout connectAddress=www.abc.com/11.11.11.11  resolvedAddress=www.abc.com/22.22.22.22

2019-08-14 09:11:49,333 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - RequestWriteListener.onTimeout() : RequestWriteListener.onTimeout(HTTPRequest@6b393600)
  3. שימו לב לכתובת ה-IP שפוענחה בשגיאה onConnectTimeout ובדקו אם כתובת ה-IP תקפה לשרת העורפי. אם כתובת ה-IP תקינה, עוברים אל שגיאות חיבור.
  4. אם כתובת ה-IP לא תקינה, סביר להניח שהבעיה נובעת מבעיות בפענוח DNS.
  5. חוזרים על שלב 3 ושלב 4 לכמה בקשות API שנכשלו, ובודקים אם מופיעות אותן כתובות IP לא תקינות או כתובות IP לא תקינות אחרות.
  6. מחפשים ביומן של מעבד ההודעות (/opt/apigee/var/log/edge-message-processor/logs/system.log) הודעות עם מילת המפתח DNS Refresh. בודקים אם כתובות IP לא תקינות או לא חוקיות מתווספות למטמון ה-DNS במעבד ההודעות מדי פעם. 
    2019-08-14 09:11:49,314 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@0 INFO c.a.p.h.d.DNSCachedAddress - DNSCachedAddress.reportDifferences() : DNS Refresh for host: apitarget-uat.schemeweb.co.uk:4436. Added 2 IPs [www.abc.com/22.22.22.22, www.abc.com/33.33.33.33] Removed 1 IPs [www.abc.com/11.11.11.11]
  7. הבעיה הזו יכולה לקרות אם יש בעיות בשרתי ה-DNS הסמכותיים או בשרתי השמות שהוגדרו ב-/etc/resolv.conf.

    בדרך כלל, יכול להיות שיהיה שרת DNS סמכותי אחד או יותר שמוגדרים לבצע פענוח DNS. אם אין שרתי DNS סמכותיים, המערכת תחזור להגדרות התצורה ב-/etc/resolv.conf ותבצע פענוח DNS לפי הצורך. לדוגמה: אם /etc/resolv.conf מוגדר להשתמש בשרתי שמות ספציפיים, שרתי השמות האלה ישמשו לביצוע פענוח ה-DNS.
  8. אם יש בעיות בשרתי DNS סמכותיים או בשרתי שמות שצוינו ב-/etc/resolv.conf, שמות המארחים של שרת הקצה העורפי יתורגמו לכתובות IP לא תקינות או לא חוקיות. כתובות ה-IP הלא תקינות יישמרו במטמון ה-DNS של מעבד ההודעות.
    1. אם הבעיה בשרתי DNS סמכותיים או בשרתי שמות שמצוינים ב-/etc/resolv.conf נמשכת, כתובות ה-IP הלא תקינות או הלא חוקיות יישארו במטמון ה-DNS של מעבד ההודעות. כל עוד כתובות ה-IP הבעייתיות מאוחסנות במטמון ה-DNS של מעבד ההודעות, הבקשות לכל ממשקי ה-API האלה באמצעות שרת הקצה העורפי הספציפי ייכשלו עם שגיאה 503.
    2. אם הבעיה בשרתי DNS סמכותיים או בשרתי שמות שצוינו ב-/etc/resolv.conf היא לסירוגין, כתובות IP טובות וגרועות יישמרו במטמון ה-DNS לסירוגין. במקרה כזה, תראו שגיאות 503 לסירוגין בכל ממשקי ה-API האלה שמשתמשים בשרת הספציפי לעורף.
  9. אם הבעיה בשרתי ה-DNS נמשכת, תראו כשלים חוזרים. אם הבעיה בשרתי ה-DNS מתרחשת מדי פעם, תראו כשלים מדי פעם. כלומר, בכל פעם ששם המארח של שרת הקצה העורפי מזוהה ככתובות IP לא תקינות, מוצגות שגיאות 503. וכששמות המארחים של שרת הקצה העורפי יזוהו ככתובות IP תקינות, תראו תגובות מוצלחות.

רזולוציה

צריך לעבוד עם מנהל מערכת ההפעלה ולפתור את הבעיות בשרתי ה-DNS.

  1. אם יש בעיה בשרתי ה-DNS הסמכותיים או בשרתי השמות שצוינו ב-/etc/resolv.conf, צריך לתקן את הבעיה בשרת המתאים כדי לפתור אותה.
  2. אם יש בעיה בהגדרה ב-/etc/resolv.conf במערכות שבהן מותקנים מעבדי הודעות, צריך לתקן את בעיית ההגדרה.

שגיאות התחברות

שגיאת חיבור מתרחשת כשמעבד הודעות של Apigee Edge מנסה להתחבר לשרת קצה עורפי ואחת מהבעיות הבאות מתרחשת:

  • מעבד הבקשות לא מצליח להתחבר במהלך זמן קצוב לתפוגה שהוגדר מראש. (ברירת מחדל: 3 שניות)
  • השרת העורפי דוחה את החיבור.

אבחון

  1. קובעים את מזהה ההודעה של הבקשה שנכשלה.
  2. מחפשים את מזהה הודעת הבקשה הספציפית ביומן של מעבד ההודעות (/opt/apigee/var/log/edge-message-processor/logs/system.log). יכול להיות שתיתקלו בשגיאות הבאות:
    1. שגיאת onConnectTimeout מציינת שמעבד ההודעות לא הצליח להתחבר לשרת העורפי במסגרת הזמן הקצוב לתפוגה של החיבור שהוגדר מראש. 
      2016-06-23 09:11:49,314 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@2 ERROR HTTP.CLIENT - HTTPClient$Context.onTimeout() : ClientChannel[C:]@10 useCount=1 bytesRead=0 bytesWritten=0 age=3001ms lastIO=3001ms .onConnectTimeout connectAddress=www.abc.com/11.11.11.11:80 resolvedAddress=www.abc.com/11.11.11.11
2016-06-23 09:11:49,333 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@2 ERROR ADAPTORS.HTTP.FLOW - RequestWriteListener.onTimeout() : RequestWriteListener.onTimeout(HTTPRequest@6b393600)
    2. השגיאה java.net.ConnectException: Connection refused מציינת שהחיבור נדחה על ידי שרת הקצה העורפי. 
      14:40:16.531 +0530
2016-06-17 09:10:16,531 org:myorg env:prod api:www.abc.com rev:1 rrt07eadn-22739-40983870-15 NIOThread@2 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() : connect to www.abc.com:11.11.11.11:443 failed with exception {}
java.net.ConnectException: Connection refused
at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) ~[na:1.7.0_75]
at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:739) ~[na:1.7.0_75]
at com.apigee.nio.ClientChannel.finishConnect(ClientChannel.java:121) ~[nio-1.0.0.jar:na]
at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:108) ~[nio-1.0.0.jar:na]
  3. בודקים אם אפשר להתחבר ישירות לשרת הספציפי של העורף מכל אחד ממעבדי ההודעות באמצעות הפקודה telnet:
    1. אם שרת הקצה העורפי מומר לכתובת IP יחידה, משתמשים בפקודה הבאה: 
      telnet BackendServer-IPaddress 443
    2. אם שרת הקצה העורפי מזהה כמה כתובות IP, צריך להשתמש בשם המארח של שרת הקצה העורפי בפקודה telnet כמו שמוצג בהמשך: 
      telnet BackendServer-HostName 443
  4. אם אתם מצליחים להתחבר לשרת הקצה העורפי, יכול להיות שתראו הודעה כמו Connected to backend-server. אם אתם לא מצליחים להתחבר לשרת העורפי, יכול להיות שזה קורה כי כתובות ה-IP של מעבדי ההודעות לא נכללות ברשימת ההיתרים בשרת העורפי הספציפי.

רזולוציה

צריך לתת גישה לכתובות ה-IP של מעבד ההודעות בשרת הקצה העורפי הספציפי כדי לאפשר לתנועה ממעבדי ההודעות של Edge לגשת לשרת הקצה העורפי. לדוגמה, ב-Linux, אפשר להשתמש ב-iptables כדי לאפשר את התנועה מכתובות ה-IP של מעבד ההודעות בשרת העורפי.

אם הבעיה נמשכת, צריך לעבוד עם האדמין של הרשת כדי לזהות ולפתור את הבעיה. אם אתם צריכים עזרה נוספת מ-Apigee, אתם יכולים לפנות אל התמיכה של Apigee.

שם המארח של שרת היעד שגוי

אבחון

אם שם המארח שצוין בשרת היעד שגוי, יכול להיות שתקבלו תגובה 503 השירות לא זמין עם קוד השגיאה messaging.adaptors.http.flow.ServiceUnavailable.

כלי המעקב

כדי לאבחן באמצעות הכלי 'מעקב':

  1. אם הבעיה עדיין פעילה, מפעילים את trace session עבור ה-API המושפע.
  2. מבצעים את הקריאה ל-API ומשחזרים את הבעיה – 503 Service Unavailable עם קוד השגיאה messaging.adaptors.http.flow.ServiceUnavailable.
  3. בוחרים אחת מהבקשות שנכשלו.
  4. מנווטים בין השלבים השונים של ה-trace ומאתרים את המקום שבו התרחשה הכשל.
  5. בוחרים את FlowInfo שכולל את השגיאה. יכול להיות שתמצאו מידע נוסף בשדה error.cause, שבו מפורטת הסיבה לכישלון, כמו בדוגמה הבאה:

    דוגמה לבקשה שבה מוצג error.cause במעקב

    בקשה לדוגמה שבה מוצג error.cause בנתוני המעקב
  6. אם אתם רואים שerror.cause מציג Host not reachable, הסיבה הסבירה לשגיאה היא אחת מהאפשרויות הבאות:
    • שם המארח שצוין בהגדרות של שרת היעד או נקודת היעד שגוי, או שהוא מכיל רווחים או תווים מיוחדים לא רצויים.

      לדוגמה, יש רווח לא רצוי בשם המארח כמו שמוצג בהמשך:
      "demo-target.apigee.net "
    • שם המארח שמוחלף על ידי המשתנה target.url ב-API Proxy באמצעות מדיניות AssignMessage או JavaScript שגוי, או שיש בו רווח או תווים מיוחדים לא רצויים אחרים.
  7. בודקים את ההגדרה של נקודת הקצה של היעד או את ההגדרה של שרת היעד כדי לראות אם שם המארח של שרת היעד שגוי או מכיל רווחים או תווים מיוחדים לא רצויים.
  8. אם מארח שרת היעד נוצר באופן דינמי, צריך לבדוק את המדיניות המתאימה (לדוגמה, מדיניות AssignMessage/JavaScript) ששימשה ליצירת המארח. בודקים אם שם המארח של שרת היעד שגוי או אם יש בו רווחים או תווים מיוחדים לא רצויים.
  9. אחרי שקובעים את שם המארח של שרת היעד, מריצים את הפקודה nslookup/dig על שם המארח כדי לראות אם אפשר לזהות אותו.

    לדוגמה, הרצת הפקודה nslookup על שם המארח עם רווח לא רצוי תחזיר את הפלט הבא:

    nslookup "demo-target.apigee.net "
Server:	49.205.75.2
Address:	49.205.75.2#53

** server can't find demo-target.apigee.net\032: NXDOMAIN
  10. אם הפקודה nslookup של מערכת ההפעלה גם נכשלת בניסיון לפתור את שם המארח, הסיבה לבעיה היא שם המארח השגוי שמשמש לשרת היעד.

    עוברים אל רזולוציה.

יומנים של מעבד הודעות

כדי לבצע אבחון באמצעות יומנים של מעבד הודעות:

  1. קובעים את מזהה ההודעה של הבקשה שנכשלה.
  2. מחפשים את מזהה ההודעה ביומן של מעבד ההודעות. (/opt/apigee/var/log/edge-message-processor/logs/system.log)
  3. אם מופיעות הודעות האזהרה או השגיאה הבאות, מעבד ההודעות לא הצליח לפתור את שם המארח. ההודעה תועבר למצב שינה, ולכן יכול להיות שלא תראו את הודעת האזהרה הזו עבור כל מזהי ההודעות או הבקשות. 
    org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 WARN S.HTTPCLIENTSERVICE - DNSCache$2.failed() : Failed to resolve hostname www.somehost.com . Reason mocktarget.apigee.net : Name or service not known. This log message will snooze for 2 hours
  4. לאחר מכן תוצג הודעת אזהרה, שבה מעבד ההודעות מסיר את הכתובת ממטמון ה-DNS, כי לא הייתה אפשרות להגיע למארח של שרת היעד. 
    org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid> NIOThread@0 WARN  c.a.p.h.d.DNSCachedAddress - DNSCachedAddress.addressNotReachable() : The last address has been removed from Address list null refreshing
  5. יכול להיות שתופיע הודעה שבה מעבד ההודעות נכשל עם החריגה Host not reachable (המארח לא נגיש). לפעמים שם המארח מופיע כחלק מהודעת השגיאה: 
    org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() :  connect to demo-target.apigee.net  failed with exception {}
java.lang.RuntimeException: Host not reachable
	at com.apigee.protocol.http.HTTPClient$Context.initConnect(HTTPClient.java:704)
	at com.apigee.protocol.http.HTTPClient$Context.send(HTTPClient.java:675)
	at com.apigee.messaging.adaptors.http.flow.data.TargetRequestSender.sendRequest(TargetRequestSender.java:234)
	…<snipped>
  6. לפעמים הוא מוצג כnull כי אי אפשר לפענח את שם המארח או להגיע אליו, כמו שמוצג בהמשך: 
    org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() :  connect to null failed with exception {}
java.lang.RuntimeException: Host not reachable
	at com.apigee.protocol.http.HTTPClient$Context.initConnect(HTTPClient.java:704)
	at com.apigee.protocol.http.HTTPClient$Context.send(HTTPClient.java:675)
	at com.apigee.messaging.adaptors.http.flow.data.TargetRequestSender.sendRequest(TargetRequestSender.java:234)
	…<snipped>
  7. השגיאה Host not reachable מתרחשת בדרך כלל באחד מהמקרים הבאים:
    • שם המארח שצוין בהגדרות של שרת היעד או נקודת היעד שגוי, או שהוא מכיל רווחים או תווים מיוחדים לא רצויים.

      לדוגמה, יש רווח לא רצוי בשם המארח demo-target.apigee.net בהודעת השגיאה הבאה: 
      NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() :  connect to demo-target.apigee.net  failed with exception
    • שם המארח שמוחלף על ידי המשתנה target.url ב-API Proxy באמצעות מדיניות AssignMessage או JavaScript שגוי, או שיש בו רווח או תווים מיוחדים לא רצויים אחרים.
  8. כדי לקבוע את שם המארח של שרת היעד שאליו מעבד ההודעות מנסה לתקשר, משתמשים באחת מהאפשרויות הבאות:
    1. בודקים את הודעת השגיאה שמכילה את Host not reachable .
    2. אם הודעת השגיאה מציגה את שם המארח, מעתיקים את שם המארח כולל רווחים או תווים מיוחדים.
    3. אם הודעת השגיאה מציגה null בשם המארח, כמו בהודעת השגיאה הבאה, 
      org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() :  connect to null failed with exception {}
      1. בודקים את ההגדרה של שרת היעד שנעשה בו שימוש ב-API Proxy שנכשל כדי לזהות את שם המארח.
      2. אם המארח של שרת היעד נוצר באופן דינמי, צריך לבדוק את המדיניות המתאימה (לדוגמה, מדיניות AssignMessage/JavaScript) ששימשה ליצירת המארח.
  9. אחרי שקובעים את שם המארח של שרת היעד, מריצים את הפקודה nslookup/dig על שם המארח ובודקים אם אפשר לפתור את הבעיה.

    לדוגמה, מריצים את הפקודה nslookup על שם המארח שיש בו רווח

    nslookup "demo-target.apigee.net "
Server:	49.205.75.2
Address:	49.205.75.2#53

** server can't find demo-target.apigee.net\032: NXDOMAIN
  10. אם הפקודה nslookup של מערכת ההפעלה גם לא מצליחה לפתור את שם המארח, סימן שהבעיה היא שם המארח השגוי שמשמש לשרת היעד.

רזולוציה

  1. מוודאים ששם המארח של שרת היעד שצוין בהגדרת נקודת הקצה של היעד או בהגדרה של שרת היעד נכון ולא מכיל רווחים או תווים מיוחדים לא רצויים.
  2. אם אתם משתמשים במדיניות AssignMessage/JavaScript כדי ליצור באופן דינמי את שם המארח של שרת היעד, כדאי לבדוק את הגדרת המדיניות ואת הקוד ולוודא ששם המארח של שרת היעד נוצר בצורה נכונה.

כשלים בלחיצת היד של SSL

ספר ההוראות המלא לפתרון בעיות מוקדש לשגיאות בלחיצת היד של TLS/SSL. מידע נוסף זמין במאמר בנושא כשלים בלחיצת היד של SSL.

קביעת מקור הבעיה

סוגים מסוימים של שגיאות יכולים להתרחש בחיבור הנכנס (צפונה) או בחיבור היוצא (דרומה). שגיאה נכנסת (צפונית) מתרחשת בין אפליקציית הלקוח לבין Edge. שגיאה יוצאת (דרומית) מתרחשת בין Edge לבין שרת היעד בקצה העורפי. כדי לאבחן בעיות כאלה, קודם צריך להבין אם השגיאה מתרחשת בחיבור צפונה או דרומה.

הסבר על חיבורים צפונה ודרומה

יכול להיות שתיתקלו בשגיאה '503 השירות לא זמין' ב-Edge בחיבור הנכנס או בחיבור היוצא:

  • חיבור נכנס (או צפוני) – החיבור בין אפליקציית הלקוח לבין נתב Edge. הנתב הוא הרכיב של Apigee Edge שמטפל בבקשות נכנסות שנשלחות למערכת.
  • חיבור יוצא (או דרומה) – החיבור בין מעבד ההודעות של Edge לבין השרת העורפי. מעבד ההודעות הוא רכיב של Apigee Edge שמשמש כ-proxy לבקשות API לשרתי יעד בקצה העורפי.

אם אתם משתמשים ב-Edge Public Cloud, סביר להניח שאתם לא מודעים לרכיבים פנימיים כמו הנתב או מעבד ההודעות. המשתמשים בענן הציבורי לא יכולים לראות את הרכיבים הפנימיים האלה או לגשת אליהם. במקרים שבהם אפשר, אנחנו מספקים דרכים חלופיות לחקירת הבעיה שלא דורשות גישה ישירה לרכיבים האלה.

באיור הבא מוצגים חיבורים צפונה ודרומה ב-Apigee Edge.

הזרימה של אפליקציית הלקוח (חיבור צפונה) דרך Edge לשרת הקצה העורפי (חיבור דרומה)

איך קובעים איפה התרחשה השגיאה '503 השירות לא זמין'

כדי לבדוק אם השגיאה 503 Service Unavailable (השירות לא זמין) התרחשה בחיבור צפונה או דרומה, אפשר להשתמש באחת מהשיטות הבאות.

עקבות ממשק המשתמש

כדי לקבוע איפה השגיאה התרחשה באמצעות הכלי UI Trace:

  1. אם הבעיה עדיין פעילה, מפעילים את מעקב ממשק המשתמש עבור ה-API המושפע.
  2. אם מעקב ממשק המשתמש אחר בקשת ה-API שנכשלה מראה שהשגיאה 503 Service Unavailable מתרחשת במהלך זרימת בקשת היעד או נשלחת על ידי שרת הקצה העורפי, הבעיה היא southbound (כלומר, בין מעבד ההודעות לבין שרת הקצה העורפי).
  3. אם לא מקבלים את המעקב עבור קריאה ל-API הספציפית, הבעיה היא בכיוון צפון, בין אפליקציית הלקוח לבין הנתב.

מעקב אחר API

מעקב אחר API מאפשר לכם לבודד במהירות אזורים בעייתיים כדי לאבחן בעיות שקשורות לשגיאות, לביצועים ולזמן האחזור, ולמצוא את המקור שלהן, למשל אפליקציות למפתחים, שרתי proxy של API, יעדי קצה עורפיים או פלטפורמת ה-API.

דוגמה לתרחיש שמראה איך לפתור בעיות שקשורות לקודי שגיאה 5xx ב-API באמצעות API Monitoring. לדוגמה, כדאי להגדיר התראה כדי לקבל עדכון כשמספר messaging.adaptors.http.flow.ServiceUnavailable התקלות חורג מסף מסוים.

יומני גישה של NGINX

כדי לקבוע איפה השגיאה התרחשה באמצעות הכלי UI Trace:

אם הבעיה קרתה בעבר או שהיא מתרחשת לסירוגין ואין אפשרות לצלם את הנתונים, צריך לבצע את השלבים הבאים:

  1. בודקים את יומני הגישה של NGINX (/opt/apigee/var/log/edge-router/nginx/ org-env.port_access_log ).
  2. מחפשים אם יש שגיאות 503 עבור פרוקסי ספציפי של API.
  3. אם אתם מצליחים לזהות שגיאות 503 ב-API הספציפי בזמן הספציפי, הבעיה התרחשה בחיבור דרומה (בין מעבד ההודעות לבין שרת הקצה העורפי).
  4. אם לא, הבעיה התרחשה בחיבור צפונה (בין אפליקציית הלקוח לבין הנתב).