ביצוע שאילתה באמצעות Prometheus API או ממשק משתמש

אחרי שפורסים את השירות המנוהל של Google Cloud ל-Prometheus, אפשר להריץ שאילתות על הנתונים שנשלחים לשירות המנוהל ולהציג את התוצאות בתרשימים ובלוחות בקרה.

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

  • The Prometheus HTTP API
  • ממשק המשתמש של Prometheus

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

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

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

הגדרת הסביבה

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

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

    • מגדירים את ה-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

    מידע נוסף על הכלים האלה:

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

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

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

kubectl create ns NAMESPACE_NAME

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

שאילתות והיקפי מדדים

הנתונים שאפשר להריץ עליהם שאילתות נקבעים לפי המבנה של Cloud Monitoring שנקרא היקף המדדים, בלי קשר לשיטה שבה משתמשים כדי להריץ את השאילתות על הנתונים. לדוגמה, אם אתם משתמשים ב-Grafana כדי לשלוח שאילתות לנתונים של Managed Service for Prometheus, כל היקף מדדים צריך להיות מוגדר כמקור נתונים נפרד.

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

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

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

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

נתונים של שירות מנוהל ל-Prometheus ב-Cloud Monitoring

הדרך הפשוטה ביותר לוודא שהנתונים שלכם ב-Prometheus מיוצאים היא להשתמש בדף Metrics Explorer ב-Cloud Monitoring במסוף Google Cloud , שתומך ב-PromQL. הוראות מפורטות זמינות במאמר בנושא שליחת שאילתות באמצעות PromQL ב-Cloud Monitoring.

ממשק משתמש עצמאי של Prometheus

אתם יכולים להשתמש בממשק המשתמש של Prometheus frontend העצמאי כדי לגשת לנתונים שהועברו ולהציג אותם באופן חזותי. ממשק המשתמש הזה מריץ שאילתות PromQL על כל הנתונים בGoogle Cloud פרויקט, כפי שנקבע על ידי היקף המדדים בפרויקט שמשויך לפרויקט.

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

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

פריסת ממשק המשתמש של הקצה הקדמי

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

  1. פורסים את שירות frontend ומגדירים אותו כך שיבצע שאילתה בפרויקט ההיקף של היקף המדדים שבחרתם:

    curl https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/e2cd07628f5bf3be5dc794ce8f4d4b9a206447ec/examples/frontend.yaml |
sed 's/\$PROJECT_ID/PROJECT_ID/' |
kubectl apply -n NAMESPACE_NAME -f -

  2. מגדירים העברת פורטים (port-forwarding) לשירות frontend במחשב המקומי. בדוגמה הבאה, השירות מועבר ליציאה 9090:

    kubectl -n NAMESPACE_NAME port-forward svc/frontend 9090

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

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

אפשר לגשת לממשק המשתמש של Prometheus קצה קדמי Standalone בדפדפן בכתובת ה-URL‏ http://localhost:9090. אם אתם משתמשים ב-Cloud Shell בשלב הזה, אתם יכולים לגשת באמצעות הלחצן תצוגה מקדימה באינטרנט.

בצילום המסך הבא מוצגת טבלה בממשק המשתמש של חזית Prometheus העצמאית, שבה מוצג המדד up:

צפייה במדד בממשק של Prometheus.

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

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

הפריסה frontend משתמשת בפרויקט Google Cloud שהוגדר כפרויקט ההיקף. אם הפרויקט הזה הוא פרויקט ההיקף של היקף מדדים של כמה פרויקטים, הוא יכול לקרוא מדדים מכל הפרויקטים בהיקף המדדים.

אפשר לציין פרויקט עם היקף מדדים של כמה פרויקטים באמצעות הדגל --query.project-id.

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

  • מציינים בפרויקט הפריסה frontend מהו פרויקט היעד.

  • נותנים לחשבון השירות הרשאת קריאה של פרויקט היעד. אם השתמשתם בחשבון השירות של Compute Engine default, אתם יכולים לבצע אחת מהפעולות הבאות:

כדי לתת את ההרשאות שנדרשות לגישה לפרויקט אחר Google Cloud , צריך לבצע את הפעולות הבאות:

  1. נותנים לחשבון השירות הרשאה לקרוא מהפרויקט שרוצים לשלוח אליו שאילתה:

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

  2. פותחים את הפריסה frontend שנוצרה קודם כדי לערוך אותה:

    kubectl -n NAMESPACE_NAME edit deploy frontend

  3. מציינים את פרויקט היעד באמצעות הדגל --query.project-id:

    apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: NAMESPACE_NAME
  name: frontend
spec:
  template
    containers:
    - name: frontend
      args:
      - --query.project-id=SCOPING_PROJECT_ID
...

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

אימות ממשק המשתמש של הקצה הקדמי

בפריסה של frontend יש תמיכה באימות גישה בסיסי לגישה מאומתת בגרסאות 0.5.0 ומעלה. כדי להפעיל אימות, מוסיפים את משתני הסביבה AUTH_USERNAME ו-AUTH_PASSWORD לפריסה: 

apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: NAMESPACE_NAME
  name: frontend
spec:
  template
    containers:
    - name: frontend
      env:
      - name: AUTH_USERNAME
        value: USERNAME
      - name: AUTH_PASSWORD
        value: PASSWORD
...

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

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

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

  1. מגדירים את ההקשר לפרויקט היעד:

    gcloud config set project PROJECT_ID

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

    gcloud iam service-accounts create gmp-test-sa

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

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

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

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

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

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

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

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

    kubectl -n NAMESPACE_NAME edit deploy frontend

    1. מוסיפים את הטקסט שמופיע בהדגשה למשאב:

      apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: NAMESPACE_NAME
  name: frontend
spec:
  template
    containers:
    - name: frontend
      args:
      - --query.credentials-file=/gmp/key.json
...
      volumeMounts:
      - name: gmp-sa
        mountPath: /gmp
        readOnly: true
...
    volumes:
    - name: gmp-sa
      secret:
        secretName: gmp-test-sa
...

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

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

    שימוש ב-Grafana דרך שרת ה-Proxy של חזית האתר

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

    אימות ל- Google Cloud APIs

    כל ממשקי ה-API מחייבים אימות באמצעות OAuth2, אבל Grafana לא תומכת באימות OAuth2 לחשבונות שירות שמשמשים עם מקורות נתונים של Prometheus.Google Cloud כדי להשתמש ב-Grafana עם השירות המנוהל ל-Prometheus, אפשר להשתמש בממשק המשתמש של Prometheus בחזית העורפית העצמאית כשרת proxy לאימות.

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

    אם עדיין לא פרסתם את שירות Prometheus UI frontend בתור proxy, אתם צריכים לפרוס אותו עכשיו באמצעות הפקודה הבאה:

    curl https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.17.2/examples/frontend.yaml |
sed 's/\$PROJECT_ID/PROJECT_ID/' |
kubectl apply -n NAMESPACE_NAME -f -

    במקרה של אשכולות Kubernetes שאינם GKE, כמו אשכולות Anthos, כדאי לעיין גם במאמר בנושא מתן הרשאות באופן מפורש כדי להעניק לשירות frontend את ההרשאות הנדרשות לשליפת מדדים.

    הוראות להגדרת היקף המדדים שמשמש את שירות frontend לשליחת שאילתות בכמה פרויקטים מפורטות במאמר בנושא שינוי הפרויקט שנשלחת אליו השאילתה.

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

    פריסת Grafana

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

    כדי ליצור פריסת Grafana זמנית, צריך להחיל את מניפסט grafana.yaml שירות מנוהל ל-Prometheus על האשכול, ולהעביר את שירות grafana ליציאה אחרת אל המחשב המקומי. בדוגמה הבאה, השירות מועבר ליציאה 3000.

    1. החלת המניפסט grafana.yaml:

      kubectl -n NAMESPACE_NAME apply -f  https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/beb779d32f4dd531a3faad9f2916617b8d9baefd/examples/grafana.yaml

    2. מגדירים העברת פורטים (port-forwarding) לשירות grafana במחשב המקומי. בדוגמה הזו, השירות מועבר ליציאה 3000:

      kubectl -n NAMESPACE_NAME port-forward svc/grafana 3000

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

      אפשר לגשת ל-Grafana בדפדפן בכתובת האתר http://localhost:3000 עם שם המשתמש:סיסמה admin:admin.

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

    כדי לשלוח שאילתות ל-שירות מנוהל ל-Prometheus ב-Grafana באמצעות ממשק המשתמש של Prometheus כשרת proxy לאימות, צריך להוסיף מקור נתונים חדש ל-Grafana. כדי להוסיף מקור נתונים לשירות המנוהל:

    1. נכנסים לפריסת Grafana, למשל על ידי גלישה לכתובת ה-URL http://localhost:3000 כדי להגיע לדף הפתיחה של Grafana.

    2. בתפריט הראשי של Grafana, בוחרים באפשרות Configuration (הגדרה) ואז באפשרות Data Sources (מקורות נתונים).

      הוספה של מקור נתונים ב-Grafana.

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

      הוספת מקור נתונים של Prometheus.

    4. בשדה כתובת URL בחלונית HTTP, מזינים את כתובת ה-URL של שירות frontend שירות מנוהל ל-Prometheus. אם הגדרתם את ממשק המשתמש של Prometheus frontend לפעול ביציאה 9090, כתובת ה-URL של השירות בשדה הזה היא http://frontend.NAMESPACE_NAME.svc:9090.

      בשדה Timeout בחלונית HTTP, מגדירים את הערך 120.

      אם הגדרתם את ה-proxy של ממשק המשתמש של קצה קדמי עם אימות בסיסי, הפעילו את המתג Basic auth בחלונית Auth ומלאו את שם המשתמש והסיסמה.

      בשדה Query timeout (זמן קצוב לתפוגה של שאילתה), מגדירים את הערך 2m.

      בשדה HTTP Method (שיטת HTTP), בוחרים באפשרות GET.

      בשדה Prometheus type, בוחרים באפשרות Prometheus.

      בשדה Prometheus version (גרסת Prometheus), בוחרים באפשרות 2.40.x או בגרסה מתקדמת יותר.

      אם יש לכם כמה מקורות נתונים של Prometheus, אתם יכולים לתת למקור הזה שם כמו Managed Prometheus Service. אפשר להשאיר את ערכי ברירת המחדל בשאר השדות.

      הגדרה של מקור נתונים של שירות מנוהל ל-Prometheus.

    5. לוחצים על שמירה ובדיקה ומחפשים את ההודעה 'מקור הנתונים פועל'.

      בדיקת מקור הנתונים של השירות המנוהל ל-Prometheus.

    שימוש במקור הנתונים החדש

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

    תרשים Grafana של מדד הזמינות של השירות המנוהל ל-Prometheus.

    קישור של שירות מנוהל ל-Prometheus אל Thanos

    אפשר לאחד את שירות מנוהל ל-Prometheus עם מחסנית Thanos שפרסתם בעצמכם באמצעות thanos-promql-connector בקוד פתוח. Google Cloudלא מספקת תמיכה בשילוב הזה.

    Prometheus HTTP API

    השירות המנוהל ל-Prometheus תומך ב-Prometheus HTTP API במעלה הזרם בכתובת ה-URL עם הקידומת https://monitoring.googleapis.com/v1/projects/PROJECT_ID/location/global/prometheus/api/v1/. מידע על נקודות הקצה הנתמכות מופיע במאמר בנושא תאימות ל-API.

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

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

    curl https://monitoring.googleapis.com/v1/projects/PROJECT_ID/location/global/prometheus/api/v1/query \
  -d "query=up" \
  -H "Authorization: Bearer $(gcloud auth print-access-token)"

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

    {
  "status":"success",
  "data":{
    "resultType":"vector",
    "result":[{
      "metric": {
        "__name__":"up",
        "cluster":"gmp-test",
        "instance":"prom-example-84c6f547f5-g4ljn:web",
        "job":"prometheus",
        "location":"us-central1-a",
        "project_id":"a-gcp-project"
      },
      "value": [1634873239.971,"1"]
    }]
  }
}

    מידע על שליחת שאילתות על מדדי מערכת שלGoogle Cloud באמצעות PromQL זמין במאמר PromQL למדדי Cloud Monitoring.

    תאימות ל-API

    השירות המנוהל ל-Prometheus תומך בנקודות הקצה הבאות של Prometheus HTTP API בכתובת ה-URL עם הקידומת https://monitoring.googleapis.com/v1/projects/PROJECT_ID/location/global/prometheus/api/v1/.

    למידע נוסף, אפשר לעיין במאמרי העזרה של Cloud Monitoring API. נקודות הקצה של Prometheus HTTP לא זמינות בספריות הלקוח הספציפיות לשפה של Cloud Monitoring.

    מידע על תאימות ל-PromQL זמין במאמר תמיכה ב-PromQL.

    • יש תמיכה מלאה בנקודות הקצה הבאות:

    • נקודת הקצה /api/v1/label/<label_name>/values פועלת רק אם התווית __name__ מסופקת באמצעות שימוש בה כערך <label_name> או באמצעות התאמה מדויקת שלה באמצעות בורר סדרות. לדוגמה, יש תמיכה מלאה בקריאות הבאות:

      • /api/v1/label/__name__/values
      • /api/v1/label/__name__/values?match[]={__name__=~".*metricname.*"}
      • /api/v1/label/labelname/values?match[]={__name__="metricname"}

      המגבלה הזו גורמת לכך שlabel_values($label)שאילתות משתנות ב-Grafana נכשלות. במקום זאת, אפשר להשתמש ב-label_values($metric, $label). מומלץ להשתמש בסוג השאילתה הזה כי הוא מונע אחזור של ערכי תוויות במדדים שלא רלוונטיים ללוח הבקרה הנתון.

    • נקודת הקצה /api/v1/series נתמכת בבקשות GET אבל לא בבקשות POST. כשמשתמשים בכלי לסנכרון מקורות נתונים או בשרת proxy של קצה קדמי, המגבלה הזו מנוהלת בשבילכם. אפשר גם להגדיר את מקורות הנתונים של Prometheus ב-Grafana כך שינפיקו רק בקשות GET. הפרמטר match[] לא תומך בהתאמה לביטוי רגולרי בתווית __name__.