Benutzerdefinierte Messwerte – Übersicht

Benutzerdefinierte Messwerte sind alle Messwerte, die nicht von Google Cloud definiert werden. Dazu gehören Messwerte, die Sie definieren, sowie Messwerte, die von Anwendungen von Drittanbietern definiert werden. Mit benutzerdefinierten Messwerten können Sie anwendungs- oder clientseitige Systemdaten erfassen. Die von Cloud Monitoring erfassten integrierten Messwerte können Ihnen Informationen zur Back-End-Latenz oder zur Laufwerksnutzung liefern, können aber nicht aussagen, wie viele Hintergrundroutinen Ihre Anwendung erstellt hat. Sie können auch Messwerte erstellen, die auf dem Inhalt von Logeinträgen basieren. Informationen zu diesen Messwerttypen finden Sie unter Übersicht über logbasierte Messwerte.

Benutzerdefinierte Messwerte werden manchmal als benutzerdefinierte oder anwendungsspezifische Messwerte bezeichnet. Mit diesen Messwerten können Sie oder eine Drittanbieteranwendung Informationen definieren und erfassen, die in den integrierten Cloud Monitoring-Messwerten nicht erfasst werden können. Sie erfassen diese Messwerte mithilfe einer API, die von einer Bibliothek für die Instrumentierung Ihres Codes bereitgestellt wird, und senden sie an eine Back-End-Anwendung wie Cloud Monitoring.

Benutzerdefinierte Messwerte lassen sich 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:

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

  • 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 Messwerte mit der Cloud Monitoring API erstellt und diesen Messwerten Daten hinzugefügt werden. In diesem Dokument wird erläutert, wie Sie die Monitoring API mit Beispielen mithilfe der Programmiersprachen APIs Explorer, C#, Go, Java, Node.js, PHP, Python und Ruby verwenden.

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

In Bezug auf Cloud Monitoring können Sie benutzerdefinierte Messwerte wie die integrierten Messwerte verwenden. Sie können sie grafisch darstellen, Benachrichtigungen dazu 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 benutzerdefinierte und integrierte Messwerttypen auflisten und prüfen. Sie können beispielsweise die Informationen in diesem Dokument verwenden, um alle benutzerdefinierten Messwertdeskriptoren in Ihrem Projekt aufzulisten.
  • Unter Zeitachsendaten abrufen wird erläutert, wie Sie mithilfe der Monitoring API Zeitreihendaten aus Messwerten abrufen. In diesem Dokument wird beispielsweise beschrieben, wie Sie mithilfe der API die CPU-Auslastung für VM-Instanzen in Ihrem Google Cloud-Projekt abrufen können.

Die Google Cloud Console bietet eine eigene Seite, auf der Sie die Nutzung benutzerdefinierter Messwerte sehen können. Informationen zum Inhalt dieser Seite finden Sie unter Messwertnutzung und -diagnose ansehen.

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

Cloud Monitoring kann den Messwertdeskriptor mit den von Ihnen geschriebenen Messwertdaten erstellen. Alternativ können Sie den Messwertdeskriptor explizit erstellen und dann Messwertdaten schreiben. In beiden Fällen müssen Sie entscheiden, wie Sie die Messwertdaten organisieren möchten.

Designbeispiel

Angenommen, Sie haben ein Programm, das auf einem einzelnen Computer ausgeführt wird und dieses Hilfsprogramm A und B aufruft. Sie möchten zählen, wie oft die Programme A und B aufgerufen werden. Sie sollten außerdem wissen möchten, wann Programm A mehr als 10-mal pro Minute und wann Programm-B mehr als 5-mal pro Minute aufgerufen wird. Nehmen wir schließlich an, dass Sie nur ein Google Cloud-Projekt haben und die Daten auf die überwachte Ressource global schreiben möchten.

In diesem Beispiel werden einige verschiedene Designs für benutzerdefinierte Messwerte beschrieben:

  • Sie verwenden zwei Messwerte: Metric-type-A zählt Aufrufe des Programms A und Metric-type-B die Aufrufe des Programms B. In diesem Fall enthält Metric-type-A eine Zeitachse und Metric-type-B eine Zeitachse.

    Sie können eine einzelne Benachrichtigungsrichtlinie mit zwei Bedingungen erstellen oder mit diesem Datenmodus 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 verwenden ein Label, um eine Programm-ID zu speichern. Das Label könnte beispielsweise den Wert A oder B speichern. Monitoring erstellt für jede eindeutige Labelkombination eine Zeitachse. Daher gibt es eine Zeitachse mit dem Labelwert A und eine andere Zeitachse 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 einen Vorfall generiert, wenn die Rate der Aufrufe für das Programm A einen Grenzwert ü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 zu erfassen, 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 die Anforderungen an die Datenanalyse erfüllen, beim letzten 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 Ihrem Google Cloud-Projekt eindeutig sein und ein Präfix verwenden, mit dem der Messwert als benutzerdefinierter Messwert gekennzeichnet wird. Für Monitoring sind die Präfixe custom.googleapis.com/, external.googleapis.com/user und external.googleapis.com/prometheus zulässig. Auf das Präfix folgt ein Name, der die erfassten Daten beschreibt. Weitere Informationen zur empfohlenen Benennung eines Messwerts finden Sie unter Konventionen 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 sind für Messwerte, die die CPU-Auslastung messen. Sie verwenden jedoch unterschiedliche Organisationsmodelle. Wenn Sie davon ausgehen, dass viele benutzerdefinierte Messwerte vorhanden sind, empfehlen wir die Verwendung einer hierarchischen Namensstruktur, die im zweiten Beispiel verwendet wird.

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

Überwachte Ressourcentypen für benutzerdefinierte Messwerte

Wenn Sie Ihre Daten in eine Zeitachse schreiben, müssen Sie angeben, woher die Daten stammen. Wählen Sie zum Angeben der Datenquelle einen Typ von überwachter Ressource aus, der den Ursprung Ihrer Daten darstellt, und verwenden Sie ihn dann, 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 eine Referenz auf die überwachte Ressource. Der Messwerttyp beschreibt die Daten, die überwachte Ressource dagegen den Ursprung der Daten.

Prüfen 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 einen Messwert für eine Compute Engine-VM-Ressource schreiben möchten, enthalten die Ressourcenlabels also 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 ü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 benutzerdefinierte 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 Quellen für Messwerte haben, kann die Verwendung desselben global-Ressourcenobjekts zu Kollisionen 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 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 Limits in Bezug auf benutzerdefinierte Messwerte und zur Datenaufbewahrung finden Sie unter Kontingente und Limits.

Damit Ihre Messwertdaten über die Aufbewahrungsdauer hinausgehen, 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