Prometheus-Sidecar für Cloud Run verwenden

Der Managed Service for Prometheus-Sidecar für Cloud Run ist die von Google empfohlene Methode, um Monitoring im Prometheus-Stil für Cloud Run-Dienste zu erhalten. Wenn Ihr Cloud Run-Dienst OTLP-Messwerte schreibt, können Sie den OpenTelemetry-Sidecar verwenden. Für Dienste, die Prometheus-Messwerte schreiben, verwenden Sie jedoch den in diesem Dokument beschriebenen Sidecar für 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 Scraping-Versuche können fehlschlagen, wenn die CPU-Zuweisung aufgrund einer geringen Anzahl von Abfragen pro Sekunde (Queries per Second, QPS) gedrosselt wird. Eine immer zugewiesene CPU bleibt verfügbar.

Der Sidecar nutzt die Cloud Run-Multicontainer-Funktion (Sidecar), um den Collector als Sidecar-Container neben Ihrem Arbeitslastcontainer auszuführen. Weitere Informationen zu Sidecars in Cloud Run finden Sie unter Mehrere Container in einem Dienst bereitstellen (Sidecars).

Mit dem Sidecar des verwalteten Prometheus-Dienstes für Cloud Run wird eine neue Konfiguration namens RunMonitoring eingeführt, die eine Teilmenge der benutzerdefinierten Kubernetes-Ressource PodMonitoring ist. Die meisten Nutzer können die Standardkonfiguration RunMonitoring verwenden. Sie können aber auch benutzerdefinierte Konfigurationen erstellen. Weitere Informationen zu den Standard- und benutzerdefinierten RunMonitoring-Konfigurationen finden Sie unter Sidecar 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

Für viele der in diesem Dokument beschriebenen Schritte wird die Google Cloud CLI verwendet. Informationen zur Installation der gcloud CLI finden Sie unter Komponenten der Google Cloud CLI verwalten.

Wenn Sie gcloud-Befehle aufrufen, müssen Sie die Kennung 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 Beispiel-App 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 in der Regel die IAM-Rollen (Identity and Access Management), die zum Schreiben der in diesem Dokument beschriebenen Messwerte und Protokolle 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 nutzerverwaltetes 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 konfigurieren und einem Cloud Run-Dienst hinzufügen

Mit dem Sidecar des verwalteten Dienstes für Prometheus für Cloud Run wird eine neue Konfiguration namens RunMonitoring eingeführt. Diese ist eine Teilmenge der benutzerdefinierten Kubernetes-Ressource PodMonitoring. In der RunMonitoring-Konfiguration werden vorhandene PodMonitoring-Optionen verwendet, um Cloud Run zu unterstützen. Einige Optionen, die nur für Kubernetes gelten, werden jedoch nicht unterstützt.

Sie können die Standardkonfiguration von 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. Wählen Sie den entsprechenden Tab aus, um weitere Informationen zur Verwendung von Standard- oder benutzerdefinierten Konfigurationen zu erhalten.

Standardkonfiguration

Standardkonfiguration für RunMonitoring verwenden

Wenn Sie keine benutzerdefinierte RunMonitoring-Konfiguration erstellen, synthetisiert der Sidecar-Collector die folgende Standardkonfiguration, um alle 30 Sekunden Messwerte von Port 8080 unter dem Pfad /metrics zu erfassen:

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 von 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 Anmerkung zu Containerabhängigkeiten hinzu, in der die Start- und Stoppreihenfolge der Container angegeben ist. Im folgenden Beispiel wird der Sidecar-Container namens „collector“ nach dem Anwendungscontainer mit dem Namen „app“ gestartet und vor ihm heruntergefahren.
  • Erstellen Sie einen Container für den Collector, der im folgenden Beispiel „collector“ heißt.

Fügen Sie beispielsweise Ihrer Cloud Run-Konfiguration die Zeilen hinzu, denen das Zeichen + (Pluszeichen) vorangestellt ist, und stellen Sie den Dienst dann neu 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.2.0"
+       name: collector

Führen Sie den folgenden Befehl aus, um den Cloud Run-Dienst mit der Konfigurationsdatei run-service.yaml neu 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 hat folgende Auswirkungen:

  • Er liest Messwerte von Port 8080 und verwendet den Standardpfad für Messwerte /metrics.
  • Es wird ein 10-Sekunden-Extraktionsintervall verwendet.
  • 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 ausführen:

Konfiguration mit Secret Manager speichern

So geben Sie eine benutzerdefinierte RunMonitoring-Konfiguration an:

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

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

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

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

Konfiguration in Secret Manager aktualisieren

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

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

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

Der Sidecar wird automatisch neu geladen und die Änderungen werden auf die Konfiguration angewendet.

Sidecar zu einem Cloud Run-Dienst hinzufügen

Nachdem Sie ein Secret Manager-Secret für Ihre RunMonitoring-Konfiguration erstellt haben, müssen Sie Ihre Cloud Run-Konfiguration so ändern, dass Folgendes möglich ist:

  • Sidecar für Managed Service for Prometheus hinzufügen
    • Fügen Sie eine Anmerkung zu Containerabhängigkeiten hinzu, in der die Start- und Stoppreihenfolge der Container angegeben ist. Im folgenden Beispiel wird der Sidecar-Container namens „collector“ nach dem Anwendungscontainer mit dem Namen „app“ gestartet und vor ihm heruntergefahren.
    • Erstellen Sie einen Container für den Collector, der im folgenden Beispiel „collector“ heißt.
  • Fügen Sie das Secret hinzu, indem Sie es an dem Speicherort /etc/rungmp/config.yaml bereitstellen:
    • Fügen Sie eine Secrets-Anmerkung hinzu, die auf das Secret verweist, das Ihre benutzerdefinierte RunMonitoring-Konfiguration enthält.
    • Erstellen Sie 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 beispielsweise Ihrer Cloud Run-Konfiguration die Zeilen hinzu, denen das Zeichen + (Pluszeichen) vorangestellt ist, und stellen Sie den Dienst dann neu 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.2.0"
+       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 neu bereitzustellen:

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

RunMonitoring-Spezifikation: Konfigurationsoptionen

In diesem Abschnitt wird die RunMonitoring-Konfigurationsspezifikation für den Sidecar von 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 RunMonitoring-Konfiguration überwacht einen Cloud Run-Dienst.

Feld Beschreibung Schema Erforderlich
metadata Metadaten, die alle gespeicherten Ressourcen haben müssen. metav1.ObjectMeta false
spec Angabe der Cloud Run-Bereitstellung, die von Prometheus für die Zielerkennung ausgewählt wurde. RunMonitoringSpec true
RunMonitoringSpec

In dieser Spezifikation wird beschrieben, wie ein Cloud Run-Dienst mit der RunMonitoring-Konfiguration überwacht wird.

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

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

Feld Beschreibung Schema Erforderlich
metadata Cloud Run-Metadatenlabels, die für alle gescrapten 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 false

Beispielanwendung erstellen und ausführen

In diesem Abschnitt wird beschrieben, wie Sie das Sidecar von Managed Service for Prometheus 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

Wenn Sie die Beispielanwendung und ihre Konfigurationsdateien abrufen möchten, klonen Sie das run-gmp-sidecar-Repository mit dem folgenden Befehl:

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

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

cd run-gmp-sidecar

Beispielanwendung erstellen und ausführen

Für die Beispielanwendung ist Docker oder ein ähnliches Container-Build-System für Linux erforderlich. Sie haben folgende Möglichkeiten, die Beispiel-App zu erstellen und auszuführen:

  • Cloud Build verwenden, um ohne lokale Docker-Unterstützung auszuführen Wenn Sie Cloud Build verwenden, müssen Sie auch die Cloud Build API aktivieren.
  • Erstellen Sie die Beispielanwendung manuell und führen Sie sie aus.

In den folgenden Abschnitten werden beide Ansätze beschrieben. Sie müssen nur eine der beiden Optionen ausführen. Wählen Sie den Tab für einen der Ansätze aus, um weitere Informationen zu erhalten.

Cloud Build verwenden

Cloud Build verwenden

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

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 außerdem ein Script, create-sa-and-ar.sh, das Folgendes tut:

  • 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 run-gmp-sa-Dienstkonto und das run-gmp-Repository zu erstellen:

./create-sa-and-ar.sh

Es dauert einige Zeit, bis die Berechtigungen übernommen werden. Wir empfehlen, etwa 30 Sekunden zu warten, bevor Sie mit dem nächsten Schritt fortfahren. Andernfalls können Autorisierungsfehler auftreten.

Cloud Build-Antrag senden

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

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

Die Ausführung dieses Befehls dauert einige Minuten. Sie erfahren jedoch fast sofort, wo Sie die Cloud Build-Build-Details finden. Die Meldung sieht in etwa 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 in Ihrem Browser auf, um den Fortschritt des Builds zu verfolgen. Sie können sich die Sidecar-Logs auch in Cloud Logging ansehen.

Dienst-URL prüfen

Prüfen Sie nach Abschluss des Cloud Build-Jobs die Cloud Run-Dienstendpunkt-URL mit dem folgenden Befehl:

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 für SERVICE_URL im Abschnitt Prüfen, ob Ihre App 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, wie unter Cloud Build verwenden beschrieben. In den folgenden Abschnitten wird beschrieben, wie Sie dieselben Aufgaben manuell ausführen.

Variablen für spätere Schritte festlegen

In einigen der nachfolgenden Schritte werden Umgebungsvariablen für gängige Werte verwendet. Legen Sie diese Variablen mit den folgenden Befehlen fest:

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 die Artifact Registry:

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

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

    pushd sample-apps/simple-app
    

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

    docker build -t ${REGION}-docker.pkg.dev/${GCP_PROJECT}/run-gmp/sample-app .
    
  4. Übertragen Sie das Image für die erstellte App per Push mit dem folgenden Befehl:

    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

In der Datei run-service-simple.yaml im Repository run-gmp-sidecar wird ein Cloud Run-Dienst mit mehreren Containern definiert, der die Beispiel-App und die 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.2.0"
        name: collector

Diese Datei enthält einen Platzhalterwert für die Images, die Sie in den vorherigen Schritten erstellt haben. Sie müssen die Platzhalter daher 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 für SERVICE_URL im Abschnitt Prüfen, ob Ihre App 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 so ändern, dass nicht authentifizierter HTTP-Zugriff zulässig ist. 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

Um zu prüfen, ob der Cloud Run-Dienst die Beispiel-App korrekt ausgeführt hat, greifen Sie mit dem Dienstprogramm curl auf den Endpunkt metrics des Dienstes zu.

  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 eine Anfrage an die Dienst-URL. Führen Sie dazu den folgenden Befehl aus:

    curl $SERVICE_URL
    

Wenn Ihre App gestartet wurde, sehen Sie die folgende Antwort:

User request received!

App-Messwerte im Metrics Explorer aufrufen

Der Beispielcontainer app schreibt die folgenden Messwerte:

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

So rufen Sie diese Messwerte im Metrics Explorer auf:

  1. Rufen Sie in der Google Cloud Console die Seite Metrics Explorer auf.

    Zum Metrics Explorer

    Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Monitoring ist.

  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 PromQL ausgewählt ist. Die Sprachschaltfläche befindet sich in derselben Symbolleiste, mit der Sie Ihre Abfrage formatieren können.

  4. Geben Sie die folgende Abfrage in den Editor 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 PromQL 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 sehen möchten, wählen Sie auf der Schaltfläche Diagramm Tabelle Beides Beides aus.

Bereinigen

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

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

Wenn Sie diese Ressourcen löschen, entstehen Ihnen nach dem Ausführen der Stichprobe keine Kosten.

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

./clean-up-cloud-run.sh

Eigene Messwerte im Metrics Explorer aufrufen

Der Managed Service for Prometheus-Sidecar meldet die folgenden Messwerte zu sich selbst an Cloud Monitoring:

  • agent_uptime: Die Uptime 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. Rufen Sie in der Google Cloud Console die Seite Metrics Explorer auf.

    Zum Metrics Explorer

    Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Monitoring ist.

  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 PromQL 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 Messwerts, den Sie abfragen möchten, in den Editorbereich ein. Beispiel:

    agent_api_request_count
    
  5. Klicken Sie auf Abfrage ausführen.

  6. Wenn Sie Details zu den Messwerten sehen möchten, wählen Sie auf der Schaltfläche Diagramm Tabelle Beides Beides aus.

Eigene Logs im Log-Explorer ansehen

Der Sidecar von Managed Service for Prometheus schreibt Protokolle in Cloud Logging. Der Sidecar schreibt Protokolle für den überwachten Ressourcentyp „Logging“ cloud_run_revision.

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

  1. Rufen Sie in der Google Cloud Console die Seite Log-Explorer auf.

    Zum Log-Explorer

    Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Logging ist.

  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"
    

Erfasste Messwerte

Wenn die vom Sidecar gesendeten Messwerte in Cloud Monitoring aufgenommen werden, werden sie dem überwachten Ressourcentyp prometheus_target zugeordnet. Dieser Ressourcentyp wird sowohl für Anwendungsmesswerte als auch für die Selbstmesswerte des Sidecars verwendet.

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

  • project_id: 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. Wird aus der Umgebungsvariablen K_SERVICE abgerufen.
  • job: Name aus der RunMonitoring-Konfiguration; Der Standardwert ist run-gmp-sidecar.
  • instance: Der Wert faas.ID:PORT der lokalen Arbeitslast, von der der Container konfiguriert ist, um Messwerte abzurufen. Der Wert faas.ID ist die Instanz-ID der Cloud Run-Instanz.

Außerdem werden die folgenden Messwertlabels hinzugefügt:

  • 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 alle standardmäßig hinzugefügt. Wenn Sie eine benutzerdefinierte RunMonitoring-Konfiguration verwenden, können Sie die Labels service_name, revision_name und configuration_name mithilfe der Option targetLabels in der Spezifikation RunMonitoring. Sie können auch eine benutzerdefinierte Konfiguration verwenden, um die Werte der Labels service_name, revision_name und configuration_name neu zu benennen.

Alle anderen Labels, die bei aufgenommenen Messwerten angezeigt werden, stammen aus Ihrem Messwert. Wenn ein benutzerdefiniertes Label mit einem der vom System bereitgestellten Labels in Konflikt steht, wird dem benutzerdefinierten Label der String exported_ vorangestellt. Wenn beispielsweise ein vom Nutzer angegebenes Label namespace="playground" mit dem systemdefinierten Label namespace in Konflikt steht, wird das Nutzerlabel als exported_namespace="playground" angezeigt.

Messwerttyp

Wenn die vom Sidecar gesendeten Messwerte in Cloud Monitoring aufgenommen werden, werden sie 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 vom Typ „Greif“ 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 den Abfragebaustein oder die Monitoring Query Language (MQL) im Metrics Explorer verwenden, ist der Cloud Monitoring-Messwerttyp relevant.

Abrechnung

Vom Sidecar ausgestellte 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.