Kosten für Benachrichtigungen verwalten

Sie können die Kosten für Ihre Cloud Monitoring-Benachrichtigungsrichtlinien verwalten, indem Sie Richtlinien zusammenfassen und die Anzahl der Zeitreihenpunkte begrenzen, die von Ihren Abfragen zurückgegeben werden. Um die Anzahl der zurückgegebenen Punkte zu reduzieren, können Sie überwachte Zeitreihen aggregieren und filtern und PromQL-Auswertungsintervalle anpassen. Sie können auch sehen, wie sich die geschätzte Rechnung ändert, wenn Sie Richtlinienparameter anpassen.

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, werden in Cloud Alerting die geschätzten Kosten der Richtlinie angezeigt. 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 Metrics Explorer und gehen Sie dann so vor:
    • Teilen Sie Ihre Anfrage in separate Klauseln auf, indem Sie sie an jedem >-, <-, >=-, <=-, ==-, !=-, AND-, OR- und UNLESS-Operator aufteilen.
    • Löschen Sie alle Klauseln, die keinen Messwert enthalten, z. B. einen numerischen Grenzwert.
    • Schließen Sie jede Klausel 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, in denen um Hilfe bei der Fehlerbehebung von Abrechnungsproblemen gebeten wird, werden möglicherweise vom Cloud Customer Care abgelehnt.

Benachrichtigungsrichtlinien konsolidieren, um mehr Ressourcen abzudecken

Für Benachrichtigungen fallen Kosten pro Messwertverweis an. Jede Richtlinie für Messwertschwellenwerte hat einen Messwertverweis 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 beobachten:

  • 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 my_metric-Zeitreihe 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 werden 100 Punkte pro Bewertung zurückgegeben.

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 Granularitätsebenen führt zu höheren Kosten als die Aggregation auf niedrigeren Granularitätsebenen. Die Aggregation auf ProjektebeneGoogle Cloud 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.

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 entscheiden sich, eine Benachrichtigungsrichtlinie mit einer Bedingung zu 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.

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 Dienst erhalten möchten, sollten Sie die Daten auf Dienstebene aggregieren.

Keine Benachrichtigungen für Rohdaten ohne Aggregierung

Für das Ressourcenmonitoring 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 Punkte zurückgegeben. Wenn Sie jedoch auf die VM aggregieren, werden unabhängig von der Kardinalität der Labels der zugrunde liegenden Daten nur 100 Punkte pro Ausführungszeitraum zurückgegeben.

Wenn Sie Warnungen für Rohdaten einrichten, besteht auch 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 Zeitreihen. In diesem Fall erhöht sich die Anzahl der zurückgegebenen Punkte in jedem Ausführungszeitraum um 1.000, obwohl sich Ihre Benachrichtigungsrichtlinie nicht geändert hat. 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 Daten ausgewertet werden, die für Ihre Benachrichtigungen erforderlich sind. Wenn Sie nicht beabsichtigen, etwas zu beheben, sollten Sie es aus Ihren Benachrichtigungsrichtlinien ausschließen. So müssen Sie beispielsweise wahrscheinlich keine Benachrichtigung 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.

Mit Top-Stream-Operatoren die Anzahl der zurückgegebenen Punkte reduzieren

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

Mit der Klausel topk(metric, 5) 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 begrenzen, kann das zu fehlenden Daten und fehlerhaften Benachrichtigungen führen, z. B.:

  • Wenn mehr als N Punkte Ihren Schwellenwert überschreiten, fehlen Daten außerhalb der N Punkte mit den höchsten Werten.
  • Wenn ein Punkt, der gegen die Richtlinien verstößt, außerhalb der N Top-Punkten liegt, werden Ihre Benachrichtigungen möglicherweise automatisch geschlossen, obwohl die ausgeschlossenen Punkte weiterhin gegen den Grenzwert verstoßen.
  • 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, 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 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 überwachten Ressourcentyp festlegen. In diesem Fall wird für jeden überwachten Ressourcentyp in Cloud Monitoring eine separate Abfrage durch die Benachrichtigungsbedingung ausgelöst. Da für jede Abfrage mindestens ein zurückgegebener Punkt berechnet wird, führt das Nichtangeben des Ressourcentyps zu einer hohen Rechnung für zurückgegebene Punkte.

Wenn Sie Ihren Rechnungsbetrag 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.