ביצוע מעקב יזום באמצעות Cloud Monitoring

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

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

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

בדיקת מדדים שימושיים

‫GKE שולח באופן אוטומטי קבוצה של מדדים ל-Cloud Monitoring. בקטעים הבאים מפורטים כמה מהמדדים החשובים ביותר לפתרון בעיות:

לרשימה המלאה של מדדי GKE

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

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

מדד תיאור פתרון בעיות שקשורות למובהקות
kubernetes.io/container/cpu/limit_utilization החלק ממגבלת המעבד (CPU) שנמצא כרגע בשימוש במכונה. הערך הזה יכול להיות גדול מ-1, כי יכול להיות שמותר למאגר לחרוג ממגבלת המעבד (CPU) שלו. מזהה ויסות נתונים (throttle) של מעבד (CPU). ערכים גבוהים עלולים לגרום לירידה בביצועים.
kubernetes.io/container/memory/limit_utilization החלק היחסי של מגבלת הזיכרון שנמצא כרגע בשימוש במופע. הערך הזה לא יכול להיות גבוה מ-1. מעקב אחרי הסיכון לשגיאות OutOfMemory ‏ (OOM).
kubernetes.io/container/memory/used_bytes הזיכרון בפועל שהקונטיינר צורך, בבייטים. עוקב אחרי צריכת הזיכרון כדי לזהות דליפות זיכרון פוטנציאליות או סיכון לשגיאות OOM.
kubernetes.io/container/memory/page_fault_count מספר השגיאות בדפים, בחלוקה לפי סוג: חמורות וקלות. מציין לחץ משמעותי על הזיכרון. כשלים חמורים בדפים מצביעים על כך שהזיכרון נקרא מהדיסק (החלפה), גם אם לא הגעתם למגבלות הזיכרון.
kubernetes.io/container/restart_count מספר הפעמים שהקונטיינר הופעל מחדש. מדגיש בעיות פוטנציאליות כמו קריסת אפליקציות, הגדרות שגויות או מיצוי משאבים באמצעות מספר גבוה או הולך וגדל של הפעלות מחדש.
kubernetes.io/container/ephemeral_storage/used_bytes נפח האחסון הזמני המקומי בשימוש, בבייטים. מעקב אחרי השימוש בדיסק הזמני כדי למנוע פינוי של Pods בגלל אחסון זמני מלא.
kubernetes.io/container/cpu/request_utilization החלק של המעבד (CPU) המבוקש שנמצא כרגע בשימוש במכונה. הערך הזה יכול להיות גדול מ-1, כי השימוש יכול לחרוג מהבקשה. מזהה בקשות למעבד עם הקצאת יתר או הקצאת חסר כדי לעזור לכם לבצע אופטימיזציה של הקצאת המשאבים.
kubernetes.io/container/memory/request_utilization החלק מהזיכרון המבוקש שנמצא כרגע בשימוש במכונה. הערך הזה יכול להיות גדול מ-1, כי השימוש יכול להיות גדול מהבקשה. מזהה בקשות לזיכרון עם הקצאת יתר או הקצאת חסר כדי לשפר את התזמון ולמנוע שגיאות OOM.

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

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

מדד תיאור פתרון בעיות שקשורות למידת החשיבות
kubernetes.io/node/cpu/allocatable_utilization החלק היחסי של מעבד שאפשר להקצות שנמצא כרגע בשימוש במכונה. מציין אם סכום השימוש ב-Pod מעמיס על משאבי ה-CPU הזמינים של הצומת.
kubernetes.io/node/memory/allocatable_utilization החלק היחסי של הזיכרון שניתן להקצאה שנמצא כרגע בשימוש במכונה. הערך הזה לא יכול להיות גדול מ-1, כי השימוש לא יכול להיות גדול מזיכרון הבייטים שניתן להקצאה. ההצעה הזו מצביעה על כך שאין מספיק זיכרון בצומת לתזמון של Pod חדש או להפעלה של Pod קיים, במיוחד אם הערכים גבוהים.
kubernetes.io/node/status_condition (בטא) תנאי של צומת משדה התנאי של סטטוס הצומת. דיווח על מצבים בריאותיים של הצומת, כמו Ready, MemoryPressure או DiskPressure.
kubernetes.io/node/ephemeral_storage/used_bytes בייטים של אחסון זמני מקומי שמשמשים את הצומת. הוא עוזר למנוע כשלים בהפעלת Pod או הוצאות של Pod מהמערכת, על ידי הצגת אזהרות לגבי שימוש גבוה בנפח אחסון נדרש זמני.
kubernetes.io/node/ephemeral_storage/inodes_free מספר חופשי של צמתי אינדקס (inodes) באחסון מקומי זמני. עוקב אחרי מספר ה-inodes החופשיים. אם נגמרים האיינודים, הפעולות עשויות להיעצר גם אם יש מקום בכונן.
‫kubernetes.io/node/interruption_count (בטא) ההפרעות הן הוצאות של התשתית מהמערכת, בזמן שהלקוח שולט בתשתית הזו. המדד הזה הוא הספירה הנוכחית של ההפרעות לפי סוג וסיבה. הסבר למה צומת עשוי להיעלם באופן בלתי צפוי בגלל פינויים מהמערכת.

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

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

מדד תיאור פתרון בעיות שקשורות למידת החשיבות
kubernetes.io/pod/network/received_bytes_count מספר הבייטים המצטבר שהתקבלו על ידי ה-Pod ברשת. מזהה פעילות חריגה ברשת (גבוהה או נמוכה) שיכולה להצביע על בעיות באפליקציה או ברשת.
‫kubernetes.io/pod/network/policy_event_count (בטא) שינוי במספר האירועים של מדיניות רשת ב-Kubernetes שמוצגים במישור הנתונים. זיהוי בעיות בקישוריות שנגרמות בגלל מדיניות רשת ב-Kubernetes.
kubernetes.io/pod/volume/utilization החלק מהנפח שנמצא כרגע בשימוש על ידי המכונה. הערך הזה לא יכול להיות גדול מ-1, כי השימוש לא יכול לחרוג מנפח האחסון הכולל שזמין. ההגדרה הזו מאפשרת ניהול פרואקטיבי של נפח האחסון, כי היא מציגה אזהרה כשיש ניצול גבוה (קרוב ל-1) שעלול להוביל לכשלים בכתיבה.
‫kubernetes.io/pod/latencies/pod_first_ready (בטא) זמן האחזור של הפעלת ה-Pod מקצה לקצה (מ-Pod ‏ `Created` עד ‏ `Ready`), כולל משיכות של תמונות. אבחון של Pods שמופעלים לאט.

המחשה ויזואלית של מדדים באמצעות Metrics Explorer

כדי להמחיש את המצב של סביבת GKE, יוצרים תרשימים על סמך מדדים באמצעות Metrics Explorer.

כדי להשתמש ב-Metrics Explorer:

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

    לדף Metrics Explorer

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

  3. צפייה בתוצאות ובמגמות לאורך זמן.

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

  1. ברשימה Select a metric, בוחרים את המדד kubernetes.io/container/memory/used_bytes ולוחצים על Apply.
  2. לוחצים על הוספת מסנן ובוחרים באפשרות שם_מרחב_השמות.
  3. ברשימה Value, בוחרים את מרחב השמות שרוצים לחקור.
  4. בשדה Aggregation, בוחרים באפשרות Sum > pod_name ולוחצים על OK. בהגדרה הזו מוצגת שורה נפרדת של סדרת זמנים לכל Pod.
  5. לוחצים על שמירת התרשים.

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

ב-Metrics Explorer יש הרבה אפשרויות לבניית המדדים שרוצים לראות. למידע נוסף על אפשרויות מתקדמות של Metrics Explorer, קראו את המאמר יצירת תרשימים באמצעות Metrics Explorer במסמכי התיעוד של Cloud Monitoring.

יצירת התראות לזיהוי יזום של בעיות

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

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

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

    מעבר אל Alerting

  2. לוחצים על יצירת מדיניות.

  3. בתיבה Select a metric, מסננים לפי CPU limit utilization ואז בוחרים את המדד הבא: kubernetes.io/container/cpu/limit_utilization.

  4. לוחצים על אישור.

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

  6. בקטע Transform data (שינוי נתונים), מבצעים את הפעולות הבאות:

    1. ברשימה חלון זמן דינמי, בוחרים באפשרות ‎1 minute. ההגדרה הזו אומרת ש- Cloud de Confiance מחשב ערך ממוצע כל דקה.

    2. ברשימה חלון זמן דינמי בוחרים באפשרות mean.

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

  7. לוחצים על הבא.

  8. בקטע Configure alert:

    1. בשדה Condition type, בוחרים באפשרות Threshold.
    2. בקטע Alert trigger (הפעלת התראה), בוחרים באפשרות Any time series violates (כל סדרת זמן חורגת).
    3. בקטע Threshold position, בוחרים באפשרות Above threshold.
    4. בשדה ערך הסף, מזינים 0.8. הערך הזה מייצג את סף ה-80% שרוצים לעקוב אחריו.
    5. לוחצים על אפשרויות מתקדמות.
    6. ברשימה Retest window בוחרים באפשרות 5 min. ההגדרה הזו אומרת שההתראה תופעל רק אם השימוש במעבד יישאר מעל 80% במשך חמש דקות רצופות, וכך יופעלו פחות אזעקות שווא כתוצאה מעליות קצרות.
    7. בשדה Condition name, נותנים לתנאי שם תיאורי.
    8. לוחצים על הבא.

  9. בקטע Configure the notifications and finalize the alert:

    1. ברשימה Notification channels, בוחרים את הערוץ שבו רוצים לקבל את ההתראה. אם אין לכם ערוץ, לוחצים על Manage notification channels כדי ליצור ערוץ.
    2. בשדה Name the alert policy (שם מדיניות ההתראות), נותנים למדיניות שם ברור ותיאורי.
    3. בכל שאר השדות משאירים את ערכי ברירת המחדל.
    4. לוחצים על הבא.

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

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

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