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

טייס אוטומטי רגילה

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

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

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

למידע נוסף על שימוש ביומנים כדי לפתור בעיות בעומסי העבודה ובאשכולות, ראו ניתוח היסטורי באמצעות 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 לא נתמכת.	חקירת גרסת האשכול

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

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

ניפוי באגים בבעיות ביומן של GKE באמצעות `gcpdiag`

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

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

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

רישום ביומן ברמת הפרויקט: מוודא שממשק Cloud Logging API מופעל בפרויקט שבו נמצא אשכול GKE. Google Cloud
רישום ביומן ברמת האשכול: מוודא שהרישום ביומן מופעל באופן מפורש בהגדרות של אשכול GKE.
הרשאות של מאגר הצמתים: מאשרות שהצמתים במאגרי הצמתים של האשכול מוגדרים עם היקף Cloud Logging Write, כך שהם יכולים לשלוח נתוני יומן.
הרשאות לחשבון שירות: המערכת בודקת שלחשבון השירות שמשמש את מאגרי הצמתים יש את הרשאות ה-IAM הנדרשות כדי לבצע אינטראקציה עם Cloud Logging. בדרך כלל נדרש התפקיד roles/logging.logWriter.
מכסות כתיבה של Cloud Logging API: המערכת בודקת שלא חרגתם ממכסות הכתיבה של Cloud Logging API בפרק הזמן שצוין.

מסוףGoogle Cloud

משלימים את הפקודה הבאה ואז מעתיקים אותה.

gcpdiag runbook gke/logs \
    --parameter project_id=PROJECT_ID \
    --parameter name=CLUSTER_NAME \
    --parameter location=LOCATION

פותחים את Google Cloud המסוף ומפעילים את Cloud Shell.

פתיחת מסוף Cloud

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

Docker

אפשר להריץ את gcpdiag באמצעות wrapper שמתחיל את gcpdiag בקונטיינר של Docker. צריך להתקין את Docker או את Podman.

מעתיקים את הפקודה הבאה ומריצים אותה בתחנת העבודה המקומית.
```
curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
```

מריצים את הפקודה gcpdiag.

./gcpdiag runbook gke/logs \
    --parameter project_id=PROJECT_ID \
    --parameter name=CLUSTER_NAME \
    --parameter location=LOCATION

כאן אפשר לראות את הפרמטרים הזמינים של קובץ ה-runbook הזה.

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

‫PROJECT_ID: מזהה הפרויקט שמכיל את המשאב.
‫CLUSTER_NAME: השם של אשכול GKE.
‫LOCATION: האזור או התחום של Compute Engine (לדוגמה, us-central1 או us-central1-a) של האשכול.

דגלים שימושיים:

‫--universe-domain: אם רלוונטי, הדומיין של Trusted Partner Sovereign Cloud שמארח את המשאב
‫--parameter או -p: פרמטרים של Runbook

רשימה ותיאור של כל הדגלים של כלי gcpdiag מופיעים בהוראות השימוש ב-gcpdiag.

שימוש ב-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 מושבת בפרויקט Google Cloud , ולכן סוכן Logging בצמתים לא יכול לשלוח יומנים.

הפתרון:

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

המסוף

במסוף Google Cloud , נכנסים לדף Enabled APIs & services.

כניסה אל Enabled APIs & services
בשדה Filter (מסנן), מקלידים Cloud Logging API ומקישים על Enter.
אם ממשק ה-API מופעל, הוא יופיע ברשימה. אם ה-API לא מופיע ברשימה, צריך להפעיל אותו:
1. לוחצים על Enable APIs and services.
2. בשדה חיפוש, מקלידים Cloud Logging API ומקישים על Enter.
3. לוחצים על התוצאה Cloud Logging API.
4. לוחצים על Enable.

gcloud

בודקים אם ה-API מופעל:

gcloud services list --enabled --filter="NAME=logging.googleapis.com"

הפלט צריך להיות:

NAME: logging.googleapis.com
TITLE: Cloud Logging API

אם ה-API לא מופיע ברשימת השירותים המופעלים, צריך להפעיל אותו:
```
gcloud services enable logging.googleapis.com \
    --project=PROJECT_ID
```
מחליפים את PROJECT_ID במזהה הפרויקט ב- Google Cloud.

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

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

תסמינים:

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

הסיבה:

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

הפתרון:

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

המסוף

נכנסים לדף Kubernetes clusters במסוף Google Cloud .

מעבר אל Kubernetes clusters
לוחצים על שם האשכול שרוצים לבדוק.
לוחצים על הכרטיסייה פרטים ועוברים לקטע מאפיינים.
בשורה Logging (רישום ביומן), בודקים אילו סוגי יומנים מופעלים, כמו System (מערכת) או Workloads (עומסי עבודה).
אם סוגי היומנים שרוצים לאסוף מושבתים או שגויים, לוחצים על עריכת הרישום ביומן.
ברשימה Components, מסמנים את תיבות הסימון של סוגי היומנים שרוצים לאסוף ולוחצים על OK. מידע נוסף על סוגי היומנים הזמינים מופיע במאמר מידע על יומנים ב-GKE.
לוחצים על שמירת השינויים.

gcloud

כדי לבדוק את הגדרות הרישום ביומן, מתארים את האשכול:
```
gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --format="value(name,loggingConfig.componentConfig.enableComponents)"
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫CLUSTER_NAME: השם של האשכול.
- ‫LOCATION: האזור או התחום של Compute Engine (לדוגמה, us-central1 או us-central1-a) של האשכול.
- ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
אם הרישום ביומן מופעל, הפלט דומה לפלט הבא:
```
example-cluster    SYSTEM_COMPONENTS;WORKLOADS
```
אם הפלט הוא NONE, הרישום ביומן מושבת.
אם סוגי היומנים שאתם רוצים מושבתים או שגויים, צריך לעדכן את הגדרות הרישום ביומן:
```
gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --logging=LOGGING_TYPE
```
מחליפים את LOGGING_TYPE ב-SYSTEM, ב-WORKLOAD או בשניהם. כדי לאסוף יומנים, צריך להפעיל את SYSTEM. אי אפשר לאסוף את היומנים של WORKLOAD בנפרד. מידע נוסף על סוגי היומנים הזמינים זמין במאמר מידע על יומנים של GKE.

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

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

תסמינים:

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

הסיבה:

לצמתים במאגר הצמתים אין את היקף הגישה הדרוש של 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. Google Cloud

הפתרון:

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

המסוף

בודקים את היקפי הגישה של מאגר הצמתים:
1. נכנסים לדף Kubernetes clusters במסוף Google Cloud .
  
  מעבר אל Kubernetes clusters
2. כדי לפתוח את דף הפרטים של האשכול, לוחצים על שם האשכול שרוצים לבדוק.
3. לוחצים על הכרטיסייה Nodes.
4. בקטע Node Pools (מאגרי צמתים), לוחצים על השם של מאגר הצמתים שרוצים לבדוק.
5. עוברים לקטע אבטחה.
6. בודקים את ההיקפים שמופיעים בשדה היקפי גישה. צריך לוודא שלפחות אחד מהיקפי ההרשאות הנדרשים מופיע:
  - ‫Stackdriver Logging API – כתיבה בלבד
  - ‫Stackdriver Logging API - Full
  - ‫Cloud Platform – מופעל
  אם ההיקפים הנדרשים חסרים, צריך ליצור מחדש את מאגר הצמתים. אי אפשר לשנות את היקפי הגישה במאגר צמתים קיים.
אם צריך, יוצרים מאגר צמתים חדש עם ההיקף הנדרש:
1. חוזרים לדף הפרטים של האשכול שרוצים לשנות.
2. לוחצים על הכרטיסייה Nodes.
3. לוחצים על יצירת מאגר צמתים בניהול המשתמש.
4. ממלאים את הפרטים בקטע פרטי מאגר הצמתים.
5. בתפריט הניווט שבצד ימין, לוחצים על אבטחה.
6. בקטע Access scopes, בוחרים את התפקידים שרוצים להוסיף:
  - כדי להוסיף היקפי גישה ספציפיים, בוחרים באפשרות Set access for each API (הגדרת גישה לכל API).
  - כדי לאפשר גישה מלאה, בוחרים באפשרות Allow full access to all Cloud APIs.
7. מגדירים את שאר הקטעים לפי הצורך.
8. לוחצים על יצירה.
העברת עומסי העבודה למאגר הצמתים החדש. אחרי שמעבירים את עומסי העבודה למאגר הצמתים החדש, האפליקציות פועלות בצמתים שיש להם את ההיקפים הדרושים לשליחת יומנים ל-Cloud Logging.
מוחקים את מאגר הצמתים הישן:
1. חוזרים לדף הפרטים של האשכול ובוחרים בכרטיסייה Nodes.
2. בקטע Node Pools (מאגרי צמתים), מאתרים את מאגר הצמתים הישן.
3. לצד מאגר הצמתים, לוחצים על מחיקה .
4. כשמופיעה בקשת אישור, מקלידים את השם של מאגר הצמתים ולוחצים על מחיקה.

gcloud

בודקים את היקפי הגישה של מאגר הצמתים:
```
gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --format="value(nodePools[].name,nodePools[].config.oauthScopes)"
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫CLUSTER_NAME: השם של האשכול.
- ‫LOCATION: האזור או התחום של Compute Engine (לדוגמה, us-central1 או us-central1-a) של האשכול.
- ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
בודקים את הפלט של כל מאגר צמתים. מוודאים שלפחות אחד מהיקפי ההרשאות הנדרשים (https://www.googleapis.com/auth/logging.write,‏ https://www.googleapis.com/auth/cloud-platform או https://www.googleapis.com/auth/logging.admin) מופיע ברשימה. אם ההיקפים הנדרשים חסרים, צריך ליצור מחדש את מאגר הצמתים. אי אפשר לשנות את היקפי הגישה במאגר צמתים קיים.
אם צריך, יוצרים מאגר צמתים חדש עם ההיקף הנדרש:
```
gcloud container node-pools create NEW_NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --scopes=https://www.googleapis.com/auth/logging.write,OTHER_SCOPES
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫NEW_NODE_POOL_NAME: שם למאגר הצמתים החדש.
- ‫OTHER_SCOPES: רשימה מופרדת בפסיקים של היקפי הרשאות אחרים שהצמתים שלכם צריכים. אם לא צריך היקפים אחרים, משמיטים את ה-placeholder הזה ואת הפסיק שלפניו.
העברת עומסי העבודה למאגר הצמתים החדש. אחרי שמעבירים את עומסי העבודה למאגר הצמתים החדש, האפליקציות פועלות בצמתים שיש להם את היקפי ההרשאות הנדרשים לשליחת יומנים ל-Cloud Logging.

מוחקים את מאגר הצמתים הישן:

gcloud container node-pools delete OLD_NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID

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

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

תסמינים:

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

הסיבה:

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

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

הפתרון:

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

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

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

חשבון השירות של הצומת הוא החשבון שבו הצומת משתמש כדי לבצע אימות ולשלוח יומנים. כדי לזהות את חשבון השירות הזה ולוודא שיש לו את ההרשאה הנדרשת roles/logging.logWriter, מבצעים את הפעולות הבאות:

כדי לזהות את חשבון השירות שמשמש את מאגר הצמתים, בוחרים באחת מהאפשרויות הבאות:
המסוף
1. נכנסים לדף Kubernetes clusters במסוף Google Cloud .
  
  מעבר אל Kubernetes clusters
2. ברשימת האשכולות, לוחצים על שם האשכול שרוצים לבדוק.
3. בהתאם למצב הפעולה של האשכול, מבצעים אחת מהפעולות הבאות:
  - במקרים של אשכולות רגילים, מבצעים את הפעולות הבאות:
    
    לוחצים על הכרטיסייה Nodes.
    
    בטבלה Node pools (מאגרי צמתים), לוחצים על שם של מאגר צמתים. ייפתח דף הפרטים של מאגר הצמתים.
    
    בקטע Security, מוצאים את השדה חשבון שירות.
  - לגבי אשכולות Autopilot, מבצעים את הפעולות הבאות:
    
    עוברים לכרטיסייה פרטים.
    
    בקטע Security, מוצאים את השדה חשבון שירות.
  אם הערך בשדה חשבון שירות הוא default, הצמתים משתמשים בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine. אם הערך בשדה הזה הוא לא default, הצמתים משתמשים בחשבון שירות בהתאמה אישית. במאמר שימוש בחשבונות שירות עם הרשאות מינימליות ב-IAM מוסבר איך מקצים את התפקיד הנדרש לחשבון שירות בהתאמה אישית.
gcloud
מריצים את הפקודה הבאה, בהתאם לסוג האשכול שבו משתמשים:
אשכולות רגילים
gcloud container node-pools describe NODE_POOL_NAME \ --cluster=CLUSTER_NAME \ --location=LOCATION \ --project=PROJECT_ID \ --format="value(config.serviceAccount)"

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

‫NODE_POOL_NAME: השם של מאגר הצמתים.

‫CLUSTER_NAME: השם של אשכול Standard.

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

‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud.

אם הפלט הוא default, מאגר הצמתים משתמש בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine. אם הערך לא default, הצמתים משתמשים בחשבון שירות בהתאמה אישית. במאמר שימוש בחשבונות שירות עם הרשאות מינימליות ב-IAM מוסבר איך להקצות את התפקיד הנדרש לחשבון שירות בהתאמה אישית.
אשכולות במצב Autopilot
gcloud container clusters describe CLUSTER_NAME \ --location=LOCATION \ --project=PROJECT_ID \ --format="value(nodePoolDefaults.nodeConfigDefaults.serviceAccount)"

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

‫CLUSTER_NAME: השם של אשכול Autopilot.

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

‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .

אם הפלט הוא default, מאגר הצמתים משתמש בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine. אם הערך לא default, הצמתים משתמשים בחשבון שירות בהתאמה אישית. במאמר שימוש בחשבונות שירות עם הרשאות מינימליות ב-IAM מוסבר איך להקצות את התפקיד הנדרש לחשבון שירות בהתאמה אישית.
סקריפטים מפורטים יותר לזיהוי הרשאות חסרות זמינים במאמר זיהוי כל חשבונות השירות של הצמתים עם הרשאות חסרות.
מערכת GKE סורקת באופן אוטומטי הרשאות חסרות ומספקת המלצות. כדי להשתמש בהמלצות כדי לבדוק אם יש הרשאות חסרות, בוחרים באחת מהאפשרויות הבאות:
המסוף
1. בדף Kubernetes clusters, מאתרים את העמודה Notifications.
2. בודקים בעמודה התראות אם מופיעה ההמלצה הענקת הרשאות קריטיות. ההמלצה הזו מציינת שהבדיקה NODE_SA_MISSING_PERMISSIONS נכשלה.
3. אם ההמלצה מופיעה, לוחצים עליה. תיפתח חלונית פרטים עם הסבר על ההרשאות החסרות ועם השלבים לפתרון הבעיה.
gcloud
1. הצגת רשימה של המלצות לגבי הרשאות חסרות בחשבון שירות:
  gcloud recommender recommendations list \ --recommender=google.container.DiagnosisRecommender \ --location LOCATION \ --project PROJECT_ID \ --format yaml \ --filter="recommenderSubtype:NODE_SA_MISSING_PERMISSIONS"
2. מנתחים את פלט הפקודה:
  - אם הפקודה מחזירה רשימה ריקה, המשמעות היא שהכלי להמלצות לא מצא המלצות פעילות לגבי NODE_SA_MISSING_PERMISSIONS. נראה שלחשבונות השירות שנבדקו יש את ההרשאות הנדרשות.
  - אם הפקודה מחזירה בלוק YAML אחד או יותר, סימן שמערכת ההמלצות זיהתה בעיית הרשאות. בודקים את הפלט בשדות המרכזיים הבאים:
    
    ‫description: מספק סיכום של הבעיה, למשל מציין שחסר לחשבון השירות של הצומת התפקיד roles/logging.logWriter או שחסר לסוכן השירות של GKE התפקיד roles/container.defaultNodeServiceAgent.
    
    ‫resource: מציין את האשכול שהושפע.
    
    ‫content.operations: מכיל את הפתרון המומלץ. בקטע הזה מופיעה הפקודה המדויקת gcloud projects add-iam-policy-binding שנדרשת כדי להקצות את התפקיד הספציפי שחסר.
יכול להיות שיחלפו עד 24 שעות עד שהשינויים האחרונים יופיעו בכלי להמלצות.
אם רוצים לאמת את ההרשאות באופן מיידי, כדי לבדוק את ההרשאות ולהעניק את התפקיד, בוחרים באחת מהאפשרויות הבאות:
המסוף
1. נכנסים לדף IAM במסוף Google Cloud .
  
  כניסה לדף IAM
2. מוצאים את חשבון השירות שמשמש את מאגר הצמתים.
3. בעמודה Role, בודקים אם לחשבון השירות יש את התפקיד Logs Writer (roles/logging.logWriter).
4. אם ההרשאה חסרה, מוסיפים אותה:
  1. לוחצים על עריכת הגורם המרכזי.
  2. לוחצים על הוספת תפקיד נוסף.
  3. בשדה החיפוש, מזינים Logs Writer.
  4. מסמנים את התיבה Logs Writer ולוחצים על Apply (אישור).
  5. לוחצים על Save.
gcloud
1. בודקים את התפקידים הנוכחיים של חשבון השירות של הצומת:
  gcloud projects get-iam-policy PROJECT_ID \ --flatten="bindings[].members" \ --format='table(bindings.role)' \ --filter="bindings.members:serviceAccount:SERVICE_ACCOUNT_EMAIL"
2. אם הוא לא מופיע, צריך להקצות את התפקיד logging.logWriter:
  gcloud projects add-iam-policy-binding PROJECT_ID \ --member="serviceAccount:SERVICE_ACCOUNT_EMAIL" \ --role="roles/logging.logWriter"

אימות ההרשאות של סוכן השירות של GKE

אם עדיין חסרים יומנים, ואתם משתמשים בגרסה 1.33 ואילך, צריך לוודא שלסוכן שמנוהל על ידי Google, ש-GKE משתמש בו כדי לנהל את רכיבי הצומת, יש את ההרשאה הנדרשת:

כדי לזהות את כתובת האימייל של סוכן השירות, צריך למצוא את מספר הפרויקט:
```
gcloud projects describe PROJECT_ID --format="value(projectNumber)"
```
מחליפים את PROJECT_ID במזהה הפרויקט. שימו לב לפלט.

כתובת האימייל של סוכן השירות של GKE היא: service-PROJECT_NUMBER@gcp-sa-gkenode.iam.gserviceaccount.com
כדי להשתמש בהמלצות כדי לבדוק אם יש הרשאות חסרות, בוחרים באחת מהאפשרויות הבאות:
המסוף
1. בדף Kubernetes clusters, מוצאים את העמודה Notifications.
2. בודקים את העמודה של ההמלצה Grant critical permissions (הענקת הרשאות קריטיות).
3. אם ההמלצה מופיעה, לוחצים עליה. תיפתח חלונית פרטים עם הסבר על ההרשאות החסרות ועם השלבים לפתרון הבעיה.
gcloud
1. הצגת רשימה של המלצות לגבי הרשאות חסרות בחשבון שירות:
  gcloud recommender recommendations list \ --recommender=google.container.DiagnosisRecommender \ --location LOCATION \ --project PROJECT_ID \ --format yaml \ --filter="recommenderSubtype:NODE_SA_MISSING_PERMISSIONS"
2. מנתחים את פלט הפקודה. בודקים את הפלט כדי לראות אם יש תיאור שמציין שלסוכן השירות של GKE‏ (gcp-sa-gkenode) חסר התפקיד roles/container.defaultNodeServiceAgent.
כדי לבדוק את ההרשאות ולהקצות את התפקיד באופן מיידי, בוחרים באחת מהאפשרויות הבאות:
המסוף
1. נכנסים לדף IAM במסוף Google Cloud .
  
  כניסה לדף IAM
2. בשדה Filter, מקלידים את כתובת האימייל של סוכן השירות של GKE ולוחצים על Enter.
3. ברשימה המסוננת, בודקים אם לסוכן השירות יש לפחות את התפקיד Kubernetes Default Node Service Agent ‏(roles/container.defaultNodeServiceAgent).
4. אם התפקיד חסר, צריך להקצות אותו:
  1. לוחצים על עריכת הגורם המורשה לצד סוכן השירות.
  2. לוחצים על הוספת תפקידים.
  3. בשדה החיפוש, מזינים את התפקיד Kubernetes Default Node Service Agent ובוחרים אותו.
  4. לוחצים על 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.iam.gserviceaccount.com"
  בפלט, מחפשים את roles/container.defaultNodeServiceAgent.
2. אם התפקיד חסר, צריך להעניק את התפקיד Kubernetes Default Node Service Agent:
  gcloud projects add-iam-policy-binding PROJECT_ID \ --member="serviceAccount:service-PROJECT_NUMBER@gcp-sa-gkenode.iam.gserviceaccount.com" \ --role="roles/container.defaultNodeServiceAgent"

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

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

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

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

תסמינים:

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

הסיבה:

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

הפתרון:

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

נכנסים לדף Quotas במסוף Google Cloud .

לפתיחת הדף Quotas
בשדה Filter (מסנן), מקלידים Cloud Logging API ומקישים על Enter.
ברשימה המסוננת, מחפשים את המכסה Log write bytes per minute per region לאזור שבו נמצא האשכול.
בודקים את הערכים בעמודה Current usage percentage. אם נפח השימוש הגיע למגבלה או קרוב אליה, כנראה חרגתם מהמכסה.
כדי לבקש הגדלה, לוחצים על עריכת מכסה ופועלים לפי ההנחיות. איך רואים ומנהלים את המכסות?

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

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

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

תסמינים:

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

הסיבה:

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

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

הפתרון:

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

אשכולות רגילים

אפשר לנסות את הפתרונות הבאים:

הפעלת רישום ביומן עם תפוקה גבוהה: התכונה הזו מגדילה את הקיבולת לכל צומת. מידע נוסף זמין במאמר שינוי קצב העברת הנתונים של סוכן Cloud Logging.
הקטנת נפח היומן: ניתוח דפוסי רישום ביומן של האפליקציה. צריך לצמצם את הרישום של פעולות לא נחוצות או מפורטות מדי ביומן.
פריסת סוכן רישום בהתאמה אישית: אתם יכולים לפרוס ולנהל DaemonSet של Fluent Bit בהתאמה אישית, אבל אז אתם אחראים להגדרה ולתחזוקה שלו.
בדיקת השימוש במשאבי הצומת: גם אם נפח היומן נמצא בגבולות, צריך לוודא שהצמתים לא נמצאים בלחץ גבוה של המעבד (CPU) או הזיכרון. אם אין מספיק משאבים בצומת, סוכן הרישום לא יוכל לעבד ולשלוח את היומנים. אפשר לבדוק מדדים כמו kubernetes.io/node/cpu/core_usage_time ו-kubernetes.io/node/memory/used_bytes בכלי לבחירת מדדים.

אשכולות במצב Autopilot

אפשר לנסות את הפתרונות הבאים:

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

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

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

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

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

תסמינים:

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

הסיבה:

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

הפתרון:

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

המסוף

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

מעבר אל Logs Router
מזהים את המסנן הבעייתי:
1. לכל יעד (חוץ מהיעד _Required, שאי אפשר להוסיף לו מסנני החרגה), לוחצים על פעולות נוספות ובוחרים באפשרות הצגת פרטי היעד.
2. בודקים את השאילתות בקטע מסנני החרגה. משווים את לוגיקת המסנן למאפיינים של היומנים החסרים (לדוגמה, סוג המשאב, תוויות או מילות מפתח).
3. מעתיקים את השאילתה של מסנן ההחרגה.
4. עוברים לדף Logs Explorer.
  
  כניסה לדף Logs Explorer
5. מדביקים את שאילתת מסנן ההחרגה בחלונית השאילתות ולוחצים על הפעלת השאילתה.
6. מעיינים בתוצאות. היומנים שמוצגים הם אלה שהמסנן לא היה כולל. אם היומנים החסרים מופיעים בתוצאות האלה, סביר להניח שהמסנן הזה הוא הסיבה לכך.
משביתים או עורכים את המסנן:
1. חוזרים לדף Logs Router.
2. לוחצים על More actions (פעולות נוספות) עבור יעד הנתונים עם המסנן החשוד ובוחרים באפשרות Edit sink (עריכת יעד הנתונים).
3. מאתרים את הקטע Choose logs to filter out of sink ומוצאים את מסנן ההחרגה.
4. אפשר ללחוץ על השבתה כדי להשבית את המסנן, או לשנות את השאילתה שלו כדי שתהיה ספציפית יותר.
5. לוחצים על עדכון יעד. השינויים חלים על יומנים חדשים.

gcloud

הצגת רשימה של כל פריטי ה-sink בפרויקט:
```
gcloud logging sinks list --project=PROJECT_ID
```
כדי לראות את מסנני ההחרגה של כל מאגר:
```
gcloud logging sinks describe SINK_NAME --project=PROJECT_ID
```
בודקים את הקטע exclusions בפלט. משווים את לוגיקת הסינון למאפיינים של היומנים החסרים (לדוגמה, סוג המשאב, התוויות או מילות המפתח).
כדי לשנות את ההחרגות, מעדכנים את ההגדרות של יעד הנתונים:
1. מייצאים את הגדרות היעד לקובץ מקומי (לדוגמה, sink-config.yaml):
```
gcloud logging sinks describe SINK_NAME \
    --format=yaml > sink-config.yaml
```
2. פותחים את הקובץ sink-config.yaml בכלי לעריכת טקסט.
3. מוצאים את הקטע exclusions: ומסירים או משנים את המסנן הבעייתי.
4. מעדכנים את הכיור ששונה:
```
gcloud logging sinks update SINK_NAME sink-config.yaml \
    --project=PROJECT_ID
```
  מידע נוסף על הפקודה הזו זמין במאמרי העזרה בנושא gcloud logging sinks update.

בדיקת חיץ (buffer) ועיכובים ביומן של מאגר תגים

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

תסמינים:

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

הפתרון:

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

כניסה לדף Logs Explorer
לוחצים על בחירת טווח זמן. גם אם אתם חושבים שאתם יודעים מתי היו היומנים, נסו להשתמש בטווח רחב יותר כדי לשלול בעיות בתזמון.
מפשטים את השאילתה:
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.
אם השאילתה הרחבה פועלת, מוסיפים מחדש את המסננים המקוריים אחד אחרי השני:
- סוג המשאב: חשוב לוודא שאתם משתמשים בסוג המשאב הנכון. לדוגמה, האם אתם מסננים לפי k8s_container כשאתם צריכים לסנן לפי k8s_node?
- תוויות: כדאי לבדוק את האיות של resource.labels, למשל namespace_name, ‏ container_name או תוויות בהתאמה אישית.
- חומרה: מוודאים שרמת החומרה (לדוגמה, severity=ERROR) לא מגבילה מדי.
- מטען ייעודי (payload) של טקסט: כדאי לבדוק אם יש שגיאות איות ומחרוזות מגבילות מדי במונחי חיפוש. לדוגמה, אם רוצים להשתמש בכלל 'מכיל/ה' (:), צריך להשתמש בו במקום בכלל 'התאמה מדויקת' (=). כלומר, jsonPayload.message:"error" במקום jsonPayload.message="error".
צריך לוודא שהמסננים מתחשבים ברגישות לאותיות רישיות (בדרך כלל הטקסט לא רגיש לאותיות רישיות, אבל יכול להיות שהתוויות כן), לוודא שלערכים אין תווים מוסתרים או רווחים מיותרים, ולבדוק אם צריך להוסיף מרכאות למונחים עם תווים מיוחדים.
בודקים את ציר הזמן. ירידות פתאומיות כשמוסיפים מסנן יכולות לעזור לכם לזהות את החלק הבעייתי בשאילתה.

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

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

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

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

תסמינים:

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

הסיבה:

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

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

הפתרון:

קובעים את שם ה-Pod ואת מרחב השמות של האפליקציה שהיומנים שלה חסרים:
```
kubectl get pods -n NAMESPACE_NAME
```
בודקים את יומני הקונטיינר:
- אם ל-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.
ניתוח הפלט:
- אם לפקודה kubectl logs אין פלט או אם פלט הפקודה לא מכיל את היומנים הצפויים, הבעיה היא באפליקציה עצמה. הפקודה kubectl logs קוראת ישירות מהזרמים stdout ו-stderr שנלכדו על ידי זמן הריצה של הקונטיינר. אם היומנים לא מופיעים כאן, סוכן הרישום ביומן של GKE לא יכול לראות אותם.
  
  משנים את הקוד או את ההגדרה של האפליקציה כדי להפסיק את הכתיבה לקובץ, ובמקום זאת מתעדים את כל ההודעות ישירות ב-stdout (לרישום רגיל) וב-stderr (לרישום שגיאות).
- אם אתם רואים תמהיל של מחרוזות JSON ושורות טקסט רגיל, הפלט הזה מצביע על בעיה בפורמט. מגדירים את האפליקציה כך שתכתוב רק אובייקטים תקינים של JSON בשורה אחת בקבצים stdout ו-stderr.
- אם הפקודה kubectl logs כן מציגה את היומנים הצפויים, סביר להניח שהבעיה מתרחשת בהמשך צינור הנתונים של הרישום ביומן (לדוגמה, סוכן, הרשאות או שירות Cloud Logging).

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

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

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

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

תסמינים:

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

הסיבה:

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

הפתרון:

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

המסוף

מזהים את הקטגוריה שאליה מנותבים היומנים של GKE:
1. נכנסים לדף Logs Router במסוף Google Cloud .
  
  מעבר אל Logs Router
2. בודקים את העמודה יעד, שבה מוצג לאן היומנים מנותבים.
  
  היעד אמור להיראות כך:
```
logging.googleapis.com/projects/PROJECT_ID/locations/LOCATION/buckets/BUCKET_ID
```
  שימו לב לPROJECT_ID, לLOCATION ולBUCKET_ID.
  
  לרוב, היומנים מנותבים לקטגוריה _Default, אבל הם יכולים להיות מנותבים גם לקטגוריות אחרות אם הגדרתם יעד מותאם אישית.
בודקים את תקופת השמירה של קטגוריה ביומן:
1. נכנסים לדף Logs Storage במסוף Google Cloud .
  
  כניסה לדף Logs Storage
2. מאתרים את הדליים שתואמים ל-BUCKET_ID, ל-LOCATION ול-PROJECT_ID מתוך יעד ה-sink.
3. בודקים את העמודה תקופת השמירה בכל קטגוריה רלוונטית.
4. אם היומנים שרוצים לראות ישנים יותר מתקופת השמירה, הם נמחקו על ידי Cloud Logging. אם אתם צריכים תקופת שמירה ארוכה יותר, אתם יכולים:
  1. בקטגוריה שבה רוצים להאריך את תקופת השמירה, לוחצים על More actions.
  2. בוחרים באפשרות עריכת מאגר ומעדכנים את תקופת השמירה. חשוב להיות מודעים להשלכות האפשריות על העלויות.

gcloud

מזהים את הקטגוריה שאליה מנותבים היומנים של GKE:
```
gcloud logging sinks list --project=PROJECT_ID
```
בודקים את הפלט. בשדה destination של כל יעד מוצג המיקום שאליו מנותבים היומנים. פורמט היעד של קטגוריה ביומן הוא:
```
logging.googleapis.com/projects/PROJECT_ID/locations/LOCATION/buckets/BUCKET_ID
```
שימו לב לPROJECT_ID, לLOCATION ולBUCKET_ID.

לרוב, היומנים מנותבים לקטגוריית _Default.
בודקים את תקופת השמירה של קטגוריה ביומן:
```
gcloud logging buckets describe BUCKET_ID \
    --location=LOCATION \
    --project=PROJECT_ID
```
בפלט, מחפשים את השדה retentionDays. אם היומנים שאתם צריכים ישנים יותר מהערך שמופיע בשדה retentionDays, סימן שהם נמחקו מ-Cloud Logging.
אם אתם צריכים תקופת שמירה ארוכה יותר, אתם יכולים לעדכן אותה:
```
gcloud logging buckets update BUCKET_ID \
    --location=LOCATION \
    --retention-days=RETENTION_DAYS \
    --project=PROJECT_ID
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫BUCKET_ID: מזהה קטגוריה ביומן.
- ‫LOCATION: האזור או התחום של Compute Engine (לדוגמה, us-central1 או us-central1-a) של הקטגוריה.
- ‫RETENTION_DAYS: מספר הימים לשמירת היומנים. חשוב להבין את ההשלכות האפשריות על העלויות של הגדלת תקופת השמירה.
- ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .

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

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

תסמינים:

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

הסיבה:

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

הפתרון:

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

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

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

תסמינים:

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

הסיבה:

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

הפתרון:

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

בודקים את הגרסה של האשכול:
```
gcloud container clusters describe CLUSTER_NAME \
    --location LOCATION \
    --format="value(currentMasterVersion)"
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫CLUSTER_NAME: השם של האשכול.
- ‫LOCATION: האזור או התחום של Compute Engine (לדוגמה, us-central1 או us-central1-a) של האשכול.
כדי לוודא שזו גרסה נתמכת, משווים את הגרסה הזו ללוח הזמנים של מהדורות GKE.
אם האשכול משתמש בגרסה לא נתמכת, משדרגים את האשכול.

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

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

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

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

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

ניפוי באגים בבעיות ביומן של GKE באמצעות gcpdiag

מסוףGoogle Cloud

Docker

שימוש ב-Gemini Cloud Assist investigations

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

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

המסוף

gcloud

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

המסוף

gcloud

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

המסוף

gcloud

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

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

המסוף

gcloud

אשכולות רגילים

אשכולות במצב Autopilot

המסוף

gcloud

המסוף

gcloud

אימות ההרשאות של סוכן השירות של GKE

המסוף

gcloud

המסוף

gcloud

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

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

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

אשכולות רגילים

אשכולות במצב Autopilot

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

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

המסוף

gcloud

בדיקת חיץ (buffer) ועיכובים ביומן של מאגר תגים

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

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

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

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

המסוף

gcloud

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

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

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

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

ניפוי באגים בבעיות ביומן של GKE באמצעות `gcpdiag`