פתרון בעיות שקשורות ליומנים חסרים ב-GKE

בעיות בצינור הנתונים של הרישום ב-Google Kubernetes Engine ‏ (GKE) עלולות למנוע את ההופעה של יומני האשכול ב-Cloud Logging, ולפגוע במאמצי המעקב והניפוי של הבאגים.

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

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

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

חיפוש פתרון לפי סימפטום

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

קטגוריה	תסמין או תצפית	סיבה אפשרית	שלבים לפתרון בעיות
Configuration	לא מוצגים יומנים מאף אשכול בפרויקט.	ה-API של Cloud Logging מושבת בפרויקט.	אימות הסטטוס של Cloud Logging API
	חסרים יומנים מאשכול ספציפי, או שחסרים רק סוגים מסוימים של יומנים.	רישום ביומן ברמת האשכול מושבת עבור סוגי היומנים הנדרשים.	אימות ההגדרה של רישום ביומן של האשכול
	יומני רישום חסרים מצמתים במאגר צמתים ספציפי.	לצמתים במאגר הצמתים חסר היקף הגישה הנדרש.	אימות היקפי הגישה של מאגר הצמתים
	שגיאות הרשאה (401 או 403) מופיעות ביומנים של סוכן הרישום.	לחשבון השירות של הצומת חסרה ההרשאה הנדרשת.	אימות ההרשאות של חשבון השירות של הצומת
משאבים וביצועים	יומנים חסרים לסירוגין, או שמופיעות שגיאות RESOURCE_EXHAUSTED.	הפרויקט חורג ממכסת הכתיבה של Cloud Logging API.	בדיקת השימוש במכסה של Cloud Logging API
	חלק מהיומנים מצומת ספציפי חסרים, לרוב בזמן עומס תנועה או עומס גבוהים.	הצומת חורג ממגבלות התפוקה של סוכן הרישום ביומן, או שחסרים לו משאבים (CPU או זיכרון) לעיבוד יומנים.	בדיקת קצב העברת הנתונים של הצומת ושימוש במשאבים
סינון והתנהגות האפליקציה	חסרים באופן עקבי יומנים ספציפיים שתואמים לתבנית מסוימת.	מסנן החרגה ביומן ב-Cloud Logging משמיט את היומנים בטעות.	בדיקת מסנני החרגה של יומנים
	היומנים ממאגר מתעכבים באופן משמעותי או מופיעים רק אחרי שהמאגר יוצא.	הפלט של האפליקציה מאוחסן במלואו במאגר, לרוב בגלל צינורות stdout.	בדיקה של אחסון זמני בזיכרון (באפרינג) ועיכובים ביומן של מאגר התגים
	יומני הרישום הצפויים לא מופיעים בתוצאות החיפוש.	יכול להיות שהמסננים של השאילתות ב-Logs Explorer מגבילים מדי.	חקירת שאילתות ב-Logs Explorer
	לא רואים יומנים מ-Pod של אפליקציה ספציפית, אבל רואים יומנים אחרים של האשכול.	האפליקציה בתוך מאגר התגים לא כותבת ל-stdout או ל-stderr.	חקירת אופן הרישום ביומן של אפליקציות ספציפיות
פלטפורמה ושירות	יומנים מלפני תאריך מסוים לא מופיעים.	היומנים עברו את תקופת השמירה שלהם ונמחקו על ידי Cloud Logging.	בדיקת תקופות השמירה של היומנים
	אובדן נרחב של יומנים או עיכובים בפרויקטים או באשכולות.	בעיה בשירות Cloud Logging או עיכוב בהוספת נתונים.	בדיקת בעיות ועיכובים בשירות Cloud Logging
	בעיות ברישום ביומן מתרחשות במקביל למגבלות של גרסת האשכול.	גרסת GKE לא נתמכת.	חקירת גרסת האשכול

שימוש בכלי אבחון אוטומטיים

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

שימוש ב-Gemini Cloud Assist investigations

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

אימות ההגדרות וההרשאות של הרישום ביומן

הגדרות שגויות הן סיבה נפוצה לחוסר ביומני GKE. השתמשו בחלקים הבאים כדי לבדוק את ההגדרה של Cloud Logging.

אימות הסטטוס של Cloud Logging API

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

תסמינים:

לא רואים ב-Cloud Logging יומנים של משאבי GKE בפרויקט.

הסיבה:

ה-Cloud Logging API מושבת בפרויקט Cloud de Confiance by S3NS , ולכן סוכן Logging בצמתים לא יכול לשלוח יומנים.

הפתרון:

כדי לוודא ש-Cloud Logging API מופעל, ולהפעיל אותו אם צריך, בוחרים באחת מהאפשרויות הבאות:

אימות ההגדרה של רישום ביומן ברמת האשכול

ב-GKE אפשר להגדיר אילו סוגים של יומנים (למשל SYSTEM או WORKLOAD) נאספים מאשכול.

תסמינים:

יומנים לא מופיעים ב-Cloud Logging מאשכול GKE ספציפי, או שחסרים רק סוגים מסוימים של יומנים (כמו SYSTEM).

הסיבה:

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

הפתרון:

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

אימות היקפי הגישה של מאגר הצמתים

צמתים באשכול GKE משתמשים בהיקפי גישה של OAuth כדי לקבל הרשאה לאינטראקציה עם ממשקי API, כולל Cloud Logging. Cloud de Confiance by S3NS

תסמינים:

חסרים יומנים מצמתים במאגר צמתים ספציפי.

הסיבה:

לצמתים במאגר הצמתים אין את היקף ההרשאות הנדרש של OAuth. כדי שהצמתים יוכלו לכתוב יומנים ב-Cloud Logging, צריך להגדיר אחד מההיקפים הבאים:

• ‫https://www.googleapis.com/auth/logging.write: מעניק הרשאה לכתיבת יומנים. זהו ההיקף המינימלי הנדרש.
• ‫https://www.googleapis.com/auth/logging.admin: מעניקה גישה מלאה ל-Cloud Logging API, כולל ההרשאות מ-logging.write.
• ‫https://www.googleapis.com/auth/cloud-platform: מעניק גישה מלאה לכל ממשקי ה-API המופעלים, כולל ההרשאות מ-logging.write. Cloud de Confiance by S3NS

הפתרון:

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

אימות ההרשאות של חשבון השירות של הצומת

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

תסמינים:

• חסרים יומנים בצמתים.
• בדיקה של יומני סוכן הרישום (לדוגמה, Fluent Bit) עשויה להציג שגיאות שקשורות להרשאות, כמו קודים 401 או 403 כשמנסים לכתוב ב-Cloud Logging.
• יכול להיות שתראו התראה לגבי האשכול במסוף Cloud de Confiance .Grant Critical Permissions to Node Service Account

הסיבה:

הבעיה הזו נגרמת על ידי אחד מחשבונות השירות הבאים:

• חשבון שירות של הצומת: לחשבון השירות שמשמש את הצמתים במאגר הצמתים אין את הרשאות ה-IAM הנדרשות לכתיבת יומנים ב-Cloud Logging. לחשבון השירות של הצומת צריך להיות תפקיד שכולל את ההרשאה logging.logEntries.create.

• סוכן שירות של צומת GKE: ב-GKE מגרסה 1.33 ואילך, סוכן השירות של צומת GKE (service-PROJECT_NUMBER@gcp-sa-gkenode.iam.s3ns-system.iam.gserviceaccount.com) צריך לקבל את התפקיד סוכן שירות ברירת המחדל של צומת Kubernetes (roles/container.defaultNodeServiceAgent). התפקיד הזה מעניק ל-GKE גישה לניהול משאבים ופעולות של צמתים, כולל רכיבי רישום ביומן.

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

יכול להיות שיחלפו עד 24 שעות עד שהשינויים האחרונים יופיעו בכלי להמלצות.

הפתרון:

כדי לפתור את הבעיה, אפשר לנסות את השלבים הבאים:

1. מקצים לחשבון השירות של הצומת את התפקיד roles/container.defaultNodeServiceAccount בפרויקט של האשכול. התפקיד הזה כולל את ההרשאות ש-GKE צריך כדי לכתוב יומנים. מידע נוסף זמין במאמר הקצאת התפקיד הנדרש המינימלי ל-GKE.

2. אחרי שמבצעים את השלב הקודם, אם עדיין חסרים יומנים והאשכול משתמש בגרסה 1.33 ואילך, צריך להקצות את התפקיד roles/container.defaultNodeServiceAgent בפרויקט לסוכן השירות של צומת GKE:

   1. מאתרים את מספר הפרויקט:

      gcloud projects describe PROJECT_ID --format="value(projectNumber)"
      

      מחליפים את PROJECT_ID במזהה הפרויקט.

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

      המסוף

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

         כניסה לדף IAM

      2. מסמנים את התיבה Include Google-provided role grants.

      3. בשדה filter_list Filter, מציינים את כתובת האימייל הבאה של סוכן השירות:

         service-PROJECT_NUMBER@gcp-sa-gkenode.s3ns-system.iam.gserviceaccount.com
         

         מחליפים את PROJECT_NUMBER במספר הפרויקט מהפלט של השלב הקודם.

      4. מקישים על Enter.

      5. לוחצים על edit עריכת הגורם המורשה.

      6. לוחצים על add הוספת תפקידים.

      7. בשדה החיפוש, מזינים Kubernetes Engine Default Node Service Agent ובוחרים את התפקיד.

      8. לוחצים על Save.

      gcloud

      1. בודקים אם התפקיד roles/container.defaultNodeServiceAgent משויך לסוכן השירות:

         gcloud projects get-iam-policy PROJECT_ID \
             --flatten="bindings[].members" \
             --format='table(bindings.role)' \
             --filter="bindings.members:serviceAccount:service-PROJECT_NUMBER@gcp-sa-gkenode.s3ns-system.iam.gserviceaccount.com"
         

         מחליפים את PROJECT_NUMBER במספר הפרויקט מהפלט של השלב הקודם.

         בפלט, מחפשים את roles/container.defaultNodeServiceAgent.

      2. אם התפקיד חסר, צריך להקצות אותו:

         gcloud projects add-iam-policy-binding PROJECT_ID \
             --member="serviceAccount:service-PROJECT_NUMBER@gcp-sa-gkenode.s3ns-system.iam.gserviceaccount.com" \
             --role="roles/container.defaultNodeServiceAgent"
         

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

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

בדיקת השימוש במכסות של Cloud Logging API

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

תסמינים:

• יומני הרישום חסרים לסירוגין או לגמרי.
• מופיעות שגיאות RESOURCE_EXHAUSTED שקשורות ל-logging.googleapis.com ביומנים של הצומת או של סוכן הרישום ביומן.

הסיבה:

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

הפתרון:

כדי לבדוק את השימוש במכסה ולבקש הגדלה שלה:

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

   לפתיחת הדף Quotas

2. בשדה filter_list Filter (מסנן), מקלידים Cloud Logging API ומקישים על Enter.

3. ברשימה המסוננת, מחפשים את המכסה Log write bytes per minute per region לאזור שבו נמצא האשכול.

4. בודקים את הערכים בעמודה Current usage percentage. אם נפח השימוש הגיע למגבלה או קרוב אליה, סביר להניח שחרגתם מהמכסה.

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

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

בדיקת קצב העברת הנתונים של הצומת והשימוש במשאבים

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

תסמינים:

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

הסיבה:

לסוכן הרישום ביומן של GKE יש מגבלת קצב העברת נתונים כברירת מחדל (בערך 100 KBps לכל צומת). אם אפליקציות בצומת יוצרות יומנים מהר יותר מהמגבלה הזו, יכול להיות שהסוכן ישמיט יומנים, גם אם לא חרגתם מהמכסה הכוללת של ה-API בפרויקט. אתם יכולים לעקוב אחרי תפוקת הרישום ביומן של הצומת באמצעות המדד kubernetes.io/node/logs/input_bytes ב-Metrics Explorer.

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

הפתרון:

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

פתרון בעיות בסינון ובאפליקציות

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

בדיקת מסנני החרגה ביומן

בכלי Logs Explorer מוצגים רק יומנים שתואמים לכל המסננים בשאילתה ולטווח הזמן שנבחר.

תסמינים:

יומנים ספציפיים שתואמים לקריטריונים מסוימים חסרים ב-Cloud Logging, אבל יומנים אחרים מאותם מקורות מופיעים.

הסיבה:

מסנני החרגה מיומן מוגדרים באובייקטים מסוג sink ב-Cloud Logging (לרוב באובייקט _Default). הכללים האלה משמיטים בשקט יומנים שתואמים לקריטריונים ספציפיים, גם אם הם נשלחו בהצלחה על ידי הצומת.

הפתרון:

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

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

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

תסמינים:

• יומנים ממכולות ספציפיות מופיעים ב-Cloud Logging רק אחרי שהמכולה יוצאת, או שיש עיכוב משמעותי בהופעת היומנים.
• לפעמים, היומנים לא מלאים.

הסיבה:

הבעיה הזו נגרמת לרוב בגלל אחסון זמני של יומנים. למרות שהפלט הרגיל (stdout) בדרך כלל נשמר בזיכרון זמני לפי שורה כשמחוברים למסוף, ההתנהגות הזו משתנה כשמפנים את הפלט לצינור. אם יומני אפליקציה או סקריפטים להפעלה בתוך צינור של קונטיינר stdout מועברים לפקודות אחרות (לדוגמה, my-app | grep ...), יכול להיות שהפלט יאוגר באופן מלא. כתוצאה מכך, רשומות היומן מושהות עד שמאגר הנתונים הזמני מתמלא או עד שהצינור נסגר. התנהגות כזו עלולה לגרום לעיכובים או לאובדן נתונים אם הקונטיינר מסתיים באופן בלתי צפוי. גם אחסון זמני (באפרינג) בתוך האפליקציה יכול לגרום לעיכובים.

הפתרון:

כדי לפתור את הבעיה, אפשר לנסות את הפתרונות הבאים:

• הימנעות מצינורות (piping) של stdout: אם אפשר, כדאי לשנות את נקודות הכניסה של הקונטיינר או את פקודות האפליקציה כדי לכתוב יומנים ישירות אל stdout או אל stderr בלי להשתמש בצינורות דרך פקודות אחרות כמו grep או sed בתוך הקונטיינר.
• Ensure line buffering:
  • אם אי אפשר להימנע מצינורות, צריך להשתמש בכלים שתומכים בחיץ שורות. לדוגמה, משתמשים ב-grep --line-buffered.
  • באפליקציות בהתאמה אישית, צריך לוודא שהן מרוקנות את היומנים בתדירות גבוהה, רצוי אחרי כל שורה, כשהן כותבות ל-stdout. בספריות רבות של רישום ביומן יש הגדרות לשליטה בחיץ.

• בדיקת התנהגות החיץ: פורסים את מניפסט ה-Pod הבא ומתבוננים בהשפעות ביומנים באמצעות הפקודה kubectl logs -f buffered-pod. כדי להתנסות, מוסיפים הערות ומבטלים הערות במערכים השונים של command buffered-container קובץ המניפסט:

  # buffered.yaml
  apiVersion: v1
  kind: ConfigMap
  metadata:
  name: run-script
  data:
  run.sh: |
      #!/bin/bash
      echo "Starting..."
      for i in $(seq 3600); do
      echo "Log ${i}"
      sleep 1
      done
      echo "Exiting."
  ---
  apiVersion: v1
  kind: Pod
  metadata:
  name: buffered-pod
  spec:
  containers:
      - name: buffered-container
      image: ubuntu  # Or any other image with bash
  
      # Case 1: Direct execution - line buffered by default to TTY
      # Logs appear immediately.
      command: ['/bin/bash', '-c', '/mnt/run.sh']
  
      # Case 2: Piped to grep - fully buffered by default
      # Logs might be delayed or appear in chunks.
      # command: ['/bin/bash', '-c', '/mnt/run.sh | grep Log']
  
      # Case 3: Piped to grep with --line-buffered
      # Logs appear immediately.
      # command: ['/bin/bash', '-c', '/mnt/run.sh | grep --line-buffered Log']
  
      volumeMounts:
          - name: scripts
          mountPath: /mnt
  volumes:
      - name: scripts
      configMap:
          name: run-script
          defaultMode: 0777
  restartPolicy: Never
  

בדיקת שאילתות ב-Logs Explorer

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

תסמינים:

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

הסיבה:

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

הפתרון:

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

   כניסה לדף Logs Explorer

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

3. מפשטים את השאילתה:

   1. ניקוי כל המסננים.

   2. כדאי לנסות לסנן רק לפי האשכול שלכם:

      resource.type="k8s_container"
      resource.labels.cluster_name="CLUSTER_NAME"
      resource.labels.location="LOCATION"
      

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

      • ‫CLUSTER_NAME: השם של האשכול.
      • ‫LOCATION: האזור או התחום של Compute Engine (לדוגמה, us-central1 או us-central1-a) של האשכול.

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

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

   • סוג המשאב: חשוב לוודא שאתם משתמשים בסוג המשאב הנכון. לדוגמה, האם אתם מסננים לפי k8s_container כשאתם צריכים לסנן לפי k8s_node?
   • תוויות: כדאי לבדוק את האיות של resource.labels, למשל namespace_name, ‏ container_name או תוויות בהתאמה אישית.
   • חומרה: מוודאים שרמת החומרה (לדוגמה, severity=ERROR) לא מגבילה מדי.
   • מטען ייעודי (payload) של טקסט: כדאי לבדוק אם יש שגיאות איות ומחרוזות מגבילות מדי במונחי חיפוש. לדוגמה, אם רוצים להשתמש באופרטור : (מכיל) במקום באופרטור = (התאמה מדויקת), צריך להשתמש ב-jsonPayload.message:"error" במקום ב-jsonPayload.message="error".

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

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

לקבלת עצות נוספות על שאילתות יעילות של רישום ביומנים, אפשר לעיין במאמר איתור מהיר של רשומות ביומן במאמרי העזרה של Cloud Logging.

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

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

סוכן הרישום ביומן של GKE אוסף רק יומנים שנכתבו לזרמי stdout ו-stderr.

תסמינים:

יומנים של Pod או קונטיינר ספציפיים לא מוצגים ב-Cloud Logging, למרות שיומנים אחרים מהאשכול כן מוצגים.

הסיבה:

האפליקציה לא כותבת ל-stdout או ל-stderr. יכול להיות שההגדרה שלו שגויה, והוא כותב את היומנים לקובץ בתוך הקונטיינר, כך שסוכן הרישום לא יכול לאסוף אותם.

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

הפתרון:

1. קובעים את שם ה-Pod ואת מרחב השמות של האפליקציה שהיומנים שלה חסרים:

   kubectl get pods -n NAMESPACE_NAME
   

2. בודקים את יומני הקונטיינר:

   • אם ל-Pod יש קונטיינר יחיד, מריצים את הפקודה הבאה:

     kubectl logs POD_NAME \
         -n NAMESPACE_NAME
     

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

     • ‫POD_NAME: השם של ה-Pod.
     • ‫NAMESPACE_NAME: מרחב השמות של ה-Pod.

   • אם ל-Pod יש כמה קונטיינרים, מציינים את שם הקונטיינר:

     kubectl logs POD_NAME \
         -c CONTAINER_NAME \
         -n NAMESPACE_NAME
     

     מחליפים את CONTAINER_NAME בשם של הקונטיינר ב-Pod.

   • כדי לעקוב אחרי היומנים בזמן אמת, מריצים את הפקודה הבאה:

     kubectl logs -f POD_NAME \
         -c CONTAINER_NAME \
         -n NAMESPACE_NAME
     

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

     • ‫POD_NAME: השם של ה-Pod.
     • ‫CONTAINER_NAME: השם של הקונטיינר ב-Pod.
     • ‫NAMESPACE_NAME: מרחב השמות של ה-Pod.

3. ניתוח הפלט:

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

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

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

   • אם הפקודה kubectl logs כן מציגה את היומנים הצפויים, סביר להניח שהבעיה מתרחשת בהמשך צינור הנתונים של הרישום ביומן (לדוגמה, סוכן, הרשאות או שירות Cloud Logging).

פתרון בעיות בפלטפורמה ובשירות

בקטעים הבאים מוסבר איך לחקור בעיות שקשורות לגורמים חיצוניים להגדרה המיידית שלכם, כמו מדיניות שמירת יומנים, תקינות של Cloud Logging או גרסאות GKE שלא נתמכות.

בדיקת תקופות השמירה של היומנים

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

תסמינים:

יומנים ישנים יותר מתאריך מסוים חסרים.

הסיבה:

היומנים שאתם מחפשים ישנים יותר מתקופת השמירה של קטגוריה ביומן שאליהם הם הועברו.

הפתרון:

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

בדיקת בעיות בשירות Cloud Logging ועיכובים בהעברה

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

תסמינים:

• אובדן נרחב או לסירוגין של יומנים בכמה פרויקטים או אשכולות.
• יש עיכוב משמעותי בהצגת היומנים ב-Logs Explorer.

הסיבה:

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

הפתרון:

• אפשר לבדוק את הסטטוס של שירותים שונים בCloud de Confiance by S3NSלוח הבקרה של Service Health. Cloud de Confiance by S3NS מחפשים אירועים פתוחים שקשורים ל-Cloud Logging או ל-GKE.

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

חקירת גרסת האשכול

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

תסמינים:

בעיות ברישום ביומן מתרחשות במקביל למגבלות של גרסת האשכול.

הסיבה:

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

הפתרון:

כדי לפתור את הבעיה:

1. בודקים את הגרסה של האשכול:

   gcloud container clusters describe CLUSTER_NAME \
       --location LOCATION \
       --format="value(currentMasterVersion)"
   

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

   • ‫CLUSTER_NAME: השם של האשכול.
   • ‫LOCATION: האזור או התחום של Compute Engine (לדוגמה, us-central1 או us-central1-a) של האשכול.

2. כדי לוודא שהגרסה נתמכת, משווים אותה ללוח הזמנים של מהדורות GKE.

3. אם האשכול משתמש בגרסה לא נתמכת, צריך לשדרג את האשכול.

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

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

  • פתיחת בקשת תמיכה באמצעות פנייה אל Cloud Customer Care.
  • קבלת תמיכה מהקהילה על ידי פרסום שאלות ב-StackOverflow ושימוש בתג google-kubernetes-engine כדי לחפש בעיות דומות. אפשר גם להצטרף לערוץ Slack‏ #kubernetes-engine כדי לקבל תמיכה נוספת מהקהילה.
  • פתיחת דיווחים על בעיות או בקשות להוספת תכונות באמצעות הכלי הציבורי למעקב אחר בעיות.