שימוש ב-Prometheus sidecar ל-Cloud Run

השירות המנוהל ל-Prometheus sidecar ל-Cloud Run הוא הדרך המומלצת על ידי Google לקבל מעקב בסגנון Prometheus לשירותי Cloud Run. אם שירות Cloud Run כותב מדדי OTLP, אפשר להשתמש ב-OpenTelemetry sidecar. אבל בשירותים שכותבים מדדים של Prometheus, צריך להשתמש ב-sidecar של השירות המנוהל ל-Prometheus שמתואר במסמך הזה.

במאמר הזה נסביר איך:

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

ה-sidecar משתמש בשירות המנוהל של Google Cloud ל-Prometheus בצד השרת, ובהפצה של OpenTelemetry Collector, שנוצרה בהתאמה אישית לעומסי עבודה ללא שרתים, בצד הלקוח. ההפצה המותאמת הזו כוללת כמה שינויים לתמיכה ב-Cloud Run. הכלי לאיסוף נתונים מבצע גירוד נתונים של הפעלה אחרי 10 שניות, ומבצע גירוד נתונים של כיבוי, לא משנה כמה קצר משך החיים של המופע. כדי להבטיח את המהימנות המקסימלית, מומלץ ששירותי Cloud Run שמריצים את קובץ העזר ישתמשו גם בהגדרת החיוב לפי מופע. מידע נוסף זמין במאמר הגדרות חיוב (שירותים). יכול להיות שחלק מהניסיונות לחילוץ נתונים ייכשלו אם הקצאת המעבד (CPU) מוגבלת בגלל מספר נמוך של שאילתות לשנייה (QPS). מעבד שהוקצה תמיד נשאר זמין.

ה-sidecar מסתמך על התכונה של Cloud Run multi-container (sidecar) כדי להריץ את האוסף כקונטיינר sidecar לצד קונטיינר עומס העבודה. מידע נוסף על קונטיינרים מסוג sidecar ב-Cloud Run זמין במאמר פריסת כמה קונטיינרים בשירות (קונטיינרים מסוג sidecar).

השירות המנוהל ל-Prometheus sidecar ל-Cloud Run כולל הגדרה חדשה, RunMonitoring, שהיא קבוצת משנה של המשאב המותאם אישית PodMonitoring של Kubernetes. רוב המשתמשים יכולים להשתמש בהגדרת ברירת המחדל של RunMonitoring, אבל אפשר גם ליצור הגדרות בהתאמה אישית. מידע נוסף על הגדרות ברירת המחדל וההגדרות המותאמות אישית של RunMonitoring זמין במאמר הוספת קובץ העזר לשירות Cloud Run.

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

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

התקנה והגדרה של ה-CLI של gcloud

בשלבים רבים שמתוארים במסמך הזה נעשה שימוש ב-Google Cloud CLI. מידע על התקנת ה-CLI של gcloud מופיע במאמר ניהול רכיבי Google Cloud CLI.

כשמפעילים פקודות של gcloud, צריך לציין את המזהה של פרויקט Google Cloud . אפשר להגדיר פרויקט ברירת מחדל ל-Google Cloud CLI וכך לא צריך להזין אותו בכל פקודה. כדי להגדיר את הפרויקט כברירת מחדל, מזינים את הפקודה הבאה:

gcloud config set project PROJECT_ID

אפשר גם להגדיר אזור ברירת מחדל לשירות Cloud Run. כדי להגדיר אזור ברירת מחדל, מזינים את הפקודה הבאה:

gcloud config set run/region REGION

הפעלת ממשקי ה-API

צריך להפעיל את ממשקי ה-API הבאים בפרויקט ב- Google Cloud :

Cloud Run Admin API: run.googleapis.com
‫Artifact Registry API: ‏ artifactregistry.googleapis.com
Cloud Monitoring API: monitoring.googleapis.com
Cloud Logging API: logging.googleapis.com
(אופציונלי) אם יוצרים config RunMonitoring בהתאמה אישית, צריך להפעיל את Secret Manager API: secretmanager.googleapis.com
(אופציונלי) אם בוחרים להריץ את אפליקציית הדוגמה באמצעות Cloud Build, צריך להפעיל גם את ממשקי ה-API הבאים:
- Cloud Build API: cloudbuild.googleapis.com.
- ‫Identity and Access Management API‏: iam.googleapis.com. מידע נוסף זמין במאמר בנושא הרצה של אפליקציית הדוגמה.

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

gcloud services list

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

gcloud services enable run.googleapis.com
gcloud services enable artifactregistry.googleapis.com
gcloud services enable secretmanager.googleapis.com
gcloud services enable monitoring.googleapis.com
gcloud services enable logging.googleapis.com
gcloud services enable cloudbuild.googleapis.com
gcloud services enable iam.googleapis.com

חשבון שירות בשביל Cloud Run

כברירת מחדל, שירותים ועבודות ב-Cloud Run משתמשים בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine,‏ PROJECT_NUMBER-compute@developer.gserviceaccount.com. בדרך כלל לחשבון השירות הזה יש את התפקידים הנדרשים בניהול הזהויות והרשאות הגישה (IAM) כדי לכתוב את המדדים והיומנים שמתוארים במסמך הזה:

roles/monitoring.metricWriter
roles/logging.logWriter

אם יוצרים הגדרות RunMonitoring בהתאמה אישית, צריך להקצות לחשבון השירות גם את התפקידים הבאים:

roles/secretmanager.admin
roles/secretmanager.secretAccessor

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

הגדרה והוספה של sidecar לשירות Cloud Run

השירות המנוהל ל-Prometheus sidecar ל-Cloud Run כולל הגדרה חדשה, RunMonitoring, שהיא קבוצת משנה של המשאב המותאם אישית PodMonitoring של Kubernetes. ההגדרה RunMonitoring משתמשת באפשרויות קיימות של PodMonitoring כדי לתמוך ב-Cloud Run, ומבטלת חלק מהאפשרויות שספציפיות ל-Kubernetes.

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

הגדרות ברירת מחדל

שימוש בהגדרת ברירת המחדל של RunMonitoring

אם לא יוצרים הגדרת RunMonitoring מותאמת אישית, האוסף של sidecar יוצר את הגדרת ברירת המחדל הבאה כדי לגרד מדדים מיציאה 8080 בנתיב המדדים /metrics כל 30 שניות:

apiVersion: monitoring.googleapis.com/v1beta
kind: RunMonitoring
metadata:
  name: run-gmp-sidecar
spec:
  endpoints:
  - port: 8080
    path: /metrics
    interval: 30s

כדי להשתמש בהגדרת ברירת המחדל, לא צריך לבצע הגדרות נוספות מעבר להוספת ה-sidecar לשירות Cloud Run.

הוספת ה-sidecar לשירות Cloud Run

כדי להשתמש ב-sidecar עם הגדרת ברירת המחדל RunMonitoring, צריך לשנות את ההגדרה הקיימת של Cloud Run כדי להוסיף את ה-sidecar. כדי להוסיף את ה-sidecar:

מוסיפים הערה של תלות במאגר שמציינת את סדר ההפעלה וההשבתה של המאגרים. בדוגמה הבאה, קונטיינר ה-sidecar, שנקרא collector, מתחיל לפעול אחרי קונטיינר האפליקציה, שנקרא app בדוגמה, ומפסיק לפעול לפניו.
יוצרים מאגר תגים בשם collector (אוסף) כמו בדוגמה הבאה.

לדוגמה, מוסיפים את השורות שמתחילות בתו + (פלוס) להגדרה של Cloud Run, ואז פורסים מחדש את השירות:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  annotations:
    run.googleapis.com/launch-stage: ALPHA
    run.googleapis.com/cpu-throttling: 'false'
  name: my-cloud-run-service
spec:
  template:
    metadata:
      annotations:
        run.googleapis.com/execution-environment: gen2
+       run.googleapis.com/container-dependencies: '{"collector":["app"]}'
    spec:
      containers:
      - image: "REGION-docker.pkg.dev/PROJECT_ID/run-gmp/sample-app"
        name: app
        startupProbe:
          httpGet:
            path: /startup
            port: 8000
        livenessProbe:
          httpGet:
            path: /liveness
            port: 8000
        ports:
        - containerPort: 8000
+     - image: "us-docker.pkg.dev/cloud-ops-agents-artifacts/cloud-run-gmp-sidecar/cloud-run-gmp-sidecar:1.2.0"
+       name: collector

כדי לפרוס מחדש את שירות Cloud Run עם קובץ התצורה run-service.yaml, מריצים את הפקודה הבאה:

‫

gcloud run services replace run-service.yaml --region=REGION

הגדרות אישיות

יצירת הגדרה מותאמת אישית של RunMonitoring

אתם יכולים ליצור הגדרה של RunMonitoring לשירות Cloud Run אם הגדרת ברירת המחדל לא מספיקה. לדוגמה, אפשר ליצור הגדרה כמו זו:

apiVersion: monitoring.googleapis.com/v1beta
kind: RunMonitoring
metadata:
  name: my-custom-cloud-run-job
spec:
  endpoints:
  - port: 8080
    path: /metrics
    interval: 10s
    metricRelabeling:
    - action: replace
      sourceLabels:
      - __address__
      targetLabel: label_key
      replacement: label_value
  targetLabels:
    metadata:
    - service
    - revision

ההגדרה הזו מבצעת את הפעולות הבאות:

הוא אוסף מדדים מיציאה 8080 ומשתמש בנתיב המדדים שמוגדר כברירת מחדל /metrics.
משתמש במרווח גירוד של 10 שניות.
משתמשים בשינוי התווית כדי להוסיף את התווית label_key עם הערך label_value לכל מדד שנאסף.
התוויות service ו-revision של המטא-נתונים מתווספות לכל מדד שנאסף.

מידע על אפשרויות ההגדרה הזמינות מופיע במאמר RunMonitoring spec: configuration options.

כשמשתמשים בהגדרה מותאמת אישית של RunMonitoring, צריך לבצע את ההגדרה הנוספת הבאה:

מפעילים את Secret Manager API ונותנים לחשבון השירות של Cloud Run תפקידים ב-Secret Manager. מידע נוסף זמין במאמר לפני שמתחילים.
שמירת ההגדרה המותאמת אישית כסוד.
הוספת sidecar לשירות Cloud Run

אחסון ההגדרה באמצעות Secret Manager

כדי לספק הגדרת RunMonitoring בהתאמה אישית:

יוצרים קובץ שמכיל את ההגדרה בהתאמה אישית.
יוצרים סוד ב-Secret Manager שמכיל את ההגדרה האישית.

הפקודה הבאה יוצרת סוד בשם mysecret מהקובץ custom-config.yaml:

gcloud secrets create mysecret --data-file=custom-config.yaml

כדי שהשינוי בהגדרות יחול אחרי שמשנים את הקובץ custom-config.yaml, צריך למחוק את הסוד וליצור אותו מחדש, ואז לפרוס מחדש את שירות Cloud Run.

עדכון ההגדרה ב-Secret Manager

אם רוצים לעדכן את ההגדרה המותאמת אישית של RunMonitoring בכל שלב, אפשר להוסיף גרסה חדשה של הסוד הקיים ל-Secret Manager.

לדוגמה, כדי לעדכן את mysecret באמצעות הגדרה חדשה שמאוחסנת בקובץ custom-config-updated.yaml, אפשר להריץ את הפקודה הבאה:

gcloud secrets versions add mysecret --data-file=custom-config-updated.yaml

ה-sidecar נטען מחדש באופן אוטומטי ומחיל את השינויים על ההגדרה שלו.

הוספת ה-sidecar לשירות Cloud Run

אחרי שיוצרים סוד ב-Secret Manager עבור ההגדרה של RunMonitoring, צריך לשנות את ההגדרה של Cloud Run באופן הבא:

הוספת קובץ ה-sidecar של השירות המנוהל ל-Prometheus
- מוסיפים הערה של תלות במאגר שמציינת את סדר ההפעלה וההשבתה של המאגרים. בדוגמה הבאה, קונטיינר ה-sidecar, שנקרא collector, מתחיל לפעול אחרי קונטיינר האפליקציה, שנקרא app בדוגמה, ומפסיק לפעול לפניו.
- יוצרים מאגר תגים בשם collector (אוסף) כמו בדוגמה הבאה.
מוסיפים את הסוד על ידי העלאת הסוד במיקום /etc/rungmp/config.yaml:
- מוסיפים הערת סוד שמפנה לסוד שמכיל את ההגדרה המותאמת אישית של RunMonitoring.
- יוצרים אמצעי אחסון בשם config, כמו בדוגמה הבאה, בשביל הסוד שמצביע על הקובץ config.yaml.
- טעינת אמצעי האחסון כחלק מתמונת האוסף בנתיב הטעינה /etc/rungmp.

לדוגמה, מוסיפים את השורות שמתחילות בתו + (פלוס) להגדרה של Cloud Run, ואז פורסים מחדש את השירות:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  annotations:
    run.googleapis.com/launch-stage: ALPHA
    run.googleapis.com/cpu-throttling: 'false'
  name: my-cloud-run-service
spec:
  template:
    metadata:
      annotations:
        run.googleapis.com/execution-environment: gen2
+       run.googleapis.com/container-dependencies: '{"collector":["app"]}'
+       run.googleapis.com/secrets: 'mysecret:projects/PROJECT_ID/secrets/mysecret'
    spec:
      containers:
      - image: "REGION-docker.pkg.dev/PROJECT_ID/run-gmp/sample-app"
        name: app
        startupProbe:
          httpGet:
            path: /startup
            port: 8000
        livenessProbe:
          httpGet:
            path: /liveness
            port: 8000
        ports:
        - containerPort: 8000
+     - image: "us-docker.pkg.dev/cloud-ops-agents-artifacts/cloud-run-gmp-sidecar/cloud-run-gmp-sidecar:1.2.0"
+       name: collector
+       volumeMounts:
+       - mountPath: /etc/rungmp/
+         name: config
+     volumes:
+     - name: config
+       secret:
+         items:
+         - key: latest
+           path: config.yaml
+         secretName: 'mysecret'

כדי לפרוס מחדש את שירות Cloud Run עם קובץ התצורה run-service.yaml, מריצים את הפקודה הבאה:

gcloud run services replace run-service.yaml --region=REGION

מפרט RunMonitoring: אפשרויות הגדרה

בקטע הזה מוסבר על RunMonitoring מפרט ההגדרות של תוסף ה-sidecar של השירות המנוהל ל-Prometheus. בדוגמה הבאה מוצגת הגדרה בהתאמה אישית:

apiVersion: monitoring.googleapis.com/v1beta
kind: RunMonitoring
metadata:
  name: my-custom-cloud-run-job
spec:
  endpoints:
  - port: 8080
    path: /metrics
    interval: 10s
    metricRelabeling:
    - action: replace
      sourceLabels:
      - __address__
      targetLabel: label_key
      replacement: label_value
  targetLabels:
    metadata:
    - service
    - revision

RunMonitoring

ההגדרה RunMonitoring עוקבת אחרי שירות Cloud Run.

שדה	תיאור	Scheme	חובה
`metadata`	מטא-נתונים שכל המשאבים הקבועים חייבים לכלול.	`metav1.ObjectMeta`	FALSE
`spec`	הגדרת הפריסה של Cloud Run שנבחרה לגילוי היעד על ידי Prometheus.	`RunMonitoringSpec`	TRUE

RunMonitoringSpec

במפרט הזה מוסבר איך RunMonitoringההגדרה עוקבת אחרי שירות Cloud Run.

שדה	תיאור	Scheme	חובה
`endpoints`	נקודות הקצה לגירוד בתרמילים שנבחרו.	`[]ScrapeEndpoint`	TRUE
`targetLabels`	תוויות להוספה ליעד Prometheus עבור נקודות קצה שזוהו. התווית `instance` תמיד מוגדרת למזהה המופע של Cloud Run.	`RunTargetLabels`	FALSE
`limits`	מגבלות שחלות בזמן החילוץ.	`*ScrapeLimits`	FALSE

RunTargetLabels

ההגדרה RunTargetLabels מאפשרת לכם לכלול תוויות של Cloud Run מיעדי Prometheus שזוהו.

שדה	תיאור	Scheme	חובה
`metadata`	תוויות מטא-נתונים של Cloud Run שמוגדרות בכל היעדים שמתבצעת מהם גרידה. המקשים המותרים הם `instance`, `revision`, `service` ו-`configuration`.‫ אם מוגדרים מפתחות מותרים, תהליך ה-sidecar מוסיף את הערך המתאים ממופע Cloud Run כתוויות של מדדים לכל מדד: `instanceID`,‏ `revision_name`,‏ `service_name` ו-`configuration_name`. ברירת המחדל היא שכל המקשים המותרים מוגדרים.	`*[]string`	FALSE

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

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

שכפול המאגר `run-gmp-sidecar`

כדי לקבל את האפליקציה לדוגמה ואת קובצי התצורה שלה, משכפלים את מאגר run-gmp-sidecar באמצעות הפקודה הבאה:

git clone https://github.com/GoogleCloudPlatform/run-gmp-sidecar/

אחרי שיבוט המאגר, עוברים לספרייה run-gmp-sidecar:

cd run-gmp-sidecar

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

אפליקציית הדוגמה דורשת Docker או מערכת build דומה ליצירת קונטיינרים ל-Linux. אפשר ליצור ולהריץ את אפליקציית הדוגמה באחת מהדרכים הבאות:

משתמשים ב-Cloud Build כדי להריץ בלי תמיכה מקומית ב-Docker. אם אתם משתמשים ב-Cloud Build, אתם צריכים להפעיל גם את Cloud Build API.
מבצעים build ומריצים את האפליקציה לדוגמה באופן ידני.

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

שימוש ב-Cloud Build

המאגר run-gmp-sidecar כולל קובצי תצורה ל-Cloud Build. הקבצים האלה כוללים את השלבים שנדרשים כדי ליצור ולפרוס את האפליקציה לדוגמה.

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

הגדרה של Cloud Build

כדי להשתמש בקובצי ההגדרות האלה, צריך חשבון שירות של Cloud Build ומאגר Artifact Registry. מאגר run-gmp-sidecar כולל גם סקריפט, create-sa-and-ar.sh, שמבצע את הפעולות הבאות:

יוצר חשבון שירות, run-gmp-sa@PROJECT_ID.iam.gserviceaccount.com.
מקצים לחשבון השירות את התפקידים הבאים:
- roles/iam.serviceAccountUser
- roles/storage.objectViewer
- roles/logging.logWriter
- roles/artifactregistry.createOnPushWriter
- roles/secretmanager.admin
- roles/secretmanager.secretAccessor
- roles/run.admin
יוצר מאגר Artifact Registry‏, run-gmp, לתמונות שלכם של קונטיינרים.

כדי ליצור את חשבון השירות run-gmp-sa ואת מאגר run-gmp, מריצים את הפקודה הבאה:

./create-sa-and-ar.sh

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

שליחת בקשה ל-Cloud Build

אחרי שמגדירים את run-gmp-sa חשבון השירות ואת run-gmp המאגר, אפשר להתחיל משימה ב-Cloud Build על ידי שליחת קובץ התצורה של Cloud Build. אפשר להשתמש בפקודה gcloud builds submit הבאה:

gcloud builds submit . --config=cloudbuild-simple.yaml --region=REGION

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

Logs are available at [
https://console.cloud.google.com/cloud-build/builds/637860fb-7a14-46f2-861e-09c1dc4cea6b?project=PROJECT_NUMBER].

כדי לראות את התקדמות הבנייה, עוברים לכתובת ה-URL שהוחזרה בדפדפן. אפשר גם לראות את היומנים של ה-sidecar ב-Cloud Logging.

בדיקת כתובת ה-URL של השירות

אחרי שהמשימה של Cloud Build מסתיימת, מריצים את הפקודה הבאה כדי לבדוק את כתובת ה-URL של נקודת הקצה של שירות Cloud Run:

gcloud run services describe my-cloud-run-service --region=REGION --format="value(status.url)"

הפקודה הזו מחזירה את כתובת ה-URL של השירות, שנראית כך:

https://my-cloud-run-service-abcdefghij-ue.a.run.app

בנייה והרצה ידנית

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

הגדרת משתנים שמשמשים בשלבים מאוחרים יותר

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

export GCP_PROJECT=PROJECT_ID
export REGION=REGION

יצירת מאגר קובצי אימג' של קונטיינרים

כדי ליצור מאגר ב-Artifact Registry בשביל קובץ האימג' של הקונטיינר, מריצים את הפקודה הבאה:

gcloud artifacts repositories create run-gmp \
    --repository-format=docker \
    --location=${REGION}

פיתוח והעלאה של אפליקציה לדוגמה

בדוגמה הזו נעשה שימוש ב-Docker ב-Linux כדי ליצור את אפליקציית הדוגמה ולהעביר אותה בדחיפה למאגר ב-Artifact Registry. יכול להיות שתצטרכו להתאים את הפקודות האלה אם אתם עובדים בסביבת Windows או macOS.

הערה: אם אתם צריכים להריץ פקודות של sudo, אתם צריכים גם לאמת את עצמכם באמצעות sudo.docker אם לא תעשו זאת, המשתמש הלא נכון במערכת יוגדר, והבקשות ל-Cloud Run לא יאומתו.

sudo gcloud auth login --no-launch-browser
sudo gcloud auth configure-docker

כדי ליצור את האפליקציה לדוגמה ולהעביר אותה בדחיפה ל-Artifact Registry:

מאמתים את לקוח Docker באמצעות Google Cloud CLI:
```
gcloud auth configure-docker ${REGION}-docker.pkg.dev
```
עוברים לספרייה simple-app במאגר run-gmp-sidecar:
```
pushd sample-apps/simple-app
```
מריצים את הפקודה הבאה כדי ליצור את אפליקציית simple-app:
```
docker build -t ${REGION}-docker.pkg.dev/${GCP_PROJECT}/run-gmp/sample-app .
```
מריצים את הפקודה הבאה כדי לשלוח את האימג' של האפליקציה שנבנתה:
```
docker push ${REGION}-docker.pkg.dev/${GCP_PROJECT}/run-gmp/sample-app
```
חוזרים לספרייה run-gmp-sidecar:
```
popd
```

הגדרת שירות Cloud Run

הקובץ run-service-simple.yaml במאגר run-gmp-sidecar מגדיר שירות Cloud Run עם כמה קונטיינרים שמשתמש באפליקציה לדוגמה ובקובצי האימג' של כלי האיסוף שיצרתם בשלבים הקודמים. קובץ run-service-simple.yaml מכיל את מפרט השירות הבא:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  annotations:
    run.googleapis.com/launch-stage: ALPHA
    run.googleapis.com/cpu-throttling: 'false'
  name: my-cloud-run-service
spec:
  template:
    metadata:
      annotations:
        run.googleapis.com/execution-environment: gen2
        run.googleapis.com/container-dependencies: '{"collector":["app"]}'
    spec:
      containers:
      - image: "%SAMPLE_APP_IMAGE%"
        name: app
        startupProbe:
          httpGet:
            path: /startup
            port: 8000
        livenessProbe:
          httpGet:
            path: /liveness
            port: 8000
        ports:
        - containerPort: 8000
      - image: "us-docker.pkg.dev/cloud-ops-agents-artifacts/cloud-run-gmp-sidecar/cloud-run-gmp-sidecar:1.2.0"
        name: collector

הקובץ הזה מכיל ערך placeholder לתמונות שיצרתם בשלבים הקודמים, ולכן אתם צריכים לעדכן את ה-placeholders בערכים בפועל של פרויקטGoogle Cloud .

מריצים את הפקודה הבאה כדי להחליף את ה-placeholder‏ %SAMPLE_APP_IMAGE%:

sed -i s@%SAMPLE_APP_IMAGE%@REGION-docker.pkg.dev/${GCP_PROJECT}/run-gmp/sample-app@g run-service-simple.yaml

פריסת שירות Cloud Run

אחרי שמעדכנים את קובץ run-service-simple.yaml עם הערכים הרצויים, אפשר ליצור ולפרוס את שירות Cloud Run באמצעות הפקודה הבאה:

gcloud run services replace run-service-simple.yaml --region=REGION

הפקודה הזו מחזירה את כתובת ה-URL של השירות, שנראית כך:

https://my-cloud-run-service-abcdefghij-ue.a.run.app

אישור גישת HTTP לא מאומתת

כדי לשלוח בקשה לכתובת ה-URL של השירות, צריך לשנות את מדיניות השירות של Cloud Run כך שתאפשר גישת HTTP לא מאומתת. קובץ policy.yaml במאגר run-gmp-sidecar מכיל את השינוי הנדרש.

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

gcloud run services set-iam-policy my-cloud-run-service policy.yaml --region=REGION

אימות שהאפליקציה פועלת

כדי לוודא ששירות Cloud Run הפעיל את האפליקציה לדוגמה בצורה תקינה, משתמשים בכלי curl כדי לגשת לנקודת הקצה metrics של השירות.

מריצים את הפקודה הבאה כדי לקבל את כתובת ה-URL של השירות:
```
SERVICE_URL=$(gcloud run services describe my-cloud-run-service --region=REGION --format 'value(status.url)')
```
מחליפים את REGION באזור Cloud Run של השירות.
שולחים בקשה לכתובת ה-URL של השירות באמצעות הפקודה הבאה:
```
curl $SERVICE_URL
```

אם האפליקציה הופעלה בהצלחה, תופיע התגובה הבאה:

User request received!

הצגת מדדי האפליקציה ב-Metrics Explorer

קובץ המאגר app לדוגמה כותב את המדדים הבאים:

‫foo_metric: השעה הנוכחית כערך נקודה צפה (מדד).
bar_metric: השעה הנוכחית כערך נקודה צפה (מונה).

כדי לראות את המדדים האלה ב-Metrics Explorer:

במסוף Google Cloud , עוברים לדף Metrics explorer:
כניסה אל Metrics Explorer

אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שכותרת המשנה שלה היא Monitoring.
בסרגל הכלים של חלונית הכלי ליצירת שאילתות, לוחצים על הלחצן ששמו הוא MQL או PromQL.
מוודאים שהאפשרות PromQL נבחרה במתג שפה. המתג לשפה נמצא באותו סרגל כלים שבו אפשר לעצב את השאילתה.
מזינים את השאילתה הבאה בחלונית העריכה:
```
foo_metric
```
לוחצים על הוספת שאילתה.
בסרגל הכלים של חלונית הכלי ליצירת שאילתות, לוחצים על הלחצן ששמו הוא MQL או PromQL.
מוודאים שהאפשרות PromQL נבחרה במתג שפה. המתג לשפה נמצא באותו סרגל כלים שבו אפשר לעצב את השאילתה.
מזינים את השאילתה הבאה בחלונית העריכה השנייה:
```
bar_metric
```
לוחצים על Run query.
כדי לראות פרטים על המדדים, במתג עם התווית Chart Table Both (תרשים, טבלה, שניהם), בוחרים באפשרות Both (שניהם).

הסרת המשאבים

אחרי שמסיימים להתנסות באפליקציה לדוגמה, אפשר להשתמש בסקריפט clean-up-cloud-run.sh במאגר run-gmp-sidecar כדי למחוק את המשאבים הבאים שאולי יצרתם עבור הדוגמה:

שירות Cloud Run.
מאגר Artifact Registry.
חשבון השירות שנוצר עבור Cloud Build.

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

כדי לנקות את אפליקציית הדוגמה, מריצים את הסקריפט clean-up-cloud-run.sh:

./clean-up-cloud-run.sh

הצגת מדדים עצמיים ב-Metrics Explorer

קובץ העזר של השירות המנוהל ל-Prometheus מדווח על המדדים הבאים לגבי עצמו ל-Cloud Monitoring:

‫agent_uptime: זמן הפעולה של אוסף הנתונים של ה-sidecar (מונה).
‫agent_memory_usage: הזיכרון שנצרך על ידי אוסף ה-sidecar (מדד).
‫agent_api_request_count: מספר בקשות ה-API מה-sidecar collector (מונה).
‫agent_monitoring_point_count: מספר נקודות המדד שנכתבו ל-Cloud Monitoring על ידי אוסף הנתונים של ה-sidecar (מונה).

כדי לראות את המדדים העצמיים של קובץ ה-sidecar ב-Metrics Explorer:

במסוף Google Cloud , עוברים לדף Metrics explorer:
כניסה אל Metrics Explorer

אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שכותרת המשנה שלה היא Monitoring.
בסרגל הכלים של חלונית הכלי ליצירת שאילתות, לוחצים על הלחצן ששמו הוא MQL או PromQL.
מוודאים שהאפשרות PromQL נבחרה במתג שפה. המתג לשפה נמצא באותו סרגל כלים שבו אפשר לעצב את השאילתה.
מזינים את שם המדד שרוצים לשלוח לגביו שאילתה בחלונית העריכה, לדוגמה:
```
agent_api_request_count
```
לוחצים על Run query.
כדי לראות פרטים על המדדים, במתג עם התווית Chart Table Both (תרשים, טבלה, שניהם), בוחרים באפשרות Both (שניהם).

צפייה ביומנים של עצמי ב-Logs Explorer

ה-sidecar של השירות המנוהל ל-Prometheus כותב יומנים ל-Cloud Logging. קובץ ה-sidecar כותב יומנים מול סוג המשאב במעקב של Logging‏ cloud_run_revision.

כדי להציג את היומנים של ה-sidecar ב-Logs Explorer, מבצעים את הפעולות הבאות:

במסוף Google Cloud , נכנסים לדף Logs Explorer:
כניסה אל Logs Explorer

אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שכותרת המשנה שלה היא Logging.
בוחרים את סוג המשאב Cloud Run Revision או מזינים את השאילתה הבאה ולוחצים על Run query:
```
resource.type="cloud_run_revision"
```

מידע על המדדים שנאספים

כשמדדים שנפלטים על ידי קובץ ה-sidecar מוזנים ל-Cloud Monitoring, המדדים נכתבים מול סוג המשאב במעקב prometheus_target של Cloud Monitoring. סוג המשאב הזה משמש גם למדדי אפליקציות וגם למדדים עצמיים של ה-sidecar.

כשכותבים את המדדים, ה-sidecar מגדיר את תוויות המשאבים באופן הבא:

‫project_id: מזהה הפרויקט שבו פועל הקונטיינר. Google Cloud
‫location: האזור Google Cloud שבו פועל הקונטיינר.
‫cluster: הערך __run__.
‫namespace: השם של שירות Cloud Run שמופעל. מגיע ממשתנה הסביבה K_SERVICE.
‫job: השם מההגדרה RunMonitoring. ברירת המחדל היא run-gmp-sidecar.
‫instance: הערך faas.ID:PORT של עומס העבודה המקומי שממנו המאגר מוגדר לשליפת מדדים. הערך faas.ID הוא מזהה המופע של מופע Cloud Run.

בנוסף, ה-sidecar מוסיף את תוויות המדדים הבאות:

‫instanceId: המזהה של מופע Cloud Run.
‫service_name: השם של שירות Cloud Run שמופעל.
‫revision_name: השם של גרסת Cloud Run שמופעלת.
‫configuration_name: השם של הגדרת Cloud Run שמופעלת.

כל תוויות המדדים האלה מתווספות כברירת מחדל. אם משתמשים בהגדרה מותאמת אישית RunMonitoring, אפשר להשמיט את התוויות service_name, revision_name ו-configuration_name באמצעות האפשרות targetLabels במפרט RunMonitoring. אפשר גם להשתמש בהגדרה מותאמת אישית כדי לשנות את התוויות של הערכים service_name, revision_name ו-configuration_name.

כל התוויות האחרות שמופיעות עם מדדים שהועברו מגיעות מהמדד שלכם. אם תווית שהוגדרה על ידי המשתמש מתנגשת עם אחת מהתוויות שסופקו על ידי המערכת, התווית שהוגדרה על ידי המשתמש תתחיל במחרוזת exported_. לדוגמה, תווית שצוינה על ידי המשתמש namespace="playground" מתנגשת עם התווית namespace שהוגדרה על ידי המערכת, ולכן תווית המשתמש מופיעה כ-exported_namespace="playground".

סוג מדד

כשמבצעים הטמעה של המדדים שמופקים על ידי ה-sidecar ב-Cloud Monitoring, המדדים נכתבים כמדדי prometheus.googleapis.com, וסוג המדד של Prometheus מצורף לסוף השם. לדוגמה, האפליקציה לדוגמה פולטת מדד של מדד Prometheus בשם foo_metric. ב-Cloud Monitoring, המדד מאוחסן כסוג המדד prometheus.googleapis.com/foo_metric/gauge.

כששולחים שאילתה למדד באמצעות PromQL, אפשר להשתמש בשם של Prometheus, כמו שמוסבר במאמרים הצגת מדדי אפליקציה ב-Metrics Explorer והצגת מדדים עצמיים ב-Metrics Explorer. כשמשתמשים בכלים כמו הכלי ליצירת שאילתות או שפת שאילתת מעקב (MQL) בכלי Metrics Explorer, סוג המדד של Cloud Monitoring רלוונטי.

חיוב

המדדים שמופקים על ידי ה-sidecar מוזנים ל-Cloud Monitoring עם התחילית prometheus.googleapis.com. החיוב על מדדים עם הקידומת הזו מתבסס על מספר הדגימות שהמערכת מעבדת. מידע נוסף על חיוב ועל שירות מנוהל ל-Prometheus זמין במאמר חיוב.

שימוש ב-Prometheus sidecar ל-Cloud Run קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

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

התקנה והגדרה של ה-CLI של gcloud

הפעלת ממשקי ה-API

חשבון שירות בשביל Cloud Run

הגדרה והוספה של sidecar לשירות Cloud Run

הגדרות ברירת מחדל

שימוש בהגדרת ברירת המחדל של RunMonitoring

הוספת ה-sidecar לשירות Cloud Run

הגדרות אישיות

יצירת הגדרה מותאמת אישית של RunMonitoring

אחסון ההגדרה באמצעות Secret Manager

עדכון ההגדרה ב-Secret Manager

הוספת ה-sidecar לשירות Cloud Run

מפרט RunMonitoring: אפשרויות הגדרה

RunMonitoring

RunMonitoringSpec

RunTargetLabels

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

שכפול המאגר run-gmp-sidecar

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

שימוש ב-Cloud Build

שימוש ב-Cloud Build

הגדרה של Cloud Build

שליחת בקשה ל-Cloud Build

בדיקת כתובת ה-URL של השירות

בנייה והרצה ידנית

בנייה והרצה ידנית

הגדרת משתנים שמשמשים בשלבים מאוחרים יותר

יצירת מאגר קובצי אימג' של קונטיינרים

פיתוח והעלאה של אפליקציה לדוגמה

הגדרת שירות Cloud Run

פריסת שירות Cloud Run

אישור גישת HTTP לא מאומתת

אימות שהאפליקציה פועלת

הצגת מדדי האפליקציה ב-Metrics Explorer

הסרת המשאבים

הצגת מדדים עצמיים ב-Metrics Explorer

צפייה ביומנים של עצמי ב-Logs Explorer

מידע על המדדים שנאספים

סוג מדד

חיוב

שימוש ב-Prometheus sidecar ל-Cloud Run

שכפול המאגר `run-gmp-sidecar`