Kosten für Benachrichtigungen verwalten

In diesem Dokument werden Strategien beschrieben, mit denen Sie die Kosten für Benachrichtigungen senken können. Informationen zum Preismodell finden Sie unter Google Cloud Observability-Preise und Preisbeispiele für Benachrichtigungen.

Geschätzte Rechnung mit dem Preisrechner in der Benutzeroberfläche ansehen

Wenn Sie eine Benachrichtigungsrichtlinie erstellen oder bearbeiten, zeigt Cloud Alerting die geschätzten Kosten der Richtlinie an. Mit diesem Rechner können Sie sehen, wie sich die geschätzten Kosten ändern, wenn Sie die Parameter Ihrer Benachrichtigungsrichtlinie ändern.

Mit dem Metrics Explorer die Anzahl der zurückgegebenen Punkte prüfen

Die Anzahl der von der Benachrichtigungsrichtlinienabfrage zurückgegebenen Punkte hängt hauptsächlich von der Kardinalität der Ausgabe Ihrer Benachrichtigungsrichtlinienabfrage ab. So rufen Sie die geschätzte Kardinalität Ihrer Benachrichtigungsrichtlinie auf:

  • Verwenden Sie für eine Benachrichtigungsbedingung mit Messwertschwellenwert den Metrics Explorer, um eine identische Abfrage zu erstellen. Fügen Sie eine sekundäre Transformation der Anzahl der Zeitreihen nach Keine hinzu.
  • Kopieren Sie für eine PromQL-Benachrichtigungsbedingung die Abfrage in den Metrics Explorer und gehen Sie dann so vor:
    • Teilen Sie Ihre Anfrage in separate Klauseln auf, indem Sie sie an jedem Operator >, <, >=, <=, ==, !=, AND, OR und UNLESS aufteilen.
    • Löschen Sie alle Klauseln, die keinen Messwert enthalten, z. B. einen numerischen Grenzwert.
    • Schließen Sie jeden Satz in eine count()-Funktion ein.
    • Addieren Sie die Ergebnisse.
  • Kopieren Sie die Abfrage für eine MQL-Benachrichtigungsbedingung in den Metrics Explorer. Entfernen Sie die Zeile | condition. Fügen Sie am Ende eine | group_by [], .count-Zeile hinzu.

    MQL ist veraltet und Anfragen an Cloud Customer Care zur Unterstützung bei der Fehlerbehebung von Abrechnungsproblemen werden möglicherweise abgelehnt.

Benachrichtigungsrichtlinien konsolidieren, um mehr Ressourcen abzudecken

Für Benachrichtigungen wird ein Kostenbetrag pro Messwertreferenz berechnet. Jede Richtlinie für Messwertschwellenwerte hat eine Messwertreferenz pro Bedingung. Verwenden Sie daher nach Möglichkeit eine Benachrichtigungsrichtlinie, um mehrere Ressourcen zu überwachen, anstatt für jede Ressource eine Benachrichtigungsrichtlinie zu erstellen.

Angenommen, Sie haben 100 VMs. Für jede VM wird jede Minute ein Punkt für den Messwerttyp my_metric generiert. Es gibt zwei Möglichkeiten, die zurückgegebenen Punkte zu überwachen:

  • Sie erstellen eine Benachrichtigungsrichtlinie mit einer Bedingung und damit mit einer Messwertreferenz. Die Bedingung überwacht my_metric und aggregiert Daten auf VM-Ebene. Nach der Aggregation wird für jede VM ein Punkt zurückgegeben. Daher werden bei der Bedingung 100 Punkte pro Auswertung zurückgegeben.

  • Sie erstellen 100 Benachrichtigungsrichtlinien, die jeweils eine Bedingung und damit eine Messwertreferenz enthalten. Jede Bedingung überwacht die Zeitachse my_metric für eine der VMs und aggregiert Daten auf VM-Ebene. Daher wird für jede Bedingung bei jeder Auswertung ein Punkt zurückgegeben.

Die zweite Option, bei der 100 Bedingungen (100 Messwertreferenzen) erstellt werden, ist teurer als die erste Option, bei der nur eine Bedingung (eine Messwertreferenz) erstellt wird. Bei beiden Optionen erhalten Sie 100 Punkte pro Bewertung.

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

Für jede Zeitreihe, die von einer Benachrichtigungsrichtlinie überwacht wird, wird ein Punkt zurückgegeben. 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. Für jede VM wird ein Punkt für den Messwerttyp my_metric generiert. 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 wird bei jeder Ausführung einer Benachrichtigungsrichtlinie ein Punkt für jeden Dienst zurückgegeben. Daher gibt die Bedingung 5 Punkte pro Ausführung zurück.

  • Sie aggregieren Daten auf VM-Ebene. Nach der Aggregation gibt jede Ausführung der Benachrichtigungsrichtlinie einen Punkt für jede VM zurück. Daher gibt die Bedingung 100 Punkte pro Ausführung zurück.

Die zweite Option, bei der 100 Punkte pro Ausführung zurückgegeben werden, ist teurer als die erste Option, bei der nur fünf Punkte pro Ausführung zurückgegeben 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 Punkte zurückgegeben. Wenn Sie jedoch auf VM-Ebene aggregieren, werden unabhängig von der Kardinalität der zugrunde liegenden Daten nur 100 Punkte pro Ausführungszeitraum zurückgegeben.

Wenn Sie Warnungen für Rohdaten einrichten, besteht außerdem das Risiko, dass mehr Punkte zurückgegeben werden, 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 Punkte 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 würden, um ein Problem zu beheben, sollten Sie es aus Ihren Benachrichtigungsrichtlinien ausschließen. 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 Punkte zu reduzieren

Wenn in Ihrer Bedingung eine PromQL-Abfrage verwendet wird, können Sie mit einem „top-streams“-Operator eine bestimmte Anzahl der zurückgegebenen Punkte mit den höchsten Werten auswählen:

Mit einer topk(metric, 5)-Klausel in einer PromQL-Abfrage wird beispielsweise die Anzahl der zurückgegebenen Punkte auf fünf pro Ausführungszeitraum begrenzt.

Wenn Sie die Anzahl der Punkte auf eine bestimmte Anzahl begrenzen, kann es zu fehlenden Daten und fehlerhaften Vorfällen kommen, z. B.:

  • Wenn mehr als N Punkte Ihren Grenzwert überschreiten, fehlen Daten außerhalb der N Punkte mit den höchsten Werten.
  • Wenn ein Verstoßpunkt außerhalb der N Top-Punkten liegt, werden Ihre Vorfälle möglicherweise automatisch geschlossen, obwohl die ausgeschlossenen Punkte den Grenzwert weiterhin überschreiten.
  • In Ihren Bedingungsabfragen werden möglicherweise keine wichtigen Kontextinformationen wie Baseline-Punkte 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 Punkten 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.

„Nicht angegebene Ressource“ nicht verwenden (nur logbasierte Messwerte)

Bei Benachrichtigungsbedingungen, die logbasierte Messwerte verwenden, können Sie „Nicht angegebene Ressource“ als Typ der überwachten Ressource festlegen. In diesem Fall wird mit der Benachrichtigungsbedingung eine separate Abfrage für jeden überwachten Ressourcentyp in Cloud Monitoring gestartet. Da für jede Abfrage mindestens ein zurückgegebener Punkt in Rechnung gestellt wird, führt die Nichtangabe des Ressourcentyps zu einer hohen Rechnung für zurückgegebene Punkte.

Wenn Sie Ihre Rechnung senken möchten, wählen Sie einen bestimmten Ressourcentyp aus, anstatt „Nicht angegebene Ressource“ zu verwenden. Das funktioniert, weil die meisten logbasierten Messwerte nur in einem Ressourcentyp enthalten sind. Wenn Ihr logbasierter Messwert in mehreren Ressourcentypen angezeigt wird, können Sie mehrere Benachrichtigungsrichtlinien erstellen oder mehrere Bedingungen in einer einzelnen Benachrichtigungsrichtlinie verwenden.