Google Cloud Observability – Preise

Mit den Preisinformationen für Google Cloud Monitoring können Sie Nutzung und Ausgaben kontrollieren. Die Preise für Google Cloud Observability-Produkte richten sich nach dem Datenvolumen oder der Nutzung. Dank der kostenlosen Datennutzungskontingente können Sie sofort loslegen – ohne Vorabgebühren oder Verpflichtungen.

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*, mit Ausnahme von freigegebenen Netzwerkprotokollen.
0, 50 $/GiB;
Einmalige Gebühr für das Streaming von Logs in den Log-Bucket-Speicher für Indexierung, Abfrage und Analyse; beinhaltet bis zu 30 Tage Speicherung in Log-Buckets. Es fallen keine zusätzlichen Kosten für Abfragen und Analysen von Logdaten an.
Erste 50 GiB/Projekt/Monat 1. Juli 2018
Gekaufter Netzwerk-Log-Speicher 0,25 $/GiB;
Einmalige Gebühr für das Streaming von Logs in der Netzwerktelemetrie für Indexierung, Abfrage und Analyse; beinhaltet bis zu 30 Tage Speicherung in Log-Buckets. Es fallen keine zusätzlichen Kosten für Abfragen und Analysen von Logdaten an.
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. Logs, die für die standardmäßige Aufbewahrungsdauer aufbewahrt werden, verursachen keine Speicherkosten. 01. Januar 2022
Logrouter  Keine zusätzliche Gebühr Nicht zutreffend Nicht zutreffend
Loganalyse  Keine zusätzliche Gebühr Nicht zutreffend Nicht zutreffend
*  Das Speicher-Volume zählt vor der Indexierung die tatsächliche Größe der Logeinträge. 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 wird. Zu den gesendeten Logs gehören VPC-Flusslogs, das Logging von Firewallregeln und Cloud NAT-Logs. Für diese Logs gelten außerdem die Preise für Netzwerktelemetrie. Weitere Informationen finden Sie unter Übermittelte Protokolle.
  Es fallen keine Aufbewahrungskosten für Logs an, die in einem _Required Log-Bucket gespeichert sind, das eine feste Aufbewahrungsdauer von 400 Tagen hat.
  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.
  Das Upgrade eines Log-Buckets für die Verwendung von Loganalysen oder das Senden von SQL-Abfragen auf der Seite Loganalysen ist kostenlos.
Hinweis: Die Preisgestaltung für Cloud Logging wurde am 19. Juli 2023 geändert. Die kostenlosen Kontingente und Preise sind jedoch unverändert. Ihre Rechnung kann sich auf die alte Preissprache beziehen.

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
Mit Google Cloud Managed Service for Prometheus aufgenommene Messwerte, einschließlich Messwerte der GKE-Steuerungsebene 0,06 $/Million Beispiele: erste 0–50 Milliarden aufgenommene Beispiele#
0,048 $/Million Proben: nächste 50–250 Milliarden aufgenommene Proben
0,036 $/Million Proben: nächste 250–500 Milliarden aufgenommene Proben
0,024 $/Million Proben: >500 Milliarden aufgenommene Proben
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 von Verfügbarkeitsdiagnosen 0,30 $/1.000 Ausführungen 1 Million Ausführungen pro Google Cloud-Projekt 1. Oktober 2022
Ausführung von Überwachen des synthetischen 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 Zeitreihen, die durch die Abfrage einer Bedingung in einer Benachrichtigungsrichtlinie bezüglich eines Messwerts zurückgegeben werden
Nicht zutreffend April 2026
  Google Cloud Managed Service for Prometheus verwendet Cloud Monitoring-Speicher für extern erstellte Messwertdaten und ruft diese Daten mit der Monitoring API ab. Managed Service for Prometheus-Messungen basieren auf Proben, die anstelle von Byte erfasst werden, um die Prometheus-Konventionen zu erfüllen. Weitere Informationen zur beispielbasierten Messung finden Sie unter Preise für Kontrollierbarkeit und Planbarkeit. Computing-Beispiele finden Sie unter Preisbeispiele basierend auf aufgenommenen Proben.
#  Beispiele werden pro Rechnungskonto gezählt.
  Ausführungen werden dem Rechnungskonto in Rechnung gestellt, in dem sie definiert wurden. Weitere Informationen finden Sie unter Preise für die Ausführung von Verfügbarkeitsdiagnosen.
*  Ausführungen werden für das Rechnungskonto in Rechnung gestellt, in dem sie definiert werden. Pro Ausführung können zusätzliche Gebühren von anderen Google Cloud-Diensten anfallen, darunter Dienste wie Cloud Run-Funktionen, Cloud Storage und Cloud Logging. Informationen zu diesen zusätzlichen Gebühren finden Sie in der Preisübersicht für den jeweiligen Google Cloud-Dienst.
  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

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

Informationen zu den Preisen für GKE Enterprise finden Sie unter GKE Enterprise.

Nutzung abrufen

Zum Abrufen Ihrer aktuellen Nutzung öffnen Sie in der Google Cloud Console die 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

Wenn Sie informiert werden möchten, sobald Ihre abrechenbaren oder prognostizierten Kosten ein bestimmtes Budget überschreiten, erstellen Sie in der Google Cloud Console auf der Seite Budgets und Benachrichtigungen eine Benachrichtigung:

  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. In Logging wird die Menge an Logdaten berechnet, die im Log-Bucket _Default und in benutzerdefinierten Log-Buckets gespeichert wird. Die Preise gelten für nicht verkaufte Netzwerklogs, wenn das Volumen das kostenlose monatliche Kontingent überschreitet, und für verkaufte Netzwerklogs.

Für den _Default-Log-Bucket und für benutzerdefinierte Log-Buckets werden auch Kosten für die Logs berechnet, die länger als die Standardaufbewahrungsdauer von 30 Tagen aufbewahrt werden.

Es fallen keine zusätzlichen Kosten an, wenn Sie Logs mit Logging weiterleiten, die Cloud Logging API verwenden, Log-Bereiche konfigurieren oder Logs im _Required-Log-Bucket speichern, der eine feste Aufbewahrungsdauer von 400 Tagen hat.

In diesem Abschnitt finden Sie Informationen zu den folgenden Themen:

Eine Übersicht der Preise finden Sie unter Cloud Logging – Preisübersicht.

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

Für jedes Google Cloud-Projekt erstellt Logging automatisch zwei Log-Buckets: _Required und _Default. Für diese beiden Buckets erstellt Logging automatisch Logsenken mit den Namen _Required und _Default, die Logs an die entsprechend benannten Log-Buckets weiterleiten. Sie können die Senke _Required nicht deaktivieren oder ändern. Sie können die Senke _Default deaktivieren oder ändern, um zu verhindern, dass der Bucket _Default neue Logs speichert.

In jedem Google Cloud-Projekt können Sie benutzerdefinierte Log-Buckets erstellen. Sie können auch Senken so konfigurieren, dass eine beliebige Kombination von Logs, sogar über Google Cloud-Projekte in Ihrer Google Cloud-Organisation hinweg, an diese Log-Buckets geleitet wird.

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 Log Analytics aktualisieren. Das Upgrade eines Log-Buckets für die Verwendung von Loganalysen ist kostenlos.

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

Speicherpreise

Für Logs, die im Bucket _Required gespeichert sind, fallen keine Logging-Kosten an. Sie können den Bucket _Required nicht löschen oder die Senke _Required ändern. Der Bucket _Required speichert die folgenden Logs:

In Logging wird das vorindexierte Volumen an Logs berechnet, das im Log-Bucket _Default und in benutzerdefinierten Log-Buckets gespeichert wird, wenn das Gesamtvolumen das kostenlose monatliche Kontingent überschreitet. Jedes Schreiben eines Logeintrags 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 Retention

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

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

Für Logs fallen Aufbewahrungskosten an, wenn sie 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 eine Gnadenfrist von sieben Tagen, in der abgelaufene Logs nicht gelöscht werden. Abgelaufene Logs können nicht abgefragt oder angezeigt werden. Innerhalb dieser sieben Tage können Sie den vollständigen Zugriff wiederherstellen, indem Sie die Aufbewahrungsdauer des Log-Buckets verlängern. Logs, die während der Gnadenfrist gespeichert werden, werden auf Ihre Aufbewahrungskosten angerechnet.

Wenn Sie einen Logeintrag an mehrere Log-Buckets weiterleiten, können Ihnen die Kosten für Speicherplatz und Aufbewahrung mehrfach in Rechnung gestellt werden. Angenommen, Sie leiten einen Logeintrag an den Log-Bucket _Default und an einen benutzerdefinierten Log-Bucket weiter. Außerdem gehen wir davon aus, dass Sie für beide Buckets eine benutzerdefinierte Aufbewahrungsdauer von mehr als 30 Tagen festlegen. Für diese Konfiguration werden zwei Speicher- und zwei Aufbewahrungskosten berechnet.

Gekaufte Netzwerkprotokolle

Vermarktete Netzwerkprotokolle sind nur verfügbar, wenn Sie die Protokollerstellung konfigurieren. Für die Erstellung von Netzwerklogs, die von Drittanbietern bereitgestellt werden, fallen Gebühren an. Wenn Sie diese Logs in einem Log-Bucket speichern oder an ein anderes unterstütztes Ziel weiterleiten, fallen auch Gebühren für Cloud Logging oder das Ziel an. Informationen zu den Kosten für die Protokollerstellung finden Sie unter Netzwerktelemetriepreise.

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

Um Ihre bereitgestellten Netzwerklogs zu finden, filtern Sie im Log-Explorer nach den folgenden Lognamen:

  • 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

Logspeicherung reduzieren

Um die Speicherkosten in Cloud Logging zu reduzieren, konfigurieren Sie Ausschlussfilter für Ihre Logsenken, um bestimmte Logs von der Weiterleitung auszuschließen. Mit Ausschlussfiltern können Sie alle Logeinträge entfernen, die dem Filter entsprechen, oder nur einen Prozentsatz der Logs. Wenn ein Logeintrag mit einem Ausschlussfilter einer Senke übereinstimmt, wird der Logeintrag nicht an das Ziel weitergeleitet. Ausgeschlossene Logeinträge werden nicht auf das Speicherkontingent angerechnet. Eine Anleitung zum Festlegen von Ausschlussfiltern finden Sie unter Logs ausschließen.

Eine weitere Möglichkeit, die Speicherkosten für Cloud Logging zu senken, ist das Weiterleiten von Logs aus Cloud Logging an ein unterstütztes Ziel. Beim Weiterleiten von Logs an unterstützte Ziele fallen für Cloud Logging keine Gebühren an. 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.

Preis 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 Log-Bytes Ihre benutzerdefinierte Grenze für Cloud Logging ü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 Logsbasierter Messwert aus.
Wählen Sie im Menü Messwerte die Option Monatlich verarbeitete Protokollbytes 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

Monitoring-Gebühren für Folgendes:

  • 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 synthetischer Monitore

  • Benachrichtigungsrichtlinien werden anhand der Anzahl der aktiven Bedingungen pro Monat gemessen.

  • Zeitreihen, die durch die Abfrage einer Bedingung in einer Benachrichtigungsrichtlinie zurückgegeben werden.

In Monitoring bezieht sich Aufnahme auf den Prozess des Schreibens von Zeitachsen in Monitoring. Jede Zeitachse enthält eine bestimmte Anzahl an Datenpunkten. Diese Datenpunkte bilden die Grundlage für Aufnahmegebühren. 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.

So lassen Sie Ihre aktuelle Nutzung anzeigen:

  • Ö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 Messwertaufnahmen werden nach der Anzahl der Byte berechnet, einige aber auch nach der Anzahl der Beispiele. Diese Preismodelle werden in den folgenden Abschnitten beschrieben.

Die folgenden Faktoren tragen zu den Aufnahmekosten bei:

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

    • Informationen zum Datentyp, der mit einem bestimmten Messwerttyp verknüpft ist, finden Sie in der Liste der Messwerte.
    • Informationen zu Skalar- und Verteilungsdatentypen finden Sie unter Werttypen.
  • Anzahl der Datenpunkte, die in Zeitreihen geschrieben werden. Dieser Wert hängt davon ab, wie häufig die Daten abgetastet werden und wie viele Daten vorhanden sind. Die Kardinalität bestimmt, wie viele Zeitreihen für eine Kombination aus Messwert- und überwachten Ressourcentypen generiert werden. Weitere Informationen finden Sie unter Kardinalität.

Die Werte der Messwert- und Ressourcenlabels, die zu der Zeitreihe gehören, tragen nicht zu den Kosten bei.

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 wie folgt berechnet:

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

Informationen zu Datenpunkten in Zeitreihen finden Sie unter Zeitreihen: 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:

  • Für einen skalaren Datentyp: 1 für jeden in eine Zeitachse geschriebenen Punkt.
  • Für einen Verteilungsdatentyp: 2 für jeden in eine Zeitachse geschriebenen Punkt sowie 1 für jeden Histogramm-Bucket, dessen Zählung ungleich Null ist.

Informationen zu Datenpunkten in Zeitreihen finden Sie unter Zeitreihen: 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 zeigen, wie sich die Kosten für das Erfassen von Messwertdaten für die nach aufgenommenen Byte berechneten Messwerte schätzen lassen. Diese Beispiele dienen zur Veranschaulichung von Berechnungen. Umfassende Schätzungen erhalten Sie mit dem Preisrechner. Wenn Sie auf dieses Tool zugreifen, geben Sie Ihre Messwert-, Logging- und Trace-Daten im Google Cloud Observability-Produkt ein.

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 Planbarkeit

Die Preise für Managed Service for Prometheus sind so konzipiert, dass sie kontrollierbar sind. 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 Anzahl der an den globalen Datenspeicher des Dienstes gesendeten Samples reduzieren. Weitere Informationen finden Sie unter Exportierte Messwerte filtern. Verwenden Sie Relabeling-Konfigurationen für Messwerte in Ihrer Prometheus-Scraping-Konfiguration, um Messwerte basierend auf Label-Übereinstimmungen zum Zeitpunkt der Aufnahme zu ignorieren.

  • Speichern Sie Daten mit hoher Kardinalität und geringem Wert lokal. Sie können parallel zum verwalteten Dienst Standard-Prometheus mit den gleichen Extraktionskonfigurationen ausführen und Daten lokal speichern, bei denen es sich nicht lohnt, sie 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 abgerechnet würde, müssten Sie für die Kardinalität eines ganzen Monats auf einmal bezahlen, wenn ein neuer Container hochgefahren wird. Bei den pro Probe berechneten Preisen zahlen Sie nur, wenn der Container aktiv ist.

Abfragen, einschließlich Benachrichtigungsanfragen

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

Preisbeispiele basierend auf aufgenommenen Beispielen

Die folgenden Beispiele zeigen, wie sich die Kosten für das Erfassen von Messwerten schätzen lassen, die nach aufgenommenen Samples berechnet werden. Für Google Cloud Managed Service for Prometheus wird eine Stichproben-Abrechnung verwendet.

Diese Beispiele dienen der Veranschaulichung von Berechnungsmethoden und stellen keine Abrechnungsdaten dar.

Das grundlegende Szenario sieht so aus: Sie haben eine bestimmte Anzahl von Containern oder Pods, die jeden Monat Punkte in einer bestimmten Anzahl von Zeitreihen schreiben. Die Daten können aus Skalarwerten und/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 Beispiele schätzen, die für eine Zeitreihe im monatlichen Abrechnungszeitraum geschrieben wurden.

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 ein Beispiel. 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 Zeitreihe Verteilungswerte schreibt, kann jeder Wert 2 + n Beispiele 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 Proben:
      • Per Histogramm: 52
      • Pro Monat: 9.110.400 (52 * 1 Wert/15 s * 2.628.000 Sekunden/Monat)
    • Erwartete Beispiele, wenn 25 % leer sind:
      • Laut 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:
      • Per 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 Proben:
      • Per Histogramm: 52
      • Pro Monat: 2.277.600 (52 * 1 Wert/60 s * 2.628.000 Sekunden/Monat)
    • Erwartete Beispiele, wenn 25 % leer sind:
      • Laut 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:
      • Per 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 Proben:
      • Per Histogramm: 102
      • Pro Monat: 17.870.400 (102 * 1 Wert/15 s * 2.628.000 Sekunden/Monat)
    • Erwartete Beispiele, wenn 25 % leer sind:
      • Per 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:
      • Per 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 Proben:
      • Per Histogramm: 102
      • Pro Monat: 4.467.600 (102 * 1 Wert/60 s * 2.628.000 Sekunden/Monat)
    • Erwartete Beispiele, wenn 25 % leer sind:
      • Per 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:
      • Per 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 Schreibgeschwindigkeit Beispiele 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 Höchstwert für den 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 Milliarden bis 500 Milliarden (500.000 Millionen) 0,036 $/Million 9.000,00 €
Über 500 Milliarden (500.000 Millionen) 0,024 $/Million  

Im Rest dieses Abschnitts werden mögliche Szenarien durchgespielt.

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

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

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

In beiden Fällen liegen weniger als 50.000 Millionen Beispiele vor, sodass nur der erste Preis gilt. Für die anderen Preise werden keine Beispiele berechnet.

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



Gesamt
17.520 Millionen



17.520 Millionen
Bis zu 50.000 Millionen
Bis zu 250.000 Millionen
Bis zu 500.000 Millionen
Mehr als 500.000 Millionen
1.051,20 $



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



Gesamt
4.380 Millionen



4.380 Millionen
Bis zu 50.000 Millionen
Bis zu 250.000 Millionen
Bis zu 500.000 Millionen
Mehr als 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 Beispiel/15 s), beträgt die Anzahl der pro Monat geschriebenen Beispiele 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.
  • Für die anderen Preise werden keine Beispiele berechnet.

Variante B: Wenn jede Zeitachse alle 60 Sekunden geschrieben wird (1 Beispiel/60 s), beträgt die Anzahl der pro Monat geschriebenen Beispiele 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 Beispiel/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
Mehr als 500.000 Millionen
3.000,00 $
6.009,60 $


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



Gesamt
43.800 Millionen



43.800 Millionen
Bis zu 50.000 Millionen
Bis zu 250.000 Millionen
Bis zu 500.000 Millionen
Mehr als 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 Beispiel/15 s), beträgt die Anzahl der pro Monat geschriebenen Beispiele 1.349.040.000.000 (13.490.400 Beispiele/Monat * 1.000 Zeitachsen * 100 Container) bzw. 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 Beispiele werden zum dritten Preis berechnet.
  • Die verbleibenden 749.040 Millionen Beispiele werden zum vierten Preis berechnet.

Variante B: Wenn jede Zeitachse alle 60 Sekunden geschrieben wird (1 Beispiel/60 s), beträgt die Anzahl der pro Monat geschriebenen Beispiele 337.260.000.000 (3.372.600 Beispiele/Monat * 1.000 Zeitachsen * 100 Container) bzw. 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 Beispiel/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
Mehr als 500.000 Millionen
3.000,00 $
9.600,00 $
9.000,00 $
17.976,96 $
39.576,96$
B (1 Beispiel/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 Beispiel/15 s), beträgt die Anzahl der pro Monat geschriebenen Beispiele 108.624.000.000.000 (10.862.400 Beispiele/Monat * 10.000 Zeitachsen * 1.000 Container) bzw. 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 Beispiele werden zum dritten Preis berechnet.
  • Die restlichen 108.124.000 Millionen Beispiele werden zum vierten Preis berechnet.

Variante B: Wenn jede Zeitachse alle 60 Sekunden geschrieben wird (1 Beispiel/60 s), beträgt die Anzahl der pro Monat geschriebenen Beispiele 27.156.000.000.000 (2.715.600 Beispiele/Monat * 10.000 Zeitachsen * 1.000 Container) bzw. 27.156.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 Beispiele werden zum dritten Preis berechnet.
  • Die verbleibenden 26.656.000 Millionen Beispiele werden zum vierten Preis berechnet.
Variante Aufgenommene Beispiele Aufnahmebereich Managed Service for Prometheus
(0,06 €; 0,048 €; 0,036 €; 0,024 €)
A (1 Beispiel/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
Mehr als 500.000 Millionen
3.000,00 $
9.600,00 $
9.000,00 $
2.594.976,00 $
2.616.576,00$
B (1 Beispiel/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
Mehr als 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 Zeitreihen mit einer Verteilung von 100 Buckets alle 15 Sekunden schreiben. Sie erwarten, dass 40 % der Buckets leer sind. Die Anzahl der pro Monat geschriebenen Beispiele liegt bei 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 Beispiele werden zum dritten Preis berechnet.
  • Die restlichen 108.299.200 Millionen Beispiele werden zum vierten Preis berechnet.
Variante Aufgenommene Beispiele Aufnahmebereich Managed Service for Prometheus
(0,06 €; 0,048 €; 0,036 €; 0,024 €)
2A + 4A



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
Mehr als 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 (Gültig ab 1. Oktober 2022)

Monitoringgebühren für jede regionale Ausführung einer Uptime-Prüfung, die über die kostenlose monatliche Kontingent von 1 Millionen 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. Die Belastung wird auf Ihrer Rechnung als SKU „CA14-D3DE-E67F“ für „Monitoring-Uptime-Checks“ ausgewiesen.

Die folgenden Beispiele zeigen, wie sich die Kosten für die Ausführung von Betriebszeitprüfungen schätzen lassen. Diese Beispiele dienen der Veranschaulichung von Berechnungsmethoden und stellen keine Abrechnungsdaten dar.

Anzahl der Ausführungen von Verfügbarkeitsdiagnosen zählen

Um die Kosten für Ihre Uptime-Prüfungen zu schätzen, müssen Sie wissen, wie viele regionale Ausführungen in einem Monat stattfinden. Monitoring-Gebühren 0,30 $ pro 1.000 Ausführungen, wobei 1 Million Ausführungen pro Monat kostenlos sind.

Sie können die Kosten für Ihre Betriebszeitprüfungen mit folgender Formel schätzen:

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

Die Anzahl der Ausführungen für jede Uptime-Prüfung hängt von den folgenden Konfigurationsoptionen ab:

  • Wie oft die Verfügbarkeitsdiagnose ausgeführt wird: jede Minute, alle 5, 10 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 Uptime-Prüfung 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 Uptime-Prüfung konfigurieren, geben Sie einen Standort für die Uptime-Prüfung an. Jeder Standort wird einer oder mehreren Regionen zugeordnet. In der folgenden Tabelle sind die gültigen Standorte für die Prüfung der Betriebszeit und die Regionen, auf die sie abgebildet werden, aufgeführt:

Standort für die Konfiguration der Verfügbarkeitsdiagnose Einschließlich 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 abgedeckt werden

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

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

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

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

  • Eine Verfügbarkeitsdiagnose, die einmal pro Minute in USA ausgeführt wird, läuft in drei Regionen. Wenn diese Verfügbarkeitsdiagnose für eine einzelne VM konfiguriert ist, wird sie 131.400-mal (3 * 43.800) pro Monat ausgeführt. Wenn die Prüfung für eine Ressourcengruppe mit 10 Mitgliedern konfiguriert ist, wird die Verfügbarkeitsdiagnose 1.314.000-mal (10 * 131.400) pro Monat ausgeführt.

  • Eine Verfügbarkeitsdiagnose, die einmal pro Minute in ASIA_PACIFIC, EUROPE und USA ausgeführt wird, läuft in 5 Regionen. Dieser Uptime-Check wird 219.000-mal pro Monat ausgeführt,wenn er für ein einzelnes Ziel konfiguriert ist.

In der folgenden Tabelle sehen Sie die Anzahl der Ausführungen pro Stunde und Monat für eine einzelne Uptime-Prüfung, die so konfiguriert ist, dass sie mit unterschiedlichen Häufigkeiten in unterschiedlichen Regionen ausgeführt wird:

Häufigkeit der Überprüfung, einmal alle:
 
Anzahl der Regionen
 
Stündliche Ausführungen
pro Ziel
Monatliche Ausführung
pro Zielgruppe
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 die Gesamtzahl der monatlichen Ausführungsabfragen und ziehen Sie 1.000.000 ab. Für die restlichen Ausführungen wird ein Preis von 0,30 $pro 1.000 Ausführungen berechnet .Multiplizieren Sie also die verbleibenden Ausführungen mit 0, 0003.

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

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

Monatliche Ausführungsrate insgesamt
 
Ausführbare kostenpflichtige Anzeigen im Monat
(über 1.000.000)
Kosten
(0,30 $/1.000 Ausführungen)
131.400 0 0,00 $

Szenario 2: Sie haben eine Verfügbarkeitsprüfung am Standort USA , die eine Ressourcengruppe mit 10 Mitgliedern einmal pro Minute überprüft. Diese Prüfung wird in 3 Regionen ausgeführt. Der Test wird 10 * 131.400-mal im 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ührungsrate insgesamt
 
Ausführbare kostenpflichtige Anzeigen im Monat
(über 1.000.000)
Kosten
(0,30 $/1.000 Ausführungen)
1.314.000 (10 Ziele) 314.000 94,20 €

Szenario 3: Sie haben 10 GLOBAL-Uptime-Checks, von denen jeder einmal pro Minute eine VM prüft. Diese Prüfungen werden in 6 Regionen durchgeführt, wobei 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 $ pro Monat.

Monatliche Ausführungsrate insgesamt
 
Ausführbare kostenpflichtige Anzeigen im Monat
(über 1.000.000)
Kosten
(0,30 $/1.000 Ausführungen)
2.628.000 1.628.000 488,40 $

Szenario 4: Sie haben 5 Uptime-Checks am Standort USA, die alle 5 Minuten 1 VM prüfen. Diese Prüfungen werden in drei Regionen durchgeführt, sodass jede Prüfung 26.280-mal pro Monat ausgeführt wird. Die Gesamtzahl der monatlichen Ausführungen für diesen Prüfungssatz beträgt 105.120 (4 × 26.280).

Außerdem haben Sie zwei GLOBAL-Verfügbarkeitsdiagnosen, die alle 15 Minuten eine VM prüfen. Diese Prüfungen werden in 6 Regionen durchgeführt, sodass jede Prüfung 17.520-mal pro Monat ausgeführt wird. Die Gesamtzahl der monatlichen Ausführungen für diesen Überprüfungssatz beträgt 35.040 (2 × 17.520).

Die Gesamtzahl der monatlichen Ausführungen beträgt 140.160 (105.120 + 35.040). Dieses Szenario ist kostenlos.

Monatliche Ausführungsrate insgesamt
 
Ausführbare kostenpflichtige Anzeigen im Monat
(über 1.000.000)
Kosten
(0,30 $/1.000 Ausführungen)
140.160 0 0,00 $

Preise für die Ausführung von synthetischen Monitoren (gültig ab 1. November 2023)

Cloud Monitoring berechnet die Kosten für jede Ausführung eines synthetischen Monitors, die über die kostenlose Zuteilung von 100 Ausführungen pro Rechnungskonto pro Monat hinausgeht. Wenn Sie beispielsweise 3 synthetische Monitore erstellen und jeden von ihnen alle 5 Minuten ausführen lassen, beträgt die Gesamtzahl der Ausführungen pro Monat 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, ziehen Sie die kostenlose Zuteilung von der Gesamtzahl der Ausführungen ab und multiplizieren Sie das Ergebnis mit den Kosten:

Monatliche Ausführungsrate insgesamt
 
Zahlbare Ausführungen pro Monat
(mehr als 100 Ausführungen pro Rechnungskonto)
Kosten
(1,20 $/1.000 Ausführungen)
26.784 26.684 32,02 €

Preise für Benachrichtigungen

Ab April 2026 werden für Benachrichtigungen in Cloud Monitoring Gebühren erhoben. Das Preismodell sieht wie folgt aus:

  • 1,50 $ pro Monat für jede Bedingung in einer Benachrichtigungsrichtlinie.
  • 0,35 $ pro 1.000.000 Zeitreihen,die durch die Abfrage einer Bedingung in einer Benachrichtigungsrichtlinie bezüglich eines Messwerts 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, bei dem eine Reaktion erforderlich ist.

    Die Gebühr beträgt 1,50 $pro Monat pro Bedingung. Wenn Sie keine Kosten mehr für eine Bedingung zahlen möchten, müssen Sie die Benachrichtigungsrichtlinie löschen. Wenn Sie die Benachrichtigungsrichtlinie pausieren oder deaktivieren, werden Ihnen weiterhin Kosten in Rechnung gestellt.

  • Messwert- und logbasierte Benachrichtigungsrichtlinien: Benachrichtigungsrichtlinien, die einen beliebigen Bedingungstyp außer Log-Übereinstimmungsbedingungen verwenden, sind messwertbasierte Benachrichtigungsrichtlinien. Die Bedingungen von messwertbasierten Benachrichtigungsrichtlinien geben Zeitreihen zurück. In jedem Ausführungszeitraum führen die Bedingungen in den Benachrichtigungsrichtlinien für Messwerte Abfragen im Cloud Monitoring-Datenspeicher aus. Die zurückgegebenen Zeitreihen werden dann anhand eines Schwellenwerts ausgewertet, um festzustellen, ob die Benachrichtigungsrichtlinie ausgelöst wird.

    Logbasierte Benachrichtigungsrichtlinien verwenden Logübereinstimmungs-Bedingungen. Log-Match-Bedingungen liefern keine Zeitreihen.

  • Ausführungszeitraum: Wie oft Cloud Monitoring die Bedingung ausführt. Bei den meisten Bedingungen beträgt dieser Wert 30 Sekunden und kann nicht geändert werden. Bei Bedingungen, die eine PromQL-Abfrage verwenden, kann dieser Zeitraum festgelegt werden. Weitere Informationen finden Sie unter Ausführungszeitraum verlängern (nur PromQL).

  • Zurückgegebene Zeitreihen: Während jeder Ausführungsperiode führt eine Benachrichtigungsrichtlinie für Messwerte die Abfrage ihrer Bedingung im Cloud Monitoring-Datenspeicher aus. Cloud Monitoring gibt Zeitreihendaten als Antwort auf jede Abfrage zurück. Jede Zeitreihe in der Antwort wird als eine zurückgegebene Zeitreihe gezählt.

    Die Anzahl der Zeitreihen, die in einem Monat zurückgegeben werden, hängt von drei Faktoren ab:

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

    Betrachten Sie beispielsweise eine Konfiguration mit folgenden Eigenschaften:

    • 100 VMs, wobei jede VM einem Dienst zugeordnet ist.
    • Jede VM gibt einen Messwert aus, metric_name, der ein Label mit 10 Werten hat.
    • Insgesamt fünf Dienste.

    Da Sie 100 VMs haben, die jeweils 10 Zeitreihen erzeugen können (eine für jeden Labelwert), haben Sie insgesamt 1.000 unterliegende Zeitreihen. Jede VM enthält außerdem ein Metadaten-ähnliches Label, das aufzeichnet, zu welchem Ihrer fünf Dienste die VM gehört.

    Sie können Ihre Benachrichtigungsrichtlinien mit PromQL auf die folgenden Arten konfigurieren. Dabei führt jede Konfiguration zu einer anderen Anzahl von Zeitreihen, die pro Ausführungszeitraum zurückgegeben werden:

    Konfiguration PromQL-Abfrage Zurückgegebene Zeitreihen pro Zeitraum
    Keine Aggregation rate(metric_name[1m]) 1.000
    Aggregieren zur VM sum by (vm) (rate(metric_name[1m])) 100
    Nach Labelwert aggregieren sum by (label_key) (rate(metric_name[1m])) 10
    Daten für den Dienst aggregieren sum by (service) (rate(metric_name[1m])) 5
    Wert und Dienst zusammenfassen sum by (service, label_key) (rate(metric_name[1m])) 50
    In der Flotte aggregieren sum (rate(metric_name[1m])) 1
    Filtern und Aggregieren auf eine VM sum (rate(metric_name{vm="my_vm_name"}[1m])) 1
    Filtern und Aggregieren in einem Dienst sum (rate(metric_name{service="my_service_name"}[1m])) 1

Preisbeispiele

Die folgenden Beispiele beziehen sich auf einen Monat mit 30 Tagen und ergeben folgende Bewertungszeiträume:

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

Beispiel 1: Eine Richtlinie, die auf die VM aggregiert wird, 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
  • Bedingungsaggregation auf VM-Ebene
  • 30-sekündige Ausführungszeit
Resultierende Kosten
  • Kosten pro Bedingung: 1 Bedingung * 1,50 $ pro Monat = 1,50 $ pro Monat
  • Kosten für Zeitreihen: 100 zurückgegebene Zeitreihen pro Zeitraum * 86.400 Zeitraume pro Monat = 8,6 Millionen zurückgegebene Zeitreihen pro Monat * 0,35 $ pro Million Zeitreihen = 3,02 $ pro Monat
  • Gesamtkosten: 4,52$pro Monat

Beispiel 2: 100 Richtlinien (eine pro VM), Aggregieren auf die 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 aggregiert
  • 30-sekündige Ausführungszeit
Resultierende Kosten
  • Kosten für Bedingungen: 100 Bedingungen * 1,50 $ pro Monat = 150 $pro Monat
  • Kosten für Zeitreihen: 100 Bedingungen * 1 zurückgegebene Zeitreihe pro Bedingung und Zeitraum * 86.400 Zeiträume pro Monat = 8,6 Millionen zurückgegebene Zeitreihen pro Monat * 0,35 $ pro Million Zeitreihen = 3,02 $ pro Monat
  • Gesamtkosten: 153,02$pro Monat

Beispiel 3: Eine Richtlinie, aggregiert auf die VM, 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
  • Bedingungsaggregation auf VM-Ebene
  • 15-sekündige Ausführungszeit
Resultierende Kosten
  • Kosten pro Bedingung: 1 Bedingung * 1,50 $ pro Monat = 1,50 $ pro Monat
  • Kosten für Zeitreihen: 100 zurückgegebene Zeitreihen pro Zeitraum * 172.800 Zeitraume pro Monat = 17,3 Millionen zurückgegebene Zeitreihen pro Monat * 0,35 $ pro Million Zeitreihen = 6,05 $ pro Monat
  • Gesamtkosten: 7,55$pro Monat

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

Verwenden Sie in diesem Beispiel die folgenden Konfigurationen:

Daten

  • 100 VMs, wobei jede VM einem Dienst zugeordnet ist
  • Insgesamt fünf Dienste
  • Jede VM gibt einen Messwert aus, metric_name
  • metric_name hat ein Label mit 10 Werten
Benachrichtigungsrichtlinie
  • Eine Bedingung
  • Bedingung aggregiert auf Dienstebene
  • 30-sekündige Ausführungszeit
Resultierende Kosten
  • Kosten pro Bedingung: 1 Bedingung * 1,50 $ pro Monat = 1,50 $ pro Monat
  • Kosten für Zeitreihen: 5 zurückgegebene Zeitreihen pro Zeitraum * 86.400 Zeitraume pro Monat = 432.000 zurückgegebene Zeitreihen pro Monat * 0,35 $ pro Million Zeitreihen = 0,14 $ pro Monat
  • Gesamtkosten: 1,64$pro Monat

Beispiel 5: Aggregieren einer Richtlinie auf die VM; höhere zugrundeliegende 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
  • Bedingungsaggregation auf VM-Ebene
  • 30-sekündige Ausführungszeit
Resultierende Kosten
  • Kosten pro Bedingung: 1 Bedingung * 1,50 $ pro Monat = 1,50 $ pro Monat
  • Kosten für Zeitreihen: 100 zurückgegebene Zeitreihen pro Zeitraum * 86.400 Zeitraume pro Monat = 8,5 Millionen zurückgegebene Zeitreihen pro Monat * 0,35 $ pro Million Zeitreihen = 3,02 $ pro Monat
  • Gesamtkosten: 4,52$pro Monat

Beispiel 6: Eine Richtlinie für die VM zusammenfassen; zwei Messwerte in einer Bedingung zusammenfassen, 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 jeweils ein Label mit 10 Werten.
Benachrichtigungsrichtlinie
  • Eine Bedingung
  • Bedingungsaggregation auf VM-Ebene
  • Bedingung verwendet einen OR-Operator, um die Messwerte zu vereinen
  • 30-sekündige Ausführungszeit
Resultierende Kosten
  • Kosten pro Bedingung: 1 Bedingung * 1,50 $ pro Monat = 1,50 $ pro Monat
  • Kosten für Zeitreihen: 2 Messwerte * 100 zurückgegebene Zeitreihen pro Messwert und Zeitraum * 86.400 Zeiträume pro Monat = 17,3 Millionen zurückgegebene Zeitreihen pro Monat * 0,35 $ pro Million Zeitreihen = 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
  • Kosten für Bedingungen: 100 Bedingungen * 1,50 $ pro Monat = 150,00 $ pro Monat
  • Kosten für Zeitreihen: 0 $ (Log-basierte Benachrichtigungsrichtlinien geben keine Zeitreihen zurück.)
  • Gesamtkosten: 150,00$pro Monat

Vorschläge zur Senkung der Kosten für Benachrichtigungen

Wenn Sie Ihre metrikbasierten Benachrichtigungsrichtlinien konfigurieren, können Sie mithilfe der folgenden Vorschläge die Kosten für Ihre Benachrichtigungen senken.

Benachrichtigungsrichtlinien konsolidieren, um mehr Ressourcen zu verwalten

Aufgrund der Kosten von 1,50 $pro Bedingung ist es kostengünstiger, mit einer Benachrichtigungsrichtlinie mehrere Ressourcen zu überwachen, als mit einer Benachrichtigungsrichtlinie jede einzelne Ressource zu überwachen. Vergleichen Sie beispielsweise Beispiel 1 mit Beispiel 2: In beiden Beispielen überwachen Sie die gleiche Anzahl von Ressourcen. Beispiel 2 verwendet jedoch 100 Benachrichtigungsrichtlinien, während in Beispiel 1 nur eine Benachrichtigungsrichtlinie verwendet wird. Beispiel 1 ist also fast 150 $pro Monat günstiger.

Aggregieren Sie nur auf die Ebene, auf der Sie Benachrichtigungen benötigen.

Eine höhere Detailgenauigkeit der Aggregation führt zu höheren Kosten als eine geringere Detailgenauigkeit. So ist die Aggregierung auf Google Cloud-Projektebene günstiger als die Aggregierung auf Clusterebene und die Aggregierung auf Clusterebene günstiger als die Aggregierung auf Cluster- und Namespace-Ebene.

Vergleichen Sie beispielsweise Beispiel 1 mit Beispiel 4: Beide Beispiele arbeiten mit denselben zugrunde liegenden Daten und haben eine einzige Benachrichtigungsrichtlinie. Da die Benachrichtigungsrichtlinie in Beispiel 4 jedoch auf den Dienst aggregiert, ist sie günstiger als die Benachrichtigungsrichtlinie in Beispiel 1, die detaillierter auf die VM aggregiert.

Vergleichen Sie dazu Beispiel 1 mit Beispiel 5: In diesem Fall ist die Kardinalität der Metrik in Beispiel 5 10.000-mal höher als die Kardinalität der Metrik in Beispiel 1. Da die Benachrichtigungsrichtlinien in Beispiel 1 und Beispiel 5 jedoch beide auf die VM aggregiert werden und die Anzahl der VMs in beiden Beispielen gleich ist, sind die Preise in beiden Beispielen gleich hoch.

Wählen Sie bei der Konfiguration Ihrer Benachrichtigungsrichtlinien die Aggregationsebenen aus, die für Ihren Anwendungsfall am besten geeignet sind. Wenn Sie beispielsweise Benachrichtigungen zur CPU-Auslastung erhalten möchten, können Sie die Aggregation auf VM- und CPU-Ebene durchführen. Wenn Sie Benachrichtigungen zur Latenz nach Endpunkt erhalten möchten, sollten Sie die Daten auf Endpunktebene aggregieren.

Keine Benachrichtigungen zu Rohdaten oder nicht aggregierten Daten

Das Monitoring verwendet ein dimensionales Messwertsystem, bei dem jeder Messwert eine Kardinalität hat, die der Anzahl der überwachten Ressourcen multipliziert mit der Anzahl der Labels für diese Messwerte entspricht. Wenn beispielsweise 100 VMs einen Messwert ausgeben und dieser Messwert 10 Labels mit jeweils 10 Werten hat, beträgt die 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 10.000 Zeitreihen für jeden Ausführungszeitraum zurückgegeben. Wenn Sie jedoch auf der VM aggregieren, werden pro Ausführungszeitraum nur 100 Zeitreihen zurückgegeben, unabhängig von der Kardinalität der Labels der zugrunde liegenden Daten.

Wenn Sie Benachrichtigungen für Rohdaten verwenden, besteht das Risiko, dass die Zeitreihen ansteigen, wenn Ihre Messwerte neue Labels erhalten. Wenn im vorherigen Beispiel ein Nutzer ein neues Label zu Ihrem Messwert hinzufügt, erhöht sich die Gesamtkardinalität auf 100 * 11 * 10 = 11.000 Zeitreihen. In diesem Fall wird die Anzahl der zurückgegebenen Zeitreihen in jedem Ausführungszeitraum um 1.000 erhöht, obwohl Ihre Benachrichtigungsrichtlinie unverändert bleibt. Wenn Sie stattdessen auf die VM aggregieren, erhalten Sie trotz der erhöhten zugrunde liegenden Kardinalität immer noch nur 100 Zeitreihen.

Unnötige Antworten herausfiltern

Konfigurieren Sie Ihre Bedingungen, um nur Daten zu bewerten, die für Ihre Benachrichtigungsanforderungen erforderlich sind. Wenn Sie nichts unternehmen, um ein Problem zu beheben, sollten Sie es von Ihren Benachrichtigungsrichtlinien ausschließen. Beispielsweise müssen Sie wahrscheinlich nicht bei der Entwicklungs-VM eines Mitarbeiters benachrichtigt werden.

Um unnötige Benachrichtigungen und Kosten zu vermeiden, können Sie Zeitreihen ausschließen, die nicht wichtig sind. Sie können Google Cloud-Metadatenlabels verwenden, um Assets mit Kategorien zu taggen und dann die nicht benötigten Metadatenkategorien herauszufiltern.

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

Wenn Ihre Bedingung eine PromQL- oder MQL-Abfrage verwendet, können Sie mit einem Top-Streams-Operator eine Anzahl der Zeitreihen auswählen, die mit den höchsten Werten zurückgegeben werden:

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

Eine Begrenzung auf eine bestimmte Anzahl von Zeitreihen kann zu fehlenden Daten und fehlerhaften Benachrichtigungen führen, z. B.:

  • Wenn mehr als N Zeitreihen Ihren Schwellenwert überschreiten, gehen Daten außerhalb der N wichtigsten Zeitreihen verloren.
  • Wenn eine Zeitreihe außerhalb der N wichtigsten Zeitreihen einen Grenzwert überschreitet, werden Vorfälle möglicherweise automatisch geschlossen, obwohl die ausgeschlossene Zeitreihe den Grenzwert immer noch überschreitet.
  • Ihre Zustandsanfragen zeigen Ihnen möglicherweise keinen wichtigen Kontext wie Zeitreihen für das Basismodell, die wie vorgesehen funktionieren.

Um solche Risiken zu minimieren, wählen Sie große Werte für N aus und verwenden Sie den Top-Streams-Operator nur in Benachrichtigungsrichtlinien, die viele Zeitreihen auswerten, z. B. Benachrichtigungen für einzelne Kubernetes-Container.

Dauer der Ausführung erhöhen (nur ProMQL)

Wenn Ihre Bedingung eine PromQL-Abfrage verwendet, können Sie die Dauer des Ausführungszeitraums ändern, indem Sie das evaluationInterval-Feld in der Bedingung festlegen.

Bei längeren Auswertungsintervallen werden pro Monat weniger Zeitreihen zurückgegeben. Eine Abfrage mit einem Intervall von 15 Sekunden wird beispielsweise doppelt so oft ausgeführt wie eine Abfrage mit einem Intervall von 30 Sekunden. Eine Abfrage mit einem Intervall von 1 Minute wird halb so oft ausgeführt wie eine Abfrage mit einem Intervall von 30 Sekunden.

Wird deaktiviert

Wenn Ihr Google Cloud-Vertrag erst im April 2026 ausläuft, können Sie die Abrechnung für Benachrichtigungen aufschieben, bis der Vertrag zur Verlängerung ansteht. Fordern Sie dazu eine Befreiung vom Billing-Team für Cloud Monitoring-Benachrichtigungen an. Kunden mit aktiven Verträgen können auf Einzelfallbasis von der Gebühr befreit werden.

Du kannst eine Ausnahmegenehmigung beantragen. Die Frist dafür endet am 1. November 2024. Wenn Sie eine Rechnungsbefreiung bis zur Vertragsverlängerung beantragen möchten, füllen Sie das Formular für die Beantragung einer Rechnungsbefreiung aus.

Error Reporting

Fehlerdaten können über die Error Reporting API oder die Cloud Logging API an Ihr Google Cloud-Projekt gemeldet werden.

Die Nutzung von Fehlermeldungen ist kostenlos. Es können jedoch Kosten für Cloud Logging anfallen, da Logs von Cloud Logging generiert und dann gespeichert werden.

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

Cloud Profiler

Die Nutzung von Cloud Profiler ist kostenlos.

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 dazu, wie Sie Ihre aktuelle oder vergangene Nutzung ansehen können, finden Sie unter Rechnungen schätzen.

Kostenlose Trace-Spans

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

Automatisch generierte Traces verbrauchen kein Cloud Trace API-Kontingent und werden in den Messwerten zur API-Nutzung 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 ü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 Abrechnung aus.
Wählen Sie im Menü Messwerte die Option Monatliche Trace-Bereiche, die eingelesen wurden 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 die Systemlogs und ‑messwerte von GKE Enterprise fallen keine Gebühren an. Control-Plane-Logs, Control-Plane-Messwerte und eine kuratierte Teilmenge von Kube State-Messwerten sind standardmäßig aktiviert für GKE-Cluster in Google Cloud, die bei der Clustererstellung in einem GKE Enterprise-fähigen Projekt registriert sind. Für Logs der Steuerebene fallen Cloud Logging-Gebühren an, während die standardmäßig aktivierten Metriken ohne Aufpreis enthalten sind.

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 die Systemlogs und -messwerte von GKE Enterprise 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 der Google Cloud Observability-Produkte wird nach Datenvolumen berechnet. Abgesehen von den auf dieser Seite beschriebenen Kosten für das 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.

Wenn Sie mehr darüber erfahren möchten, wie Sie Ihre Kosten verwalten können, lesen Sie diese Blogbeiträge:

Wie wirken sich Messwertbereiche und Protokollbereiche auf die Abrechnung aus?

Messwertbereiche und Protokollbereiche wirken sich in den meisten Fällen nicht auf die Abrechnung aus. Logs und Messwerte werden dem Projekt, Rechnungskonto, Ordner oder der Organisation berechnet, die die Daten empfängt. Der Messwertbereich für ein Projekt definiert die Sammlung der Ressourcen, deren Messwerte das Projekt aufrufen und überwachen kann. Wenn Sie einen Messwertbereich definieren, ändern Sie weder die Ressource, die Messwertdaten empfängt, noch lassen Sie Daten duplizieren. Ebenso listet ein Logbereich nur die Ressourcen auf, in denen die Logeinträge gespeichert oder weitergeleitet werden, die Sie sich 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 dazu 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-Messwerte oder GKE Enterprise-Messwerte an, die mit bis zu 1 Datenpunkt pro Minute abgerechnet werden, der derzeit höchsten 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