Google Cloud Observability-Kosten optimieren und überwachen

Auf dieser Seite wird beschrieben, wie Sie Ihre Google Cloud Observability-Kosten optimieren und überwachen können. Preisinformationen finden Sie unter Google Cloud Observability-Preise.

Möglicherweise sind auch die folgenden Dokumente für Sie interessant:

Optimieren

In diesem Abschnitt finden Sie Informationen dazu, wie Sie die Kosten für Cloud Logging, Cloud Trace und Google Cloud Managed Service for Prometheus senken oder optimieren können.

Logspeicher reduzieren

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

Eine weitere Möglichkeit, die Speicherkosten für Cloud Logging zu senken, besteht darin, Logs aus Cloud Logging an ein unterstütztes Ziel weiterzuleiten. 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 an einem Ziel empfangen werden:

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

Kosten für Managed Service for Prometheus optimieren

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 Stichproben durch Filtern reduzieren. Weitere Informationen finden Sie unter Exportierte Messwerte filtern. Verwenden Sie Messwert-Relabeling-Konfigurationen in Ihrer Prometheus-Scraping-Konfiguration, um Messwerte zum Zeitpunkt der Aufnahme basierend auf Label-Matcher zu verwerfen.

  • 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 jedes Mal, wenn ein neuer Container hochgefahren wird, die Kardinalität für einen ganzen Monat auf einmal bezahlen. Bei den pro Probe berechneten Preisen zahlen Sie nur, wenn der Container ausgeführt wird.

Abfragen, einschließlich Benachrichtigungsabfragen

Alle vom Nutzer ausgegebenen Abfragen, einschließlich der Abfragen, die beim Ausführen von Prometheus-Aufzeichnungsregeln ausgegeben werden, werden über Cloud Monitoring API-Aufrufe abgerechnet. Den aktuellen Preis finden Sie in der Zusammenfassungstabelle für Preise für Managed Service for Prometheus oder Monitoring-Preise.

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.

Kosten für Benachrichtigungen senken

Ab dem 1. Mai 2026 oder später werden für die Verwendung von Benachrichtigungsrichtlinien in Cloud Monitoring Gebühren berechnet. Informationen zum Preismodell finden Sie unter Preise für Benachrichtigungen.

In diesem Dokument werden Strategien beschrieben, mit denen Sie die Kosten für Benachrichtigungen senken können.

Benachrichtigungsrichtlinien konsolidieren, um mehr Ressourcen abzudecken

Aufgrund der Kosten von 0,10 $pro Bedingung ist es kostengünstiger, mehrere Ressourcen mit einer Benachrichtigungsrichtlinie zu überwachen, als für jede Ressource eine eigene Benachrichtigungsrichtlinie zu verwenden. Betrachten Sie hierzu folgende Beispiele:

Beispiel 1

Daten

  • 100 VMs
  • Jede VM gibt einen Messwert aus: metric_name.
  • metric_name hat ein Label mit 10 Werten.
Benachrichtigungsrichtlinie
  • Eine Benachrichtigungsbedingung
  • Bedingung wird auf VM-Ebene aggregiert
  • 30-sekündiger Ausführungszeitraum
Anfallende Kosten
  • Kosten für Bedingung: 1 Bedingung × 0,10 $ pro Monat = 0,10 $ pro Monat
  • Kosten für Zeitreihen: 100 zurückgegebene Zeitreihen pro 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: 3,12$pro Monat

Beispiel 2

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ündiger Ausführungszeitraum
Anfallende Kosten
  • Kosten für Bedingung: 100 Bedingungen × 0,10 $ pro Monat = 10 $pro Monat
  • Kosten für Zeitreihen: 100 Bedingungen * 1 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: 13,02$pro Monat

In beiden Beispielen überwachen Sie dieselbe Anzahl von Ressourcen. In Beispiel 2 werden jedoch 100 Benachrichtigungsrichtlinien verwendet, während in Beispiel 1 nur eine Benachrichtigungsrichtlinie verwendet wird. Daher ist Beispiel 1 fast 10 $pro Monat günstiger.

Nur auf der Ebene aggregieren, auf der Sie Benachrichtigungen erhalten möchten

Die Aggregation auf höheren Detaillierungsebenen führt zu höheren Kosten als die Aggregation auf niedrigeren Detaillierungsebenen. Die Aggregation auf Projektebene ist beispielsweise günstiger als die Aggregation auf Clusterebene und die Aggregation auf Clusterebene ist günstiger als die Aggregation auf Cluster- und Namespace-Ebene. Google Cloud

Betrachten Sie hierzu folgende Beispiele:

Beispiel 1

Daten

  • 100 VMs
  • Jede VM gibt einen Messwert aus: metric_name.
  • metric_name hat ein Label mit 10 Werten.
Benachrichtigungsrichtlinie
  • Eine Benachrichtigungsbedingung
  • Bedingung wird auf VM-Ebene aggregiert
  • 30-sekündiger Ausführungszeitraum
Anfallende Kosten
  • Kosten für Bedingung: 1 Bedingung × 0,10 $ pro Monat = 0,10 $ pro Monat
  • Kosten für Zeitreihen: 100 zurückgegebene Zeitreihen pro 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: 3,12$pro Monat

Beispiel 4

Daten

  • 100 VMs, wobei jede VM zu einem Dienst gehört
  • Insgesamt fünf Dienste
  • Jede VM gibt einen Messwert aus: metric_name.
  • metric_name hat ein Label mit 10 Werten.
Benachrichtigungsrichtlinie
  • Eine Bedingung
  • Aggregate auf Dienstebene abstimmen
  • 30-sekündiger Ausführungszeitraum
Anfallende Kosten
  • Kosten für Bedingung: 1 Bedingung × 0,10 $ pro Monat = 0,10 $ pro Monat
  • Kosten für Zeitreihen: 5 zurückgegebene Zeitreihen pro Zeitraum * 86.400 Zeiträume pro Monat = 432.000 zurückgegebene Zeitreihen pro Monat * 0,35 $ pro Million Zeitreihen = 0,14 $ pro Monat
  • Gesamtkosten: 0,24$pro Monat

Beispiel 5

Daten

  • 100 VMs
  • Jede VM gibt einen Messwert aus: metric_name.
  • metric_name hat 100 Labels mit jeweils 1.000 Werten.
Benachrichtigungsrichtlinie
  • Eine Bedingung
  • Bedingung wird auf VM-Ebene aggregiert
  • 30-sekündiger Ausführungszeitraum
Anfallende Kosten
  • Kosten für Bedingung: 1 Bedingung × 0,10 $ pro Monat = 0,10 $ pro Monat
  • Kosten für Zeitreihen: 100 zurückgegebene Zeitreihen pro Zeitraum * 86.400 Zeiträume pro Monat = 8,5 Millionen zurückgegebene Zeitreihen pro Monat * 0,35 $ pro Million Zeitreihen = 3,02 $ pro Monat
  • Gesamtkosten: 3,12$pro Monat

Vergleich von Beispiel 1 und Beispiel 4: Beide Beispiele basieren auf denselben zugrunde liegenden Daten und haben eine einzige Benachrichtigungsrichtlinie. Da die Benachrichtigungsrichtlinie in Beispiel 4 jedoch auf den Dienst aggregiert wird, ist sie kostengünstiger als die Benachrichtigungsrichtlinie in Beispiel 1, die detaillierter auf die VM aggregiert wird.

Vergleichen Sie außerdem Beispiel 1 mit Beispiel 5: In diesem Fall ist die Messwertkardinalität in Beispiel 5 10.000-mal höher als die Messwertkardinalität in Beispiel 1. Da die Benachrichtigungsrichtlinie in Beispiel 1 und in Beispiel 5 jedoch beide auf die VM aggregiert werden und die Anzahl der VMs in beiden Beispielen gleich ist, sind die Beispiele preislich gleichwertig.

Wählen Sie beim Konfigurieren Ihrer Benachrichtigungsrichtlinien 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 die Daten auf Endpunktebene aggregieren.

Keine Benachrichtigungen für Rohdaten ohne Aggregierung festlegen

Für die Überwachung wird ein System mit dimensionalen Messwerten verwendet. Die Kardinalität eines Messwerts entspricht der Anzahl der überwachten Ressourcen 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 die Gesamtkardinalität 100 × 10 × 10 = 10.000.

Aufgrund der Art und Weise, wie die Kardinalität skaliert wird, kann die Benachrichtigung über Rohdaten extrem teuer sein. Im vorherigen Beispiel werden für jeden Ausführungszeitraum 10.000 Zeitreihen zurückgegeben. Wenn Sie die Daten jedoch auf VM-Ebene aggregieren, werden unabhängig von der Kardinalität der zugrunde liegenden Daten nur 100 Zeitreihen pro Ausführungszeitraum zurückgegeben.

Wenn Sie Warnungen für Rohdaten einrichten, besteht außerdem das Risiko, dass die Anzahl der Zeitreihen steigt, wenn Ihre Messwerte neue Labels erhalten. Wenn ein Nutzer im vorherigen Beispiel 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 Zeitreihen bei jedem Ausführungszeitraum um 1.000, obwohl sich Ihre Benachrichtigungsrichtlinie nicht ändert. Wenn Sie stattdessen nach der VM aggregieren, werden trotz der erhöhten zugrunde liegenden Kardinalität nur 100 Zeitreihen zurückgegeben.

Unnötige Antworten herausfiltern

Konfigurieren Sie Ihre Bedingungen so, dass nur die Daten ausgewertet werden, die für Ihre Benachrichtigungen erforderlich sind. Wenn Sie nichts unternehmen möchten, um ein Problem zu beheben, schließen Sie es aus Ihren Benachrichtigungsrichtlinien aus. So müssen Sie beispielsweise wahrscheinlich keine Benachrichtigungen für die Entwicklungs-VM eines Praktikanten einrichten.

Um unnötige Benachrichtigungen und Kosten zu vermeiden, können Sie Zeitreihen herausfiltern, die nicht wichtig sind. Mit Google Cloud -Metadatenlabels können Sie Assets mit Kategorien taggen und dann die nicht benötigten Metadatenkategorien herausfiltern.

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

Wenn für Ihre Bedingung eine PromQL- oder MQL-Abfrage verwendet wird, können Sie mit einem „top-streams“-Operator eine bestimmte Anzahl der Zeitreihen mit den höchsten Werten auswählen, die zurückgegeben werden:

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

Wenn Sie die Anzahl der Zeitreihen begrenzen, kann es zu fehlenden Daten und fehlerhaften Benachrichtigungen kommen, z. B.:

  • Wenn mehr als N Zeitreihen Ihren Grenzwert überschreiten, fehlen Daten außerhalb der N wichtigsten Zeitreihen.
  • Wenn eine Zeitreihe mit Verstoß außerhalb der N wichtigsten Zeitreihen auftritt, werden Ihre Vorfälle möglicherweise automatisch geschlossen, obwohl die ausgeschlossene Zeitreihe den Grenzwert weiterhin überschreitet.
  • In Ihren Bedingungsabfragen werden möglicherweise keine wichtigen Kontextinformationen wie Baseline-Zeitreihen angezeigt, die wie vorgesehen funktionieren.

Um solche Risiken zu minimieren, sollten Sie große Werte für N auswählen und den Operator „top-streams“ nur in Benachrichtigungsrichtlinien verwenden, die viele Zeitreihen auswerten, z. B. Benachrichtigungen für einzelne Kubernetes-Container.

Ausführungszeitraum verlängern (nur PromQL)

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

Längere Auswertungsintervalle führen zu weniger Zeitreihen pro Monat. Eine Bedingungsabfrage mit einem 15-Sekunden-Intervall wird beispielsweise doppelt so oft ausgeführt wie eine Abfrage mit einem 30-Sekunden-Intervall und eine Abfrage mit einem 1-Minuten-Intervall halb so oft wie eine Abfrage mit einem 30-Sekunden-Intervall.

Überwachen

In diesem Abschnitt wird beschrieben, wie Sie Ihre Kosten überwachen, indem Sie Benachrichtigungsrichtlinien erstellen. Mit einer Benachrichtigungsrichtlinie können Messwertdaten überwacht werden. Sie werden benachrichtigt, wenn diese Daten einen Grenzwert überschreiten.

Aufgenommene Log-Byte pro Monat überwachen

Verwenden Sie die folgenden Einstellungen, um eine Benachrichtigungsrichtlinie zu erstellen, sodass Sie benachrichtigt werden, wenn die Anzahl der in Ihre Log-Buckets geschriebenen Log-Byte 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 Monatlich aufgenommene Logbytes 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.

Aufgenommene Gesamtmesswerte überwachen

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.

Monatlich aufgenommene Trace-Spans überwachen

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 Monatlich aufgenommene Trace-Spans 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.

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. Rufen Sie in der Google Cloud Console die Seite Abrechnung auf:

    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.