יצירת כללי מדיניות התראות

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

לפני שמתחילים

כדי ליצור מדיניות התראות, צריך את ההרשאות הבאות:

  • monitoring.alertPolicies.create
  • monitoring.alertPolicies.delete
  • monitoring.alertPolicies.update

יש לכם את ההרשאות האלה אם יש לכם אחד מהתפקידים הבאים:

  • monitoring.alertPolicyEditor
  • monitoring.editor
  • עריכת פרויקטים
  • בעלי הפרויקט

כדי ליצור מדיניות התראות מבוססת-יומן באמצעות Google Cloud CLI, צריך גם את התפקיד serviceusage.serviceUsageConsumer. הוראות להגדרת מדיניות התראות מבוססת-יומנים זמינות במאמר בנושא הגדרת התראות מבוססות-יומנים במסמכי התיעוד של Google Cloud Observability.

כדי לבדוק את התפקידים שלכם, עוברים אל הדף IAM במסוף Google Cloud .

יצירת מדיניות לדוגמה: שרת API לא זמין

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

  1. מורידים את קובץ התצורה של המדיניות: apiserver-unavailable.json
  2. יוצרים את המדיניות:
        gcloud monitoring policies create --policy-from-file=POLICY_CONFIG
        

    מחליפים את POLICY_CONFIG בנתיב של קובץ התצורה שהורדתם.

  3. כדי לראות את מדיניות ההתראות:

    המסוף

    1. נכנסים לדף Monitoring במסוף Google Cloud .

      מעקב

    2. בצד ימין, בוחרים באפשרות Alerting (התראות).
    3. בקטע Policies (כללי מדיניות), תוכלו לראות רשימה של כללי המדיניות בנושא התראות.

      ברשימה, בוחרים באפשרות Anthos cluster API server unavailable (critical) (שרת ה-API של אשכול Anthos לא זמין (קריטי)) כדי לראות פרטים על המדיניות החדשה. בקטע תנאים מופיע תיאור של המדיניות. לדוגמה:

      Policy violates when ANY condition is met
      Anthos cluster API server uptime is absent for 5m

    gcloud

    gcloud monitoring policies list

    בפלט מוצג מידע מפורט על המדיניות. לדוגמה:

    combiner: OR
    conditions:
    - conditionAbsent:
        aggregations:
        - alignmentPeriod: 60s
          crossSeriesReducer: REDUCE_MEAN
          groupByFields:
          - resource.label.project_id
          - resource.label.location
          - resource.label.cluster_name
          - resource.label.namespace_name
          - resource.label.container_name
          - resource.label.pod_name
          perSeriesAligner: ALIGN_MAX
        duration: 300s
        filter: resource.type = "k8s_container" AND metric.type = "kubernetes.io/anthos/container/uptime"
          AND resource.label."container_name"=monitoring.regex.full_match("kube-apiserver")
        trigger:
          count: 1
      displayName: Anthos cluster API server uptime is absent for 5m
      name: projects/…/alertPolicies/…/conditions/…
    displayName: Anthos cluster API server unavailable (critical)
    enabled: true
    mutationRecord:
      mutateTime: 
      mutatedBy: 
    name: projects/…/alertPolicies/…

יצירה של כללי מדיניות נוספים להתראות

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

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

  1. כדי להוריד את קובץ ההגדרות, לוחצים על הקישור בעמודה השמאלית.
  2. אפשר גם לשנות את התנאים כדי להתאים אותם טוב יותר לצרכים הספציפיים שלכם. לדוגמה, אתם יכולים להוסיף מסננים נוספים לקבוצת משנה של אשכולות, או לשנות את ערכי הסף כדי ליצור איזון בין רמת הרעש לבין רמת הקריטיות.
  3. מריצים את הפקודה gcloud monitoring policies create כדי ליצור את המדיניות.

זמינות של רכיבי מישור הבקרה

שם ההתראה תיאור הגדרת מדיניות התראות ב-Cloud Monitoring
שרת ה-API לא זמין (קריטי) מדד זמן הפעולה הרציפה של שרת ה-API לא זמין apiserver-unavailable.json
הכלי לתזמון לא זמין (קריטי) מדד הזמינות של הכלי לתזמון פגישות לא זמין scheduler-unavailable.json
מנהל הבקרים לא זמין (קריטי) מדד זמן הפעולה של מנהל הבקר לא זמין controller-manager-unavailable.json

מערכת Kubernetes

שם ההתראה תיאור הגדרת מדיניות התראות ב-Cloud Monitoring
הפעלה חוזרת של קריסת Pod (אזהרה) ה-Pod ממשיך להפעיל מחדש ויכול להיות שהוא במצב של לולאת קריסה pod-crash-looping.json
ה-Pod לא מוכן יותר משעה (קריטי) ה-Pod נמצא במצב לא מוכן במשך יותר משעה pod-not-ready-1h.json
השימוש במעבד של מאגר חורג מ-80 אחוז (אזהרה) ניצול המעבד (CPU) של הקונטיינר גבוה מ-80% מהמגבלה container-cpu-usage-high-reaching-limit.json
השימוש בזיכרון של הקונטיינר חורג מ-85% (אזהרה) השימוש בזיכרון של הקונטיינר הוא מעל 85% מהמגבלה container-memory-usage-high-reaching-limit.json
שימוש גבוה בנפח אחסון מתמיד (קריטי) לנפח האחסון המתמיד שנדרש יש פחות מ-3% של שטח פנוי persistent-volume-usage-high.json
השימוש במעבד (CPU) של הצומת חורג מ-80% (אזהרה) השימוש במעבד של הצומת הוא מעל 80% מההקצאה הכוללת למשך 5 דקות node-cpu-usage-high.json
השימוש בדיסק של הצומת חורג מ-85% (אזהרה) פחות מ-15 אחוזים פנויים לכל נקודת טעינה של דיסק למשך 10 דקות node-disk-usage-high.json
השימוש בזיכרון של הצומת חורג מ-80% (אזהרה) השימוש בזיכרון של הצומת הוא מעל 80% מהזיכרון הכולל שניתן להקצאה למשך 5 דקות node-memory-usage-high.json
צומת לא מוכן במשך יותר משעה (קריטי) הצומת נמצא במצב לא מוכן במשך יותר משעה node-not-ready-1h.json

ביצועים של Kubernetes

שם ההתראה תיאור הגדרת מדיניות התראות ב-Cloud Monitoring
יחס שגיאות השרת של API חורג מ-20% (קריטי) שרת ה-API מחזיר שגיאות 5xx או 429 ביותר מ-20% מכל הבקשות לכל פועל למשך 15 דקות apiserver-error-ratio-high.json
שינוי ב-ETCD leader או הצעה שנכשלה מתרחשים בתדירות גבוהה מדי (אזהרה) השינויים בetcd או הכשלים בהצעות קורים בתדירות גבוהה מדי etcd-leader-changes-or-proposal-failures-frequent.json
שרת ETCD לא נמצא בקוורום (קריטי) לא בוצעו הצעות לשרת etcd במשך 5 דקות, לכן יכול להיות שהן איבדו את הקוורום etcd-server-not-in-quorum.yaml
נפח האחסון של ETCD חורג מ-90% מהמגבלה (אזהרה) השימוש בנפח אחסון נדרש etcd הוא יותר מ-90% מהמגבלה etcd-storage-usage-high.json

כללי מדיניות התראות עם PromQL

אפשר גם להגדיר את השאילתות במדיניות ההתראות ב-PromQL במקום ב-MQL. לדוגמה, גרסת PromQL של מדיניות API server error ratio exceeds 20 percent (critical) זמינה להורדה: apiserver-error-ratio-high-promql.json.

מידע נוסף זמין במאמר בנושא שימוש בשירות מנוהל ל-Prometheus במסמכי העזרה של Google Distributed Cloud ובמאמר בנושא מדיניות התראות עם PromQL במסמכי העזרה של Cloud Monitoring.

קבלת התראות

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

הוראות להגדרת ערוצי התראות מופיעות במאמר ניהול ערוצי התראות.