Google Cloud Observability – Preise

Mit den Preisen für Google Cloud Observability können Sie die Nutzung und Ausgaben kontrollieren. Die Preise für Google Cloud Observability-Produkte richten sich nach dem Datenvolumen oder der Nutzung. Sie können die kostenlosen Kontingente zur Datennutzung für den Einstieg ohne Vorabgebühren oder Verpflichtungen verwenden.

Die folgenden Tabellen enthalten eine Übersicht über die Preise für Cloud Logging, Cloud Monitoring und Cloud Trace.

Preisübersicht für Cloud Logging

Feature Preis1 Kostenloses Kontingent pro Monat Datum des Inkrafttretens
Logging-Speicher*
außer für gesendete Netzwerklogs
0,50 $/GiB;
Einmalige Gebühr für das Streamen von Logs in den Log-Bucket-Speicher zum Indexieren, Abfragen und Analysieren, einschließlich der Speicherung in Log-Buckets für bis zu 30 Tage. Keine zusätzlichen Kosten für die Abfrage und Analyse von Logdaten.
Erste 50 GiB/Projekt/Monat 1. Juli 2018
Verkaufte Netzwerkprotokollspeicher 0,25 $/GiB;
Einmalige Gebühr für das Streamen von Netzwerktelemetrielogs in den Log-Bucket-Speicher zum Indexieren, Abfragen und Analysieren; beinhaltet bis zu 30 Tage Speicherung in Log-Buckets. Keine zusätzlichen Kosten für die Abfrage und Analyse von Logdaten.
Nicht zutreffend 1. Oktober 2024:
Logging-Aufbewahrung 0,01 $ pro GiB und Monat für Logs, die länger als 30 Tage aufbewahrt werden; monatliche Abrechnung entsprechend der Aufbewahrungsdauer. Für Logs, die für die standardmäßige Aufbewahrungsdauer aufbewahrt werden, fallen keine Aufbewahrungskosten an. 01. Januar 2022
Protokollrouter Keine zusätzliche Gebühr Nicht zutreffend Nicht zutreffend
Loganalysen Keine zusätzliche Gebühr Nicht zutreffend Nicht zutreffend
*  Im Speichervolumen wird die tatsächliche Größe der Logeinträge vor der Indexierung ermittelt. Für Logs, die im Log-Bucket _Required gespeichert sind, fallen keine Speichergebühren an.
  Gesendete Logs sind Google Cloud-Netzwerklogs, die von Google Cloud-Diensten generiert werden, wenn die Generierung dieser Logs aktiviert ist. Zu den gesendeten Logs gehören VPC-Flusslogs, das Logging von Firewallregeln und Cloud NAT-Logs. Diese Logs unterliegen außerdem den Preisen für Netzwerktelemetrie. Weitere Informationen finden Sie unter Gesendete Logs.
  Für Logs, die im Log-Bucket _Required gespeichert sind, fallen keine Aufbewahrungsgebühren an. Dieser hat eine feste Aufbewahrungsdauer von 400 Tagen.
  Logrouting ist definiert als Weiterleitung von Logs, die über die Cloud Logging API an ein unterstütztes Ziel empfangen werden. Für weitergeleitete Logs können Gebühren je nach Ziel anfallen.
  Für das Upgrade eines Log-Buckets zur Verwendung von Loganalysen oder das Senden von SQL-Abfragen über die Seite Loganalysen fallen keine Kosten an.
Hinweis: Die Preissprache für Cloud Logging hat sich am 19. Juli 2023 geändert. Die kostenlosen Kontingente und Preise haben sich jedoch nicht geändert. Ihre Rechnung bezieht sich möglicherweise auf die alte Preissprache.

Preisübersicht für Cloud Monitoring

Feature Preis Kostenloses Kontingent pro Monat Datum des Inkrafttretens
Alle Monitoring-Daten
mit Ausnahme von Daten, die mit Managed Service for Prometheus aufgenommen wurden
0,2580 $/MiB1: erste 150–100.000 MiB
0,1510 $/MiB: nächste 100.000–250.000 MiB
0,0610 $/MiB: >250.000 MiB
Alle kostenlosen Google Cloud-Messwerte
Erste 150 MiB pro Rechnungskonto für Messwerte, die nach aufgenommenen Byte abgerechnet werden
1. Juli 2018
Messwerte, die mit Google Cloud Managed Service for Prometheus aufgenommen wurden, einschließlich Messwerte der GKE-Steuerungsebene 0,06 $/Million Stichproben: Erste 0–50 Milliarden aufgenommene Stichproben#
0,048 $/Million Stichproben: die nächsten 50–250 Milliarden aufgenommenen Stichproben
0,036 $/Million Stichproben: die nächsten 250–500 Milliarden aufgenommenen Stichproben
0,024 $/Million Stichproben: >500 Milliarden Stichproben
Nicht zutreffend 8. August 2023
Monitoring-API-Aufrufe 0,01 $/1.000 API-Leseaufrufe
(API-Schreibaufrufe kostenlos)
Erste Million API-Leseaufrufe pro Rechnungskonto inbegriffen 1. Juli 2018
Ausführung von Monitoring für Verfügbarkeitsdiagnosen 0,30 $/1.000 Ausführungen 1 Million Ausführungen pro Google Cloud-Projekt 1. Oktober 2022
Ausführung von Synthetischen Monitoring-Monitoring 1,20 $/1.000 Ausführungen* 100 Ausführungen pro Rechnungskonto 1. November 2023
Benachrichtigungsrichtlinien 1,50 $ pro Monat für jede Bedingung in einer Benachrichtigungsrichtlinie
0,35 $ pro 1.000.000 Zeitachsen, die durch die Abfrage einer Bedingung der Benachrichtigungsrichtlinie für Messwerte zurückgegeben werden
Nicht zutreffend April 2025
  Google Cloud Managed Service for Prometheus verwendet Cloud Monitoring-Speicher für extern erstellte Messwertdaten und die Monitoring API, um diese Daten abzurufen. Managed Service for Prometheus-Messtools basieren auf aufgenommenen Stichproben anstelle von Byte, um die Konventionen von Prometheus einzuhalten. Weitere Informationen zur stichprobenbasierten Messung finden Sie unter Preise für Kontrollierbarkeit und Vorhersehbarkeit. Berechnungsbeispiele finden Sie unter Preisbeispiele auf Basis der aufgenommenen Stichproben.
#  Die Beispiele werden pro Rechnungskonto gezählt.
  Ausführungen werden über das Rechnungskonto abgerechnet, in dem sie definiert sind. Weitere Informationen finden Sie unter Preise für die Ausführung von Verfügbarkeitsdiagnosen.
*  Ausführungen werden über das Rechnungskonto abgerechnet, in dem sie definiert sind. Für jede Ausführung können zusätzliche Gebühren durch andere Google Cloud-Dienste anfallen, einschließlich Diensten wie Cloud Run-Funktionen, Cloud Storage und Cloud Logging. Informationen zu diesen zusätzlichen Gebühren finden Sie in der Preisliste des jeweiligen Google Cloud-Dienstes.
  Weitere Informationen finden Sie unter Preise für Benachrichtigungen.

Preisübersicht für Cloud Trace

Feature Preis Kostenloses Kontingent pro Monat Gültig ab
Trace-Aufnahme 0,20 $/Million Spans Erste 2,5 Millionen Spans pro Abrechnungskonto 1. November 2018

Ausführliche Informationen zu den Kosten für Google Cloud Observability-Produkte finden Sie in den folgenden Abschnitten auf dieser Seite:

Informationen zu den GKE Enterprise-Preisen finden Sie unter GKE Enterprise.

Nutzung abrufen

Ihre aktuelle Nutzung finden Sie in der Google Cloud Console auf der Seite Cloud Billing-Berichte.

Zu Cloud Billing

Anhand Ihrer aktuellen Nutzungsdaten können Sie eine Kostenschätzung mit dem Preisrechner vornehmen.

Beispiel: In einer Konfiguration erzeugt jede Compute Engine-VM-Instanz monatlich 10 GiB an kostenpflichtigen Logs und 20 MiB an kostenpflichtigen Messwerten. Der Preisrechner gibt Ihnen einen Eindruck der zu erwartenden Cloud Monitoring- und Cloud Logging-Kosten:

1 VM 10 VMs 100 VMs 1.000 VMs
Messwertkosten pro Monat 0,00 $ 12,90 $ 477,30 $ 5.121,30 $
Logging-Kosten pro Monat 0,00 $ 25,00 $ 475,00 $ 4.975,00 $
Gesamtkosten: 0,00 $ 37,90 $ 952,30 $ 10.096,30 $

Abrechnungsbenachrichtigung konfigurieren

Um informiert zu werden, wenn Ihre abrechenbaren oder prognostizierten Kosten ein Budget überschreiten, können Sie auf der Seite Budgets und Benachrichtigungen der Google Cloud Console eine Benachrichtigung erstellen:

  1. Öffnen Sie in der Google Cloud Console die Seite Abrechnung.

    Zur Abrechnung

    Sie können diese Seite auch über die Suchleiste finden.

    Wenn Sie mehrere Cloud-Rechnungskonto haben, führen Sie einen der folgenden Schritte aus:

    • Wählen Sie zum Verwalten von Cloud Billing für das aktuelle Projekt die Option Zum verknüpften Rechnungskonto aus.
    • Wenn Sie lieber ein anderes Cloud-Rechnungskonto aufrufen möchten, wählen Sie Rechnungskonten verwalten und anschließend das Konto aus, für das Sie ein Budget festlegen möchten.
  2. Wählen Sie im Navigationsmenü für die Abrechnung Budgets und Benachrichtigungen aus.
  3. Klicken Sie auf Budget erstellen.
  4. Füllen Sie das Dialogfeld für das Budget aus. In diesem Dialogfeld wählen Sie Google Cloud-Projekte und -Produkte aus und erstellen anschließend ein Budget für die ausgewählte Kombination. Standardmäßig werden Sie informiert, sobald Sie 50 %, 90 % bzw. 100 % des Budgets erreichen. Die vollständige Dokumentation finden Sie unter Budgets und Budgetbenachrichtigungen festlegen.

Cloud Logging

Log-Buckets sind die Logging-Container, in denen Logdaten gespeichert werden. Logging berechnet die Menge der Logdaten, die im Log-Bucket _Default und in benutzerdefinierten Log-Buckets gespeichert sind. Die Preise gelten für nicht bereitgestellte Netzwerklogs, wenn das Volumen das kostenlose monatliche Kontingent überschreitet, sowie für ausgelieferte Netzwerklogs.

Für den Log-Bucket _Default und für benutzerdefinierte Log-Buckets fallen ebenfalls Kosten an, wenn Logs länger als die standardmäßige Aufbewahrungsdauer von 30 Tagen aufbewahrt werden.

Logging verursacht keine zusätzlichen Kosten für das Weiterleiten von Logs, die Verwendung der Cloud Logging API, die Konfiguration von Logbereichen oder für Logs, die im Log-Bucket _Required gespeichert sind, der eine feste Aufbewahrungsdauer von 400 Tagen hat.

Dieser Abschnitt enthält Informationen zu den folgenden Themen:

Eine Zusammenfassung der Preisinformationen finden Sie in der Preisübersicht für Cloud Logging.

Angaben zu den Limits für Ihre Loggingnutzung (u. a. die Aufbewahrungsdauer der Daten) finden Sie unter Kontingente und Limits.

Informationen zum Aufrufen Ihrer Cloud Logging-Nutzungsdaten finden Sie unter Rechnungen schätzen.

Cloud Logging-Speichermodell

Für jedes Google Cloud-Projekt werden von Logging automatisch zwei Log-Buckets erstellt: _Required und _Default. Für diese beiden Buckets erstellt Logging automatisch Logsenken mit den Namen _Required und _Default, die Logs an die entsprechenden Log-Buckets weiterleiten. Sie können die Senke _Required weder deaktivieren noch ändern. Sie können die Senke _Default deaktivieren oder anderweitig ändern, um zu verhindern, dass im Bucket _Default neue Logs gespeichert werden.

Sie können in jedem Ihrer Google Cloud-Projekte benutzerdefinierte Log-Buckets erstellen. Sie können auch Senken konfigurieren, um beliebige Kombinationen von Logs, auch aus Google Cloud-Projekten in Ihrer Google Cloud-Organisation, an diese Log-Buckets weiterzuleiten.

Für den Log-Bucket _Default und für benutzerdefinierte Log-Buckets können Sie eine benutzerdefinierte Aufbewahrungsdauer konfigurieren.

Sie können Ihre Log-Buckets für die Verwendung von Loganalysen aktualisieren. Für das Upgrade eines Log-Buckets zur Verwendung von Loganalysen fallen keine Kosten an.

Weitere Informationen zu Cloud Logging-Buckets und -Senken finden Sie unter Routing und Speicher.

Speicherpreise

Logging berechnet keine Gebühren für Logs, die im Bucket _Required gespeichert sind. Sie können den Bucket _Required nicht löschen oder die Senke _Required ändern. Im Bucket _Required werden die folgenden Logs gespeichert:

In Logging wird das vorab indexierte Volumen an Logdaten in Rechnung gestellt, die im Log-Bucket _Default und in benutzerdefinierten Log-Buckets gespeichert sind, wenn das Gesamtvolumen das kostenlose monatliche Kontingent überschreitet. Jeder Schreibvorgang in den Log-Bucket _Default oder in einen benutzerdefinierten Log-Bucket wird auf Ihr Speicherkontingent angerechnet. Wenn Sie beispielsweise Senken haben, die einen Logeintrag an drei Log-Buckets weiterleiten, wird dieser Logeintrag dreimal gespeichert.

Preise für die Kundenbindung

In der folgenden Tabelle sind die Datenaufbewahrungsdauer für Logs aufgeführt, die in Log-Buckets gespeichert sind:

Bucket Standardmäßige Aufbewahrungsdauer Benutzerdefinierte Aufbewahrung
_Required 400 Tage Nicht konfigurierbar
_Default 30 Tage Konfigurierbar
Benutzerdefiniert 30 Tage Konfigurierbar

Logging berechnet Aufbewahrungskosten, wenn die Logs länger als die standardmäßige Aufbewahrungsdauer aufbewahrt werden. Sie können die Aufbewahrungsdauer für den Log-Bucket _Required nicht konfigurieren. Wenn Logs nur für die standardmäßige Aufbewahrungsdauer des Log-Buckets gespeichert werden, fallen keine Aufbewahrungskosten an.

Wenn Sie die Aufbewahrungsdauer eines Log-Buckets verkürzen, gibt es einen siebentägigen Kulanzzeitraum, in dem abgelaufene Logs nicht gelöscht werden. Abgelaufene Logs können nicht abgefragt oder angezeigt werden. In diesen sieben Tagen können Sie jedoch den vollen Zugriff wiederherstellen, indem Sie die Aufbewahrungsdauer des Log-Buckets verlängern. Logs, die während des Kulanzzeitraums gespeichert werden, werden auf Ihre Aufbewahrungskosten angerechnet.

Wenn Sie einen Logeintrag an mehrere Log-Buckets weiterleiten, können Speicher- und Aufbewahrungskosten mehrmals berechnet werden. Angenommen, Sie leiten einen Logeintrag an den Log-Bucket _Default und an einen benutzerdefinierten Log-Bucket weiter. Angenommen, Sie konfigurieren für beide Buckets eine benutzerdefinierte Aufbewahrungsdauer von mehr als 30 Tagen. Für diese Konfiguration werden zwei Speichergebühren und zwei Aufbewahrungsgebühren berechnet.

Gelieferte Netzwerkprotokolle

Gekaufte Netzwerkprotokolle sind nur verfügbar, wenn Sie die Generierung von Protokollen konfigurieren. Bei Diensten, die veröffentlichte Netzwerkprotokolle generieren, fallen Gebühren für die Generierung an. Wenn Sie diese Logs in einem Log-Bucket speichern oder an ein anderes unterstütztes Ziel weiterleiten, fallen außerdem Gebühren von Cloud Logging oder dem Ziel an. Informationen zu den Kosten für die Loggenerierung finden Sie unter Preise für Netzwerktelemetrie.

Informationen zum Aktivieren von ausgegebenen Netzwerklogs finden Sie unter VPC-Flusslogs konfigurieren, Logging von Firewallregeln verwenden und Cloud NAT: Logs und Messwerte.

Filtern Sie im Log-Explorer nach den folgenden Lognamen, um die ausgegebenen Netzwerklogs zu finden:

  • projects/PROJECT_ID/logs/compute.googleapis.com%2Fvpc_flows
  • projects/PROJECT_ID/logs/compute.googleapis.com%2Ffirewall
  • projects/PROJECT_ID/logs/compute.googleapis.com%2Fnat_flows
  • projects/PROJECT_ID/logs/networkmanagement.googleapis.com%2Fvpc_flows

Logspeicher reduzieren

Konfigurieren Sie zum Reduzieren der Cloud Logging-Speicherkosten Ausschlussfilter für Ihre Logsenken, um bestimmte Logs von der Weiterleitung auszuschließen. Ausschlussfilter können alle Logeinträge, die dem Filter entsprechen, oder nur einen Teil der Logs entfernen. Wenn ein Logeintrag mit einem Ausschlussfilter einer Senke übereinstimmt, leitet die Senke den Logeintrag nicht an das Ziel weiter. Ausgeschlossene Logeinträge werden nicht auf Ihr Speicherkontingent angerechnet. Eine Anleitung zum Festlegen von Ausschlussfiltern finden Sie unter Logausschlüsse.

Eine weitere Möglichkeit zur Reduzierung Ihrer Cloud Logging-Speicherkosten besteht darin, Logs von Cloud Logging an ein unterstütztes Ziel weiterzuleiten. Das Weiterleiten von Logs an unterstützte Ziele ist in Cloud Logging kostenlos. Es können jedoch Gebühren anfallen, wenn Logs von einem Ziel empfangen werden:

Informationen zum Weiterleiten von Logs aus Cloud Logging finden Sie unter Logs an unterstützte Ziele weiterleiten.

Preise für logbasierte Messwerte

Systemdefinierte logbasierte Messwerte werden für alle Google Cloud-Projekte bereitgestellt und sind kostenlos.

Benutzerdefinierte logbasierte Messwerte sind eine Klasse von Cloud Monitoring-benutzerdefinierten Messwerten und sind kostenpflichtig. Details zu den Preisen finden Sie unter Kostenpflichtige Messwerte.

Weitere Informationen finden Sie in der Übersicht zu logbasierten Messwerten.

Benachrichtigungsrichtlinie für aufgenommene Logbyte pro Monat erstellen

Verwenden Sie die folgenden Einstellungen, um eine Benachrichtigungsrichtlinie zu erstellen, sodass Sie benachrichtigt werden, wenn die Anzahl der in Ihre Log-Buckets geschriebenen Logbyte Ihr benutzerdefiniertes Limit für Cloud Logging überschreitet.

Neue Bedingung
Feld

Wert
Ressource und Messwert Wählen Sie im Menü Ressourcen die Option Global aus.
Wählen Sie im Menü Messwertkategorien die Option Logbasierter Messwert aus.
Wählen Sie im Menü Messwerte die Option Monthly log bytes amount (Aufgenommene Log-Daten pro Monat) aus.
Filter Keine.
Über Zeitreihen hinweg
Zeitreihenaggregation
sum
Rollierendes Zeitfenster 60 m
Funktion für rollierendes Zeitfenster max
Benachrichtigungstrigger konfigurieren
Feld

Wert
Bedingungstyp Threshold
Benachrichtigungstrigger Any time series violates
Grenzwertposition Above threshold
Grenzwert Sie legen den akzeptablen Wert fest.
Zeitfenster noch einmal testen Der kleinste akzeptable Wert liegt bei 30 Minuten.

Cloud Monitoring

Bei Monitoring wird Folgendes in Rechnung gestellt:

  • Messwerte, die nach Byte aufgenommen werden, wenn die aufgenommenen Messwertdaten das kostenlose monatliche Messwertkontingent überschreiten.

    Kostenlose Messwerte werden nicht auf das Kontingent angerechnet.

  • Messwerte, gemessen an der Anzahl der aufgenommenen Beispiele.

  • Cloud Monitoring API-Leseaufrufe, die das kostenlose monatliche API-Kontingent überschreiten.

    Monitoring API-Schreibaufrufe werden nicht auf das Kontingent angerechnet.

  • Ausführung von Verfügbarkeitsdiagnosen

  • Ausführung von synthetischen Monitorings

  • Bedingungen für Benachrichtigungsrichtlinien, gemessen an der Anzahl der aktiven Bedingungen pro Monat.

  • Von der Abfrage einer Bedingung einer Benachrichtigungsrichtlinie zurückgegebene Zeitreihe.

In Monitoring bezieht sich Aufnahme auf das Schreiben von Zeitachsen in Monitoring. Jede Zeitachse enthält eine bestimmte Anzahl von Datenpunkten. Diese Datenpunkte bilden die Grundlage für die Aufnahmekosten. Preisinformationen finden Sie unter Cloud Monitoring-Preise.

In diesem Abschnitt finden Sie folgende Informationen:

Aktuelle Preisinformationen finden Sie unter Cloud Monitoring-Preise.

Angaben zu den Limits für Ihre Monitoring-Nutzung finden Sie unter Kontingente und Limits.

Führen Sie einen der folgenden Schritte aus, um Ihre aktuelle Nutzung anzusehen:

  • Öffnen Sie in der Google Cloud Console die Seite Abrechnung.

    Zur Abrechnung

    Sie können diese Seite auch über die Suchleiste finden.

  • Öffnen Sie in der Google Cloud Console die Seite Einstellungen.

    Einstellungenaufrufen

    Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Monitoring ist.

Anhand Ihrer aktuellen Nutzungsdaten können Sie eine Kostenschätzung vornehmen.

Kostenlose Messwerte

Messwertdaten von Google Cloud, GKE Enterprise und Knative sind kostenlos. Dazu gehören:

Kostenpflichtige Messwerte

Alle Messwertdaten, mit Ausnahme der im Abschnitt Kostenlose Messwerte aufgeführten Messwerte, sind kostenpflichtig. Die meisten Messwerte werden nach der Anzahl der Byte abgerechnet, andere nach der Anzahl der Stichproben. Diese Preismodelle werden in den folgenden Abschnitten beschrieben.

Die folgenden Faktoren tragen zu den Datenaufnahmekosten bei:

  • Der Typ der Datenpunkte – Skalarwerte oder Verteilungswerte – die von den Messwerten erfasst werden.

    • Informationen zu dem Datentyp, der einem bestimmten Messwerttyp zugeordnet ist, finden Sie in der Liste der Messwerte.
    • Weitere Informationen zu skalaren und Verteilungsdatentypen finden Sie unter Werttypen.
  • Die Anzahl der Datenpunkte, die in eine Zeitreihe geschrieben werden. Dieser Wert hängt von der Häufigkeit, mit der die Daten erhoben werden, und von der Kardinalität der Daten ab. Die Kardinalität bestimmt, wie viele Zeitachsen für eine Kombination aus Messwert- und überwachten Ressourcentypen generiert werden. Weitere Informationen finden Sie unter Kardinalität.

Die Werte für die Messwert- und Ressourcenlabels, die zu Ihrer Zeitachse gehören, werden bei Ihren Kosten nicht berücksichtigt.

Messwerte, die nach aufgeommenen Byte berechnet werden

Die folgenden Messwerte sind kostenpflichtig und werden nach der Anzahl der aufgenommenen Byte berechnet:

Zur Preisberechnung wird das Aufnahmevolumen so berechnet:

  • Bei einem skalaren Datentyp: 8 Byte für jeden in eine Zeitachse geschriebenen Datenpunkt. In diese Kategorie fallen benutzerdefinierte logbasierte Zählermesswerte.
  • Für einen Verteilungsdatentyp: 80 Byte für jeden in eine Zeitachse geschriebenen Datenpunkt.

Informationen zu Datenpunkten in Zeitachsen finden Sie unter Zeitachse: Daten aus einer überwachten Ressource.

Von aufgenommenen Beispielen berechnete Messwerte

Die folgenden Messwerte sind kostenpflichtig und werden nach der Anzahl der aufgenommenen Beispiele berechnet:

Zur Preisberechnung wird die Beispielzahl so berechnet:

  • Bei einem skalaren Datentyp: 1 für jeden in eine Zeitachse geschriebenen Punkt.
  • Für einen Verteilungsdatentyp: 2 für jeden in eine Zeitachse geschriebenen Punkt plus 1 für jeden Histogramm-Bucket, dessen Anzahl nicht null ist.

Informationen zu Datenpunkten in Zeitachsen finden Sie unter Zeitachse: Daten aus einer überwachten Ressource.

Benachrichtigungen über aufgenommene Messwerte

Es ist nicht möglich, eine Benachrichtigung auf Grundlage der monatlich aufgenommenen Messwerte zu erstellen. Sie können jedoch eine Benachrichtigung über Ihre Cloud Monitoring-Kosten anlegen. Weitere Informationen finden Sie unter Abrechnungsbenachrichtigung konfigurieren.

Preisbeispiele auf der Grundlage der aufgenommenen Byte

Die folgenden Beispiele veranschaulichen, wie Sie eine Schätzung der Kosten für das Erfassen von Messwertdaten für Messwerte erhalten, die nach aufgenommenen Byte abgerechnet werden. Diese Beispiele sollen die Berechnungen veranschaulichen. Für umfassende Schätzungen können Sie den Preisrechner verwenden. Wenn Sie auf dieses Tool zugreifen, verwenden Sie das Google Cloud Observability-Produkt, um Ihre Messwert-, Logging- und Trace-Daten einzugeben.

Das grundlegende Szenario sieht so aus: Sie haben eine bestimmte Anzahl überwachter Ressourcen wie Compute Engine, Kubernetes Engine oder App Engine, die jeden Monat Daten von einer bestimmten Anzahl von Messwerten schreiben.

Die verschiedenen Szenarien umfassen folgende Variablen:

  • Die Anzahl der Ressourcen
  • Die Anzahl der Messwerte
  • Ob die Messwerte Google Cloud-Messwerte sind oder nicht
  • Die Rate, mit der die Messwertdaten geschrieben werden

Die Beispiele in diesem Abschnitt beruhen auf den Monitoring-Preisen vom Juli 2020.

Gemeinsamer Hintergrund

In den folgenden Preisbeispielen wird angenommen, dass die aufgenommenen Messwert-Datenpunkte den Typ „double“, „int64“ oder „bool“ haben. Diese zählen für die Ermittlung der Kosten jeweils als 8 Byte. Ein Monat hat ungefähr 730 Stunden (365 Tage ÷ 12 Monate × 24 Stunden) oder 43.800 Minuten.

Für einen Messwert, der Daten einen Monat lang mit einer Rate von 1 Datenpunkt pro Minute schreibt, ergibt sich Folgendes:

  • Datenpunkte insgesamt: 43.800
  • Aufgenommenes Volumen insgesamt:
    • 350.400 Byte (43.800 Datenpunkte × 8 Byte)
    • 0,33416748 MiB (350.400 Byte ÷ 1.048.576 Byte/MiB)

Für einen Messwert, der Daten einen Monat lang mit einer Rate von 1 Datenpunkt pro Stunde schreibt, ergibt sich Folgendes:

  • Datenpunkte insgesamt: 730
  • Aufgenommenes Volumen insgesamt:
    • 5.840 Byte (730 Datenpunkte × 8 Byte)
    • 0,005569458 MiB (5.840 Byte ÷ 1.048.576 Byte/MiB)

Beispiele

Szenario 1: Sie haben 1.000 Ressourcen, die jeweils 75 Messwerte schreiben. Dies sind Messwerte, die nur aus Google Cloud stammen und mit einer Rate von 1 Datenpunkt pro Minute geschrieben werden.

  • Monatliche Datenaufnahme: 25.063 MiB = 0,33416748 MiB für einen Messwert × 75.000 (also 1.000 Ressourcen, 75 Messwerte)
  • Ungefähre Kosten pro Monat: 0,00 $ (Google Cloud-Messwerte sind kostenlos enthalten)
Datenaufnahme in MiB Preis ($/MiB) Kosten ($)
Unbegrenzt 0,00 0,00 $
Summe 25.063 0,00 $

Szenario 2: Sie haben 1.000 Ressourcen, die jeweils 75 Messwerte schreiben. Dies sind kostenpflichtige Messwerte, die mit einer Rate von 1 Datenpunkt pro Minute geschrieben werden.

  • Monatliche Datenaufnahme: 25.063 MiB (wie oben)
  • Ungefähre Kosten pro Monat: 6.427,55 $
Datenaufnahme in MiB Preis ($/MiB) Kosten ($)
150 0,00 0,00 $
24.913 0,258 6.427,55 $
Summe 25.063 6.427,55 $

Szenario 3: Sie haben 1.000 Ressourcen, die jeweils 75 benutzerdefinierte Messwerte schreiben. Dies sind kostenpflichtige Messwerte, die mit einer Rate von 1 Datenpunkt pro Stunde geschrieben werden.

  • Monatliche Datenaufnahme: 418 MiB = 0,005569458 MiB für einen Messwert × 75.000
  • Ungefähre Kosten pro Monat: 69,14 $
Datenaufnahme in MiB Preis ($/MiB) Kosten ($)
150 0,00 0,00 $
267 0,258 69,14 $
Summe 417 69,14 $

Szenario 4: Sie haben eine Ressource, die 500.000 Messwerte schreibt. Dies sind kostenpflichtige Messwerte, die mit einer Rate von 1 Datenpunkt pro Minute geschrieben werden.

  • Monatliche Datenaufnahme: 167.084 MiB = 0,33416748 MiB für einen Messwert × 500.000
  • Ungefähre Kosten pro Monat: 35.890,98 $
Datenaufnahme in MiB Preis ($/MiB) Kosten ($)
150 0,00 0,00 $
99.850 0,258 25.761,30 $
67.084 0,151 10.129,68 $
Summe 167.084 35.890,98 $

Preise für Kontrollierbarkeit und Vorhersehbarkeit

Die Preise für Managed Service for Prometheus sind steuerbar. Da die Abrechnung auf Basis pro Beispiel erfolgt, können Sie die folgenden Faktoren zur Kostenkontrolle nutzen:

  • Entnahmezeitraum: Wenn Sie den Messwert-Scraping-Zeitraum von 15 Sekunden auf 60 Sekunden ändern, können Sie Einsparungen von 75 % erzielen, ohne die Kardinalität zu beeinträchtigen. Sie können Entnahmezeiträume pro Job, pro Ziel oder global konfigurieren.

  • Filtern: Sie können die Filterung verwenden, um die Anzahl der Stichproben zu reduzieren, die an den globalen Datenspeicher des Dienstes gesendet werden. Weitere Informationen finden Sie unter Exportierte Messwerte filtern. Verwenden Sie Konfigurationen für die Messwertumbenennung in Ihrer Prometheus-Scraping-Konfiguration, um Messwerte bei der Aufnahme anhand von Label-Matchern zu löschen.

  • Halten Sie Daten mit hoher Kardinalität und niedrigem Wert lokal. Sie können Standard-Prometheus zusammen mit dem verwalteten Dienst mit denselben Scape-Konfigurationen ausführen und Daten lokal speichern, die sich nicht lohnen, an den globalen Datenspeicher des Dienstes zu senden.

Die Preise für Managed Service for Prometheus sind vorhersehbar.

  • Sie werden nicht für dünnbesetzte Histogramme bestraft. Beispiele werden nur für den ersten Wert ungleich null gezählt und dann, wenn der Wert für den Bucket gilt.n ist größer als der Wert in Bucketn–1. Ein Histogramm mit den Werten 10 10 13 14 14 14 zählt beispielsweise drei Beispiele für den ersten, dritten und vierten Bucket.

    Je nachdem, wie viele Histogramme Sie verwenden und wofür sie verwendet werden, kann der Ausschluss unveränderter Buckets von der Preisgestaltung dazu führen, dass 20 bis 40 % weniger Beispiele für Abrechnungen gezählt werden als die absolute Anzahl der Histogramm-Buckets deuten würde.

  • Bei einer Abrechnung pro Beispiel werden Ihnen keine Kosten für schnell skalierte und unskalierte, sitzungsspezifische Container oder Container auf Abruf berechnet, die von HPA oder GKE Autopilot erstellt wurden.

    Wenn Managed Service for Prometheus pro Messwert berechnet wird, zahlen Sie jedes Mal, wenn ein neuer Container hochgefahren wird, die Kardinalität eines ganzen Monats auf einmal. Bei diesem Preismodell zahlen Sie nur, während der Container ausgeführt wird.

Abfragen, einschließlich Benachrichtigungsabfragen

Alle vom Nutzer ausgegebenen Abfragen, einschließlich Abfragen, die bei der Ausführung von Prometheus-Aufzeichnungsregeln gestellt werden, werden über Cloud Monitoring API-Aufrufe abgerechnet. Die aktuellen Preise finden Sie in der Übersichtstabelle für die Preise für Managed Service for Prometheus und die Preise für Monitoring.

Preisbeispiele basierend auf aufgenommenen Beispielen

Die folgenden Beispiele veranschaulichen, wie die Kosten für das Erfassen von Messwerten, die nach aufgenommenen Stichproben berechnet werden, geschätzt werden. Die stichprobenbasierte Abrechnung wird für Google Cloud Managed Service for Prometheus verwendet.

Diese Beispiele sollen Berechnungsverfahren veranschaulichen, nicht die Bereitstellung von Abrechnungsdaten.

Das grundlegende Szenario sieht so aus: Sie haben eine bestimmte Anzahl von Containern oder Pods, die jeden Monat Punkte in eine bestimmte Anzahl von Zeitachsen schreiben. Die Daten können aus skalaren Werten oder Verteilungen bestehen.

Die verschiedenen Szenarien umfassen folgende Variablen:

  • Die Anzahl der Container oder Pods.
  • Die Anzahl der Zeitreihen.
  • Ob die Daten aus Skalarwerten und/oder Verteilungen bestehen.
  • Die Rate, mit der die Daten geschrieben werden.

Beispiele zählen

Bevor Sie Preise schätzen können, müssen Sie wissen, wie Beispiele gezählt werden. Die Anzahl der für einen Wert gezählten Beispiele hängt von folgenden Faktoren ab:

  • Ob der Wert ein Skalar oder eine Verteilung ist
  • Die Rate, mit der die Werte geschrieben werden

In diesem Abschnitt wird beschrieben, wie Sie die Anzahl der für eine Zeitreihe erstellten Stichproben im monatlichen Abrechnungszeitraum schätzen.

Ein Monat dauert etwa 730 Stunden (365 Tage / 12 Monate * 24 Stunden), 43.800 Minuten oder 2.628.000 Sekunden.

Wenn eine Zeitachse skalare Werte schreibt, zählt jeder Wert als eine Stichprobe. Die Anzahl der Beispiele, die in einem Monat geschrieben werden, hängt nur davon ab, wie häufig die Werte geschrieben werden. Betrachten Sie folgende Beispiele:

  • Für Werte, die alle 15 Sekunden geschrieben werden:
    • Schreibrate: 1 Wert/15 s = 1 Beispiel/15 s
    • Beispiele pro Monat: 175.200 (1 Beispiel/15 Sekunden * 2.628.000 Sekunden/Monat)
  • Für Werte, die alle 60 Sekunden geschrieben werden:
    • Schreibrate: 1 Wert/60 s = 1 Beispiel/60 s
    • Beispiele pro Monat: 43.800 (1 Beispiel/60 s * 2.628.000 Sekunden/Monat)

Wenn eine Zeitachse Verteilungswerte schreibt, kann jeder Wert 2 + n Stichproben enthalten, wobei n die Anzahl der Buckets im Histogramm ist. Die Anzahl der Beispiele, die in einem Monat geschrieben werden, hängt von der Anzahl der Buckets in Ihren Histogrammen und der Häufigkeit ab, mit der die Werte geschrieben werden.

Beispielsweise kann jede Instanz eines 50-Bucket-Histogramms 52 Beispiele enthalten. Wenn die Werte einmal alle 60 Sekunden geschrieben werden, schreibt ein Histogramm mit 50 Buckets höchstens 2.277.600 Beispiele pro Monat. Wenn das Histogramm 100 Buckets hat und einmal alle 60 Sekunden geschrieben wird, kann jedes Histogramm 102 Beispiele enthalten und schreibt maximal 4.467.600 Beispiele pro Monat.

Die meisten Zeitachsen für Verteilung enthalten weniger als die maximale Anzahl von Beispielen. In der Praxis sind zwischen 20 % und 40 % der Histogramm-Buckets leer. Dieser Prozentsatz ist für Nutzer mit dünnbesetzten Histogrammen, z. B. solchen, die von Istio generiert wurden, noch höher.

Beim Zählen der Beispiele für die Preise werden nur Buckets mit nicht leeren Werten berücksichtigt. Die maximale Anzahl von Beispielen pro Histogramm beträgt 2 + n . Wenn 25 % Ihrer Buckets leer sind, beträgt die erwartete Anzahl von Beispielen 2 + 0,75n pro Histogramm. Wenn 40 % Ihrer Buckets leer sind, beträgt die erwartete Anzahl von Beispielen 2 + 0,60n pro Histogramm.

Die folgende Berechnungs- und Übersichtstabelle zeigt die maximale Anzahl von Beispielen und eine realistischere erwartete Anzahl von Beispielen:

  • Für 50-Bucket-Histogrammwerte, die alle 15 Sekunden geschrieben werden:

    • Schreibrate: 1 Wert/15 s
    • Maximale Anzahl von Stichproben:
      • Pro Histogramm: 52
      • Pro Monat: 9.110.400 (52 * 1 Wert/15 s * 2.628.000 Sekunden/Monat)
    • Erwartete Beispiele, wenn 25 % leer sind:
      • Pro Histogramm: 39,5 (2 + 0,75(50) oder 2 + (50–12,5))
      • Pro Monat: 6.920.400 (39,5 * 1 Wert/15 s * 2.628.000 Sekunden/Monat)
    • Erwartete Beispiele, wenn 40 % leer sind:
      • Pro Histogramm: 32 (2 + 0,6(50) oder 2 + (50 - 20))
      • Pro Monat: 5.606.400 (32 * 1 Wert/15 s * 2.628.000 Sekunden/Monat)
  • Für 50-Bucket-Histogrammwerte, die alle 60 Sekunden geschrieben werden:

    • Schreibrate: 1 Wert/60 s
    • Maximale Anzahl von Stichproben:
      • Pro Histogramm: 52
      • Pro Monat: 2.277.600 (52 * 1 Wert/60 s * 2.628.000 Sekunden/Monat)
    • Erwartete Beispiele, wenn 25 % leer sind:
      • Pro Histogramm: 39,5 (2 + 0,75(50) oder 2 + (50–12,5))
      • Pro Monat: 1.730.100 (39,5 * 1 Wert/60 s * 2.628.000 Sekunden/Monat)
    • Erwartete Beispiele, wenn 40 % leer sind:
      • Pro Histogramm: 32 (2 + 0,6(50) oder 2 + (50 - 20))
      • Pro Monat: 1.401.600 (32 * 1 Wert/60 s * 2.628.000 Sekunden/Monat)
  • Für 100-Bucket-Histogrammwerte, die alle 15 Sekunden geschrieben werden:

    • Schreibrate: 1 Wert/15 s
    • Maximale Anzahl von Stichproben:
      • Pro Histogramm: 102
      • Pro Monat: 17.870.400 (102 * 1 Wert/15 s * 2.628.000 Sekunden/Monat)
    • Erwartete Beispiele, wenn 25 % leer sind:
      • Pro Histogramm: 77 (2 + 0,75(100) oder 2 + (100–25))
      • Pro Monat: 13.490.400 (77 * 1 Wert/15 s * 2.628.000 Sekunden/Monat)
    • Erwartete Beispiele, wenn 40 % leer sind:
      • Pro Histogramm: 62 (2 + 0,6(100) oder 2 + (100–40))
      • Pro Monat: 10.862.400 (62 * 1 Wert/15 s * 2.628.000 Sekunden/Monat)
  • Für 100-Bucket-Histogrammwerte, die alle 60 Sekunden geschrieben werden:

    • Schreibrate: 1 Wert/60 s
    • Maximale Anzahl von Stichproben:
      • Pro Histogramm: 102
      • Pro Monat: 4.467.600 (102 * 1 Wert/60 s * 2.628.000 Sekunden/Monat)
    • Erwartete Beispiele, wenn 25 % leer sind:
      • Pro Histogramm: 77 (2 + 0,75(100) oder 2 + (100–25))
      • Pro Monat: 3.372.600 (77 * 1 Wert/60 s * 2.628.000 Sekunden/Monat)
    • Erwartete Beispiele, wenn 40 % leer sind:
      • Pro Histogramm: 62 (2 + 0,6(100) oder 2 + (100–40))
      • Pro Monat: 2.715.600 (62 * 1 Wert/60 s * 2.628.000 Sekunden/Monat)

In der folgenden Tabelle werden die soeben beschriebenen Informationen zusammengefasst:

Anzahl der Buckets Schreibrate Stichproben pro Monat
(max.)
Beispiele pro Monat
(25 % leer)
Beispiele pro Monat
(40 % leer)
50 1 Beispiel/15 s 9.110.400 6.920.400 5.606.400
50 1 Beispiel/60 s 2.277.600 1.730.100 1.401.600
100 1 Beispiel/15 s 17.870.400 13.490.400 10.862.400
100 1 Beispiel/60 s 4.467.600 3.372.600 2.715.600

Beispiele

Um die Preise zu schätzen, zählen Sie die Anzahl der Beispiele, die über einen Monat geschrieben wurden, und wenden Sie die Preiswerte an. Die Preise für Beispiele werden für gestapelte Bereiche folgendermaßen in Millionen abgerechnet:

Aufnahmebereich Verwalteter Dienst für Prometheus Maximum für Bereich
Bis zu 50 Milliarden (50.000 Millionen) 0,06 $/Million 3.000,00 $
50 Milliarden bis 250 Milliarden (250.000 Millionen) 0,048 $/Million $9.600,00
250 bis 500 Milliarden (500.000 Millionen) 0,036 $/Million 9.000,00 $
Mehr als 500 Milliarden (500.000 Millionen) 0,024 $/Million  

Im weiteren Verlauf dieses Abschnitts werden mögliche Szenarien durchgegangen.

Szenario 1: Sie haben 100 Container, die jeweils 1.000 skalare Zeitachsen schreiben.

Variante A: Wenn jede Zeitachse alle 15 Sekunden geschrieben wird (1 Stichprobe/15 s), beträgt die Anzahl der pro Monat geschriebenen Stichproben 17.520.000.000 (175.200 Stichproben/Monat * 1.000 Zeitachsen * 100 Container) oder 17.520 Millionen.

Variante B: Wenn jede Zeitachse alle 60 Sekunden geschrieben wird (1 Stichprobe/60 Sekunden), beträgt die Anzahl der pro Monat geschriebenen Stichproben 4.380.000.000 (43.800 Beispiele/Monat * 1.000 Zeitachsen * 100 Container) oder 4.380 Millionen.

In beiden Fällen sind weniger als 50.000 Millionen Stichproben vorhanden, sodass nur die erste Rate angewendet wird. Die anderen Tarife werden nicht berechnet.

Variante Aufgenommene Beispiele Aufnahmebereich Managed Service for Prometheus
(0,06 $, 0,048 $, 0,036 $, 0,024 $)
A (1 Stichprobe/15 s)



Gesamt
17.520 Millionen



17.520 Millionen
Bis zu 50.000 Millionen
Bis zu 250.000 Millionen
Bis zu 500.000 Millionen
Über 500.000 Millionen
1.051,20 $



1.051,20$
B (1 Stichprobe/60 s)



Gesamt
4.380 Millionen



4.380 Millionen
Bis zu 50.000 Millionen
Bis zu 250.000 Millionen
Bis zu 500.000 Millionen
Über 500.000 Millionen
262,80 $



262,80 $

Szenario 2: Sie haben 1.000 Container, die jeweils 1.000 skalare Zeitreihen schreiben.

Variante A: Wenn jede Zeitachse alle 15 Sekunden geschrieben wird (1 Stichprobe/15 s), beträgt die Anzahl der pro Monat geschriebenen Stichproben 175.200.000.000 oder 175.200 Millionen:

  • Die ersten 50.000 Millionen Beispiele werden zum ersten Preis berechnet.
  • Die restlichen 125.200 Millionen Beispiele werden zum zweiten Preis berechnet.
  • Zu den anderen Preisen fallen keine Stichproben an.

Variante B: Wenn jede Zeitachse alle 60 Sekunden geschrieben wird (1 Stichprobe/60 Sekunden), beträgt die Anzahl der pro Monat geschriebenen Stichproben 43.800.000.000 oder 43.800 Millionen. Dieser monatliche Wert beträgt weniger als 50.000 Millionen Beispiele, sodass nur der erste Preis gilt.

Variante Aufgenommene Beispiele Aufnahmebereich Managed Service for Prometheus
(0,06 $, 0,048 $, 0,036 $, 0,024 $)
A (1 Stichprobe/15 s)



Gesamt
50.000 Millionen
125.200 Millionen


175.200 Millionen
Bis zu 50.000 Millionen
Bis zu 250.000 Millionen
Bis zu 500.000 Millionen
Über 500.000 Millionen
3.000,00 $
6.009,60 $


9.009,60$
B (1 Stichprobe/60 s)



Gesamt
43.800 Millionen



43.800 Millionen
Bis zu 50.000 Millionen
Bis zu 250.000 Millionen
Bis zu 500.000 Millionen
Über 500.000 Millionen
2.628,00 $



2.628,00$

Szenario 3: Sie haben 100 Container, die jeweils 1.000 Zeitreihen mit je 100 Buckets schreiben. Sie erwarten, dass 25 % der Buckets leer sind.

Variante A: Wenn jede Zeitachse alle 15 Sekunden geschrieben wird (1 Stichprobe/15 s), beträgt die Anzahl der pro Monat geschriebenen Stichproben 1.349.040.000.000 (13.490.400 Beispiele pro Monat × 1.000 Zeitachsen × 100 Container) oder 1.349.040 Millionen.

  • Die ersten 50.000 Millionen Beispiele werden zum ersten Preis berechnet.
  • Die nächsten 200.000 Millionen Beispiele werden zum zweiten Preis berechnet.
  • Die nächsten 250.000 Millionen Stichproben werden zum dritten Preis abgerechnet.
  • Die verbleibenden 749.040 Millionen Stichproben werden zum vierten Preis abgerechnet.

Variante B: Wenn jede Zeitachse alle 60 Sekunden geschrieben wird (1 Stichprobe/60 Sekunden), beträgt die Anzahl der pro Monat geschriebenen Stichproben 337.260.000.000 (3.372.600 Beispiele pro Monat × 1.000 Zeitachsen × 100 Container) oder 337.260 Millionen.

  • Die ersten 50.000 Millionen Beispiele werden zum ersten Preis berechnet.
  • Die nächsten 200.000 Millionen Beispiele werden zum zweiten Preis berechnet.
  • Die verbleibenden 87.260 Millionen Beispiele werden zum dritten Preis berechnet.
Variante Aufgenommene Beispiele Aufnahmebereich Managed Service for Prometheus
(0,06 $, 0,048 $, 0,036 $, 0,024 $)
A (1 Stichprobe/15 s)



Gesamt
50.000 Millionen
200.000 Millionen
250.000 Millionen
749.040 Millionen
1.349.040 Millionen
Bis zu 50.000 Millionen
Bis zu 250.000 Millionen
Bis zu 500.000 Millionen
Über 500.000 Millionen
3.000,00 $
9.600,00 $
9.000,00 $
17.976,96 $
39.576,96$
B (1 Stichprobe/60 s)



Gesamt
50.000 Millionen
200.000 Millionen
87.260 Millionen

337.260 Millionen
Bis zu 50.000 Millionen
Bis zu 250.000 Millionen
Bis zu 500.000 Millionen
Über 500.000 Millionen
3.000,00 $
9.600,00 $
3.141,36 $

15.741,36$

Szenario 4: Sie haben 1.000 Container, die jeweils 10.000 Zeitreihen mit einer Verteilung von 100 Buckets schreiben. Sie erwarten, dass 40 % der Buckets leer sind.

Variante A: Wenn jede Zeitachse alle 15 Sekunden geschrieben wird (1 Stichprobe/15 s), beträgt die Anzahl der pro Monat geschriebenen Stichproben 108.624.000.000.000 (10.862.400 Stichproben/Monat × 10.000 Zeitachsen * 1.000 Container) oder 108.006.624,

  • Die ersten 50.000 Millionen Beispiele werden zum ersten Preis berechnet.
  • Die nächsten 200.000 Millionen Beispiele werden zum zweiten Preis berechnet.
  • Die nächsten 250.000 Millionen Stichproben werden zum dritten Preis abgerechnet.
  • Die verbleibenden 108.124.000 Millionen Stichproben werden zum vierten Satz abgerechnet.

Variante B: Wenn jede Zeitachse alle 60 Sekunden geschrieben wird (1 Stichprobe/60 Sekunden), beträgt die Anzahl der pro Monat geschriebenen Stichproben 27.156.000.000.000 (2.715.600 Stichproben/Monat × 10.000 Zeitachsen × 1.000 Container) = 27.156.000.

  • Die ersten 50.000 Millionen Beispiele werden zum ersten Preis berechnet.
  • Die nächsten 200.000 Millionen Beispiele werden zum zweiten Preis berechnet.
  • Die nächsten 250.000 Millionen Stichproben werden zum dritten Preis abgerechnet.
  • Die verbleibenden 26.656.000 Millionen Stichproben werden zum vierten Preis abgerechnet.
Variante Aufgenommene Beispiele Aufnahmebereich Managed Service for Prometheus
(0,06 $, 0,048 $, 0,036 $, 0,024 $)
A (1 Stichprobe/15 s)



Gesamt
50.000 Millionen
200.000 Millionen
250.000 Millionen
108.124.000 Millionen
108.624.000 Millionen
Bis zu 50.000 Millionen
Bis zu 250.000 Millionen
Bis zu 500.000 Millionen
Über 500.000 Millionen
3.000,00 $
9.600,00 $
9.000,00 $
2.594.976,00 $
2.616.576,00$
B (1 Stichprobe/60 s)



Gesamt
50.000 Millionen
200.000 Millionen
250.000 Millionen
26.656.000 Millionen
27.156.000 Millionen
Bis zu 50.000 Millionen
Bis zu 250.000 Millionen
Bis zu 500.000 Millionen
Über 500.000 Millionen
3.000,00 $
9.600,00 $
9.000,00 $
639.744,00 $
661.344,00$

Szenario 5: Sie haben Folgendes:

  • 1.000 Container, die jeweils 1.000 skalare Zeitachsen alle 15 Sekunden schreiben. Die Anzahl der pro Monat geschriebenen Beispiele liegt bei 175.200.000.000 oder 175.200 Millionen. (Szenario 2, Variante A)

  • 1.000 Container, die jeweils 10.000 Verteilungszeitreihen mit je 100 Buckets alle 15 Sekunden schreiben Sie erwarten, dass 40 % der Buckets leer sind. Die Anzahl der pro Monat geschriebenen Stichproben beträgt 108.624.000.000.000 oder 108.624.000 Millionen. (Szenario 4, Variante A)

Die Gesamtzahl der Beispiele pro Monat beträgt 108.799.200 (175.200 Millionen + 108.624.000 Millionen).

  • Die ersten 50.000 Millionen Beispiele werden zum ersten Preis berechnet.
  • Die nächsten 200.000 Millionen Beispiele werden zum zweiten Preis berechnet.
  • Die nächsten 250.000 Millionen Stichproben werden zum dritten Preis abgerechnet.
  • Die verbleibenden 108.299.200 Millionen Stichproben werden zum vierten Satz abgerechnet.
Variante Aufgenommene Beispiele Aufnahmebereich Managed Service for Prometheus
(0,06 $, 0,048 $, 0,036 $, 0,024 $)
2 A + 4 A



Gesamt
50.000 Millionen
200.000 Millionen
250.000 Millionen
108.299.200 Millionen
108.799.200 Millionen
Bis zu 50.000 Millionen
Bis zu 250.000 Millionen
Bis zu 500.000 Millionen
Über 500.000 Millionen
3.000,00 $
9.600,00 $
9.000,00 $
2.599.180,80 $
2.620.780,80$

Preise für die Ausführung von Verfügbarkeitsdiagnosen (Datum des Inkrafttretens: 1. Oktober 2022)

Monitoring-Gebühren für jede regionale Ausführung einer Verfügbarkeitsdiagnose, die über das kostenlose monatliche Kontingent von 1 Million Ausführungen hinausgeht. Eine Prüfung, die in drei Regionen ausgeführt wird, zählt als drei Ausführungen.

Die Kosten für die Ausführung von Verfügbarkeitsdiagnosen betragen 0,30 $pro 1.000 Ausführungen. Auf Ihrer Rechnung erscheint die SKU „CA14-D3DE-E67F“ für „Monitoring-Verfügbarkeitsdiagnosen“.

Die folgenden Beispiele veranschaulichen, wie die Kosten für das Ausführen von Verfügbarkeitsdiagnosen geschätzt werden können. Diese Beispiele sollen Berechnungsverfahren veranschaulichen, nicht die Bereitstellung von Abrechnungsdaten.

Ausführungen von Verfügbarkeitsdiagnosen zählen

Um die Kosten Ihrer Verfügbarkeitsdiagnosen zu schätzen, müssen Sie wissen, wie viele regionale Ausführungen in einem Monat erfolgen. Monitoring berechnet 0,30 $ pro 1.000 Ausführungen mit einem kostenlosen monatlichen Kontingent von 1 Million Ausführungen.

Mit der folgenden Berechnung können Sie die Kosten Ihrer Verfügbarkeitsdiagnosen schätzen:

(EXECUTIONS_PER_MONTH - 1,000,000) * .0003

Die Anzahl der Ausführungen für jede Verfügbarkeitsdiagnose hängt von den folgenden Konfigurationsoptionen ab:

  • Ausführungshäufigkeit der Verfügbarkeitsdiagnose: jede Minute, 5 Minuten, 10 Minuten oder 15 Minuten.

  • Die Anzahl der Regionen, in denen die Verfügbarkeitsdiagnose ausgeführt wird.

  • Die Anzahl der Ziele, für die die Verfügbarkeitsdiagnose konfiguriert ist. Wenn die Verfügbarkeitsdiagnose für eine einzelne VM konfiguriert ist, beträgt die Anzahl der Ziele 1. Wenn die Verfügbarkeitsdiagnose für eine Ressourcengruppe konfiguriert ist, entspricht die Anzahl der Ziele der Anzahl der Ressourcen in der Gruppe.

Wenn Sie eine Verfügbarkeitsdiagnose konfigurieren, geben Sie einen Standort für die Verfügbarkeitsdiagnose an und jeder Standort wird einer oder mehreren Regionen zugeordnet. In der folgenden Tabelle sind die gültigen Standorte für Verfügbarkeitsdiagnosen und die Regionen aufgeführt, denen sie zugeordnet sind:

Standort für Verfügbarkeitsdiagnosen-Konfiguration Umfasst Google Cloud-Regionen
ASIA_PACIFIC asia-southeast1
EUROPE europe-west1
SOUTH_AMERICA southamerica-east1
USA us-central1, us-east4, us-west1
GLOBAL Alle Regionen, die von anderen Standorten eingeschlossen sind

Sie müssen die Verfügbarkeitsdiagnosen so konfigurieren, dass sie in mindestens drei Regionen ausgeführt werden.

Wenn Sie die Anzahl der Ausführungen für eine Verfügbarkeitsdiagnose schätzen möchten, müssen Sie wissen, wie viele Regionen vom Standort der Verfügbarkeitsdiagnose abgedeckt werden:

  • ASIA_PACIFIC, EUROPE und SOUTH_AMERICA enthalten jeweils 1 Region.
  • USA umfasst 3 Regionen.
  • GLOBAL umfasst 6 Regionen.

Ein Monat hat etwa 730 Stunden (365 Tage ÷ 12 Monate × 24 Stunden) oder 43.800 Minuten.

  • Eine Verfügbarkeitsdiagnose, die so konfiguriert ist, dass sie einmal pro Minute in USA ausgeführt wird, wird in drei Regionen ausgeführt. Wenn diese Verfügbarkeitsdiagnose zur Überprüfung einer einzelnen VM konfiguriert ist, wird sie 131.400 (3 × 43.800) Mal pro Monat ausgeführt. Ist die Diagnose so konfiguriert, dass eine aus zehn Mitgliedern bestehende Ressourcengruppe geprüft wird, wird sie 1.314.000 (10 × 131.400) Mal pro Monat ausgeführt.

  • Eine Verfügbarkeitsdiagnose, die so konfiguriert ist, dass sie einmal pro Minute in ASIA_PACIFIC, EUROPE und USA ausgeführt wird, wird in 5 Regionen ausgeführt. Diese Verfügbarkeitsdiagnose wird 219.000 Mal pro Monat ausgeführt,wenn sie für ein einzelnes Ziel konfiguriert ist.

Die folgende Tabelle zeigt die stündliche und monatliche Ausführungsanzahl für eine einzelne Verfügbarkeitsdiagnose, die so konfiguriert ist, dass sie mit unterschiedlicher Häufigkeit in unterschiedlichen Regionen ausgeführt wird:

Häufigkeit der Prüfungsausführung (einmal alle):
Anzahl der Regionen
Stündliche Ausführungen
pro Ziel
Monatliche Ausführungen
pro Ziel
1 Minute 3
4
5
6
180
240
300
360
131.400
175.200
219.000
262.800
5 Minuten 3
4
5
6
36
48
60
72
26.280
35.040
43.000
52.660
10 Minuten 3
4
5
6
18
24
30
36
13.140
17.520
21.900
26.280
15 Minuten 3
4
5
6
12
16
20
24
8.760
11.680
14.600
17.520

Beispiele

Um die Preise zu schätzen, ermitteln Sie Ihre gesamten monatlichen Ausführungen und subtrahieren Sie 1.000.000. Für alle verbleibenden Ausführungen werden 0,30 $pro 1.000 Ausführungen berechnet .Multiplizieren Sie daher die verbleibenden Ausführungen mit 0, 0003.

(EXECUTIONS_PER_MONTH - 1,000,000) * .0003

Szenario 1: Sie haben eine Verfügbarkeitsdiagnose am Standort USA, die einmal pro Minute eine VM prüft. Diese Prüfung wird in 3 Regionen ausgeführt. Die Prüfung wird 131.400 Mal im Monat ausgeführt und kostet nichts.

Monatliche Ausführungen insgesamt
Kostenpflichtige monatliche Ausführungen
(über 1.000.000)
Kosten
(0,30 $ pro 1.000 Ausführungen)
131.400 0 0,00 $

Szenario 2: Sie haben eine Verfügbarkeitsdiagnose am Standort USA, die einmal pro Minute eine zehnköpfige Ressourcengruppe prüft. Diese Prüfung wird in 3 Regionen ausgeführt. Die Prüfung wird 10 × 131.400 Mal pro Monat ausgeführt und kostet 94,20 $pro Monat. Der einzige Unterschied zwischen diesem Szenario und Szenario 1 ist die Anzahl der Ziele.

Monatliche Ausführungen insgesamt
Kostenpflichtige monatliche Ausführungen
(über 1.000.000)
Kosten
(0,30 $ pro 1.000 Ausführungen)
1.314.000 (10 Ziele) 314.000 94,20 $

Szenario 3: Sie haben 10 GLOBAL-Verfügbarkeitsdiagnosen, von denen jede einmal pro Minute 1 VM prüft. Diese Prüfungen werden in 6 Regionen ausgeführt, sodass jede Prüfung 262.800 Mal pro Monat ausgeführt wird. Die Gesamtzahl der monatlichen Ausführungen beträgt 2.628.000 (10 * 262.800). Dieses Szenario kostet 488,40 $/Monat.

Monatliche Ausführungen insgesamt
Kostenpflichtige monatliche Ausführungen
(über 1.000.000)
Kosten
(0,30 $ pro 1.000 Ausführungen)
2.628.000 1.628.000 488,40 $

Szenario 4: Sie haben fünf Verfügbarkeitsdiagnosen am Standort USA, die alle fünf Minuten eine VM prüfen. Diese Prüfungen werden in 3 Regionen ausgeführt, sodass jede Prüfung 26.280 Mal pro Monat ausgeführt wird. Die Gesamtzahl der monatlichen Ausführungen für diese Gruppe von Prüfungen beträgt 105.120 (4 * 26.280).

Außerdem haben Sie 2 GLOBAL-Verfügbarkeitsdiagnosen, die alle 15 Minuten eine VM prüfen. Diese Prüfungen werden in 6 Regionen ausgeführt, sodass jede Prüfung 17.520 Mal pro Monat ausgeführt wird. Die Gesamtzahl der monatlichen Ausführungen für diese Gruppe von Prüfungen beträgt 35.040 (2 * 17.520).

Ihre gesamten monatlichen Ausführungen betragen 140.160 (105.120 + 35.040). Dieses Szenario kostet nichts.

Monatliche Ausführungen insgesamt
Kostenpflichtige monatliche Ausführungen
(über 1.000.000)
Kosten
(0,30 $ pro 1.000 Ausführungen)
140.160 0 0,00 $

Preise für die Ausführung von synthetischem Monitoring (Datum des Inkrafttretens: 1. November 2023)

Cloud Monitoring stellt die Kosten für jede Ausführung eines synthetischen Monitors in Rechnung, über das kostenlose monatliche Kontingent für 100 Ausführungen pro Rechnungskonto hinaus. Wenn Sie beispielsweise drei synthetische Monitore erstellen und jede so konfigurieren, dass sie alle 5 Minuten ausgeführt wird, ergibt sich eine Gesamtzahl von Ausführungen pro Monat von 26.784:

Number of executions per month =  3 synthetic monitors * 1 execution per monitor per 5 minutes *
                                  1440 minutes per day * 31 days per month
                               =  26,784

Um die Anzahl der kostenpflichtigen Ausführungen zu ermitteln, subtrahieren Sie das kostenlose Kontingent von der Gesamtzahl der Ausführungen und multiplizieren Sie dann das Ergebnis mit den Kosten:

Monatliche Ausführungen insgesamt
Kostenpflichtige monatliche Ausführungen
(über 100 Ausführungen pro Rechnungskonto)
Kosten
(1,20 $ pro 1.000 Ausführungen)
26.784 26.684 32,02 $

Preise für Benachrichtigungen

Ab April 2025 werden in Cloud Monitoring Benachrichtigungen in Rechnung gestellt. Das Preismodell sieht so aus:

  • 1,50 $ pro Monat für jede Bedingung in einer Benachrichtigungsrichtlinie.
  • 0,35 $ pro 1.000.000 Zeitachsen,die durch die Abfrage einer Bedingung der Messwertbenachrichtigungsrichtlinie zurückgegeben werden.

In diesem Abschnitt finden Sie folgende Informationen:

Definitionen

  • Bedingung: Die Bedingung einer Benachrichtigungsrichtlinie beschreibt, wann eine Ressource oder eine Gruppe von Ressourcen sich in einem Zustand befindet, der eine Antwort erfordert.

    Die Gebühr beträgt für jede Bedingung 1,50 US-Dollar pro Monat. Wenn Sie keine Gebühren für eine Bedingung mehr erheben möchten, müssen Sie die Benachrichtigungsrichtlinie löschen. Wenn Sie die Richtlinie zurückstellen oder deaktivieren, werden Ihnen trotzdem Kosten in Rechnung gestellt.

  • Messwert- und logbasierte Benachrichtigungsrichtlinien: Benachrichtigungsrichtlinien, die einen beliebigen Bedingungstyp außer Log-Übereinstimmungsbedingungen verwenden, sind Benachrichtigungsrichtlinien für Messwerte. Die Bedingungen der Benachrichtigungsrichtlinien für Messwerte geben Zeitachsen zurück. Während jedes Ausführungszeitraums führen Bedingungen in Messwertbenachrichtigungsrichtlinien ihre Abfragen an den Cloud Monitoring-Datenspeicher aus. Die zurückgegebenen Zeitachsen werden dann anhand eines Schwellenwerts ausgewertet, um festzustellen, ob die Benachrichtigungsrichtlinie ausgelöst wird.

    Logbasierte Benachrichtigungsrichtlinien verwenden Bedingungen für die Logübereinstimmung. Bei den Bedingungen für den Logabgleich wird keine Zeitachse zurückgegeben.

  • Ausführungszeitraum: Wie oft Cloud Monitoring Ihre Bedingung ausführt. Bei den meisten Bedingungstypen beträgt dieser 30 Sekunden und kann nicht geändert werden. Mit Bedingungen, die eine PromQL-Abfrage verwenden, kann dieser Zeitraum festgelegt werden. Weitere Informationen finden Sie unter Länge des Ausführungszeitraums erhöhen (nur PromQL).

  • Zurückgegebene Zeitachse: Während jedes Ausführungszeitraums führt eine Benachrichtigungsrichtlinie für Messwerte die Abfrage ihrer Bedingung im Cloud Monitoring-Datenspeicher aus. Cloud Monitoring gibt Zeitachsendaten als Antwort auf jede Abfrage zurück. Jede Zeitachse in der Antwort zählt als eine zurückgegebene Zeitachse.

    Die Anzahl der in einem Monat zurückgegebenen Zeitreihen wird durch drei Faktoren bestimmt:

    • Die Form und der Umfang der zugrunde liegenden Daten.
    • Die Filter und Aggregationen, die Sie in der Abfrage der Bedingung verwenden.
    • Ausführungszeitraum.

    Betrachten Sie beispielsweise eine Konfiguration, die Folgendes enthält:

    • 100 virtuelle Maschinen (VMs), wobei jede VM zu einem Dienst gehört.
    • Jede VM gibt einen Messwert aus, metric_name, der ein Label mit zehn Werten hat.
    • Insgesamt fünf Dienste.

    Da Sie 100 VMs haben, von denen jede 10 Zeitachsen generieren kann (eine für jeden Labelwert), haben Sie insgesamt 1.000 unterliegende Zeitachsen. Jede VM enthält auch ein Metadaten-ähnliches Label, das aufzeichnet, zu welchem Ihrer fünf Dienste die VM gehört.

    Sie können Ihre Benachrichtigungsrichtlinien mithilfe von PromQL auf folgende Arten konfigurieren, wobei jede Konfiguration zu einer anderen Anzahl von Zeitachsen führt, die pro Ausführungszeitraum zurückgegeben werden:

    Konfiguration PromQL-Abfrage Zurückgegebene Zeitreihen pro Zeitraum
    Keine Aggregation rate(metric_name[1m]) 1.000
    In VM aggregieren sum by (vm) (rate(metric_name[1m])) 100
    Zu Labelwert aggregieren sum by (label_key) (rate(metric_name[1m])) 10
    Zum Dienst aggregieren sum by (service) (rate(metric_name[1m])) 5
    Zu Labelwert und Dienst aggregieren sum by (service, label_key) (rate(metric_name[1m])) 50
    In der Flotte aggregieren sum (rate(metric_name[1m])) 1
    Zu einer VM filtern und aggregieren sum (rate(metric_name{vm="my_vm_name"}[1m])) 1
    Zu einem Dienst filtern und aggregieren sum (rate(metric_name{service="my_service_name"}[1m])) 1

Preisbeispiele

Die folgenden Beispiele finden in einem 30-tägigen Monat statt, was zu folgenden Bewertungszeiträumen führt:

  • 86.400 30-sekündige Ausführungszeiträume pro Monat
  • 172.800 15-sekündige Ausführungszeiträume pro Monat (nur PromQL-Abfragen)

Beispiel 1: Eine Richtlinie, wird zur VM aggregiert, 30 Sekunden

Verwenden Sie in diesem Beispiel die folgenden Konfigurationen:

Daten

  • 100 VMs
  • Jede VM gibt einen Messwert aus, metric_name
  • metric_name hat ein Label mit 10 Werten
Benachrichtigungsrichtlinie
  • Eine Benachrichtigungsbedingung
  • Bedingung wird auf VM-Ebene aggregiert
  • Ausführungszeitraum von 30 Sekunden
Resultierende Kosten
  • Bedingungskosten: 1 Bedingung × 1,50 $ pro Monat = 1,50 $ pro Monat
  • Kosten für Zeitachsen: 100 zurückgegebene Zeitachsen pro Periode × 86.400 Perioden pro Monat = 8,6 Millionen zurückgegebene Zeitachsen pro Monat × 0,35 $ pro Million Zeitachsen = 3,02 $ pro Monat
  • Gesamtkosten: 4,52 € pro Monat

Beispiel 2: 100 Richtlinien (eine pro VM), Zusammenfassung zur VM, 30 Sekunden

Verwenden Sie in diesem Beispiel die folgenden Konfigurationen:

Daten

  • 100 VMs
  • Jede VM gibt einen Messwert aus, metric_name
  • metric_name hat ein Label mit 10 Werten
Benachrichtigungsrichtlinien
  • 100 Bedingungen
  • Jede Bedingung wird gefiltert und zu einer VM zusammengefasst
  • Ausführungszeitraum von 30 Sekunden
Resultierende Kosten
  • Bedingungskosten: 100 Bedingungen × 1,50 $ pro Monat = 150 $pro Monat
  • Kosten für Zeitachsen: 100 Bedingungen × 1 zurückgegebene Zeitachse pro Bedingung und Periode × 86.400 Perioden pro Monat = 8,6 Millionen zurückgegebene Zeitachsen pro Monat × 0,35 $ pro Million Zeitachsen = 3,02 $ pro Monat
  • Gesamtkosten: 153,02$pro Monat

Beispiel 3: Eine Richtlinie, wird zur VM aggregiert, 15 Sekunden

Verwenden Sie in diesem Beispiel die folgenden Konfigurationen:

Daten

  • 100 VMs
  • Jede VM gibt einen Messwert aus, metric_name
  • metric_name hat ein Label mit 10 Werten
Benachrichtigungsrichtlinie
  • Eine PromQL-Benachrichtigungsbedingung
  • Bedingung wird auf VM-Ebene aggregiert
  • 15-sekündige Ausführungsphase
Resultierende Kosten
  • Bedingungskosten: 1 Bedingung × 1,50 $ pro Monat = 1,50 $ pro Monat
  • Kosten für Zeitachsen: 100 zurückgegebene Zeitachsen pro Periode × 172.800 Perioden pro Monat = 17,3 Millionen zurückgegebene Zeitachsen pro Monat × 0,35 $ pro Million Zeitachsen = 6,05 $ pro Monat
  • Gesamtkosten: 7,55 € pro Monat

Beispiel 4: Eine Richtlinie für jeden Dienst aggregieren, 30 Sekunden

Verwenden Sie in diesem Beispiel die folgenden Konfigurationen:

Daten

  • 100 VMs, wobei jede VM zu einem Dienst gehört
  • 5 Dienste insgesamt
  • Jede VM gibt einen Messwert aus, metric_name
  • metric_name hat ein Label mit 10 Werten
Benachrichtigungsrichtlinie
  • Eine Bedingung
  • Bedingung wird zur Serviceebene aggregiert
  • Ausführungszeitraum von 30 Sekunden
Resultierende Kosten
  • Bedingungskosten: 1 Bedingung × 1,50 $ pro Monat = 1,50 $ pro Monat
  • Kosten für Zeitachsen: 5 zurückgegebene Zeitachsen pro Periode × 86.400 Perioden pro Monat = 432.000 zurückgegebene Zeitachsen pro Monat × 0,35 $ pro Million Zeitachsen = 0,14 $ pro Monat
  • Gesamtkosten: 1,64 € pro Monat

Beispiel 5: Eine Richtlinie zur VM aggregieren; höhere zugrunde liegende Kardinalität pro VM, 30 Sekunden

Verwenden Sie in diesem Beispiel die folgenden Konfigurationen:

Daten

  • 100 VMs
  • Jede VM gibt einen Messwert aus, metric_name
  • metric_name hat 100 Labels mit jeweils 1.000 Werten
Benachrichtigungsrichtlinie
  • Eine Bedingung
  • Bedingung wird auf VM-Ebene aggregiert
  • Ausführungszeitraum von 30 Sekunden
Resultierende Kosten
  • Bedingungskosten: 1 Bedingung × 1,50 $ pro Monat = 1,50 $ pro Monat
  • Kosten für Zeitachsen: 100 zurückgegebene Zeitachsen pro Periode × 86.400 Perioden pro Monat = 8,5 Millionen zurückgegebene Zeitachsen pro Monat × 0,35 $ pro Million Zeitachsen = 3,02 $ pro Monat
  • Gesamtkosten: 4,52 € pro Monat

Beispiel 6: Eine Richtlinie auf der VM aggregieren; zwei Messwerte in einer Bedingung zusammenführen, 30 Sekunden

Verwenden Sie in diesem Beispiel die folgenden Konfigurationen:

Daten

  • 100 VMs
  • Jede VM gibt zwei Messwerte aus: metric_name_1 und metric_name_2
  • Beide Messwerte haben ein Label mit jeweils 10 Werten
Benachrichtigungsrichtlinie
  • Eine Bedingung
  • Bedingung wird auf VM-Ebene aggregiert
  • In der Bedingung wird ein OR-Operator verwendet, um die Messwerte zu verbinden
  • Ausführungszeitraum von 30 Sekunden
Resultierende Kosten
  • Bedingungskosten: 1 Bedingung × 1,50 $ pro Monat = 1,50 $ pro Monat
  • Zeitreihenkosten: 2 Messwerte × 100 zurückgegebene Zeitachsen pro Messwert und Zeitraum × 86.400 Zeitreihen pro Monat = 17,3 Millionen zurückgegebene Zeitachsen pro Monat × 0,35 $ pro Million Zeitachsen = 6,05 $ pro Monat
  • Gesamtkosten: 7,55 € pro Monat

Beispiel 7: 100 logbasierte Benachrichtigungsrichtlinien

Verwenden Sie in diesem Beispiel die folgende Konfiguration:

Benachrichtigungsrichtlinien

  • 100 Bedingungen (eine Bedingung pro logbasierter Benachrichtigungsrichtlinie)
Resultierende Kosten
  • Bedingungskosten: 100 Bedingung × 1,50 $ pro Monat = 150,00 $ pro Monat
  • Zeitreihenkosten: 0 $ (logbasierte Benachrichtigungsrichtlinien geben keine Zeitreihen zurück.)
  • Gesamtkosten: 150,00 € pro Monat

Vorschläge zur Reduzierung der Kosten für Benachrichtigungen

Beachten Sie beim Konfigurieren Ihrer messwertbasierten Benachrichtigungsrichtlinien die folgenden Vorschläge, um die Kosten für Benachrichtigungen zu senken.

Benachrichtigungsrichtlinien konsolidieren, um für mehr Ressourcen zu arbeiten

Aufgrund der Kosten von 1,50 $pro Bedingung ist es kostengünstiger, eine Benachrichtigungsrichtlinie zum Überwachen mehrerer Ressourcen zu verwenden, als eine Benachrichtigungsrichtlinie für das Monitoring jeder Ressource zu verwenden. Vergleichen Sie beispielsweise Beispiel 1 mit Beispiel 2: In beiden Beispielen überwachen Sie die gleiche Anzahl von Ressourcen. In Beispiel 2 werden jedoch 100 Benachrichtigungsrichtlinien verwendet, in Beispiel 1 hingegen nur eine. Infolgedessen ist Beispiel 1 fast 150 $pro Monat günstiger.

Aggregieren Sie nur auf der Ebene, für die Sie eine Benachrichtigung erhalten möchten

Das Aggregieren auf höheren Detaillierungsgraden führt zu höheren Kosten als das Aggregieren auf niedrigeren Detaillierungsgraden. Beispielsweise ist das Aggregieren auf Google Cloud-Projektebene günstiger als das Aggregieren auf Clusterebene und das Aggregieren auf Clusterebene ist kostengünstiger als das Aggregieren auf Cluster- und Namespace-Ebene.

Vergleichen Sie beispielsweise Beispiel 1 mit Beispiel 4: Beide Beispiele beziehen sich auf dieselben zugrunde liegenden Daten und haben eine einzige Benachrichtigungsrichtlinie. Da die Benachrichtigungsrichtlinie in Beispiel 4 jedoch zum Dienst aggregiert wird, ist sie kostengünstiger als die Benachrichtigungsrichtlinie in Beispiel 1, die detaillierter für die VM aggregiert wird.

Vergleichen Sie außerdem Beispiel 1 mit Beispiel 5: In diesem Fall ist die Kardinalität des Messwerts in Beispiel 5 10.000-mal höher als die Kardinalität des Messwerts in Beispiel 1. Da jedoch die Benachrichtigungsrichtlinie in Beispiel 1 und Beispiel 5 beide zur VM aggregiert werden und die Anzahl der VMs in beiden Beispielen identisch ist, sind die Beispiele im Preis gleich.

Wählen Sie beim Konfigurieren der Benachrichtigungsrichtlinien die Aggregationsebenen aus, die für Ihren Anwendungsfall am besten geeignet sind. Wenn Sie beispielsweise Benachrichtigungen zur CPU-Auslastung erhalten möchten, sollten Sie die Daten auf VM- und CPU-Ebene aggregieren. Wenn Sie Benachrichtigungen zur Latenz nach Endpunkt erhalten möchten, sollten Sie sie auf Endpunktebene aggregieren.

Keine Benachrichtigung bei nicht aggregierten Rohdaten

Monitoring verwendet ein System mit Dimensionsmetriken, bei dem die Kardinalität eines jeden Messwerts gleich der Anzahl der überwachten Ressourcen ist, multipliziert mit der Anzahl der Labelkombinationen für diesen Messwert. Wenn Sie beispielsweise 100 VMs haben, die einen Messwert ausgeben, und dieser Messwert 10 Labels mit jeweils 10 Werten hat, beträgt Ihre Gesamtkardinalität 100 × 10 × 10 = 10.000.

Aufgrund der Skalierung der Kardinalität können Benachrichtigungen zu Rohdaten extrem teuer sein. Im vorherigen Beispiel wurden für jeden Ausführungszeitraum 10.000 Zeitachsen zurückgegeben. Wenn Sie jedoch zur VM aggregieren, werden pro Ausführungszeitraum nur 100 Zeitachsen zurückgegeben, unabhängig von der Labelkardinalität der zugrunde liegenden Daten.

Bei Benachrichtigungen für Rohdaten besteht außerdem das Risiko, dass die Zeitreihen erhöht werden, wenn Ihre Messwerte neue Labels erhalten. Wenn im vorherigen Beispiel ein Nutzer Ihrem Messwert ein neues Label hinzufügt, erhöht sich die Gesamtkardinalität auf 100 × 11 × 10 = 11.000 Zeitachsen. In diesem Fall erhöht sich die Anzahl der zurückgegebenen Zeitachsen pro Ausführungszeitraum um 1.000, auch wenn Ihre Benachrichtigungsrichtlinie unverändert ist. Wenn Sie stattdessen zur VM aggregieren, werden trotz der erhöhten zugrunde liegenden Kardinalität nur 100 Zeitachsen zurückgegeben.

Unnötige Antworten herausfiltern

Konfigurieren Sie die Bedingungen so, dass nur Daten ausgewertet werden, die für Ihre Benachrichtigungsanforderungen erforderlich sind. Wenn Sie keine Maßnahmen ergreifen würden, um etwas zu beheben, schließen Sie es aus Ihren Benachrichtigungsrichtlinien aus. Beispielsweise müssen Sie wahrscheinlich keine Benachrichtigungen für die Entwicklungs-VM eines Praktikums erstellen.

Um unnötige Benachrichtigungen und Kosten zu reduzieren, können Sie unwichtige Zeitreihen herausfiltern. Sie können Google Cloud-Metadatenlabels verwenden, um Assets mit Kategorien zu taggen, und dann die nicht benötigten Metadatenkategorien herausfiltern.

Top-Stream-Operatoren verwenden, um die Anzahl der zurückgegebenen Zeitreihen zu reduzieren

Wenn Ihre Bedingung eine PromQL- oder MQL-Abfrage verwendet, können Sie einen Top-Stream-Operator verwenden, um eine Anzahl der Zeitachsen auszuwählen, die mit den höchsten Werten zurückgegeben wurden:

Beispielsweise begrenzt die topk(metric, 5)-Klausel in einer PromQL-Abfrage die Anzahl der zurückgegebenen Zeitachsen in jedem Ausführungszeitraum auf fünf.

Die Begrenzung auf eine höchste Anzahl von Zeitachsen kann zu fehlenden Daten und fehlerhaften Benachrichtigungen führen, z. B.:

  • Wenn mehr als N Zeitachsen gegen Ihren Grenzwert verstoßen, verpassen Sie Daten außerhalb der Top-N-Zeitachsen.
  • Wenn eine Zeitreihe mit Verstößen außerhalb der Top-N-Zeitachsen auftritt, werden die Vorfälle möglicherweise automatisch geschlossen, obwohl die ausgeschlossene Zeitachse weiterhin gegen den Grenzwert verstößt.
  • Ihre Bedingungsabfragen zeigen möglicherweise keinen wichtigen Kontext wie Referenzzeitachsen an, die wie vorgesehen funktionieren.

Wählen Sie zur Minderung solcher Risiken große Werte für N aus und verwenden Sie den Operator "Top-Streams" nur in Benachrichtigungsrichtlinien, die viele Zeitreihen auswerten, z. B. bei Benachrichtigungen für einzelne Kubernetes-Container.

Ausführungszeitraum verlängern (nur PromQL)

Wenn für die Bedingung eine PromQL-Abfrage verwendet wird, können Sie die Länge des Ausführungszeitraums ändern. Dazu legen Sie in der Bedingung das Feld evaluationInterval fest.

Längere Bewertungsintervalle führen dazu, dass weniger Zeitreihen pro Monat zurückgegeben werden. Beispielsweise wird eine Bedingungsabfrage mit einem 15-Sekunden-Intervall doppelt so oft ausgeführt wie eine Abfrage mit einem 30-Sekunden-Intervall und eine Abfrage mit einem 1-minütigen Intervall halb so oft wie eine Abfrage mit einem 30-Sekunden-Intervall.

Wird deaktiviert

Wenn Sie einen bestehenden Google Cloud-Vertrag haben, der nicht bis April 2025 abläuft, können Sie die Abrechnung für Benachrichtigungen verschieben, bis die Vertragsverlängerung fällig ist. Dazu beantragen Sie eine Ausnahme vom Cloud Monitoring-Abrechnungsteam für Benachrichtigungen. Ausnahmen für Kunden mit aktiven Verträgen werden von Fall zu Fall beurteilt.

Sie können bis zum 1. November 2024 eine Ausnahme beantragen. Wenn Sie bis zur Vertragsverlängerung eine Abrechnungsbefreiung beantragen möchten, füllen Sie das Antragsformular für die Abrechnungsbefreiung aus.

Error Reporting

Fehlerdaten können mithilfe der Error Reporting API oder der Cloud Logging API an Ihr Google Cloud-Projekt gemeldet werden.

Für die Nutzung von Error Reporting fallen keine Gebühren an. Es können jedoch Kosten für Cloud Logging anfallen, da Logeinträge generiert und dann von Cloud Logging gespeichert werden.

Angaben zu den Limits für Ihre Error Reporting-Nutzung finden Sie unter Kontingente und Limits.

Cloud Profiler

Für die Nutzung von Cloud Profiler fallen keine Kosten an.

Angaben zu den Limits für Ihre Profiler-Nutzung finden Sie unter Kontingente und Limits.

Cloud Trace

Die Trace-Kosten basieren auf der Anzahl der aufgenommenen und gescannten Trace-Spans: Bei der Übermittlung von Latenzdaten an Trace werden diese in ein Trace-Log gepackt, das sich aus Spans zusammensetzt. Die Spans werden vom Cloud Trace-Backend aufgenommen. Wenn Sie sich Trace-Daten anzeigen lassen, werden die gespeicherten Spans von Cloud Trace gescannt. In diesem Abschnitt finden Sie folgende Informationen:

  • Definition von kostenpflichtigen und kostenlosen Trace-Spans
  • Preisbeispiel
  • Informationen zur Reduzierung der Trace-Span-Aufnahme
  • Einstellungen für eine Benachrichtigungsrichtlinie, mit der Sie informiert werden, sobald die Trace-Span-Aufnahme einen bestimmten Grenzwert erreicht

Aktuelle Preisinformationen finden Sie unter Cloud Trace-Preise.

Angaben zu den Limits für Ihre Trace-Nutzung finden Sie unter Kontingente und Limits.

Informationen zur Anzeige der aktuellen oder früheren Nutzung finden Sie unter Rechnungen schätzen.

Kostenlose Trace-Spans

Die Cloud Trace-Preise gelten nicht für Spans, die automatisch von App Engine Standard, Cloud Run-Funktionen oder Cloud Run generiert werden: Die Aufnahme dieser Traces ist kostenlos.

Automatisch generierte Traces verbrauchen kein Cloud Trace API-Kontingent und werden in den API-Nutzungsmesswerten nicht berücksichtigt.

Kostenpflichtige Trace-Spans

Alle Trace-Spans (mit Ausnahme der im Abschnitt Kostenlose Traces aufgeführten Spans) sind kostenpflichtig und werden nach dem aufgenommenen Volumen berechnet. Dies gilt auch für Spans, die von Instrumentierungen erstellt werden, die Sie der App Engine-Standardanwendung hinzugefügt haben.

Preisbeispiele

Das Beispiel beruht auf den Trace-Preisen vom Juli 2020.

  • Wenn Sie 2 Millionen Spans in einem Monat haben, betragen Ihre Kosten 0 $. Die ersten 2,5 Millionen Spans pro Monat sind kostenlos.
  • Wenn Sie 14 Millionen Spans in einem Monat haben, betragen Ihre Kosten 2,30 $. Die ersten 2,5 Millionen Spans pro Monat sind kostenlos. Die Kosten der verbleibenden Spans berechnen sich so: 11,5 Millionen Spans × 0,20 $/Million Spans = 2,30 $.
  • Wenn Sie 1 Milliarde Spans in einem Monat haben, betragen Ihre Kosten 199 $. Die ersten 2,5 Millionen Spans pro Monat sind kostenlos. Die Kosten der verbleibenden Spans berechnen sich so: 997,5 Millionen Spans × 0,20 $/Million Spans = 199,50 $.

Trace-Nutzung reduzieren

Zur Steuerung des Aufnahmevolumens von Trace können Sie die Trace-Abtastrate ändern und so die Anzahl der Traces, die Sie für die Leistungsanalyse benötigen, mit Ihrem Budget in Einklang bringen.

Bei Systemen mit hohem Traffic können die meisten Kunden 1 von 1.000 Transaktionen oder sogar 1 von 10.000 Transaktionen abtasten und haben dennoch genügend Informationen für die Leistungsanalyse.

Die Abtastrate wird mit den Cloud Trace-Clientbibliotheken konfiguriert.

Benachrichtigungen über aufgenommene monatliche Spans

Verwenden Sie die folgenden Einstellungen, um eine Benachrichtigungsrichtlinie zu erstellen, sodass Sie benachrichtigt werden, wenn die Anzahl der pro Monat aufgenommenen Cloud Trace-Spans eine benutzerdefinierte Grenze überschreiten.

Neue Bedingung
Feld

Wert
Ressource und Messwert Wählen Sie im Menü Ressourcen die Option Global aus.
Wählen Sie im Menü Messwertkategorien die Option Abrechnung aus.
Wählen Sie im Menü Messwerte die Option Monthly Trace spansincludeds (Aufgenommene Trace-Spans pro Monat) aus.
Filter
Über Zeitreihen hinweg
Zeitreihenaggregation
sum
Rollierendes Zeitfenster 60 m
Funktion für rollierendes Zeitfenster max
Benachrichtigungstrigger konfigurieren
Feld

Wert
Bedingungstyp Threshold
Benachrichtigungstrigger Any time series violates
Grenzwertposition Above threshold
Threshold value Sie legen den akzeptablen Wert fest.
Zeitfenster noch einmal testen Der kleinste akzeptable Wert liegt bei 30 Minuten.

GKE Enterprise

Für GKE Enterprise-Systemlogs und -messwerte fallen keine Kosten an. Logs der Steuerungsebene, Messwerte der Steuerungsebene und eine ausgewählte Teilmenge von Kube State Metrics sind standardmäßig aktiviert für GKE-Cluster in Google Cloud, die bei der Clustererstellung in einem für GKE Enterprise aktivierten Projekt registriert sind. Für Logs der Steuerungsebene fallen Cloud Logging-Gebühren an. Standardmäßig aktivierte Messwerte sind ohne Aufpreis enthalten.

Eine Liste der enthaltenen GKE-Logs und -Messwerte finden Sie unter Welche Logs werden erfasst? und Verfügbare Messwerte.

In einem Google Distributed Cloud-Cluster enthalten GKE Enterprise-Systemlogs und -Messwerte Folgendes:

  • Logs und Messwerte aus allen Komponenten in einem Administratorcluster
  • Logs und Messwerte aus Komponenten in diesen Namespaces in einem Nutzercluster:kube-system, gke-system, gke-connect, knative-serving, istio-system, monitoring-system, config-management-system, gatekeeper-system, cnrm-system

FAQ

Welche Produktfeatures sind kostenlos verfügbar?

Die Nutzung von Google Cloud Observability-Produkten wird nach Datenvolumen berechnet. Abgesehen von den auf dieser Seite beschriebenen Kosten für Datenvolumen ist die Nutzung aller zusätzlichen Produktfeatures von Google Cloud Observability kostenlos.

Wie hoch sind meine Kosten?

Informationen zum Schätzen der Nutzungskosten finden Sie unter Rechnungen schätzen.

Hilfe bei Unklarheiten zur Abrechnung bekommen Sie unter Fragen zur Abrechnung.

Welche Informationen erhalte ich aus den detaillierten Angaben zu meiner Nutzung?

Mit verschiedenen Messwerten lassen sich Log- und Messwertvolumen im Metrics Explorer leichter nachvollziehen. Weitere Informationen dazu finden Sie unter Detaillierte Verwendung im Metrics Explorer ansehen.

Informationen zur Kostenverwaltung finden Sie in den folgenden Blogposts:

Wie wirken sich Messwert- und Logbereiche auf die Abrechnung aus?

In den meisten Fällen wirken sich Messwertbereiche und Logbereiche nicht auf die Abrechnung aus. Logs und Messwerte werden je nach Projekt, Rechnungskonto, Ordner oder Organisation, das bzw. der die Daten empfängt, in Rechnung gestellt. Der Messwertbereich für ein Projekt definiert die Sammlung der Ressourcen, deren Messwerte das Projekt aufrufen und überwachen kann. Das Definieren eines Messwertbereichs hat keinen Einfluss darauf, welche Ressource Messwertdaten empfängt. Außerdem hat dies keinen Einfluss darauf, dass Daten dupliziert werden. Ebenso werden in einem Logbereich nur die Ressourcen aufgelistet, die die Logeinträge speichern oder weiterleiten, die Sie ansehen möchten.

Angenommen, Ihre Organisation hat 100 virtuelle Maschinen (VMs): 60 VMs werden von Projekt-A gehostet und 40 VMs sind im Projekt-B. Projekt-A empfängt und speichert die Messwerte für ihre VMs. Für dieses Projekt fallen Kosten an, wenn Messwerte kostenpflichtig sind. Ebenso empfängt und speichert Projekt-B die Messwerte für ihre VMs. Auch hier entstehen Kosten, wenn Messwerte kostenpflichtig sind. Wenn Sie einen Messwertbereich erstellen, der Projekt-A und Projekt-B enthält, können Sie die kombinierten Messwerte für die 100 VMs ansehen. Sie können sich nur die Messwerte für Projekt-A, nur die Messwerte von Projekt-B oder alle Messwerte zusammen anzeigen lassen. Obwohl Sie zwei Möglichkeiten haben, die Messwerte von Projekt-A aufzurufen, hat dies keine Auswirkungen auf die Abrechnung.

Was passiert, wenn ich die kostenlosen Kontingente überschreite?

Die Nutzung über Ihre kostenlosen Kontingente hinaus wird automatisch berechnet. Sie verlieren keine Logs oder Messwerte. Informationen zu den möglichen Kosten finden Sie unter Rechnungen schätzen.

Sie können eine Benachrichtigungsrichtlinie erstellen, mit der Ihre Nutzung überwacht wird und Sie benachrichtigt werden, wenn die Grenze für die kostenlose Nutzung fast erreicht ist.

In meinen Projekten gibt es eine große Anzahl von Google Cloud-Logs, die ich nicht verwende. Wie kann ich vermeiden, dass diese Logs Kosten verursachen?

Sie können Logs ausschließen und so festlegen, welche Logs in Logging aufgenommen werden. Informationen dazu finden Sie unter Lognutzung reduzieren.

Erhalten Dienste, die Logs an mein Projekt senden, einen Fehler, wenn Logs ausgeschlossen werden?

Nein. Dienste, die Logeinträge senden, können nicht feststellen, ob die Einträge in Logging aufgenommen werden oder nicht.

Muss ich für meine Flusslogs in der Virtual Private Cloud doppelt zahlen?

Wenn Sie Ihre VPC-Flusslogs an Logging senden, fallen keine Gebühren für das Erzeugen der Logs an, es werden nur Logging-Gebühren berechnet. Wenn Sie diese jedoch erst senden und dann Ihre VPC-Flusslogs von Logging ausschließen, werden Gebühren für die Logs berechnet. Weitere Informationen finden Sie im Google Cloud-Preisrechner. Wählen Sie dann den Tab „Cloud Load Balancing und Netzwerkdienste“ aus.

1. Zur Preisberechnung werden alle Einheiten so behandelt:Binärsystem zum BeispielMebibyte (MiB oder 220 Byte) oderGibibyte (GiB oder 230 Byte).

2 Es fallen keine Kosten für Google Cloud- oder GKE Enterprise-Messwerte an, die mit bis zu 1 Datenpunkt pro Minute gemessen werden. Dies ist derzeit die höchste Auflösung. Für zukünftige Messungen mit höherer Auflösung können Gebühren anfallen.

3 Prozessmesswerte werden derzeit mit einer vordefinierten Standardrate von einmal pro Minute erfasst, die nicht geändert werden kann. Diese Daten ändern sich in der Regel nur langsam, sodass diese Messwerte derzeit anhand von Stichproben erfasst werden. Daher entspricht die Berechnung von Prozessmesswerten mit 5 % der Standardrate der Standardrate, wenn die Messwerte in 20-Minuten-Intervallen abgetastet werden. Nutzern, die 100 MiB an Daten aus diesen Messwerten sammeln, werden nur 5 MiB berechnet.

Nächste Schritte

Individuelles Angebot einholen

Mit den „Pay as you go“-Preisen von Google Cloud bezahlen Sie nur für die Dienste, die Sie nutzen. Wenden Sie sich an unser Vertriebsteam, wenn Sie ein individuelles Angebot für Ihr Unternehmen erhalten möchten.
Vertrieb kontaktieren