מבוא לפתרון בעיות ב-Cloud Run

בדף הזה מתוארות אסטרטגיות נפוצות לפתרון בעיות שקשורות לשגיאות ב-Cloud Run. ב-Service Health בהתאמה אישית מתפרסמים כל האירועים ב-Cloud Run שנובעים מהתשתית הבסיסית של Cloud de Confiance by S3NS , כדי שתוכלו לזהות שיבושים בשירות של Cloud de Confiance by S3NS שמשפיעים על הפרויקטים שלכם. מומלץ גם להגדיר התראות על אירועים במרכז האישי ב-Service Health. מידע על אירועים שמשפיעים על כל שירותי Cloud de Confiance by S3NS Google Cloud זמין בלוח הבקרה Cloud de Confiance by S3NS Service Health.

כדי לפתור בעיות שקשורות למשאב Cloud Run, אפשר לעיין בקטעים הבאים במדריך לפתרון בעיות ב-Cloud Run:

אסטרטגיות לפתרון בעיות ב-Cloud Run

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

יצירת יומנים טובים באמצעות Cloud Logging

כדי שיהיה קל יותר לפתור בעיות במשאב Cloud Run, כדאי שיהיו לכם יומנים טובים לניפוי באגים. מומלץ לכתוב יומנים באופן שמבצע קורלציה בין יומני מאגרי התגים לבין יומן בקשות.

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

חקירת מקרים באמצעות הכלי Logs Explorer

כל יומן בקשות ב-Cloud Run מכיל שדה instanceId שמזהה מופע שמטפל בבקשה. בהתאם לערך המקבילות שאתם מציינים, מופע יחיד יכול לטפל בכמה בקשות בו-זמנית.

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

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

כדי לסנן מופע ספציפי ב-Logs Explorer:

  1. נכנסים לדף Logs Explorer במסוף Cloud de Confiance :

    כניסה לדף Logs Explorer

  2. בוחרים פרויקט קיים Cloud de Confiance by S3NS בחלק העליון של הדף או יוצרים פרויקט חדש.

  3. בוחרים את המשאב Cloud Run Revision לשירות, או Cloud Run Job למשימה.

  4. אפשר להרחיב רשומה ביומן כדי לסנן לפי מופע ספציפי.

  5. לוחצים על הערך של מזהה המופע ובוחרים באפשרות הצגת רשומות תואמות.

במהלך החקירה של מופעים, אתם יכולים להשתמש ב-Gemini Cloud Assist Investigations כדי לקבל תובנות נוספות לגבי היומנים. מידע נוסף על דרכים שונות להתחלת חקירה באמצעות Logs Explorer מופיע במאמר פתרון בעיות באמצעות Gemini Cloud Assist Investigations במסמכי Gemini.

פתרון בעיות שקשורות לזמני אחזור לא צפויים של בקשות

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

  1. בודקים אם זמן האחזור משפיע על כל הבקשות למשאב Cloud Run או רק על אחוז קטן מהן. ‫Cloud Run משולב אוטומטית עם Cloud Monitoring בלי צורך בהגדרה או בתצורה.

    כדי לראות את מדדי זמן האחזור של בקשות ספציפיות:

    1. במסוף Cloud de Confiance , נכנסים לדף Cloud Run:

      כניסה ל-Cloud Run

    2. בתפריט הניווט הימני, בוחרים שירות או משרה מהרשימות שזמינות.

    3. לוחצים על הכרטיסייה METRICS כדי להציג את לוח הבקרה Request latencies.

    כדי לראות את מדדי זמן האחזור ב-Cloud Monitoring, בוחרים באפשרות Cloud Run Revision > Request_latencies > Request latency מתוך רשימת המדדים.

    רשימה של כל המדדים הזמינים ב-Cloud Run ופרטים נוספים מופיעים במאמר Cloud de Confiance by S3NS מדדים ב-Cloud Monitoring.

  2. מזהים את הבקשה עם זמן האחזור הגבוה כדי להבין מה מקור זמן האחזור. אפשר להשתמש ב-Cloud Trace או ב-Cloud Logging כדי להבין כמה זמן נמשכה בקשה מסוימת.

    כדי לזהות בקשות עם זמן אחזור גבוה באמצעות Cloud Logging, צריך להחיל את המסנן traceSampled=true כדי ליצור קורלציה בין היומנים ב-Cloud Logging לבין העקבות ב-Cloud Trace. מידע נוסף זמין במאמר בנושא אינטגרציה עם Cloud Logging.

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

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

  3. כדאי להגדיל את מספר המופעים המינימליים כדי לקצר את זמן האחזור של בקשות נכנסות ולהימנע מהפעלות במצב התחלתי (cold start). כדאי גם לשנות את קוד המקור ולהתאים את הגדרות ההרחבה כדי להגביל את מספר החיבורים לשירות גיבוי.

    מידע נוסף זמין במאמר בנושא אופטימיזציה של הביצועים.

פתרון בעיות בקישוריות

אם אתם נתקלים בבעיות קישוריות בשירות Cloud Run, כדאי לנסות את האסטרטגיות והכלים הבאים כדי לאבחן את הבעיה:

  • ‫PCAP sidecar: כדי לבצע ניתוח מעמיק ברמת הרשת, פורסים PCAP sidecar לצד שירות Cloud Run. קונטיינר ה-sidecar הזה מבצע לכידה של חבילות נתונים באמצעות tcpdump באותו מרחב שמות של הרשת. ה-sidecar מופרד מהקונטיינר הראשי של ה-ingress, ולא צריך לבצע בו שינויים כדי ללכוד מנות מידע. בנוסף, קובצי ה-sidecar משתמשים במשאבים משלהם, וכך מונעים מ-tcpdump להתחרות על המשאבים שהקציתם לשירות הראשי.

  • בדיקות קישוריות וניתוח רשת לעדכונים של Cloud Run ולפונקציות Cloud Run: בדיקות אוטומטיות של נתיב הרשת בין משאב Cloud Run לבין נקודת קצה. הבדיקה הזו עוזרת לכם למצוא הגדרות שגויות שעשויות לחסום תעבורת נתונים אל או מהמשאב של Cloud Run כשמתחברים למכונה וירטואלית, לכתובת IP או לשירות שמנוהל על ידי Google.

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

המאמרים הבאים

אם לא הצלחתם למצוא פתרון לבעיה שלכם במסמכי התיעוד של Cloud Run, תוכלו לפעול לפי השלבים הבאים: