שגיאה 503 Service Unavailable עם TARGET_CONNECT_TIMEOUT (יעדים של חיבור לאינטרנט וחיבור VPC)

הדף הזה רלוונטי ל-Apigee ול-Apigee Hybrid.

לעיון במסמכי התיעוד של Apigee Edge

תיאור הבעיה

הבעיה הזו מופיעה כשגיאות מסוג '503 – השירות לא זמין' במעקב אחר API, בניפוי באגים או בכלים אחרים. הסיבה TARGET_CONNECT_TIMEOUT מציינת שחל פסק זמן לחיבור בין מופע Apigee ליעד באינטרנט או ליעד שאפשר להגיע אליו באמצעות קישור בין רשתות VPC שכנות (peering).

חשוב לא להתבלבל בין השגיאה הזו לבין שגיאות אחרות שקשורות לזמן קצוב לתפוגה, כמו 504 Gateway Timeout.

הודעת השגיאה

זו השגיאה האופיינית בסשן הניפוי או במטען הייעודי לתגובה. הסיבה: TARGET_CONNECT_TIMEOUT

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

סיבות אפשריות

הערה: הסיבות האלה ספציפיות ליעדים באינטרנט או ליעדים שאפשר להגיע אליהם באמצעות VPC Peering. אפשרויות הרשת של Apigee אם היעד הוא Private Service Connect (קובץ מצורף של נקודת קצה), כדאי לעיין במקום זאת במדריך Private Service Connect.

מטרה	תיאור
הגדרה שגויה של מסלולים	מסלולי היעד לא מיוצאים אל ה-peering עם מופע Apigee.
בעיה בקישוריות ביעד	יכול להיות שאי אפשר לקבל חיבור TCP ביעד.
רשימת היתרים של כתובות IP ביעד, כשחלק מכתובות ה-IP של Apigee NAT לא נוספו או שכולן לא נוספו	לא כל כתובות ה-IP של Apigee NAT מופיעות ברשימת ההיתרים ביעד.
מיצוי של יציאות ב-NAT	אין מספיק יציאות NAT לתנועה.
הערך של connect.timeout.millis נמוך מדי	ההגדרה של הזמן הקצוב לתפוגה של החיבור נמוכה מדי בצד של Apigee.

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

הכלי Debug הוא כלי חיוני לתיעוד ולהערכה של הפרטים הבאים לגבי הבעיה:

• משך הזמן הכולל של הבקשה. בדרך כלל, חולפות שלוש שניות (ברירת המחדל connect.timeout.millis) עד שמתרחש פסק זמן לחיבור. אם משך הזמן נמוך יותר, כדאי לבדוק את ההגדרה של נקודת הקצה (endpoint) של היעד.
• שם המארח של היעד וכתובת ה-IP. אם מוצגת כתובת IP שגויה, יכול להיות שיש בעיה שקשורה ל-DNS. יכול להיות שתבחינו גם בקשר בין כתובות IP שונות לבין הבעיה.
• תדירות. צריך להשתמש בגישות שונות בהתאם לסוג הבעיה: לסירוגין או קבועה.

הסיבה: הגדרה שגויה של המסלול

אבחון

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

יכול להיות שהדבר ישפיע על יעדים פנימיים (שמופנים ב-VPC שמוגדר כעמית) ועל יעדים חיצוניים (אינטרנט).

1. קודם כול, מזהים את כתובת ה-IP של היעד שנפתרה ממופע Apigee. אחת מהשיטות היא שימוש בסשן Debug. בניפוי הבאגים, עוברים אל AnalyticsPublisher (או אל AX בניפוי הבאגים הקלאסי):
   
   

   מחפשים את הערך target.ip בצד שמאל של המסך.

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

   שימו לב: אם היעד נמצא באינטרנט, צריך לבצע את השלב הזה אם VPC Service Controls מופעל ב-Apigee, כי הוא מונע קישוריות לאינטרנט.

2. חשוב לציין את האזור שבו פריסת מופע Apigee שנפגע. בממשק המשתמש של Apigee במסוף Cloud, לוחצים על Instances. בשדה Location, אפשר לראות את האזור המדויק של המופע.
   
   
   
3. בפרויקט שמקושר ל-Apigee, עוברים לקטע VPC Network (רשת VPC) -> VPC network peering (קישור בין רשתות VPC שכנות) בממשק המשתמש. שימו לב: אם אתם משתמשים ב-VPC משותף, צריך לבצע את השלבים האלה בפרויקט המארח ולא בפרויקט Apigee.
   
   
4. לוחצים על servicenetworking-googleapis-com, בוחרים בכרטיסייה EXPORTED ROUTES ומסננים לפי האזור שהתקבל בשלב 2.
   
   בדוגמה הזו מוצג הנתיב 10.2.0.0/24 כפי שהוא מיוצא, והיא כוללת את כתובת ה-IP של יעד הדוגמה 10.2.0.1. אם לא מופיע מסלול שמתאים ליעד, זו הסיבה לבעיה.
   
   הערה: אם היעד הוא חיצוני, בדרך כלל הנתיבים לא מופיעים בנתיבים שיוצאו והבקשות של Apigee מנותבות ישירות לאינטרנט. יכול להיות שזה לא תמיד המצב, לכן חשוב להבהיר את טופולוגיית הרשת הרצויה. לדוגמה, אם VPC Service Controls מופעל, צריך גם לייצא מסלולים שמוגדרים כברירת מחדל או מסלולים אחרים כדי להגיע ליעדים חיצוניים.
   
   

רזולוציה

בודקים את ארכיטקטורת הרשת ומוודאים שהנתיבים מיוצאים ל-VPC peering עם Apigee. סביר להניח שהמסלול החסר הוא סטטי או דינמי. אם חסרים מסלולים דינמיים נדרשים, זה מצביע על בעיה בתכונה המתאימה, למשל Cloud Interconnect.

שימו לב, אין תמיכה בהעברת קישור בין רשתות שכנות (peering). במילים אחרות, אם רשת ה-VPC ששמה N1 מקושרת לרשתות השכנות N2 ו-N3, אבל N2 ו-N3 לא מקושרות בקישור ישיר, רשת ה-VPC ששמה N2 לא יכולה לתקשר עם רשת ה-VPC ששמה N3 באמצעות קישור בין רשתות VPC שכנות.

מידע נוסף זמין במאמר בנושא דפוסי רשת יוצאת.

הסיבה: בעיה בקישוריות ביעד

אבחון

יכול להיות שלא ניתן להגיע ליעד מרשת ה-VPC או שהוא לא יכול לקבל חיבור. יש שתי אפשרויות לאבחון הבעיה.

בדיקת קישוריות (כתובות IP פרטיות של יעד)

אם היעד נמצא ברשת פרטית, אפשר להשתמש בתכונה בדיקת הקישוריות כדי לאבחן סיבות נפוצות.

1. מזהים את כתובת ה-IP של היעד שנפתרה ממופע Apigee. אחת מהשיטות היא שימוש בסשן Debug.
   
   בניפוי הבאגים, עוברים אל AnalyticsPublisher (או אל AX בניפוי הבאגים הקלאסי). מחפשים את הערך target.ip בצד שמאל של המסך.
   
   בדוגמה הזו, כתובת ה-IP היא 10.2.0.1. זוהי כתובת IP פרטית, ולכן אפשר להשתמש בבדיקת הקישוריות.
   
   
2. שימו לב לכתובת ה-IP של מופע Apigee שלא מצליח להתחבר ליעד. בקטע Instances במסוף Apigee, מחפשים את כתובת ה-IP של מופע Apigee בשדה IP Address.
   
   
3. עוברים אל בדיקות קישוריות ולוחצים על יצירת בדיקת קישוריות. מזינים את הפרטים הבאים:
   1. כתובת ה-IP של המקור: משתמשים בכתובת ה-IP של מופע Apigee שקיבלתם בשלב 2 שלמעלה. שימו לב: זו לא כתובת ה-IP המדויקת של המקור שבה Apigee משתמש כדי לשלוח בקשה ליעד, אבל היא מספיקה לבדיקה כי היא נמצאת באותה רשת משנה.
   2. זו כתובת IP שמשמשת ב-Google Cloud: אל תסמנו את התיבה הזו אלא אם הכתובת מופיעה באחד מהפרויקטים שלכם ב-Google Cloud. אם בודקים את הערך הזה, צריך לספק גם את הפרויקט והרשת.
   3. מזינים את כתובת היעד (שלב 1) ואת היציאה בשדות כתובת ה-IP של היעד ויציאת היעד בהתאמה.
   
4. לוחצים על יצירה ומחכים שהבדיקה תסיים את ההרצה הראשונה.
5. ברשימת בדיקות הקישוריות, לוחצים על הצגה כדי לראות את תוצאות ההרצה.
6. אם התוצאה היא Unreachable (לא ניתן להגיע), סימן שיש בעיה בהגדרות. הכלי אמור להפנות אתכם אל המסמכים בנושא מצבי בדיקות הקישוריות כדי להמשיך. אם הסטטוס הוא 'אפשר להגיע', זה אומר שאין בעיות רבות בהגדרות. עם זאת, אין בכך ערובה לכך שאפשר להגיע ליעד. לא היה ניסיון בפועל ליצור חיבור TCP עם היעד. רק האבחון הבא שבהמשך יעזור לבדוק את זה.
   
   

בדיקת קישוריות של מכונה וירטואלית (כל היעדים)

1. באותו VPC שבו מתבצעת פעולת ה-peering עם Apigee, יוצרים מכונת VM ב-Linux.
2. מבצעים בדיקות קישוריות מהמכונה הווירטואלית, רצוי ברגע שבו הבעיה ניתנת לשחזור מ-Apigee. אפשר להשתמש ב-telnet, ב-curl ובכלי עזר אחרים כדי ליצור חיבור. דוגמה ל-curl שפועל בלולאה עם פסק זמן של שלוש שניות. אם curl לא מצליח ליצור חיבור TCP תוך שלוש שניות, הוא נכשל.

   for i in {1..100}; do curl -m 3 -v -i https://[TARGET_HOSTNAME] ; sleep 0.5 ; done

3. בודקים את הפלט המלא ומחפשים את השגיאה הזו:

   * Closing connection 0
    curl: (28) Connection timed out after 3005 milliseconds

   הצגת השגיאה הזו מאשרת שאפשר לשחזר את הבעיה מחוץ ל-Apigee.

   שימו לב: אם מופיעות שגיאות אחרות, כמו שגיאות שקשורות ל-TLS, קודי סטטוס לא תקינים וכו', הם לא מאשרים שחלף הזמן הקצוב לתפוגת החיבור, ואין להם קשר לבעיה הזו.

4. אם היעד דורש הוספה לרשימת ההיתרים לפי כתובת IP, יכול להיות שלא תוכלו לבדוק אותו ממכונה וירטואלית, אלא אם תוסיפו לרשימת ההיתרים גם את כתובת ה-IP של מכונת ה-VM.

רזולוציה

אם זיהיתם בעיה על סמך בדיקות הקישוריות, צריך להמשיך לשלבים לפתרון הבעיה שמתועדים בקישור שלמטה.

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

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

אם היעד נמצא באינטרנט, אפשר לנסות לשחזר את הבעיה מחוץ למסוף Google Cloud.

אם הבעיה מתרחשת בשעות השיא, יכול להיות שהיעד מוצף בחיבורים.

אם בשלב הזה אתם צריכים לפתוח בקשת תמיכה ב-Google Cloud, אתם כבר לא צריכים לבחור את רכיב Apigee, כי הבעיה ניתנת לשחזור ישירות מ-VPC.

הסיבה: רשימת כתובות IP מותרות ביעד, וחלק מכתובות ה-IP של Apigee NAT או כולן לא נוספו

אבחון

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

אם השגיאות מתרחשות לסירוגין, קל יותר לזהות את הבעיה, כי במקרה כזה אפשר למצוא קשר בין כתובות IP מסוימות של NAT לבין השגיאות.

אם הבעיה נמשכת (כל השיחות נכשלות), צריך לוודא שכתובות ה-IP של NAT מופעלות ב-Apigee, ולשלוף אותן באמצעות השלבים הבאים:

כדי להציג את כתובות ה-IP של NAT עבור מופע:

curl -H "Authorization: Bearer $TOKEN" \
"https://apigee.googleapis.com/v1/organizations/$ORG_ID/instances/$INSTANCE_NAME/natAddresses"

דוגמה לתשובה:

{
  "natAddresses": [
    {
      "name": "nat-1",
      "ipAddress": "35.203.160.18",
      "state": "ACTIVE"
    },
    {
      "name": "nat-2",
      "ipAddress": "35.230.14.174",
      "state": "RESERVED"
    }
  ]
}

אם לא מופיעות כתובות בפלט, סימן שכתובות ה-IP של NAT לא נוספו בצד של Apigee. אם קיבלתם כתובות אבל אף אחת מהן לא פעילה, זה אומר שאף אחת מהכתובות שבהן נעשה שימוש לא מאפשרת גישה לאינטרנט, וזו גם בעיה.

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

אם הבעיה מתרחשת לסירוגין, יכול להיות שרק קבוצת משנה של כתובות ה-IP של ה-NAT נכללת ברשימת ההיתרים ביעד. כדי לזהות את זה:

1. יוצרים שרת proxy הפוך חדש שבו היעד המושפע מצוין ב-TargetEndpoint. אפשר גם להשתמש מחדש ב-proxy הקיים ולעבור לשלב הבא:
   
   
2. מוסיפים מדיניות ServiceCallout ל-Request PreFlow. הרכיב ServiceCallout צריך לקרוא לכתובת https://icanhazip.com, לכתובת https://mocktarget.apigee.net/ip או לכל נקודת קצה ציבורית אחרת שמחזירה את כתובת ה-IP של המתקשר בתגובה. מאחסנים את התגובה במשתנה response כדי שהתוכן יהיה גלוי בניפוי באגים. זו דוגמה להגדרת מדיניות ServiceCallout:
   

   <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
   <ServiceCallout continueOnError="false" enabled="true" name="Service-Callout-1">
       <DisplayName>Service Callout-1</DisplayName>
       <Properties/>
       <Request clearPayload="true" variable="myRequest">
           <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
       </Request>
       <Response>response</Response>
       <HTTPTargetConnection>
           <Properties/>
           <URL>https://icanhazip.com</URL>
       </HTTPTargetConnection>
   </ServiceCallout>

   אפשר גם לאחסן את התגובה במשתנה מותאם אישית, אבל צריך לקרוא את הערך ‎.content של המשתנה הזה באמצעות מדיניות AssignMessage כדי להציג אותו בכלי לניפוי באגים.

   מוודאים שהיעד מוגדר בדיוק באותו אופן כמו בשרת ה-proxy המושפע.

   הערה: בקשת ServiceCallout ובקשת Target צריכות להתבצע במסגרת טרנזקציה אחת. כך אפשר לוודא שאותו שרת מעבד בקשה, כדי שכתובת ה-IP של NAT של הבקשה המושפעת תתאים לכתובת ה-IP של NAT שהתקבלה מ-ServiceCallout.
3. מפעילים סשן של ניפוי באגים ולוחצים על השלב ServiceCallout:
   
   
4. בפינה השמאלית התחתונה, אמור להופיע הקטע Response content (תוכן התגובה) שמכיל את כתובת ה-IP של NAT (בגוף) של מופע Apigee ששולח את הבקשה. לחלופין, אם שומרים את התגובה של ServiceCallout במקום אחר, היא אמורה להופיע שם.
   
   שימו לב: בהמשך התהליך, ה-proxy יקרא ליעד ותוכן התגובה יידרס עם השגיאה או עם תגובה מהיעד.
5. נסו למצוא קשר בין כתובות ה-IP של ה-NAT לבין הבעיה. אם שמתם לב שרק כתובות IP מסוימות נכשלות, זה סימן שחלק מכתובות ה-IP נכללות ברשימת ההיתרים ביעד, אבל לא כולן.
6. אם לא מצאתם קשר בין כתובות ה-IP של NAT לבין השגיאות, למשל אם אותה כתובת IP נכשלת בבקשה אחת אבל לא בבקשה אחרת, סביר להניח שזו לא בעיה שקשורה להוספה לרשימת ההיתרים. יכול להיות שזו בעיה של מיצוי כתובות NAT. ראו הסיבה: מיצוי של יציאת כתובת IP של NAT.

רזולוציה

צריך לוודא שהקצאתם כתובות IP של NAT והפעלתם אותן, ולוודא שכולן נוספו בצד היעד.

הסיבה: מיצוי של יציאות בכתובת IP של NAT

אבחון

הערה: הסיבה הזו לא נפוצה והיא רלוונטית אם אי אפשר לשחזר את הבעיה מ-VPC או מכל מקום אחר מחוץ ל-Apigee. אם לא ביצעתם את הבדיקה הזו, תוכלו לפעול לפי ההוראות שמפורטות בקטע בעיית קישוריות ביעד למעלה. הקטע הזה לא רלוונטי גם אם אתם לא משתמשים בכתובות IP של NAT.

אם הבעיה ניתנת לשחזור רק מ-Apigee ומוקצים כתובות IP של NAT לארגון שלכם, ואתם רואים שהיא מתרחשת עבור יעדים שונים בו-זמנית, יכול להיות שנגמרו לכם יציאות המקור של NAT:

1. מציינים את מסגרת הזמן של הבעיה. לדוגמה: מדי יום בין השעות 17:58 ל-18:08.
2. בודקים אם הבעיה משפיעה על יעדים אחרים באותו פרק זמן. היעד האחר הזה צריך להיות נגיש דרך האינטרנט, ואסור שהוא יתארח באותו מיקום כמו היעד המקורי שהושפע.
3. בודקים אם השגיאות מתרחשות רק מעל נפח תעבורה מסוים ב-TPS. כדי לעשות זאת, צריך לשים לב למסגרת הזמן של הבעיה ולעבור אל לוח הבקרה Proxy Performance.
4. כדאי לנסות למצוא קשר בין חלון הזמן של השגיאה לבין העלייה במספר הממוצע של טרנזקציות לשנייה (tps).

בדוגמה הזו, הערך של tps גדל ל-1,000 בשעה 17:58. בהנחה שבמקרה הזה, 17:58 הוא בדיוק הזמן שבו הבעיה מתרחשת, והבעיה משפיעה על שני יעדים או יותר שלא קשורים זה לזה, זהו אות לבעיה של מיצוי כתובות NAT.

רזולוציה

מחשבים מחדש את הדרישות לכתובות IP של NAT באמצעות ההוראות שבמאמר חישוב הדרישות לכתובות IP סטטיות של NAT.

אפשר גם להוסיף עוד כתובות IP של NAT ולבדוק אם הבעיה נפתרת. הערה: יכול להיות שיהיה צורך להוסיף את כתובות ה-IP לרשימת ההיתרים בכל היעדים לפני שמוסיפים אותן.

הסיבה: הערך של connect.timeout.millis נמוך מדי

אבחון

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

כדי לבדוק את זה, עוברים אל ה-proxy המושפע ובודקים את TargetEndpoint הרלוונטי. שימו לב למאפיין connect.timeout.millis ולערך שלו. בדוגמה כאן הערך הוא 50, ששווה ל-50 אלפיות שנייה, ובדרך כלל הוא נמוך מדי כדי להבטיח יצירת חיבור TCP. אם מופיע ערך מתחת ל-1,000, סביר להניח שזו הסיבה לבעיה. אם לא רואים את המאפיין connect.timeout.millis, ערך ברירת המחדל מוגדר והסיבה לא מאומתת.

רזולוציה

מתקנים את הערך של connect.timeout.millis, וחשוב לזכור שיחידות הזמן הן באלפיות השנייה. ערך ברירת המחדל הוא 3,000, כלומר 3,000 אלפיות השנייה. מידע נוסף זמין במאמר הפניה למאפייני נקודות קצה.

לקבלת עזרה נוספת, אפשר לפנות לתמיכה

אם הבעיה נמשכת אחרי שמבצעים את ההוראות שלמעלה, צריך לאסוף את נתוני האבחון הבאים בשביל התמיכה של Google Cloud:

1. מזהה הפרויקט ושם הארגון ב-Apigee
2. שמות ה-Proxy והסביבה
3. מסגרת הזמן של הבעיה
4. תדירות הבעיה
5. שם המארח של היעד
6. סשן ניפוי באגים עם הבעיה
7. תוצאת הבדיקות שבוצעו לגבי הסיבות האפשריות שצוינו למעלה. לדוגמה, הפלט של הפקודה curl ממכונה וירטואלית