In diesem Dokument werden Strategien beschrieben, mit denen Sie die Kosten für Benachrichtigungen senken können.
Benachrichtigungsrichtlinien konsolidieren, um mehr Ressourcen zu überwachen
Aufgrund der Kosten von 1,50 $pro Bedingung ist es kostengünstiger, eine Benachrichtigungsrichtlinie für die Überwachung mehrerer Ressourcen zu verwenden, als eine Benachrichtigungsrichtlinie für die Überwachung jeder Ressource. Betrachten Sie hierzu folgende Beispiele:
Beispiel 1
Daten
- 100 VMs
- Jede VM sendet einen Messwert,
metric_name metric_namehat ein Label mit 10 Werten
- Eine Benachrichtigungsbedingung
- Bedingung wird auf VM-Ebene zusammengefasst
- 30-sekündige Ausführung
- Bedingungspreis: 1 Bedingung * 1,50 $ pro Monat = 1,50 $ 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: 4,52$pro Monat
Beispiel 2
Daten
- 100 VMs
- Jede VM sendet einen Messwert,
metric_name metric_namehat ein Label mit 10 Werten
- 100 Bedingungen
- Jede Bedingung wird gefiltert und zu einer VM zusammengefasst.
- 30-sekündige Ausführung
- Bedingungskosten: 100 Bedingungen * 1,50 $ pro Monat = 150 $pro Monat
- Kosten für Zeitreihen: 100 Bedingungen * 1 zurückgegebene 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: 153,02$pro Monat
In beiden Beispielen wird dieselbe Anzahl von Ressourcen überwacht. In Beispiel 2 werden jedoch 100 Benachrichtigungsrichtlinien verwendet, während in Beispiel 1 nur eine Benachrichtigungsrichtlinie verwendet wird. Beispiel 1 ist also fast 150 $günstiger pro Monat.
Aggregieren Sie nur auf die Ebene, für die Sie eine Benachrichtigung erhalten möchten.
Die Aggregation auf höhere Detailebenen führt zu höheren Kosten als die Aggregation auf niedrigere Detailebenen. So ist die Aggregation auf Google Cloud-Projektebene beispielsweise günstiger als die Aggregation auf Clusterebene. Die Aggregation auf Clusterebene ist wiederum günstiger als die Aggregation auf Cluster- und Namespaceebene.
Betrachten Sie hierzu folgende Beispiele:
Beispiel 1
Daten
- 100 VMs
- Jede VM sendet einen Messwert,
metric_name metric_namehat ein Label mit 10 Werten
- Eine Benachrichtigungsbedingung
- Bedingung wird auf VM-Ebene zusammengefasst
- 30-sekündige Ausführung
- Bedingungspreis: 1 Bedingung * 1,50 $ pro Monat = 1,50 $ 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: 4,52$pro Monat
Beispiel 4
Daten
- 100 VMs, wobei jede VM zu einem Dienst gehört
- Insgesamt fünf Dienste
- Jede VM sendet einen Messwert,
metric_name metric_namehat ein Label mit 10 Werten
- Eine Bedingung
- Bedingungen für Aggregationen auf Dienstebene
- 30-sekündige Ausführung
- Bedingungspreis: 1 Bedingung * 1,50 $ pro Monat = 1,50 $ pro Monat
- Kosten für Zeitreihen: 5 Zeitreihen pro Zeitraum * 86.400 Zeiträume pro Monat = 432.000 Zeitreihen pro Monat * 0,35 $ pro Million Zeitreihen = 0,14 $ pro Monat
- Gesamtkosten: 1,64$pro Monat
Beispiel 5
Daten
- 100 VMs
- Jede VM sendet einen Messwert,
metric_name metric_namehat 100 Labels mit jeweils 1.000 Werten
- Eine Bedingung
- Bedingung wird auf VM-Ebene zusammengefasst
- 30-sekündige Ausführung
- Bedingungspreis: 1 Bedingung * 1,50 $ pro Monat = 1,50 $ 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: 4,52$pro Monat
Vergleichen Sie Beispiel 1 mit Beispiel 4: Beide Beispiele basieren auf denselben zugrunde liegenden Daten und haben dieselbe 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 Kardinalität des Messwerts in Beispiel 5 10.000-mal höher als die Kardinalität des Messwerts 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 gleich.
Wählen Sie beim Konfigurieren Ihrer Benachrichtigungsrichtlinien die 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 zusammenfassen. Wenn Sie Benachrichtigungen zur Latenz nach Endpunkt erhalten möchten, sollten Sie die Daten auf Endpunktebene zusammenfassen.
Keine Benachrichtigungen für Rohdaten senden
Für die Überwachung wird ein dimensionales Messwertsystem verwendet, bei dem die Gesamtzahl [Cardinalität][Cardinality] eines Messwerts der Anzahl der überwachten Ressourcen multipliziert mit der Anzahl der Labelkombinationen für diesen Messwert entspricht. Wenn Sie beispielsweise 100 VMs haben, die einen Messwert senden, und dieser Messwert 10 Labels mit jeweils 10 Werten hat, beträgt die Gesamtkardinalität 100 × 10 × 10 = 10.000.
Aufgrund der Skalierung der Kardinalität können Benachrichtigungen zu Rohdaten extrem teuer sein. Im vorherigen Beispiel werden für jeden Ausführungszeitraum 10.000 Zeitreihen zurückgegeben. Wenn Sie jedoch eine Aggregation auf VM-Ebene vornehmen, werden unabhängig von der Kardinalität der Labels der zugrunde liegenden Daten nur 100 Zeitreihen pro Ausführungszeitraum zurückgegeben.
Wenn Sie Benachrichtigungen zu Rohdaten erhalten, besteht außerdem das Risiko, dass die Zeitreihen länger werden, wenn Ihre Messwerte neue Labels erhalten. Wenn ein Nutzer Ihrem Messwert im vorherigen Beispiel 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 Zeitreihen in jedem Ausführungszeitraum um 1.000, auch wenn sich Ihre Benachrichtigungsrichtlinie nicht geändert hat. Wenn Sie stattdessen auf die VM aggregieren, werden trotz der erhöhten zugrunde liegenden Kardinalität immer noch nur 100 Zeitreihen zurückgegeben.
Unnötige Antworten herausfiltern
Konfigurieren Sie die Bedingungen so, dass nur Daten ausgewertet werden, die für Ihre Benachrichtigungen erforderlich sind. Wenn Sie nichts unternehmen würden, um ein Problem zu beheben, schließen Sie es aus Ihren Benachrichtigungsrichtlinien aus. Beispielsweise müssen Sie wahrscheinlich nicht für die Entwicklungs-VM eines Praktikanten benachrichtigt werden.
Sie können Zeitreihen herausfiltern, die nicht wichtig sind, um unnötige Benachrichtigungen und Kosten zu vermeiden. 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- oder MQL-Abfrage verwendet wird, können Sie mit einem Top-Streams-Operator eine Reihe der Zeitreihen auswählen, die mit den höchsten Werten zurückgegeben wurden:
Mit einer topk(metric, 5)-Klausel in einer PromQL-Abfrage lässt sich beispielsweise die Anzahl der zurückgegebenen Zeitreihen in jedem Ausführungszeitraum auf fünf begrenzen.
Wenn Sie die Anzahl der Zeitreihen begrenzen, kann das zu fehlenden Daten und fehlerhaften Benachrichtigungen führen, z. B.:
- Wenn mehr als N Zeitreihen den Grenzwert überschreiten, gehen Daten außerhalb der N wichtigsten Zeitreihen verloren.
- Wenn eine Zeitreihe, die den Grenzwert überschreitet, nicht zu den N wichtigsten Zeitreihen gehört, werden Ihre Vorfälle möglicherweise automatisch geschlossen, obwohl die ausgeschlossene Zeitreihe den Grenzwert weiterhin überschreitet.
- Ihre Bedingungsabfragen enthalten möglicherweise keinen wichtigen Kontext, z. B. Zeitreihen für den Vergleich, die wie vorgesehen funktionieren.
Um solche Risiken zu minimieren, wählen Sie große Werte für N aus und verwenden Sie den Operator „top-streams“ nur in Benachrichtigungsrichtlinien, in denen viele Zeitreihen ausgewertet werden, z. B. Benachrichtigungen für einzelne Kubernetes-Container.
Dauer des Ausführungszeitraums erhöhen (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.
Bei längeren Auswertungsintervallen werden pro Monat weniger Zeitreihen zurückgegeben. So wird eine Bedingungsabfrage mit einem Intervall von 15 Sekunden beispielsweise doppelt so oft ausgeführt wie eine Abfrage mit einem Intervall von 30 Sekunden. Eine Abfrage mit einem Intervall von 1 Minute wird dagegen halb so oft ausgeführt wie eine Abfrage mit einem Intervall von 30 Sekunden.