Benutzerdefinierte Messwerte

Mit benutzerdefinierten Messwerten können Sie anwendungsspezifische oder clientseitige Systemdaten erfassen. Die integrierten Messwerte von Cloud Monitoring geben Ihnen Informationen zur Back-End-Latenz oder Laufwerknutzung, lassen sich aber beispielsweise nicht darüber informieren, wie viele Hintergrundroutinen Ihre Anwendung verursacht hat. Sie können auch Messwerte erstellen, die auf dem Inhalt von Logeinträgen basieren. Informationen zu diesen benutzerdefinierten Messwerten finden Sie unter Logbasierte Messwerte.

Mit benutzerdefinierten Messwerten, auch anwendungsspezifische Messwerte genannt, können Sie 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 bereitgestellt wird, um Ihren Code zu instrumentieren. Anschließend senden Sie die Messwerte an eine Back-End-Anwendung wie Cloud Monitoring.

Sie können benutzerdefinierte Messwerte mithilfe der Cloud Monitoring API direkt erstellen. Wir empfehlen jedoch die Verwendung von OpenCensus. Informationen zum Erstellen benutzerdefinierter Messwerte finden Sie in den folgenden Dokumenten:

  • Unter Benutzerdefinierte Messwerte mit OpenCensus erstellen wird beschrieben, wie Sie OpenCensus verwenden, eine Open-Source-Bibliothek für Monitoring und Tracing. Mit dieser Bibliothek können Sie benutzerdefinierte Messwerte erstellen, ihnen Messwertdaten hinzufügen und sie nach Cloud Monitoring exportieren.

  • Unter Benutzerdefinierte Messwerte mit der API erstellen wird beschrieben, wie Sie benutzerdefinierte Messwerte mithilfe der Cloud Monitoring API erstellen und zu diesen Messwerten Messwertdaten hinzufügen. In diesem Dokument wird gezeigt, wie Sie die Monitoring API mit Beispielen für den APIs Explorer, die C#, Go, Java, Node.js, PHP, Python und Ruby nutzen.

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

  • Unter Messwerte und Ressourcentypen durchsuchen 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.
  • Im Artikel Lesen von Messwertdaten erfahren Sie, wie Sie mithilfe der Monitoring API Zeitachsendaten aus benutzerdefinierten und integrierten Messwerten 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.

Die Google Cloud Console bietet eine dedizierte Seite, auf der Sie sich Ihre Nutzung von benutzerdefinierten Messwerten ansehen können. Informationen zum Inhalt dieser Seite finden Sie unter Messwertdiagnosen.

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.

Wenn Sie benutzerdefinierte Messwerte verwenden, kann Cloud Monitoring den Messwertdeskriptor mit den von Ihnen geschriebenen Messwerten erstellen. Alternativ können Sie den Messwertdeskriptor explizit erstellen und dann Messwertdaten schreiben. In beiden Fällen müssen Sie festlegen, wie die Messwertdaten organisiert werden sollen.

Beispiel für ein Design

Angenommen, Sie haben ein Programm, das auf einer einzelnen Maschine ausgeführt wird und die Hilfsprogramme A und B aufruft. Sie möchten zählen, wie oft Programme A und B aufgerufen werden. Du möchtest außerdem wissen, wann das Programm A mehr als 10-mal pro Minute aufgerufen wird und wann das Programm B mehr als 5-mal pro Minute aufgerufen wird. Angenommen, Sie haben ein einzelnes Google Cloud-Projekt und möchten die Daten in die überwachte global-Ressource schreiben.

In diesem Beispiel werden verschiedene Designs beschrieben, die Sie für Ihre benutzerdefinierten Messwerte verwenden können:

  • Sie verwenden zwei benutzerdefinierte Messwerttypen: 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.

    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 benutzerdefinierten Messwert und verwenden ein Label, um eine Programm-ID zu speichern. Das Label könnte beispielsweise den Wert A oder B speichern. Monitoring erstellt eine Zeitachse für jede eindeutige Labelkombination. Es gibt daher eine Zeitachse, deren Labelwert A und eine andere Zeitachse mit dem Labelwert B ist.

    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 Anzahl 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 benutzerdefinierten Messwert, um die Anzahl der Aufrufe zu zählen, aber Sie nutzen kein Label, um aufzuzeichnen, 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 werden Ihre Anforderungen an die Datenanalyse erfüllt, beim letzten Design jedoch nicht.

Informationen zum Erstellen von Messwertdeskriptoren finden Sie unter Messwertdeskriptoren erstellen.

Namen benutzerdefinierter Messwerte

Wenn Sie einen benutzerdefinierten Messwert erstellen, definieren Sie eine Stringkennung, die den Messwerttyp darstellt. Dieser String muss unter den benutzerdefinierten Messwerten in Ihrem Google Cloud-Projekt eindeutig sein und muss ein Präfix verwenden, das den Messwert als benutzerdefinierten Messwert markiert. Für Monitoring sind die zulässigen Präfixe custom.googleapis.com/, external.googleapis.com/user und external.googleapis.com/prometheus zulässig. Das Präfix gefolgt von einem Namen, der die von Ihnen erfassten Daten beschreibt. Weitere Informationen zur empfohlenen Benennung von benutzerdefinierten 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 zeigt das Präfix custom.googleapis.com an, dass beide Messwerte benutzerdefinierte Messwerte sind. Beide Beispiele beziehen sich auf Messwerte, in denen die CPU-Auslastung gemessen wird. Sie werden jedoch mit unterschiedlichen Organisationsmodellen erstellt. Wenn Sie eine große Anzahl von benutzerdefinierten Messwerten erwarten, empfehlen wir die Verwendung einer hierarchischen Namensstruktur, wie im zweiten Beispiel verwendet.

Alle Messwerttypen haben weltweit eindeutige Kennzeichnungen namens Ressourcennamen. 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. Wählen Sie dazu den Typ der überwachten Ressource aus, aus dem die Daten stammen, und verwenden Sie diesen, um den Ursprung der Daten 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, während die überwachte Ressource den Ursprung der Daten beschreibt.

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 also einen benutzerdefinierten Messwert mit einer Compute Engine-VM-Ressource schreiben möchten, ist in den Ressourcenlabels die Instanz-ID enthalten. 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 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 viele Quellen von Messwerten in einem Projekt haben, kann die Verwendung desselben Ressourcenobjekts global zu Kollisionen 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 Verwendung mit
benutzerdefinierten Messwerten
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 in Bezug auf benutzerdefinierte Messwerte und zur Datenaufbewahrung finden Sie unter Kontingente und Limits.

Damit Ihre Messwertdaten über die Aufbewahrungsdauer hinaus beibehalten werden, 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.

Weitere Informationen