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

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

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

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

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

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

רשימה מלאה של מדדי GKE זמינה במאמר מדדי מערכת של 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, כי השימוש יכול להיות גבוה מהבקשה. הכלי מזהה בקשות ליחידות עיבוד מרכזיות (CPU) שהוקצו להן יותר מדי משאבים או פחות מדי משאבים, כדי לעזור לכם לבצע אופטימיזציה של הקצאת המשאבים.
kubernetes.io/container/memory/request_utilization החלק היחסי של הזיכרון המבוקש שנמצא כרגע בשימוש במופע. הערך הזה יכול להיות גדול מ-1, כי השימוש יכול להיות גבוה מהבקשה. מזהה בקשות לזיכרון עם הקצאת יתר או הקצאת חסר כדי לשפר את התזמון ולמנוע שגיאות OOM.

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

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

מדד תיאור פתרון בעיות שקשורות למובהקות
kubernetes.io/node/cpu/allocatable_utilization החלק היחסי של ה-CPU שניתן להקצאה שנמצא בשימוש כרגע במופע. מציין אם סכום השימוש ב-Pod גורם לעומס על משאבי המעבד הזמינים של הצומת.
kubernetes.io/node/memory/allocatable_utilization החלק היחסי של הזיכרון שניתן להקצאה שנמצא כרגע בשימוש במופע. הערך הזה לא יכול להיות גדול מ-1, כי השימוש לא יכול להיות גדול מבתים של זיכרון שניתן להקצאה. הערך הגבוה מצביע על כך שאין מספיק זיכרון בצומת לתזמון של פודים חדשים או להפעלה של פודים קיימים.
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 הפנויים. אם מספר ה-inodes יגיע למקסימום, יכול להיות שהפעולות ייעצרו גם אם יש מקום פנוי בדיסק.
kubernetes.io/node/interruption_count (בטא) ההפרעות הן פינויים של התשתית על ידי המערכת, בזמן שהלקוח שולט בתשתית הזו. המדד הזה הוא המספר הנוכחי של ההפרעות לפי סוג וסיבה. הסבר למה צומת עשוי להיעלם באופן בלתי צפוי בגלל פינוי מערכת.

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

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

מדד תיאור פתרון בעיות שקשורות למובהקות
kubernetes.io/pod/network/received_bytes_count מספר הבייטים המצטבר שה-Pod קיבל דרך הרשת. זיהוי פעילות חריגה ברשת (גבוהה או נמוכה) שיכולה להצביע על בעיות באפליקציה או ברשת.
kubernetes.io/pod/network/policy_event_count (בטא) שינוי במספר האירועים של מדיניות הרשת שמוצגים במישור הנתונים. זיהוי בעיות בקישוריות שנגרמות בגלל מדיניות הרשת.
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. ברשימה בחירת מדד, בוחרים את המדד kubernetes.io/container/memory/used_bytes ולוחצים על אישור.
  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. ברשימה Rolling window בוחרים באפשרות 1 minute. ההגדרה הזו אומרת ש- Cloud de Confiance מחשב ערך ממוצע כל דקה.

    2. ברשימה Rolling window function בוחרים באפשרות 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.

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