Benutzerdefinierte Messwerte sind Messwerte, die nicht von Google Cloud definiert werden. Dazu gehören Messwerte, die Sie selbst definieren, sowie Messwerte, die von einer Drittanbieteranwendung definiert werden. Mit benutzerdefinierten Messwerten können Sie anwendungsspezifische Daten oder clientseitige Systemdaten erfassen. Die von Cloud Monitoring erfassten integrierten Messwerte geben Ihnen Informationen zur Back-End-Latenz oder zur Laufwerksnutzung, geben jedoch keine Aufschluss darüber, wie viele Hintergrundroutinen Ihre Anwendung erzeugt hat.
Sie können auch Messwerte erstellen, die auf dem Inhalt von Logeinträgen basieren. Logbasierte Messwerte sind eine Klasse benutzerdefinierter Messwerte, die jedoch in Cloud Logging erstellt werden müssen. Weitere Informationen zu logbasierten Messwerten finden Sie in der Übersicht zu logbasierten Messwerten.
Benutzerdefinierte Messwerte werden manchmal 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 solche Messwerte mithilfe einer API, die von einer Bibliothek bereitgestellt wird, um Ihren Code zu instrumentieren, und senden die Messwerte dann an eine Back-End-Anwendung wie Cloud Monitoring.
Sie können benutzerdefinierte Messwerte außer logbasierte Messwerte erstellen, indem Sie die Cloud Monitoring API direkt verwenden. Wir empfehlen jedoch die Verwendung von OpenTelemetry. Informationen zum Erstellen benutzerdefinierter Messwerte finden Sie in den folgenden Dokumenten:
Unter OTLP-Messwerte und -Traces erfassen wird beschrieben, wie Sie den Ops-Agent und den OTLP-Empfänger (OpenTelemetry Protocol) des Agents verwenden, um Messwerte und Traces von Anwendungen zu erfassen, die mithilfe von OpenTelemetry instrumentiert wurden und in Compute Engine ausgeführt werden.
In Google Cloud Managed Service for Prometheus wird beschrieben, wie Prometheus-Messwerte aus Anwendungen erfasst werden, die in Google Kubernetes Engine und Kubernetes ausgeführt werden.
Unter Prometheus-Messwerte erfassen wird beschrieben, wie Sie mit dem Ops-Agent Prometheus-Messwerte aus Anwendungen erfassen, die in Compute Engine ausgeführt werden.
Unter Benutzerdefinierte Messwerte mit der API erstellen wird beschrieben, wie Sie Messwerte mithilfe der Cloud Monitoring API erstellen und diesen Messwerten Messwertdaten hinzufügen. In diesem Dokument wird anhand von Beispielen für die Verwendung der Monitoring API erläutert, wie Sie die Programmiersprachen APIs Explorer, C#, Go, Java, Node.js, PHP, Python und Ruby verwenden.
Unter Benutzerdefinierte Messwerte in Cloud Run erstellen erfahren Sie, wie Sie den OpenTelemetry Collector als Sidecar-Agent in Cloud Run-Bereitstellungen verwenden.
Für Cloud Monitoring können Sie benutzerdefinierte Messwerte wie die integrierten Messwerte verwenden. Sie können diese Diagramme grafisch darstellen, Benachrichtigungen dafür einrichten, sie lesen und anderweitig überwachen. Informationen zum Lesen von Messwertdaten finden Sie in den folgenden Dokumenten:
- Unter Messwerte und Ressourcentypen auflisten wird erläutert, wie Sie Ihre benutzerdefinierten und integrierten Messwerttypen auflisten und untersuchen. Anhand der Informationen in diesem Dokument können Sie beispielsweise alle benutzerdefinierten Messwertdeskriptoren in Ihrem Projekt auflisten.
- Unter Zeitreihendaten abrufen wird erläutert, wie Sie mit der Monitoring API Zeitachsendaten aus Messwerten abrufen. In diesem Dokument wird beispielsweise beschrieben, wie Sie mit der API die CPU-Auslastung von VM-Instanzen in Ihrem Google Cloud-Projekt abrufen können.
Die Google Cloud Console bietet eine eigene Seite, auf der Sie sich die Nutzung benutzerdefinierter Messwerte ansehen 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 für den Messwert und den Namen des Messwerts. Die Messwertlisten enthalten beispielsweise die Messwertdeskriptoren für alle integrierten Messwerttypen.
Cloud Monitoring kann den Messwertdeskriptor mithilfe der von Ihnen geschriebenen Messwertdaten für Sie erstellen. Alternativ können Sie den Messwertdeskriptor 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 einem einzelnen Computer ausgeführt wird und dass dieses Programm die Hilfsprogramme A
und B
aufruft. Sie möchten zählen, wie oft die Programme A
und B
aufgerufen werden. Sie möchten auch wissen, wann das Programm A
mehr als zehnmal pro Minute und wann das Programm B
mehr als fünfmal pro Minute aufgerufen wird. Angenommen, Sie haben ein einzelnes Google Cloud-Projekt und möchten die Daten in die überwachte Ressource global
schreiben.
In diesem Beispiel werden verschiedene Designs beschrieben, die Sie für Ihre benutzerdefinierten Messwerte verwenden können:
Sie verwenden zwei Messwerte:
Metric-type-A
zählt Aufrufe für das ProgrammA
undMetric-type-B
zählt Aufrufe für das ProgrammB
. In diesem Fall enthältMetric-type-A
eine Zeitachse undMetric-type-B
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 zum Speichern einer Programmkennung. Das Label kann beispielsweise den Wert
A
oderB
speichern. Monitoring erstellt eine Zeitachse für jede eindeutige Labelkombination. Daher gibt es eine Zeitachse mit dem LabelwertA
und eine weitere Zeitachse 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. Für eine Bedingung, die einen Vorfall generiert, wenn die Aufrufrate für das Programm
A
einen Schwellenwert überschreitet, muss ein Filter verwendet werden, der nur Datenpunkte mit dem LabelwertA
einschließt.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 verwenden kein Label, um aufzuzeichnen, welches Programm aufgerufen wurde. In diesem Modell gibt es eine einzelne Zeitachse, die die Daten für die beiden Programme kombiniert. 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 die Anforderungen an die Datenanalyse erfüllen.
Weitere Informationen finden Sie unter Benutzerdefinierten Messwert erstellen.
Namen benutzerdefinierter Messwerte
Wenn Sie einen benutzerdefinierten Messwert erstellen, definieren Sie eine String-ID, die den Messwerttyp darstellt. Dieser String darf unter den benutzerdefinierten Messwerten in Ihrem Google Cloud-Projekt nur einmal vorkommen und ein Präfix enthalten, das den Messwert als benutzerdefinierten Messwert markiert. Für Monitoring sind die zulässigen Präfixe custom.googleapis.com/
, workload.googleapis.com/
, external.googleapis.com/user
und external.googleapis.com/prometheus
.
Auf das 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 benutzerdefinierte Messwerte sind. Beide Beispiele beziehen sich auf Messwerte, die die CPU-Auslastung messen. Sie verwenden jedoch unterschiedliche Organisationsmodelle. Wenn Sie eine große Anzahl von benutzerdefinierten Messwerten erwarten, empfehlen wir die Verwendung einer hierarchischen Namensstruktur wie im zweiten Beispiel.
Alle Messwerttypen haben global eindeutige Kennzeichnungen, die als Ressourcennamen bezeichnet werden. Die Struktur eines Ressourcennamens für einen Messwerttyp sieht so aus:
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 werden, würden ihre Ressourcennamen für diese Messwerte so aussehen:
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 Typ von überwachter Ressource aus, der angibt, woher Ihre Daten stammen, und verwenden diesen, um den spezifischen Ursprung 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 den Ursprung der Daten beschreibt.
Betrachten Sie die überwachte Ressource, bevor Sie den Messwertdeskriptor erstellen. Der verwendete Typ der überwachten Ressource wirkt sich darauf aus, welche Labels Sie in den Messwertdeskriptor aufnehmen müssen. Beispielsweise enthält die Compute Engine-VM-Ressource Labels für die Projekt-ID, die Instanz-ID und die Instanzzone. Wenn Sie also Ihren Messwert für eine Compute Engine-VM-Ressource schreiben möchten, enthalten die Ressourcenlabels die Instanz-ID, sodass Sie kein Label für die Instanz-ID im Messwertdeskriptor benötigen.
Jeder Datenpunkt eines Messwerts muss mit dem Objekt einer überwachten Ressource verknüpft sein. Punkte aus verschiedenen Objekten überwachter Ressourcen werden in verschiedenen Zeitachsen gespeichert.
Sie müssen einen der folgenden überwachten Ressourcentypen mit benutzerdefinierten Messwerten verwenden:
aws_ec2_instance
: Amazon EC2-Instanzdataflow_job
: Dataflow-Job.gae_instance
: App Engine-Instanzgce_instance
: Compute Engine-Instanzgeneric_node
: Vom Nutzer angegebener Rechenknotengeneric_task
: Benutzerdefinierte Aufgabegke_container
: GKE-Containerinstanz.global
: Verwenden Sie diese Ressource, wenn kein anderer Ressourcentyp geeignet ist. Für die meisten Anwendungsfälle sindgeneric_node
odergeneric_task
eine bessere Wahl alsglobal
.k8s_cluster
: Kubernetes-Clusterk8s_container
: Kubernetes-Containerk8s_node
: Kubernetes-Knotenk8s_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 Ihre benutzerdefinierten Messwertdaten mit anderen Messwertdaten aus denselben Ressourcen gruppieren.
global
und allgemeine 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 die Labels project_id
und location
. Wenn Sie in einem Projekt viele Messwertquellen haben, kann die Verwendung desselben global
-Ressourcenobjekts zu Konflikten und Überschreibungen Ihrer Messwertdaten führen.
API-Methoden, die benutzerdefinierte Messwerte unterstützen
Die folgende Tabelle zeigt, welche Methoden in der Monitoring API benutzerdefinierte Messwerte und welche Methoden integrierte Messwerte unterstützen:
Monitoring API-Methode | Mit benutzerdefinierten Messwerten verwenden |
Verwendung mit integrierten Messwerten |
---|---|---|
monitoredResourceDescriptors.get | yes | yes |
monitoredResourceDescriptors.list | Ja | Ja |
metricDescriptors.get | Ja | Ja |
metricDescriptors.list | Ja | Ja |
timeSeries.list | yes | Ja |
timeSeries.create | Ja | |
metricDescriptors.create | Ja | |
metricDescriptors.delete | yes |
Limits und Latenzen
Informationen zu den Limits in Bezug auf benutzerdefinierte Messwerte und die Datenaufbewahrung finden Sie unter Kontingente und Limits.
Wenn Sie Ihre Messwertdaten über die Aufbewahrungsdauer hinaus beibehalten möchten, müssen Sie die Daten manuell an einen anderen Speicherort wie Cloud Storage oder BigQuery kopieren.
Informationen zu Latenzen beim Schreiben von Daten in benutzerdefinierte Messwerte finden Sie unter Latenz von Messwertdaten.
Nächste Schritte
- Verwenden Sie Google Cloud Managed Service for Prometheus, um Prometheus-Messwerte aus Anwendungen zu erfassen, die in Google Kubernetes Engine und Kubernetes ausgeführt werden.
- Prometheus-Messwerte aus Anwendungen erfassen, die in Compute Engine ausgeführt werden
- Erfassen Sie OTLP-Messwerte und -Traces aus Anwendungen, die mit OpenTelemetry instrumentiert wurden und in Compute Engine ausgeführt werden.
- Benutzerdefinierte Messwerte mit der API erstellen
- Einführung in die Cloud Monitoring API
- Messwerte, Zeitreihen und Ressourcen