管理快訊費用

本文說明可降低快訊費用的策略。如要瞭解定價模式，請參閱「Google Cloud Observability 定價」和「快訊定價範例」。

使用 UI 內建的 Pricing Calculator 查看預估帳單

建立或編輯警告政策時，Cloud Alerting 會顯示政策的預估費用。您可以透過這項計算機，瞭解變更警告政策參數後，預估費用會如何變化。

使用 Metrics Explorer 驗證傳回的點數

警告政策查詢傳回的點數主要取決於警告政策查詢輸出內容的基數。如要查看警告政策的預估基數，請按照下列步驟操作：

  • 如果是指標閾值快訊條件，請使用 Metrics Explorer 建構相同的查詢。新增「計算時間序列」的次要轉換，並選取「無」。
  • 如果是 PromQL 警報條件，請將查詢複製到 Metrics Explorer，然後執行下列操作：
    • 將查詢分割成多個子句，方法是依據每個 >、<、>=、<=、==、!=、AND、OR 和 UNLESS 運算子進行分割。
    • 刪除不含指標的任何子句，例如數值門檻值。
    • 將每個子句包裝在 count() 函式中。
    • 加總結果。

  • 如果是 MQL 快訊觸發條件，請將查詢複製到 Metrics Explorer。移除 | condition 行。在結尾處新增 | group_by [], .count 行。

    MQL 已淘汰，Cloud Customer Care 可能會拒絕處理要求協助偵錯帳單問題的案件。

合併快訊政策，以便對更多資源執行作業

快訊會收取每項指標參照的費用，且每項指標門檻政策的每個條件都有一項指標參照。因此，請盡可能使用一項警告政策監控多項資源，而不是為每項資源建立一項警告政策。

舉例來說，假設您有 100 個 VM。每分鐘，每個 VM 會為 my_metric 指標類型產生一個點。以下提供兩種不同的方式，供您監控退回的點數：

  • 您建立的警告政策只有一個條件，因此只有一個指標參照。這項條件會監控 my_metric，並將資料匯總至 VM 層級。匯總後，每個 VM 都會傳回一個點。 因此，條件會為每次評估作業回傳 100 分。

  • 您建立了 100 項快訊政策，每項政策都包含一個條件，因此各有一項指標參照。每個條件都會監控其中一個 VM 的 my_metric 時間序列，並將資料匯總至 VM 層級。因此，每個條件在每次評估時都會傳回一個點。

第二個選項會建立 100 個條件 (100 個指標參照)，因此比第一個選項 (只建立 1 個條件，即 1 個指標參照) 更昂貴。這兩種選項每次評估都會回饋 100 點。

匯總至您需要發出快訊的層級

系統會為警報政策監控的每個時間序列傳回一個點。與匯總至較低精細程度相比，匯總至較高精細程度的成本較高。舉例來說，匯總至Google Cloud 專案層級的費用，會比匯總至叢集層級的費用低；匯總至叢集層級的費用，則會比匯總至叢集和命名空間層級的費用低。

舉例來說，假設您有 100 個 VM。每個 VM 都會為指標類型 my_metric 產生一個點。每個 VM 都屬於五項服務之一。您決定建立一項警告政策，其中包含一項監控 my_metric 的條件。以下提供兩種不同的匯總選項：

  • 您將資料匯總至服務。彙整後，每個警告政策執行作業都會針對每項服務傳回一個點。因此，條件每次執行都會傳回 5 分。

  • 您會將資料匯總至 VM 層級。匯總後，每項警告政策執行作業都會為每個 VM 傳回一個點。因此，條件每次執行都會傳回 100 點。

第二個選項每次執行會傳回 100 點，比第一個選項 (每次執行只會傳回 5 點) 貴。

設定快訊政策時，請選擇最適合用途的匯總層級。舉例來說，如果您想針對 CPU 使用率發出快訊，可以匯總至 VM 和 CPU 層級。如果您想根據服務延遲時間發出快訊，可能需要匯總至服務層級。

不要根據未經匯總的原始資料發送快訊

監控系統採用多維度指標，任何指標的總基數都等於受監控的資源數量，乘以該指標的標籤組合數量。舉例來說，如果您有 100 個 VM 發出指標，而該指標有 10 個標籤，每個標籤有 10 個值，則總基數為 100 * 10 * 10 = 10,000。

由於基數的規模，對原始資料發出快訊的成本可能極高。在上一個範例中，每個執行期間會傳回 10,000 點。不過，如果匯總至 VM，則無論基礎資料的標籤基數為何，每個執行期間只會傳回 100 個點。

如果根據原始資料發出快訊，當指標收到新標籤時，您也可能會收到更多回報點數。在先前的範例中，如果使用者為指標新增標籤，總基數就會增加至 100 * 11 * 10 = 11,000 個時間序列。在這種情況下，即使警示政策沒有變更，每個執行週期傳回的點數仍會增加 1,000 點。如果改為匯總至 VM，即使基礎基數增加，系統仍只會傳回 100 個時間序列。

篩除不必要的回覆

設定條件，只評估符合警報需求的資料。如果不想採取行動修正問題，請將該項目從警告政策中排除。舉例來說，您可能不需要針對實習生的開發 VM 發出快訊。

為減少不必要的事件和費用，您可以篩除不重要的時間序列。您可以使用 Google Cloud 中繼資料標籤為資產加上類別標記，然後篩除不需要的中繼資料類別。

使用頂層串流運算子減少傳回的點數

如果條件使用 PromQL 查詢，您可以運用 top-streams 運算子，選取傳回最高值的點數：

舉例來說，PromQL 查詢中的 topk(metric, 5) 子句會將每個執行週期傳回的點數限制為五個。

如果將點數限制為上限，可能會導致資料遺失和事件錯誤，例如：

  • 如果超過 N 個點違反門檻，您就會遺失前 N 個點以外的資料。
  • 如果違規點出現在前 N 個點以外，即使排除的點仍違反門檻，事件也可能會自動結案。
  • 條件查詢可能不會顯示重要背景資訊，例如可正常運作的基準點。

為降低這類風險，請為 N 選擇較大的值，並僅在評估多個時間序列的警報政策中使用 top-streams 運算子，例如個別 Kubernetes 容器的事件。

延長執行時間 (僅限 PromQL)

如果條件使用 PromQL 查詢，您可以透過在條件中設定 evaluationInterval 欄位，修改執行期間的長度。

評估間隔越長，每月傳回的點就越少；舉例來說，間隔 15 秒的條件查詢執行頻率是間隔 30 秒查詢的兩倍，間隔 1 分鐘的查詢執行頻率則是間隔 30 秒查詢的一半。

請勿使用「未指定的資源」(僅限記錄指標)

使用記錄指標的快訊條件可讓您將「未指定資源」設為受監控的資源類型。這麼做時，系統會針對 Cloud Monitoring 中的每個受監控資源類型，分別啟動查詢。由於每項查詢至少會傳回一個點，因此如果未指定資源類型，就會產生高額的點數費用。

如要降低帳單費用，請選擇特定資源類型，而非使用「未指定資源」。這是因為大多數以記錄為準的指標只會出現在一種資源類型中。如果記錄檔指標顯示多種資源類型，您可以建立多個警告政策，或在單一警告政策中使用多個條件。