Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

במאמר הזה מוסבר איך להגדיר את השירות המנוהל של 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. בשדה שם הפרויקט, מזינים שם לפרויקט ולוחצים על יצירה.
  3. עוברים אל חיוב:
    
    לדף החיוב
  4. אם הפרויקט שיצרתם לא מסומן בחלק העליון של הדף, בוחרים אותו.
  5. תתבקשו לבחור פרופיל תשלומים קיים או ליצור פרופיל תשלומים חדש.
  ממשק Monitoring API מופעל כברירת מחדל בפרויקטים חדשים.
- אם כבר יש לכם פרויקט ב- Google Cloud , צריך לוודא ש-Monitoring API מופעל:
  1. עוברים אל APIs & services:
    
    עוברים אל APIs & services
  2. בוחרים את הפרויקט הרצוי.
  3. לוחצים על Enable APIs and Services.
  4. מחפשים את האפשרות 'מעקב'.
  5. בתוצאות החיפוש, לוחצים על Cloud Monitoring API.
  6. אם לא מוצגת ההודעה 'API enabled' (ה-API מופעל), לוחצים על הלחצן Enable (הפעלה).
אשכול 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, שמבצע הרחבה אופקית של האיסוף על ידי גירוד מדדים רק מ-pods שפועלים באותו צומת כמו כל אוסף.
‫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

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

בודקים אם השירות המנוהל ל-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.
לוחצים על יצירה.
לוחצים על הגדרה באפשרות רגיל.
בחלונית הניווט, לוחצים על תכונות.
בקטע Operations (פעולות), מבטלים את הסימון של Enable Managed Service for Prometheus (הפעלת שירות מנוהל ל-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 או של שרת פיזי בארגון שמופעלות בגרסה 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

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

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

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

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

כדאי להפעיל את התכונה 'סטטוס היעד' כדי להקל על ניפוי הבאגים.
הגדרת גירוד נתונים מיעדים באמצעות 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 ב-שירות מנוהל ל-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) לאוסף מנוהל

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

כשמגדירים את השדה scaling.vpa.enabled: true במשאב OperatorConfig, האופרטור פורס מניפסט VerticalPodAutoscaler באשכול שמאפשר להגדיר אוטומטית את הבקשות והמגבלות של המשאבים של פודים של אוספים, על סמך השימוש.

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

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

אם הפקודה מסתיימת בלי שגיאות, האופרטור מגדיר קנה מידה אוטומטי של פודים אנכיים לפודים של האוסף. שגיאות של חוסר זיכרון מובילות להגדלה מיידית של מגבלות המשאבים. אם אין שגיאות 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.
מסמנים את התיבה התאמה אנכית של קבוצות Pod לעומס ולוחצים על שמירת השינויים. השינוי הזה יפעיל מחדש את האשכול. הפעולה הזו גורמת להפעלה מחדש של האופרטור.
מנסים שוב להריץ את הפקודה הבאה: 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, אתם לא יכולים להפעיל מחדש את פוד gmp-operator באופן ידני. כשמפעילים את VPA עבור האוספים המנוהלים באשכול Autopilot, ‏ VPA מפנה באופן אוטומטי את פודים האוספים ויוצר אותם מחדש כדי להחיל את בקשות המשאבים החדשות. לא נדרשת הפעלה מחדש של האשכול. אם השגיאה vertical pod autoscaling is not available מופיעה אחרי הפעלת VPA, או אם נתקלתם בבעיות אחרות בהפעלת VPA בשירות מנוהל ל-Prometheus, אתם יכולים לפנות לתמיכה.

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

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

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

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

הגדרת הסביבה

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

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

הפעלת איסוף מנוהל: 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