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

מוצג המסמך של Apigee Edge.
עוברים אל מסמכי תיעוד של Apigee X. מידע

סרטונים

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

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

תיאור הבעיה

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

הודעות שגיאה

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

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

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

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

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

      לדוגמה, יש שטח לא רצוי בשם המארח 'demo-target.apigee.net' בהודעת השגיאה הבאה: 
      NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() :  connect to demo-target.apigee.net  failed with exception
    • שם המארח שהוחלף על ידי המשתנה target.url בשרת ה-proxy ל-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 policy) שבה נעשה שימוש כדי ליצור את המארח.
  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 לבין שרת היעד העורפי. כדי לאבחן מקרים כאלה כמה בעיות, התפקיד הראשון שלכם הוא להבין אם השגיאה מתרחשת בדרך הצפונית או חיבור שפונה דרומה.

הסבר על החיבורים לכיוון צפון ולדרום

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

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

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

האיור הבא ממחיש את החיבורים בין צפון לדרום עבור Apigee קצה.

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

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

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

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

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

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

מעקב אחרי 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 הספציפי בזמן מסוים, יש להזין את התרחשה בחיבור היוצא (בין מעבד ההודעות לבין שרת העורפי).
  4. אם לא, הבעיה התרחשה בחיבור צפון (בין אפליקציית הלקוח והנתב).