Prometheus-Sidecar für Cloud Run verwenden

Der Managed Service for Prometheus-Sidecar für Cloud Run ist die von Google empfohlene Methode, um Prometheus-ähnliches Monitoring für Cloud Run-Dienste zu erhalten. Wenn Ihr Cloud Run-Dienst OTLP-Messwerte schreibt, können Sie den OpenTelemetry-Sidecar verwenden. Verwenden Sie jedoch für Dienste, die Prometheus-Messwerte schreiben, den in diesem Dokument beschriebenen Sidecar-Dienst von Managed Service for Prometheus.

In diesem Dokument wird Folgendes beschrieben:

Der Sidecar verwendet Google Cloud Managed Service for Prometheus auf der Serverseite und eine Verteilung des OpenTelemetry Collector, der für serverlose Arbeitslasten benutzerdefiniert entwickelt wurde, auf der Clientseite. Diese benutzerdefinierte Distribution enthält einige Änderungen zur Unterstützung von Cloud Run. Der Collector führt nach 10 Sekunden ein Scraping beim Hochfahren durch und führt ein Scraping beim Herunterfahren durch, unabhängig davon, wie kurzlebig die Instanz ist. Für maximale Zuverlässigkeit empfehlen wir, dass Cloud Run-Dienste, die die Sidecar-Datei ausführen, auch eine immer zugewiesene CPU verwenden. Weitere Informationen finden Sie unter CPU-Zuweisung (Dienste). Einige Extraktionsversuche können fehlschlagen, wenn die CPU-Zuweisung aufgrund einer geringen Anzahl von Abfragen pro Sekunde gedrosselt wird. Eine immer zugewiesene CPU bleibt verfügbar.

Der Sidecar verwendet das Cloud Run-Multicontainer-Feature (Sidecar), um den Collector als Sidecar-Container zusammen mit Ihrem Arbeitslastcontainer auszuführen. Weitere Informationen zu Sidecars in Cloud Run finden Sie unter Mehrere Container in einem Dienst bereitstellen (Sidecars).

Mit dem Managed Service for Prometheus-Sidecar für Cloud Run wird die neue Konfiguration RunMonitoring eingeführt, eine Teilmenge der benutzerdefinierten Kubernetes-Ressource PodMonitoring. Die meisten Nutzer können die Standardkonfiguration RunMonitoring verwenden. Sie können aber auch benutzerdefinierte Konfigurationen erstellen. Weitere Informationen zur standardmäßigen und benutzerdefinierten RunMonitoring-Konfiguration finden Sie unter Sidecar-Datei einem Cloud Run-Dienst hinzufügen.

Hinweise

In diesem Abschnitt wird die Einrichtung beschrieben, die für die Verwendung dieses Dokuments erforderlich ist.

gcloud CLI installieren und konfigurieren

Viele der in diesem Dokument beschriebenen Schritte verwenden die Google Cloud CLI. Informationen zur Installation der gcloud CLI finden Sie unter Komponenten der Google Cloud CLI verwalten.

Wenn Sie gcloud-Befehle aufrufen, müssen Sie die ID für Ihr Google Cloud-Projekt angeben. Sie können ein Standardprojekt für die Google Cloud CLI festlegen und müssen es nicht bei jedem Befehl eingeben. Geben Sie den folgenden Befehl ein, um Ihr Projekt als Standardprojekt festzulegen:

gcloud config set project PROJECT_ID

Sie können auch eine Standardregion für Ihren Cloud Run-Dienst festlegen. Geben Sie den folgenden Befehl ein, um eine Standardregion festzulegen:

gcloud config set run/region REGION

APIs aktivieren

Sie müssen in Ihrem Google Cloud-Projekt die folgenden APIs aktivieren:

  • 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
  • (Optional) Wenn Sie eine benutzerdefinierte RunMonitoring-Konfiguration erstellen, müssen Sie die Secret Manager API aktivieren: secretmanager.googleapis.com
  • (Optional) Wenn Sie die Beispielanwendung mit Cloud Build ausführen möchten, müssen Sie auch die folgenden APIs aktivieren:

Führen Sie den folgenden Befehl aus, um die in Ihrem Projekt aktivierten APIs aufzurufen:

gcloud services list

Führen Sie einen der folgenden Befehle aus, um eine nicht aktivierte API zu aktivieren:

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

Dienstkonto für Cloud Run

Cloud Run-Jobs und -Dienste verwenden standardmäßig das Compute Engine-Standarddienstkonto PROJECT_NUMBER-compute@developer.gserviceaccount.com. Dieses Dienstkonto hat normalerweise die IAM-Rollen (Identity and Access Management), die zum Schreiben der in diesem Dokument beschriebenen Messwerte und Logs erforderlich sind:

  • roles/monitoring.metricWriter
  • roles/logging.logWriter

Wenn Sie eine benutzerdefinierte RunMonitoring-Konfiguration erstellen, muss Ihr Dienstkonto auch die folgenden Rollen haben:

  • roles/secretmanager.admin
  • roles/secretmanager.secretAccessor

Sie können auch ein vom Nutzer verwaltetes Dienstkonto für Cloud Run konfigurieren. Ein vom Nutzer verwaltetes Dienstkonto muss auch diese Rollen haben. Weitere Informationen zu Dienstkonten für Cloud Run finden Sie unter Service Identity konfigurieren.

Sidecar-Datei konfigurieren und einem Cloud Run-Dienst hinzufügen

Der Managed Service for Prometheus-Sidecar für Cloud Run führt die neue Konfiguration RunMonitoring ein, die eine Teilmenge der benutzerdefinierten Ressource PodMonitoring von Kubernetes ist. Die RunMonitoring-Konfiguration verwendet vorhandene PodMonitoring-Optionen, um Cloud Run zu unterstützen, während einige für Kubernetes spezifische Optionen entfernt werden.

Sie können die Standardkonfiguration RunMonitoring verwenden oder eine benutzerdefinierte Konfiguration erstellen. In den folgenden Abschnitten werden beide Ansätze beschrieben. Sie müssen nur eine der beiden Optionen ausführen. Weitere Informationen zur Verwendung von Standard- oder benutzerdefinierten Konfigurationen finden Sie auf dem entsprechenden Tab.

Standardkonfiguration

Standardkonfiguration von RunMonitoring verwenden

Wenn Sie keine benutzerdefinierte RunMonitoring-Konfiguration erstellen, synthetisiert der Sidecar-Collector die folgende Standardkonfiguration, um alle 30 Sekunden Messwerte aus Port 8080 im Messwertpfad /metrics zu extrahieren:

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

Die Verwendung der Standardkonfiguration erfordert keine zusätzliche Einrichtung. Sie müssen lediglich die Sidecar-Datei zu Ihrem Cloud Run-Dienst hinzufügen.

Sidecar zu einem Cloud Run-Dienst hinzufügen

Wenn Sie die Sidecar-Datei mit der Standardkonfiguration RunMonitoring verwenden möchten, müssen Sie Ihre vorhandene Cloud Run-Konfiguration ändern, um die Sidecar-Datei hinzuzufügen. So fügen Sie den Sidecar hinzu:

  • Fügen Sie eine Containerabhängigkeits-Annotation hinzu, die die Reihenfolge der Start- und Shutdown-Vorgänge der Container angibt. Im folgenden Beispiel wird der Sidecar-Container namens „collector“ nach dem Anwendungscontainer mit dem Namen „app“ gestartet und vor ihm heruntergefahren.
  • Erstellen Sie im folgenden Beispiel einen Container für den Collector: "collector".

Fügen Sie Ihrer Cloud Run-Konfiguration beispielsweise die Zeilen mit dem vorangestellten +-Zeichen (plus) hinzu und stellen Sie den Dienst dann noch einmal bereit:

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.1.1"
+       name: collector

Führen Sie den folgenden Befehl aus, um den Cloud Run-Dienst mit der Konfigurationsdatei run-service.yaml noch einmal bereitzustellen:

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

Benutzerdefinierte Konfiguration

Benutzerdefinierte RunMonitoring-Konfiguration erstellen

Sie können eine RunMonitoring-Konfiguration für einen Cloud Run-Dienst erstellen, wenn die Standardkonfiguration nicht ausreicht. Sehen Sie sich diese Beispielkonfiguration an:

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

Diese Konfiguration tut Folgendes:

  • Extrahiert Messwerte aus dem Port 8080 und verwendet den Standardmesswertpfad /metrics.
  • Verwendet ein Extraktionsintervall von 10 Sekunden.
  • Verwendet Relabeling, um jedem extrahierten Messwert das Label label_key mit dem Wert label_value hinzuzufügen.
  • Fügt jedem extrahierten Messwert die Metadatenlabels service und revision hinzu.

Informationen zu den verfügbaren Konfigurationsoptionen finden Sie unter RunMonitoring-Spezifikation: Konfigurationsoptionen.

Wenn Sie eine benutzerdefinierte RunMonitoring-Konfiguration verwenden, müssen Sie die folgende zusätzliche Konfiguration vornehmen:

Konfiguration mit Secret Manager speichern

So stellen Sie eine benutzerdefinierte RunMonitoring-Konfiguration bereit:

  • Erstellen Sie eine Datei, die die benutzerdefinierte Konfiguration enthält.
  • Erstellen Sie ein Secret Manager-Secret, das die benutzerdefinierte Konfiguration enthält.

Mit dem folgenden Befehl wird ein Secret mit dem Namen mysecret aus der Datei custom-config.yaml erstellt:

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

Wenn Sie nach dem Ändern der Datei custom-config.yaml eine Änderung an der Konfiguration übernehmen möchten, müssen Sie das Secret löschen und neu erstellen und dann den Cloud Run-Dienst noch einmal bereitstellen.

Konfiguration in Secret Manager aktualisieren

Wenn Sie die benutzerdefinierte RunMonitoring-Konfiguration jederzeit aktualisieren möchten, können Sie eine neue Version des vorhandenen Secrets zu Secret Manager hinzufügen.

Wenn Sie beispielsweise mysecret mit einer neuen in der Datei custom-config-updated.yaml gespeicherten Konfiguration aktualisieren möchten, können Sie Folgendes ausführen:

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

Die Sidecar-Datei wird automatisch neu geladen und wendet die Änderungen auf ihre Konfiguration an.

Sidecar zu einem Cloud Run-Dienst hinzufügen

Nachdem Sie ein Secret Manager-Secret für Ihre RunMonitoring-Konfiguration erstellt haben, müssen Sie die Cloud Run-Konfiguration so ändern:

  • Managed Service for Prometheus-Sidecar hinzufügen
    • Fügen Sie eine Containerabhängigkeits-Annotation hinzu, die die Reihenfolge der Start- und Shutdown-Vorgänge der Container angibt. Im folgenden Beispiel wird der Sidecar-Container namens „collector“ nach dem Anwendungscontainer mit dem Namen „app“ gestartet und vor ihm heruntergefahren.
    • Erstellen Sie im folgenden Beispiel einen Container für den Collector: "collector".
  • Fügen Sie das Secret hinzu, indem Sie das Secret am Standort /etc/rungmp/config.yaml bereitstellen:
    • Fügen Sie eine Secret-Annotation hinzu, die auf das Secret verweist, das Ihre benutzerdefinierte RunMonitoring-Konfiguration enthält.
    • Erstellen Sie im folgenden Beispiel ein Volume mit dem Namen "config" für das Secret, das auf die Datei config.yaml verweist.
    • Stellen Sie das Volume als Teil des Collector-Images unter dem Bereitstellungspfad /etc/rungmp bereit.

Fügen Sie Ihrer Cloud Run-Konfiguration beispielsweise die Zeilen mit dem vorangestellten +-Zeichen (plus) hinzu und stellen Sie den Dienst dann noch einmal bereit:

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.1.1"
+       name: collector
+       volumeMounts:
+       - mountPath: /etc/rungmp/
+         name: config
+     volumes:
+     - name: config
+       secret:
+         items:
+         - key: latest
+           path: config.yaml
+         secretName: 'mysecret'

Führen Sie den folgenden Befehl aus, um den Cloud Run-Dienst mit der Konfigurationsdatei run-service.yaml noch einmal bereitzustellen:

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

RunMonitoring-Spezifikation: Konfigurationsoptionen

In diesem Abschnitt wird die Konfigurationsspezifikation RunMonitoring für den Sidecar für Managed Service for Prometheus beschrieben. Das folgende Beispiel zeigt eine benutzerdefinierte Konfiguration:

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

Die Konfiguration RunMonitoring überwacht einen Cloud Run-Dienst.

Feld Beschreibung Schema Erforderlich
metadata Metadaten, die alle persistenten Ressourcen enthalten müssen. metav1.ObjectMeta falsch
spec Spezifikation der Cloud Run-Bereitstellung, die für die Zielerkennung durch Prometheus ausgewählt wurde. RunMonitoringSpec wahr
RunMonitoringSpec

Diese Spezifikation beschreibt, wie die Konfiguration RunMonitoring einen Cloud Run-Dienst überwacht.

Feld Beschreibung Schema Erforderlich
endpoints Endpunkte zur Extraktion auf den ausgewählten Pods. []ScrapeEndpoint wahr
targetLabels Labels, die dem Prometheus-Ziel für erkannte Endpunkte hinzugefügt werden sollen. Das Label instance ist immer auf die Instanz-ID von Cloud Run festgelegt. RunTargetLabels falsch
limits Limits zum Anwenden zum Scraping-Zeitpunkt. *ScrapeLimits falsch
RunTargetLabels

Mit der Konfiguration RunTargetLabels können Sie Cloud Run-Labels aus den erkannten Prometheus-Zielen einschließen.

Feld Beschreibung Schema Erforderlich
metadata Cloud Run-Metadatenlabels, die für alle extrahierten Ziele festgelegt sind.

Zulässige Schlüssel sind instance, revision, service und configuration.

Wenn zulässige Schlüssel festgelegt sind, fügt die Sidecar-Datei zu jedem Messwert den entsprechenden Wert aus der Cloud Run-Instanz als Messwertlabels hinzu: instanceID, revision_name, service_name und configuration_name.

Standardmäßig werden alle zulässigen Schlüssel festgelegt.
*[]string falsch

Beispiel-App erstellen und ausführen

In diesem Abschnitt wird beschrieben, wie Sie den Managed Service for Prometheus-Sidecar mit einer Beispielanwendung ausführen. Dieser Abschnitt ist optional. Wenn Sie bereits einen Cloud Run-Dienst haben und den Sidecar mit diesem bereitstellen möchten, finden Sie weitere Informationen unter Managed Service for Prometheus-Sidecar zu einem Cloud Run-Dienst hinzufügen.

run-gmp-sidecar-Repository klonen

Klonen Sie das Repository run-gmp-sidecar mit dem folgenden Befehl, um die Beispielanwendung und ihre Konfigurationsdateien abzurufen:

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

Wechseln Sie nach dem Klonen des Repositorys zum Verzeichnis run-gmp-sidecar:

cd run-gmp-sidecar

Beispiel-App erstellen und ausführen

Die Beispielanwendung erfordert Docker oder ein ähnliches Container-Build-System für Linux. Sie können die Beispielanwendung auf eine der folgenden Arten erstellen und ausführen:

  • Führen Sie Cloud Build ohne lokale Docker-Unterstützung aus. Wenn Sie Cloud Build verwenden, müssen Sie auch die Cloud Build API aktivieren.
  • Beispiel-App manuell erstellen und ausführen

In den folgenden Abschnitten werden beide Ansätze beschrieben. Sie müssen nur eine der beiden Optionen ausführen. Weitere Informationen erhalten Sie über den Tab für einen dieser Ansätze.

Cloud Build verwenden

Cloud Build verwenden

Das Repository run-gmp-sidecar enthält Konfigurationsdateien für Cloud Build. Diese Dateien fassen die Schritte zum Erstellen und Bereitstellen der Beispielanwendung zusammen.

Sie können die von Cloud Build verarbeiteten Schritte auch manuell ausführen. Weitere Informationen finden Sie unter Manuell erstellen und ausführen.

Für Cloud Build einrichten

Für diese Konfigurationsdateien sind ein Cloud Build-Dienstkonto und ein Artifact Registry-Repository erforderlich. Das run-gmp-sidecar-Repository enthält auch ein Skript, create-sa-and-ar.sh, das Folgendes ausführt:

  • Erstellt das Dienstkonto run-gmp-sa@PROJECT_ID.iam.gserviceaccount.com.
  • Weist dem Dienstkonto die folgenden Rollen zu:
      .
    • roles/iam.serviceAccountUser
    • roles/storage.objectViewer
    • roles/logging.logWriter
    • roles/artifactregistry.createOnPushWriter
    • roles/secretmanager.admin
    • roles/secretmanager.secretAccessor
    • roles/run.admin
  • Erstellt ein Artifact Registry-Repository, run-gmp, für Ihre Container-Images.

Führen Sie den folgenden Befehl aus, um das Dienstkonto run-gmp-sa und das Repository run-gmp zu erstellen:

./create-sa-and-ar.sh

Es dauert einige Zeit, bis die Berechtigungen wirksam werden. Daher empfehlen wir, etwa 30 Sekunden zu warten, bevor Sie mit dem nächsten Schritt fortfahren. Andernfalls werden möglicherweise Autorisierungsfehler angezeigt.

Cloud Build-Anfrage senden

Nachdem Sie das Dienstkonto run-gmp-sa und das Repository run-gmp eingerichtet haben, können Sie einen Cloud Build-Job starten. Senden Sie dazu die Cloud Build-Konfigurationsdatei. Sie können den folgenden gcloud builds submit-Befehl verwenden:

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

Die Ausführung dieses Befehls kann mehrere Minuten dauern. Er gibt jedoch fast sofort an, wo Sie die Build-Details von Cloud Build finden. Die Nachricht sieht so aus:

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

Rufen Sie die zurückgegebene URL im Browser auf, um den Fortschritt des Builds zu beobachten. Sie können auch die Sidecar-Logs in Cloud Logging aufrufen.

Dienst-URL prüfen

Prüfen Sie nach dem Ende des Cloud Build-Jobs die Endpunkt-URL des Cloud Run-Dienstes. Führen Sie dazu den folgenden Befehl aus:

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

Dieser Befehl gibt die Dienst-URL zurück, die so aussieht:

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

Verwenden Sie die zurückgegebene URL als Wert von SERVICE_URL im Abschnitt Prüfen, ob die Anwendung ausgeführt wird.

Manuell erstellen und ausführen

Manuell erstellen und ausführen

Sie können die von Cloud Build verarbeiteten Schritte manuell ausführen. Weitere Informationen dazu finden Sie unter Cloud Build verwenden. In den folgenden Abschnitten wird beschrieben, wie Sie dieselben Aufgaben manuell ausführen.

In späteren Schritten verwendete Variablen festlegen

In einigen der späteren Schritte werden Umgebungsvariablen für gängige Werte verwendet. Richten Sie diese Variablen mit den folgenden Befehlen ein:

export GCP_PROJECT=PROJECT_ID
export REGION=REGION

Container-Image-Repository erstellen

Erstellen Sie ein Artifact Registry-Repository für das Container-Image, indem Sie den folgenden Befehl ausführen:

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

Beispiel-App erstellen und per Push übertragen

In diesem Beispiel wird mit Docker unter Linux die Beispielanwendung erstellt und in ein Artifact Registry-Repository übertragen. Wenn Sie in einer Windows- oder macOS-Umgebung arbeiten, müssen Sie diese Befehle möglicherweise anpassen.

So erstellen Sie die Beispielanwendung und übertragen sie per Push in Artifact Registry:

  1. Authentifizieren Sie Ihren Docker-Client bei der Google Cloud CLI:

    gcloud auth configure-docker ${REGION}-docker.pkg.dev
    
  2. Wechseln Sie im Repository run-gmp-sidecar zum Verzeichnis simple-app:

    pushd sample-apps/simple-app
    

  3. Erstellen Sie mit dem folgenden Befehl die Anwendung simple-app:

    docker build -t ${REGION}-docker.pkg.dev/${GCP_PROJECT}/run-gmp/sample-app .
    
  4. Laden Sie das Image für die erstellte Anwendung mit dem folgenden Befehl hoch:

    docker push ${REGION}-docker.pkg.dev/${GCP_PROJECT}/run-gmp/sample-app
    

  5. Kehren Sie zum Verzeichnis run-gmp-sidecar zurück:

    popd
    

Cloud Run-Dienst konfigurieren

Die Datei run-service-simple.yaml im Repository run-gmp-sidecar definiert einen Cloud Run-Dienst mit mehreren Containern, der die Beispielanwendung und Collector-Images verwendet, die Sie in den vorherigen Schritten erstellt haben. Die Datei run-service-simple.yaml enthält die folgende Dienstspezifikation:

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.1.1"
        name: collector

Diese Datei enthält einen Platzhalterwert für die Images, die Sie in den vorherigen Schritten erstellt haben. Daher müssen Sie die Platzhalter mit den tatsächlichen Werten für Ihr Google Cloud-Projekt aktualisieren.

Ersetzen Sie den Platzhalter %SAMPLE_APP_IMAGE% mit dem folgenden Befehl:

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

Cloud Run-Dienst bereitstellen

Nachdem Sie die Datei run-service-simple.yaml mit Ihren Werten aktualisiert haben, können Sie den Cloud Run-Dienst mit dem folgenden Befehl erstellen und bereitstellen:

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

Dieser Befehl gibt die Dienst-URL zurück, die so aussieht:

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

Verwenden Sie die zurückgegebene URL als Wert von SERVICE_URL im Abschnitt Prüfen, ob die Anwendung ausgeführt wird.

Nicht authentifizierten HTTP-Zugriff zulassen

Bevor Sie eine Anfrage an die Dienst-URL senden können, müssen Sie die Cloud Run-Dienstrichtlinie ändern, um den nicht authentifizierten HTTP-Zugriff zu akzeptieren. Die Datei policy.yaml im Repository run-gmp-sidecar enthält die erforderliche Änderung.

Führen Sie den folgenden Befehl aus, um die Dienstrichtlinie zu ändern:

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

Prüfen, ob Ihre Anwendung ausgeführt wird

Wenn Sie prüfen möchten, ob der Cloud Run-Dienst die Beispielanwendung korrekt ausgeführt hat, verwenden Sie das Dienstprogramm curl für den Zugriff auf den Endpunkt metrics des Dienstes.

  1. Legen Sie die Umgebungsvariable SERVICE_URL auf die Cloud Run-Dienst-URL aus dem vorherigen Schritt fest:

    export SERVICE_URL=SERVICE_URL
    
  2. Senden Sie mit dem folgenden Befehl eine Anfrage an die Dienst-URL:

    curl $SERVICE_URL
    

Wenn Ihre Anwendung erfolgreich gestartet wurde, sehen Sie die folgende Antwort:

User request received!

Anwendungsmesswerte im Metrics Explorer aufrufen

Der Beispielcontainer app schreibt die folgenden Messwerte:

  • foo_metric: Die aktuelle Zeit als Gleitkommawert (Messgerät).
  • bar_metric: Die aktuelle Zeit als Gleitkommawert (Zähler).

So rufen Sie diese Messwerte im Metrics Explorer auf:

  1. Wählen Sie im Navigationsbereich der Google Cloud Console Monitoring und anschließend  Metrics Explorer aus:

    Zum Metrics Explorer

  2. Klicken Sie in der Symbolleiste des Bereichs "Query Builder" auf die Schaltfläche  MQL oder  PromQL.

  3. Prüfen Sie, ob PromQL in der Ein-/Aus-Schaltfläche Sprache ausgewählt ist. Die Sprachschaltfläche befindet sich in derselben Symbolleiste, mit der Sie Ihre Abfrage formatieren können.

  4. Geben Sie in den Editorbereich die folgende Abfrage ein:

    foo_metric
    
  5. Klicken Sie auf Abfrage hinzufügen.

  6. Klicken Sie in der Symbolleiste des Bereichs "Query Builder" auf die Schaltfläche  MQL oder  PromQL.

  7. Prüfen Sie, ob PromQL in der Ein-/Aus-Schaltfläche Sprache ausgewählt ist. Die Sprachschaltfläche befindet sich in derselben Symbolleiste, mit der Sie Ihre Abfrage formatieren können.

  8. Geben Sie in den zweiten Editorbereich die folgende Abfrage ein:

    bar_metric
    
  9. Klicken Sie auf Abfrage ausführen.

  10. Wenn Sie Details zu den Messwerten abrufen möchten, wählen Sie in der Schaltfläche Diagrammtabelle beides die Option Beide aus.

Bereinigen

Wenn Sie mit dem Testen der Beispielanwendung fertig sind, können Sie das Skript clean-up-cloud-run.sh im Repository run-gmp-sidecar verwenden, um die folgenden Ressourcen zu löschen, die Sie möglicherweise für das Beispiel erstellt haben:

  • Der Cloud Run-Dienst.
  • Artifact Registry-Repository
  • Das für Cloud Build erstellte Dienstkonto.

Durch das Löschen dieser Ressourcen fallen nach der Ausführung des Beispiels keine Kosten an.

Führen Sie das Skript clean-up-cloud-run.sh aus, um die Beispielanwendung zu bereinigen:

./clean-up-cloud-run.sh

Eigene Messwerte im Metrics Explorer aufrufen

Die Sidecar-Datei von Managed Service for Prometheus meldet folgende Messwerte über sich selbst an Cloud Monitoring:

  • agent_uptime: Die Verfügbarkeit des Sidecar-Collectors (Zähler).
  • agent_memory_usage: Der vom Sidecar-Collector erfasste Arbeitsspeicher (Messgerät).
  • agent_api_request_count: Die Anzahl der API-Anfragen vom Sidecar-Collector (Zähler).
  • agent_monitoring_point_count: Die Anzahl der Messwertpunkte, die vom Sidecar-Collector in Cloud Monitoring geschrieben werden (Zähler).

So rufen Sie die eigenen Messwerte der Sidecar-Datei im Metrics Explorer auf:

  1. Wählen Sie im Navigationsbereich der Google Cloud Console Monitoring und anschließend  Metrics Explorer aus:

    Zum Metrics Explorer

  2. Klicken Sie in der Symbolleiste des Bereichs "Query Builder" auf die Schaltfläche  MQL oder  PromQL.

  3. Prüfen Sie, ob PromQL in der Ein-/Aus-Schaltfläche Sprache ausgewählt ist. Die Sprachschaltfläche befindet sich in derselben Symbolleiste, mit der Sie Ihre Abfrage formatieren können.

  4. Geben Sie den Namen des abzufragenden Messwerts in den Editorbereich ein. Beispiel:

    agent_api_request_count
    
  5. Klicken Sie auf Abfrage ausführen.

  6. Wenn Sie Details zu den Messwerten abrufen möchten, wählen Sie in der Schaltfläche Diagrammtabelle beides die Option Beide aus.

Eigene Logs im Log-Explorer ansehen

Die Sidecar-Datei des Managed Service for Prometheus schreibt Logs in Cloud Logging. Die Sidecar-Datei schreibt Logs in den überwachten Logging-Ressourcentyp cloud_run_revision.

So rufen Sie die Logs der Sidecar-Datei im Log-Explorer auf:

  1. Wählen Sie im Navigationsbereich der Google Cloud Console Logging und anschließend Log-Explorer aus:

    Zum Log-Explorer

  2. Wählen Sie den Ressourcentyp Cloud Run Revision aus oder geben Sie die folgende Abfrage ein und klicken Sie auf Abfrage ausführen:

    resource.type="cloud_run_revision"
    

Informationen zu den erfassten Messwerten

Wenn die vom Sidecar ausgegebenen Messwerte in Cloud Monitoring aufgenommen werden, werden die Messwerte im überwachten Cloud Monitoring-Ressourcentyp prometheus_target geschrieben. Dieser Ressourcentyp wird sowohl für Anwendungsmesswerte als auch für die Self-Messwerte der Sidecar-Datei verwendet.

Beim Schreiben der Messwerte legt die Sidecar-Datei die Ressourcenlabels so fest:

  • project_id ist die ID des Google Cloud-Projekts, in dem der Container ausgeführt wird.
  • location: Die Google Cloud-Region, in der der Container ausgeführt wird.
  • cluster: Der Wert __run__.
  • namespace: Der Name des ausgeführten Cloud Run-Dienstes; stammt aus der Umgebungsvariable K_SERVICE.
  • job: Name aus der RunMonitoring-Konfiguration; Der Standardwert ist run-gmp-sidecar.
  • instance: Der Wert faas.ID:PORT der lokalen Arbeitslast, aus der der Container zum Abrufen von Messwerten konfiguriert ist. Der Wert faas.ID ist die Instanz-ID der Cloud Run-Instanz.

Die Sidecar-Datei fügt die folgenden Messwertlabels hinzu:

  • instanceId: Die ID der Cloud Run-Instanz.
  • service_name: Der Name des ausgeführten Cloud Run-Dienstes.
  • revision_name: Der Name der ausgeführten Cloud Run-Überarbeitung.
  • configuration_name: Der Name der ausgeführten Cloud Run-Konfiguration.

Diese Messwertlabels werden standardmäßig hinzugefügt. Wenn Sie eine benutzerdefinierte RunMonitoring-Konfiguration verwenden, können Sie diese Labels mit der Option targetLabels in der RunMonitoring-Spezifikation weglassen. Sie können auch eine benutzerdefinierte Konfiguration verwenden, um jedes dieser Messwertlabels außer instanceId neu zu benennen.

Alle anderen Labels, die mit aufgenommenen Messwerten angezeigt werden, stammen aus dem Messwert des Nutzers. Wenn ein benutzerdefiniertes Label mit einem der vom System bereitgestellten Labels in Konflikt steht, wird dem benutzerdefinierten Label der String exported_ vorangestellt. Beispiel: Ein benutzerdefiniertes Label namespace=playground steht in Konflikt mit dem systemdefinierten Label namespace, sodass das Nutzerlabel exported_namespace=playground lautet.

Messwerttyp

Wenn die vom Sidecar ausgegebenen Messwerte in Cloud Monitoring aufgenommen werden, werden die Messwerte als prometheus.googleapis.com-Messwerte geschrieben und der Typ des Prometheus-Messwerts wird an das Ende des Namens angehängt. Die Beispielanwendung gibt beispielsweise einen Prometheus-Messwert mit dem Namen foo_metric aus. In Cloud Monitoring wird der Messwert als Messwerttyp prometheus.googleapis.com/foo_metric/gauge gespeichert.

Wenn Sie den Messwert mit PromQL abfragen, können Sie den Prometheus-Namen verwenden, wie unter Anwendungsmesswerte in Metrics Explorer ansehen und Eigene Messwerte im Metrics Explorer ansehen dargestellt. Wenn Sie Tools wie Query Builder oder Monitoring Query Language (MQL) im Metrics Explorer verwenden, ist der Messwerttyp von Cloud Monitoring relevant.

Abrechnung

Von der Sidecar-Datei ausgegebene Messwerte werden in Cloud Monitoring mit dem Präfix prometheus.googleapis.com aufgenommen. Messwerte mit diesem Präfix werden nach der Anzahl der aufgenommenen Stichproben berechnet. Weitere Informationen zur Abrechnung und zu Managed Service for Prometheus finden Sie unter Abrechnung.