אחרי שפורסים את השירות המנוהל של Google Cloud ל-Prometheus, אפשר לשלוח שאילתות לגבי הנתונים שנשלחים לשירות המנוהל ולהציג את התוצאות בתרשימים ובלוחות בקרה.
במסמך הזה מוסבר על היקפי מדדים, שקובעים את הנתונים שאפשר לשלוח לגביהם שאילתות, ואיך להשתמש ב-Grafana כדי לאחזר את הנתונים שאספתם ולהשתמש בהם.
כל ממשקי השאילתות של השירות המנוהל ל-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. בקטע הזה מתוארים הנושאים הבאים:
- יצירה של Google Cloud חשבון שירות ייעודי,
gmp-test-sa. - קישור חשבון השירות Google Cloud אל חשבון השירות שמוגדר כברירת מחדל ב-Kubernetes במרחב שמות לבדיקה,
NAMESPACE_NAME. - מעניקים את ההרשאה הנדרשת לחשבון השירות Google Cloud .
יצירה של חשבון השירות וקישור שלו
השלב הזה מופיע בכמה מקומות במסמכי התיעוד של השירות המנוהל ל-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, ומקבל את כל ההרשאות הנדרשות לשימוש ב-Monitoring API. Google Cloud
בסביבת ייצור, יכול להיות שתרצו להשתמש בגישה מפורטת יותר, עם חשבון שירות לכל רכיב, ולכל אחד מהם הרשאות מינימליות. מידע נוסף על הגדרת חשבונות שירות לניהול Workload Identity זמין במאמר שימוש באיחוד זהויות של עומסי עבודה ל-GKE.
שאילתות והיקפים של מדדים
הנתונים שאפשר להריץ עליהם שאילתות נקבעים לפי המבנה של Cloud Monitoring שנקרא היקף המדדים, בלי קשר לשיטה שבה משתמשים כדי להריץ את השאילתות על הנתונים. לדוגמה, אם אתם משתמשים ב-Grafana כדי לשלוח שאילתות לנתונים של שירות מנוהל ל-Prometheus, כל היקף מדדים צריך להיות מוגדר כמקור נתונים נפרד.
היקף למעקב אחרי מדדים הוא מבנה לקריאה בלבד שמאפשר לשלוח שאילתות לגבי נתוני מדדים ששייכים לכמה פרויקטים של Google Cloud Google Cloud. כל היקף של מדדים מתארח בפרויקט ייעודי Google Cloud , שנקרא פרויקט ההיקף.
כברירת מחדל, פרויקט הוא פרויקט ההיקף של היקף המדדים שלו, והיקף המדדים מכיל את המדדים וההגדרות של הפרויקט הזה. לפרויקט היקפי יכול להיות יותר מפרויקט אחד למעקב בהיקף המדדים שלו, והמדדים וההגדרות מכל הפרויקטים למעקב בהיקף המדדים גלויים לפרויקט ההיקפי. פרויקט במעקב יכול להשתייך גם ליותר מהיקף מדדים אחד.
כשמבצעים שאילתה על המדדים בפרויקט שמוגדר כפרויקט היקף, ואם הפרויקט הזה מארח היקף מדדים של כמה פרויקטים, אפשר לאחזר נתונים מכמה פרויקטים. אם היקף המדדים כולל את כל הפרויקטים, השאילתות והכללים מוערכים באופן גלובלי.
מידע נוסף על הגדרת היקף לפרויקטים ולהיקף המדדים זמין במאמר היקפי מדדים. מידע על הגדרת היקף מדדים של כמה פרויקטים זמין במאמר הצגת מדדים של כמה פרויקטים.
נתונים של שירות מנוהל ל-Prometheus ב-Cloud Monitoring
הדרך הפשוטה ביותר לוודא שהנתונים שלכם ב-Prometheus מיוצאים היא באמצעות הדף Metrics Explorer ב-Cloud Monitoring במסוף Google Cloud , שתומך ב-PromQL. הוראות מפורטות זמינות במאמר בנושא שליחת שאילתות באמצעות PromQL ב-Cloud Monitoring.
אפשר גם לייבא את לוחות הבקרה של Grafana אל Cloud Monitoring. כך תוכלו להמשיך להשתמש בלוחות בקרה של Grafana שנוצרו על ידי הקהילה או על ידיכם, בלי שתצטרכו להגדיר או לפרוס מופע של Grafana.
Grafana
שירות מנוהל ל-Prometheus משתמש במקור הנתונים המובנה של Prometheus ל-Grafana, כך שתוכלו להמשיך להשתמש בכל מרכזי הבקרה של Grafana שנוצרו על ידי הקהילה או על ידיכם, ללא שינויים.
פריסת Grafana, אם צריך
אם אין לכם פריסת Grafana פעילה באשכול, אתם יכולים ליצור פריסת בדיקה זמנית כדי להתנסות.
כדי ליצור פריסת Grafana זמנית, צריך להחיל את מניפסט grafana.yaml שירות מנוהל ל-Prometheus על האשכול, ולהעביר את שירות grafana ליציאה במחשב המקומי. בגלל הגבלות CORS, אי אפשר לגשת לפריסת Grafana באמצעות Cloud Shell.
החלת מניפסט
grafana.yaml:kubectl -n NAMESPACE_NAME apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.17.2/examples/grafana.yaml
מגדירים העברת פורטים לשירות
grafanaלמחשב המקומי. בדוגמה הזו, השירות מועבר ליציאה 3000:kubectl -n NAMESPACE_NAME port-forward svc/grafana 3000
הפקודה הזו לא מחזירה ערך, ובזמן שהיא פועלת, היא מדווחת על גישות לכתובת ה-URL.
אפשר לגשת ל-Grafana בדפדפן בכתובת האתר
http://localhost:3000עם שם המשתמש:סיסמהadmin:admin.
לאחר מכן מוסיפים מקור נתונים חדש של Prometheus ל-Grafana באופן הבא:
עוברים לפריסת Grafana, למשל על ידי גלישה לכתובת ה-URL
http://localhost:3000כדי להגיע לדף הפתיחה של Grafana.בתפריט הראשי של Grafana, בוחרים באפשרות Connections (קישורים) ואז בוחרים באפשרות Data Sources (מקורות נתונים).
לוחצים על הוספה של מקור נתונים ובוחרים באפשרות Prometheus כמסד נתונים של סדרות זמן.
נותנים שם למקור הנתונים, מגדירים את השדה
URLלערךhttp://localhost:9090ולוחצים על שמירה ובדיקה. אפשר להתעלם משגיאות שמופיעות לגבי הגדרה לא תקינה של מקור הנתונים.מעתיקים את כתובת ה-URL של השירות המקומי לפריסה, שתיראה כך:
http://grafana.NAMESPACE_NAME.svc:3000
הגדרה ואימות של מקור הנתונים של Grafana
כל ממשקי ה-API מחייבים אימות באמצעות OAuth2, אבל Grafana לא תומכת באימות OAuth2 לחשבונות שירות שמשמשים עם מקורות נתונים של Prometheus.Google Cloud כדי להשתמש ב-Grafana עם שירות מנוהל ל-Prometheus, צריך להשתמש בכלי לסנכרון מקורות נתונים כדי ליצור פרטי כניסה מסוג OAuth2 לחשבון השירות ולסנכרן אותם עם Grafana באמצעות Grafana data source API.
צריך להשתמש בכלי לסנכרון מקורות נתונים כדי להגדיר את Grafana ולתת לו הרשאה לשלוח שאילתות לנתונים באופן גלובלי. אם לא תפעלו לפי השלבים האלה, Grafana תריץ שאילתות רק על נתונים בשרת Prometheus המקומי.
כלי הסנכרון של מקורות הנתונים הוא כלי עם ממשק שורת פקודה (CLI) ששולח מרחוק ערכי הגדרה למקור נתונים מסוים של Grafana Prometheus. כך מוודאים שמקור הנתונים שלכם ב-Grafana מוגדר בצורה נכונה:
- אימות, שמתבצע על ידי רענון תקופתי של אסימון גישה מסוג OAuth2
- הגדרת Cloud Monitoring API ככתובת ה-URL של שרת Prometheus
- שיטת ה-HTTP מוגדרת ל-GET
- הסוג והגרסה של Prometheus מוגדרים לגרסה מינימלית של 2.40.x
- הערכים של הזמן הקצוב לתפוגה של HTTP ושל שאילתה מוגדרים ל-2 דקות
הכלי לסנכרון מקורות נתונים צריך לפעול שוב ושוב. אסימוני גישה לחשבון שירות תקפים לשעה אחת כברירת מחדל, ולכן הפעלת הכלי לסנכרון מקורות נתונים כל 10 דקות מבטיחה שיהיה לכם חיבור מאומת רציף בין Grafana לבין Cloud Monitoring API.
אתם יכולים להריץ את הכלי לסנכרון מקורות נתונים באמצעות Kubernetes CronJob או באמצעות Cloud Run ו-Cloud Scheduler כדי ליהנות מחוויה מלאה ללא שרתים. אם אתם פורסים את Grafana באופן מקומי, למשל באמצעות Grafana בקוד פתוח או Grafana Enterprise, מומלץ להריץ את הכלי לסנכרון מקורות הנתונים באותו אשכול שבו פועל Grafana. אם אתם משתמשים ב-Grafana Cloud, מומלץ לבחור באפשרות של בלי שרת (serverless) מלאים.
שימוש ב-Serverless
כדי לפרוס ולהפעיל כלי לסנכרון מקורות נתונים בלי שרת (serverless) באמצעות Cloud Run ו-Cloud Scheduler, מבצעים את הפעולות הבאות:
בוחרים פרויקט שבו רוצים לפרוס את הכלי לסנכרון מקורות נתונים. מומלץ לבחור בפרויקט ההיקף של היקף מדדים מרובה פרויקטים. הכלי לסנכרון מקורות נתונים משתמש בפרויקט שהוגדר Google Cloud כפרויקט ההיקף.
לאחר מכן, מגדירים ומאשרים חשבון שירות עבור הכלי לסנכרון מקור הנתונים. רצף הפקודות הבא יוצר חשבון שירות ומקצה לו כמה תפקידים ב-IAM. שני התפקידים הראשונים מאפשרים לחשבון השירות לקרוא מ-Cloud Monitoring API וליצור אסימונים של חשבון השירות. שני התפקידים האחרונים מאפשרים לחשבון השירות לקרוא את האסימון של חשבון השירות של Grafana מ-Secret Manager ולהפעיל את Cloud Run:
gcloud config set project PROJECT_ID \ && gcloud iam service-accounts create gmp-ds-syncer-sa \ && gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:gmp-ds-syncer-sa@PROJECT_ID.iam.gserviceaccount.com \ --role=roles/monitoring.viewer \ && \ gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:gmp-ds-syncer-sa@PROJECT_ID.iam.gserviceaccount.com \ --role=roles/iam.serviceAccountTokenCreator \ && \ gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:gmp-ds-syncer-sa@PROJECT_ID.iam.gserviceaccount.com \ --role=roles/secretmanager.secretAccessor && \ gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:gmp-ds-syncer-sa@PROJECT_ID.iam.gserviceaccount.com \ --role=roles/run.invoker
קובעים את כתובת ה-URL של מופע Grafana, לדוגמה
https://yourcompanyname.grafana.netלפריסה של Grafana Cloud. צריך שתהיה גישה למכונת Grafana מ-Cloud Run, כלומר צריך שתהיה גישה אליה מהאינטרנט הרחב.אם אי אפשר לגשת למופע Grafana שלכם מהאינטרנט הרחב, מומלץ לפרוס את הכלי לסנכרון מקור הנתונים ב-Kubernetes במקום זאת.
בוחרים את מקור הנתונים של Grafana Prometheus שרוצים להשתמש בו בשירות המנוהל ל-Prometheus. אפשר לבחור מקור נתונים חדש או מקור נתונים קיים של Prometheus. לאחר מכן מאתרים את ה-UID של מקור הנתונים ורושמים אותו. אפשר למצוא את מזהה מקור הנתונים בחלק האחרון של כתובת ה-URL כשמנתחים או מגדירים מקור נתונים, לדוגמה
https://yourcompanyname.grafana.net/connections/datasources/edit/GRAFANA_DATASOURCE_UID. אל תעתיקו את כתובת ה-URL המלאה של מקור הנתונים. מעתיקים רק את המזהה הייחודי מכתובת ה-URL.
מגדירים חשבון שירות ב-Grafana על ידי יצירת חשבון השירות ויצירת אסימון לשימוש בחשבון:
בסרגל הצד לניווט ב-Grafana, לוחצים על Administration > Users and Access > Service Accounts (ניהול > משתמשים וגישה > חשבונות שירות).
יוצרים את חשבון השירות ב-Grafana על ידי לחיצה על Add service account, נותנים לו שם ומעניקים לו את התפקיד Data Sources > Writer. חשוב ללחוץ על הלחצן החלה כדי להקצות את התפקיד. בגרסאות ישנות יותר של Grafana, אפשר להשתמש בתפקיד 'Admin' במקום זאת.
לוחצים על הוספת אסימון של חשבון שירות.
מגדירים את תוקף האסימון ל'ללא תוקף', לוחצים על יצירת אסימון ומעתיקים את האסימון שנוצר ללוח כדי להשתמש בו כ-GRAFANA_SERVICE_ACCOUNT_TOKEN בשלב הבא:
מגדירים את משתני התיעוד הבאים באמצעות התוצאות של השלבים הקודמים. אין צורך להדביק את הטקסט הבא במסוף:
# These values are required. REGION # The Google Cloud region where you want to run your Cloud Run job, such as us-central1. PROJECT_ID # The Project ID from Step 1. GRAFANA_INSTANCE_URL # The Grafana instance URL from step 2. This is a URL. Include "http://" or "https://". GRAFANA_DATASOURCE_UID # The Grafana data source UID from step 3. This is not a URL. GRAFANA_SERVICE_ACCOUNT_TOKEN # The Grafana service account token from step 4.
יוצרים סוד ב-Secret Manager:
gcloud secrets create datasource-syncer --replication-policy="automatic" && \ echo -n GRAFANA_SERVICE_ACCOUNT_TOKEN | gcloud secrets versions add datasource-syncer --data-file=-
יוצרים את קובץ ה-YAML הבא ונותנים לו את השם
cloud-run-datasource-syncer.yaml:apiVersion: run.googleapis.com/v1 kind: Job metadata: name: datasource-syncer-job spec: template: spec: taskCount: 1 template: spec: containers: - name: datasource-syncer image: gke.gcr.io/prometheus-engine/datasource-syncer:v0.17.2-gke.2 args: - "--datasource-uids=GRAFANA_DATASOURCE_UID" - "--grafana-api-endpoint=GRAFANA_INSTANCE_URL" - "--project-id=PROJECT_ID" env: - name: GRAFANA_SERVICE_ACCOUNT_TOKEN valueFrom: secretKeyRef: key: latest name: datasource-syncer serviceAccountName: gmp-ds-syncer-sa@PROJECT_ID.iam.gserviceaccount.comלאחר מכן מריצים את הפקודה הבאה כדי ליצור משימת Cloud Run באמצעות קובץ ה-YAML:
gcloud run jobs replace cloud-run-datasource-syncer.yaml --region REGION
יוצרים תזמון ב-Cloud Scheduler להרצת המשימה של Cloud Run כל 10 דקות:
gcloud scheduler jobs create http datasource-syncer \ --location REGION \ --schedule="*/10 * * * *" \ --uri="https://REGION-run.googleapis.com/apis/run.googleapis.com/v1/namespaces/PROJECT_ID/jobs/datasource-syncer-job:run" \ --http-method POST \ --oauth-service-account-email=gmp-ds-syncer-sa@PROJECT_ID.iam.gserviceaccount.com
לאחר מכן מריצים בכוח את מתזמן המשימות שיצרתם:
gcloud scheduler jobs run datasource-syncer --location REGION
יכול להיות שיחלפו עד 15 שניות עד שמקור הנתונים יתעדכן.
עוברים למקור הנתונים החדש שהגדרתם ב-Grafana ומוודאים שהערך של כתובת ה-URL של שרת Prometheus מתחיל ב-
https://monitoring.googleapis.com. יכול להיות שתצטרכו לרענן את הדף. אחרי האימות, גוללים לתחתית הדף, בוחרים באפשרות שמירה ובדיקה ומוודאים שמופיע סימן וי ירוק שאומר שמקור הנתונים מוגדר בצורה תקינה. כדי לוודא שההשלמה האוטומטית של התוויות ב-Grafana פועלת, צריך ללחוץ על שמירה ובדיקה לפחות פעם אחת.
שימוש ב-Kubernetes
כדי לפרוס ולהפעיל את הכלי לסנכרון מקורות נתונים באשכול Kubernetes:
בוחרים פרויקט, אשכול ומרחב שמות לפריסת הכלי לסנכרון מקור הנתונים. מומלץ לפרוס את הכלי לסנכרון מקורות נתונים באשכול ששייך לפרויקט ההיקף של היקף מדדים מרובה פרויקטים. הכלי לסנכרון מקורות נתונים משתמש בפרויקט שהוגדר Google Cloud כפרויקט ההיקף.
בשלב הבא, מוודאים שהגדרתם והרשיתם את הכלי לסנכרון מקורות נתונים בצורה נכונה:
- אם אתם משתמשים באיחוד שירותי אימות הזהות של עומסי עבודה ב-GKE, אתם צריכים לפעול לפי ההוראות ליצירה ולאישור של חשבון שירות. חשוב לוודא שמשייכים אותו למרחב השמות של Kubernetes שבו רוצים להפעיל את הכלי לסנכרון מקורות נתונים.
- אם אתם לא משתמשים ב-איחוד זהויות של עומסי עבודה ל-GKE, אז ודאו שלא שיניתם את חשבון השירות שמוגדר כברירת מחדל ב-Compute Engine.
- אם אתם לא מריצים את הכלי ב-GKE, תוכלו לקרוא את המאמר הרצת הכלי לסנכרון מקורות נתונים מחוץ ל-GKE.
לאחר מכן, בודקים אם צריך לתת הרשאה נוספת לכלי לסנכרון מקורות נתונים כדי לבצע שאילתות בכמה פרויקטים:
- אם הפרויקט המקומי הוא פרויקט ההיקף, ופעלתם לפי ההוראות לאימות או להגדרה של חשבון שירות עבור הפרויקט המקומי, שאילתות מרובות פרויקטים אמורות לפעול ללא צורך בהגדרה נוספת.
- אם הפרויקט המקומי שלכם הוא לא פרויקט ההיקף, אתם צריכים לתת הרשאה לכלי לסנכרון מקורות נתונים להריץ שאילתות בפרויקט ההיקף. הוראות מפורטות זמינות במאמר בנושא מתן הרשאה לכלי לסנכרון מקורות נתונים כדי לקבל מעקב אחרי כמה פרויקטים.
מגדירים את כתובת ה-URL של מופע Grafana, לדוגמה:
https://yourcompanyname.grafana.netלפריסה של Grafana Cloud או http://grafana.NAMESPACE_NAME.svc:3000למופע מקומי שהוגדר באמצעות קובץ ה-YAML של פריסת הבדיקה.אם אתם פורסים את Grafana באופן מקומי והאשכול שלכם מוגדר לאבטח את כל התנועה בתוך האשכול באמצעות TLS, אתם צריכים להשתמש ב-
https://בכתובת ה-URL ולאמת את עצמכם באמצעות אחת מאפשרויות האימות הנתמכות של TLS.בוחרים את מקור הנתונים של Grafana Prometheus שרוצים להשתמש בו בשירות המנוהל ל-Prometheus. אפשר לבחור מקור נתונים חדש או מקור נתונים קיים. לאחר מכן, מאתרים את ה-UID של מקור הנתונים ורושמים אותו. אפשר למצוא את ה-UID של מקור הנתונים בחלק האחרון של כתובת ה-URL כשמגדירים מקור נתונים או כשבוחנים אותו. לדוגמה:
https://yourcompanyname.grafana.net/connections/datasources/edit/GRAFANA_DATASOURCE_UID.אין להעתיק את כתובת ה-URL המלאה של מקור הנתונים. מעתיקים רק את המזהה הייחודי מכתובת ה-URL.
מגדירים חשבון שירות ב-Grafana על ידי יצירת חשבון השירות ויצירת אסימון לשימוש בחשבון:
- בסרגל הצד לניווט ב-Grafana, לוחצים על Administration > Users and Access > Service Accounts (ניהול > משתמשים וגישה > חשבונות שירות).
כדי ליצור את חשבון השירות, לוחצים על Add service account, נותנים לו שם ומקצים לו את התפקיד Admin ב-Grafana. אם הגרסה של Grafana מאפשרת הרשאות מפורטות יותר, אפשר להשתמש בתפקיד Data Sources > Writer.
לוחצים על הוספת אסימון של חשבון שירות.
מגדירים את תוקף האסימון ל'ללא תוקף', לוחצים על יצירת אסימון ומעתיקים את האסימון שנוצר ללוח כדי להשתמש בו בתור GRAFANA_SERVICE_ACCOUNT_TOKEN בשלב הבא.

מגדירים את משתני הסביבה הבאים באמצעות התוצאות של השלבים הקודמים:
# These values are required. PROJECT_ID=SCOPING_PROJECT_ID # The value from Step 1. GRAFANA_API_ENDPOINT=GRAFANA_INSTANCE_URL # The value from step 2. This is a URL. DATASOURCE_UIDS=GRAFANA_DATASOURCE_UID # The value from step 3. This is not a URL. GRAFANA_API_TOKEN=GRAFANA_SERVICE_ACCOUNT_TOKEN # The value from step 4.
מריצים את הפקודה הבאה כדי ליצור CronJob שמרענן את מקור הנתונים באתחול ואז כל 10 דקות. אם אתם משתמשים באיחוד שירותי אימות הזהות של עומסי עבודה ב-GKE, הערך של NAMESPACE_NAME צריך להיות אותו מרחב שמות שקישרתם קודם לחשבון השירות.
curl https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.17.2/cmd/datasource-syncer/datasource-syncer.yaml \ | sed 's|$DATASOURCE_UIDS|'"$DATASOURCE_UIDS"'|; s|$GRAFANA_API_ENDPOINT|'"$GRAFANA_API_ENDPOINT"'|; s|$GRAFANA_API_TOKEN|'"$GRAFANA_API_TOKEN"'|; s|$PROJECT_ID|'"$PROJECT_ID"'|; ' \ | kubectl -n NAMESPACE_NAME apply -f -
עוברים למקור הנתונים החדש שהגדרתם ב-Grafana ומוודאים שהערך של כתובת ה-URL של שרת Prometheus מתחיל ב-
https://monitoring.googleapis.com. יכול להיות שתצטרכו לרענן את הדף. אחרי האימות, גוללים לחלק התחתון של הדף ולוחצים על שמירה ובדיקה. כדי לוודא שההשלמה האוטומטית של התוויות ב-Grafana פועלת, צריך ללחוץ על הלחצן הזה לפחות פעם אחת.
הרצת שאילתות באמצעות Grafana
מעכשיו אפשר ליצור מרכזי בקרה של Grafana ולהריץ שאילתות באמצעות מקור הנתונים שהוגדר. בצילום המסך הבא מוצג תרשים Grafana שבו מוצג המדד up:
מידע על שליחת שאילתות על מדדי מערכת שלGoogle Cloud באמצעות PromQL זמין במאמר PromQL למדדי Cloud Monitoring.
הפעלת הכלי לסנכרון מקורות נתונים מחוץ ל-GKE
אם אתם מריצים את הכלי לסנכרון מקורות נתונים באשכול Google Kubernetes Engine או אם אתם משתמשים באפשרות ללא שרת, אתם יכולים לדלג על הקטע הזה. אם נתקלתם בבעיות באימות ב-GKE, כדאי לעיין במאמר אימות פרטי הכניסה של חשבון שירות.
כשמפעילים את הכלי לסנכרון מקורות נתונים ב-GKE, הוא מאחזר אוטומטית פרטי כניסה מהסביבה על סמך חשבון השירות של הצומת או ההגדרה של איחוד זהויות של עומסי עבודה ל-GKE.
באשכולות Kubernetes שאינם GKE, צריך לספק את פרטי הכניסה באופן מפורש למסנכרן של מקור הנתונים באמצעות משתנה הסביבה GOOGLE_APPLICATION_CREDENTIALS.
מגדירים את ההקשר לפרויקט היעד:
gcloud config set project PROJECT_ID
יוצרים חשבון שירות:
gcloud iam service-accounts create gmp-test-sa
בשלב הזה נוצר חשבון השירות שאולי כבר יצרתם בהוראות בנושא איחוד זהויות של עומסי עבודה ל-GKE.
מעניקים לחשבון השירות את ההרשאות הנדרשות:
gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \ --role=roles/monitoring.viewer \ && \ gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \ --role=roles/iam.serviceAccountTokenCreator
יוצרים ומורידים מפתח לחשבון השירות:
gcloud iam service-accounts keys create gmp-test-sa-key.json \ --iam-account=gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com
מגדירים את הנתיב של קובץ המפתח באמצעות משתנה הסביבה
GOOGLE_APPLICATION_CREDENTIALS.
מתן הרשאה לכלי לסנכרון מקורות נתונים כדי לקבל מעקב אחרי כמה פרויקטים
השירות המנוהל ל-Prometheus תומך בניטור של כמה פרויקטים באמצעות היקפי מדדים.
אם אתם משתמשים באפשרות ללא שרת, תוכלו להריץ שאילתות על כמה פרויקטים אם הפרויקט שבחרתם הוא פרויקט ההיקף של היקף מדדים שכולל כמה פרויקטים.
אם אתם פורסים את הכלי לסנכרון מקורות נתונים ב-Kubernetes, הפרויקט המקומי הוא פרויקט ההיקף ופעלתם לפי ההוראות לאימות או להגדרה של חשבון שירות עבור הפרויקט המקומי, שאילתות מרובות פרויקטים אמורות לפעול ללא צורך בהגדרה נוספת.
אם הפרויקט המקומי הוא לא פרויקט ההיקף, צריך לתת לפרויקט המקומי הרשאה לחשבון השירות שמוגדר כברירת מחדל לחישוב או לחשבון השירות של איחוד זהויות של עומסי עבודה ל-GKE גישת monitoring.viewer לפרויקט ההיקף. לאחר מכן מעבירים את מזהה פרויקט ההיקף כערך של משתנה הסביבה PROJECT_ID.
אם אתם משתמשים בחשבון השירות של Compute Engine default, אתם יכולים לבצע אחת מהפעולות הבאות:
פורסים את הכלי לסנכרון מקורות נתונים באשכול ששייך לפרויקט ההיקף.
מפעילים את איחוד הזהויות של עומסי עבודה ל-GKE באשכול ופועלים לפי שלבי ההגדרה.
צריך לספק מפתח מפורש של חשבון שירות.
כדי לתת לחשבון שירות את ההרשאות הנדרשות לגישה לפרויקט Google Cloud אחר, מבצעים את הפעולות הבאות:
נותנים לחשבון השירות הרשאה לקרוא מהפרויקט של היעד שרוצים לשלוח אליו שאילתה:
gcloud projects add-iam-policy-binding SCOPING_PROJECT_ID \ --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \ --role=roles/monitoring.viewer
כשמגדירים את הכלי לסנכרון מקורות נתונים, מעבירים את המזהה של פרויקט ההיקף כערך של משתנה הסביבה
PROJECT_ID.
בדיקת ה-CronJob של Kubernetes
אם אתם פורסים את הכלי לסנכרון מקורות נתונים ב-Kubernetes, אתם יכולים לבדוק את CronJob ולוודא שכל המשתנים מוגדרים בצורה נכונה על ידי הפעלת הפקודה הבאה:
kubectl describe cronjob datasource-syncer
כדי לראות את היומנים של ה-Job שמגדיר את Grafana בהתחלה, מריצים את הפקודה הבאה מיד אחרי שמחילים את קובץ datasource-syncer.yaml:
kubectl logs job.batch/datasource-syncer-init
פירוק
כדי להשבית את Cronjob של סנכרון מקור הנתונים ב-Kubernetes, מריצים את הפקודה הבאה:
kubectl delete -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.17.2/cmd/datasource-syncer/datasource-syncer.yaml
השבתה של הכלי לסנכרון מקור הנתונים מפסיקה את העדכון של Grafana המקושר עם פרטי כניסה חדשים לאימות, וכתוצאה מכך, שליחת שאילתות אל שירות מנוהל ל-Prometheus כבר לא פועלת.
תאימות ל-API
נקודות הקצה (endpoints) הבאות של Prometheus HTTP API נתמכות על ידי השירות המנוהל ל-Prometheus בכתובת ה-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. כשמשתמשים בכלי לסנכרון מקורות נתונים או בפרוקסי של חזית האתר, המגבלה הזו מנוהלת בשבילכם. אפשר גם להגדיר את מקורות הנתונים של Prometheus ב-Grafana כך שינפיקו רק בקשותGET. הפרמטרmatch[]לא תומך בהתאמה לביטוי רגולרי בתווית__name__.
המאמרים הבאים
- שימוש בהתראות PromQL ב-Cloud Monitoring.
- מגדירים הערכה של כללים מנוהלים.
- מגדירים ייצואנים בשימוש נפוץ.