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

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

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

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

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

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

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

  • ‫kube_pod_status_phase: מעקב אחרי פודים בשלבים 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, מכונות וירטואליות (VM) פועלות בתוך פודים רגילים של Kubernetes, בדרך כלל עם הקידומת virt-launcher-. כדי לעקוב אחרי התקינות והסטטוס של המכונה הווירטואלית, בודקים את הסטטוס של המשאב בהתאמה אישית VirtualMachine או עוקבים אחרי מדדי האפליקציה מתוך המכונה הווירטואלית.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

על מה Google מתריעה

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

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

הגדרת התראות

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

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

שגיאה תיאור מערכת מעקב פרטים
זמן השבתה של עומס העבודה תרמילים או מכונות וירטואליות שלא מצליחים להתחיל או נכנסים ללולאת קריסה Prometheus לעומסי עבודה של קונטיינרים, צרו התראות ב-kube_pod_status_phase כדי לזהות Pods בשלבים Failed או Unknown. אפשר גם להגדיר התראה על kube_pod_container_status_waiting_reason כשהערך שלו שווה ל-CrashLoopBackOff או ל-ImagePullBackOff.
Cloud Monitoring לעומסי עבודה של מכונות וירטואליות שפועלים ב-Pods, צריך להגדיר התראות באמצעות מדדים סטנדרטיים של קונטיינרים של Kubernetes ב-Cloud Monitoring כדי לעקוב אחרי הסטטוס של Pods של virt-launcher.
ניצול יתר של משאבים בעומס העבודה השימוש בדיסק מתקרב לקיבולת המקסימלית, או שיש שימוש גבוה בזיכרון או במעבד (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 ו-edg/1.13.0/docs/ogleapis.com/machine/restart_count. מידע נוסף זמין במאמר פתרון בעיות בהפעלות מחדש של מכונות.
ניצול מלא של נפח האחסון במערכת נגמר המקום באחסון של המערכת Cloud Monitoring אפשר להגדיר התראות באמצעות edgecontainer.googleapis.com/machine/disk/utilization/1.13.0/docs/more information, see Monitor system storage health.

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