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

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

הערכת הכלל

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

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

כללים

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

    הערכת כללים בהתאמה לעומס (scaling)

    הפריסה rule-evaluator פועלת כעותק יחיד עם בקשות ומגבלות קבועות של משאבים. יכול להיות שתבחינו בשיבושים בעומס העבודה, למשל, שהתהליך יופסק בגלל חריגה ממגבלת הזיכרון (OOMKilled) כשמוערך מספר גדול של כללים. כדי לצמצם את הבעיה הזו, אפשר להשתמש ב-VerticalPodAutoscaler כדי להרחיב את הפריסה באופן אנכי.

    כדי להגדיר שינוי אוטומטי של גודל ה-Pod האנכי באשכול:

    1. מוודאים שהתאמה אנכית של קבוצות Pod לעומס מופעלת באשכול Kubernetes.

    2. כדי להגדיר שינוי אוטומטי של גודל ה-Pod בצורה אנכית, משתמשים באחת מהשיטות הבאות:

      • אשכולות במצב Autopilot ואשכולות רגילים: הפעלה של שינוי גודל אוטומטי של Pods אנכיים לעומסי עבודה של שירות מנוהל ל-Prometheus במשאב OperatorConfig. ב-Autopilot clusters, הפריסה rule-evaluator פועלת במרחב השמות המנוהל gke-gmp-system, שבו יצירה ישירה של משאבים מוגבלת, ולכן צריך להגדיר את VPA דרך המשאב OperatorConfig:

        kubectl -n gmp-public patch operatorconfig/config -p '{"scaling":{"vpa":{"enabled":true}}}' --type=merge

        מידע נוסף מופיע במאמר בנושא הפעלה של שינוי אוטומטי של גודל ה-Pod (VPA) עבור אוסף מנוהל.

      • מדיניות VPA מותאמת אישית באשכולות רגילים: באשכולות רגילים, אם רוצים להחיל מדיניות VerticalPodAutoscaler מותאמת אישית רק על rule-evaluator בלי להפעיל VPA לכל הרכיבים של שירות מנוהל ל-Prometheus, צריך להחיל משאב VerticalPodAutoscaler במרחב השמות gmp-system:

        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

    כדי לוודא שהשינוי האוטומטי של גודל הקבוצה פועל, בודקים את הסטטוס של המשאב VerticalPodAutoscaler. באשכולות סטנדרטיים, בודקים את מרחב השמות gmp-system. באשכולות במצב Autopilot, בודקים את מרחב השמות gke-gmp-system:

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

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

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

    דחיסת הגדרות

    אם יש לכם הרבה משאבי כללים, יכול להיות שלא יישאר לכם מקום ב-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

    שירות מנוהל ל-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 שלא עושה כלום.