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:
- Rechnungen schätzen
- Preisbeispiele
- Kosten mit dem Cost Explorer optimieren Der Cost Explorer bietet aktuelle und bisherige Visualisierungen von Kostendaten und Nutzungsmesswerten. Anhand der Daten lassen sich Optimierungsmöglichkeiten ermitteln.
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.
Cloud Logging-Kosten senken
Um die Speicherkosten für Cloud Logging zu senken, konfigurieren Sie Ausschlussfilter für Ihre Logsenken, damit Logeinträge mit geringem Wert nicht in Ihre Log-Buckets gestreamt werden. Sie können eine Logsenke so konfigurieren, dass alle Logeinträge, die mit einem Ausschlussfilter übereinstimmen, oder nur ein Prozentsatz der übereinstimmenden Logeinträge ausgeschlossen werden. Ausgeschlossene Logeinträge werden nicht in Ihre Log-Buckets gestreamt und nicht auf Ihr Speicherkontingent angerechnet. Weitere Informationen finden Sie unter Logsenkenfilter.
Die Speicherkosten für Cloud Logging gelten nur für Logdaten, die in Log-Buckets gespeichert sind. Sie können Ihre Logsenken so konfigurieren, dass Logdaten nicht in Log-Buckets gespeichert, sondern an eines der folgenden Ziele weitergeleitet werden:
Beim Weiterleiten von Logeinträgen an die aufgeführten Ziele fallen für Cloud Logging keine Gebühren an. Es können jedoch Gebühren anfallen, wenn Logeinträge an einem Ziel empfangen werden.
Informationen zum Weiterleiten von Logdaten 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 basierend auf Label-Matcher zum Zeitpunkt der Aufnahme 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 14zä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.
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
In diesem Abschnitt werden Strategien beschrieben, mit denen Sie die Kosten für Benachrichtigungen senken können.
Benachrichtigungsrichtlinien konsolidieren, um mehr Ressourcen abzudecken
Für Benachrichtigungen fallen Kosten pro Bedingung an. Verwenden Sie daher nach Möglichkeit eine Benachrichtigungsrichtlinie, um mehrere Ressourcen zu überwachen, anstatt für jede Ressource eine eigene Benachrichtigungsrichtlinie zu erstellen.
Angenommen, Sie haben 100 VMs. Jede VM generiert eine Zeitachse für den Messwerttyp my_metric. Es gibt zwei verschiedene Möglichkeiten, die Zeitreihe zu beobachten:
Sie erstellen eine Benachrichtigungsrichtlinie mit einer Bedingung. Die Zustandsmonitore
my_metricaggregieren Daten auf VM-Ebene. Nach der Aggregation gibt es für jede VM eine Zeitachse. Daher werden mit der Bedingung 100 Zeitreihen überwacht.Sie erstellen 100 Benachrichtigungsrichtlinien, die jeweils eine Bedingung enthalten. Jede Bedingung überwacht die Zeitachse
my_metricfür eine der VMs und aggregiert Daten auf VM-Ebene. Jede Bedingung überwacht also eine Zeitachse.
Die zweite Option, bei der 100 Bedingungen erstellt werden, ist teurer als die erste Option, bei der nur eine Bedingung erstellt wird. Bei beiden Optionen werden 100 Zeitreihen überwacht.
Nur auf der Ebene aggregieren, auf der Sie Benachrichtigungen erhalten möchten
Für jede Zeitreihe, die von einer Benachrichtigungsrichtlinie überwacht wird, fallen Kosten an. 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
Angenommen, Sie haben 100 VMs. Jede VM generiert eine Zeitachse für den Messwerttyp my_metric. Jede Ihrer VMs gehört zu einem von fünf Diensten. Sie möchten eine Benachrichtigungsrichtlinie mit einer Bedingung erstellen, mit der my_metric überwacht wird. Hier sind zwei verschiedene Aggregationsoptionen:
Sie aggregieren Daten für den Dienst. Nach der Aggregation gibt es für jeden Dienst eine Zeitachse. Die Bedingung überwacht also fünf Zeitreihen.
Sie aggregieren Daten auf VM-Ebene. Nach der Aggregation gibt es für jede VM eine Zeitachse. Daher werden mit der Bedingung 100 Zeitreihen überwacht.
Die zweite Option, mit der 100 Zeitreihen überwacht werden, ist teurer als die erste Option, mit der nur fünf Zeitreihen überwacht werden.
Wenn Sie Ihre Benachrichtigungsrichtlinien konfigurieren, wählen Sie 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 Dienst erhalten möchten, sollten Sie die Daten auf Dienstebene 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 das Einrichten von Benachrichtigungen für Rohdaten sehr teuer sein. Im vorherigen Beispiel werden für jeden Ausführungszeitraum 10.000 Zeitreihen zurückgegeben. Wenn Sie 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 Zeitachsen steigt, wenn Ihren Messwerten neue Labels hinzugefügt werden. 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 in 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 Vorfälle 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.
Operatoren für Top-Streams verwenden, um die Anzahl der zurückgegebenen Zeitreihen zu reduzieren
Wenn in Ihrer Bedingung eine PromQL-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:
- PromQL:
topk
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 Vorfällen 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, in denen viele Zeitreihen ausgewertet werden, z. B. Vorfälle 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 Ihre benutzerdefinierte Grenze 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 Messwerte insgesamt ü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:
-
Rufen Sie in der Google Cloud Console die Seite Abrechnung auf:
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.