Benutzerdefinierte Messwerte sind alle Messwerte, die nicht von Google Cloud definiert sind. Dazu gehören Messwerte, die Sie definieren, und Messwerte, die von einer Drittanbieteranwendung definiert werden. Mit benutzerdefinierten Messwerten können Sie anwendungsspezifische Daten oder clientseitige Systemdaten erfassen. Die eingebauten Messwerte, die von Cloud Monitoring erfasst werden, können Ihnen Informationen zur Back-End-Latenz oder zur Laufwerknutzung liefern. Sie geben jedoch keine Auskunft darüber, wie viele Hintergrundroutinen Ihre Anwendung beispielsweise gestartet hat.
Sie können auch Messwerte erstellen, die auf dem Inhalt von Logeinträgen basieren. Logbasierte Messwerte sind eine Art von benutzerdefinierten Messwerten, die Sie jedoch in Cloud Logging erstellen müssen. Weitere Informationen zu logbasierten Messwerten finden Sie unter Übersicht über logbasierte Messwerte.
Benutzerdefinierte Messwerte werden manchmal auch als benutzerdefinierte Messwerte oder anwendungsspezifische Messwerte bezeichnet. Mit diesen Messwerten können Sie oder eine Drittanbieteranwendung Informationen definieren und erfassen, die mit den integrierten Cloud Monitoring-Messwerten nicht möglich sind. Sie erfassen die Messwerte mit einer von einer Bibliothek bereitgestellten API, um Ihren Code zu instrumentieren, und senden sie dann an eine Back-End-Anwendung wie Cloud Monitoring.
Sie können benutzerdefinierte Messwerte (außer logbasierte Messwerte) direkt mit der Cloud Monitoring API erstellen. Wir empfehlen jedoch die Verwendung von OpenTelemetry. Informationen zum Erstellen benutzerdefinierter Messwerte finden Sie in den folgenden Dokumenten:
Im Hilfeartikel OTLP-Messwerte und ‑Traces (OpenTelemetry Protocol) erfassen wird beschrieben, wie Sie mit dem Ops-Agent und dem OpenTelemetry Protocol-Empfänger (OTLP) Messwerte und Traces aus Anwendungen erfassen können, die mit OpenTelemetry instrumentiert und in der Compute Engine ausgeführt werden.
Im Artikel Google Cloud Managed Service for Prometheus wird beschrieben, wie Sie Prometheus-Messwerte von Anwendungen erfassen, die in der Google Kubernetes Engine und in Kubernetes ausgeführt werden.
Im Hilfeartikel Prometheus-Messwerte erfassen wird beschrieben, wie Sie mit dem Ops-Agent Prometheus-Messwerte aus Anwendungen erfassen, die in der Compute Engine ausgeführt werden.
Benutzerdefinierte Messwerte mit der API erstellen beschreibt, wie Sie mit der Cloud Monitoring API Messwerte erstellen und diesen Messwerten Messwertdaten hinzufügen. In diesem Dokument wird die Verwendung der Monitoring API anhand von Beispielen mit den Programmiersprachen API Explorer, C#, Go, Java, Node.js, PHP, Python und Ruby veranschaulicht.
Im Hilfeartikel Benutzerdefinierte Messwerte in Cloud Run erstellen wird beschrieben, wie Sie den OpenTelemetry Collector als Sidecar-Agent in Cloud Run-Deployments verwenden.
Was Cloud Monitoring betrifft, können benutzerdefinierte Messwerte wie die integrierten Messwerte verwendet werden. Sie können sie grafisch darstellen, Benachrichtigungen für sie festlegen, sie lesen und sie anderweitig überwachen. Informationen zum Lesen von Messwertdaten finden Sie in den folgenden Dokumenten:
- Unter Mess- und Ressourcentypen auflisten erfahren Sie, wie Sie benutzerdefinierte und integrierte Messwerttypen auflisten und analysieren. Sie können die Informationen in diesem Dokument beispielsweise verwenden, um alle benutzerdefinierten Messwertdeskriptoren in Ihrem Projekt aufzulisten.
- Zeitreihendaten abrufen beschreibt, wie Sie mithilfe der Monitoring API Zeitreihendaten aus Messwerten abrufen können. In diesem Dokument wird beispielsweise beschrieben, wie Sie mit der API die CPU-Auslastung für VM-Instanzen in Ihrem Google Cloud-Projekt abrufen.
In der Google Cloud Console gibt es eine spezielle Seite, auf der Sie die Nutzung benutzerdefinierter Messwerte einsehen können. Informationen zum Inhalt dieser Seite finden Sie unter Messwertnutzung ansehen und verwalten.
Messwertdeskriptoren für benutzerdefinierte Messwerte
Jeder Messwerttyp muss einen Messwertdeskriptor haben, der definiert, wie die Messwertdaten organisiert sind. Der Messwertdeskriptor definiert auch die Labels und den Namen des Messwerts. In den Listen mit Messwerten finden Sie beispielsweise die Messwertdeskriptoren für alle vordefinierten Messwerttypen.
Cloud Monitoring kann den Messwertdeskriptor anhand der von Ihnen geschriebenen Messwertdaten für Sie erstellen. Sie können den Messwertdeskriptor aber auch explizit erstellen und dann Messwertdaten schreiben. In beiden Fällen müssen Sie entscheiden, wie Sie Ihre Messwertdaten organisieren möchten.
Designbeispiel
Angenommen, Sie haben ein Programm, das auf einer einzelnen Maschine ausgeführt wird, und das Programm ruft die Hilfsprogramme A
und B
auf. Sie möchten zählen, wie oft Programme A
und B
aufgerufen werden. Sie möchten auch wissen, wann das Programm A
mehr als zehnmal pro Minute aufgerufen wird und wenn das Programm B
mehr als fünfmal pro Minute aufgerufen wird. Angenommen, Sie haben nur ein Google Cloud-Projekt und möchten die Daten in die überwachte Ressource global
schreiben.
In diesem Beispiel werden einige verschiedene Designs beschrieben, die Sie für Ihre benutzerdefinierten Messwerte verwenden können:
Sie verwenden zwei Messwerte:
Metric-type-A
zählt die Aufrufe des ProgrammsA
undMetric-type-B
zählt die Aufrufe für das ProgrammB
. In diesem Fall enthaltenMetric-type-A
undMetric-type-B
jeweils eine Zeitachse.Mit diesem Datenmodus können Sie eine einzelne Benachrichtigungsrichtlinie mit zwei Bedingungen oder zwei Benachrichtigungsrichtlinien mit jeweils einer Bedingung erstellen. Eine Benachrichtigungsrichtlinie kann mehrere Bedingungen unterstützen, hat aber eine einzige Konfiguration für die Benachrichtigungskanäle.
Dieses Modell eignet sich möglicherweise, wenn Sie nicht an den Ähnlichkeiten der Daten zwischen den beobachteten Aktivitäten interessiert sind. In diesem Beispiel sind die Aktivitäten die Rate, nach der die Programme
A
undB
aufgerufen werden.Sie verwenden einen einzelnen Messwert und ein Label, um eine Programm-ID zu speichern. Das Label kann beispielsweise den Wert
A
oderB
speichern. Für jede eindeutige Kombination von Labels wird eine Zeitachse erstellt. Es gibt also eine Zeitreihe mit dem LabelwertA
und eine andere Zeitreihe mit dem LabelwertB
.Wie beim vorherigen Modell können Sie eine einzelne Benachrichtigungsrichtlinie oder zwei Benachrichtigungsrichtlinien erstellen. Allerdings sind die Bedingungen für die Benachrichtigungsrichtlinie komplexer. Eine Bedingung, die einen Vorfall generiert, wenn die Häufigkeit von Aufrufen für das Programm
A
einen Schwellenwert überschreitet, muss einen Filter mit Datenpunkten enthalten, deren LabelwertA
ist.Ein Vorteil dieses Modells ist, dass die Berechnung von Verhältnissen einfach ist. Beispielsweise können Sie ermitteln, wie viel des Gesamtbetrags durch Aufrufe von
A
verursacht wird.Sie verwenden einen einzelnen Messwert, um die Anzahl der Aufrufe zu zählen, aber Sie nutzen kein Label, um aufzuzeichnen, welches Programm aufgerufen wurde. In diesem Modell gibt es eine einzelne Zeitachse, in der die Daten für die beiden Programme kombiniert werden. Sie können jedoch keine Benachrichtigungsrichtlinie erstellen, die Ihren Zielen entspricht, da die Daten für zwei Programme nicht getrennt werden können.
Mit den ersten beiden Designs können Sie Ihre Anforderungen an die Datenanalyse erfüllen, das letzte Design erfüllt sie jedoch nicht.
Weitere Informationen finden Sie unter Benutzerdefinierten Messwert erstellen.
Namen von benutzerdefinierten Messwerten
Beim Erstellen eines benutzerdefinierten Messwerts wird eine String-ID erstellt, die den Messwerttyp darstellt. Dieser String muss unter den benutzerdefinierten Messwerten in Ihrem Google Cloud-Projekt eindeutig sein und ein Präfix enthalten, das den Messwert als benutzerdefinierten Messwert kennzeichnet. Für Monitoring sind die zulässigen Präfixe custom.googleapis.com/
, workload.googleapis.com/
, external.googleapis.com/user
und external.googleapis.com/prometheus
.
Dem Präfix folgt ein Name, der beschreibt, was Sie erfassen.
Weitere Informationen zur empfohlenen Benennung von Messwerten finden Sie unter Namenskonventionen für Messwerte.
Im Folgenden finden Sie Beispiele für die beiden Arten von IDs für Messwerttypen:
custom.googleapis.com/cpu_utilization custom.googleapis.com/instance/cpu/utilization
Im vorherigen Beispiel gibt das Präfix custom.googleapis.com
an, dass beide Messwerte benutzerdefiniert sind. Beide Beispiele beziehen sich auf Messwerte zur CPU-Auslastung, verwenden jedoch unterschiedliche Organisationsmodelle. Wenn Sie davon ausgehen, dass Sie eine große Anzahl von benutzerdefinierten Messwerten haben werden, empfehlen wir eine hierarchische Benennungsstruktur wie im zweiten Beispiel.
Alle Messwerttypen haben global eindeutige Kennzeichnungen, die als Ressourcennamen bezeichnet werden. Die Struktur eines Ressourcennamens für einen Messwerttyp ist:
projects/PROJECT_ID/metricDescriptors/METRIC_TYPE
Dabei ist METRIC_TYPE
die String-ID des Messwerttyps.
Wenn die vorherigen Messwertbeispiele im Projekt my-project-id
erstellt wurden, würden ihre Ressourcennamen für diese Messwerte so lauten:
projects/my-project-id/metricDescriptors/custom.googleapis.com/cpu_utilization projects/my-project-id/metricDescriptors/custom.googleapis.com/instance/cpu/utilization
Name oder Typ? Im Messwertdeskriptor speichert das Feld name
den Ressourcennamen des Messwerttyps und das Feld type
speichert den String METRIC_TYPE
.
Überwachte Ressourcentypen für benutzerdefinierte Messwerte
Wenn Sie Ihre Daten in eine Zeitachse schreiben, müssen Sie angeben, woher die Daten stammen. Um die Quelle der Daten anzugeben, wählen Sie einen Ressourcentyp für die überwachte Ressource aus, der für den Ursprung der Daten steht, und verwenden ihn dann, um den Ursprung genauer zu beschreiben. Die überwachte Ressource ist nicht Teil des Messwerttyps. Stattdessen enthält die Zeitachse, in die Sie Daten schreiben, einen Verweis auf den Messwerttyp und einen Verweis auf die überwachte Ressource. Der Messwerttyp beschreibt die Daten, während die überwachte Ressource angibt, woher die Daten stammen.
Sehen Sie sich die überwachte Ressource genau an, bevor Sie den Messwertdeskriptor erstellen. Der verwendete Typ der überwachten Ressource wirkt sich darauf aus, welche Labels Sie in den Messwertdeskriptor aufnehmen müssen. Die Compute Engine-VM-Ressource enthält beispielsweise Labels für die Projekt-ID, die Instanz-ID und die Instanzzone. Wenn Sie also einen Messwert für eine Compute Engine-VM-Ressource aufzeichnen möchten, enthalten die Ressourcenlabels die Instanz-ID. Sie benötigen also kein Label für die Instanz-ID im Messwert-Descriptor.
Jeder Datenpunkt eines Messwerts muss mit dem Objekt einer überwachten Ressource verknüpft sein. Punkte aus verschiedenen überwachten Ressourcenobjekten werden in verschiedenen Zeitachsen gespeichert.
Sie müssen einen der folgenden überwachten Ressourcentypen mit benutzerdefinierten Messwerten verwenden:
aws_ec2_instance
: Amazon EC2-Instanz.dataflow_job
: Dataflow-Job.gae_instance
: App Engine-Instanz.gce_instance
: Compute Engine-Instanz.generic_node
: Vom Nutzer angegebener Rechenknoten.generic_task
: Benutzerdefinierte Aufgabe.gke_container
: GKE-Container-Instanz.global
: Verwenden Sie diese Ressource, wenn kein anderer Ressourcentyp geeignet ist. Für die meisten Anwendungsfälle istgeneric_node
odergeneric_task
die bessere Wahl alsglobal
.k8s_cluster
: Kubernetes-Cluster.k8s_container
: Kubernetes-Container.k8s_node
: Kubernetes-Knoten.k8s_pod
: Kubernetes-Pod.
Häufig werden die überwachten Ressourcenobjekte verwendet, die die physischen Ressourcen repräsentieren, auf denen Ihr Anwendungscode ausgeführt wird. Dieser Ansatz bietet verschiedene Vorteile:
- Sie erhalten eine bessere Leistung im Vergleich zur Verwendung eines einzelnen Ressourcentyps.
- Sie vermeiden falsche Dateneinträge, die verursacht werden, wenn mehrere Prozesse in dieselbe Zeitachse schreiben.
- Sie können die Daten Ihres benutzerdefinierten Messwerts mit anderen Messwertdaten aus derselben Ressource gruppieren.
global
und generische Ressourcen
Die Ressourcentypen generic_task
und generic_node
sind in Situationen nützlich, in denen keiner der spezifischeren Ressourcentypen geeignet ist.
Der Typ generic_task
eignet sich zum Definieren von aufgabenähnlichen Ressourcen wie Anwendungen. Der Typ generic_node
eignet sich zum Definieren knotenähnlicher Ressourcen wie virtuelle Maschinen. Beide generic_*
-Typen haben mehrere allgemeine Labels, die Sie zur Definition eindeutiger Ressourcenobjekte verwenden können. Somit lassen sie sich bei Messwertfiltern ganz einfach für Aggregationen und Reduzierungen verwenden.
Im Gegensatz dazu hat der Ressourcentyp global
nur das Label project_id
.
Wenn in einem Projekt viele Quellen für Messwerte vorhanden sind, kann die Verwendung desselben global
-Ressourcenobjekts zu Konflikten und Überschreibungen der Messwertdaten führen.
API-Methoden, die benutzerdefinierte Messwerte unterstützen
In der folgenden Tabelle sehen Sie, welche Methoden in der Monitoring API benutzerdefinierte und welche Methoden integrierte Messwerte unterstützen:
Monitoring API-Methode | Verwendung mit benutzerdefinierten Messwerten |
Verwendung mit integrierten Messwerten |
---|---|---|
monitoredResourceDescriptors.get | Ja | Ja |
monitoredResourceDescriptors.list | Ja | Ja |
metricDescriptors.get | Ja | Ja |
metricDescriptors.list | Ja | Ja |
timeSeries.list | Ja | Ja |
timeSeries.create | Ja | |
metricDescriptors.create | Ja | |
metricDescriptors.delete | Ja |
Limits und Latenzen
Weitere Informationen zu Limits für benutzerdefinierte Messwerte und die Datenaufbewahrung finden Sie unter Kontingente und Limits.
Wenn Sie Ihre Messwertdaten über die festgelegte Aufbewahrungsdauer hinaus beibehalten möchten, kopieren Sie die Daten manuell an einen anderen Ort wie etwa Cloud Storage oder BigQuery.
Informationen zu Latenzen beim Schreiben von Daten in benutzerdefinierte Messwerte finden Sie unter Latenz von Messwertdaten.
Nächste Schritte
- Verwenden Sie den Google Cloud Managed Service for Prometheus, um Prometheus-Messwerte von Anwendungen zu erfassen, die in der Google Kubernetes Engine und in Kubernetes ausgeführt werden.
- Prometheus-Messwerte aus Anwendungen erfassen, die in der Compute Engine ausgeführt werden.
- OTLP-Messwerte und -Traces aus Anwendungen erfassen, die mit OpenTelemetry instrumentiert und in der Compute Engine ausgeführt werden.
- Benutzerdefinierte Messwerte mit der API erstellen
- Einführung in die Cloud Monitoring API
- Messwerte, Zeitreihen und Ressourcen