ביצוע ניתוח היסטורי באמצעות Cloud Logging

כש-Pod נכשל או ששירות לא פועל כמצופה ב-Google Kubernetes Engine‏ (GKE), חשוב להבין את רצף האירועים שהובילו לבעיה. בדיקת המצב הנוכחי לא תמיד מספיקה כדי למצוא את שורש הבעיה, ולכן נתוני יומן היסטוריים הם בעלי ערך רב.

בדף הזה מוסבר איך להשתמש ב-Cloud Logging כדי לחקור כשלים שהתרחשו בעבר (למשל, למה לא הצליחה ההפעלה של Pod או מי מחק פריסה קריטית) באמצעות שאילתות וניתוח של יומני GKE.

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

הסבר על סוגים עיקריים של יומנים לפתרון בעיות

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

  • יומנים של צמתים וזמן ריצה (kubelet, ‏ containerd): היומנים משירותי הצמתים הבסיסיים. מכיוון ש-kubelet מנהל את מחזור החיים של כל ה-Pods בצומת, היומנים שלו חיוניים לפתרון בעיות כמו הפעלת קונטיינרים, אירועים של חוסר זיכרון (OOM), כשלים בבדיקה ושגיאות בהרכבת נפח. היומנים האלה חשובים גם לאבחון בעיות ברמת הצומת, כמו צומת עם סטטוס NotReady.

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

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

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

תרחישים נפוצים לפתרון בעיות

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

  • אם הסטטוס של צומת הוא NotReady, צריך לבדוק את יומני הצומת. לרוב, היומנים kubelet ו-containerd חושפים את הסיבה הבסיסית, כמו בעיות ברשת או מגבלות משאבים.
  • אם הקצאה של צומת חדש נכשלת והצומת לא מצטרף לאשכול, כדאי לעיין ביומני יציאה טורית של הצומת. היומנים האלה מתעדים את פעילות האתחול המוקדם ואת הפעלת kubelet לפני שהסוכנים של רישום היומנים של הצומת פעילים באופן מלא.
  • אם בעבר פוד נכשל בהפעלה, כדאי לבדוק את יומני האפליקציה של הפוד כדי לראות אם היו קריסות. אם היומנים ריקים או שלא ניתן לתזמן את ה-Pod, צריך לבדוק את יומני הביקורת כדי למצוא אירועים רלוונטיים או את יומני הצמתים בצומת היעד כדי למצוא רמזים לגבי עומס על המשאבים או שגיאות בשליפת תמונות.
  • אם פריסה קריטית נמחקה ואף אחד לא יודע למה, אפשר להריץ שאילתה ביומני הביקורת של פעילות האדמין. היומנים האלה יכולים לעזור לכם לזהות איזה משתמש או חשבון שירות ביצע את הקריאה למחיקת ה-API, וכך לספק נקודת התחלה ברורה לחקירה.

איך ניגשים ליומנים

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

כדי לגשת ל-Logs Explorer ולהשתמש בו, פועלים לפי השלבים הבאים:

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

    כניסה לדף Logs Explorer

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

    סוג מסנן תיאור ערך לדוגמה
    resource.type סוג המשאב ב-Kubernetes. k8s_cluster,‏ k8s_node,‏ k8s_pod,‏ k8s_container
    log_id הזרם של היומן מהמשאב. stdout, stderr
    resource.labels.RESOURCE_TYPE.name סינון משאבים לפי שם ספציפי.‫
    מחליפים את RESOURCE_TYPE בשם המשאב שרוצים לשלוח לגביו שאילתה. לדוגמה, namespace או pod.    		 example-namespace-name, example-pod-name
    severity רמת החומרה של הרישום ביומן. DEFAULT, INFO, WARNING, ERROR, CRITICAL
    jsonPayload.message=~ חיפוש ביטוי רגולרי של טקסט בהודעת היומן. scale.down.error.failed.to.delete.node.min.size.reached

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

    resource.type="k8s_container"
resource.labels.pod_name="POD_NAME"
resource.labels.namespace_name="NAMESPACE_NAME"
severity=ERROR

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫POD_NAME: שם ה-Pod שבו מתרחשות בעיות.
    • ‫NAMESPACE_NAME: מרחב השמות שבו נמצא ה-Pod. אם אתם לא בטוחים מהו מרחב השמות, כדאי לעיין בעמודה Namespace מהפלט של הפקודה kubectl get pods.

    דוגמאות נוספות זמינות במאמר שאילתות שקשורות ל-Kubernetes במאמרי העזרה של Google Cloud Observability.

  3. לוחצים על Run query.

  4. כדי לראות את הודעת היומן המלאה, כולל מטען ה-JSON, המטא-נתונים וחותמת הזמן, לוחצים על הרשומה ביומן.

מידע נוסף על יומנים של GKE זמין במאמר מידע על יומנים של GKE.

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