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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    כניסה לדף Logs Explorer

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

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

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

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