‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

איך מתחילים לעבוד עם אוסף מנוהל

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

במאמר הזה מוסבר איך:

מגדירים את הסביבה ואת כלי שורת הפקודה.
מגדירים אוסף מנוהל לאשכול.
הגדרת משאב לגירוד נתונים מהיעד ולהוספת מדדים.
העברה של משאבים מותאמים אישית קיימים של prometheus-operator.

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

האיסוף המנוהל מפעיל אוספים מבוססי-Prometheus כ-Daemonset, ומבטיח יכולת הרחבה על ידי גירוד (scraping) רק של יעדים בצמתים שמוצבים יחד. מגדירים את האוספים באמצעות משאבים מותאמים אישית קלי משקל כדי לגרד נתונים ממייצאים באמצעות איסוף משיכה, ואז האוספים דוחפים את הנתונים שגורדו למאגר הנתונים המרכזי Monarch.‏ Google Cloud לעולם לא ניגש ישירות לאשכול שלכם כדי למשוך או לגרד נתוני מדדים. האוספים שלכם דוחפים נתונים אלGoogle Cloud. מידע נוסף על איסוף נתונים מנוהל ופריסה עצמית של איסוף נתונים זמין במאמרים איסוף נתונים באמצעות שירות מנוהל ל-Prometheus וקליטה ושאילתות באמצעות איסוף מנוהל ופריסה עצמית.

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

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

הגדרת פרויקטים וכלים

כדי להשתמש בשירות המנוהל של Google Cloud ל-Prometheus, אתם צריכים את המשאבים הבאים:

Google Cloud פרויקט שמופעל בו Cloud Monitoring API.
- אם אין לכם Google Cloud פרויקט, אתם צריכים לבצע את הפעולות הבאות:
  1. במסוף Google Cloud , עוברים אל New Project:
    
    יצירת פרויקט חדש
  2. בשדה Project Name (שם הפרויקט), מזינים שם לפרויקט ולוחצים על Create (יצירה).
  3. עוברים אל חיוב:
    
    לדף החיוב
  4. אם הפרויקט שיצרתם לא מסומן בחלק העליון של הדף, בוחרים אותו.
  5. תתבקשו לבחור פרופיל תשלומים קיים או ליצור פרופיל חדש.
  ממשק Monitoring API מופעל כברירת מחדל בפרויקטים חדשים.
- אם כבר יש לכם פרויקט ב- Google Cloud , צריך לוודא ש-Monitoring API מופעל:
  1. עוברים לדף Monitoring API library במסוףGoogle Cloud :
    
    לדף ספרייה
  2. בוחרים את הפרויקט הרצוי.
  3. אם מופיע לחצן ניהול בדף הספרייה, סימן שה-Monitoring API מופעל. אם מופיע לחצן הפעלה, סימן שה-API לא מופעל, ואתם צריכים ללחוץ על הלחצן הפעלה כדי להפעיל אותו.
אשכול Kubernetes. אם אין לכם אשכול Kubernetes, אתם צריכים לפעול לפי ההוראות שבמדריך להתחלה מהירה של GKE.

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

gcloud
kubectl

הכלים gcloud ו-kubectl הם חלק מ-Google Cloud CLI. מידע על התקנת הרכיבים האלה מופיע במאמר ניהול רכיבי Google Cloud CLI. כדי לראות את הרכיבים של ה-CLI של gcloud שהתקנתם, מריצים את הפקודה הבאה:

gcloud components list

הגדרת הסביבה

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

מגדירים את כלי שורת הפקודה באופן הבא:
- מגדירים את ה-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

הגדרת אוסף מנוהל

אפשר להשתמש באיסוף מנוהל גם באשכולות GKE וגם באשכולות Kubernetes שאינם GKE.

אחרי שמפעילים את האוסף המנוהל, הרכיבים בתוך האשכול יפעלו, אבל עדיין לא ייווצרו מדדים. הרכיבים האלה צריכים את המשאבים PodMonitoring או ClusterPodMonitoring כדי לבצע סקריפינג של נקודות הקצה של המדדים בצורה נכונה. צריך לפרוס את המשאבים האלה עם נקודות קצה תקינות של מדדים או להפעיל אחד מחבילות המדדים המנוהלות, למשל Kube state metrics, שמובנית ב-GKE. מידע על פתרון בעיות מופיע במאמר בנושא בעיות בצד הקליטה.

הפעלת אוסף מנוהל מתקינה את הרכיבים הבאים באשכול:

פריסת gmp-operator, שפורסת את אופרטור Kubernetes בשביל השירות המנוהל ל-Prometheus.
‫rule-evaluator Deployment, שמשמש להגדרה והרצה של כללי התראות והקלטה.
‫collector DaemonSet, שמבצע גידול אופקי של האיסוף על ידי גירוד מדדים רק מתרמילים שפועלים באותו צומת כמו כל אוסף.
‫alertmanager StatefulSet, שמוגדר לשליחת התראות מופעלות לערוצי ההתראות המועדפים.

למאמרי עזרה בנושא האופרטור של השירות המנוהל ל-Prometheus, אפשר לעיין בדף המניפסטים.

הפעלת איסוף מנוהל: GKE

האוסף המנוהל מופעל כברירת מחדל במקרים הבאים:

אשכולות GKE Autopilot שמריצים GKE מגרסה 1.25 ואילך.
אשכולות GKE Standard שפועלים בגרסה 1.27 של GKE ואילך. אפשר לשנות את ברירת המחדל הזו כשיוצרים את האשכול. מידע נוסף זמין במאמר השבתת איסוף מנוהל.

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

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

האוסף המנוהל ב-GKE משתמש בהרשאות שניתנו לחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine. אם יש לכם מדיניות שמשנה את ההרשאות הרגילות בחשבון השירות שמוגדר כברירת מחדל לצומת, יכול להיות שתצטרכו להוסיף את התפקיד Monitoring Metric Writer כדי להמשיך.

הפעלה ידנית של אוסף מנוהל

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

לוח הבקרה Managed Prometheus Bulk Cluster Enablement ב-Cloud Monitoring.
הדף Kubernetes Engine במסוף Google Cloud .
‫Google Cloud CLI. כדי להשתמש ב-CLI של gcloud, צריך להפעיל את GKE בגרסה 1.21.4-gke.300 ואילך.
‫Terraform for Google Kubernetes Engine. כדי להשתמש ב-Terraform כדי להפעיל את השירות המנוהל ל-Prometheus, צריך להריץ את GKE בגרסה 1.21.4-gke.300 ומעלה.

מרכז הבקרה להפעלה של אשכולות בכמות גדולה ב-Managed Prometheus

ב-Cloud Monitoring, בלוח הבקרה Managed Prometheus Bulk Cluster Enablement, אתם יכולים:

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

כדי לראות את מרכז הבקרה Managed Prometheus Bulk Cluster Enablement:

במסוף Google Cloud , עוברים לדף Dashboards:
מעבר אל מרכזי בקרה

אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שבה הכותרת המשנית היא Monitoring.
משתמשים בסרגל הסינון כדי לחפש את הערך Managed Prometheus Bulk Cluster Enablement ואז בוחרים בו.

לוח הבקרה Managed Prometheus Bulk Cluster Enablement ב-Cloud Monitoring.

כדי להפעיל איסוף מנוהל באשכול GKE אחד או יותר באמצעות מרכז הבקרה Managed Prometheus Bulk Cluster Enablement, מבצעים את הפעולות הבאות:

מסמנים את התיבה לצד כל אשכול GKE שרוצים להפעיל בו איסוף מנוהל.
לוחצים על הפעלת הנבחרים.

ממשק המשתמש של Kubernetes Engine

אפשר לבצע את הפעולות הבאות באמצעות מסוף Google Cloud :

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

כדי לעדכן אשכול קיים:

נכנסים לדף Kubernetes clusters במסוף Google Cloud .
כניסה אל Kubernetes clusters

אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שכותרת המשנה שלה היא Kubernetes Engine.
לוחצים על שם האשכול.
ברשימה Features, מאתרים את האפשרות Managed Service for Prometheus. אם הוא מופיע כהשבתה, לוחצים על עריכה ואז על הפעלה של שירות מנוהל ל-Prometheus.
לוחצים על שמירת השינויים.

כדי ליצור אשכול עם אוסף מנוהל מופעל:

נכנסים לדף Kubernetes clusters במסוף Google Cloud .
כניסה אל Kubernetes clusters

אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שכותרת המשנה שלה היא Kubernetes Engine.
לוחצים על יצירה.
לוחצים על הגדרה באפשרות רגיל.
בחלונית הניווט, לוחצים על תכונות.
בקטע Operations (פעולות), בוחרים באפשרות Enable Managed Service for Prometheus (הפעלת שירות מנוהל ל-Prometheus).
לוחצים על Save.

‫CLI של gcloud

אפשר לבצע את הפעולות הבאות באמצעות ה-CLI של gcloud:

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

יכול להיות שיחלפו עד 5 דקות עד שהפקודות האלה יושלמו.

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

gcloud config set project PROJECT_ID

כדי לעדכן אשכול קיים, מריצים אחת מהפקודות הבאות של update, בהתאם לסוג האשכול (אזורי או אזורי):

gcloud container clusters update CLUSTER_NAME --enable-managed-prometheus --zone ZONE

gcloud container clusters update CLUSTER_NAME --enable-managed-prometheus --region REGION

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

gcloud container clusters create CLUSTER_NAME --zone ZONE --enable-managed-prometheus

טייס אוטומטי של GKE

איסוף מנוהל מופעל כברירת מחדל באשכולות GKE Autopilot שפועלים בגרסה 1.25 של GKE ואילך. אי אפשר להשבית את האוסף המנוהל.

אם האשכול נכשל בהפעלת האוסף המנוהל באופן אוטומטי בעת השדרוג לגרסה 1.25, אפשר להפעיל אותו באופן ידני על ידי הרצת פקודת העדכון בקטע ה-CLI של gcloud.

Terraform

הוראות להגדרת איסוף מנוהל באמצעות Terraform זמינות במאגר Terraform ל-google_container_cluster.

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

השבתת אוסף מנוהל

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

ממשק המשתמש של Kubernetes Engine

אפשר לבצע את הפעולות הבאות באמצעות מסוף Google Cloud :

השבתה של איסוף מנוהל באשכול GKE קיים.
השבתה של ההפעלה האוטומטית של אוסף מנוהל כשיוצרים אשכול GKE Standard חדש עם GKE בגרסה 1.27 ומעלה.

כדי לעדכן אשכול קיים:

נכנסים לדף Kubernetes clusters במסוף Google Cloud .
כניסה אל Kubernetes clusters

אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שכותרת המשנה שלה היא Kubernetes Engine.
לוחצים על שם האשכול.
בקטע Features (תכונות), מאתרים את האפשרות Managed Service for Prometheus (שירות מנוהל ל-Prometheus). לוחצים על עריכה, ומבטלים את הסימון של הפעלת השירות המנוהל ל-Prometheus.
לוחצים על שמירת השינויים.

כדי לבטל את ההפעלה האוטומטית של אוסף מנוהל כשיוצרים אשכול GKE Standard חדש (גרסה 1.27 ומעלה), פועלים לפי השלבים הבאים:

נכנסים לדף Kubernetes clusters במסוף Google Cloud .
כניסה אל Kubernetes clusters

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

‫CLI של gcloud

אפשר לבצע את הפעולות הבאות באמצעות ה-CLI של gcloud:

השבתה של איסוף מנוהל באשכול GKE קיים.
השבתה של ההפעלה האוטומטית של אוסף מנוהל כשיוצרים אשכול GKE Standard חדש עם GKE בגרסה 1.27 ומעלה.

יכול להיות שיחלפו עד 5 דקות עד שהפקודות האלה יושלמו.

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

gcloud config set project PROJECT_ID

כדי להשבית את האיסוף המנוהל באשכול קיים, מריצים אחת מהפקודות הבאות update בהתאם לסוג האשכול (אזורי או אזורי):

gcloud container clusters update CLUSTER_NAME --disable-managed-prometheus --zone ZONE

gcloud container clusters update CLUSTER_NAME --disable-managed-prometheus --region REGION

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

--monitoring=SYSTEM (מומלץ)
--monitoring=NONE

כדי לבטל את ההפעלה האוטומטית של איסוף מנוהל כשיוצרים אשכול GKE Standard חדש (גרסה 1.27 ומעלה), מריצים את הפקודה הבאה:

gcloud container clusters create CLUSTER_NAME --zone ZONE --no-enable-managed-prometheus

טייס אוטומטי של GKE

אי אפשר להשבית את האוסף המנוהל באשכולות GKE Autopilot שפועלים ב-GKE בגרסה 1.25 ומעלה.

Terraform

כדי להשבית אוסף מנוהל, מגדירים את המאפיין enabled בבלוק ההגדרות managed_prometheus לערך false. מידע נוסף על בלוק ההגדרה הזה זמין במאגר Terraform ל-google_container_cluster.

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

הפעלה של איסוף מנוהל: Kubernetes שאינו GKE

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

‫kubectl CLI.
פריסות של VMware או של Bare Metal בארגון שמופעלות בגרסה 1.12 ואילך.

‫`kubectl` CLI

כדי להתקין אוספים מנוהלים כשמשתמשים באשכול Kubernetes שאינו GKE, מריצים את הפקודות הבאות כדי להתקין את מניפסטים של ההגדרה והאופרטור:

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.17.2/manifests/setup.yaml

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.17.2/manifests/operator.yaml

מקומי

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

פריסת האפליקציה לדוגמה

באפליקציה לדוגמה מופקים מדד הדלפק example_requests_total ומדד ההיסטוגרמה example_random_numbers (ועוד) ביציאה metrics. המניפסט של האפליקציה מגדיר שלוש רפליקות.

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

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

הגדרת משאב PodMonitoring

כדי להטמיע את נתוני המדדים שמופקים מאפליקציית הדוגמה, שירות Managed Service for Prometheus משתמש בגירוד של יעדים. הגדרת גירוד נתונים מהיעד והטמעת מדדים מתבצעת באמצעות משאבים מותאמים אישית של Kubernetes. השירות המנוהל משתמש במשאבים מותאמים אישית (CR) של PodMonitoring.

משאב PodMonitoring CR מבצע גירוד של יעדים רק במרחב השמות שבו הוא נפרס. כדי לבצע סקריפינג של יעדים בכמה מרחבי שמות, צריך לפרוס את אותו PodMonitoring CR בכל מרחב שמות. כדי לוודא שהמשאב PodMonitoring מותקן במרחב השמות הרצוי, מריצים את הפקודה kubectl get podmonitoring -A.

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

המניפסט הבא מגדיר משאב PodMonitoring‏, prom-example, במרחב השמות NAMESPACE_NAME. המשאב משתמש בבורר תוויות של Kubernetes כדי למצוא את כל הפודים במרחב השמות שיש להם את התווית app.kubernetes.io/name עם הערך prom-example. ה-pods התואמים נסרקים ביציאה בשם metrics, כל 30 שניות, בנתיב ה-HTTP ‏/metrics.

apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  name: prom-example
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: prom-example
  endpoints:
  - port: metrics
    interval: 30s

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

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

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

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

אם אתם מריצים את המערכת ב-GKE, אתם יכולים לבצע את הפעולות הבאות:

כדי לשלוח שאילתות על המדדים שנקלטים על ידי האפליקציה לדוגמה באמצעות PromQL ב-Cloud Monitoring, ראו שליחת שאילתות באמצעות Cloud Monitoring.
כדי לשלוח שאילתות על המדדים שנקלטים על ידי האפליקציה לדוגמה באמצעות Grafana, אפשר לעיין במאמר שליחת שאילתות באמצעות Grafana או כל צרכן של Prometheus API.
כדי לקבל מידע על סינון מדדים מיוצאים ועל התאמה של משאבי prom-operator, אפשר לעיין במאמר נושאים נוספים בנושא איסוף מנוהל.

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

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

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

מגדירים את ההקשר לפרויקט היעד:
```
gcloud config set project PROJECT_ID
```

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

gcloud iam service-accounts create gmp-test-sa

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

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 gmp-public create secret generic gmp-test-sa \
  --from-file=key.json=gmp-test-sa-key.json

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

kubectl -n gmp-public edit operatorconfig config

מוסיפים את הטקסט שמופיע באותיות מודגשות למשאב:
```
apiVersion: monitoring.googleapis.com/v1
kind: OperatorConfig
metadata:
  namespace: gmp-public
  name: config
collection:
  credentials:
    name: gmp-test-sa
    key: key.json
```
חשוב גם להוסיף את פרטי הכניסה האלה לקטע rules כדי שההערכה של כללים מנוהלים תפעל.
שומרים את הקובץ וסוגרים את הכלי לעריכה. אחרי שהשינוי מוחל, הפודים נוצרים מחדש ומתחילים לבצע אימות לשרת העורפי של המדדים באמצעות חשבון השירות שצוין.

נושאים נוספים לאוסף מנוהל

בקטע הזה מוסבר איך:

כדי להקל על ניפוי הבאגים, מומלץ להפעיל את התכונה 'סטטוס היעד'.
הגדרת גירוד נתונים מיעדים באמצעות Terraform.
מסננים את הנתונים שמייצאים לשירות המנוהל.
גירוד מדדים של Kubelet ו-cAdvisor.
המרת משאבי prom-operator קיימים לשימוש בשירות המנוהל.
הפעלת אוסף מנוהל מחוץ ל-GKE.

הפעלת התכונה 'סטטוס היעד'

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

כדי לבדוק את הסטטוס של היעדים במשאבי PodMonitoring או ClusterPodMonitoring, צריך להגדיר את הערך features.targetStatus.enabled במשאב OperatorConfig ל-true, כמו שמוצג בדוגמה הבאה:

apiVersion: monitoring.googleapis.com/v1
kind: OperatorConfig
metadata:
  namespace: gmp-public
  name: config
features:
  targetStatus:
    enabled: true

אחרי כמה שניות, השדה Status.Endpoint Statuses מופיע בכל משאב תקין של PodMonitoring או ClusterPodMonitoring, אם הוא מוגדר.

אם יש לכם משאב PodMonitoring בשם prom-example במרחב השמות NAMESPACE_NAME, תוכלו לבדוק את הסטטוס על ידי הרצת הפקודה הבאה:

kubectl -n NAMESPACE_NAME describe podmonitorings/prom-example

הפלט אמור להיראות כך:

API Version:  monitoring.googleapis.com/v1
Kind:         PodMonitoring
...
Status:
  Conditions:
    ...
    Status:                True
    Type:                  ConfigurationCreateSuccess
  Endpoint Statuses:
    Active Targets:       3
    Collectors Fraction:  1
    Last Update Time:     2023-08-02T12:24:26Z
    Name:                 PodMonitoring/custom/prom-example/metrics
    Sample Groups:
      Count:  3
      Sample Targets:
        Health:  up
        Labels:
          Cluster:                     CLUSTER_NAME
          Container:                   prom-example
          Instance:                    prom-example-589ddf7f7f-hcnpt:metrics
          Job:                         prom-example
          Location:                    REGION
          Namespace:                   NAMESPACE_NAME
          Pod:                         prom-example-589ddf7f7f-hcnpt
          project_id:                  PROJECT_ID
        Last Scrape Duration Seconds:  0.020206416
        Health:                        up
        Labels:
          ...
        Last Scrape Duration Seconds:  0.054189485
        Health:                        up
        Labels:
          ...
        Last Scrape Duration Seconds:  0.006224887

הפלט כולל את שדות הסטטוס הבאים:

הערך של Status.Conditions.Status הוא true כש-שירות מנוהל ל-Prometheus מאשר ומעבד את PodMonitoring או ClusterPodMonitoring.
‫Status.Endpoint Statuses.Active Targets מציג את מספר יעדי הגירוד ששירות מנוהל ל-Prometheus סופר בכל האוספים של משאב PodMonitoring הזה. באפליקציה לדוגמה, לפריסת prom-example יש שלוש רפליקות עם יעד מדד יחיד, ולכן הערך הוא 3. אם יש יעדים לא תקינים, השדה Status.Endpoint Statuses.Unhealthy Targets מופיע.
הערך שמוצג ב-Status.Endpoint Statuses.Collectors Fraction הוא 1 (כלומר 100%) אם אפשר להגיע לכל האוספים המנוהלים דרך השירות המנוהל ל-Prometheus.
Status.Endpoint Statuses.Last Update Time מציג את שעת העדכון האחרון. אם הזמן של העדכון האחרון ארוך משמעותית מהזמן הרצוי למרווח בין סריקות, יכול להיות שההבדל מצביע על בעיות ביעד או באשכול.
בשדה Status.Endpoint Statuses.Sample Groups מוצגים יעדים לדוגמה שמקובצים לפי תוויות יעד נפוצות שמוחדרות על ידי הכלי לאיסוף נתונים. הערך הזה שימושי לניפוי באגים במקרים שבהם היעדים לא מזוהים. אם כל יעדי האיסוף תקינים והנתונים נאספים מהם, הערך הצפוי בשדה Health הוא up, והערך בשדה Last Scrape Duration Seconds הוא משך הזמן הרגיל של יעד אופייני.

מידע נוסף על השדות האלה זמין במסמכי העזרה של שירות מנוהל ל-Prometheus API.

אחת מהבעיות הבאות עשויה להצביע על בעיה בהגדרות:

אין שדה Status.Endpoint Statuses במשאב PodMonitoring.
הערך בשדה Last Scrape Duration Seconds ישן מדי.
מוצגים לכם מעט מדי יעדים.
הערך בשדה Health מציין שהיעד הוא down.

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

הגדרת נקודת קצה מורשית לגירוד

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

השירות המנוהל של Google Cloud ל-Prometheus תומך בסוגי ההרשאות הבאים:

mTLS
BasicAuth
כותרת הרשאה של HTTP
OAuth 2

mTLS

בדרך כלל מגדירים mTLS בסביבות של אפס אמון, כמו Istio service mesh או Cloud Service Mesh.

כדי להפעיל נקודות קצה של גירוד נתונים שמאובטחות באמצעות mTLS, צריך להגדיר את השדה Spec.Endpoints[].Scheme במשאב PodMonitoring לערך https. אפשר להגדיר את השדה Spec.Endpoints[].tls.insecureSkipVerify במשאב PodMonitoring לערך true כדי לדלג על אימות רשות האישורים, אבל לא מומלץ לעשות את זה. אפשר גם להגדיר את השירות המנוהל ל-Prometheus לטעינת אישורים ומפתחות ממקורות סודיים.

לדוגמה, משאב הסוד הבא מכיל מפתחות ללקוח (cert), מפתח פרטי (key) ואישורים של רשות האישורים (ca):

kind: Secret
metadata:
  name: secret-example
stringData:
  cert: ********
  key: ********
  ca: ********

מעניקים למאסף של שירות מנוהל ל-Prometheus הרשאה לגשת למשאב Secret:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: secret-example-read
rules:
- resources:
  - secrets
  apiGroups: [""]
  verbs: ["get", "list", "watch"]
  resourceNames: ["secret-example"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: gmp-system:collector:secret-example-read
  namespace: default
roleRef:
  name: secret-example-read
  kind: Role
  apiGroup: rbac.authorization.k8s.io
subjects:
- name: collector
  namespace: gmp-system
  kind: ServiceAccount

באשכולות GKE Autopilot, זה נראה כך:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: secret-example-read
rules:
- resources:
  - secrets
  apiGroups: [""]
  verbs: ["get", "list", "watch"]
  resourceNames: ["secret-example"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: gmp-system:collector:secret-example-read
  namespace: default
roleRef:
  name: secret-example-read
  kind: Role
  apiGroup: rbac.authorization.k8s.io
subjects:
- name: collector
  namespace: gke-gmp-system
  kind: ServiceAccount

כדי להגדיר משאב PodMonitoring שמשתמש במשאב Secret הקודם, צריך לשנות את המשאב ולהוסיף לו את הקטע scheme ואת הקטע tls:

apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  name: prom-example
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: prom-example
  endpoints:
  - port: metrics
    interval: 30s
    scheme: https
    tls:
      ca:
        secret:
          name: secret-example
          key: ca
      cert:
        secret:
          name: secret-example
          key: cert
      key:
        secret:
          name: secret-example
          key: key

במאמרי העזרה בנושא API מופיע מידע על כל האפשרויות של mTLS בשירות המנוהל ל-Prometheus.

BasicAuth

כדי להפעיל גירוד של נקודות קצה שמאובטחות באמצעות BasicAuth, צריך להגדיר את השדה Spec.Endpoints[].BasicAuth במשאב PodMonitoring עם שם המשתמש והסיסמה. למידע על סוגים אחרים של כותרות הרשאה של HTTP, אפשר לעיין במאמר בנושא כותרת הרשאה של HTTP.

לדוגמה, משאב הסוד הבא מכיל מפתח לאחסון הסיסמה:

kind: Secret
metadata:
  name: secret-example
stringData:
  password: ********

מעניקים למאסף של שירות מנוהל ל-Prometheus הרשאה לגשת למשאב Secret:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: secret-example-read
rules:
- resources:
  - secrets
  apiGroups: [""]
  verbs: ["get", "list", "watch"]
  resourceNames: ["secret-example"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: gmp-system:collector:secret-example-read
  namespace: default
roleRef:
  name: secret-example-read
  kind: Role
  apiGroup: rbac.authorization.k8s.io
subjects:
- name: collector
  namespace: gmp-system
  kind: ServiceAccount

באשכולות GKE Autopilot, זה נראה כך:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: secret-example-read
rules:
- resources:
  - secrets
  apiGroups: [""]
  verbs: ["get", "list", "watch"]
  resourceNames: ["secret-example"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: gmp-system:collector:secret-example-read
  namespace: default
roleRef:
  name: secret-example-read
  kind: Role
  apiGroup: rbac.authorization.k8s.io
subjects:
- name: collector
  namespace: gke-gmp-system
  kind: ServiceAccount

כדי להגדיר משאב PodMonitoring שמשתמש במשאב Secret הקודם ובשם משתמש foo, משנים את המשאב כדי להוסיף קטע basicAuth:

apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  name: prom-example
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: prom-example
  endpoints:
  - port: metrics
    interval: 30s
    basicAuth:
      username: foo
      password:
        secret:
          name: secret-example
          key: password

במאמרי העזרה של ה-API מופיע מידע על כל האפשרויות של BasicAuth בשירות המנוהל ל-Prometheus.

כותרת הרשאה של HTTP

כדי להפעיל גירוד של נקודות קצה שמאובטחות באמצעות כותרות הרשאה של HTTP, צריך להגדיר את השדה Spec.Endpoints[].Authorization במשאב PodMonitoring עם הסוג ופרטי הכניסה. לנקודות קצה של BasicAuth, צריך להשתמש במקום זאת בהגדרות BasicAuth.

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

kind: Secret
metadata:
  name: secret-example
stringData:
  credentials: ********

מעניקים למאסף של שירות מנוהל ל-Prometheus הרשאה לגשת למשאב Secret:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: secret-example-read
rules:
- resources:
  - secrets
  apiGroups: [""]
  verbs: ["get", "list", "watch"]
  resourceNames: ["secret-example"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: gmp-system:collector:secret-example-read
  namespace: default
roleRef:
  name: secret-example-read
  kind: Role
  apiGroup: rbac.authorization.k8s.io
subjects:
- name: collector
  namespace: gmp-system
  kind: ServiceAccount

באשכולות GKE Autopilot, זה נראה כך:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: secret-example-read
rules:
- resources:
  - secrets
  apiGroups: [""]
  verbs: ["get", "list", "watch"]
  resourceNames: ["secret-example"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: gmp-system:collector:secret-example-read
  namespace: default
roleRef:
  name: secret-example-read
  kind: Role
  apiGroup: rbac.authorization.k8s.io
subjects:
- name: collector
  namespace: gke-gmp-system
  kind: ServiceAccount

כדי להגדיר משאב PodMonitoring שמשתמש במשאב Secret הקודם ובסוג Bearer, משנים את המשאב כדי להוסיף קטע authorization:

apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  name: prom-example
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: prom-example
  endpoints:
  - port: metrics
    interval: 30s
    authorization:
      type: Bearer
      credentials:
        secret:
          name: secret-example
          key: credentials

במאמרי העזרה של ה-API מופיע מידע על כל האפשרויות של כותרת ההרשאה של HTTP ב-Managed Service for Prometheus.

‫OAuth 2

כדי להפעיל גישה לנקודות קצה של גירוד נתונים שמוגנות באמצעות OAuth 2, צריך להגדיר את השדה Spec.Endpoints[].OAuth2 במשאב PodMonitoring.

לדוגמה, משאב הסוד הבא מכיל מפתח לאחסון הסוד של הלקוח:

kind: Secret
metadata:
  name: secret-example
stringData:
  clientSecret: ********

מעניקים למאסף של שירות מנוהל ל-Prometheus הרשאה לגשת למשאב Secret:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: secret-example-read
rules:
- resources:
  - secrets
  apiGroups: [""]
  verbs: ["get", "list", "watch"]
  resourceNames: ["secret-example"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: gmp-system:collector:secret-example-read
  namespace: default
roleRef:
  name: secret-example-read
  kind: Role
  apiGroup: rbac.authorization.k8s.io
subjects:
- name: collector
  namespace: gmp-system
  kind: ServiceAccount

באשכולות GKE Autopilot, זה נראה כך:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: secret-example-read
rules:
- resources:
  - secrets
  apiGroups: [""]
  verbs: ["get", "list", "watch"]
  resourceNames: ["secret-example"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: gmp-system:collector:secret-example-read
  namespace: default
roleRef:
  name: secret-example-read
  kind: Role
  apiGroup: rbac.authorization.k8s.io
subjects:
- name: collector
  namespace: gke-gmp-system
  kind: ServiceAccount

כדי להגדיר משאב PodMonitoring שמשתמש במשאב Secret הקודם עם מזהה לקוח foo וכתובת URL של אסימון example.com/token, משנים את המשאב כדי להוסיף קטע oauth2:

apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  name: prom-example
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: prom-example
  endpoints:
  - port: metrics
    interval: 30s
    oauth2:
      clientID: foo
      clientSecret:
        secret:
          name: secret-example
          key: password
      tokenURL: example.com/token

למאמרי עזרה על כל האפשרויות של OAuth 2 בשירות המנוהל ל-Prometheus, אפשר לעיין במאמרי העזרה של ה-API.

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

אתם יכולים להפוך את היצירה והניהול של משאבי PodMonitoring ו-ClusterPodMonitoring לאוטומטיים באמצעות kubernetes_manifest Terraform resource type או kubectl_manifest Terraform resource type. כל אחת מהאפשרויות האלה מאפשרת לכם לציין משאבים מותאמים אישית שרירותיים.

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

סינון מדדים מיוצאים

אם אתם אוספים הרבה נתונים, כדאי למנוע שליחה של חלק מהסדרות העיתיות אל שירות מנוהל ל-Prometheus כדי לצמצם את העלויות. כדי לעשות את זה, אפשר להשתמש בכללי תיוג מחדש של Prometheus עם פעולה מסוג keep לרשימת היתרים או פעולה מסוג drop לרשימת חסימה. במקרה של אוסף מנוהל, הכלל הזה מופיע בקטע metricRelabeling של המשאב PodMonitoring או ClusterPodMonitoring.

לדוגמה, כלל התיוג מחדש של המדדים הבא יסנן כל מדד שמתחיל ב-foo_bar_, ב-foo_baz_ או ב-foo_qux_:

  metricRelabeling:
  - action: drop
    regex: foo_(bar|baz|qux)_.+
    sourceLabels: [__name__]

בדף Metrics Management ב-Cloud Monitoring מופיע מידע שיכול לעזור לכם לשלוט בסכום שאתם מוציאים על מדדים שניתנים לחיוב, בלי לפגוע ביכולת הצפייה. בדף Metrics Management מופיע המידע הבא:

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

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

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

גירוד מדדים מ-Kubelet ומ-cAdvisor

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

המרת משאבים קיימים של prometheus-operator

בדרך כלל אפשר להמיר את המשאבים הקיימים של prometheus-operator למשאבים מנוהלים של PodMonitoring ו-ClusterPodMonitoring בשירות המנוהל ל-Prometheus.

לדוגמה, המשאב ServiceMonitor מגדיר מעקב אחרי קבוצה של שירותים. המשאב PodMonitoring מציג קבוצת משנה של השדות שמוצגים על ידי המשאב ServiceMonitor. אפשר להמיר ServiceMonitor CR ל-PodMonitoring CR על ידי מיפוי השדות כמו שמתואר בטבלה הבאה:

monitoring.coreos.com/v1 ServiceMonitor	תאימות	monitoring.googleapis.com/v1 PodMonitoring
`.ServiceMonitorSpec.Selector`	זהה	`.PodMonitoringSpec.Selector`
`.ServiceMonitorSpec.Endpoints[]`	‫`.TargetPort` maps to `.Port` `.Path`: compatible `.Interval`: compatible `.Timeout`: compatible	`.PodMonitoringSpec.Endpoints[]`
`.ServiceMonitorSpec.TargetLabels`	ב-PodMonitor צריך לציין: `.FromPod[].From` תווית של Pod `.FromPod[].To` תווית יעד	`.PodMonitoringSpec.TargetLabels`

זוהי דוגמה ל-ServiceMonitor CR. התוכן שמודגש מוחלף בהמרה, והתוכן שמוטה ממופה ישירות:

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: example-app
spec:
  selector:
    matchLabels:
      app: example-app
  endpoints:
  - targetPort: web
    path: /stats
    interval: 30s
  targetLabels:
  - foo

זוהי CR דומה של PodMonitoring, בהנחה שהשירות והפודים שלו מסומנים בתווית app=example-app. אם ההנחה הזו לא רלוונטית, צריך להשתמש בבוררי התוויות של משאב השירות הבסיסי.

התוכן המודגש הוחלף בהמרה:

apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  name: example-app
spec:
  selector:
    matchLabels:
      app: example-app
  endpoints:
  - port: web
    path: /stats
    interval: 30s
  targetLabels:
    fromPod:
    - from: foo # pod label from example-app Service pods.
      to: foo

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

תוויות שמורות

שירות מנוהל ל-Prometheus מוסיף באופן אוטומטי את התוויות הבאות לכל המדדים שנאספים. התוויות האלה משמשות לזיהוי ייחודי של משאב ב-Monarch:

‫project_id: המזהה של Google Cloud הפרויקט שמשויך למדד.
location: המיקום הפיזי (Google Cloud אזור) שבו הנתונים מאוחסנים. הערך הזה הוא בדרך כלל האזור של אשכול GKE. אם הנתונים נאספים מפריסה של AWS או מפריסה מקומית, יכול להיות שהערך יהיה Google Cloud האזור הקרוב ביותר.
‫cluster: השם של אשכול Kubernetes שמשויך למדד.
‫namespace: השם של מרחב השמות של Kubernetes שמשויך למדד.
‫job: תווית העבודה של יעד Prometheus, אם ידועה. יכול להיות שהתוצאה תהיה ריקה אם מדובר בתוצאות של הערכת כלל.
‫instance: תווית המופע של יעד Prometheus, אם ידועה; יכול להיות שיהיה ריק בתוצאות של הערכת כלל.

לא מומלץ להשתמש באפשרות הזו כשמריצים ב-Google Kubernetes Engine, אבל אפשר לשנות את התוויות project_id, location ו-cluster על ידי הוספתן כ-args למשאב הפריסה בתוך operator.yaml. אם משתמשים בתוויות שמורות כתוויות של מדדים, שירות מנוהל ל-Prometheus מתייג אותן מחדש באופן אוטומטי על ידי הוספת הקידומת exported_. ההתנהגות הזו זהה לזו של Prometheus במעלה הזרם כשמדובר בהתנגשויות עם תוויות שמורות.

דחיסת הגדרות

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

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

הפעלת התאמה אנכית של קבוצות Pod לעומס (VPA) לאיסוף מנוהל

אתם יכולים להשתמש בהתאמה אנכית של קבוצות Pod לעומס (VPA) כדי להקצות משאבים באופן דינמי לעומסי עבודה של שירות מנוהל ל-Prometheus. הקצאה דינמית יכולה לפתור את הבעיות הבאות:

שגיאות של חוסר זיכרון (OOM) בתרמילי collector,‏ rule-evaluator,‏ alertmanager או gmp-operator באשכול.
בקשות ולימיטים של משאבים שמוגדרים כברירת מחדל לעומסי העבודה האלה, שלא עונים על הצרכים שלכם.

כשמגדירים את השדה scaling.vpa.enabled: true במשאב OperatorConfig, האופרטור פורס מניפסטים של VerticalPodAutoscaler עבור הפודים collector,‏ rule-evaluator,‏ alertmanager ו-gmp-operator. קובצי המניפסט האלה נפרסים במרחב השמות gmp-system באשכולות רגילים ובמרחב השמות gke-gmp-system באשכולות של Autopilot, והם מאפשרים להגדיר באופן אוטומטי את הבקשות והמגבלות של המשאבים על סמך השימוש.

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

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

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

יכול להיות שתקבלו את השגיאה הזו כשאתם מנסים להפעיל את VPA:

vertical pod autoscaling is not available - install vpa support and restart the operator

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

נכנסים לדף Kubernetes Engine - Clusters במסוףGoogle Cloud .

נכנסים לדף Kubernetes clusters במסוף Google Cloud .
כניסה אל Kubernetes clusters

אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שכותרת המשנה שלה היא Kubernetes Engine.
בוחרים את האשכול שרוצים לשנות.
בקטע Automation, עורכים את הערך של האפשרות Vertical Pod Autoscaling.
מסמנים את התיבה Enable Vertical Pod Autoscaling ולוחצים על Save changes. השינוי הזה יגרום להפעלה מחדש של האשכול. האופרטור מופעל מחדש כחלק מהתהליך הזה.
מנסים שוב להריץ את הפקודה הבאה: kubectl -n gmp-public patch operatorconfig/config -p '{"scaling":{"vpa":{"enabled":true}}}' --type=merge כדי להפעיל את VPA בשירות מנוהל ל-Prometheus.

כדי לוודא שהמשאב OperatorConfig נערך בהצלחה, פותחים אותו באמצעות הפקודה kubectl -n gmp-public edit operatorconfig config. אם הפקודה מצליחה, הקטע הבא מופיע באותיות מודגשות ב-OperatorConfig:

apiVersion: monitoring.googleapis.com/v1
kind: OperatorConfig
metadata:
  namespace: gmp-public
  name: config
scaling:
  vpa:
    enabled: true

אם כבר הפעלתם את התכונה 'התאמה אנכית של קבוצות Pod לעומס' ברמת האשכול ואתם עדיין רואים את השגיאה vertical pod autoscaling is not available - install vpa support and restart the operator, יכול להיות שקובץ ה-Pod‏ gmp-operator צריך להעריך מחדש את הגדרת האשכול. מבצעים אחת מהפעולות הבאות:

אם מריצים אשכול Standard, מריצים את הפקודה הבאה כדי ליצור מחדש את ה-Pod:
```
kubectl -n gmp-system rollout restart deployment/gmp-operator
```
אחרי שמפעילים מחדש את gmp-operator pod, פועלים לפי השלבים שלמעלה כדי להחיל את התיקון על OperatorConfig שוב.
אם אתם מריצים אשכול Autopilot, אתם לא יכולים להפעיל מחדש את ה-pod‏ gmp-operator באופן ידני. כשמפעילים את VPA עבור האוספים המנוהלים באשכול Autopilot, ‏ VPA מפנה באופן אוטומטי את פודים האוספים ויוצר אותם מחדש כדי להחיל את בקשות המשאבים החדשות. לא נדרשת הפעלה מחדש של האשכול. אם השגיאה vertical pod autoscaling is not available מופיעה אחרי שמפעילים את VPA, או אם נתקלים בבעיות אחרות בהפעלת VPA בשירות המנוהל ל-Prometheus, צריך לפנות לתמיכה.

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

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

הגדרה של statsd_exporter ושל כלי ייצוא אחרים שמדווחים על מדדים באופן מרכזי

אם אתם משתמשים ב-statsd_exporter ל-Prometheus, ב-Envoy ל-Istio, ב-SNMP exporter, ב-Prometheus Pushgateway, ב-kube-state-metrics, או אם יש לכם exporter דומה אחר שמתווך ומדווח על מדדים בשם משאבים אחרים שפועלים בסביבה שלכם, אתם צריכים לבצע כמה שינויים קטנים כדי שה-exporter יעבוד עם שירות מנוהל ל-Prometheus.

הוראות להגדרת כלי הייצוא האלה מופיעות בהערה הזו בקטע 'פתרון בעיות'.

פירוק

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

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

gcloud container clusters update CLUSTER_NAME --disable-managed-prometheus

שימוש בממשק המשתמש של GKE:
1. בוחרים באפשרות Kubernetes Engine במסוף Google Cloud , ואז בוחרים באפשרות Clusters.
2. מאתרים את האשכול שרוצים להשבית בו את האוסף המנוהל ולוחצים על השם שלו.
3. בכרטיסייה פרטים, גוללים למטה אל מאפיינים ומשנים את המצב למושבת באמצעות לחצן העריכה.

כדי להשבית את איסוף הנתונים המנוהל שנפרס באמצעות Terraform, מציינים enabled = false בקטע managed_prometheus של משאב google_container_cluster.

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

kubectl delete -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.17.2/manifests/operator.yaml

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

השבתה של איסוף מנוהל תגרום גם למחיקה של מרחב השמות gmp-public וכל המשאבים שבו, כולל כלים לייצוא שהותקנו במרחב השמות הזה.

הרצת איסוף מנוהל מחוץ ל-GKE

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

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

אתם יכולים לספק מפתח של חשבון שירות על ידי שינוי המשאב OperatorConfig ב-operator.yaml, כפי שמתואר במאמר הזנת פרטי כניסה באופן מפורש. אפשר לספק ערכים של project-id, location ו-cluster על ידי הוספתם כ-args למשאב Deployment בתוך operator.yaml.

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

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

במקרה של cluster, מומלץ לבחור את שם האשכול שבו האופרטור נפרס.

אם ההגדרה בוצעה בצורה נכונה, הקובץ OperatorConfig אמור להיראות כך:

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

ומשאב הפריסה אמור להיראות כך:

apiVersion: apps/v1
kind: Deployment
...
spec:
  ...
  template:
    ...
    spec:
      ...
      containers:
      - name: operator
        ...
        args:
        - ...
        - "--project-id=PROJECT_ID"
        - "--cluster=CLUSTER_NAME"
        - "--location=REGION"

בדוגמה הזו, משתנה REGION מוגדר לערך כמו us-central1, למשל.

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

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

מידע נוסף על משאבים מותאמים אישית של אוסף מנוהל

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

המאמרים הבאים

שימוש ב-PromQL ב-Cloud Monitoring כדי לשלוח שאילתות על מדדי Prometheus.
שימוש ב-Grafana כדי לשלוח שאילתות על מדדי Prometheus
שימוש בהתראות PromQL ב-Cloud Monitoring.
מגדירים הערכה של כללים מנוהלים.
הגדרת כלי ייצוא נפוצים.

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

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

הגדרת פרויקטים וכלים

הגדרת הסביבה

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

הגדרת אוסף מנוהל

הפעלת איסוף מנוהל: GKE

הפעלה ידנית של אוסף מנוהל

מרכז הבקרה להפעלה של אשכולות בכמות גדולה ב-Managed Prometheus

ממשק המשתמש של Kubernetes Engine

‫CLI של gcloud

טייס אוטומטי של GKE

Terraform

השבתת אוסף מנוהל

ממשק המשתמש של Kubernetes Engine

‫CLI של gcloud

טייס אוטומטי של GKE

Terraform

הפעלה של איסוף מנוהל: Kubernetes שאינו GKE

‫kubectl CLI

מקומי

פריסת האפליקציה לדוגמה

הגדרת משאב PodMonitoring

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

נושאים נוספים לאוסף מנוהל

הפעלת התכונה 'סטטוס היעד'

הגדרת נקודת קצה מורשית לגירוד

mTLS

BasicAuth

כותרת הרשאה של HTTP

‫OAuth 2

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

סינון מדדים מיוצאים

גירוד מדדים מ-Kubelet ומ-cAdvisor

המרת משאבים קיימים של prometheus-operator

תוויות שמורות

דחיסת הגדרות

הפעלת התאמה אנכית של קבוצות Pod לעומס (VPA) לאיסוף מנוהל

הגדרה של statsd_exporter ושל כלי ייצוא אחרים שמדווחים על מדדים באופן מרכזי

פירוק

הרצת איסוף מנוהל מחוץ ל-GKE

מידע נוסף על משאבים מותאמים אישית של אוסף מנוהל

המאמרים הבאים

איך מתחילים לעבוד עם אוסף מנוהל

‫`kubectl` CLI