מעקב אחרי פריסות

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

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

אתם אחראים למעקב אחר תקינות וזמינות של עומסי העבודה (קונטיינרים ומכונות וירטואליות) שפועלים בפריסה המחוברת של Distributed Cloud.

עומסי עבודה של קונטיינרים

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

אפשר להשתמש במדדים החשובים הבאים כדי לעקוב אחרי עומסי עבודה של קונטיינרים. אם אתם משתמשים ב-Prometheus, אתם אחראים לפריסה ולניהול של Kube State Metrics כדי לחשוף את המדדים הספציפיים האלה לעומסי העבודה שלכם:

  • ‫kube_pod_status_phase: מעקב אחרי Pods בשלבים Failed או Unknown.
  • ‫kube_pod_container_status_waiting_reason: זיהוי של Pods שנתקעו במצב CrashLoopBackOff או ImagePullBackOff.
  • ‫container_cpu_usage_seconds_total ו-container_memory_working_set_bytes (מ-cAdvisor): מעקב אחרי צריכת המשאבים כדי למנוע בעיות שקשורות לזיכרון (OOM).

עומסי עבודה של מכונות וירטואליות

ב-Distributed Cloud Connected, מכונות וירטואליות (VM) פועלות בתוך פודים רגילים של Kubernetes, שבדרך כלל מתחילים בקידומת virt-launcher-. כדי לעקוב אחרי המצב והסטטוס של מכונה וירטואלית, בודקים בעיקר את הסטטוס של המשאב המותאם אישית VirtualMachine או עוקבים אחרי מדדי האפליקציה מתוך המכונה הווירטואלית.

אפשר להשתמש במדדים הבסיסיים של virt-launcher Pod כאינדיקטורים משניים לפרטים הבאים:

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

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

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

מעקב אחרי שדרוגים של Google Distributed Cloud במודל מחובר

אפשר לעקוב אחרי ההתקדמות והסטטוס של שדרוגי תוכנה ב-Distributed Cloud במודל מחובר באמצעות מדדים של Cloud Monitoring ופקודות gcloud. ‫Google מתזמנת ומבצעת את השדרוגים. המעקב נועד רק כדי לקבל תמונה ברורה ולתכנן את העברת עומסי העבודה.

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

מעקב אחר תקינות האחסון המקומי

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

מעקב אחר תקינות האחסון במערכת

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

  • ‫Prometheus עם Kube State Metrics‏ (PromQL). פריסה וניהול של Kube State Metrics באשכול כדי לחשוף מדדי תנאים של Kubernetes.

  • מדדים של Cloud Monitoring. יצירת מדיניות התראות על סמך מדדים ברמת המארח שמיוצאים ל-Cloud Monitoring.

מעקב אחר תקינות האחסון במערכת באמצעות Prometheus

כדי לעקוב אחרי תקינות האחסון במערכת באמצעות Prometheus עם Kube State Metrics ‏ (PromQL), צריך להגדיר את ההתראות הבאות:

  1. התראה מיידית כשמצב הצומת משתנה לDiskPressure:

    kube_node_status_condition{condition="DiskPressure",status="true"} == 1

  2. התראה פרואקטיבית לפני חריגה מספי איפוס על ידי בדיקה מתי השימוש בדיסק עולה על סף תפעולי:

    (1 - (node_filesystem_avail_bytes{mountpoint="/mnt/shared_lpvs"} / node_filesystem_size_bytes{mountpoint="/mnt/shared_lpvs"})) > THRESHOLD

    מחליפים את THRESHOLD בסף התפעולי של היעד בטווח 0.00 עד 1.00. ‫Google ממליצה להגדיר את הערך הזה ל-0.85.

מעקב אחרי תקינות האחסון במערכת באמצעות Cloud Monitoring

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

  • מדד: edgecontainer.googleapis.com/machine/disk/utilization
  • היקף: המדד הזה מדווח באופן ספציפי על ניצול הדיסק של מערכת הקבצים של מחיצת המערכת המקומית של הצומת (/dev/mapper/shared_lpvs_encrypted).
  • סף: הגדרת סף להתרעה כשניצול הדיסק גבוה מ-85%. כך אפשר לזהות מצב של ניצול מלא של נפח האחסון בדיסק המערכת לפני שמתרחש אירוע של DiskPressure צומת קשיח.

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

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

  • Filesystem מצב עוצמת הקול. אפשר לעקוב אחרי נפחי מערכת הקבצים באמצעות Prometheus על ידי גירוד המדדים הבאים של נפח Kubelet:

    • kubelet_volume_stats_capacity_bytes
    • kubelet_volume_stats_available_bytes
    • kubelet_volume_stats_used_bytes
    • kubelet_volume_stats_inodes_used
    • kubelet_volume_stats_inodes_free

  • Block מצב עוצמת הקול. נפחי אחסון גולמיים של בלוקים לא גלויים ל-Kubelet. כדי לעקוב אחרי תקינות הנתונים, צריך להשתמש במדדים ברמת האפליקציה או במדדים של Symcloud Storage.

ניטור של כמה אשכולות

אם אתם מנהלים הרבה אשכולות שמקושרים ל-Distributed Cloud, מומלץ להשתמש ב-Cloud Monitoring כדי לצבור ולסנן מדדים.

  • שימוש בתוויות משאבים: מדדים שמיוצאים ל-Cloud Monitoring כוללים תוויות שמזהות את המקור. התוויות הזמינות משתנות בהתאם לסוג המשאב:

    • למדדים של אשכולות וקונטיינרים, כמו k8s_container, התוויות העיקריות כוללות את הערכים הבאים:

      • ‫project_id: הפרויקט Google Cloud שבו מתארח האשכול.
      • ‫location: Google Cloud האזור שבו האשכול רשום.
      • ‫cluster_name: שם האשכול.

    • במדדי חומרה, כמו edgecontainer.googleapis.com/machine, התוויות העיקריות כוללות את הערכים הבאים:

      • ‫resource_container: הפרויקט Google Cloud שמשויך לחומרה.
      • ‫location: האזור Google Cloud שבו רשום אזור ה-Distributed Cloud במודל מחובר.
      • ‫machine_id: המזהה של המכונה.

      מדדי החומרה לא כוללים תווית cluster_name באופן ישיר.

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

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

אסטרטגיית התראות

המעקב אחרי Google Distributed Cloud במודל מחובר והתחזוקה שלו הם אחריות משותפת. בקטע הזה מוסבר על מה Google מתריעה ואיך אפשר להגדיר מדיניות התרעות משלכם.

מהן ההתראות של Google

‫Google מנטרת באופן רציף את התשתית הבסיסית. הוא מבצע פעולה ומודיע לכם אם יש צורך בכך במצבים הבאים:

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

הגדרת התראות

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

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

שגיאה תיאור מערכת ניטור פרטים
זמן השבתה של עומס העבודה פודים או מכונות וירטואליות לא מופעלים או נכנסים ללולאת קריסה Prometheus לעומסי עבודה של קונטיינרים, יוצרים התראות ב-kube_pod_status_phase כדי לזהות קבוצות Pod בשלבים Failed או Unknown. אפשר גם להגדיר התראה ב-kube_pod_container_status_waiting_reason כשהערך שווה ל-CrashLoopBackOff או ל-ImagePullBackOff.
Cloud Monitoring עבור עומסי עבודה של מכונות וירטואליות שפועלים ב-Pods, מגדירים התראות באמצעות מדדי קונטיינרים סטנדרטיים של Kubernetes ב-Cloud Monitoring כדי לעקוב אחרי הסטטוס של virt-launcher Pods.
מיצוי משאבים של עומס עבודה השימוש בדיסק מתקרב לקיבולת, או שיש שימוש גבוה בזיכרון או במעבד (CPU) בעומסי עבודה Prometheus עבור עומסי עבודה של קונטיינרים, מגדירים התראות על סף ב-container_cpu_usage_seconds_total וב-container_memory_working_set_bytes (מ-cAdvisor) כדי לזהות Pods שמתקרבים למגבלות המשאבים שלהם.
Cloud Monitoring כדי לעקוב אחרי האחסון במכונה, צריך לעקוב אחרי מדד ניצול הדיסק במכונה edgecontainer.googleapis.com/machine/disk/utilization כדי לזהות מתי האחסון בצומת מתקרב לקיבולת.
בעיות ברשת המקומית ממשק הרשת נעלם במחשבים Cloud Monitoring בודקים אם מדד הזמינות של רשת המכונה edgecontainer.googleapis.com/machine/network/up הוא false.
אין חיבור לאינטרנט Cloud Monitoring בודקים אם מדד הקישוריות לרשת edgecontainer.googleapis.com/machine/network/connectivity הוא false.
הפעלה מחדש של המכונה הפעלה מחדש או כיבוי לא צפויים של המכשיר Cloud Monitoring הגדרת התראות באמצעות מדדים של edgecontainer.googleapis.com/machine/uptime ו-edgecontainer.googleapis.com/machine/restart_count. מידע נוסף זמין במאמר בנושא פתרון בעיות בהפעלה מחדש של מכונות.
מיצוי נפח האחסון של המערכת נגמר המקום באחסון המערכת Cloud Monitoring הגדרת התראות עם המדד edgecontainer.googleapis.com/machine/disk/utilization. מידע נוסף מופיע במאמר מעקב אחרי תקינות האחסון במערכת.

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