Benutzerdefinierte Messwerte sind Messwerte, die nicht von Google Cloud definiert werden. Dazu gehören Messwerte, die Sie selbst definieren, und sie umfassen Messwerte, die von einer Drittanbieter-App definiert wird. Mit benutzerdefinierten Messwerten können Sie anwendungsspezifischen Daten oder clientseitigen Systemdaten. Die integrierten Messwerte, die von Cloud Monitoring erfasst werden Informationen zur Back-End-Latenz oder Laufwerksnutzung geben, Sie erfahren beispielsweise, 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 Sie erstellen müssen, in Cloud Logging speichern. Weitere Informationen zu logbasierten Messwerten finden Sie unter Übersicht über logbasierte Messwerte
Benutzerdefinierte Messwerte werden auch als benutzerdefinierte Messwerte oder und anwendungsspezifischen Metriken. Mit diesen Messwerten können Sie oder ein Drittanbieter Anwendung, Definition und Daten erfassen, die mit den integrierten Cloud Monitoring-Messwerten nicht möglich sind. Sie erfassen solche Messwerte mithilfe einer API, die von einer Bibliothek zur Instrumentierung bereitgestellt wird. und senden die Messwerte an eine Back-End-Anwendung wie Cloud Monitoring
Sie können benutzerdefinierte Messwerte erstellen, ausgenommen logbasierte Messwerte, direkt mit der Cloud Monitoring API. Wir empfehlen Ihnen jedoch, OpenTelemetry: Informationen zur Benutzerdefinierte Messwerte erstellen, finden Sie in den folgenden Dokumenten:
Unter OTLP-Messwerte und ‐Traces erfassen wird beschrieben, wie Sie Verwenden Sie den Ops-Agent und den OTLP-Empfänger (OpenTelemetry Protocol) des Agents, um Messwerte und Traces aus Anwendungen erfassen, die mit OpenTelemetry instrumentiert wurden und auf Compute Engine ausgeführt werden.
In Google Cloud Managed Service for Prometheus wird beschrieben, wie Prometheus erfasst wird. von Anwendungen, die in der Google Kubernetes Engine und Kubernetes ausgeführt werden.
Unter Prometheus-Messwerte erfassen wird beschrieben, Sie möchten den Ops-Agent verwenden, um Prometheus-Messwerte aus Anwendungen zu erfassen. die in Compute Engine ausgeführt wird.
Benutzerdefinierte Messwerte mit der API erstellen beschreibt, wie Sie Messwerte mit der Cloud Monitoring API erstellen und wie Sie Messwerte zu diesen Messwerten hinzufügen. In diesem Dokument wird die Verwendung der Monitoring API mit APIs Explorer, C#, Go, Java, Node.js, PHP, Python und Ruby.
Erstellen Sie benutzerdefinierte Messwerte zu Cloud Run zeigt, wie Sie die OpenTelemetry Collector als Sidecar-Agent in Cloud Run-Bereitstellungen
Für Cloud Monitoring können Sie benutzerdefinierte Messwerte wie die integrierten Messwerte. Sie können Diagramme erstellen, Benachrichtigungen dafür einrichten, und sie auch anderweitig überwachen. Informationen zum Lesen von Messwertdaten finden Sie unter folgende Dokumente:
- Unter Messwerte und Ressourcentypen auflisten wird erläutert, wie die Listeneinträge und überprüfen Sie Ihre benutzerdefinierten und integrierten Messwerttypen. Zum Beispiel haben Sie anhand der Informationen in diesem Dokument alle benutzerdefinierten in Ihrem Projekt verwenden.
- Informationen zum Abrufen von Zeitreihendaten wie Sie Zeitachsendaten mithilfe der Methode Monitoring API In diesem Dokument wird beispielsweise beschrieben, wie Sie können Sie mit der API die CPU-Auslastung VM-Instanzen in Ihrem Google Cloud-Projekt
Die Google Cloud Console bietet eine eigene Seite, auf der Sie die Nutzung von benutzerdefinierten Messwerten. Informationen zum Inhalt dieser Seite finden Sie unter Messwertnutzung ansehen und verwalten
Messwertdeskriptoren für benutzerdefinierte Messwerte
Jeder Messwerttyp muss einen Messwertdeskriptor haben, der festlegt, sind die Metrikdaten organisiert. Der Messwertdeskriptor definiert auch die Labels und den Namen des Messwerts. Beispiel: Der Parameter Messwertlisten enthalten die Messwertdeskriptoren für alle integrierten Messwerttypen.
Cloud Monitoring kann den Messwertdeskriptor mithilfe der Methode selbst geschriebene Messwertdaten oder Sie erstellen den Messwert Deskriptor und schreiben dann Messwertdaten. In beiden Fällen müssen Sie entscheiden, wie Sie Ihre Messwertdaten organisieren möchten.
Designbeispiel
Angenommen, Sie haben ein Programm,
das auf einer einzigen Maschine 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,
Das Programm A
wird mehr als zehnmal pro Minute aufgerufen. Wenn das Programm B
mehr als fünfmal pro Minute aufgerufen. Nehmen wir abschließend an, Sie haben
Google Cloud-Projekt erstellen und die Daten
in Bezug auf die überwachte Ressource global
.
Dieses Beispiel beschreibt einige verschiedene Designs, die Sie für benutzerdefinierten Messwerten:
Sie verwenden zwei Messwerte:
Metric-type-A
zählt die Aufrufe des Programms.A
undMetric-type-B
zählen Aufrufe für das ProgrammB
. In diesem FallMetric-type-A
enthält eine Zeitreihe undMetric-type-B
enthält eine Zeitreihe Zeitreihe.Sie können eine einzelne Benachrichtigungsrichtlinie mit zwei Bedingungen erstellen oder zwei Benachrichtigungsrichtlinien mit jeweils eine Bedingung mit diesem Datenmodus. 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 Zeitreihe für jede eindeutige Kombination von Beschriftungen. Daher gibt es eine Zeitachse mit dem LabelwertA
und eine weitere Zeitachse mit 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 ein Vorfall, bei dem die Aufrufrate für das Programm
A
einen Schwellenwert überschreitet Verwenden Sie einen Filter, 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 zählen die Anzahl der Anrufe mit einem einzigen Messwert, verwenden Sie kein Label, um aufzuzeichnen, welches Programm aufgerufen wurde. In dieser gibt es eine einzige Zeitreihe, die die Daten der beiden Programmen. 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: Allerdings beim letzten Design nicht.
Weitere Informationen finden Sie unter Benutzerdefinierten Messwert erstellen
Namen benutzerdefinierter Messwerte
Wenn Sie einen benutzerdefinierten Messwert erstellen, definieren Sie eine String-ID, die
ist der Messwerttyp. Dieser String muss unter den
benutzerdefinierten Messwerte
Google Cloud-Projekt hinzu und muss ein Präfix verwenden, das den Messwert als
benutzerdefinierten Messwerts. 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 sammeln.
Weitere Informationen zur empfohlenen Benennung eines Messwerts 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 sowohl
Messwerte sind benutzerdefinierte Messwerte. Beide Beispiele beziehen sich auf Messwerte, die den
CPU-Auslastung; Sie verwenden jedoch unterschiedliche Organisationsmodelle. Wenn Sie
eine große Anzahl benutzerdefinierter Messwerte erwarten, sollten Sie
verwenden Sie eine hierarchische 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ären ihre Ressourcennamen für diese Messwerte wie folgt:
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 Zeitreihe schreiben, müssen Sie angeben, Daten stammen. Um die Quelle der Daten anzugeben, wählen Sie eine überwachter Ressourcentyp, gibt an, woher Ihre Daten stammen. einen bestimmten Ursprung haben. Die überwachte Ressource ist nicht Teil des Messwerttyps. Stattdessen werden die Zeitachsen in die Sie Daten schreiben, enthalten einen Verweis auf den Messwerttyp und einen Verweis auf die überwachte Ressource. Der Messwerttyp beschreibt die Daten, Die überwachte Ressource beschreibt, woher die Daten stammen.
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. Beispiel: Der Parameter Compute Engine-VM-Ressource enthält Labels für die Projekt-ID, die Instanz-ID und die Instanzzone. Wenn Sie also Ihren Messwert für eine Compute Engine-VM-Ressource zu schreiben, enthalten die Ressourcenlabels die Instanz-ID, brauchen kein Label für die Instanz-ID im Messwertdeskriptor.
Jeder Datenpunkt eines Messwerts muss mit dem Objekt einer überwachten Ressource verknüpft sein. Punkte aus verschiedenen Objekten überwachter Ressourcen werden unterschiedlich Zeitreihe.
Sie müssen einen der folgenden überwachten Ressourcentypen mit benutzerdefinierten Messwerten:
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-Containerinstanz.global
: Verwenden Sie diese Ressource, wenn kein anderer Ressourcentyp geeignet sind. Für die meisten Anwendungsfälle sindgeneric_node
odergeneric_task
bessere Entscheidungen 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 den Zeitreihe angezeigt.
- Sie können Ihre benutzerdefinierten Messwertdaten mit anderen Messwertdaten aus der dieselben Ressourcen.
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 Quellen von Metriken haben,
global
-Ressourcenobjekt kann
Kollisionen und Überschreibungen Ihrer Messwertdaten.
API-Methoden, die benutzerdefinierte Messwerte unterstützen
In der folgenden Tabelle sehen Sie, 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 | 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
Für Limits in Bezug auf benutzerdefinierte Messwerte und die Datenaufbewahrung: Siehe Kontingente und Limits.
Wenn Sie Ihre Messwertdaten über die Aufbewahrungsdauer hinaus beibehalten möchten, müssen Sie Daten manuell an einen anderen Speicherort wie Cloud Storage oder BigQuery
Informationen über Latenzen beim Schreiben von Daten in Benutzerdefinierte Messwerte finden Sie unter Latenz von Messwertdaten.
Nächste Schritte
- Prometheus mit Google Cloud Managed Service for Prometheus erfassen von Anwendungen, die in der Google Kubernetes Engine und Kubernetes ausgeführt werden.
- Prometheus-Messwerte erfassen Anwendungen, die in Compute Engine ausgeführt werden.
- OTLP-Messwerte und -Traces aus Anwendungen erfassen mithilfe von OpenTelemetry instrumentiert und auf Compute Engine ausgeführt wird.
- Benutzerdefinierte Messwerte mit der API erstellen
- Einführung in die Cloud Monitoring API
- Messwerte, Zeitreihen und Ressourcen