פתרון בעיות ב-Monitoring API

במדריך הזה מוסבר על חלק מהבעיות שעלולות לקרות כשמשתמשים ב-Monitoring API.

‫Monitoring API הוא אחד מממשקי ה-API של Cloud. לממשקי ה-API האלה יש קבוצה משותפת של קודי שגיאה. רשימה של קודי השגיאה שמוגדרים על ידי Cloud APIs והצעות כלליות לטיפול בשגיאות מופיעות במאמר טיפול בשגיאות.

שימוש ב-API Explorer לניפוי באגים

‫APIs Explorer הוא ווידג'ט שמוטמע בדפי ההפניה לשיטות API. הוא מאפשר להפעיל את השיטה על ידי מילוי שדות, בלי לכתוב קוד.

אם נתקלתם בבעיה בהפעלת method, תוכלו להשתמש בווידג'ט של APIs Explorer (Try this API) בדף העזר של ה-method כדי לנפות את הבעיה. מידע נוסף זמין במאמר APIs Explorer.

שגיאות כלליות ב-API

אלה חלק מהשגיאות וההודעות של Monitoring API שאולי תראו בקריאות ל-API:

  • 404 NOT_FOUND עם השגיאה 'כתובת ה-URL שחיפשת לא נמצאת בשרת הזה': חלק מכתובת ה-URL שגוי. משווים את כתובת ה-URL לכתובת ה-URL של השיטה שמוצגת בדף ההפניה של השיטה. יכול להיות שהשגיאה הזו מציינת שיש שגיאת איות, למשל "project" במקום "projects", או שגיאה בשימוש באותיות רישיות, למשל "TimeSeries" במקום "timeSeries".

  • ‫401 UNAUTHENTICATED עם השגיאה 'למשתמש אין הרשאה לגשת לפרויקט (או למדד)': קוד השגיאה הזה בדרך כלל מצביע על בעיית הרשאה, אבל יכול להיות שהוא מצביע על שגיאה במזהה הפרויקט או בשם סוג המדד. בודקים את האיות ואת השימוש באותיות רישיות.

    אם אתם לא משתמשים ב-APIs Explorer, כדאי לנסות להשתמש בו. אם קריאה ל-API פועלת ב-APIs Explorer, כנראה שיש בעיה בהרשאה בסביבה שבה מתבצעת קריאה ל-API. עוברים אל הדף של API Manager כדי לוודא שממשק Monitoring API מופעל בפרויקט.

  • 400 INVALID_ARGUMENT עם 'למסנן השדה היה ערך לא תקין': צריך לבדוק את האיות והפורמט של מסנן המעקב. מידע נוסף זמין במאמר בנושא מסנני מעקב.

  • ‫400 INVALID_ARGUMENT עם ההודעה "Request was missing field interval.endTime": ההודעה הזו מוצגת אם שעת הסיום חסרה, או אם היא מופיעה אבל לא בפורמט הנכון. אם אתם משתמשים ב-APIs Explorer, אל תשימו גרשיים סביב הערך של שדה הזמן.

    ריכזנו כאן כמה דוגמאות לציון זמן תקין:

    2024-05-11T01:23:45Z
2024-05-11T01:23:45.678Z
2024-05-11T01:23:45.678+05:00
2024-05-11T01:23:45.678-04:30

תוצאות חסרות

אם קריאה ל-API מחזירה את קוד הסטטוס 200 ותגובה ריקה, כדאי לבדוק את הדברים הבאים:

  • יכול להיות שהמסנן לא התאים לשיחה. ההתאמה של המסנן היא תלוית אותיות רישיות (case-sensitive). כדי לפתור בעיות במסננים, מתחילים בציון של רכיב סינון אחד בלבד, כמו metric.type, ומוודאים שמתקבלות תוצאות. מוסיפים את שאר רכיבי המסנן אחד אחרי השני כדי ליצור את הבקשה.
  • כשעובדים עם מדד מותאם אישית, צריך לוודא שהפרויקט שבו המדד מוגדר מצוין.

יכולות להיות כמה סיבות לכך שנקודות נתונים חסרות כשמשתמשים בשיטה timeSeries.list:

  • יכול להיות שהנתונים מיושנים. מידע נוסף זמין במאמר שמירת נתונים.

  • יכול להיות שהנתונים עדיין לא הועברו לניטור. מידע נוסף זמין במאמר זמן האחזור של נתוני המדדים.

  • המרווח לא תקין:

    • מוודאים ששעת הסיום נכונה.
    • מוודאים ששעת ההתחלה נכונה ושמועד ההתחלה מוקדם ממועד הסיום. אם שעת ההתחלה חסרה או לא תקינה, ה-API מגדיר את שעת ההתחלה כשעת הסיום. במקרה של מדדי GAUGE, מרווח הזמן הזה תואם רק לנקודות שזמני ההתחלה והסיום שלהן הם בדיוק זמן הסיום של המרווח. לגבי המדדים CUMULATIVE או DELTA, שמודדים לאורך מרווחי זמן, לא נמצאו נקודות תואמות. מידע נוסף זמין במאמר בנושא מרווחי זמן.

ניסיון חוזר לתיקון שגיאות ב-API

שניים מקודי השגיאה של Cloud APIs מציינים נסיבות שבהן כדאי לנסות שוב לשלוח את הבקשה:

  • ‫503 UNAVAILABLE: ניסיונות חוזרים שימושיים כשהבעיה היא מצב זמני או חולף.
  • ‫429 RESOURCE_EXHAUSTED: ניסיונות חוזרים שימושיים, אחרי השהיה, למשימות רקע ארוכות טווח עם מכסת זמן, כמו n קריאות לכל t שניות. ניסיונות חוזרים לא מועילים אם הבעיה היא מצב זמני או חולף, או אם חרגתם ממכסה שמבוססת על נפח. במקרים של תנאים חולפים, כדאי לשקול לאפשר את השגיאה. במקרה של בעיות שקשורות למכסות, כדאי לצמצם את השימוש במכסה או לבקש להגדיל אותה.

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

האם אפשר לנסות לשלוח את הבקשה שוב?

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

  • קריאה של x היא אידמפוטנטית, כלומר לא חל שינוי בערך.
  • הגדרת x כ-10 היא אידמפוטנטית. יכול להיות שהיא תשנה את המצב, אם הערך הוא לא 10, אבל לא משנה מה הערך הנוכחי. ולא משנה כמה פעמים תנסו להגדיר את הערך.
  • הגדלה של x היא לא אידמפוטנטית. הערך החדש תלוי בערך הנוכחי.

ניסיון חוזר עם השהיה מעריכית לפני ניסיון חוזר (exponential backoff)

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

במקום זאת, צריך להשתמש בגישה של השהיה מעריכית קטועה לפני ניסיון חוזר. אם הבקשות נכשלות בגלל עומס זמני ולא בגלל חוסר זמינות אמיתי, הפתרון הוא להפחית את העומס. השהיה מעריכית קטועה לפני ניסיון חוזר (truncated exponential backoff) פועלת לפי הדפוס הכללי הבא:

  • קובעים כמה זמן אתם מוכנים לחכות בזמן ניסיון חוזר או כמה ניסיונות אתם מוכנים לעשות. אם חורגים מהמגבלה הזו, צריך להתייחס לשירות כאל שירות לא זמין ולטפל במצב הזה בצורה מתאימה באפליקציה. בגלל זה, הנסיגה האקספוננציאלית מקוטעת – בשלב מסוים מפסיקים את הניסיונות החוזרים.

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

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

יש הרבה דרכים להטמיע השהיה מעריכית לפני ניסיון חוזר (exponential backoff). בדוגמה הבאה מוסיפים עיכוב הולך וגדל של נסיגה (backoff) לעיכוב מינימלי של 1,000 אלפיות השנייה. השהיית הגיבוי הראשונית היא 2ms, והיא גדלה ל-2retry_countms עם כל ניסיון.

בטבלה הבאה מוצגים מרווחי הזמן לניסיונות חוזרים באמצעות הערכים הראשוניים:

  • השהיה מינימלית = שנייה אחת = 1,000 מילישניות
  • השהיה ראשונית = 2 אלפיות השנייה
מספר הניסיונות החוזרים השהיה נוספת (אלפיות השנייה) ניסיון חוזר אחרי (אלפיות השנייה)
0 ‫20 = 1 1001
1 ‫21 = 2 1002
2 ‫22 = 4 1004
3 23 = 8 1008
4 ‫24 = 16 1016
... ... ...
n ‫2n ‫1000 + 2n

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

מידע נוסף זמין במאמר Exponential backoff בוויקיפדיה.