管理快訊費用

最快自 2026 年 5 月 1 日起,Cloud Monitoring 將開始收取快訊政策的使用費用。如要瞭解定價模式,請參閱 Google Cloud Observability 定價

本文說明可降低快訊費用的策略。

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

由於每個條件的費用為 $0.10 美元,因此使用一項快訊政策監控多項資源,比使用一項快訊政策監控一項資源更具成本效益。請見以下範例:

範例 1

資料

  • 100 個 VM
  • 每個 VM 會發出一個指標,即 metric_name
  • metric_name 有一個標籤,其中有 10 個值
快訊政策
  • 一個警告觸發條件
  • 將條件匯總至 VM 層級
  • 30 秒執行期
產生費用
  • 條件費用: 1 個條件 * 每月 $0.10 美元 = 每月 $0.10 美元
  • 時間序列費用: 每個週期傳回 100 個時間序列 * 每月 86,400 個週期 = 每月傳回 860 萬個時間序列 * 每百萬個時間序列 $0.35 美元 = 每月 $3.02 美元
  • 總費用每月$3.12 美元

示例 2

資料

  • 100 個 VM
  • 每個 VM 會發出一個指標,即 metric_name
  • metric_name 有一個標籤,其中有 10 個值
快訊政策
  • 100 個條件
  • 每項條件都會經過篩選並彙整至一個 VM
  • 30 秒執行期
產生費用
  • 條件費用:100 個條件 * 每月 $0.10 美元 = 每月 $10 美元
  • 時間序列費用: 100 個條件 * 每個週期每個條件傳回 1 個時間序列 * 每月 86,400 個週期 = 每月傳回 860 萬個時間序列 * 每 100 萬個時間序列 $0.35 美元 = 每月 $3.02 美元
  • 總費用每月$13.02 美元

在這兩個範例中,您監控的資源數量相同。不過,範例 2 使用 100 項快訊政策,範例 1 則只使用一項快訊政策。因此,範例 1 每月可省下近 $10 美元。

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

與匯總至較低精細程度相比,匯總至較高精細程度的成本較高。舉例來說,匯總至 Google Cloud 專案層級的費用,會比匯總至叢集層級的費用低;匯總至叢集層級的費用,則會比匯總至叢集和命名空間層級的費用低。

請見以下範例:

範例 1

資料

  • 100 個 VM
  • 每個 VM 會發出一個指標,即 metric_name
  • metric_name 有一個標籤,其中有 10 個值
快訊政策
  • 一個警告觸發條件
  • 將條件匯總至 VM 層級
  • 30 秒執行期
產生費用
  • 條件費用: 1 個條件 * 每月 $0.10 美元 = 每月 $0.10 美元
  • 時間序列費用: 每個週期傳回 100 個時間序列 * 每月 86,400 個週期 = 每月傳回 860 萬個時間序列 * 每百萬個時間序列 $0.35 美元 = 每月 $3.02 美元
  • 總費用每月$3.12 美元

示例 4

資料

  • 100 個 VM,每個 VM 屬於一項服務
  • 最多五項服務
  • 每個 VM 會發出一個指標,即 metric_name
  • metric_name 有一個標籤,其中有 10 個值
快訊政策
  • 一個條件
  • 將條件匯總至服務層級
  • 30 秒執行期
產生費用
  • 條件費用: 1 個條件 * 每月 $0.10 美元 = 每月 $0.10 美元
  • 時間序列費用: 每個週期傳回 5 個時間序列 * 每月 86,400 個週期 = 每月傳回 432,000 個時間序列 * 每百萬個時間序列 $0.35 美元 = 每月 $0.14 美元
  • 總費用每月$0.24 美元

範例 5

資料

  • 100 個 VM
  • 每個 VM 會發出一個指標,即 metric_name
  • metric_name 有 100 個標籤,每個標籤有 1,000 個值
快訊政策
  • 一個條件
  • 將條件匯總至 VM 層級
  • 30 秒執行期
產生費用
  • 條件費用: 1 個條件 * 每月 $0.10 美元 = 每月 $0.10 美元
  • 時間序列費用: 每個週期傳回 100 個時間序列 * 每月 86,400 個週期 = 每月傳回 850 萬個時間序列 * 每百萬個時間序列 $0.35 美元 = 每月 $3.02 美元
  • 總費用每月$3.12 美元

比較範例 1 和範例 4: 這兩個範例都使用相同的基礎資料,且只有一項快訊政策。不過,由於範例 4 中的快訊政策會匯總至服務,因此比範例 1 中的快訊政策便宜,後者會以更精細的方式匯總至 VM。

此外,請比較範例 1 和範例 5: 在本例中,範例 5 的指標基數比範例 1 的指標基數高出 10,000 倍。不過,由於範例 1 和範例 5 中的警報政策都會匯總至 VM,且兩個範例中的 VM 數量相同,因此價格相同。

設定快訊政策時,請選擇最適合您用途的匯總層級。舉例來說,如果您想針對 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 秒查詢的一半。