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

השירות המנוהל של Google Cloud ל-Prometheus תומך בהערכת כללים ובהתראות שתואמות ל-Prometheus. במאמר הזה מוסבר איך מגדירים הערכה של כללים מנוהלים.

הערכת הכלל

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

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

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

כללים

הכלי המנוהל להערכת כללים משתמש במשאב Rules כדי להגדיר כללי הקלטה והתראה. דוגמה למשאב Rules:

apiVersion: monitoring.googleapis.com/v1
kind: Rules
metadata:
  namespace: NAMESPACE_NAME
  name: example-rules
spec:
  groups:
  - name: example
    interval: 30s
    rules:
    - record: job:up:sum
      expr: sum without(instance) (up)
    - alert: AlwaysFiring
      expr: vector(1)

הפורמט של הרכיב .spec.groups זהה למערך rule_group של Prometheus במעלה הזרם. הכללים להתרעות ולתיעוד שמוגדרים ב-Rules מוגבלים ל-project_id, ל-cluster ול-namespace של המשאב. לדוגמה, הכלל job:up:sum במשאב שלמעלה מבצע שאילתה למעשה על sum without(instance) (up{project_id="test-project", cluster="test-cluster", namespace="NAMESPACE_NAME"}). ההתחייבות הזו מבטיחה שכללי ההתראה או ההקלטה לא יבצעו בטעות הערכה של מדדים מאפליקציות שאולי אתם לא מכירים.

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

kubectl apply -n NAMESPACE_NAME -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.17.2/examples/rules.yaml

אחרי כמה דקות, המדד job:up:sum יהיה זמין. ההתראה AlwaysFiring מתחילה לפעול. מידע על שליחת התראות ל-Alertmanager זמין במאמר בנושא הגדרת Alertmanager.

המשאבים ClusterRules ו-GlobalRules מספקים את אותו ממשק כמו המשאב Rules, אבל הם מחילים את הכללים על היקפים רחבים יותר. הפונקציה ClusterRules בוחרת נתונים באמצעות התוויות project_id ו-cluster, והפונקציה GlobalRules בוחרת את כל הנתונים בהיקף המדדים שנשאלו בלי להגביל את התוויות.

בprometheus-engine/doc/api reference אפשר למצוא מאמרי עזרה על כל המשאבים המותאמים אישית של שירות מנוהל ל-Prometheus.

המרת כללים של Prometheus לכללים

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

groups:
- name: example
  interval: 30s
  rules:
  - record: job:up:sum
    expr: sum without(instance) (up)
  - alert: AlwaysFiring
    expr: vector(1)

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

apiVersion: monitoring.googleapis.com/v1
kind: Rules
metadata:
  namespace: NAMESPACE_NAME
  name: example-rules
spec:
  groups:
  - name: example
    interval: 30s
    rules:
    - record: job:up:sum
      expr: sum without(instance) (up)
    - alert: AlwaysFiring
      expr: vector(1)

ClusterRules

אתם יכולים להשתמש במשאב ClusterRules כדי להגדיר כללי הקלטה והתראה שיכולים להעריך את כל סדרות הזמן שנשלחות אל שירות מנוהל ל-Prometheus מכל מרחבי השמות באשכול מסוים. המפרט זהה לזה של Rules. כלל Prometheus לדוגמה שמופיע למעלה הופך למשאב ClusterRules הבא:

apiVersion: monitoring.googleapis.com/v1
kind: ClusterRules
metadata:
  name: example-clusterrules
spec:
  groups:
  - name: example
    interval: 30s
    rules:
    - record: job:up:sum
      expr: sum without(instance) (up)
    - alert: AlwaysFiring
      expr: vector(1)

מומלץ להשתמש במשאבי ClusterRules רק במדדים אופקיים, כמו אלה שנוצרים על ידי Service mesh. כדי לקבל מדדים של פריסות נפרדות, צריך להשתמש במשאבי Rules כדי לוודא שההערכה לא כוללת נתונים לא רצויים.

GlobalRules

אתם יכולים להשתמש במשאב GlobalRules כדי להגדיר כללי הקלטה והתראות שיכולים להעריך את כל סדרות הזמן שנשלחות אל השירות המנוהל ל-Prometheus בכל הפרויקטים בהיקף המדדים. המפרט זהה לזה של Rules. כלל Prometheus לדוגמה שמופיע למעלה הופך למשאב GlobalRules הבא:

apiVersion: monitoring.googleapis.com/v1
kind: GlobalRules
metadata:
  name: example-globalrules
spec:
  groups:
  - name: example
    interval: 30s
    rules:
    - record: job:up:sum
      expr: sum without(instance) (up)
    - alert: AlwaysFiring
      expr: vector(1)

מכיוון שמדדים של Cloud Monitoring לא מוגבלים למרחב שמות או לאשכול, צריך להשתמש במשאב GlobalRules כשכותבים כללים או התראות למדדים של Cloud Monitoring. שימוש ב-GlobalRules נדרש גם כשמגדירים התראות על מדדי מערכת של Google Kubernetes Engine.

אם הכלל לא שומר על התוויות project_id או location, ברירת המחדל היא הערכים של האשכול.

לגבי מדדים של שירות מנוהל ל-Prometheus, מומלץ להשתמש ב-GlobalRules רק בתרחישי שימוש נדירים שבהם יכול להיות שצריך נתונים מכל האשכולות בבת אחת כדי להפעיל התראה. כדי לקבל מדדים של פריסות ספציפיות, כדאי להשתמש במשאבי Rules או ClusterRules כדי להגביר את המהימנות ולוודא שההערכה לא כוללת נתונים לא רצויים. מומלץ מאוד לשמור על התוויות cluster ו-namespace בתוצאות של הערכת הכלל, אלא אם מטרת הכלל היא לצמצם את התוויות האלה. אחרת, יכול להיות שביצועי השאילתה ירדו ותיתקלו במגבלות של עוצמת הקשר. לא מומלץ להסיר את שתי התוויות.

הערכת כללים בכמה פרויקטים וברמה הגלובלית

כשפורסים את הכלי להערכת כללים ב-Google Kubernetes Engine, הוא משתמש בGoogle Cloud פרויקט שמשויך לאשכול, והוא מזהה אותו באופן אוטומטי. כדי להעריך כללים שמשתרעים על פרויקטים, צריך להגדיר את כלי ההערכה של הכללים שמבצע את משאב GlobalRules כך שישתמש בפרויקט עם היקף מדדים של כמה פרויקטים. יש שתי דרכים לעשות את זה:

• ממקמים את משאב GlobalRules בפרויקט שיש לו היקף למעקב אחרי מדדים בכמה פרויקטים.
• מגדירים את השדה queryProjectID בתוך OperatorConfig כדי להשתמש בפרויקט עם היקף מדדים של כמה פרויקטים.

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

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

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

אפשר להשתמש במשאב GlobalRules כדי להגדיר התראות על Google Cloudמדדים של המערכת באמצעות PromQL. הוראות ליצירת שאילתה תקינה זמינות במאמר PromQL למדדי Cloud Monitoring.

הגדרת כללים והתראות באמצעות Terraform

אתם יכולים להפוך את היצירה והניהול של משאבי Rules,‏ ClusterRules ו-GlobalRules לאוטומטיים באמצעות סוג המשאב kubernetes_manifest Terraform או סוג המשאב kubectl_manifest Terraform. כל אחד מהם מאפשר לכם לציין משאבים מותאמים אישית שרירותיים.

מידע כללי על שימוש ב- Google Cloud עם Terraform זמין במאמר Terraform עם Google Cloud.

הזנת פרטי כניסה באופן מפורש

כשמריצים את הכלי להערכת כללים ב-GKE, הוא מאחזר באופן אוטומטי פרטי כניסה מהסביבה על סמך חשבון השירות של הצומת. באשכולות Kubernetes שאינם GKE, צריך לספק את פרטי הכניסה באופן מפורש דרך משאב OperatorConfig במרחב השמות gmp-public.

1. מגדירים את ההקשר לפרויקט היעד:

   gcloud config set project PROJECT_ID
   

2. יוצרים חשבון שירות:

   gcloud iam service-accounts create gmp-test-sa
   

3. נותנים לחשבון השירות את ההרשאות הנדרשות:

   gcloud projects add-iam-policy-binding PROJECT_ID \
     --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \
     --role=roles/monitoring.viewer \
   && \
   gcloud projects add-iam-policy-binding PROJECT_ID\
     --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \
     --role=roles/monitoring.metricWriter
   

4. יוצרים ומורידים מפתח לחשבון השירות:

   gcloud iam service-accounts keys create gmp-test-sa-key.json \
     --iam-account=gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com
   

5. מוסיפים את קובץ המפתח כסוד לאשכול שאינו GKE:

   kubectl -n gmp-public create secret generic gmp-test-sa \
     --from-file=key.json=gmp-test-sa-key.json
   

6. פותחים את המשאב OperatorConfig לעריכה:

   kubectl -n gmp-public edit operatorconfig config
   

   1. מוסיפים את הטקסט שמופיע בהדגשה למשאב:

      apiVersion: monitoring.googleapis.com/v1
      kind: OperatorConfig
      metadata:
        namespace: gmp-public
        name: config
      rules:
        credentials:
          name: gmp-test-sa
          key: key.json
      

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

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

   שינוי קנה המידה של הערכת הכללים

   הכלי להערכת כללים פועל כפריסת עותק יחיד עם בקשות ומגבלות קבועות של משאבים. יכול להיות שתשימו לב לשיבושים בחוויות השימוש בעומס העבודה, כמו OOMKilled כשמעריכים מספר גדול של כללים. כדי לצמצם את הסיכון הזה, אפשר לפרוס VerticalPodAutoscaler כדי להרחיב את הפריסה באופן אנכי. קודם צריך לוודא שVertical Pod Autoscaling מופעל באשכול Kubernetes. לאחר מכן מוסיפים משאב VerticalPodAutoscaler, כמו:

   apiVersion: autoscaling.k8s.io/v1
   kind: VerticalPodAutoscaler
   metadata:
     name: rule-evaluator
     namespace: gmp-system
   spec:
     resourcePolicy:
       containerPolicies:
       - containerName: evaluator
         controlledResources:
           - memory
         maxAllowed:
           memory: 4Gi
         minAllowed:
           memory: 16Mi
         mode: Auto
     targetRef:
       apiVersion: apps/v1
       kind: Deployment
       name: rule-evaluator
     updatePolicy:
       updateMode: Auto
   

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

   kubectl get vpa --namespace gmp-system rule-evaluator
   

   אם שינוי הגודל האוטומטי פועל, הוא ידווח שחישב את ההמלצות לגבי המשאבים עבור עומס העבודה בעמודה 'PROVIDED':

   NAME             MODE   CPU   MEM        PROVIDED   AGE
   rule-evaluator   Auto   2m    11534336   True       30m
   

   דחיסת ההגדרות

   אם יש לכם הרבה משאבי Rules, יכול להיות שייגמר לכם המקום ב-ConfigMap. כדי לפתור את הבעיה, מפעילים דחיסה של gzip במשאב OperatorConfig:

     apiVersion: monitoring.googleapis.com/v1
     kind: OperatorConfig
     metadata:
       namespace: gmp-public
       name: config
     features:
       config:
         compression: gzip
   

   הגדרת Alertmanager

   אתם יכולים להשתמש במשאב OperatorConfig כדי להגדיר את כלי הערכת הכללים המנוהל לשליחת התראות אל Alertmanager של Prometheus. אתם יכולים לשלוח התראות ל-Alertmanager המנוהל שנפרס באופן אוטומטי, בנוסף לכל Alertmanager שנפרס באופן עצמאי.

   Managed Alertmanager

   תצוגה מקדימה

   השימוש בתכונה הזו כפוף לתנאי השימוש במוצרים בגרסת טרום-GA, שמפורטים בחלק "תנאי שירות הכלליים" בתנאים הספציפיים של השירות. השימוש בתכונות בגרסת טרום-GA הוא "כפי שהן" (As is), ויכול להיות שהתמיכה בהן תהיה מוגבלת. מידע נוסף זמין בקטע תיאור שלבי ההשקה.

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

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

   1. יוצרים קובץ הגדרות מקומי שמכיל את ההגדרות של Alertmanager (אפשר להיעזר בתבניות הגדרות לדוגמה):

      touch alertmanager.yaml
      

   2. מעדכנים את הקובץ עם ההגדרות הרצויות של Alertmanager ויוצרים סוד בשם alertmanager במרחב השמות gmp-public:

      kubectl create secret generic alertmanager \
        -n gmp-public \
        --from-file=alertmanager.yaml
      

   אחרי כמה רגעים, שירות מנוהל ל-Prometheus מאתר את הסוד החדש של config ומפעיל את Alertmanager המנוהל עם ההגדרות שלכם.

   התאמה אישית של שם הסוד של ההגדרה

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

   כדי לציין שם Secret שאינו ברירת המחדל באמצעות משאב OperatorConfig:

   1. יוצרים Secret מקובץ התצורה המקומי של Alertmanager:

      kubectl create secret generic SECRET_NAME \
        -n gmp-public \
        --from-file=FILE_NAME
      

   2. פותחים את המשאב OperatorConfig לעריכה:

      kubectl -n gmp-public edit operatorconfig config
      

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

      apiVersion: monitoring.googleapis.com/v1
      kind: OperatorConfig
      metadata:
        namespace: gmp-public
        name: config
      managedAlertmanager:
        configSecret:
          name: SECRET_NAME
          key: FILE_NAME
      

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

   התאמה אישית של כתובת ה-URL החיצונית

   אתם יכולים להגדיר את כתובת ה-URL החיצונית של Alertmanager המנוהל כדי שהתראות יוכלו לספק קישור לקריאה חוזרת לממשק המשתמש של מערכת ההתראות. השימוש באפשרות הזו שווה לשימוש בדגל --web.external-url של Prometheus Alertmanager.

   apiVersion: monitoring.googleapis.com/v1
   kind: OperatorConfig
   metadata:
     namespace: gmp-public
     name: config
   managedAlertmanager:
     externalURL: EXTERNAL_URL
   

   פריסה עצמית של Alertmanager

   כדי להגדיר את כלי ההערכה של הכללים עבור Alertmanager שפרסתם בעצמכם, צריך לבצע את הפעולות הבאות:

   1. פותחים את המשאב OperatorConfig לעריכה:

      kubectl -n gmp-public edit operatorconfig config
      

   2. מגדירים את המשאב לשליחת התראות לשירות Alertmanager:

      apiVersion: monitoring.googleapis.com/v1
      kind: OperatorConfig
      metadata:
        namespace: gmp-public
        name: config
      rules:
        alerting:
          alertmanagers:
          - name: SERVICE_NAME
            namespace: SERVICE_NAMESPACE
            port: PORT_NAME
      

   אם Alertmanager נמצא באשכול אחר מזה של rule-evaluator, יכול להיות שתצטרכו להגדיר משאב של נקודות קצה. לדוגמה, אם בקובץ OperatorConfig מצוין שנקודות הקצה של Alertmanager נמצאות באובייקט Endpoints‏ ns=alertmanager/name=alertmanager, אתם יכולים ליצור את האובייקט הזה באופן ידני או באמצעות תוכנה, ולאכלס אותו בכתובות IP שאפשר להגיע אליהן מהאשכול השני. בקטע ההגדרות AlertmanagerEndpoints יש אפשרויות להגדרת הרשאות, אם צריך.

   חיסכון במשאבים כשאין פעילות

   אם לא מוגדרים משאבים מסוג Rules, ‏ ClusterRules או GlobalRules, ‏ GKE משנה את קנה המידה של הפריסות של כלי הערכת הכללים ושל Alertmanager לאפס, כדי לחסוך במשאבי האשכול ללקוחות שלא משתמשים בכללים או בהתראות מנוהלים. הפריסות האלה יגדלו באופן אוטומטי כשתחיל משאב Rules חדש. אפשר להגדיל את מספר המכונות בכוח על ידי החלת משאב Rules שלא עושה כלום.