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 |
_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 |
# 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.
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:
-
Öffnen Sie in der Google Cloud Console die Seite 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.
- Wählen Sie im Navigationsmenü für die Abrechnung Budgets und Benachrichtigungen aus.
- Klicken Sie auf Budget erstellen.
- 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:
- Cloud Logging-Speichermodell
- Speicherpreise
- Preise für die Bindung
- Gesendete Netzwerkprotokolle
- Logspeicher reduzieren
- Preise für logbasierte Messwerte
- Benachrichtigungsrichtlinie für aufgenommene Logbyte pro Monat erstellen
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:
- Audit-Logs zur Administratoraktivität
- Audit-Logs zu Systemereignissen
- Audit-Logs für Google Workspace-Administratoren
- Audit-Logs zu Unternehmensgruppen
- Audit-Logs für die Anmeldung
- Access Transparency-Logs Informationen zum Aktivieren von Access Transparency-Logs finden Sie in der Dokumentation zu Access Transparency-Logs.
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:
- Definitionen für kostenpflichtige und kostenlose Messwerte.
- Beschreibungen byte- und samplebasierter Aufnahmestrategien.
- Preisbeispiele für Messwerte, die nach aufgenommenen Byte abgerechnet werden
- Preisbeispiele für Messwerte, die nach aufgenommenen Stichproben berechnet werden
- Preisbeispiele für die Ausführung von Verfügbarkeitsdiagnosen (Datum des Inkrafttretens: 1. Oktober 2022)
- Preisbeispiele für die Ausführung von synthetischem Monitoring (Datum des Inkrafttretens: 1. November 2023)
- Beschreibungen und Beispiele von Preisen für Benachrichtigungen (Gültig ab: April 2025).
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.
Sie können diese Seite auch über die Suchleiste finden.
-
Öffnen Sie in der Google Cloud Console die Seite settingsEinstellungen.
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:
- Google Cloud-Messwerte. Weitere Informationen finden Sie in Fußnote 2.
- GKE Enterprise-Messwerte: Weitere Informationen finden Sie in Fußnote 2.
- Istio-Messwerte
- Knative-Messwerte
- Google Kubernetes Engine-Systemmesswerte
agent.googleapis.com/agent/
-Messwerte
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:
Agent-Messwerte unter
agent.googleapis.com
, außer der Gruppeagent.googleapis.com/agent/
Ab dem 6. August 2021 werden die
agent.googleapis.com/processes/
-Messwerte mit 5 % der Volumenrate für andere kostenpflichtige Messwerte berechnet. Beispiel: Die Aufnahme von 100 MiB Prozessmesswerten kostet genauso viel wie die Aufnahme von 5 MiB anderer kostenpflichtiger Messwerte.3Messwerte aus Integrationen von Drittanbietern mit dem Ops-Agent. Diese Messwerte werden in Cloud Monitoring mit Kennzeichnungen im Format
workload.googleapis.com/APPLICATION.METRIC
aufgenommen. In diese Kategorie fällt beispielsweise der Messwerttypworkload.googleapis.com/nginx.requests
.OTLP-Messwerte (OpenTelemetry Protocol), die vom Ops-Agent als
workload.googleapis.com
-Messwerte in Cloud Monitoring aufgenommen wurden. Dies ist eine Konfigurationsoption. Weitere Informationen finden Sie unter Aufnahmeformate für OTLP-Messwerte.Benutzerdefinierte Messwerte, einschließlich, aber nicht beschränkt auf die Messwerte, die über die Cloud Monitoring API oder sprachspezifische Clientbibliotheken, OpenCensus und OpenTelemetry gesendet werden.
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:
- Messwerte aus Google Cloud Managed Service for Prometheus:
prometheus.googleapis.com
-Messwerte
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
undSOUTH_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
undUSA
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 der Benachrichtigungsterminologie
- Beispiele für Gebühren für verschiedene Konfigurationen von Benachrichtigungsrichtlinien.
- Vorschläge zur Kostensenkung durch Konsolidieren oder Löschen von Benachrichtigungsrichtlinien
- Informationen zum Deaktivieren der Abrechnung für Benachrichtigungsrichtlinien
Definitionen
Bedingung: Die Bedingung einer Benachrichtigungsrichtlinie beschreibt, wann eine Ressource oder eine Gruppe von Ressourcen sich in einem Zustand befindet, der eine Antwort erfordert.
- In Benachrichtigungsrichtlinien, in denen Filter zum Erstellen von Abfragen für Messwertschwellen oder Messwertfehlen verwendet werden, können bis zu sechs Bedingungen kombiniert werden.
- Benachrichtigungsrichtlinien mit den folgenden Abfragetypen können nur eine einzige Bedingung haben:
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
- Eine Benachrichtigungsbedingung
- Bedingung wird auf VM-Ebene aggregiert
- Ausführungszeitraum von 30 Sekunden
- 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
- 100 Bedingungen
- Jede Bedingung wird gefiltert und zu einer VM zusammengefasst
- Ausführungszeitraum von 30 Sekunden
- 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
- Eine PromQL-Benachrichtigungsbedingung
- Bedingung wird auf VM-Ebene aggregiert
- 15-sekündige Ausführungsphase
- 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
- Eine Bedingung
- Bedingung wird zur Serviceebene aggregiert
- Ausführungszeitraum von 30 Sekunden
- 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
- Eine Bedingung
- Bedingung wird auf VM-Ebene aggregiert
- Ausführungszeitraum von 30 Sekunden
- 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
undmetric_name_2
- Beide Messwerte haben ein Label mit jeweils 10 Werten
- 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
- 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)
- 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:
- Cloud Logging-Preise für Cloud-Administratoren: Vorgehensweise und Kosteneinsparungen
- Vier Schritte zur Verwaltung der Cloud Logging-Kosten mit einem Budget
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
- Dokumentation zu Google Cloud Observability
- Preisrechner ausprobieren
- Weitere Informationen zu Google Cloud Observability-Lösungen und -Anwendungsfällen