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

שאילתה והצגה של מדדים

אחרי איסוף המדדים מעומסי העבודה שפרסתם במכשיר Google Distributed Cloud ‏ (GDC) עם בידוד פיזי, תוכלו להתחיל לנתח אותם. כדי לנתח מדדים, אפשר להציג אותם בתרשימים ולסנן אותם במרכזי בקרה של Grafana שמספקים מידע, או לגשת אליהם ישירות מ-Cortex באמצעות הכלי curl ליצירת סקריפטים גמישים ולאוטומציה.

יש שתי דרכים לגשת למדדים:

מרכזי בקרה של Grafana: אפשר לבחון מגמות ולזהות אנומליות באמצעות תצוגות חזותיות אינטואיטיביות של מדדים מרכזיים כמו ניצול CPU, צריכת אחסון ופעילות ברשת. ‫Grafana מספקת ממשק ידידותי למשתמש לסינון ולניתוח של נתוני עומס העבודה בלוחות בקרה.
נקודת קצה של Cortex: בתרחישי שימוש מתקדמים יותר, אפשר להריץ שאילתות ישירות במופע Cortex של הפרויקט באמצעות הכלי curl בשורת פקודה. מערכת Cortex מאחסנת את מדדי Prometheus של הפרויקט ומספקת נקודת קצה (endpoint) של HTTP לגישה פרוגרמטית. הגישה הזו מאפשרת לכם לייצא נתונים, לבצע משימות אוטומטיות וליצור שילובים בהתאמה אישית.

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

כדי לקבל את ההרשאות שדרושות לשאילתות ולתצוגה חזותית של מדדים בלוחות בקרה של Grafana, צריך לבקש מאדמין IAM ברמת הארגון או מאדמין IAM ברמת הפרויקט להקצות לכם את אחד מהתפקידים המוגדרים מראש: צפייה ב-Grafana ברמת הארגון או צפייה ב-Grafana ברמת הפרויקט. בהתאם לרמת הגישה וההרשאות שאתם צריכים, יכול להיות שתקבלו תפקידים ב-Grafana בארגון או בפרויקט.

לחלופין, כדי לקבל את ההרשאות שנדרשות לשליחת שאילתות למדדים מנקודת הקצה של Cortex, צריך לבקש מאדמין ה-IAM של הפרויקט להקצות לכם את התפקיד Project Cortex Prometheus Viewer במרחב השמות של הפרויקט.

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

בטבלה הבאה מפורטות הדרישות של Role ל-PA and AO persona.

פרסונה	אובייקט	אשכול	תפקיד	מרחב שמות	קבוצה/משתמש	הגדרה
PA	grafana	org-admin	`project-grafana-viewer`	platform-obs	קבוצה	1
PA	cortex	org-admin	`project-cortex-prometheus-viewer`	platform-obs	קבוצה	2
PA	grafana	org-admin	`project-grafana-viewer`	platform-obs	משתמש	3
PA	cortex	org-admin	`project-cortex-prometheus-viewer`	platform-obs	משתמש	4
AO	grafana	org-admin	`project-grafana-viewer`	PROJECT_NAMESPACE	קבוצה	1
AO	cortex	org-admin	`project-cortex-prometheus-viewer`	PROJECT_NAMESPACE	קבוצה	2
AO	grafana	org-admin	`project-grafana-viewer`	PROJECT_NAMESPACE	משתמש	3
AO	cortex	org-admin	`project-cortex-prometheus-viewer`	PROJECT_NAMESPACE	משתמש	4

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

משתנה	תיאור
`KUBECONFIG`	תצטרכו את קובץ ה-kubeconfig של האשכול הספציפי שמכיל את `NAMESPACE` שבו יוחל RoleBinding.
`RULE_NAME`	השם הייחודי של משאב `RoleBinding` במרחב השמות. לדוגמה, `io-root-cortex-prometheus-viewer`.
`NAMESPACE`	מרחב השמות של Kubernetes שבו ייווצר ויחול `RoleBinding`. מחפשים את העמודה `Namespace` בטבלה הקודמת.
`EMAIL_ADDRESS`	המזהה של המשתמש שמקבל את התפקיד. לרוב מדובר בכתובת אימייל. לדוגמה, `platform-administrator@example.com`.
`ROLE`	השם של `Role` שמכיל את ההרשאות שרוצים להעניק למשתמש. חיפוש התפקידים שזמינים בטבלה הקודמת
`GROUP_NAME`	השם של `Group` שהמשתמש עם הרשאת PA/AO שייך אליו. לדוגמה, `pa-group`.
`ZONE`	שם האזור

הגדרה 1

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

פקודת Kubectl

זהו פורמט הפקודה הכללי:

kubectl --kubeconfig `KUBECONFIG` create rolebinding `RULE_NAME` -n `NAMESPACE` --group=`GROUP_NAME` --role=project-grafana-viewer

לדוגמה:

kubectl --kubeconfig <path-to-kubeconfig> create rolebinding project-grafana-viewers-binding --role=project-grafana-viewer --group=my-team --namespace=platform-obs

קובץ YAML

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: RULE_NAME
  namespace: NAMESPACE
subjects:
- kind: Group
  name: GROUP_NAME
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: project-grafana-viewer
  apiGroup: rbac.authorization.k8s.io

הגדרה 2

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

פקודת Kubectl

זהו פורמט הפקודה הכללי:

kubectl --kubeconfig `KUBECONFIG` create rolebinding `RULE_NAME` -n `NAMESPACE` --group=`GROUP_NAME` --role=project-cortex-prometheus-viewer

לדוגמה:

kubectl --kubeconfig <path-to-kubeconfig> create rolebinding project-cortex-prometheus-viewer-binding --role=project-cortex-prometheus-viewer --group=my-team --namespace=platform-obs

קובץ YAML

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: RULE_NAME
  namespace: NAMESPACE
subjects:
- kind: Group
  name: GROUP_NAME
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: project-cortex-prometheus-viewer
  apiGroup: rbac.authorization.k8s.io

הגדרה 3

ההגדרה הזו מעניקה למשתמש הרשאות גישה ל-PA/AO Grafana באשכול org. אחרי שמגדירים את ההגדרה הזו, אפשר לעיין בקטע לוחות בקרה של Grafana במסמך הזה כדי לראות את המדדים ב-Grafana.

פקודת Kubectl

זהו פורמט הפקודה הכללי:

kubectl --kubeconfig `KUBECONFIG` create rolebinding `RULE_NAME` -n `NAMESPACE` --user=`EMAIL_ADDRESS` --role=project-grafana-viewer

לדוגמה:

kubectl --kubeconfig <path-to-kubeconfig> create rolebinding project-grafana-viewers-binding --role=project-grafana-viewer --user=my-email@example.com --namespace=platform-obs

קובץ YAML

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: RULE_NAME
  namespace: NAMESPACE
subjects:
- kind: User
  name: EMAIL_ADDRESS
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: project-grafana-viewer
  apiGroup: rbac.authorization.k8s.io

הגדרה 4

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

פקודת Kubectl

זהו פורמט הפקודה הכללי:

kubectl --kubeconfig `KUBECONFIG` create rolebinding `RULE_NAME` -n `NAMESPACE` --user=`EMAIL_ADDRESS` --role=project-cortex-prometheus-viewer

לדוגמה:

kubectl --kubeconfig <path-to-kubeconfig> create rolebinding project-cortex-prometheus-viewer-binding --role=project-cortex-prometheus-viewer --user=my-email@example.com --namespace=platform-obs

קובץ YAML

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: RULE_NAME
  namespace: NAMESPACE
subjects:
- kind: User
  name: EMAIL_ADDRESS
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: project-cortex-prometheus-viewer
  apiGroup: rbac.authorization.k8s.io

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

קבלת המדדים וסינון שלהם

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

לוחות בקרה של Grafana

בקטע הזה מוסבר איך לגשת למדדים באמצעות לוחות בקרה של Grafana.

זיהוי נקודת הקצה של Grafana

כתובת ה-URL הבאה היא נקודת הקצה של מופע Grafana בפרויקט שלכם:

  https://GDC_URL/PROJECT_NAMESPACE/grafana

מחליפים את מה שכתוב בשדות הבאים:

‫GDC_URL: כתובת ה-URL של הארגון ב-GDC.
‫PROJECT_NAMESPACE: מרחב השמות של הפרויקט.

לדוגמה, נקודת הקצה של Grafana לפרויקט platform-obs בארגון org-1 היא https://org-1/platform-obs/grafana.

הצגת מדדים בממשק המשתמש של Grafana

אחזור מדדים בממשק המשתמש של Grafana:

במסוף GDC, בוחרים את הפרויקט.
בתפריט הניווט, בוחרים באפשרות Operations > Monitoring.
לוחצים על הצגת הכול ב-Grafana.

ייפתח דף חדש עם נקודת הקצה של Grafana ויוצג ממשק המשתמש.
בממשק המשתמש,לוחצים על ניתוח ניתוח בתפריט הניווט כדי לפתוח את הדף ניתוח.
בתפריט בסרגל ניתוח, בוחרים מקור נתונים כדי לאחזר מדדים, בהתאם לסוג היקום:
- יקומים עם אזור אחד: בוחרים באפשרות prometheus כדי להציג מדדים מהאזור היחיד של היקום.
מזינים שאילתה כדי לחפש מדדים באמצעות ביטויים של PromQL (שפת שאילתות של Prometheus). אפשר לבצע את השלב הזה באחת מהדרכים הבאות:
- בוחרים מדד ותווית לשאילתה מהתפריטים מדד ומסנני תוויות. לוחצים על הוספה הוספה כדי להוסיף עוד תוויות לשאילתה. אחר כך לוחצים על Run query.
- מזינים את השאילתה ישירות בשדה הטקסט מדדים ומקישים על Shift+Enter כדי להריץ את השאילתה.
בדף מוצגים המדדים שתואמים לשאילתה.

איור 1. אפשרות בתפריט לשאילתת מדדים מממשק המשתמש של Grafana.

באיור 1, האפשרות prometheus מציגה את הממשק שמאפשר ליצור שאילתות מ-Grafana כדי לאחזר מדדים.

דוגמאות לערכים של תוויות שאפשר להשתמש בהן כדי לשלוח שאילתות למדדים מופיעות במאמר דוגמאות לשאילתות ולתוויות.

נקודת קצה של Cortex

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

זיהוי נקודת הקצה של Cortex

כתובת ה-URL הבאה היא נקודת הקצה של מופע Cortex בפרויקט שלכם:

  https://GDC_URL/PROJECT_NAMESPACE/cortex/prometheus/

מחליפים את מה שכתוב בשדות הבאים:

‫GDC_URL: כתובת ה-URL של הארגון ב-GDC.
‫PROJECT_NAMESPACE: מרחב השמות של הפרויקט.

לדוגמה, נקודת הקצה של Cortex בפרויקט platform-obs בארגון org-1 היא https://org-1/platform-obs/cortex/prometheus/.

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

אימות הבקשה `curl`

מורידים ומתקינים את gdcloud CLI.
מגדירים את מאפיין core/organization_console_url של gcloud:
```
gdcloud config set core/organization_console_url
https://GDC_URL
```
כניסה באמצעות ספק הזהויות שהוגדר:
```
gdcloud auth login
```
משתמשים בשם המשתמש ובסיסמה כדי לבצע אימות ולהיכנס לחשבון.

אם ההתחברות הצליחה, אפשר להשתמש בכותרת ההרשאה בבקשת cURL באמצעות הפקודה gdcloud auth print-identity-token. מידע נוסף זמין במאמר בנושא gdcloud auth.

התקשרות לנקודת הקצה של Cortex

כדי להגיע לנקודת הקצה של Cortex באמצעות הכלי curl:

אימות הבקשה curl.
משתמשים ב-curl כדי לשלוח קריאה ל-Cortex endpoint ולהרחיב את כתובת ה-URL באמצעות Prometheus HTTP API רגיל (https://prometheus.io/docs/prometheus/latest/querying/api/) כדי לשלוח שאילתות למדדים.

דוגמה לבקשת curl:
```
curl https://GDC_URL/PROJECT_NAME/cortex/prometheus/api/v1/query?query=my_metric{cluster="my-cluster"}&time=2015-07-01T20:10:51.781Z \
-H "Authorization: Bearer $(gdcloud auth print-identity-token \
--audiences=https://GDC_URL)"
```
הפלט מתקבל אחרי הפקודה. התגובה מה-API היא בפורמט JSON.

הערה: מוסיפים את נקודת הקצה api/v1/query כדי לשלוח שאילתות למדדים מכתובת ה-URL. אפשר לכלול פרמטרים אופציונליים לקריאה ל-API אחרי סימן שאלה (?) בסוף כתובת ה-URL. מפרידים בין הפרמטרים האלה באמצעות סמלי אמפרסנד (&), כמו בדוגמה של בקשת curl מהשלב הקודם.

דוגמאות לשאילתות ולתוויות

אפשר לשלוח שאילתות לגבי מדדים באמצעות שם המדד וזוגות של מפתח וערך לתוויות. שאילתת PromQL כוללת את התחביר הבא:

metric_name{label_one="value", label_two="value"}

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

לדוגמה, אפשר להשתמש במדד api_http_requests_total כדי לספור את מספר בקשות ה-HTTP שהתקבלו. אחר כך, תוכלו להוסיף תווית request_method למדד הזה, עם הערך POST, GET או PUT. לכן, צריך ליצור שלושה זרמי מדדים לכל סוג בקשה שאפשר לקבל. במקרה הזה, כדי למצוא את מספר הבקשות של HTTP GET, מריצים את השאילתה הבאה:

api_http_requests_total{request_method="GET"}

מידע נוסף על מדדים ותוויות זמין בכתובת https://prometheus.io/docs/practices/naming/.

אלה כמה מהתוויות שמוגדרות כברירת מחדל שנוספות על ידי MonitoringTarget custom resource. אפשר להשתמש בתוויות ברירת המחדל האלה כדי לשלוח שאילתות לגבי מדדים:

‫_gdch_service: השם המקוצר של השירות.
‫cluster: שם האשכול.
‫container_name: השם של הקונטיינר בתוך ה-Pod.
‫namespace_name: מרחב השמות של הפרויקט.
‫pod_name: הקידומת של שם ה-Pod.

בטבלה הבאה מתוארות התוויות ש-Prometheus מוסיף באופן אוטומטי:

תוויות ברירת מחדל
תווית מדד	תיאור
`job`	השם הפנימי של משימת הגירוד ששימשה לאיסוף המדד. למשימות שנוצרו על ידי המשאב המותאם אישית `MonitoringTarget` יש שם עם התבנית הבאה: `obs-system/OBS_SHADOW_PROJECT_NAME/MONITORINGTARGET_NAME.MONITORINGTARGET_NAMESPACE/I/J` `I` ו-`J` הם מספרים ייחודיים שנקבעים באופן פנימי כדי למנוע קונפליקטים בשמות.
`instance`	השם `$IP:$PORT` של השירות שהוצא משימוש. אם למשאב של עומס עבודה יש כמה עותקים, משתמשים בשדה הזה כדי להבדיל ביניהם.

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

כדי לראות את כל זרמי המדדים של הפעולות שעברו עיבוד בפרויקט:
```
processed_ops_total
```
כדי לראות את הפעולות המעובדות שנאספו באשכול Kubernetes:
```
processed_ops_total{cluster="CLUSTER_NAME"}
```
כדי לראות את השימוש במעבד שנאסף באשכול Kubernetes:
```
cpu_usage{cluster="CLUSTER_NAME"}
```

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

שאילתת מדדים מ-Cortex API

‫Cortex הוא האחסון לטווח ארוך של מדדי Prometheus ב-GDC. פלטפורמת ה-Observability חושפת נקודת קצה ל-API של Cortex HTTP לשליחת שאילתות ולקריאת מדדים, התראות ונתונים אחרים של סדרות זמן של Prometheus מהפרויקט שלכם.

אפשר לשלוח שאילתות למדדים ישירות מ-HTTP API כדי לקרוא ולייצא מדדים ונתונים אחרים של סדרות זמן לכלים חיצוניים, להגדיר משימות אוטומטיות, להתאים תשובות ולבנות שילובים בהתאם לתרחיש השימוש שלכם במעקב אחרי המערכת. לדוגמה, אפשר להוסיף את הפלט לפקודה אחרת, לייצא פרטים לפורמטים של קובצי טקסט או להגדיר משימת cron ב-Linux. אפשר לקרוא ל-API מממשק שורת הפקודה (CLI) או מדפדפן אינטרנט ולהשתמש בביטויים של שפת שאילתות כפרמטרים של נקודת קצה כדי לקבל את התוצאה בפורמט JSON.

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

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

צריך לקבל הרשאה כדי לשלוח שאילתות למדדים מ-CLI. כדי לקבל את ההרשאות שנדרשות לגישה לנקודת קצה ל-API של Cortex, צריך לבקש מאדמין ה-IAM של הפרויקט להקצות לכם את התפקיד Project Cortex Prometheus Viewer (project-cortex-prometheus-viewer).

יוצרים את ה-role bindings הבאים באמצעות הפקודות kubectl ל-Cortex prometheus לכל פרסונה:

אדמין ראשי של מפעיל תשתית (IO) – Project Cortex Prometheus Viewer:

kubectl --kubeconfig $HOME/root-admin-kubeconfig create rolebinding 
io-cortex-prometheus-viewer-binding -n infra-obs 
--user=fop-infrastructure-operator@example.com 
--role=project-cortex-prometheus-viewer

אדמין פלטפורמה (PA) אדמין ראשי – Project Cortex Prometheus Viewer:

kubectl --kubeconfig $HOME/root-admin-kubeconfig create rolebinding 
pa-cortex-prometheus-viewer-binding -n platform-obs 
--user=fop-platform-admin@example.com --role=project-cortex-prometheus-viewer

אדמין על אפליקציה (AO) – אדמין ראשי – Project Cortex Prometheus Viewer :
```
kubectl --kubeconfig $HOME/root-admin-kubeconfig create rolebinding 
project-cortex-prometheus-viewer-binding -n PROJECT_NAME 
--user=USER_NAME --role=project-cortex-prometheus-viewer
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫PROJECT_NAME: שם הפרויקט.
- ‫USER_NAME: שם החשבון של המשתמש שנדרש לו קישור התפקיד.

אחרי שיוצרים את הקישור לתפקיד, אפשר לגשת ל-Prometheus API באמצעות שם המשתמש להתחברות.

נקודת קצה ל-API של HTTP

כתובת ה-URL הבאה היא נקודת קצה ל-API של HTTP לגישה למדדים בפרויקט platform-obs:

https://GDC_URL/PROJECT_NAME/cortex/prometheus/

מחליפים את מה שכתוב בשדות הבאים:

‫GDC_URL: כתובת ה-URL של הארגון ב-GDC.
‫PROJECT_NAME: שם הפרויקט.

שליחת קריאה לנקודת קצה ל-API

בצע את השלבים הבאים כדי להגיע לנקודת קצה ל-API של Cortex מ-CLI ולשלוח שאילתה על מדדים:

חשוב לוודא שאתם עומדים בדרישות המוקדמות.
פותחים את ה-CLI.
משתמשים בכלי curl כדי לשלוח קריאה לנקודת הקצה של Cortex ולהרחיב את כתובת ה-URL באמצעות התקן https://prometheus.io/docs/prometheus/latest/querying/api/ כדי לשלוח שאילתות למדדים. לדוגמה:
```
curl https://console.org-1.zone1.google.gdch.test/alice/cortex/prometheus/api/v1/query?query=my_metric{cluster="org-1-system"}&time=2015-07-01T20:10:51.781Z
```

הפלט מתקבל ב-CLI אחרי הפקודה. פורמט התגובה של ה-API הוא JSON.

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

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

הגדרה 1

הגדרה 2

הגדרה 3

הגדרה 4

קבלת המדדים וסינון שלהם

לוחות בקרה של Grafana

זיהוי נקודת הקצה של Grafana

הצגת מדדים בממשק המשתמש של Grafana

נקודת קצה של Cortex

זיהוי נקודת הקצה של Cortex

אימות הבקשה curl

התקשרות לנקודת הקצה של Cortex

דוגמאות לשאילתות ולתוויות

שאילתת מדדים מ-Cortex API

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

נקודת קצה ל-API של HTTP

שליחת קריאה לנקודת קצה ל-API

שאילתה והצגה של מדדים

אימות הבקשה `curl`