Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

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

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

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

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

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

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

הגדרת קובץ העזר והוספתו לשירות 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.

הוספת קובץ עזר לשירות Cloud Run

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

הוספת קובץ עזר לשירות 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 ואת המאגר, אפשר להגיש את קובץ תצורת ה-build של 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:

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

אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שבה הכותרת המשנית היא Monitoring.
בסרגל הכלים של החלונית ליצירת שאילתות, לוחצים על הלחצן ששמו PromQL.
מזינים את השאילתה הבאה בחלונית העריכה:
```
foo_metric
```
לוחצים על הוספת שאילתה.
בסרגל הכלים של החלונית ליצירת שאילתות, לוחצים על הלחצן ששמו 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

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

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

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

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

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

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

כל התוויות האחרות שמופיעות עם מדדים שהועברו מגיעות מהמדד שלכם. אם תווית שהוגדרה על ידי המשתמש מתנגשת עם אחת מהתוויות שסופקו על ידי המערכת, התווית שהוגדרה על ידי המשתמש תתחיל במחרוזת 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. כשמשתמשים בכלים כמו הכלי ליצירת שאילתות או שפת השאילתות של Monitoring‏ (MQL) ב-Metrics Explorer, סוג המדד של Cloud Monitoring רלוונטי.

חיוב

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

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

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

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

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

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

הגדרת קובץ העזר והוספתו לשירות Cloud Run

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

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

הוספת קובץ עזר לשירות Cloud Run

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

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

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

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

הוספת קובץ עזר לשירות 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`