Benutzerdefinierte Messwerte – Übersicht

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 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 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 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.

  • 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.

  • Erstellen Sie benutzerdefinierte Messwerte zu Cloud Run zeigt, wie Sie die OpenTelemetry Collector als Sidecar-Agent in Cloud Run-Bereitstellungen

Was Cloud Monitoring betrifft, können benutzerdefinierte Messwerte wie die integrierten Messwerte verwendet werden. 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 Mess- und Ressourcentypen auflisten erfahren Sie, wie Sie benutzerdefinierte und integrierte Messwerttypen auflisten und analysieren. 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 mit der API die CPU-Auslastung für VM-Instanzen in Ihrem Google Cloud-Projekt abrufen.

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. In den Listen mit Messwerten werden beispielsweise die Messwertdeskriptoren für alle integrierten Messwerttypen angezeigt.

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, Das Programm A wird mehr als zehnmal pro Minute aufgerufen. Wenn das Programm B mehr als fünfmal pro Minute aufgerufen. Angenommen, Sie haben nur ein Google Cloud-Projekt und möchten die Daten in die überwachte Ressource global schreiben.

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 und Metric-type-B zählt die Aufrufe für das Programm B. In diesem Fall enthalten Metric-type-A und Metric-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 und B aufgerufen werden.

  • Sie verwenden einen einzelnen Messwert und ein Label zum Speichern einer Programmkennung. Das Label kann beispielsweise den Wert A oder B speichern. Für jede eindeutige Kombination von Labels wird eine Zeitachse erstellt. Daher gibt es eine Zeitreihe mit dem Labelwert A und eine weitere Zeitachse mit Labelwert B.

    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 Labelwert A 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 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 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 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 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 Referenz zur überwachten Ressource. Der Messwerttyp beschreibt die Daten, während die überwachte Ressource angibt, 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. 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:

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 Messwerte mit anderen Messwertdaten aus der dieselben Ressourcen.

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 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 festgelegte Aufbewahrungsdauer hinaus beibehalten möchten, kopieren Sie die Daten manuell an einen anderen Ort wie etwa Cloud Storage oder BigQuery.

Informationen über Latenzen beim Schreiben von Daten in Benutzerdefinierte Messwerte finden Sie unter Latenz von Messwertdaten.

Nächste Schritte