‫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 ישתמשו גם בהגדרת החיוב שמבוססת על מכונות. מידע נוסף זמין במאמר הגדרות חיוב (שירותים). יכול להיות שחלק מניסיונות הגירוד ייכשלו אם הקצאת המעבד (CPU) תוגבל בגלל מספר נמוך של שאילתות לשנייה (QPS). מעבד שמוקצה באופן קבוע נשאר זמין.

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

ב-sidecar של השירות המנוהל ל-Prometheus ב-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

ה-sidecar של השירות המנוהל ל-Prometheus ב-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.
- טוענים את אמצעי האחסון כחלק מתמונת ה-Collector בנתיב הטעינה /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`	נקודות קצה לגירוד ב-pods שנבחרו.	`[]ScrapeEndpoint`	TRUE
`targetLabels`	תוויות שצריך להוסיף ליעד של Prometheus לנקודות קצה (endpoint) שהתגלו. התווית `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

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

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

הקובץ הזה מכיל ערך זמני לשמירת מקום (פלייסהולדר) לתמונות שיצרתם בשלבים הקודמים, לכן צריך לעדכן את הפלייסהולדרים בערכים האמיתיים של הפרויקט ב-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:

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

אם אתם משתמשים בשורת החיפוש כדי למצוא את הדף הזה, בחרו בתוצאה שכותרת המשנה שלה היא Monitoring.
בסרגל הכלים של החלונית query-builder, לוחצים על הלחצן PromQL.
מזינים את השאילתה הבאה בחלונית העריכה:
```
foo_metric
```
לוחצים על הוספת שאילתה.
בסרגל הכלים של החלונית query-builder, לוחצים על הלחצן 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 collector (מד).
‫agent_api_request_count: מספר בקשות ה-API מה-sidecar collector (מונה).
‫agent_monitoring_point_count: מספר נקודות המדדים שנכתבו ב-Cloud Monitoring על ידי אוסף ה-sidecar (מונה).

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

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

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

נכנסים לדף Logs Explorer ב- במסוף Google Cloud :
נכנסים לדף 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 gauge בשם foo_metric. ב-Cloud Monitoring, המדד נשמר כסוג המדד prometheus.googleapis.com/foo_metric/gauge.

כששולחים שאילתה על המדד באמצעות PromQL, אפשר להשתמש בשם של Prometheus, כמו שמוסבר במאמרים הצגת מדדי האפליקציה ב-Metrics Explorer והצגת מדדי ה-self ב-Metrics Explorer. כשמשתמשים בכלים כמו הכלי ליצירת שאילתות או שפת שאילתת מעקב (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`