הערכה והתראות של כללים שמוטמעים באופן עצמאי

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

צריך לפעול לפי ההוראות האלה רק אם רוצים להפעיל כללים והתראות מול מאגר הנתונים הגלובלי.

הערכת כללים לאיסוף ביקורות שהוטמע באופן עצמאי

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

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

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

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

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

הגדרת הסביבה

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

מגדירים את כלי שורת הפקודה באופן הבא:
- מגדירים את ה-CLI של gcloud כך שיפנה למזהה של פרויקטGoogle Cloud :
```
gcloud config set project PROJECT_ID
```
- אם אתם מריצים את הפקודה ב-GKE, צריך להשתמש ב-CLI של gcloud כדי להגדיר את האשכול:
```
gcloud container clusters get-credentials CLUSTER_NAME --location LOCATION --project PROJECT_ID
```
- אחרת, משתמשים ב-CLI של kubectl כדי להגדיר את האשכול:
```
kubectl config set-cluster CLUSTER_NAME
```
מידע נוסף על הכלים האלה:
- סקירה כללית על ה-CLI של gcloud
- פקודות של kubectl

הגדרת מרחב שמות

יוצרים את מרחב השמות NAMESPACE_NAME Kubernetes בשביל המשאבים שיוצרים כחלק מאפליקציית הדוגמה. מומלץ להשתמש בשם מרחב השמות gmp-test כשמשתמשים במסמכי התיעוד האלה כדי להגדיר דוגמה של הגדרת Prometheus.

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

kubectl create ns NAMESPACE_NAME

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

אם באשכול Kubernetes שלכם מופעל איחוד זהויות של עומסי עבודה ל-GKE, אתם יכולים לדלג על הקטע הזה.

כשמריצים את שירות מנוהל ל-Prometheus ב-GKE, המערכת מאחזרת באופן אוטומטי פרטי כניסה מהסביבה על סמך חשבון השירות שמוגדר כברירת מחדל של Compute Engine. לחשבון השירות שמוגדר כברירת מחדל יש את ההרשאות הנדרשות. אם אינכם משתמשים באיחוד זהויות של עומסי עבודה ל-GKE, ואם בעבר הסרתם את הענקת התפקיד monitoring.metricWriter ו-monitoring.viewer מחשבון השירות שמוגדר כברירת מחדל של הצומת, תצטרכו להוסיף מחדש את התפקידים החסרים האלה לפני שתמשיכו.

הגדרת חשבון שירות לשימוש באיחוד זהויות של עומסי עבודה ב-GKE

אם איחוד זהויות של עומסי עבודה ל-GKE לא מופעל באשכול Kubernetes, אפשר לדלג על הקטע הזה.

השירות המנוהל ל-Prometheus אוסף נתוני מדדים באמצעות Cloud Monitoring API. אם באשכול שלכם נעשה שימוש באיחוד זהויות של עומסי עבודה ל-GKE, אתם צריכים לתת לחשבון השירות של Kubernetes הרשאה ל-Monitoring API. בקטע הזה מתוארים הנושאים הבאים:

יצירה של Google Cloud חשבון שירות ייעודי, gmp-test-sa.
קישור חשבון השירות Google Cloud אל חשבון השירות שמוגדר כברירת מחדל ב-Kubernetes במרחב שמות לבדיקה, NAMESPACE_NAME.
מעניקים את ההרשאה הנדרשת לחשבון השירות Google Cloud .

יצירה של חשבון השירות וקישור שלו

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

קודם יוצרים חשבון שירות, אם עדיין לא עשיתם זאת:

gcloud config set project PROJECT_ID \
&&
gcloud iam service-accounts create gmp-test-sa

אחר כך משתמשים ברצף הפקודות הבא כדי לקשר את חשבון השירות gmp-test-saלחשבון השירות שמוגדר כברירת מחדל ב-Kubernetes במרחב השמות NAMESPACE_NAME:

gcloud config set project PROJECT_ID \
&&
gcloud iam service-accounts add-iam-policy-binding \
  --role roles/iam.workloadIdentityUser \
  --condition=None \
  --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE_NAME/default]" \
  gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \
&&
kubectl annotate serviceaccount \
  --namespace NAMESPACE_NAME \
  default \
  iam.gke.io/gcp-service-account=gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com

אם אתם משתמשים במרחב שמות או בחשבון שירות אחרים של GKE, צריך לשנות את הפקודות בהתאם.

אישור חשבון השירות

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

הפקודה הבאה מעניקה לחשבון השירות Google Cloud את התפקידים ב-Monitoring API שנדרשים לו כדי לקרוא ולכתוב נתוני מדדים.gmp-test-sa

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

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

ניפוי באגים בהגדרת איחוד הזהויות של עומסי עבודה ל-GKE

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

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

איחוד זהויות של עומסי עבודה ל-GKE בסביבות ייצור

בדוגמה שמתוארת במסמך הזה, חשבון השירות Google Cloud משויך לחשבון השירות שמוגדר כברירת מחדל ב-Kubernetes, ומקבל את כל ההרשאות הנדרשות לשימוש ב-Monitoring API. Google Cloud

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

פריסת כלי נפרד להערכת כללים

השירות המנוהל ל-Prometheus מעריך את כללי ההתראות והתיעוד של Prometheus באמצעות HTTP API של השירות המנוהל ל-Prometheus, וכותב את התוצאות בחזרה ל-Monarch. הוא מקבל את אותו פורמט של קובץ תצורה ושל קובץ כללים כמו Prometheus. גם הדגלים זהים ברובם.

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

kubectl apply -n NAMESPACE_NAME -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.17.2/manifests/rule-evaluator.yaml

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

kubectl -n NAMESPACE_NAME get pod

אם הפריסה בוצעה בהצלחה, הפלט אמור להיראות כך:

NAME                              READY   STATUS    RESTARTS   AGE
...
rule-evaluator-64475b696c-95z29   2/2     Running   0          1m

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

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

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

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

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

מגדירים את ההקשר לפרויקט היעד:
```
gcloud config set project PROJECT_ID
```
יוצרים חשבון שירות:
```
gcloud iam service-accounts create gmp-test-sa
```
בשלב הזה נוצר חשבון השירות שאולי כבר יצרתם בהוראות בנושא איחוד זהויות של עומסי עבודה ל-GKE.

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

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

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

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

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

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

פותחים את משאב הפריסה של כלי להערכת כללים לעריכה:
```
kubectl -n NAMESPACE_NAME edit deploy rule-evaluator
```
1. מוסיפים את הטקסט שמופיע בהדגשה למשאב:
```
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: NAMESPACE_NAME
  name: rule-evaluator
spec:
  template
    containers:
    - name: evaluator
      args:
      - --query.credentials-file=/gmp/key.json
      - --export.credentials-file=/gmp/key.json
...
      volumeMounts:
      - name: gmp-sa
        mountPath: /gmp
        readOnly: true
...
    volumes:
    - name: gmp-sa
      secret:
        secretName: gmp-test-sa
...
```
2. שומרים את הקובץ וסוגרים את הכלי לעריכה. אחרי שהשינוי יוחל, יחידות ה-Pod ייווצרו מחדש ויתחילו לבצע אימות לשרת העורפי של המדדים באמצעות חשבון השירות שצוין.
לחלופין, במקום להשתמש בדגלים שמוגדרים בדוגמה הזו, אפשר להגדיר את הנתיב של קובץ המפתח באמצעות משתנה הסביבה GOOGLE_APPLICATION_CREDENTIALS.
הערכת כללים בכמה פרויקטים וברמה הגלובלית

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

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

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

שמירה על תוויות כשכותבים כללים

לגבי נתונים שהמעריך כותב בחזרה לשירות המנוהל ל-Prometheus, המעריך תומך באותם דגלים של --export.* ובהגדרות מבוססות external_labels כמו בקובץ הבינארי של השרת של השירות המנוהל ל-Prometheus. מומלץ מאוד לכתוב כללים כך שהתוויות project_id,‏ location,‏ cluster ו-namespace יישמרו בצורה מתאימה לרמת הצבירה שלהן. אחרת, יכול להיות שביצועי השאילתה ירדו ותיתקלו במגבלות על עוצמת הקבוצה.

חובה להוסיף את התוויות project_id או location. אם התוויות האלה חסרות, הערכים בתוצאות של הערכת הכללים מוגדרים על סמך ההגדרה של כלי הערכת הכללים. אם חסרות תוויות cluster או namespace, לא ניתן להן ערכים.

ניראות (observability) עצמית

הכלי להערכת כללים פולט מדדי Prometheus ביציאה שאפשר להגדיר באמצעות הדגל --web.listen-address.

לדוגמה, אם הפוד rule-evaluator-64475b696c-95z29 חושף את המדדים האלה ביציאה 9092, אפשר לראות את המדדים באופן ידני באמצעות kubectl:
```
# Port forward the metrics endpoint.
kubectl port-forward rule-evaluator-64475b696c-95z29 9092
# Then query in a separate terminal.
curl localhost:9092/metrics
```
אתם יכולים להגדיר את חבילת Prometheus כדי לאסוף את הנתונים האלה, וכך לקבל תובנות לגבי הביצועים של כלי הערכת הכללים.

פריסות עם זמינות גבוהה

אפשר להריץ את כלי ההערכה של הכללים בהגדרה של זמינות גבוהה, באמצעות אותה גישה שמתועדת עבור שרת Prometheus.

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

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