Benutzerdefinierte Messwerte – Übersicht

Mit benutzerdefinierten Messwerten (auch benutzerdefinierte Messwerte genannt) in Cloud Monitoring können Sie anwendungsspezifische oder clientseitige Telemetriedaten erfassen, die von integrierten Google Cloud Messwerten nicht erfasst werden. Sie können beispielsweise die Anzahl der Hintergrundroutinen aufzeichnen, die Ihre Anwendung erzeugt, und diese Messwerte dann wie integrierte Messwerte in Diagrammen darstellen, lesen und Benachrichtigungen dazu erhalten.

Möglichkeiten zum Erfassen und Lesen benutzerdefinierter Messwerte

Wir empfehlen, OpenTelemetry zu verwenden, um Ihren Code zu instrumentieren und benutzerdefinierte Messwerte zu erfassen. Sie können aber auch Prometheus oder die Cloud Monitoring API direkt verwenden. Wenn Sie Messwerte aus Logeinträgen ableiten möchten, erstellen Sie stattdessen logbasierte Messwerte in Cloud Logging. Sie können die Messwertaufnahme auf der Seite Messwertverwaltung in der Google Cloud Console überwachen.

Informationen zum Erstellen benutzerdefinierter Messwerte finden Sie in den folgenden Dokumenten:

  • Unter OTLP-Messwerte und -Traces erfassen wird beschrieben, wie Sie mit dem Ops-Agent und dem OTLP-Empfänger (OpenTelemetry Protocol) des Agenten Messwerte und Traces aus Anwendungen erfassen, die mit OpenTelemetry instrumentiert sind und in Compute Engine ausgeführt werden.

  • Unter Google Cloud Managed Service for Prometheus wird beschrieben, wie Sie Prometheus-Messwerte von Anwendungen erfassen, die in Google Kubernetes Engine und Kubernetes ausgeführt werden.

  • Unter Prometheus-Messwerte erfassen wird beschrieben, wie Sie mit dem Ops-Agent Prometheus-Messwerte von Anwendungen erfassen, die in der Compute Engine ausgeführt werden.

  • Unter Benutzerdefinierte Messwerte mit der API erstellen wird beschrieben, wie Sie Messwerte mit der Cloud Monitoring API erstellen und diesen Messwerten Daten hinzufügen. In diesem Dokument wird anhand von Beispielen mit dem APIs Explorer und den Programmiersprachen C#, Go, Java, Node.js, PHP, Python und Ruby veranschaulicht, wie die Monitoring API verwendet wird.

  • Unter Benutzerdefinierte Messwerte in Cloud Run erstellen wird gezeigt, wie Sie den OpenTelemetry Collector als Sidecar-Agent in Cloud Run-Deployments verwenden.

In Cloud Monitoring können Sie benutzerdefinierte Messwerte wie die integrierten Messwerte verwenden. Sie können sie in Diagrammen darstellen, Benachrichtigungen dafür einrichten, sie lesen und anderweitig überwachen. Informationen zum Lesen von Messwertdaten finden Sie in den folgenden Dokumenten:

  • Unter Messwert- und Ressourcentypen auflisten wird erläutert, wie Sie Ihre benutzerdefinierten und integrierten Messwerttypen auflisten und untersuchen. Sie können beispielsweise die Informationen in diesem Dokument verwenden, um alle benutzerdefinierten Messwertdeskriptoren in Ihrem Projekt aufzulisten.
  • Unter Zeitreihendaten abrufen wird erläutert, wie Sie Zeitreihendaten aus Messwerten mithilfe der Monitoring API abrufen. In diesem Dokument wird beispielsweise beschrieben, wie Sie mit der API die CPU-Auslastung für VM-Instanzen in Ihrem Google Cloud -Projekt abrufen können.

Messwertdeskriptoren für benutzerdefinierte Messwerte

Jeder Messwerttyp muss einen Messwertdeskriptor haben, der definiert, wie die Messwertdaten organisiert sind. Der Messwert-Deskriptor definiert auch die Labels für den Messwert und den Namen des Messwerts. In den Messwertlisten werden beispielsweise die Messwertdeskriptoren für alle integrierten Messwerttypen angezeigt.

Cloud Monitoring kann den Messwertdeskriptor für Sie erstellen, indem die von Ihnen geschriebenen Messwertdaten verwendet werden. 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 einer einzelnen Maschine ausgeführt wird, und dieses Programm ruft die Hilfsprogramme A und B auf. 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 des Programms A und Metric-type-B zählt Aufrufe des Programms B. In diesem Fall enthält Metric-type-A eine Zeitreihe und Metric-type-B eine Zeitreihe.

    Mit diesem Datenmodell 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, um eine Programmkennung zu speichern. Das Label kann beispielsweise den Wert A oder B speichern. Monitoring erstellt für jede eindeutige Kombination von Labels eine Zeitreihe. Daher gibt es eine Zeitreihe mit dem Labelwert A und eine weitere Zeitreihe mit dem 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 eine Benachrichtigung generiert, wenn die Anzahl der Aufrufe für das Programm A einen Schwellenwert überschreitet, muss einen Filter verwenden, der nur Datenpunkte enthält, deren Labelwert A 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 kein Label, um aufzuzeichnen, welches Programm aufgerufen wurde. In diesem Modell gibt es eine einzelne Zeitreihe, 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 die beiden Programme nicht getrennt werden können.

Mit den ersten beiden Designs können Sie Ihre Anforderungen an die Datenanalyse erfüllen, mit dem letzten Design jedoch nicht.

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 muss unter den benutzerdefinierten Messwerten in IhremGoogle Cloud -Projekt eindeutig sein und ein Präfix verwenden, 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. 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 benutzerdefiniert sind. Beide Beispiele beziehen sich auf Messwerte, die die CPU-Auslastung messen. Sie verwenden jedoch unterschiedliche Organisationsmodelle. Wenn Sie eine große Anzahl benutzerdefinierter Messwerte erwarten, empfehlen wir eine hierarchische Benennungsstruktur wie im zweiten Beispiel.

Alle Messwerttypen haben global eindeutige Kennungen, 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, lauten die Ressourcennamen für diese Messwerte so:

    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.

Typen überwachter Ressourcen für benutzerdefinierte Messwerte

Wenn Sie Daten in eine Zeitreihe schreiben, müssen Sie angeben, woher die Daten stammen. Um die Quelle der Daten anzugeben, wählen Sie einen Typ für die überwachte Ressource aus, der die Herkunft Ihrer Daten darstellt, und beschreiben damit den spezifischen Ursprung. Die überwachte Ressource ist nicht Teil des Messwerttyps. Stattdessen enthält die Zeitreihe, 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 beschreibt, woher die Daten stammen.

Berücksichtigen 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 Ihren Messwert für eine Compute Engine-VM-Ressource schreiben möchten, enthalten die Ressourcenlabels die Instanz-ID. Sie benötigen also 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 überwachten Ressourcenobjekten werden in verschiedenen Zeitreihen 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 ungeordnete Daten, die durch mehrere Prozesse verursacht werden, die in dieselbe Zeitachse schreiben.
  • Sie können die Daten Ihrer benutzerdefinierten Messwerte 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.

Der Ressourcentyp global hat dagegen nur das Label project_id. Wenn Sie viele Messwertquellen in einem Projekt haben, kann die Verwendung desselben global-Ressourcenobjekts zu Konflikten und Überschreibungen Ihrer Messwertdaten führen.

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

Informationen zu Limits für benutzerdefinierte Messwerte und die Datenaufbewahrung finden Sie unter Kontingente und Limits.

Wenn Sie Ihre Messwertdaten über die Aufbewahrungsdauer hinaus speichern möchten, müssen Sie die Daten manuell an einen anderen Speicherort kopieren, z. B. Cloud Storage oder BigQuery.

Informationen zu Latenzen beim Schreiben von Daten in benutzerdefinierte Messwerte finden Sie unter Latenz von Messwertdaten.

Nächste Schritte