管理快訊費用

您可以合併政策，並限制查詢傳回的時間序列點數量，藉此管理 Cloud Monitoring 警告政策的費用。如要減少傳回的資料點，可以匯總及篩選監控的時間序列，並調整 PromQL 評估間隔。您也可以在變更政策參數時，查看預估帳單更新。

如要瞭解定價模式，請參閱「Google Cloud Observability 定價」和「Alerting 定價範例」。

使用 UI 內建的價格計算工具，查看預估帳單

建立或編輯警告政策時，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 中的每個受監控資源類型，啟動個別的查詢。由於每項查詢至少會傳回一個資料點，因此如未指定資源類型，帳單費用會很高。

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