‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

מידע על יומני GKE

Autopilot Standard

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

סקירה כללית

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

סוכן Logging ב-GKE

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

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

באירועים, GKE משתמש בפריסה במרחב השמות kube-system, שאוסף אירועים באופן אוטומטי ושולח אותם ל-Logging.

אילו יומנים נאספים

כברירת מחדל, GKE אוסף כמה סוגים של יומנים מהאשכול ומאחסן אותם ב-Cloud Logging:

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

המגבלות הבאות עלולות לגרום לכך שיומני האפליקציות לא יישלחו ל-Cloud Logging:
- ביומני JSON, אין תמיכה במפתחות JSON כפולים.
- ‫stream הוא מפתח שמור בצינור עיבוד הנתונים של רישום ביומן ב-GKE. מפתח stream ביומן JSON של האפליקציה עלול לגרום להתנהגות לא צפויה ולשליחת יומנים.
- ב-Cloud Logging יש מגבלת גודל לכל LogEntry. כל LogEntry שחורג ממגבלת הגודל מושמט ביומני jsonPayload, ונחתך ביומני textPayload.

ב-GKE אפשר גם לאסוף סוגים נוספים של יומנים מרכיבים מסוימים של מישור הבקרה של Kubernetes, ולאחסן אותם ב-Cloud Logging:

יומני שרת ה-API כוללים את כל היומנים שנוצרו על ידי שרת ה-API של Kubernetes‏ (kube-apiserver).
יומני Scheduler כוללים את כל היומנים שנוצרו על ידי Kubernetes Scheduler (kube-scheduler).
יומני Controller Manager כוללים את כל היומנים שנוצרו על ידי Kubernetes Controller Manager‏ (kube-controller-manager).

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

איסוף היומנים שלך

כשיוצרים אשכול GKE חדש, השילוב עם Cloud Logging מופעל כברירת מחדל.

יומני המערכת והאפליקציות מועברים אל Log Router ב-Cloud Logging.

משם אפשר להטמיע את היומנים ב-Cloud Logging, להחריג אותם או לייצא אותם ל-BigQuery, ל-Pub/Sub או ל-Cloud Storage.

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

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

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

אם צמתים מסוימים ב-GKE דורשים תפוקת יומן גבוהה יותר מברירת המחדל, ואשכול GKE Standard משתמש בגרסה 1.23.13-gke.1000 או בגרסה מאוחרת יותר של מישור הבקרה, אתם יכולים להגדיר ל-GKE לפרוס הגדרה חלופית של סוכן Logging שנועדה למקסם את תפוקת הרישום ביומן.

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

איסוף יומנים באמצעות fluentd או fluentbit בהתאמה אישית

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

אי אפשר להתאים אישית את ההגדרות של הסוכן המנוהל הזה, אבל אפשר לפרוס DaemonSet בהתאמה אישית של fluentd או fluentbit כדי לאסוף את יומני האפליקציה.

מידע נוסף על הגדרות הרישום ביומן זמין בקטע יומנים זמינים בדף הזה.

איסוף יומנים של Linux‏ `auditd` לצומתי GKE

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

מידע נוסף זמין במאמר הפעלת יומני auditd של Linux בצומתי GKE.

יומני ביקורת של GKE

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

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

יש שני היבטים של בקרת גישה לרישום ביומן: גישה לאפליקציה וגישה למשתמשים. ב-Cloud Logging יש תפקידים של ניהול זהויות והרשאות גישה (IAM) שבעזרתם אפשר לתת גישה מתאימה.

גישה לאפליקציה

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

גישת צפייה של משתמשים

כדי לראות את היומנים בפרויקט, צריך להיות לכם תפקיד roles/logging.viewer. כדי לקבל גישה ליומני הגישה לנתונים, אתם צריכים את הרשאת ה-IAM‏ logging.privateLogViewer.

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

הרשאת אדמין למשתמשים

תפקידי ה-IAM‏ roles/logging.configWriter ו-roles/logging.admin מספקים את יכולות הניהול. התפקיד roles/logging.configWriter נדרש כדי ליצור יעד ליומן, שמשמש בדרך כלל להפניית היומנים לפרויקט ספציפי או מרכזי. לדוגמה, יכול להיות שתרצו להשתמש ביעד של יומנים יחד עם מסנן יומנים כדי להפנות את כל היומנים של מרחב שמות מסוים לקטגוריה מרכזית של יומנים.

מידע נוסף זמין במדריך בנושא בקרת גישה ב-Cloud Logging.

שיטות מומלצות

רישום מובנה ביומן: סוכן Logging שמשולב ב-GKE יקרא מסמכי JSON שעברו סריאליזציה למחרוזות של שורה אחת ונכתבו לפלט סטנדרטי או לשגיאה סטנדרטית, וישלח אותם ל-Google Cloud Observability כרשומות מובנות ביומן.
- למידע נוסף על עבודה עם סוכן Logging משולב, ראו רישום ביומן מובנה.
- אתם יכולים להשתמש במסננים מתקדמים של יומנים כדי לסנן יומנים על סמך השדות במסמך ה-JSON.
- ביומנים שנוצרו באמצעות glog, השדות הנפוצים ינותחו, לדוגמה, severity, pid, source_file, source_line. עם זאת, המטען הייעודי (payload) של ההודעה עצמה לא מנותח ומופיע מילה במילה בהודעת היומן שנוצרת ב-Google Cloud Observability.
רמות חומרה: כברירת מחדל, יומנים שנכתבים בפלט הסטנדרטי הם ברמה INFO ויומנים שנכתבים בשגיאה הסטנדרטית הם ברמה ERROR. יומנים מובְנים יכולים לכלול את השדה severity, שמגדיר את חומרת היומן.
ייצוא ל-BigQuery: כדי לבצע ניתוח נוסף, אפשר לייצא יומנים לשירותים חיצוניים, כמו BigQuery או Pub/Sub. היומנים שמיוצאים ל-BigQuery שומרים על הפורמט והמבנה שלהם. מידע נוסף זמין במאמר סקירה כללית על ניתוב ואחסון.
התראות: כשמתועדת ב-Logging התנהגות לא צפויה, אתם יכולים להשתמש במדדים מבוססי-יומנים כדי להגדיר מדיניות התראות. דוגמה מופיעה במאמר בנושא יצירת מדיניות התראות לגבי מדד של מונה. למידע מפורט על מדדים מבוססי-יומנים, קראו את המאמר סקירה כללית של מדדים מבוססי-יומנים.
דיווח על שגיאות: כדי לאסוף שגיאות מאפליקציות שפועלות באשכולות, אתם יכולים להשתמש ב-Error Reporting.

היומנים הזמינים

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

בטבלה הבאה מפורטים הערכים הנתמכים לדגל --logging בפקודות create ו-update.

מקור היומן	ערך של `--logging`	היומנים שנאספו
ללא	`NONE`	לא נשלחים יומנים ל-Cloud Logging, ולא מותקן באשכול סוכן לאיסוף יומנים. הערך הזה לא נתמך באשכולות Autopilot.
מערכת	`SYSTEM`	אוסף יומנים מהמקורות הבאים: כל ה-Pods שפועלים במרחבי השמות `kube-system`, `istio-system`, `knative-serving`, `gke-system` ו-`config-management-system`. שירותים שלא מבוססים על קונטיינרים, כולל סביבת זמן הריצה של `docker`/`containerd`, ‏ `kubelet`,‏ `kubelet-monitor`, ‏ `node-problem-detector` ו-`kube-container-runtime-monitor`. הפלט של היציאות הטוריות של הצומת, אם המטא-נתונים של מופע ה-VM‏ `serial-port-logging-enable` מוגדרים כ-true. אוסף גם אירועים של Kubernetes. חובה להזין את הערך הזה לכל סוגי האשכולות.
עומסי עבודה	`WORKLOAD`	כל היומנים שנוצרו על ידי קונטיינרים שאינם קונטיינרים של המערכת, שפועלים בצמתים של המשתמש. הערך הזה מופעל כברירת מחדל, אבל הוא אופציונלי לכל סוגי האשכולות.
שרת API	`API_SERVER`	כל היומנים שנוצרו על ידי `kube-apiserver`. הערך הזה אופציונלי לכל סוגי האשכולות.
מתזמן	`SCHEDULER`	כל היומנים שנוצרו על ידי `kube-scheduler`. הערך הזה הוא אופציונלי לכל סוגי האשכולות.
המרכז לניהול בקרים	`CONTROLLER_MANAGER`	כל היומנים שנוצרו על ידי `kube-controller-manager`. הערך הזה אופציונלי לכל סוגי האשכולות.
Horizontal Pod Autoscaler (HPA)	`KCP_HPA`	ייצוא של יומני ההחלטות לגבי המלצות אטומיות וסופיות לכל אובייקט HPA באשכול GKE. למידע נוסף, קראו את המאמר הצגת אירועים של Horizontal Pod Autoscaler (HPA).
Vertical Pod Autoscaler (טרום השקה)	`KCP_VPA`	מייצא את יומני ההחלטות של כל אובייקט VPA באשכול GKE. מידע נוסף זמין במאמר הצגת אירועים של Vertical Pod Autoscaler.
חיבורי רשת של מישור הבקרה	`KCP_CONNECTION`	זמין רק עם שליטה במישור הבקרה של GKE יומנים של חיבורים לרשת נכנסים עבור מופעים של מישור הבקרה של GKE. למידע נוסף, קראו את המאמר אימות החיבורים של Google למישור הבקרה של האשכול.
אירועי SSH במישור הבקרה	`KCP_SSHD`	זמין רק עם שליטה במישור הבקרה של GKE יצירת יומנים לכל אירועי ה-SSH, כמו קבלת מפתח ציבורי וסגירת סשן, שמתרחשים כשצוות Google מתחבר למכונות של מישור הבקרה של האשכול במהלך בקשות תמיכה או לצורך גישה אדמינסטרטיבית אחרת. למידע נוסף, קראו את המאמר אימות החיבורים של Google למישור הבקרה של האשכול.

תמחור

יומני GKE מיוצאים ל-Cloud Logging. התמחור של Cloud Logging חל.

אתם מחויבים על עלויות האחסון שנצברו כשאתם מייצאים יומנים לשירות אחר של Google Cloud , כמו BigQuery. למידע על העלויות שקשורות ל-Cloud Logging, ראו תמחור.

מכסה

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

אמצעי בקרת גישה

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

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