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 Managed Service for Prometheus-Sidecar.
In diesem Dokument wird Folgendes beschrieben:
- Fügen Sie einem vorhandenen Cloud Run-Dienst den Managed Service for Prometheus-Sidecar hinzu.
- Erstellen Sie eine Beispiel-App mit dem Sidecar. Wenn Sie keinen Cloud Run-Dienst haben, können Sie anhand der Beispiel-App sehen, wie der Sidecar funktioniert.
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 Verteilung 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 Managed Service for Prometheus-Sidecar 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:
- Cloud Build API:
cloudbuild.googleapis.com. - Identity and Access Management API:
iam.googleapis.com. Weitere Informationen finden Sie unter Beispiel-App erstellen und ausführen.
- Cloud Build API:
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 Logs erforderlich sind:
roles/monitoring.metricWriterroles/logging.logWriter
Wenn Sie eine benutzerdefinierte RunMonitoring-Konfiguration erstellen, muss Ihr Dienstkonto auch die folgenden Rollen haben:
roles/secretmanager.adminroles/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 Managed Service for Prometheus-Sidecar für Cloud Run wird eine neue Konfiguration namens RunMonitoring eingeführt, die eine Teilmenge der benutzerdefinierten Kubernetes-Ressource PodMonitoring ist. 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 per Scraping 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 den Sidecar mit der RunMonitoring-Standardkonfiguration verwenden möchten, müssen Sie Ihre vorhandene Cloud Run-Konfiguration ändern, um den Sidecar hinzuzufügen. So fügen Sie den Sidecar hinzu:
- Fügen Sie eine Annotation 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.1.1"
+ 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 führt folgende Schritte aus:
- Extrahiert Messwerte von Port 8080 per Scraping und verwendet den Standardpfad für Messwerte
/metrics. - Verwendet ein 10-Sekunden-Scraping-Intervall.
- Verwendet Relabeling, um jedem extrahierten Messwert das Label
label_keymit dem Wertlabel_valuehinzuzufügen. - Fügt jedem extrahierten Messwert die Metadatenlabels
serviceundrevisionhinzu.
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:
- Aktivieren Sie die Secret Manager API und gewähren Sie Ihrem Cloud Run-Dienstkonto Secret Manager-Rollen. Weitere Informationen finden Sie unter Vorbereitung.
- Speichern Sie die benutzerdefinierte Konfiguration als Secret.
- Fügen Sie den Sidecar zu einem Cloud Run-Dienst hinzu.
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 seine 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 sie Folgendes tut:
- Managed Service for Prometheus-Sidecar hinzufügen
- Fügen Sie eine Annotation 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.yamlbereitstellen:- Fügen Sie eine Secrets-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.yamlverweist. - Stellen Sie das Volume als Teil des Collector-Images unter dem Bereitstellungspfad
/etc/rungmpbereit.
- Fügen Sie eine Secrets-Annotation hinzu, die auf das Secret verweist, das Ihre benutzerdefinierte
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.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 neu bereitzustellen:
gcloud run services replace run-service.yaml --region=REGION
RunMonitoring-Spezifikation: Konfigurationsoptionen
In diesem Abschnitt wird die RunMonitoring-Konfigurationsspezifikation für den Managed Service for Prometheus-Sidecar 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 von der RunMonitoring-Konfiguration überwacht wird.
| Feld | Beschreibung | Schema | Erforderlich |
|---|---|---|---|
endpoints |
Endpunkte, bei denen in den ausgewählten Pods ein Scraping durchgeführt 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 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 |
false |
Beispiel-App erstellen und ausführen
In diesem Abschnitt wird beschrieben, wie Sie den Managed Service for Prometheus-Sidecar mit einer Beispiel-App 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 Beispiel-App 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
Beispiel-App erstellen und ausführen
Für die Beispiel-App 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:
- Verwenden Sie Cloud Build, 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 Beispiel-App 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. In diesen Dateien sind die Schritte zusammengefasst, die zum Erstellen und Bereitstellen der Beispiel-App erforderlich sind.
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.serviceAccountUserroles/storage.objectViewerroles/logging.logWriterroles/artifactregistry.createOnPushWriterroles/secretmanager.adminroles/secretmanager.secretAccessorroles/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-Anfrage 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 Build-Details von Cloud Build 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 Beispiel-App und übertragen sie per Push in die Artifact Registry:
Authentifizieren Sie Ihren Docker-Client mit der Google Cloud CLI:
gcloud auth configure-docker ${REGION}-docker.pkg.devWechseln Sie im Repository
run-gmp-sidecarin das Verzeichnissimple-app:pushd sample-apps/simple-app
Erstellen Sie die
simple-app-App mit dem folgenden Befehl:docker build -t ${REGION}-docker.pkg.dev/${GCP_PROJECT}/run-gmp/sample-app .Ü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-appKehren Sie zum Verzeichnis
run-gmp-sidecarzurü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.1.1"
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.
Legen Sie die Umgebungsvariable
SERVICE_URLauf die Cloud Run-Dienst-URL aus dem vorherigen Schritt fest:export SERVICE_URL=SERVICE_URL
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:
-
Rufen Sie in der Google Cloud Console die Seite leaderboard Metrics Explorer auf.
Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Monitoring ist.
Klicken Sie in der Symbolleiste des Bereichs "Query Builder" auf die Schaltfläche code MQL oder code PromQL.
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.
Geben Sie die folgende Abfrage in den Editorbereich ein:
foo_metric
Klicken Sie auf Abfrage hinzufügen.
Klicken Sie in der Symbolleiste des Bereichs "Query Builder" auf die Schaltfläche code MQL oder code PromQL.
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.
Geben Sie in den zweiten Editorbereich die folgende Abfrage ein:
bar_metric
Klicken Sie auf Abfrage ausführen.
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 dem Testen 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:
- Den 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 des Beispiels keine Kosten.
Führen Sie das clean-up-cloud-run.sh-Script aus, um die Beispiel-App 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:
-
Rufen Sie in der Google Cloud Console die Seite leaderboard Metrics Explorer auf.
Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Monitoring ist.
Klicken Sie in der Symbolleiste des Bereichs "Query Builder" auf die Schaltfläche code MQL oder code PromQL.
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.
Geben Sie den Namen des Messwerts, den Sie abfragen möchten, in den Editorbereich ein. Beispiel:
agent_api_request_count
Klicken Sie auf Abfrage ausführen.
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 Managed Service for Prometheus-Sidecar schreibt Logs in Cloud Logging. Der Sidecar schreibt Logs für den Logging-überwachten Ressourcentyp cloud_run_revision.
So rufen Sie die Logs des Sidecars im Log-Explorer auf:
-
Rufen Sie in der Google Cloud Console die Seite Log-Explorer auf.
Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Logging ist.
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 durch Cloud Monitoring ü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 UmgebungsvariablenK_SERVICEabgerufen.job: Name aus derRunMonitoring-Konfiguration; Der Standardwert istrun-gmp-sidecar.instance: Der Wertfaas.ID:PORTder 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 fügt der Sidecar 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 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 Beispiel-App gibt beispielsweise einen Prometheus-Messgerät-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 den Query Builder 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 Managed Service for Prometheus finden Sie unter Abrechnung.