Ab dem 1. Mai 2026 werden für die Verwendung von Benachrichtigungsrichtlinien in Cloud Monitoring Gebühren berechnet. Informationen zum Preismodell finden Sie unter Cloud Monitoring-Preise.
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_namehat ein Label mit 10 Werten.
- Eine Benachrichtigungsbedingung
- Bedingung wird auf VM-Ebene aggregiert
- 30-sekündiger Ausführungszeitraum
- 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_namehat ein Label mit 10 Werten.
- 100 Bedingungen
- Jede Bedingung wird gefiltert und zu einer VM aggregiert.
- 30-sekündiger Ausführungszeitraum
- 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_namehat ein Label mit 10 Werten.
- Eine Benachrichtigungsbedingung
- Bedingung wird auf VM-Ebene aggregiert
- 30-sekündiger Ausführungszeitraum
- 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_namehat ein Label mit 10 Werten.
- Eine Bedingung
- Aggregate auf Dienstebene abstimmen
- 30-sekündiger Ausführungszeitraum
- 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_namehat 100 Labels mit jeweils 1.000 Werten.
- Eine Bedingung
- Bedingung wird auf VM-Ebene aggregiert
- 30-sekündiger Ausführungszeitraum
- 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 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 Zeitreihen 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 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 nicht über die Entwicklungs-VM eines Praktikanten benachrichtigt werden.
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.
Top-Stream-Operatoren 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 auf eine bestimmte Höchstzahl begrenzen, kann das zu fehlenden Daten und fehlerhaften Vorfällen führen, 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 liegt, 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.