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

כתיבת מדדי Prometheus באמצעות Prometheus sidecar

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

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

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

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

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

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

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

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

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

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

כשמפעילים פקודות של 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
(אופציונלי) אם יוצרים הגדרת 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 collector יוצר את הגדרת ברירת המחדל הבאה כדי לאסוף מדדים מיציאה 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:

מוסיפים הערה של תלות בקונטיינר שמציינת את סדר ההפעלה וההשבתה של הקונטיינרים. בדוגמה הבאה, הקונטיינר המשני (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: אפשרויות הגדרה.

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

הוספת קובץ העזר לשירות 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 או מערכת דומה ליצירת קונטיינרים ל-Linux. אפשר ליצור ולהריץ את האפליקציה לדוגמה באחת מהדרכים הבאות:

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

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

שימוש ב-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].

כדי לצפות בהתקדמות של תהליך ה-build, עוברים לכתובת ה-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 יריץ פקודות של docker, תצטרכו גם לאמת באמצעות sudo. אם לא תעשו את זה, משתמש המערכת הלא נכון יוגדר, והבקשות ל-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

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

חיוב

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

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

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

התקנה והגדרה של ה-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 באמצעות Prometheus sidecar

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