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

כרגע מוצג התיעוד של Apigee Edge.
כניסה למסמכי התיעוד של Apigee X. מידע

סרטונים

לקבלת מידע נוסף על שגיאות 503, אפשר לצפות בסרטונים הבאים:

וידאו תיאור
פתרון בעיות ופתרון בעיות מסוג 'שירות לא זמין של שירות 503' עקב בעיית DNS מידע על הנושאים הבאים:
  • 503 שגיאת 'שירות לא זמין' שנגרמה עקב רזולוציית DNS ובעיות הקשורות לרשת ב-Apigee Edge
  • פתרון בעיות ופתרון השגיאה של 'שירות לא זמין של 503 בזמן אמת', שנגרמה עקב בעיה בפענוח ה-DNS
פתרון בעיות ופתרון שגיאה מסוג 'שירות לא זמין של שירות 503' עקב בעיה ברשת פתרון בעיות ופתרון שגיאה של 503 שירות לא זמין בזמן אמת, שנגרמה עקב בעיה ברשת ב-Apigee Edge

תיאור הבעיה

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

הודעות שגיאה

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

HTTP/1.1 503 Service Unavailable

ייתכן שהודעת השגיאה הבאה תופיע גם בתגובת ה-HTTP:

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

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

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

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

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

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

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

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

כלי המעקב

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

  1. אם הבעיה עדיין פעילה, מפעילים את סשן המעקב ל-API המושפע.
  2. ביצוע הקריאה ל-API ושחזור הבעיה – שירות 503 לא זמין עם קוד שגיאה 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 לשרת ה-API הספציפי במשך פרק זמן ספציפי (אם הבעיה אירעה בעבר) או אם יש בקשות שעדיין נכשלות עם 503.
  3. אם יש שגיאות 503 ב-X-Apigee-fault-code messages.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. כדאי לבדוק מדי פעם אם כתובות 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.ConnectExit: החיבור נדחה מציינת שהחיבור נדחה על ידי שרת הקצה העורפי. 
      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. אם הבעיה עדיין פעילה, מפעילים את סשן המעקב ל-API המושפע.
  2. ביצוע הקריאה ל-API ושחזור הבעיה – שירות 503 לא זמין עם קוד שגיאה messaging.adaptors.http.flow.ServiceUnavailable.
  3. בוחרים אחת מהבקשות שנכשלו.
  4. אפשר לנווט בשלבים השונים של המעקב ולאתר את המיקום שבו אירעה הכשל.
  5. בוחרים ב-FlowInfo שבו נמצאה השגיאה. בשדה error.cause ניתן למצוא מידע נוסף לגבי הסיבה לכשל, כפי שמוצג בדוגמה הבאה:

    בקשה לדוגמה שמציגה את error.cause בדוח

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

      לדוגמה, יש רווח לא רצוי בשם המארח, כמו שמוצג כאן:
      "demo-target.apigee.net "
    • שם המארח שהוחלף על ידי המשתנה target.url בשרת ה-API של ה-API באמצעות המדיניות AssignedMessage או JavaScript, הוא שגוי או שיש בו רווח או תווים מיוחדים לא רצויים אחרים.
  7. צריך לבדוק את ההגדרה של נקודת הקצה (endpoint) של היעד ו/או את ההגדרה של שרת היעד כדי לראות אם שם המארח של שרת היעד שגוי או שיש בו רווחים או תווים מיוחדים לא רצויים.
  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. יכול להיות שתופיע הודעה שבה מעבד ההודעות נכשל, למעט "לא ניתן להגיע למארח". לפעמים שם המארח מוצג כחלק מהודעת השגיאה: 
    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 של ה-API באמצעות המדיניות 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. אפשר לקבוע את שם המארח באמצעות בדיקת ההגדרה של שרת היעד שבה נעשה שימוש בשרת ה-proxy של ה-API שנכשל.
      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. צריך לוודא ששם המארח של שרת היעד שצוין בהגדרה של נקודת הקצה (endpoint) של היעד או בהגדרה של שרת היעד נכון, ושאין בו רווחים או תווים מיוחדים לא רצויים.
  2. אם משתמשים במדיניות הקצאת הודעה/JavaScript כדי ליצור באופן דינמי את שם המארח של שרת היעד, צריך לבדוק את הגדרת המדיניות ואת הקוד ולוודא ששם המארח של שרת היעד נוצר בצורה נכונה.

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

מדריך שלם לפתרון בעיות מוקדש לשגיאות לחיצת יד של TLS/SSL. לפרטים, קראו את המאמר כשל בלחיצת יד של SSL.

זיהוי המקור לבעיה

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

הבנת חיבורים לכיוון צפון ודרום

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

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

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

האיור הבא ממחיש חיבורים לכיוון צפון ודרום של Apigee Edge.

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

קביעת המיקום שבו אירעה השגיאה 503 Service Unavailable

אפשר להשתמש באחד מהתהליכים הבאים כדי לקבוע אם השגיאה '503 Service Unavailable' אירעה בחיבור לכיוון צפון או לכיוון דרום.

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

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

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

מעקב אחר API

API Monitoring מאפשר לבודד אזורים בעייתיים במהירות כדי לאבחן בעיות של שגיאות, ביצועים וזמן אחזור, ואת המקור שלהן, כמו אפליקציות למפתחים, שרתי 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 לשרת proxy ספציפי של API.
  3. אם הצלחת לזהות שגיאות 503 ב-API הספציפי בזמן הרלוונטי, הבעיה התרחשה בחיבור southbound (בין מעבד ההודעות לבין השרת של הקצה העורפי).
  4. אם לא, הבעיה התרחשה בחיבור northbound (בין אפליקציית הלקוח לבין הנתב).