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

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

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

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

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

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

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

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

אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שכותרת המשנה שלה היא Kubernetes Engine.
לוחצים על שם האשכול.
ברשימה Features, מאתרים את האפשרות שירות מנוהל ל-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 Autopilot

האפשרות 'אוסף מנוהל' מופעלת כברירת מחדל באשכולות 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 Autopilot

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

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

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

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

אין שדה 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 הרשאה לגשת למשאב הסודי הזה:

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 הרשאה לגשת למשאב הסודי הזה:

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 הרשאה לגשת למשאב הסודי הזה:

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 הרשאה לגשת למשאב הסודי הזה:

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

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

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

Terraform

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

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

‫CLI של gcloud

GKE Autopilot

Terraform

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

kubectl CLI

מקומי

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

הגדרת משאב PodMonitoring

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

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

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

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

mTLS

BasicAuth

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

OAuth 2

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

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

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

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

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

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

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

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

פירוק

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

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

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

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

`kubectl` CLI